Re: Byte Ranges

Henrik Frystyk Nielsen wrote:
> 
> "Roy T. Fielding" writes:
> > > Section 14.36.1 of draft 7 says that if the last-byte-pos is greater
> > > than the current length fo the entity-body, it should be taken to be
> > > one less than the current length of the entity-body in bytes.
> > >
> > > While this is tolerant, it is not rigourous.  One (the only?) case
> > > where this could happen is for a client to make an unconditional
> > > request for an entity that has changed (i.e., the request would fail if
> > > it were qualified with the appropriate validator).
> >
> > Nope, Ted's comments in Paris were discussed at length when the editors
> > met in Palo Alto.  The reason for the above rule (which I didn't know
> > when I was in Paris) is that it allows a resource-constrained client,
> > such as a palmtop viewer, to always limit its requests even when it has
> > no idea how large the response will be.  Thus, it allows the client
> > to cleanly request only what it knows it can handle, and therefore may
> > reduce unnecessary network transfer and/or broken connections.
> 
> Regarding byte ranges, I have been playing with making ranges effective
> to stop and restart the load at a later time. The reason was to come up
> with some figures for how much you can gain over a slow link (modem, for
> example). This is something that will be needed even with a possible
> session layer below HTTP as the bandwidth may be so limited that it is
> difficult/impossible to have multiple background loads going on at the
> same time.
> 
> These are the points that I have so far - comments are welcome!

Navigator has had this feature since January and it has proved to 
be very effective for slow modem connections.  Our algorythm is
as follows.

*Normal load starts.
*User interrupts load via stop button or clicking on another link.
*The cache recognizes that the server supports byte ranges via
the Accept-ranges header and stores the partially cached file
along with the full content length.
*User returns to partially cached object
*Navigator issues an If-modified-since request to see if the
object has changed.  If the object has changed we download
the whole object again, otherwise we move to the next step.
*We issue a byte range request for the rest of the object
and stream the whole object to the parser.

When I had originally implemented this I had thought about
a different request type that could perform the If-modified-since
request and the byte-range request at the same time.  I threw
out the idea because I thought it was overly complicated and
difficult to express.

:lou
-- 
Lou Montulli                 http://www.netscape.com/people/montulli/
       Netscape Communications Corp.

Received on Wednesday, 2 October 1996 11:39:21 UTC