Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add link to amp.dev docs for Signed Exchanges in AMP Packager Readme. #332

Merged
merged 3 commits into from
Aug 5, 2019
Merged
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
8 changes: 4 additions & 4 deletions README.md
Original file line number Diff line number Diff line change
@@ -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).
AMP Packager is a tool to [Serve AMP using Signed Exchanges](https://amp.dev/documentation/guides-and-tutorials/optimize-and-measure/signed-exchange/) which in turn [improves AMP
URLs](https://amp.dev/documentation/guides-and-tutorials/optimize-and-measure/signed-exchange/).
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like leading with the purpose, the intended effect of fixing AMP URLs, and following with the means (signed exchanges). I'd also lean towards not having two links to the same URL in the same sentence; the user will probably click both not realizing they're the same (or at least hover, costing time). So, e.g.

AMP Packager is a tool to [improve AMP URLs](https://amp.dev/documentation/guides-and-tutorials/optimize-and-measure/signed-exchange/)
by serving AMP using signed exchanges.

FWIW the second para goes into detail on signed exchanges, so the mention might not be necessary in the first para, but I'm okay with it either way.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oops. I meant to change the 2nd link to the correct blog post, rather than have them both be the same. If you'd prefer, I can just remove it.

By running it in a proper configuration, web publishers may (eventually) have
origin URLs 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,
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
Expand Down Expand Up @@ -139,7 +139,7 @@ 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
Expand Down