>>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/