W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > May to August 1996

Re: Accept-Ranges: the controversy that wouldn't die

From: Roy T. Fielding <fielding@liege.ICS.UCI.EDU>
Date: Wed, 05 Jun 1996 23:36:07 -0700
To: Lou Montulli <montulli@mozilla.com>
Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com, Jeffrey Mogul <mogul@pa.dec.com>
Message-Id: <9606052336.aa25602@paris.ics.uci.edu>
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/815
> This is confused.  We are not interested in knowing if the OS can
> handle ranges.  What we wan't to know is if *ANY* point in the chain
> can provide range service.  Once that is known we can make major
> optimizations.

Well, that's what I thought too -- I was responding to Jeff's comments.

> BTW- Why do you keep bringing up PDF?  Ranges have nothing to do with PDF.
> They were not concieved for PDF and are hardly restricted to PDF
> usage.

Good -- that's exactly what I want to hear.

>> ------- End of Forwarded Message
>> [previous wording]
>> 14.5 Accept-Ranges
>> The Accept-Ranges response header allows the server to indicate its
>> acceptance of range requests for a resource:
>>        Accept-Ranges     = "Accept-Ranges" ":" acceptable-ranges
>>        acceptable-ranges = 1#range-unit | "none"
>> Origin servers that accept byte-range requests MAY send
>>        Accept-Ranges: bytes
>> but are not required to do so.  Clients MAY generate byte-range requests
>> without having received this header for the plain resource involved.
>> The Accept-Ranges MUST NOT be added to a response by a proxy (i.e., it
>> may only be added by the origin server), MUST NOT be forwarded by a
>> proxy that does not support the Range header, and MUST NOT be returned
>> to a client whose HTTP version is less than HTTP/1.1.
> These "MUST NOT" rules are uneccessary.  Proxies should *absolutely*
> be allowed to add an "accept-ranges" header, it's a very important
> addition of functionality.  Proxies should absolutely forward on
> accept-ranges headers, but should be aware of range requests so
> that it can pass them on to the upstream server if it doesn't
> natively support ranges.  And finally, there is no reason to 
> restrict range headers to 1.1 clients.  There are existing
> 1.0 clients that use ranges quite effectively, and there can
> be no confusion since you would never return a range response
> to a client without first receiving a range request.
> :lou
> -- 
> Lou Montulli                 http://www.netscape.com/people/montulli/
>        Netscape Communications Corp.

Thanks, that's what I suggested in 
and Jim did make that change for draft 04, so now we can stop arguing
about it.

 ...Roy T. Fielding
    Department of Information & Computer Science    (fielding@ics.uci.edu)
    University of California, Irvine, CA 92717-3425    fax:+1(714)824-4056
Received on Wednesday, 5 June 1996 23:55:31 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:17 UTC