project jira-projects / Anti-AMP scripts avatar

jira-projects/FKAMP#2: Report of script not working

Issue Information

Issue Type: issue
Status: closed
Reported By: btasker
Assigned To: btasker

Milestone: v1.6
Created: 23-Apr-22 08:02


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.

Toggle State Changes


assigned to @btasker

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)

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 origin
  • t2: Fetch from CDN, MISS edge, MISS perma-cache
  • t3: Fetch from CDN, MISS edge, hit perma-cache
  • t4: Fetch from CDN, HIT edge
  • t5: Fetch from

Response bodies are all the same

ben@optimus:~$ sha1sum t*
34147d73795d7e5b75ef0e7d562078e5587ab28b  t1
34147d73795d7e5b75ef0e7d562078e5587ab28b  t2
34147d73795d7e5b75ef0e7d562078e5587ab28b  t3
34147d73795d7e5b75ef0e7d562078e5587ab28b  t4
34147d73795d7e5b75ef0e7d562078e5587ab28b  t5

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

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.

As of the script now checks for amp-ver in HTML attributes


mentioned in commit github-mirror/RemoveAMP@230443fb767325260b59da3fbd0042a230597247

Commit: github-mirror/RemoveAMP@230443fb767325260b59da3fbd0042a230597247 
Author: B Tasker                            
Date: 2022-04-23T09:32:05.000+01:00 


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

+1 -1 (2 lines changed)