2 (MUST result in change)
I can't parse the `variant' definition in terminology section.
Suggested new version:
variant
A representation of a resource, which may be updated through time,
which is available to a server for inclusion in responses.
Jg to choose among any of the competing definitions, so long
as it isn't the current one…
This suggestion does not imply any terminology changes elsewere.
3 (MUST result in change)
no-transform, and section 14.9.5
Suggested change: one of these
1) delete 14.9.5, delete no-transform
2) delete 14.9.5, change no-transform to allow-transform and add
note that future specifications might allow caches to transform
if this directive is present
also, maybe add a note that compression by a proxy must happen
at the transfer-encoding level.
Discussed above, and resolved above.
Koen.
From: rst@ai.mit.edu (Robert S. Thau)
Date: Thu, 6 Jun 1996 10:42:26 -0400
Message-Id: <199606061442.KAA11830@volterra.ai.mit.edu>
To: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Subject: 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