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

> 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 
    <http://www.ics.uci.edu/pub/ietf/http/hypermail/1996q2/0615.html>
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
    http://www.ics.uci.edu/~fielding/

Received on Wednesday, 5 June 1996 23:55:31 UTC