Re: Comments on Byte range draft

Chuck Shotton wrote:
> 
> At 5:32 PM 11/13/95, Lou Montulli wrote:
> >Larry Masinter wrote:
> >Maybe we should make "if-not-modified-since" an optional
> >attribute to the request-range header.
> >
> >Therefore a byte range request would look like:
> >
> >GET /byterange-capable-document HTTP/1.0
> >Request-Range: bytes=500-999; if-not-modified-since="DATE"
> 
> I assume the semantics of this would mean that if the if-not-modified-since
> information is present, it must be honored by the server in that it must be
> used to determine if the identical byte range can be served. If this is the
> case, what is acceptable behavior for a server that receives this header
> but cannot determine the date associated with the requested byte range?
> (e.g., the content was generated on the fly and has no modification date,
> per se, but may be reproducable)

If the results are reproducable than the server can produce any date
that it wishes to use as a time checksum.  I have written such scripts
in the past and I usually use the most recent modification date of
all the dependancies for the data.

> 
> >We should also be able to send size checksums, so we
> >could add 'if-size-equal="LENGTH"' as well.
> 
> How would this work? I assume this is for documents where the entire
> document has already been received, or at least a size checksum has already
> been transmitted to the client as part of a previous response. I assume it
> has no bearing on the partial file transfer problem? What is the added
> value of this option?

In most cases the server returns a content-length for the object.  The
content length would be returned in the if-size-equal header.

The added value of the option is to give an additional checksum to guarentee
accuracy.  A generalized checksum method would also be desirable.

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

Received on Monday, 13 November 1995 18:42:11 UTC