- From: Lou Montulli <montulli@mozilla.com>
- Date: Mon, 13 Nov 1995 14:57:29 -0800
- To: Shel Kaphan <sjk@amazon.com>
- Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Shel Kaphan wrote:
>
> I'm not going to say if I think byte ranges as presented here are A
> Good Thing or A Bad Thing (since there seem to be some valid arguments
> on both sides), but I would like to suggest that it might be
> considerably safer if there was a standard way the client could
> include in the request the last-modified date, or a checksum of the
> whole document, that it last received in connection with the original
> fragment of the document that it received. Then servers too could
> help to keep things in sync, in particular by returning an error
> status if the request and some available version of the document don't
> match up. Except for a request for an initial fragment of a
> not-yet-seen document, clients should probably always include this
> information.
Netscape always sends an If-modified-since request with a
date stamp and size checksum before attempting to use a
partial cache file and request the missing end.
>
> Regarding certain other parts of this discussion I have not really
> read too thoroughly, the byte range should be defined in
> terms of the *server's* original byte numbering, before any
> end-of-line processing, double-byte character conversion, or whatever.
> And intermediates shouldn't do any such processing. Or else this is doomed.
The byte range should be defined by what goes over the wire.
It should reflect any post processing that the server does but
should not reflect anything that the client changes.
:lou
--
Lou Montulli http://www.netscape.com/people/montulli/
Netscape Communications Corp.
Received on Monday, 13 November 1995 15:02:56 UTC