Self host entire specific runtime

[MadisonMiner]

Description

We use AMP across many projects.

Testing everything with the weekly release, or even monthly with LTS, is challenging.

When using AMP in PWA, we self host the AMP runtime, to ensure a more reliable and stable environment.

However, even when we self host the runtime and set <meta name="runtime-host">, some files (like ww.js) are always served from the AMP cache.

We would like to ensure that all files are self hosted when we self-host shadow-v0. (We understand why amp-geo would be an exception.)

Reproduction Steps

Even though we are self hosting, the self hosted shadow-v0 fetches this file from the AMP cache:
https://cdn.ampproject.org/rtv/012012232217000/ww.js

Tonight the 012012232217000 version of AMP (about 6 months old) started redirecting to: https://cdn.ampproject.org/lts/v0/amp-geo-0.1.js

Since the above link now redirects to amp-Geo, our site went down.

Relevant Logs

No response

Browser(s) Affected

Chrome, Firefox, Safari, Edge, UC Browser

OS(s) Affected

All

Device(s) Affected

All

AMP Version Affected

012012232217000

[micajuine-ho]

/cc @ampproject/wg-infra Is this something we offer/can offer?

[rsimha]

@MadisonMiner I suspect this is due to AMP's 6 month retention policy for runtime versions. Any hard links to releases older than that are redirected to the current LTS version. You can find more details at the I2I at #25468, and the design review summary at #27071 (comment). Would it be possible for you to try a newer version of AMP and see if the behavior changes?

Meanwhile, you've raised two interesting questions:

1. Why did the link to the deleted version of ww.js redirect to LTS amp-geo.js?
2. Why did shadow-v0.js fetch ww.js from the CDN?

Let me check with the team and get back to you on these two.

/cc @danielrozenberg

[honeybadgerdontcare]

@sebastianbenz regarding self hosting.

[MadisonMiner]

@rsimha, we did upgrade to a new version last night. That did correct the issue. Thank you for checking on questions 1 and 2.

[rsimha]

That's excellent to hear, @MadisonMiner. Thanks for letting us know, and sorry about the additional trouble.

Meanwhile, I do have an update on the questions raised by this bug.

1. We've identified the cause of the incorrect ww.js redirect to amp-geo.js. It's due to how our serving redirections for deprecated AMP /rtv/ requests worked, and a fix has already been checked in. It will be a few days before it makes its way to production (expected in the second half of next week). Special thanks to @danielrozenberg for driving this.
2. We're still trying to understand why shadow-v0.js is fetching ww.js from the CDN. There is a tracking issue at Self-hosted AMP using CDN version of ww.js #34971 where you can find more updates. Thanks to @samouri for investigating this.

[kristoferbaxter]

It looks like #34971 covers the remaining work on this item. Closing this issue.

@rsimha – Should we add some additional guidance regarding the 6 month timeline for allowed access to releases from the Google CDN?

If you'd like to re-open for a relevant question, please ping here.

Edit: Additional question.

[MadisonMiner]

@rsimha, can you share any more information regarding fixing ww.js redirecting to amp-geo.js? A link to reference would be helpful.

Thank you!

[kristoferbaxter]

@MadisonMiner The redirect issue was an internal Google issue impacting requests for versions >6 months old.

@danielrozenberg might be able to answer additional questions.