This is really good. Thank you for explaining wth weak etags are.
Could do with an explanation of when the UA will use weak or string comparison for etags. Wikipedia claims it’s weak when you want to refresh something you already downloaded, strong when you want to resume a download with a range request (for which you need to be certain that you’re going to be downloading the next part of a byte-for-byte identical file to the one you started downloading earlier).
Teasing the title, requests that aren’t made at all are even faster 😉. I’ve seen sites get visibly faster from setting cache-control public max-age=… on a few dozen static resources.
How well do these work across browsers? I thought at least Safari disabled a load of these because they can be used for tracking. In the simplest case, if I use a tracking ID as the etag, I can use that as a beacon: the browser will say ‘Hey server, I have a thing with {tracking ID}, is it the latest?’ and the server says ‘Yup. Muahahahaha, now I have tracked this user’. It’s probably a bit harder with the other things, but I can imagine that if the last-modified time is a full ISO 8601 format and I don’t update resources more than once per minute then I can use the seconds + milliseconds to give me 60,000 unique tokens that I can use for tracking IDs.
They’re part of the HTTP spec, so all browsers (probably) implement them. Not sure if Safari disables these headers but you’re correct when saying that they can be used to track users. It is a well documented tracking vector.
I can imagine that if the last-modified time is a full ISO 8601 format and I don’t update resources more than on…
It’s actually simpler. ETags are opaque for the clients, so one can, in theory, put a fingerprint in the ETag and track that user agent across its session. In fact, KissMetrics got sued for it back in 2012.
This is really good. Thank you for explaining wth weak etags are.
Could do with an explanation of when the UA will use weak or string comparison for etags. Wikipedia claims it’s weak when you want to refresh something you already downloaded, strong when you want to resume a download with a range request (for which you need to be certain that you’re going to be downloading the next part of a byte-for-byte identical file to the one you started downloading earlier).
Teasing the title, requests that aren’t made at all are even faster 😉. I’ve seen sites get visibly faster from setting cache-control public max-age=… on a few dozen static resources.
Thank you!
Wikipedia is (as usual) right. Weak ETags are useful for refreshes, while strong ETags are useful for downloads using Range.
I am keen to write more on the topic 👆 if that’s something you’d be interested in reading?
Today I learned, thank you :)
Maybe a bit late to reply, but thanks – I am glad you found the article worth reading!
How well do these work across browsers? I thought at least Safari disabled a load of these because they can be used for tracking. In the simplest case, if I use a tracking ID as the etag, I can use that as a beacon: the browser will say ‘Hey server, I have a thing with {tracking ID}, is it the latest?’ and the server says ‘Yup. Muahahahaha, now I have tracked this user’. It’s probably a bit harder with the other things, but I can imagine that if the last-modified time is a full ISO 8601 format and I don’t update resources more than once per minute then I can use the seconds + milliseconds to give me 60,000 unique tokens that I can use for tracking IDs.
They’re part of the HTTP spec, so all browsers (probably) implement them. Not sure if Safari disables these headers but you’re correct when saying that they can be used to track users. It is a well documented tracking vector.
It’s actually simpler. ETags are opaque for the clients, so one can, in theory, put a fingerprint in the ETag and track that user agent across its session. In fact, KissMetrics got sued for it back in 2012.