amphtml: Google AMP CDN using hashed publisher subdomain, breaks CORS validation
What’s the issue?
Seeing a lot of broken CORS requests in some of our content due to the publisher subdomain being one-way hashed by the Google AMP CDN.
For example, this AMP doc:
According to the encoding documented in the Google AMP cache docs (https://developers.google.com/amp/cache/overview), the expected Google AMP cache subdomain for our example should be:
But this is being redirected to this one-way hashed subdomain:
According to the docs this is done in certain cases, but for unclear reasons:
Subdomains created by the Google AMP Cache will be human-readable when character limits and technical specs allow, and will closely resemble the publisher’s own domain.
Where technical limitations prevent a human readable subdomain, a one-way hash will be used instead.
Not clear why this domain is subject to “technical limitations”. Bug?
Anyway, in this example, the Origin is now presented as 7ai3pvhopvh4fo4mm3sukbcq2wp6ubqw5ndoini2u3d6epbxubaa.cdn.ampproject.org, which does not pass our CORS header validation as specified by the AMP docs.
So how should publishers be validating these one-way hashed publisher subdomains?
About this issue
- Original URL
- State: closed
- Created 6 years ago
- Comments: 23 (16 by maintainers)
I misunderstood what’s left of this issue. Reopening and updating.
thanks, this helps! assigning to Crystal to prioritize.
@src-code I looked more into the specifics of that URL and why it’s failing. In the AMP URL format, there are 4 steps to convert the domain into an AMP subdomain, part of which involves IDN/Punycode. IDN does not accept hyphens as the third and fourth characters, presumably because only the prefix “xn–” is allowed for internationalized domains. Therefore, es–us-vida–estilo-yahoo-com ends up being rejected due to the “es–” prefix.