Re: Comments on Byte range draft

Shel Kaphan writes:
> 
> 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.
To make this working, allways when a 'Partial content' response sent, we
should require sending checksums and digests for the whole url and the part
transmitted if the server supports any checksums/digests.
> 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 last 1.1 draft I read says something like:
intermediaries and even clients should cache documents without any change in
content, the only case when a client may and MUST apply conversions to local
line-endings and other such stuff when it does a 'save as' operation.
If my memory is correct, then we have absolutely no problems with byte-ranges.

Andrew. (Endre Balint Nagy) <bne@bne.ind.eunet.hu>

Received on Sunday, 12 November 1995 16:50:14 UTC