Re: Comments on Byte range draft
Lou Montulli (montulli@mozilla.com)
Mon, 13 Nov 1995 18:36:31 -0800
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.