ETag header about ga-beacon

[igrigorik]

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.

[igrigorik]

👍

Any chance you'd be up for putting together a PR? :)

[ArtemGr]

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.

[igrigorik]

Resolved via #54.