Re: HTTP Caching Design

Roy T. Fielding:
>
[....]
>In contrast, the design that Jeff Mogul has proposed in 
><http://ftp.digital.com/%7emogul/cachedraft.txt> implicitly *discourages*
>caching.  In order to make a resource cachable, the provider must do 
>extra work even when they "don't care". 

I completely agree with you that Jeff's requirement

  |An HTTP/1.1 server SHOULD provide a fresh-until time with every
  |cachable entity, but if it does not, the cache must assume a value of
  |zero.

is a very bad thing.  However, Jeff's reason for requiring this:

  |Any other interpretation of a missing value (such as
  |``Forever'') would make it impossible for the server to provide a
  |new, earlier fresh-until time at a subsequent point, since a large
  |enough cache would never validate the entity again.

does have a point.  I would like to propose a rule in 1.1 that a
response without a valid Expires/Fresh-until/Cache-control/whatever
header may not be served unvalidated from a cache if more than 7 days
have past since the previous validation.

Other comments on <http://ftp.digital.com/%7emogul/cachedraft.txt>:

- I'd rather not require servers to generate opaque validators, though
  I do want to require clients and proxies to use them if present.

- In section 2.3, it says that there needs to be a clear definition of
  `correct' (I agree to that), but the section fails to give a clear
  definition.

- I have no big problem with clients using `stale-max=...' to override
  a lifetime set by the server, as long as the addition of stale-max
  does not mean that service authors loose their ability say that a
  response must really _never_ be served from a cache without
  validation (interactive web services often generate such responses,
  and no, they cannot do without them).

- (2.11) If the warnings are in a response header, they should not use
  numbers from the Status-Codes space.

- In `2.14 Side effects of GET and HEAD':
   | Section 14.2 (``Safe Methods'') of the draft HTTP/1.1
   | specification [1] implies that GET and HEAD methods should not have
   | any side effects that would prevent caching the results of these
   | methods.
  This interpretation of 14.2 is completely incorrect.  Ever heard of 
  page counters?

- In general, I feel that the 1.1 draft caching features do not need a
  complete redesign from first principles.  Yet this seems to be one
  of the things the draft aims for.  And in starting from first
  principles, it fails to address the few unplugged holes in the 1.1
  draft caching features. (Some examples of unplugged holes:
  description assumes global clock, cascaded proxy caches and max-age,
  failure to be more explicit about (the allowedness of) caching
  heuristics when cache-related response headers are absent.)

>Finally, at least one person has said that the current caching algorithm
>is "broken".  However, I have yet to see any examples of brokenness
>illustrated with the current HTTP/1.1 caching mechanisms.

Me too.

>  I have also
>yet to see an example of cache usage/requirements that has not already
>been met by the HTTP/1.1 design.

I have an example. Currently, if servers use authentication, responses
can never be cached.  See Section 10.6 in the 1.1 draft:

 # Responses to requests containing an Authorization field are not 
 # cachable. 

There exists a great number of servers that use authentication just to
recognize different users, not to protect content from being accessed
by everybody.  www.wired.com and www.dds.nl are two examples I know
of.  Almost all of the responses from these servers are not secret,
and highly cachable.  Yet, there is no easy way for these servers to
get the cachable responses cached.  I believe that wired.com uses a
second server for the inline pictures, just to get around the
restriction in Section 10.6.

I therefore propose (again, I also did this somewhere in the summer) a

 Cache-control: public

response header that could be used to override the restriction in
Section 10.6.

>[...] I am not at all happy about the current direction of the subgroup.

I'm not that happy too.  I would applaud it of someone would, sometime
in the next few weeks, mail an edited version of the 1.1 draft caching
sections with just the holes plugged, completely ignoring
<http://ftp.digital.com/%7emogul/cachedraft.txt> and the discussions
about caching of POSTs in this subgroup.

I probably won't have the time to make such an edited version myself,
but I promise to help in flaming anyone who objects to such an edited
1.1 version on the grounds that it does not start from first
principles, or does not include an explicit correctness model.

> ...Roy T. Fielding

Koen.

Received on Sunday, 7 January 1996 21:43:14 UTC