Re: 304 on Non-Conditional Request?

Actually there's a hole in the spec maybe.

if you get a 304 response to a request that had more than 1 Etag, and 
the Etag in the response doesn't match any of the Etags from the 
request, then there's no way to choose which representation is being 
indicated by the 304.

Is this just a broken server?  We see 304s come back all the time with 
new Etags, and I'm pretty sure I've seen comments about just treating it 
as metadata and updating the stored Etag, but fundamentally

if 304 means no change, and
different Etag means it changed,

then which is it?  And this only "works" if there's only 1 Etag.


------ Original Message ------
From: "Willy Tarreau" <>
To: "Adrien de Croy" <>
Cc: "Mark Nottingham" <>; "Mike Bishop" 
<>; "HTTP Working Group" 
Sent: 15/08/2016 8:23:08 PM
Subject: Re: 304 on Non-Conditional Request?

>Hi Adrien,
>On Fri, Aug 12, 2016 at 01:32:03AM +0000, Adrien de Croy wrote:
>>  if the request was non-conditional, that would also happen if you 
>>  have any version already.  Client basically needs to retry.
>>  FWIW we see this happen quite a bit with proxies encountering broken
>>  servers.
>>  E.g.
>>  1. client makes non-conditional request to proxy.
>>  2. Proxy has a stale version
>>  3. Proxy adds If-None-Match and stored ETag
>>  4. Server responds with 304 with different ETag (yes, there are 
>>  high-profile servers that frequently do this)
>>  5. Exasperated proxy forwards 304 to the client, which then has to 
>>  hopefully the proxy removed the invalidated (by ETag) cache entry in 
>>  meantime so it works the second time.
>A long time ago (~15 years) I've been experiencing a different case 
>a caching proxy would ignore the if-none-match field, pass the request 
>the server, which responds 304, which is forwarded to the client and 
>by the proxy. The next client requesting the same object to the proxy 
>be delivered the 304 from the cache.

Received on Tuesday, 16 August 2016 02:03:52 UTC