Concerns with draft-04...

Well, I *finally* (belatedly) did a serious review of the draft-04
text.  There still may be a few problems... here are two items in
particular I picked up (one big item and another which is small, but
--- IMHO --- serious).

1) Section 14.7 says that a proxy MUST NOT edit the Allow: header
   value.  Section 9.2 says that it MUST, at least in the specific
   case of a response to an OPTIONS request.  Who's right?

2) The wording in section 10.3.5 on what headers should be sent with a
   304 is an improvement, but I still can't figure out what *exactly*
   a conforming server is supposed to do.  The three conditions there
   are:

   a) A response MUST include any values which might differ from those
      which were received with a prior 200 response.

   b) A response MUST include any values that caches use for matching
      requests and responses with cache entries.

   c) A response SHOULD NOT include anything "which cannot possibly
      have changed."

   These criteria don't seem entirely consistent with the examples of
   "relevant" headers given in the text.  For instance, I'm not sure
   which of criteria (a) or (b) makes "Server" a particularly relevant
   header, especially given that in almost all cases, (c) will apply.
   However, it is the rules themselves that are normative, and my main
   concern is with them.

   To begin with, (b) and (c) seem to be partially contradictory ---
   the implication of (b) seems to be that even if a header that
   caches use for checking matches to cache entries cannot possibly
   have changed, the 304 response should include it anyway.

   A more serious concern is that I can't figure out how, say, a
   member of a chain of HTTP/1.1 caches sandwiched between an HTTP/1.2
   user agent and origin server is supposed to determine exactly which
   headers meet criterion (b).

   For example, "Alternates" might be a reasonable bet, but this is a
   manner of interpretation, since as far as I can tell the current
   draft does not otherwise specify any normative behavior at all for
   an HTTP/1.1 cache in receipt of an Alternates header.  In any case,
   the working group might change the spelling of "Alternates" to
   "Variants", or to add some sort of more general Negotiation-control
   header which subsumes it.  Given that multiple incompatible content
   negotiation proposals have already come out of this WG over the
   past year or so, I as an implementor don't feel comfortable
   excluding either possibility, which makes it very difficult to
   determine how I should treat any particular header in any code
   which I might be writing now.

   Accordingly, I'd like to respectfully suggest that change here is
   needed.  As a strawman, here's a set of rules that I personally
   would be a little more comfortable with (though it's entirely
   possible that they have problems which have escaped my cursory
   review):

   a') A response MUST include any values which might differ from those
       which were received with a prior 200 response.

   b') If a response comes from an origin server directly, it MUST
       include any values that caches use for matching requests and
       responses with cache entries by caches of its protocol version
       or better, and SHOULD NOT include any other values.

   c') If a response comes from a proxy, it MUST include all values
       received, *except* those on an explicit, normative stop-list.

       (I understand that some of you don't like normative lists.
       However, a proxy cannot in general know the protocol version of
       the origin server, since the response may have been downgraded
       by an intermediate proxy.  Likewise, a caching proxy which has
       to generate a 304 for a resource which is fresh in its cache
       may never have seen a validating 304 from downstream for that
       resource.  Given all that, passing along everything not on a
       normative stop list is the only thing I can personally think of
       that allows new negotiation-related headers to be added to
       future versions of the protocol).

There is some more minor stuff (e.g., certain questions about
responses from caches in New Zealand and elsewhere which don't always
allow clients to force the cache to validate an entry), but I'll save
those for later.

rst

Received on Thursday, 6 June 1996 07:45:47 UTC