Re: Some potentially interesting information about Expires:

    > So in summary I would say that it might well be sadly reasonable
    > to ignore "Expires:" today, since it's almost never used, and when
    > it is used, it is often clearly bogus.
    
    Aaargh, no!  If it exists but is bogus (un-parseable) treat it as
    "expires now", and don't cache.
    
    It's true that most of the time it's not there, and we can't build on
    its existence -- but the times it _is_ there, there _is_ a reason for
    it.  There may be software bugs that corrupt it in some cases, but
    those should be treated as "expires now", because the originator _was_
    trying to tell something expiration related, and failing to do that
    properly, "expires now" is the only safe thing to do.

Actually, my point was that the Netscape behavior that Koen was
complaining about (doing a conditional GET for every new request
on a resource that lacks an Expires header) makes sense in this
context.  Koen would agree (I assume) that the browser should
do a conditional GET on expired resources, and a bogus Expires:
header (as you observe) means that the resource ought to be treated
as expired, so this further reduces any reason to pay a lot of
attention to them.

One observation: I deduced that a certain fraction of the Expires:
headers were bogus by examining them for syntactical errors.
Of course, it may well be that some fraction of the remaining
Expires: headers were syntactically correct but were otherwise
bogus.

I'd like to see some form of Expires: (perhaps with different
syntax) become more or less mandatory in HTTP/1.1, so that a
response that does not carry the value would be treated as
"stale" immediately.  With HTTP/1.0 servers, it's probably
too costly to assume that no Expires: means "Expires: already",
because 99% of the time this would be the case, but in the
1.1 version, we should take a "safer" approach to expiration.

-Jeff

Received on Saturday, 30 December 1995 02:47:23 UTC