W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 1995

Re: Comments on Byte range draft

From: Chuck Shotton <cshotton@biap.com>
Date: Mon, 13 Nov 1995 20:29:34 -0600
Message-Id: <v02130503accdae2935fe@[198.64.246.22]>
To: Lou Montulli <montulli@mozilla.com>, Larry Masinter <masinter@parc.xerox.com>
Cc: ietf-lists@proper.com, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
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)

>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?

--_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-
Chuck Shotton                               StarNine Technologies, Inc.
chuck@starnine.com                             http://www.starnine.com/
cshotton@biap.com                                  http://www.biap.com/
                 "Shut up and eat your vegetables!"
Received on Monday, 13 November 1995 18:35:08 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 2 February 2023 18:42:56 UTC