W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > January to April 1996

Re: Via Header Field (replaces Forwarded)

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
Message-Id: <9604012120.aa01204@paris.ics.uci.edu>
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 EST

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:31:49 EDT