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

From: Julian Reschke <[email-masked]>
Date: Fri, 06 Jul 2012 11:52:04 +0200

(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?

Best regards, Julian

---

From: Yves Lafon <[email-masked]>
Date: Wed, 11 Jul 2012 08:52:56 -0400 (EDT)

On Fri, 6 Jul 2012, Julian Reschke wrote:

>> 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.
>

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