Re: Byte Ranges

"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!

1) The return code "206 Partial Response" is overloaded which makes it
difficult to handle. In the example of the palm-top above, if I do
not include an "If-Range" then the nature of the request is a normal
GET, but if it included an "If-Range" then it is more of a cache 
validation 
including the extra chunk of data. In the former case, sending the meta
information is OK, but in the latter case, the metainformation is just as
confusing as it would be in a 304 response. That is, it'd better be the
same - otherwise I'm in trouble. Therefore, two different return codes
seems appropriate - "206 Partial Response" and "30x Partial Update"

2) The second problem is that you can not ask for byte ranges of streamed 
data which you normally would chunk encode - the full content-length must
be provided in the Content-Range header. While in some cases it is good to
know the full content length, it is not always available and certainly not
always needed. This effectively means that you can not have streamed data
on your palm-top served by HTTP.

3) An unfortunate consequence of aborting a load is of course that it 
requires
the connection to be closed. This is just a statement of fact - I am not
too concerned about this one as it may be fixed, for example in a session
layer below HTTP.

Henrik

-- 
Henrik Frystyk Nielsen, <frystyk@w3.org>
World Wide Web Consortium, MIT/LCS NE43-356
545 Technology Square, Cambridge MA 02139, USA

Received on Wednesday, 2 October 1996 08:20:37 UTC