- From: Lou Montulli <montulli@mozilla.com>
- Date: Mon, 14 Aug 95 21:25:04 -0700
- To: Brian Behlendorf <brian@organic.com>
- Cc: Alex Hopmann <hopmann@holonet.net>, Lou Montulli <montulli@mozilla.com>, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
>Why would a server pumping out bogus last-modified headers act appropriately
>to another type of check? Adding something to the protocol just because
>another part is not being used properly seems a bit weird. If I'm
>understanding the problem correctly.
The problems currently encountered are mostly caused by the date comparisons
done by most HTTP servers when dealing with If-modified-since requests.
Most servers assume that as long as the If-modified-since date is equal to
or AFTER the current modification date of the document then it is unchanged.
This is a problem because people screw up the dates on their files and
sometimes give them dates far into the future. When they fix the
dates of the files to correspond to the current date, caches never
get updated.
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.
>
>Will the "size" be determined from the Content-length header or the size on
>the cache's disk? If the former, documents with incorrect content-length
>headers are essentially uncacheable, as are results from CGI scripts which
>generally don't have content-length headers. If the latter, could there
>be encoding problems?
The size is determined by taking the current length of the document in the
cache. The content-length of the transfer is discarded, so encodings
should have no effect.
:lou
--
Lou Montulli http://www.mcom.com/people/montulli/
Netscape Communications Corp.
Received on Monday, 14 August 1995 21:27:31 UTC