Cherry-pick README fixes into releases. (#344)

Author: twifkak

README.md

@@ -1,15 +1,15 @@
 # AMP Packager
 
-AMP Packager is a tool to [improve AMP
-URLs](https://www.ampproject.org/latest/blog/developer-preview-of-better-amp-urls-in-google-search).
-By running it in a proper configuration, web publishers may (eventually) have
-origin URLs appear in AMP search results.
+AMP Packager is a tool to [improve AMP URLs](https://blog.amp.dev/2018/11/13/developer-preview-of-better-amp-urls-in-google-search/)
+by [serving AMP using Signed Exchanges](https://amp.dev/documentation/guides-and-tutorials/optimize-and-measure/signed-exchange/).
+By running it in a proper configuration, web publishers enable origin URLs to
+appear in AMP search results.
 
 The AMP Packager works by creating [Signed HTTP
 Exchanges (SXGs)](https://wicg.github.io/webpackage/draft-yasskin-httpbis-origin-signed-exchanges-impl.html)
 containing AMP documents, signed with a certificate associated with the origin,
-with a maximum lifetime of 7 days. In the future, the [Google AMP
-Cache](https://www.ampproject.org/docs/fundamentals/how_cached) will fetch,
+with a maximum lifetime of 7 days. The [Google AMP
+Cache](https://amp.dev/documentation/guides-and-tutorials/learn/amp-caches-and-cors/how_amp_pages_are_cached/) will fetch,
 cache, and serve them, similar to what it does for normal AMP HTML documents.
 When a user loads such an SXG, Chrome validates the signature and then displays
 the certificate's domain in the URL bar instead of `google.com`, and treats the
@@ -18,6 +18,8 @@ web page as though it were on that domain.
 The packager is an HTTP server that sits behind a frontend server; it fetches
 and signs AMP documents as requested by the AMP Cache.
 
+As an alternative to running the packager, you can sign up for one of the SXG [service providers](https://github.com/ampproject/amppackager/wiki/Service-Providers).
+
 ## Packager/Signer
 
 ### How to use
@@ -102,6 +104,10 @@ For now, productionizing is a bit manual. The minimum steps are:
      2. If the URL points to an AMP page and the `AMP-Cache-Transform` request
         header is present, rewrite the URL by prepending `/priv/doc` and forward
         the request.
+
+        NOTE: If using nginx, prefer using `proxy_pass` with `$request_uri`,
+        rather than using `rewrite`, as in [this PR](https://github.com/Warashi/try-amppackager/pull/3),
+        to avoid percent-encoding issues.
      3. If at all possible, don't send URLs of non-AMP pages to `amppkg`; its
         [transforms](transformer/) may break non-AMP HTML.
      4. DO NOT forward `/priv/doc` requests; these URLs are meant to be
@@ -121,19 +127,21 @@ For now, productionizing is a bit manual. The minimum steps are:
      restart amppkg (per
      [#93](https://github.com/ampproject/amppackager/issues/93)).
   7. Keep amppkg updated from `releases` (the default branch, so `go get` works)
-     about every ~2 months. The details of this release cadence are still being
-     worked out, but they will be signaled by Googlebot changing its
-     `AMP-Cache-Transform` header from `google;v=N` to `google;v=N..{N+1}` and
-     then ~2 months later to `google;v={N+1}`. (Or perhaps Google will always
-     allow at least 2 versions; TBD.) You can use [various
-     tools](https://stackoverflow.com/questions/9845655/how-do-i-get-notifications-for-commits-to-a-repository)
-     to subscribe to `releases`.
+     about every ~2 months. The [wg-caching](https://github.com/ampproject/wg-caching)
+     team will release a new version approximately this often. Soon after each
+     release, Googlebot will increment the version it requests with
+     `AMP-Cache-Transform`. Googlebot will only allow the latest 2-3 versions
+     (details are still TBD), so an update is necessary but not immediately.
+
+     To keep subscribed to releases, you can select "Releases only" from the
+     "Watch" dropdown in GitHub, or use [various tools](https://stackoverflow.com/questions/9845655/how-do-i-get-notifications-for-commits-to-a-repository)
+     to subscribe to the `releases` branch.
 
 You may also want to:
 
   1. Launch `amppkg` as a restricted user.
   2. Save its stdout to a rotated log somewhere.
-  3. Use the [provided tools](https://www.ampproject.org/docs/fundamentals/validate)
+  3. Use the [provided tools](https://amp.dev/documentation/guides-and-tutorials/learn/validation-workflow/validate_amp/)
      to verify that your published AMP documents are valid, for instance just
      before publication, or with a regular audit of a sample of documents. The
      [transforms](transformer/) are designed to work on valid AMP pages, and
@@ -208,6 +216,13 @@ This tool only packages AMP documents. To sign non-AMP documents, look at the
 commandline tools on which this was based, at
 https://github.com/WICG/webpackage/tree/master/go/signedexchange.
 
+`<amp-install-serviceworker>` will fail inside of a signed exchange, due to a
+[Chrome limitation](https://bugs.chromium.org/p/chromium/issues/detail?id=939237). The
+recommendation is to ignore the console error, for now. This is because
+amp-install-serviceworker will still succeed in the unsigned AMP viewer case,
+and crawlers may reuse the contents of the signed exchange when displaying an
+AMP viewer to browser versions that don't support SXG.
+
 ## Local Transformer
 
 The local transformer is a library within the AMP Packager that transforms AMP