Koen asked:
> Upgraded-From: HTTP/1.0, HTTP/1.1
>
> With this header, my detectability requirements are met. Roy, is this
> header acceptable to you?
Jeff and I talked about this concept during the LA IETF. I think that
it belongs in the Forwarded header. It was also pointed out (by JimG)
that the Forwarded header as currently defined has too many unnecessary
bytes, so we thought about coming up with a more compact encoding.
How about this as a complete replacement for the current Forwarded?
===================================================================
10.xx Via
The Via general-header field is used by gateways and proxies to
indicate the intermediate protocols and recipients between the user
agent and the server on requests, and between the origin server and
the client on responses. It is analogous to the "Received" field of
RFC 822 [9] and is intended to be used for tracking message forwards,
avoiding request loops, and identifying the protocol capabilities of
all senders along the request/response chain.
Via = "Via" ":" 1#( received-protocol received-by [ comment ] )
received-protocol = [ protocol-name "/" ] protocol-version
received-by = ( host [ ":" port ] ) | pseudonym )
pseudonym = token
The protocol-name is optional if and only if it would be "HTTP". The
received-by field is normally the host and optional port number of
a recipient server or client that subsequently forwarded the message.
However, if the real host is considered to be sensitive information,
it may be replaced by a pseudonym.
Multiple Via field values are allowed and represent each proxy or
gateway that has forwarded the message. Each recipient must append
their information such that the end result is ordered according to
the sequence of forwarding applications.
Comments may be used in the Via header field to identify the software
of the recipient proxy or gateway, analogous to the User-Agent and
Server header fields. However, all comments in the Via field are
optional and may be removed by any recipient prior to forwarding the
message.
For example, a request message could be sent from an HTTP/1.0 user
agent to an internal proxy code-named "fred", which uses HTTP/1.1
to forward the request to a public proxy at nowhere.com, which
completes the request by forwarding it to the origin server at
www.ics.uci.edu. The request received by www.ics.uci.edu would then
have the following Via header field:
Via: 1.0 fred, 1.1 nowhere.com (Apache/1.1)
Proxies and gateways used as a portal through a network firewall
should not, by default, forward information about the internal hosts
within the firewall region. This information should only be
propagated if explicitly enabled. If not enabled, the received-by
host of any host behind the firewall should be replaced by an
appropriate pseudonym for that host.
Note: The Via header field replaces the Forwarded header field
which was present in earlier drafts of this protocol.
===================================================================
...Roy T. Fielding
Department of Information & Computer Science (fielding@ics.uci.edu)
University of California, Irvine, CA 92717-3425 fax:+1(714)824-4056
http://www.ics.uci.edu/~fielding/