Re: Improving If-Modified-Since

In article <19950816.75DE920.13DA5@contessa.phone.net> mwm@contessa.phone.net
(Mike Meyer) wrote:
> 
> > It is not at all a fatal flaw.  The size returned by the client needs
> > to be specified to be the same as the "content-length" returned by
> > the server during the request.  If line-feed conversion is being
> > done consistantly the size can be compared accurately.
> 
> This makes the "content-length" an arbitrary value that must be stored
> out of band in the cache, and returned to the server as part of a
> "version check" request.

the IMS last modified date is already a value that must be stored
out of band in the cache.  The client local time can not be
relied upon so it can not be used to compute a last modified date.
Only in cases where you can guarentee reliable dates (i.e not
PC's and not Macs) can you use the local date as a value, I
suspect some UNIX proxies do this.

> 
> If we're going to change the spec for this, and are requiring that
> clients keep out of band data to comply, why not provide versioning of
> the kind the server (which has to do the work) wants to support?
> 
> Observation: the version string has no meaning as far as the client is
>         concerned.
> 
> Proposal:
> 
> A new header from servers: Version: Version-string
> A new header from clients: If-Not-Version: Version-string
> 
> Version-string is a string of characters other than ";" and whitespace.
> 
> Since version-string only has meaning to the server, it can be
> whatever you want. The file size; a VMS file version number; an MD5
> digest; a CRC, etc.

This would work pretty well but has the disadvantage of not being
reproducable on the client end.  A standardized checksum method
would remove the need for out of band data to be stored, or if
the out of band data was lost, it could be regenerated.

:lou
-- 
Lou Montulli                 http://www.mcom.com/people/montulli/
       Netscape Communications Corp.

Received on Wednesday, 16 August 1995 23:52:33 UTC