Re: Improving If-Modified-Since

> the IMS last modified date is already a value that must be stored
> out of band in the cache.

I think I pointed that out; it's important to note, though.

> > A new header from servers: Version: Version-string
> > A new header from clients: If-Not-Version: Version-string

> This would work pretty well but has the disadvantage of not being
> reproducable on the client end.

The IMS LM date has the same problem - the client can't reproduce it.

I like the more generic "If-different" header. We can even tweak it to
save 15 of the 20 bytes you complained about:

	If-Different: 1#( field-name value ; )

The server then verifies that for each field-name/value pair, it is
going to send a header with that name whose value (after trimming
leading and trailing whitespace) is the same as the client sent on the
if-different field. If one of them is different it sends the document.
Otherwise, it sends a 3xx reply "Not different".

You can therefore get the behavior you want from 

	if-modified-since: last-modified ; size=length

with

	if-different: last-modified ; content-length length

and leave if-modified-since with the current definition for those who
have a use for that.

Optional bandwidth reducer: allow the server to not send any headers
that are named on the if-different header that haven't changed.

	<mike

Received on Thursday, 17 August 1995 02:28:13 UTC