W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2009

Re: 304 reponse with unrecognised ETag

From: Henrik Nordstrom <henrik@henriknordstrom.net>
Date: Thu, 25 Jun 2009 00:32:09 +0200
To: Adrien de Croy <adrien@qbik.com>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <1245882729.9223.95.camel@localhost.localdomain>
fre 2009-06-19 klockan 22:38 +1200 skrev Adrien de Croy:
> Apart from the known IIS bug with Content-Length: 0, how is an 
> intermediary cache to deal with this?

P4 3.1 304 Not Modified

"If a 304 response indicates an entity not currently cached, then the
cache MUST disregard the response and repeat the request without the

However, it's my understanding that if the conditional wasn't added by
the cache then it may just as well invalidate the cached response(s) and
relay received 304 response without repeating the request.

> Is it allowable to change an ETag on a stored representation?

Never ever.

> The 304 is pretty clear, whatever the client asked for hasn't changed.  
> But what if there were more than one ETag in the request?  Which stored 
> representation would one update?  the latest?

None. See above.

> Does this mean it's generally a really bad idea to have more than 1 Etag 
> in a If-None-Match header, or at least more than 1 added by an 
> intermediary cache?

No. Most servers do get this correct.

> IOW is it a really bad idea for an intermediary to 
> try and use If-None-Match to see which stored representation is the one 
> that's still valid?

No. It's required that the intermediary do this.

On a side note I should mention that I know that at least one of the
major servers in use today is broken in this regard and only expects a
single etag in If-None-Match, processing If-None-Match as a string
literal instead of list, but this only gives a soft degradation in that
the conditional then never matches and is not considered harmful.

Received on Wednesday, 24 June 2009 22:32:52 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 2 February 2023 18:43:19 UTC