Re: Improving If-Modified-Since

>>In addition to supporting size=SIZE I encourage other server authors to
>>do an _equals_ comparison rather than a greater than or equal comparison
>>of the two dates.
>
>Isn't this what the standard says anyway?

The spec only refers to "if the resource has been modified since the
If-Modified-Since: date".  As far as I'm concerned, if the request contains
"If-Modified-Since: Mon, 14 Aug 1995 23:38:43 GMT", and the server has a
last modified date of "Mon, 14 Aug 1995 23:38:44 GMT", then returning
something other than 304 is a bug.  Who knows how the caching client/proxy
is saving the date.  Maybe it's saving the last time it requested it, maybe
it's saving the Date: the server previously sent back, maybe it's saving the
last time when the response is completely recieved.  It wasn't specified in
the spec <insert standard "this is a communication protocol" rant> that
cache's have to store on the Date: header, so it can't be forced on them
now.  Changing from >= to == would probably render a few current caching
schemes completely useless.

I'm against this change. :)

>I assume you anticipate this being implemented by having software simply
>ask the underlying file system for a byte count of the file? This will

Makes sense.

>break between any two machines with different end of line sequences. As an
>example, many servers read text files in their native format, converting
>EOL sequences as they are sent to the client (proxy). This means that the

They do?  Shouldn't the client be doing those EOL translations?

>I think this problem alone is enough to make this scheme unworkable. This

Caches would have to store the Content-Length header, not the size of their
content to deal with this EOL translation problem.  Content that lies about
its length is a much bigger issue (keep alives break).

I think if the scheme is unworkable, it's because of dynamic content.  But,
then again, the whole If-Modified-since: thing goes out the window with
dynamic content, so adding a "size=value" paramter won't hurt anything.  (I
assume most servers ignore If-Modified-since: on CGI/POST requests, am I
correct?)

>corrupted caches. The modification date is a sufficient mechanism for
>determining whether or not a document has changed, assuming both ends are
>able to maintain data integrity. If the proxy server needs to maintain a

I would tend to agree, but if people plan on starting a HEAD request,
checking Content-Length:, then comparing lengths before doing a GET, we
might as well give them the ability to do it with an If-Modified-since:.

>Simple comparison of the local checksum to the local data store is
>sufficient to indicate corruption.

That's not the kind of corruption Lou's trying to solve.

I'm for this change. (I think) :)
-----
Dan DuBois, Software Animal                          ddubois@spyglass.com
(708) 505-1010 x532                     http://www.spyglass.com/~ddubois/

Received on Tuesday, 15 August 1995 07:12:11 UTC