- From: Klaus Weide <kweide@tezcat.com>
- Date: Tue, 18 Feb 1997 00:23:50 -0600 (CST)
- To: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Here are some comments or suggestions (mostly minor) for
draft draft-ietf-http-negotiation-00.txt:
1/
Somewhere in 4.4:
--- begin excerpt ---
| A server may only choose on behalf of the user agent if the user
| agent explicitly allows the use of a particular remote variant
| selection algorithm in the Negotiate request header.
--- end excerpt ---
Replace first "the user agent" with "a user agent supporting
transparent content negotiation", and maybe add the following in
parentheses: (But see also 4.5).
2/
What exactly does "capable of t.c.n." or "supports t.c.n." mean?
The expression occurs often enough that it should be added to the
terms in 2.2...
I assume that a server (including a proxy) must be able to determine
unambiguously whether a request originates from a user agent "capable
of t.c.n." (e.g. 1/ above and 4.5 require this), if the request is for
a transparently negotiable resource. I also assume that the Negotiate
header is for this purpose. But does absense of a Negotiate header
mean "The user agent does not support t.c.n. (for this request)"?
This seems logical, but I did not find it clearly stated. (I may have
overlooked it though..)
3/
--- begin excerpt ---
|8.7 Variant-Vary
The Variant-Vary response header can be used in a list response to
^^^^^^^^^^^^^(a)
record any vary information which applies to the variant data
^^^^^^^^^^^^(b)
contained in the response, rather than to the response as a whole.
--- end excerpt ---
(a) Should that be "choice response"?
(b) The term "variant data" is not explained (I first took it as meaning
the same as "variant list"). Suggestion: replace with something
involving the word "entity", or add term to list in 2.2.
4/
--- begin excerpt ---
|9.2 Structured entity tags
A structured entity tag consists of a normal entity tag of which
the opaque string is extended with a semicolon followed by a
variant list validator:
--- end excerpt ---
Replace with
--- begin excerpt ---
|9.2 Structured entity tags
A structured entity tag consists of a normal entity tag of which
the opaque string is extended with a semicolon followed by the text
(without surrounding quotes) of a variant list validator:
--- end excerpt ---
Yes this is really a nitpick...
5/
--- begin excerpt ---
10 Content negotiation responses
[...]
Transparently negotiated responses with other status codes may also
include an Alternates header, if this is allowed by the HTTP/1.1
specification [1]. Note that HTTP/1.1 does not allow an Alternates
header in a 304 (Not Modified) response. [...]
negotiation, a server must never include an Alternates header.
--- end excerpt ---
I cannot find anything that forbids an Alternates header field in RFC 2068.
What comes closest is (section 10.3.5)
--- begin excerpt ---
If the conditional GET used a strong cache validator (see section
13.3.3), the response SHOULD NOT include other entity-headers.
Otherwise (i.e., the conditional GET used a weak validator), the
response MUST NOT include other entity-headers; this prevents
inconsistencies between cached entity-bodies and updated headers.
--- end excerpt ---
But (a) the "MUST NOT" only applies for weak validators, and (b) Alternates
is not an entity-header but a response-header.
6/
--- begin excerpt ---
10 Content negotiation responses
[...]
| After having constructed a list, choice, or ad hoc response, a
| server may process any If-No-Match or If-Range headers in the
| request message and shorten the response to a 304 (Not Modified) or
| 206 (Partial Content) response, following the rules in the HTTP/1.1
| specification [1]. In this case, the entity-ID of the shortened
| response will identify it as belonging to a list, choice, or ad-hoc
| response.
--- end excerpt ---
You have not defined entity-ID (at least in this draft). As a result,
I don't understand how a 304 response (or a 206 response) carries
information on the original response code.
7/
10.2, 3rd paragraph:
--- begin excerpt ---
[...] Section 10.3 specifies how
^^^^
| these two items can be obtained by a proxy cache.
--- end excerpt ---
Should this be 10.4, or maybe 9.x?
8/
10.2, in description of the algorithm under 2.:
--- begin excerpt ---
| Note: the proxy must be careful not to add entity tags of
| non-neighboring variants to the request, as there are no
| global uniqueness requirements for these tags.
--- end excerpt ---
Suggest replacing of "to the request" by "to If-* headers in the request",
for clarity.
9/
10.2, in description of the algorithm:
--- begin excerpt ---
3. Check for an origin server configuration error. If the HTTP
response message generated in step 2 contains an Alternates
header, a Content-Location header, or has the 300 status code,
^^^^^^^^^^^^^^^^
then the best variant resource is not a proper end point in
the negotiation process, and a 506 (Variant Also Negotiates)
error response message should be generated instead of going to
step 4.
--- end excerpt ---
This seems slightly too restrictive. Suggestion: change to "[...],
a non-matching Content-Location header, [...]", and add:
"A Content-Location header is non-matching if the location given
by its value, after resolution according to the HTTP/1.1 specification
in the case of a relative URI, does not match (in the sense of the
HTTP/1.1 specification, 3.2.3) the chosen variant's location.
Remove any existing Content-Location header."
Reason: RFC 2068 describes several uses of Content-Location outside of
content negotiation (even with a SHOULD in 14.15). Use of this header
should not be discouraged by the negotiation draft if it doesn't
create any conflict (i.e. if the variant "knows" its own correct
location, this should be ok). After all a Vary header *is* allowed
here, and Content-Location together with Vary may help caching in some
cases if there are any non-negotiating proxies between a proxy implementing
this algorithm and the origin server.
Btw, RFC 2068 3.5.2 completely forbids modification of Content-Location
or Etag headers by "A cache or non-caching proxy". Can a proxy implement
section 10.2 of the negotiation draft and still be HTTP/1.1 compliant?
(Maybe that part of the HTTP spec needs to be amended.)
10/
Change the note under 10.2, 4.a. to
--- begin excerpt ---
Note: According to the HTTP/1.1 specification [1], if
the Content-Location header contains a relative URI,
this URI is relative to the URI in the Content-Base
header, if present, and relative to the Request-URI
if no Content-Base header is present.
--- end excerpt ---
11/
In 10.5, 2nd paragraph:
--- begin excerpt ---
[...] This
caching of extracted responses can increase overall efficiency with
up to a factor 2.
--- end excerpt ---
How is this number derived, and what does it mean?
(I.e. how is "overall efficiency" measured?)
12/
Add part in parentheses to last paragraph of 10.8:
--- begin excerpt ---
Like HTTP/1.1, this specification allows proxies to encode or
decode relayed or cached responses on the fly (unless explicitly
forbidden by a Cache-Control directive): [...]
--- end excerpt ---
13/
--- begin excerpt ---
|11 User agent support for transparent negotiation
[...] If the user agent
| contains an internal cache, this cache must satisfy the
| requirements for proxy caches in section 13.
--- end excerpt ---
However, section 13 doesn't list any requirements.
14/
In section 12.1, second paragraph:
--- begin excerpt ---
| [...] The origin server must never return a response
| with a 2xx status code or any 3xx status code, except 304, which is
| not a list, choice, or ad hoc response.
--- end excerpt ---
Add to end of that sentence:
", if the request was for a negotiable resource".
15/
At end of 12.2:
--- begin excerpt ---
See the HTTP/1.1 specification [1] for details on the 303 (See
Other) response code. Note that this response code is not
understood by most HTTP/1.0 clients. ^^^^^^
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
--- end excerpt ---
Is that really the case? I know of problems with 300, but not with 303.
Most clients treat 301 and 302 responses to POST requests like 303 responses
(to the point that so many Web pages rely on this "feature" that 301 and 302
responses will probably never be usable as intended...). I they would
at least treat 303 the same way.
16/
--- begin excerpt ---
|13 Proxy support for transparent negotiation
|
| Transparent content negotiation is designed to work through any
| proxy which only implements the HTTP/1.1 specification [1]. If
| Expires headers are added as discussed in section 10.7, negotiation
| will also work though HTTP/1.0 proxies. Thus, in a sense, every
| HTTP proxy supports transparent content negotiation.
Plain HTTP/1.1 allows proxies to cache list, choice, and ad hoc
responses, and to efficiently revalidate them by using the
If-None-Match header. This specification defines additional
optimization mechanisms.
--- end excerpt ---
[Are the next three paragraphs meant as a listing of the additional
mechanisms, or a listing of old and new mechanisms? This should be
made clearer.]
--- begin excerpt ---
| First, when getting a request on a transparently negotiable
| resource from a user agent which is capable of transparent content
| negotiation (from a user agent which sends a Negotiate header), the
| proxy may return a cached, fresh list response from that resource.
--- end excerpt ---
This is what a proxy that is not aware of t.c.n. would do,
if it happens to hold in its cache a cachable 300 response, right?
So it is not really a new mechanism.
--- begin excerpt ---
| Second, when allowed by the user agent and origin server, a proxy
| may reuse an Alternates header taken from a previous response
| (section 10.4) to run a remote variant selection algorithm. If the
| algorithm has sufficient information to choose a best variant, the
| origin server may return a choice response with this variant.
^^^^^^^^^^^^^
--- end excerpt ---
I assume that should be "proxy"?
--- end excerpt ---
| Third, if a proxy receives a choice response, it may extract and
| cache the normal response embedded therein, as described in section
| 10.5.
--- end excerpt ---
Section 13 should include a part similar to 12.1 (maybe just a copy from
there, with appropriate modifications). It should also list some
requirements, especially what a proxy (which understands t.c.n.) MUST
or SHOULD not do. For example: A proxy forwarding a request MUST NOT
add or change a Negotiate header (Is this always true?). A proxy MUST
NOT choose a variant on behalf of the user agent unless specifically
allowed by a Negotiate header (and not forbidden by an Alternates header's
proxy-rvsa directive).
That's all for now...
Klaus
P.S. Koen, it would be nice if you could make gewis.win.tue.nl
return a more appropriate Content-Type than text/plain for
<URL:http://gewis.win.tue.nl/~koen/conneg/conneg-uax-v1.1.tar.gz>...
Received on Monday, 17 February 1997 22:29:38 UTC