- From: Mike Bishop <Michael.Bishop@microsoft.com>
- Date: Thu, 11 Aug 2016 21:44:38 +0000
- To: HTTP Working Group <ietf-http-wg@w3.org>
- Message-ID: <BY1PR03MB1338D4919BC6CB061EF86C5E871E0@BY1PR03MB1338.namprd03.prod.outlook.com>
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?
Received on Thursday, 11 August 2016 21:45:10 UTC