- From: Dan Connolly <connolly@w3.org>
- Date: Thu, 13 Feb 1997 13:30:49 -0600
- To: Koen Holtman <koen@win.tue.nl>
- Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Koen Holtman wrote:
> Dan Connolly:
> >Protocol-Info, on the other hand, is an entity header: it applies
> >to resources, either those explicitly named using the "for" syntax,
> Doesn't protocol-info apply to a single hop in the connection, not to the
> resource on the origin server, when {scope conn} is used?
Nope. Perhaps this illustration will explain:
Protocol: {foo}
means "Dear origin server(client) of this transaction,
This message is extended per the 'foo' extension"
C-Protocol: {bar }
means
"Dear party at the end of the tcp connection,
This message is extended per the 'bar' extension."
whereas
Protocol-Info: {baz for=xyz {scope conn} {str req}}
means
"To whom it may concern,
When accessing the xyz resource, you MUST use the baz
hop-by-hop extension."
Now that I think about it, {scope conn} might not be necessary:
that information might be defined by the extension itself;
e.g.
Protocol-Info: {baz for=xyz {str req}}
means
"To whom it may concern,
When accessing the xyz resource, you MUST use the baz
extension (and if you know what baz is, you'll know
that it's a hop-by-hop extension)."
> I think using C-protocol-info in stead of Protocol-info: .. {scope conn} ..
> may make some things easier for proxies and for 1.0 compatibility.
I don't follow. Could you illustrate with an example?
>Wouldn't
> proxies have to strip off the hop-only protocol info when relaying the
> message to the next hop?
Nope. There isn't any 'hop-only protocol info.'
The stuff in the Protocol-Info header might as well be
multicast to the whole planet and written on the moon. It's
a claim about a resource (specifically, about access to that
resource), not about any particular message or
transaction.
Dan
Received on Thursday, 13 February 1997 11:38:07 UTC