Re: Improving If-Modified-Since

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

Changing the date comparision from equal to greater than or equal
makes the date comparison into another such item, module conversion
between date formats (though most file systems have a place reserved
for that). You could implement this by saving the last-modified header
and sending it back as the value of the if-modified-since header.

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.

	<mike

Received on Wednesday, 16 August 1995 22:35:02 UTC