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

Re: Improving If-Modified-Since

From: Rob Hartill <hartill@ooo.lanl.gov>
Date: Tue, 15 Aug 95 14:26:25 MDT
Message-Id: <199508152026.AA026908385@ooo.lanl.gov>
To: montulli@mozilla.com
Cc: fielding@beach.w3.org, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Lou M writes,

> If it is a violation of the spec then you really ought to make the spec
> clearer on this point.  All the major servers that I know of do a
> greater than or equal comparison.  The spec needs to be changed to
> specifically say that 304 should only be returned when the If-modified-since
> date matches the current modification date of the file.

There's nothing to say that the If-modified-since is the date given to
the client by the server it is subsequently sent to.

Condsider a resource mirrored at A and B
Server A can give you a Last-modified date for a URL which you can
then use on server B.

What you appear to be asking for (which might be useful as an alternative)
is a If-something-different type header,

a server sends

Foo: 1234

client asks,

If-Foo-Different: 1234

That might give everyone enough flexibility to increase the number of
"304 Not Modified" messages that servers return. It's difficult for
script writers to define Last-modified times for some output, but if
they could negotiate on something simpler, with a straightforward comparison,
then it'd encourage more script writers to write cache-friendly applications.

I abuse the IMS system with lots of scripts by using it in the way Lou
describes; returning a 304 only if the strings match (give or take a few
formating differences). Writing a full IMS handler is beyond the 
capabilities of most CGI writers, and I'm just too lazy.

Received on Tuesday, 15 August 1995 13:29:09 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:14 UTC