Re: Explicit revocation

Ari Luotonen:
>[Koen Holtman:]
>> I conclude that we should first focus on reducing the number of
>> _unnecessary_ conditional GETs by giving some guidelines in the 1.1
>> protocol.
>
>Agreed!

OK, I see 2 options:

OPTION 1:
---------

Adopt the the rule that, if expires or cache control headers are
absent in a 1.0 or 1.1 response, a `soft expiration time' must be computed
by the recipient.

Encourage the use of the following computation heuristic:

  if no Last-modified header is present in the response:
      soft expiration time = now 

  if a Last-modified header is present in the response:
      soft expiration time = min( now + 1 day ,
                                  now + (now - Last-Modified) / 10
                                )

Furthermore, specify that:

 - if the recipient is a user agent, it should not send conditional
   GETs until after the soft expiration time.

 - if the recipient is a proxy cache, it should only send conditional
   GETs before the soft expiration time if forced to do so by a
   Cache-control: max-age=N request header from a client.

Encourage content providers to more often provide a `hard expiration
time' by adding Expires or Cache-control headers to responses.

Option 1 amounts to a standardisation of the fix that most current
proxy maintainers are using to deal with the lack of Expires headers.


OPTION 2: 
---------

Adopt the rule that an absent Expires or Cache-control header in a 1.1
response means `not cachable, always do conditional GET', and
encourage 1.1 content providers to always use Expires or
Cache-control.

In particular, encourage 1.1 server authors to make the automatic
addition of Expires or Cache-control headers to every reply a
configurable option that defaults to `on'.

For 1.0 responses, adopt the `soft expiration time' rule under option 1.

    --------

Given Jeffrey Mogul's excellent, though rather discouraging,
statistics about the current use of Expires headers, I prefer
option 1.

Opinions?


By the way, concerning the expires statistics:

Pages that do use Expires headers are indeed often made inaccessible
to web crawlers.  I believe that Expires is mostly used in dynamic web
systems, and these also often provide a semi-infinite web space that
crawlers would get lost in.  We recently forgot to protect a
semi-infinite futplex document space on www.design-inst.nl from
crawlers, and this has led to `interesting' results if you look up
`futplex' in altavista.

Also, note that a count of only 0.23% of web pages having Expires
headers does _not_ imply that at least 99.77% of the web is cachable.
Most CGI scripts producing dynamic output that is definitely not
cachable do not produce Expires headers to go along, and get away with
it because they also fail to produce Last-Modified headers.  Most
proxy caches use the rule
  no Last-Modified header present --> response was probably produced by 
  a CGI script --> I'd better not cache it then.


Koen.

Received on Saturday, 30 December 1995 18:12:37 UTC