Re: If-* vs Range (part of #366)

On Fri, 6 Jul 2012, Julian Reschke wrote:

> (see also http://trac.tools.ietf.org/wg/httpbis/trac/ticket/366)
>
> In 
> <http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p4-conditional-19.html#rfc.section.3.3> 
> we have:
>
>> Note: The Range header field modifies the meaning of If-Modified-Since; see 
>> Section 5.4 of [Part5] for full details.
>
> It has been like that since the days of RFC 2068.
>
> <http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p5-range-19.html#rfc.section.5.4.2> 
> says:
>
>> If the server supports the Range header field and the specified range or 
>> ranges are appropriate for the representation:
>>
>>     The presence of a Range header field in an unconditional GET modifies 
>> what is returned if the GET is otherwise successful. In other words, the 
>> response carries a status code of 206 (Partial Content) instead of 200 
>> (OK).
>>     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.
>
> So why do we have this note only for If-Modified-Since?

Indeed, the note should appear for either all the other similar headers, 
or better, none of them (it's not up to IMS, INM to define what optional 
parts or yet-to-be-defined extensions are doing).

-- 
Baroula que barouleras, au tiéu toujou t'entourneras.

         ~~Yves

Received on Wednesday, 11 July 2012 12:53:02 UTC