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

> 
> >     The reason is because the Range header field is interpreted by the
> >     next inbound server that has the entity cached -- not necessarily
> >     the origin server -- and thus 14.5 is SEVERELY BROKEN in draft 04a.
> >
> > Unfortunately, you are wrong here.  I say "unfortunately" because
> > I regard this part of the specification as somewhat ugly.
> >
> > Two weeks ago, I would have agreed with you, but then I finally got Lou
> > Montulli to explain Netscape's insistence on support for
> > "Accept-Ranges: bytes".  We had several long telephone conversations,
> > with some side conversations between me and Jim, and this is the only
> > solution we could come up with that would satisfy Netscape's
> > already-deployed use of this header.
> 
> Ummm, no, I think there was a disconnect.  Assuming they implemented
> it according to their own design, then this is just a case of them
> not understanding what will happen when caches are involved.
> 
> > After all, if we weren't concerned with Netscape's installed base, we
> > would have named this header "Allow-Ranges".
> 
> Nope -- Allow-Ranges was the original name for indicating the
> byte range would be added to the URL, which is why we couldn't
> use that name again.
> 
> > Netscape wants to know that a Range GET on a (say) multi-megabyte
> > resource will definitely not result in a full-entity transfer, in
> > order to provide efficient support for plug-in applications that
> > do seeks.  And we have not made Range support mandatory for HTTP/1.1
> > servers, so "Accept-Ranges: bytes" is the signal Netscape uses
> > to tell the plug-in that a resource is "seekable".
> >
> > But if we allow an intermediate proxy to add an "Accept-Ranges: bytes"
> > to a response (thus turning this into a true hop-by-hop header) then
> > the client could be misled if the (1) the proxy evicts the entry
> > from its cache and (2) the origin server (or the next inbound
> > cache with a corresponding cache entry) does not support Range.
> > I.e., the request would be relayed through the Range-supporting
> > proxy to a server that would return the full (and possibly huge)
> > entity.
> 
> Then we need to inform the implementers (i.e., Netscape) that they
> are driving without a clue on this one.  For example,
> 
>    UA ---------->  A  ---------->  B  ------------> OS
> 
> UA makes a request for a 10MB file on OS which is not in UA's cache.
> 
>    a) If it is in A's cache, whether or not OS supports ranges is
>       irrelevant; preventing A from signaling support for ranges would
>       prevent Netscape from doing range seeking on the cache.
> 
>    b) If not in A but in B's cache, whether or not OS supports ranges is
>       irrelevant; preventing B from signaling support for ranges would
>       prevent Netscape from doing range seeking on the cache.
> 
>    c) If it isn't in A or B's cache, then the response comes first-hand
>       from OS and thus the client will find out if OS supports ranges.
> 
> So, if the desire here is to only send Accept-Ranges when the server
> is capable of the start-request/break-connection/get-catalog/get-1st-page
> hack that was the [SEVERELY dumb] design fostered by Adobe for PDF
> [as opposed to the rational design of just defining a network-pdf type],
> then we should at least define it in such a way as to be useful when,
> for example, UA is a palmtop and A is its home-base cache.

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.

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.

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

Received on Wednesday, 5 June 1996 17:46:53 UTC