Closed ArtemGr closed 7 years ago
👍
Any chance you'd be up for putting together a PR? :)
Any chance you'd be up for putting together a PR? :)
So far it's just an idea, one would have to experiment on it to see if it changes anything. For example, the beacon might change ETag
periodically, by feeding the current second (or unix_time_seconds() / X
) into ETag
. It would be interesting to see if that'll do anything to the beacon-generated AdSense stats.
On one hand, ETag
shouldn't do anything in presence of Cache-Control: no-cache
. On the other hand, we have statements from GitHub programmers (?) that ETag
is needed in order not to screw things up. It's weird, but maybe it's real. Maybe the lack of ETag
is screwing no-cache
because of some non-standard caching.
Another thing to try would be Cache-Control: must-revalidate
with a changing ETag
, instead of just Cache-Control: no-cache
. It might use a different code path in github/fastly and so improve the amount of requests that goes directly to the beacon instead of being cached.
That said, I don't have the infrastructure (Go compiler, a working app-engine instance of the beacon) to work on it properly. Dubbing in that would be supper inefficient. Like nine times to one, where nine is the time to figure out the environment and one is the time to work on the problem.
FWIW, for the purpose of our use case.. we don't want the response to ever be served from cache. As such, using no-cache and unique ETag on each request is both simplest and easiest.
Resolved via https://github.com/igrigorik/ga-beacon/pull/54.
To be on the safe side of GitHub image caching I think it's better to add the "ETag" header (or "Expires").
See https://github.com/github/markup/issues/224#issuecomment-33454537 and https://github.com/github/markup/issues/224#issuecomment-37663375 and https://github.com/github/markup/issues/224#issuecomment-48532178.