- From: Roy T. Fielding <fielding@avron.ICS.UCI.EDU>
- Date: Mon, 01 Apr 1996 21:20:08 -0800
- To: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
This message reflects my understanding of consensus on the Via header
field as a replacement for the Forwarded header field present in draft 01.
===================================================================
10.xx Via
The Via general-header field must be 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
protocol-name = token
protocol-version = token
received-by = ( host [ ":" port ] ) | pseudonym )
pseudonym = token
The received-protocol indicates the protocol version of the message
received by the server or client along each segment of the
request/response chain. The received-protocol version is appended to
the Via field value when the message is forwarded so that information
about the protocol capabilities of upstream applications remains
visible to all recipients.
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. If the port is not given, it may
be assumed to be the default port of the received-protocol.
Multiple Via field values 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 the names and ports of 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.
For organizations that have strong privacy requirements for hiding
internal structures, a proxy may combine an ordered subsequence of
Via header field entries with identical received-protocol values into
a single such entry. For example,
Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy
could be collapsed to
Via: 1.0 ricky, 1.1 mertz, 1.0 lucy
Applications should not combine multiple entries unless they are all
under the same organizational control and the hosts have already been
replaced by pseudoynms. Applications must not combine entries which
have different received-protocol values.
Note: The Via header field replaces the Forwarded header field
which was present in earlier drafts of this specification.
===================================================================
Plus these additional changes in context:
*** draft-ietf-http-v11-spec-01.txt Mon Feb 12 16:37:14 1996
--- ttt Mon Apr 1 20:36:56 1996
***************
*** 1491,1501 ****
General-Header = Cache-Control ; Section 10.8
| Connection ; Section 10.9
| Date ; Section 10.17
- | Forwarded ; Section 10.20
| Keep-Alive ; Section 10.24
| MIME-Version ; Section 10.28
| Pragma ; Section 10.29
| Upgrade ; Section 10.41
General header field names can be extended reliably only in
combination with a change in the protocol version. However, new or
--- 1491,1501 ----
General-Header = Cache-Control ; Section 10.8
| Connection ; Section 10.9
| Date ; Section 10.17
| Keep-Alive ; Section 10.24
| MIME-Version ; Section 10.28
| Pragma ; Section 10.29
| Upgrade ; Section 10.41
+ | Via ; Section 10.xx
General header field names can be extended reliably only in
combination with a change in the protocol version. However, new or
***************
*** 3636,3668 ****
- 10.20 Forwarded
-
- The Forwarded general-header field is to be used by gateways and
- proxies to indicate the intermediate steps 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 tracing transport problems
- and avoiding request loops.
-
- Forwarded = "Forwarded" ":" #( "by" URI [ "(" product ")" ]
- [ "for" FQDN ] )
-
- FQDN = <Fully-Qualified Domain Name>
-
- For example, a message could be sent from a client on
- ptsun00.cern.ch to a server at www.ics.uci.edu port 80, via an
- intermediate HTTP proxy at info.cern.ch port 8000. The request
- received by the server at www.ics.uci.edu would then have the
- following Forwarded header field:
-
- Forwarded: by http://info.cern.ch:8000/ for ptsun00.cern.ch
-
- Multiple Forwarded header fields are allowed and should represent
- each proxy/gateway that has forwarded the message. It is strongly
- recommended that proxies/gateways used as a portal through a
- network firewall do not, by default, send out information about the
- internal hosts within the firewall region. This information should
- only be propagated if explicitly enabled. If not enabled, the for
- token and FQDN should not be included in the field value, and any
- Forwarded headers already present in the message (those added
- behind the firewall) should be removed.
-
--- 3636,3637 ----
***************
*** 4060,4066 ****
If the response is being forwarded through a proxy, the proxy
application must not add its data to the product list. Instead, it
! should include a Forwarded field (as described in Section 10.20).
Note: Revealing the specific software version of the server
may allow the server machine to become more vulnerable to
--- 4032,4038 ----
If the response is being forwarded through a proxy, the proxy
application must not add its data to the product list. Instead, it
! should include a Via field (as described in Section 10.xx).
Note: Revealing the specific software version of the server
may allow the server machine to become more vulnerable to
***************
*** 4232,4237 ****
--- 4204,4213 ----
User-Agent: CERN-LineMode/2.15 libwww/2.17b3
+ 10.xx Via
+
+ [new section above]
+
10.44 WWW-Authenticate
The WWW-Authenticate response-header field must be included in 401
***************
*** 4604,4610 ****
information within the context of any given request. Therefore,
applications should supply as much control over this information as
possible to the provider of that information. Four header fields
! are worth special mention in this context: Server, Forwarded,
! Referer and From.
Revealing the specific software version of the server may allow the
--- 4580,4586 ----
information within the context of any given request. Therefore,
applications should supply as much control over this information as
possible to the provider of that information. Four header fields
! are worth special mention in this context: Server, Via, Referer and
! From.
Revealing the specific software version of the server may allow the
***************
*** 4615,4622 ****
Proxies which serve as a portal through a network firewall should
take special precautions regarding the transfer of header
information that identifies the hosts behind the firewall. In
! particular, they should remove, or replace with sanitized versions,
! any Forwarded fields generated behind the firewall.
The Referer field allows reading patterns to be studied and reverse
links drawn. Although it can be very useful, its power can be
--- 4591,4598 ----
Proxies which serve as a portal through a network firewall should
take special precautions regarding the transfer of header
information that identifies the hosts behind the firewall. In
! particular, they should replace any Via fields generated behind the
! firewall with sanitized versions, as described in Section 10.xx.
The Referer field allows reading patterns to be studied and reverse
links drawn. Although it can be very useful, its power can be
=========================================================================
...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/
Received on Monday, 1 April 1996 22:01:31 UTC