Re: Byteranges with 206 partial content

> > An additional feature is to say "give me a range if the document
> > hasn't changed, but if it has, send me the entire document".  Similar
> > to If-modified-since, but still quite different...  What would you
> > call such a header?
> 
> If-Modified-Since   (for the current case)
> Unless              (for the generic case)
> 
> > I will re-vamp a new version of the byterange draft reflecting these
> > changes, and will submit it for review in http-wg shortly.
> 
> I am willing to proceed with this in the main HTTP/1.1 spec, since the
> changes required are interwoven with the description of GET and caching.
> 
> However, I am not willing to support multiple ranges within a single
> request at the current time, so no multipart/x-byteranges.
> 
>  ...Roy T. Fielding
>     Department of Information & Computer Science    (fielding@ics.uci.edu)
>     University of California, Irvine, CA 92717-3425    fax:+1(714)824-4056
>     http://www.ics.uci.edu/~fielding/
> 

Could we use extra parameters in Request-Range as Shel Kaphan suggested instead
of having interactions between headers?  

>From Shel:

	Request-range:  bytes=X-Y; validator=<xxxxx>; other-parameter=<yyyy>

I think it provides a cleaner implementation.  The value of the validator
(or whatever we call it) can be interpreted by the server returning the
object.  One thing I'm not clear on is which header this identifier would be
passed in when delivering the original object?  One downside to this would be
that mirrored objects would have to have consistent values for the validator.  
When using URNs in something like the path scheme there is no guarantee that
the request will return to the original server.  So servers would have to
cooperate when mirrorring documents.

Another thing I like about Shel's suggestion is the idea of being able to use
an opaque string to uniquely identify an object which could be used instead of
the last modification date and URL. We are looking at the possibility of using
internal identifiers for each object for other reasons, but they could also be
used for the opaque string.  It would rapidily indicate to our server if the
requested URL and the previously identified object are identical or not.  Again,
we'd have to keep track of which documents are mirrored and treat the validator
differently for mirrorred documents and non-mirrored documents.


-- 
		Elizabeth(Beth) Frank
		NCSA Server Development Team
		efrank@ncsa.uiuc.edu

Received on Tuesday, 14 November 1995 16:31:28 UTC