Talk:HTTP ETag

Server and Browser Usage

There is little information here. It's fine to document the ETag spec, but if that's all that's going to be covered we might as well be linked off to W3C. I want to know how, or for that matter if or which, web browsers are actually taking advantage of ETag. We have had to use randomized querystrings in the past as cache-busters during debugging, but if web browsers are able to rely on ETag then I'd like to know which ones. Also, I'd like to know whether Apache and IIS natively implement ETag, and if it's specific to the programming technology then I'd like to know which version of PHP started to support, which version of ASP.NET, and so on. As a bonus I'd like to know how to manage ETags while working with ASP.NET.

Scott Guthrie was recently responding to comments in his ASP.NET MVC 4 / ASP.NET 4.5 blog about how the new scripts / CSS bundler is relying on ETag for cache busting. I was quite surprised to read this since I thought that browsers mostly just ignored ETag. Stimpy77

Cookies

Need to know how to allow cookies on my computer. They are needed for me to access other sites — Preceding unsigned comment added by 92.2.175.81 (talk) 13:46, 14 February 2009 (UTC)

It would have been better to ask this kind of question at the Computing Ref Desk. However, changing the cookies setting is easy: In Internet Explorer, go to Tools -> Options... and choose the Privacy tab. Other browsers have similar facilities. Astronaut (talk) 14:15, 14 February 2009 (UTC)

Not accurate

The article says that a checksum may be used. However, this of course may result in "clashes". —Preceding unsigned comment added by 130.161.37.198 (talk) 16:37, 19 April 2010 (UTC)

I rewrote much of this article and I hope it is both clearer and more accurate now. - Dmeranda (talk) 15:42, 20 May 2010 (UTC)

(Weak) ETags and Last-Modified

As far as I understand the specs, the ETag, which was introduced in RFC 2616 (HTTP/1.1) is a predecessor of the Last-Modified-Header, which is proposet to give the software-architect more controll over the cache-revalidating process.

If both Cache-Validation-Headers (If-None-Match and If-Modified-Since) are present, according to RFC 2616, the client (i.e. the browser) should use the ETag when checking, if a resource has changed. According to section 14.26 of RFC 2616, the server MUST NOT respond with a 304 Not Modified, if the ETag presented in a If-None-Match-Header has changed, and the server has to ignore an additional If-Modified-Since-Header, if present. If the presented ETag matches, he MUST NOT perform the request, unless the Date in the Last-Modified-Header says so. (If the presented ETag matches, the server should respond with a 304 Not Modified in case of a GET- or HEAD-request...)

This section leaves room for some speculations:

• A strong ETag is supposed to change everytime, the resource changes. So, having to responde with something else as 304 Not Modified to a request with an unchanged ETag and an If-Modified-Since-Header, which dose not match is a bit of a contradiction, because the strong ETag says, that the resource was not modified. (Though, this is not that fatal, because the server can send the same unchanged resource again.)
• ...

... o.k. While I was writing this, the question was boiling down to this answer:

The (small) contradiction stated above, was made because of Weak ETags. A resource marked with a Weak ETag may have changed, although the ETag has not. So, in case of a Weak ETag it would be wrong, to answer with 304 Not Modified, when the ETag has not changed, but the date presented in the If-Modified-Since does not match, right?

Kai.moritz (talk) 08:44, 15 June 2010 (UTC)

The last modified date as represented in the Last-Modified header is a so-called entity header (see HTTP 1.1 section 7.1). Thus, just like other entity headers like Content-Language, if the date changes then a strong ETag MUST also change. However a weak ETag may stay the same (or change). In general, for strong ETags both the content of the resource/file as well as the value of all entity headers must remain unchanged. So you should never see the case where you have the same strong ETag yet a different last-modified timestamp. -- Dmeranda (talk) 19:04, 16 June 2010 (UTC)

You stated: "...in case of a Weak ETag it would be wrong, to answer with 304 Not Modified, when the ETag has not changed, but the date presented in the If-Modified-Since does not match, right?" — that is my understanding, as long as the If-[Not-]Modified-Since conditional is present. However for weak ETags, as long as the conditional is not in the request the server is permitted to return a 304 even if the entity's last-modified date did change. Generally, if a conditional request includes multiple conditions (both etags and modification date), then ALL the conditions must be satisfied before a 304 Not Modified may be returned (or for PUT/DELETE if ANY condition fails then you must return a 412 Precondition Failed). Note that this case (same etag, different date) is much more likely with weak ETags; but it is possible when using strong ETags that the If-Modified* headers from the request are different (illustrated below), so the server must still check all the conditions. -- Dmeranda (talk) 19:31, 16 June 2010 (UTC)

**** REQUEST 1
> GET /example HTTP/1.1

< HTTP/1.1 200 OK
< ETag: "VERSION-1"
< Last-Modified: Tue, 15 Jun 2010 01:00:00 GMT

           **** RESOURCE UPDATED IN THE MEAN TIME (at JUN 16, 08:22:22)****

**** REQUEST 2
> GET /example HTTP/1.1
> If-Match: "VERSION-1"

< HTTP/1.1 200 OK
< ETag: "VERSION-2"
< Last-Modified: Wed, 16 Jun 2010 08:22:22 GMT

**** REQUEST 3
> GET /example HTTP/1.1
> If-Match: "VERSION-2"
> If-Modified-Since: Wed, 16 Jun 2010 08:22:22 GMT

< HTTP/1.1 304 Not Modified

**** REQUEST 4 (UNLIKELY)
> GET /example HTTP/1.1
> If-Match: "VERSION-2"
> If-Modified-Since: Wed, 16 Jun 2010 08:59:59 GMT

< HTTP/1.1 304 Not Modified
< Last-Modified: Wed, 16 Jun 2010 08:22:22 GMT

(assuming 08:59:59 is not in the future, we can return a 304 even
though date doesn't "match" exactly, because the resource still
wasn't modified *since* that date.  Should probably return a
Last-Modified header though so caches can update their wrong date)

**** REQUEST 5 (UNLIKELY AND STRANGE, BUT POSSIBLE CASE)
> GET /example HTTP/1.1
> If-Match: "VERSION-2"
> If-Modified-Since: Tue, 15 Jun 2010 17:17:17 GMT

< HTTP/1.1 200 OK
< ETag: "VERSION-2"
< Last-Modified: Wed, 16 Jun 2010 08:22:22 GMT
...
(Have to return full response here because if-modified-date is old
even though if-match is correct)