Had a report come in last night of the anti-amp script not working.
The user seems to have concluded that it was something on their side as it started working with no changes, but I'd like to double-check a few things just to be sure.
It seems like the required script that is imported is this one, which doesn't translate the zap right, and instead shows 'âš¡', thing that doesn't happen on the same script from the repo.
This sounds like a possible content-encoding issue. Which is a expected side-effect of viewing the script directly in a browser (though it shouldn't affect subsequent execution)
Response headers all look OK too (Github incudes a content-type header specifying utf-8 which does support my original hunch).
Permacache does result in a bunch of headers from the origin not being present (because it acts as an origin itself), but none of those are anything which should have an effect here (it's more things like alt-svc)
So, I don't think there is a delivery issue here, the user's probably right in that it was something odd on their end.
However, I do like the suggestion they've made
or changing the conditional line to also check for the attribute "amp-version" to be like the following on the other script would work
That's definitely doable.
They also suggested
changing the @require tag to https://raw.githubusercontent.com/bentasker/RemoveAMP/master/anti-amp.js
I couldn't remember why I chose to serve from my CDN in the first place, but it turns out the answer is in FKAMP-1
I've had to host the JS on my CDN as I didn't really want to inject so much javascript into every page, and couldn't load direct from GitHub because they return text/plain in the Content-Type header so Chrome refuses to run it.
Activity
23-Apr-22 08:02
assigned to @btasker
23-Apr-22 08:03
This sounds like a possible content-encoding issue. Which is a expected side-effect of viewing the script directly in a browser (though it shouldn't affect subsequent execution)
23-Apr-22 08:18
I'm wondering though, if there's perhaps a difference between cache HIT and cache MISS on the CDN.
The user's GH profile says they're in Spain, and in my CDN providers logs I see some requests, from Spain, for that file at around the right time.
All are cache-hit.
I have "Perma-cache" enabled in BunnyCDN, so there are a handful of scenarios scenarios
t1
: Fetch direct from origint2
: Fetch from CDN, MISS edge, MISS perma-cachet3
: Fetch from CDN, MISS edge, hit perma-cachet4
: Fetch from CDN, HIT edget5
: Fetch from https://raw.githubusercontent.com/bentasker/RemoveAMP/master/anti-amp.jsResponse bodies are all the same
Response headers all look OK too (Github incudes a
content-type
header specifyingutf-8
which does support my original hunch).Permacache does result in a bunch of headers from the origin not being present (because it acts as an origin itself), but none of those are anything which should have an effect here (it's more things like
alt-svc
)23-Apr-22 08:29
So, I don't think there is a delivery issue here, the user's probably right in that it was something odd on their end.
However, I do like the suggestion they've made
That's definitely doable.
They also suggested
I couldn't remember why I chose to serve from my CDN in the first place, but it turns out the answer is in FKAMP-1
23-Apr-22 08:46
As of https://github.com/bentasker/RemoveAMP/releases/tag/v1.6 the script now checks for
amp-ver
in HTML attributes23-Apr-22 08:59
mentioned in commit github-mirror/RemoveAMP@230443fb767325260b59da3fbd0042a230597247
Message
Add an additional attribute check for #6 / jira-projects/FKAMP#2
This checks for the attribute "amp-version" as a reliable indicator of the page being AMPy