AMP Packager -Production Implementation

[sidnuc]

I am trying to understand/implement AMP packager concept in our application into Production Environment and quite confused what exactly mention into below Github URL.
https://github.com/ampproject/amppackager
Below are a few Queries, please clarify

1. What mean url start with /amppkg/ ? Are we need to change our URL domain pointing?
2. What the significance of /priv/doc?
3. Transport Layer Security(TLS) we explicitly need to point amppkg proxy for AMP pages, This configuration does not hamper our secure communication between servers and web browser? As We have a lot of NON-AMP HTML pages in our application?
4. Any reference project(production) which already implement AMP Packager and integrate
   AMP+NON AMP HTML web project?

[anirudhkhanna]

I would love to give my take on these points since Signed Exchange (SXG) is such a revolution in AMP as well as the Web itself. (I welcome corrections if I am wrong somewhere, since amppackager implementation is still very new and volatile.)

1. /amppkg/ urls would be the ones on which amppackager serves content other that your actual SXGs, like certificates.

2. /priv/doc/<yourAmpUrl> is just the path which will serve the SXG for yourAmpUrl. That is just how amppackager is configured to work.

3. It is recommended to selectively proxy only the AMP URLs to amppackager. That too, only if request headers demand SXGs.

4. ampbyexample is a nice goto reference for starters.
   Also, oyorooms.com is doing it. You should be able to see it in action on the Google Search's webpackage demo page in search results.

[cathyxz]

@Gregable would you or anyone in @ampproject/wg-caching by chance know the right people to answer this question or point these folks to the right documentation / examples?

[Gregable]

I think @anirudhkhanna's answers are all correct. Let me know if you hare any additional questions. Also @ampproject/wg-caching

[twifkak]

Yes, @anirudhkhanna's look accurate to me, but just to add a few clarifying examples:

Essentially you'll want your reverse proxy (e.g. Apache or nginx) to forward some URLs to your backend, e.g.:

If client requests https://yourwebsite.example/amppkg/cert/123, then you'll want to proxy the request to http://localhost:8888/amppkg/cert/123. (Where localhost:8888 is an example internal location of where you're running amppkg.)

If client requests https://yourwebsite.example/some/AMP/page.html AND sends AMP-Cache-Transform request header, then proxy to http://localhost:8888/priv/doc/https://yourwebsite.example/some/amp/page.html. You'll need to know which URLs are AMP pages.

If client requests https://yourwebsite.example/some/AMP/page.html and DOES NOT send the AMP-Cache-Transform request header, then handle your usual way; don't proxy to amppkg. This is a user, so they should get normal AMPHTML.

If client requests https://yourwebsite.example/some/NON-AMP/page.html, then handle your usual way; don't ever proxy to amppkg.

If a client requests https://yourwebsite.example/priv/doc/..., then DON'T proxy to amppkg. You should only form these /priv/doc URLs internally.

Can you help me understand what you mean in #3? Under normal circumstances, your amppkg server should not talk directly to browsers. It should only respond to AMP Cache requests (via your proxy), and AMP Cache is responsible for serving it to browsers. It is important that both your proxy and AMP Cache serve over HTTPS, for security reasons.

[twifkak]

@sidnuc feel free to reopen if your question wasn't answered.