Re: 304 on Non-Conditional Request?

if the request was non-conditional, that would also happen if you didn't 
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 several 
high-profile servers that frequently do this)
5. Exasperated proxy forwards 304 to the client, which then has to 
retry, hopefully the proxy removed the invalidated (by ETag) cache entry 
in the meantime so it works the second time.

Adrien


------ Original Message ------
From: "Mark Nottingham" <mnot@mnot.net>
To: "Mike Bishop" <Michael.Bishop@microsoft.com>
Cc: "HTTP Working Group" <ietf-http-wg@w3.org>
Sent: 12/08/2016 12:50:03 PM
Subject: Re: 304 on Non-Conditional Request?

>If you squint at it just right, you can see a 304 as a redirect to what 
>you already have at hand -- in the common case, what you have in cache, 
>expressed by the conditional.
>
>If there were some other way of expressing what you have at hand, a 304 
>might be the status code to return in that situation too. It would 
>require some work, though.
>
>Cheers,
>
>
>>  On 12 Aug 2016, at 7:44 AM, Mike Bishop 
>><Michael.Bishop@microsoft.com> wrote:
>>
>>  Going back over my HTTP Workshop notes around push and cache 
>>revalidation, I see a comment that a 304 response to a non-conditional 
>>GET is supposed to be valid, if somewhat ambiguous.  I’m trying to 
>>parse what that would mean, and I’m drawing a blank.
>>
>>  RFC 7232 defines 304 (Not Modified) this way:
>>     The 304 (Not Modified) status code indicates that a conditional 
>>GET
>>     or HEAD request has been received and would have resulted in a 200
>>     (OK) response if it were not for the fact that the condition
>>     evaluated to false.  In other words, there is no need for the 
>>server
>>     to transfer a representation of the target resource because the
>>     request indicates that the client, which made the request
>>     conditional, already has a valid representation; the server is
>>     therefore redirecting the client to make use of that stored
>>     representation as if it were the payload of a 200 (OK) response.
>>
>>  I therefore can’t envision the scenario in which you would use this 
>>for a non-conditional GET.  I could vaguely see the reason phrase “Not 
>>Modified” as applying to e.g. a PATCH or PUT that doesn’t actually 
>>result in a change to the resource, but that still seems more like a 
>>2XX series response, perhaps 202 (Accepted).  But that’s not GET.
>>
>>  Is there a scenario I’m missing, were my notes incorrect, or did I 
>>accurately transcribe the comment of someone who was incorrect?
>
>--
>Mark Nottingham   https://www.mnot.net/
>
>

Received on Friday, 12 August 2016 01:32:38 UTC