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

    Section 13.4.1
    
     Accept-Ranges should be added to the list of hop-by-hop headers.
    
No; see below.

This is not a hop-by-hop header, because it can only be deleted
by intermediate servers, not added by them.

    ====================
    Section 14.5 (Accept-Ranges)
    
    The following paragraphs are absolutely wrong and must be deleted:
    
    >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.
    > 
    >  Note: this rule allows a client to be reasonably sure that a
    >  subsequent Range request on the entity will not accidentally
    >  transfer the entire entity.  However, the subsequent Range request
    >  may follow a different request chain, and so there is a small
    >  chance that the entire entity will be returned in a response.
    
    and the paragraph below it should begin with "Servers ..." instead
    of "Origin servers ...".
    
    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.

After all, if we weren't concerned with Netscape's installed base, we
would have named this header "Allow-Ranges".

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.

So, in fact, the specification for Accept-Ranges in previous
drafts was "SEVERELY BROKEN" in that it did not actually work
for the sole purpose that anyone currently cares about.

-Jeff

Received on Monday, 3 June 1996 16:52:52 UTC