Lou Montulli writes: > I've been getting lots of bug reports due to corrupted or out dated > caches. I would like to propose an extension to the If-modified-since > header to improve the situation. I'd like to start sending > > If-modified-since: DATE; size=SIZE > > The addition of size=SIZE informs the server of the current size of the > document cached by the client. The size acts as a checksum, if the size > of the file to be served is different than the size given in the > If-modified-since header than a 304 should not be returned. > > The advantage of size over other checksums is that it is highly > efficient. Clients and servers can obtain the information at little or > no cost. > > The disadvantage of size is that it is not completely accurate as a > checksum. An MD5 hash or some other content based checksum would be far > more accurate but would require lots of additional overhead. > > In the future, if a stronger checksum is deemed necessary it can be added > as another part of the If-modified-since header. Perhaps: > > If-modified-since: DATE; size=SIZE; md5=SIGNATURE > > I have tested this change against the Netscape, NCSA, CERN and Apache > servers and all of them ignore the addition of size=SIZE, so we can add > this addition without fear of backwards compatibility concerns. I would say this was a good thing. I like the idea of using an md5 optionally. The processing would generally only be on the server, especially if netscape were to modify its cache index file to include the md5 of the document. Perhaps the server could be smart about when it re-computes the md5 of a document its serving as well. Perhaps store the md5 and last-modified time in memory for n documents? Just stat() the file and compare the last-modified times to see if it needs to be md5'd again. The problem with this is that for an efficient client, an index file for the cache would be necessary. And I don't like index files. :) -Bill P.