On Mon, 14 Aug 1995, Lou Montulli wrote:
> >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.
If people "screw up their dates", they're hurting themselves and the people
who view their pages. This *isn't* accidental, is it? How do you
accidentally set a last-modified to be some future time? It's like a
surgeon accidentally removing a right leg instead of a left leg or a
disgruntled employee accidentally shooting his boss.
Or maybe it's intentional...
> 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.
They can't just do a strcmp() since there are a couple date formats it
needs to deal with. Also, consider a situation where there are three
mirrors for a web site, and all three are hidden behind www.host.com and
selected through shortest-return-trip calculations (like the CERN
linemode browser does). Getting a last-modified on one which was later
than the last-modified on the other, even though they are the same
document, certainly makes sense.
> >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.
Okay, so what should a server do when it doesn't know the actual
content-length of an object, like a CGI script? It's totally plausible to
ask a dynamic object "hey, has any data upon which you would answer this
question changed since *blah*" in a way that's very quick to answer, but it's
hard to imagine asking it "hey, will your final output be any size
different than *blah*" without having it do what it normally does. So,
if it's in there, it must be optional for the server to use it.
Brian
--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
brian@organic.com brian@hyperreal.com http://www.[hyperreal,organic].com/