- From: Alex Hopmann <hopmann@holonet.net>
- Date: Mon, 14 Aug 1995 20:00:07 -0700
- To: Lou Montulli <montulli@mozilla.com>, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
I agree with Lou's proposal. Regarding Simon's suggestion that we also provide a simple checksum, I don't think that would really be a great benifit. The overhead of simply opening a file and scanning through its contents strikes me as greater than that of the MD5 ifself. So personally I would either want an extremely fast mechanism such as the file size & date, or else go for the real MD5. >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. > >Comments? > >:lou >-- >Lou Montulli http://www.mcom.com/people/montulli/ > Netscape Communications Corp. > > Alex Hopmann ResNova Software, Inc. hopmann@holonet.net
Received on Monday, 14 August 1995 20:06:58 UTC