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

more If-Modified-Since

From: Dave Kristol <dmk@allegra.att.com>
Date: Thu, 17 Aug 95 10:57:55 EDT
Message-Id: <199508171515.AA294242517@hplb.hpl.hp.com>
To: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
I feel like the little kid whose questions are missed among the
shouting of a huddle of bigger kids.  So I'll try again, now that the
exchanges among people on the U.S. Pacific Coast have died down.  The
issue is cache corruption and how to avoid it, and I'm obviously not
following some of the dialog.

Yesterday I asked whether Lou Montulli (or anyone else) could describe
to me the circumstances under which a file's modification date might
remain unchanged, even though the file content had changed.  I can
imagine the mechanics (e.g., Unix "touch"), but I don't understand why
someone would go to the trouble to do so.  Anyone care to respond?
(Private is okay.)

Lou argues that "HTTP servers reference a file system that can be
changed at random".  I presume he means by the Webmaster, and not by
other users.  If the Webmaster doesn't administer a site properly, then
all bets are off anyway.  Lou also says that "dates are not strong
enough by themselves to do an adequate job of versioning".  I'd like to
know why, which gets back to my original question.

I also don't understand the arguments about a Version header.  Mike
Meyer suggested that the origin server could generate one, and a client
could reflect it back to ask whether something changed.  Lou Montulli
was unhappy, saying the client could not calculate the Version
information independently.  I don't understand that reasoning.  Why is
it so hard to store it?  Why does the client need to calculate it?

I infer that Lou wants to use size as a way to tell whether a client
got an entire resource in the face of prematurely cut off connections.
Wouldn't a requirement that there be either a Content-Length or
packetized content (HTTP/1.2) be a better solution?  The client would
then know whether it got everything then.

I support the idea of the client's knowing whether its cache is
correct, but I oppose burdening the origin server with significant
extra work to help it do so.  So I oppose the need for an origin server
always to calculate checksums or file sizes, since that might require
running a script.  Even asking the origin server to compare a checksum
or file size supplied by the client against the server's idea of those
values is a burden.  For scripts, the server would have to do all the
processing of a GET anyway, if only to decide the supplied value

Dave Kristol
Received on Thursday, 17 August 1995 08:17:13 UTC

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