Re: ADAMS1, point 31. (cachability of methods).

Sorry for the slow response - due to a mailing list malfunction,
I wasn't getting HTTP-WG messages for a few days.

Larry writes:

    In most cases, the 'cachable' constraint is not on whether
    you store the value in a cache, but whether you USE the
    cached value. Now, it may be foolish to cache something that
    you cannot use, but perhaps not; e.g., even if the results
    aren't exactly cachable, could you use delta-coding on the
    next request with an appropriate entity tag?
    
Yes indeed.  This might be one of the biggest payoffs for
delta-encoding, since it allows the "virtual transmission"
of a sequence of changing responses without actually sending
all of the bits over and over again.

    I don't know whether it's best to say SHOULD NOT and let
    implementors figure out the constraints, or to go ahead
    and use MUST NOT, but to carefully redefine 'cachable' or
    'cached' to mean that the cached value cannot be used,
    and thus probably shouldn't be stored.

I agree that the term "cachable" may be a poor one to use in a
statement of formal requirements.  But we *do* have the right
formal definition in section 1.3:

 cachable
     A response is cachable if a cache is allowed to store a copy of
     the response message for use in answering subsequent requests. The
     rules for determining the cachability of HTTP responses are
     defined in section 13. Even if a resource is cachable, there may
     be additional constraints on whether a cache can use the cached
     copy for a particular request.

although I'm not sure I would trust every implementor to read and
internalize these definitions.  Fortunately, the folkloric definition
of "cachable" (meaning: to store at all in a cache) is a stronger
requirement.  So an implementor who uses the folkloric definition,
rather than the formal one, risks losing efficiency but not
transparency.

However, Jim proposed:

    Responses to methods other than GET or HEAD MUST NOT be cached,
    unless the response includes appropriate Cache-Control or Expires
    header fields

and the verb here ("be cached") is not formally defined in the
sense that Larry describes, as far as I know.  I'd suggest:

    Responses to methods other than GET or HEAD MUST NOT be treated
    as "cachable" (by the definition in section 1.3),
    unless the response includes appropriate Cache-Control or Expires
    header fields.

Koen writes:
    >"Responses to methods other than GET or HEAD MUST NOT be cached,
    >unless the response includes appropriate Cache-Control or Expires
    >header fields"

    I believe that the spec makes the above statement somewhere already,
    though I just tried to find it and failed.  Jeff?

Hmm.  Section 13.4 (Response Cachability) says something
vaguely similar, although it might say something wrong: it
doesn't mention any methods, but says (in effect) that all
status-200 responses are cachable unless otherwise marked.
Since POST definitely allows a status-200 response and is
by default not cachable (section 9.5), this is a contradiction.

I did a quick search for a statement matching the one that Jim
suggests, and didn't find it (which doesn't mean that it isn't
there).

My suggested fix:

(1) In 13.4 change:

   Unless specifically constrained by a cache-control (section 14.9)
   directive, a caching system MAY always store a successful response
   (see section 13.8) as a cache entry, MAY return it without validation
   if it is fresh, and MAY return it after successful validation.

to:

   Unless specifically constrained by a cache-control (section 14.9)
   directive, a caching system MAY always store a successful response
   (see section 13.8) to a GET or HEAD request
   as a cache entry, MAY return it without validation
   if it is fresh, and MAY return it after successful validation.
   A caching system MUST NOT treat responses to other methods
   as cachable (by the definition in section 1.3) unless the
   response includes Cache-Control or Expires header fields
   implying that the response is cachable.

(2) In section 9, make a forward reference to section 13.4?

-Jeff

Received on Monday, 16 November 1998 11:51:06 UTC