- From: Zhong Yu <zhong.j.yu@gmail.com>
- Date: Mon, 16 Jan 2012 00:58:58 -0600
- To: Julian Reschke <julian.reschke@gmx.de>
- Cc: ietf-http-wg@w3.org
On Sun, Jan 15, 2012 at 11:21 AM, Julian Reschke <julian.reschke@gmx.de> wrote: > On 2012-01-13 13:29, Zhong Yu wrote: >> >> Suppose a GET request contains `If-None-Match` and `Range` headers; >> the If-None-Match condition fails, the Range is unsatisfiable. Which >> code should be returned, 304 or 416? There are conflicting statements >> in the draft: >> >> Part 4, section 3.2. >> >> If the request would, without the If-None-Match header field, result >> in anything other than a 2xx or 304 status code, then the If-None- >> Match header field MUST be ignored. >> >> (that means 416 should be returned) >> >> Part 5, section 5.4.2. >> >> o The presence of a Range header field in a conditional GET (a >> request using one or both of If-Modified-Since and If-None-Match, >> or one or both of If-Unmodified-Since and If-Match) modifies what >> is returned if the GET is otherwise successful and the condition >> is true. It does not affect the 304 (Not Modified) response >> returned if the conditional is false. >> >> (that means 304 should be returned) >> >> If the server decides that such a bad request is not worth honoring, >> which error code should be returned to client? > > > I don't think we know. Does it really matter? Not really, except for a server implementation, which must yield a result for any situation, so the question is what kind of results are acceptable for this case. It's OK if the spec explicitly states that such case is undefined; but my reading is that the draft contradicts itself here. (400 is apparently a legit response according to the new draft) Zhong Yu > (I think this is the same issue as > <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/241>) > > Best regards, Julian >
Received on Monday, 16 January 2012 06:59:47 UTC