Re: Accept-Ranges (was Re: More small edits to draft 04a)

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

To do this, just define it such that any cache that supports Range can
add an Accept-Ranges if it has (or will have) the entire entity in its
cache for at least the next few seconds.  Netscape's implementation does
support this case, assuming it was implemented as they designed it to work.
This isn't exactly a hop-by-hop header, but I was never really fond of
that distinction anyway.

If it isn't defined in such a way that it is useful independent of
the PDF-hack, then it should be left outside the standard.

 ...Roy T. Fielding
    Department of Information & Computer Science    (
    University of California, Irvine, CA 92717-3425    fax:+1(714)824-4056

Received on Tuesday, 4 June 1996 14:55:36 UTC