1. 25
  1.  

  2. 4

    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.

    1. 1

      Today I learned, thank you :)

      1. 1

        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.