Re: If-None-Match + Range

On 16.01.2012 06:21, 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)
>>
>> 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?
>
> (I think this is the same issue as
> <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/241>)
>
> Best regards, Julian



There is another ambiguity with the If-Match texts:
" If the request would, without the If-Match header field, result in
    anything other than a 2xx or 412 status code, then the If-Match
    header field MUST be ignored.
"

So the example of two resources A (200 bytes) and B (100 bytes). The 
request:

   If-Match: "B"
   If-None-Match: "A"
   If-Range: 1-150/200

If-Range could potentially return true from the "A" resource. Leading to 
ambiguity whether the If-Match MUST be ignored (resulting in 304) or not 
(resulting in 206).


I think the If-Match text should be brought inline with the other 
definitions which say "anything other than a 2xx or 304 status code". 
That way we can use AND logics consistently between them. Or have I 
missed  discussion about why If-Match MUST be OR'd against the other 
conditionals?



Taking another stab at #421 would it not be be clearer to re-write the 
section 3 intro along the lines of:
"
  Conditional headers defined by this specification are []. When 
combined they form a boolean AND condition on the request success or 
failure.

  If any one of the conditionals contains invalid syntax, or directly 
contradicts another conditional then the appropriate 4xx should be 
returned.

  If all of the conditionals produce true then a 2xx status with 
appropriate entity should be returned.

  If one or more of the conditionals produces false then the whole 
conditional is false and a 304 should be returned.
"

That way all the confusing text about when one condition or another 
"MUST be ignored" can be dropped. Since none of them are ignored pre-se, 
but they may not need checking if another conditional already produced 
false.

Then a list of the conditionals with specific descriptions including:
  * what is tested by each and how to compare for true/false result
  * whether 304 or something else constitutes a 'false' response. It 
seems very weird to be getting 304 out when seeking to fetch a Range: 
with only If-Match: presented.
  * other considerations?



Just my 2c to get things rolling.

AYJ

Received on Monday, 16 January 2012 06:07:36 UTC