- From: Dave Kristol <dmk@allegra.att.com>
- Date: Thu, 17 Aug 95 10:57:55 EDT
- 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 matches. Dave Kristol
Received on Thursday, 17 August 1995 08:17:13 UTC