Re: "end-to-end" headers in HTTP/1.1 [was Re: Mandatory]

From: Ted Hardie (hardie@thornhill.arc.nasa.gov)
Date: Thu, Apr 16 1998


Message-Id: <3.0.5.32.19980416172627.00967770@localhost>
Date: Thu, 16 Apr 1998 17:26:27 +0900
To: ietf-http-ext@w3.org
From: hardie@thornhill.arc.nasa.gov (Ted Hardie) (by way of Henrik Frystyk Nielsen <frystyk@w3.org>)
Subject: Re: "end-to-end" headers in HTTP/1.1 [was Re: Mandatory]

(Henrik writes)
> The above examples are all cases of "smart" proxies performing an operation
> on behalf on somebody else, either because it has an out-of-band agreement
> or because it is explicitly allowed to do this within HTTP. The operation
> can involve one or more header fields but does not have to included the
> whole message.
> 
> Looking at deployed applications and how people are using HTTP, we can't
> change the policy now and not allow this behavior - it has been there all
> along. The current wording in the Mandatory draft reflects this use of the
> term end-to-end.

I think the key term in what you write here is "out of band"
agreements; in the previous uses, the end user had some out-of-band
way to know how the proxies in the chain would behave.  As is pretty
obvious, that doesn't scale very well, and it doesn't allow anyone
to change the behavior on the fly.  Mandatory gives us a chance
to create an in-band method for providing that infomration.  The
requirements are different for in-band methods, though, than out
of band methods.  Some method of indicating that a Mandatory
header is meant to be consumed by a specific proxy or class
of proxies seems to me to be part of that.  Minimally, that
would help deal with situations where a header meant to be
consumed by a proxy isn't.

			regards,
				Ted Hardie
				NASA NIC