Re: If-None-Match + Range

On 16/01/2012 7:58 p.m., Zhong Yu wrote:
> On Sun, Jan 15, 2012 at 11:21 AM, Julian Reschke 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)

Meaning 206 or 304 or any 4xx or any 5xx may 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.

But ... it *is* defined as having If-None-Match condition tested then 
the Range checked. 200 or 206 or 304 or 4xx or 5xx are all valid 
responses the server gets to choose from.

On first reading your post I get the impression maybe you think Range as 
being always unsatisfiable with If-None-Match indicating false (object 
has not changed). This is not correct. The If-None-Match is there to 
make available the small 304 response instead of a 4xx error or 206 with 
data wasting work if the object has not changed at all.

It is perfectly reasonable for some client application to grab a preview 
snippet of the first X bytes of an object only if it has changed from 
some previous copy seen.

For example, an AV scanner polling over a download site for infections 
in exectuable binaries headers (small fixed size of bytes in the 
infectable header area) can use If-None-Match and Range to get a 
scannable preview without having to download the whole object when it 
changes. With a supportive server it only gets a small 206 and partial 
body for scanning if the object has changed (with MB binaries the speed 
difference from 200 status can be impressive). 304 (unchanged, skip) or 
206 (new content, scan) or 412 (range is invalid, object gone?) are all 
reasonable replies from the server.

It is an unlikely case that clients would emit such a combo normally but 
not impossible.

Your final statement "If the server decides that such a bad request is 
not worth honoring, which error code should be returned to client?" 
assumes that the server is going to produce a 4xx message. Which 
indicates you/server have already decided the 304 is not suitable 
response for some reason. Which in turn means the Part 4, section 3.2 
has been chosen and the Part 5, section 5.4.2 texts about 304 are not 
relevant.

>
> (400 is apparently a legit response according to the new draft)

It would be valid yes. But more specific errors (ie 416) are preferred 
over the generic 400. To give the client a strong hint where the problem is.

It is unclear whithout knowing a lot more about the application context 
and expectations whether 416 or 412 or some other error status is _best_.

AYJ

Received on Monday, 16 January 2012 13:26:18 UTC