W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > May to August 1995

Re: Improving If-Modified-Since

From: Mike Meyer <mwm@contessa.phone.net>
Date: Thu, 17 Aug 95 02:19:14 PST
Message-Id: <19950817.77E12D0.23E6@contessa.phone.net>
To: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
> 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 EDT

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:31:25 EDT