W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2012

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

From: Yves Lafon <ylafon@w3.org>
Date: Wed, 11 Jul 2012 08:52:56 -0400 (EDT)
To: Julian Reschke <julian.reschke@gmx.de>
cc: HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <alpine.DEB.1.10.1207110832420.14753@wnl.j3.bet>
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.

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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:02 UTC