Talk:HTTP ETag

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

Server and Browser Usage[edit]

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. Jon (talk) 21:31, 18 June 2012 (UTC)[reply]

Cookies[edit]

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

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)[reply]


Not accurate[edit]

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)[reply]

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)[reply]
I wish checksums were even mandated. As of now, ETag and Last-Modified will encourage browsers to preserve a corrupt download. Hopefully, every download failure results in deleting the cached copy. --ilgiz (talk) 11:35, 28 February 2019 (UTC)[reply]
I wish they were too, but checksums would be difficult to validate for a weak ETag. Nevertheless, at least for strong ETags they would be useful. This of course implies that the checksum, e.g. sha3_224, and its encoding, e.g. hex, follow an agreed-upon standard. Such an ETag should probably have as its prefix the hash type. The content-coding, if present, would also have to be handled. An example of such an ETag would be sha3_224:93e6e458dd69a3102d8b85fa6fe964baf51ade8c96fff862e50b402e-a --Acyclic (talk) 04:55, 28 May 2019 (UTC)[reply]

(Weak) ETags and Last-Modified[edit]

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)[reply]

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)[reply]
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)[reply]
**** 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)

≤== External links modified ==

Hello fellow Wikipedians,

I have just modified one external link on HTTP ETag. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 18 January 2022).

  • If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
  • If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 15:12, 27 October 2017 (UTC)[reply]

The original link led to a live demo of ETag cookies, which presumably had a server-side app running that would set persistent ETag-based cookies. Since web.archive.org of course can't archive the server-side code, the archived page just shows a spinner continuously. I'm not sure this can be considered a bug with the bot -- it's not clear how it would know that the page had server-side functionality.
110.147.164.125 (talk) 11:44, 7 December 2017 (UTC)[reply]

Opt-out[edit]

Disable all fake settings i was hacked on my imei — Preceding unsigned comment added by 152.36.151.33 (talk) 09:29, 20 April 2022 (UTC)[reply]

Retrieved from "https://en.wikipedia.org/w/index.php?title=Talk:HTTP_ETag&oldid=1202136524"