Re: 304 on Non-Conditional Request?

[Mark Nottingham <[e-mail]>]

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 <[e-mail]> 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/