search

ampproject / amphtml

The AMP web component framework.
https://amp.dev
Apache License 2.0
14.89k stars 3.89k forks source link

AMP Page `<style amp-custom>` removed after being in the Google Cache for a while #29656

Closed seanthepottingshed closed 3 years ago

seanthepottingshed commented 4 years ago

Sorry for raising issue here but I'm getting no response in Stack Overflow:

caroqliu commented 3 years ago

@seanthepottingshed I'm seeing "Page not found" when clicking on the link, can you share more information about the issue?

seanthepottingshed commented 3 years ago

Yeah sorry it was so long ago the page no longer exists. I will add another test page shortly and post here when I've done ;)

seanthepottingshed commented 3 years ago

@caroqliu

Here is another AMP page:

I share the non-AMP version of the page on LinkedIn:

And visit the post via LinkedIn iOS app which redirects to the AMP version, all the styling has been removed from the page in the AMP cache:

This was pointed out by the client and I was unable to figure out why so I'm incredibly grateful for your earlier response. Any help you can provide would be very much appreciated!

caroqliu commented 3 years ago

Hmm. Could someone from @ampproject/wg-caching take a look?

Gregable commented 3 years ago

@seanthepottingshed it looks like your webserver returns a page without that style tag sometimes. The cache isn't removing it, it arrives at the cache without the style tag.

For some reason, this is inconsistent and possibly varies by URL, but you'd have to debug on your side.

For example, at the moment, this URL works fine:

https://agilisys-gg.cdn.ampproject.org/c/s/agilisys.gg/news/amp/taoism-darwinism-everything-i-know-about-adapting-change?r=1

All I did was append the random URL param ?r=1 which isn't a special string - it just changes the URL that the cache is requesting from your server slightly. Pick any such url param and try it yourself.

This works fine, and the cache isn't running different code for different URLs like that. I can also see in the response logs that the uncompressed response lengths from your server for the ?r=1 one are 31kb while for the one you linked to I see 27kb.

seanthepottingshed commented 3 years ago

Thanks @Gregable! Strange that the server should be removing the style tag, I'm kind of out of my comfort zone here - would you be able to recommend any tools I could use on the server to log what is sent when the AMP page is requested by the cache?

The site is built using OctoberCMS / Laravel ( PHP 7.2 ) installed using Laravel Forge on a Digital Ocean Droplet if that information is of any use.

Gregable commented 3 years ago

@seanthepottingshed From my end, your serving stack is a black box, so it's very hard to guess what's going on in the same way the cache is somewhat of a black box from your end.

Usually with this kind of thing, the server varies by the useragent or some other request header. The fact that changing the URL param "fixes" the issue suggests that's probably not the case here. The AMP cache requests for both URLs would have been identical save for the URL itself and the passage of time.

My guess is that the server is doing different things at different times, rather than varying by the URL. These responses might even be cached, perhaps by Cloudflare which I see in the response header. Sorry that I can't offer much more than those (possibly red herring) observations.

seanthepottingshed commented 3 years ago

LEGEND, that's really helpful. The client has their own CloudFlare account so I think this may be the cause. Will investigate further.

seanthepottingshed commented 3 years ago

@Gregable

There's a setting in CloudFlare called Brotli Compression which I've disabled would that have any bearing on the issues I'm experiencing?

Do you think it would be worth disabling CloudFlare completely and seeing if the issue still persists?

honeybadgerdontcare commented 3 years ago

@seanthepottingshed that may be a question best asked of CloudFlare through their support channels. Compression such as brotli should not change the content (e.g. removing a tag).

seanthepottingshed commented 3 years ago

@honeybadgerdontcare - excellent idea, I will contact them and see what they say

seanthepottingshed commented 3 years ago

@Gregable and @honeybadgerdontcare

Sorry to trouble you further - I've completely disabled CloudFlare with the exception of their DNS settings, and it's still doing the same thing, any further ideas ( I've emailed CloudFlare support ):