Re: Comments on Byte range draft

Okay, so we have a suggested algorithm:

1) Clients send the byte range as an HTTP header, something like 
   "Request-Range: bytes=500-999".

2) Servers either

	a) Respond with "206 Partial Content", with the same headers as what 
           the full object would get, the only difference being 

	b) Respond with "200 Ok" if they don't support that header for that
	   object.  It's expected that some servers won't support the
	   header for a class of documents (CGI scripts, parsed documents, 
	   other forms of dynamic documents) but that is an implementation 
           decision.  Note that this would be the default behavior for 
	   servers which do not understand the new header.

3) Proxies act like a client when pulling in data, and a server when 
   pushing out data.  Note that the default behavior of existing 
   proxies will be to ship around the full object, which is preferable
   to failure, partial objects, or redundant data (i.e., having both
   a full object and parts of the same object in the cache).

Could we discuss the benefits/drawbacks of this algorithm? 

The only thing which this document does not address is a syntax for encoding
byte ranges into URLs, with the expectation that its syntax would be
standardized and recognized by proxies/servers across the board for the
purpose of optimization.  I would suggest that another mechanism be proposed
for query by structure for more complex data types.  The main purpose of 
this algorithm is graceful recovery from aborted transfers. 


--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--  http://www.[hyperreal,organic].com/

Received on Sunday, 12 November 1995 22:21:30 UTC