- From: Klaus Weide <kweide@tezcat.com>
- Date: Thu, 20 Feb 1997 18:33:38 -0600 (CST)
- To: Koen Holtman <koen@win.tue.nl>
- Cc: http-wg@cuckoo.hpl.hp.com
On Wed, 19 Feb 1997, Koen Holtman wrote:
> Klaus Weide:
> >
> >16/
> >--- begin excerpt ---
> >|13 Proxy support for transparent negotiation
> >|
> >
> >Section 13 should include a part similar to 12.1 (maybe just a copy from
> >there, with appropriate modifications).
>
> I did copy some parts (and made a cut-and-paste error). Which parts
> do you think I should copy in addition? I'm not aware of any
> omissions.
Most of the requirements may already be there scattered in other
sections, but it would be nice to have them summarized here (parallel
to 12.1).
I am just taking a copy of 12.1 here, changing and annotating it,
to give an idea what I meant:
|13.1 Requirements for proxies [and caches?]
To implement transparent negotiation [a.k.a. `support t.c.n.',
a.k.a. `be compliant with this specification'?] on a resource, a proxy
must be able to [?????] when getting a GET
request on the resource. It should also be able to [?????]
for HEAD requests. A list response must
always be sent [or the request be forwarded to the origin server?]
if the request includes a Negotiate header with only
a "trans" directive. If the Negotiate header allows it, the proxy
may run a remote variant selection algorithm, and if the
algorithm has sufficient information to choose a best variant, the
proxy may return a choice response with this variant.
When getting a request without a Negotiate header indicating
support for transparent content negotiation, the proxy MUST
forward the request towards the origin server
[or reply from its cache if allowed by HTTP/1.1 rules, Vary etc.?]
[and must forward the response towards the client without any other
changes than those allowed by HTTP/1.1?]
Negotiability is a binary property: a resource is either
transparently negotiated, or it is not. A proxy MUST determine
whether a resource is transparently negotiated or not by the presence
of an Alternates header, and [do the stuff that is allowed by this
draft but otherwise forbidden by HTTP/1.1 only if a resource is
transparently negotiated.]
Proxies and caches implementing this spec MUST recognize and obey
all [some?] cache-control directives defined by HTTP/1.1, even if
they are not otherwise HTTP/1.1 conformant [i.e. claim only
HTTP/1.0 version in messages]. [thinking about this sentence
from the Introduction: "However, use of
this extension does not require use of HTTP/1.1: transparent
content negotiation can also be done if some or all of the parties
are HTTP/1.0 [3] systems."]
Add whatever is missing, "First" and "Third" from the present section 13 etc.
Klaus
Received on Thursday, 20 February 1997 16:34:41 UTC