Re: Improving If-Modified-Since

 
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,

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


rob
--
http://nqcd.lanl.gov/~hartill/

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