- From: Chuck Shotton <cshotton@biap.com>
- Date: Mon, 13 Nov 1995 20:29:34 -0600
- 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