Ignore:
Timestamp:
09/06/13 06:05:43 (10 years ago)
Author:
fielding@…
Message:

Remove the requirement that gateways must generate Via in responses; clarify why the received-protocol values are important for protocol versioning; remove redundant (and insufficient) requirements from gateway intro; addresses #460

Location:
draft-ietf-httpbis/latest
Files:
2 edited

Legend:

Unmodified
Added
Removed

  • draft-ietf-httpbis/latest/p1-messaging.html

    r2285 r2286  
    899899      <p id="rfc.section.2.3.p.8">All HTTP requirements applicable to an origin server also apply to the outbound communication of a gateway. A gateway communicates
    900900         with inbound servers using any protocol that it desires, including private extensions to HTTP that are outside the scope of
    901          this specification. However, an HTTP-to-HTTP gateway that wishes to interoperate with third-party HTTP servers <em class="bcp14">MUST</em> conform to HTTP user agent requirements on the gateway's inbound connection and <em class="bcp14">MUST</em> implement the <a href="#header.connection" class="smpl">Connection</a> (<a href="#header.connection" id="rfc.xref.header.connection.1" title="Connection">Section&nbsp;6.1</a>) and <a href="#header.via" class="smpl">Via</a> (<a href="#header.via" id="rfc.xref.header.via.1" title="Via">Section&nbsp;5.7.1</a>) header fields for both inbound and outbound connections.
     901         this specification. However, an HTTP-to-HTTP gateway that wishes to interoperate with third-party HTTP servers ought to conform
     902         to user agent requirements on the gateway's inbound connection.
    902903      </p>
    903904      <p id="rfc.section.2.3.p.9"><span id="rfc.iref.t.2"></span> A "<dfn>tunnel</dfn>" acts as a blind relay between two connections without changing the messages. Once active, a tunnel is not considered a party
    … …  
    988989      <p id="rfc.section.2.6.p.7">New header fields can be defined such that, when they are understood by a recipient, they might override or enhance the interpretation
    989990         of previously defined header fields. When an implementation receives an unrecognized header field, the recipient <em class="bcp14">MUST</em> ignore that header field for local processing regardless of the message's HTTP version. An unrecognized header field received
    990          by a proxy <em class="bcp14">MUST</em> be forwarded downstream unless the header field's field-name is listed in the message's <a href="#header.connection" class="smpl">Connection</a> header field (see <a href="#header.connection" id="rfc.xref.header.connection.2" title="Connection">Section&nbsp;6.1</a>). These requirements allow HTTP's functionality to be enhanced without requiring prior update of deployed intermediaries.
     991         by a proxy <em class="bcp14">MUST</em> be forwarded downstream unless the header field's field-name is listed in the message's <a href="#header.connection" class="smpl">Connection</a> header field (see <a href="#header.connection" id="rfc.xref.header.connection.1" title="Connection">Section&nbsp;6.1</a>). These requirements allow HTTP's functionality to be enhanced without requiring prior update of deployed intermediaries.
    991992      </p>
    992993      <p id="rfc.section.2.6.p.8">Intermediaries that process HTTP messages (i.e., all intermediaries other than those acting as tunnels) <em class="bcp14">MUST</em> send their own HTTP-version in forwarded messages. In other words, they <em class="bcp14">MUST NOT</em> blindly forward the first line of an HTTP message without ensuring that the protocol version in that message matches a version
    … …  
    11071108         the algorithm defined in <a href="#RFC3986" id="rfc.xref.RFC3986.15"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-6">Section 6</a>, using the defaults described above for each scheme.
    11081109      </p>
    1109       <p id="rfc.section.2.7.3.p.2">If the port is equal to the default port for a scheme, the normal form is to elide the port subcomponent. When not being used
     1110      <p id="rfc.section.2.7.3.p.2">If the port is equal to the default port for a scheme, the normal form is to omit the port subcomponent. When not being used
    11101111         in absolute form as the request target of an OPTIONS request, an empty path component is equivalent to an absolute path of
    11111112         "/", so the normal form is to provide a path of "/" instead. The scheme and host are case-insensitive and normally provided
    … …  
    12251226         the protocol version if their defined semantics allow them to be safely ignored by recipients that do not recognize them.
    12261227      </p>
    1227       <p id="rfc.section.3.2.1.p.2">New HTTP header fields ought to be registered with IANA in the Message Header Field Registry, as described in <a href="p2-semantics.html#header.field.registry" title="Header Field Registry">Section 8.3</a> of <a href="#Part2" id="rfc.xref.Part2.10"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>. A proxy <em class="bcp14">MUST</em> forward unrecognized header fields unless the field-name is listed in the <a href="#header.connection" class="smpl">Connection</a> header field (<a href="#header.connection" id="rfc.xref.header.connection.3" title="Connection">Section&nbsp;6.1</a>) or the proxy is specifically configured to block, or otherwise transform, such fields. Other recipients <em class="bcp14">SHOULD</em> ignore unrecognized header fields.
     1228      <p id="rfc.section.3.2.1.p.2">New HTTP header fields ought to be registered with IANA in the Message Header Field Registry, as described in <a href="p2-semantics.html#header.field.registry" title="Header Field Registry">Section 8.3</a> of <a href="#Part2" id="rfc.xref.Part2.10"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>. A proxy <em class="bcp14">MUST</em> forward unrecognized header fields unless the field-name is listed in the <a href="#header.connection" class="smpl">Connection</a> header field (<a href="#header.connection" id="rfc.xref.header.connection.2" title="Connection">Section&nbsp;6.1</a>) or the proxy is specifically configured to block, or otherwise transform, such fields. Other recipients <em class="bcp14">SHOULD</em> ignore unrecognized header fields.
    12281229      </p>
    12291230      <h3 id="rfc.section.3.2.2"><a href="#rfc.section.3.2.2">3.2.2</a>&nbsp;<a id="field.order" href="#field.order">Field Order</a></h3>
    … …  
    16911692         no transfer coding is always acceptable.
    16921693      </p>
    1693       <p id="rfc.section.4.3.p.9">Since the TE header field only applies to the immediate connection, a sender of TE <em class="bcp14">MUST</em> also send a "TE" connection option within the <a href="#header.connection" class="smpl">Connection</a> header field (<a href="#header.connection" id="rfc.xref.header.connection.4" title="Connection">Section&nbsp;6.1</a>) in order to prevent the TE field from being forwarded by intermediaries that do not support its semantics.
     1694      <p id="rfc.section.4.3.p.9">Since the TE header field only applies to the immediate connection, a sender of TE <em class="bcp14">MUST</em> also send a "TE" connection option within the <a href="#header.connection" class="smpl">Connection</a> header field (<a href="#header.connection" id="rfc.xref.header.connection.3" title="Connection">Section&nbsp;6.1</a>) in order to prevent the TE field from being forwarded by intermediaries that do not support its semantics.
    16941695      </p>
    16951696      <h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a>&nbsp;<a id="message.routing" href="#message.routing">Message Routing</a></h1>
    … …  
    18711872         enhance (or interfere) with either direction of the stream.
    18721873      </p>
    1873       <p id="rfc.section.5.7.p.2">Intermediaries that forward a message <em class="bcp14">MUST</em> implement the <a href="#header.connection" class="smpl">Connection</a> header field, as specified in <a href="#header.connection" id="rfc.xref.header.connection.5" title="Connection">Section&nbsp;6.1</a>, to exclude fields that are only intended for the incoming connection.
     1874      <p id="rfc.section.5.7.p.2">Intermediaries that forward a message <em class="bcp14">MUST</em> implement the <a href="#header.connection" class="smpl">Connection</a> header field, as specified in <a href="#header.connection" id="rfc.xref.header.connection.4" title="Connection">Section&nbsp;6.1</a>, to exclude fields that are only intended for the incoming connection.
    18741875      </p>
    18751876      <p id="rfc.section.5.7.p.3">In order to avoid request loops, a proxy that forwards requests to other proxies <em class="bcp14">MUST</em> be able to recognize and exclude all of its own server names, including any aliases, local variations, or literal IP addresses.
    … …  
    18771878      <div id="rfc.iref.v.1"></div>
    18781879      <h3 id="rfc.section.5.7.1"><a href="#rfc.section.5.7.1">5.7.1</a>&nbsp;<a id="header.via" href="#header.via">Via</a></h3>
    1879       <p id="rfc.section.5.7.1.p.1">The "Via" header field <em class="bcp14">MUST</em> be sent by a proxy or gateway in forwarded messages to indicate the intermediate protocols and recipients between the user
    1880          agent and the server on requests, and between the origin server and the client on responses. It is analogous to the "Received"
    1881          field used by email systems (<a href="http://tools.ietf.org/html/rfc5322#section-3.6.7">Section 3.6.7</a> of <a href="#RFC5322" id="rfc.xref.RFC5322.3"><cite title="Internet Message Format">[RFC5322]</cite></a>). Via is used in HTTP for tracking message forwards, avoiding request loops, and identifying the protocol capabilities of
    1882          all senders along the request/response chain.
    1883       </p>
    1884       <div id="rfc.figure.u.51"></div><pre class="inline"><span id="rfc.iref.g.87"></span><span id="rfc.iref.g.88"></span><span id="rfc.iref.g.89"></span><span id="rfc.iref.g.90"></span><span id="rfc.iref.g.91"></span><span id="rfc.iref.g.92"></span>  <a href="#header.via" class="smpl">Via</a>               = 1#( <a href="#header.via" class="smpl">received-protocol</a> <a href="#rule.whitespace" class="smpl">RWS</a> <a href="#header.via" class="smpl">received-by</a>
    1885                           [ <a href="#rule.whitespace" class="smpl">RWS</a> <a href="#rule.comment" class="smpl">comment</a> ] )
     1880      <p id="rfc.section.5.7.1.p.1">The "Via" header field indicates the presence of intermediate protocols and recipients between the user agent and the server
     1881         (on requests) or between the origin server and the client (on responses), similar to the "Received" header field in email
     1882         (<a href="http://tools.ietf.org/html/rfc5322#section-3.6.7">Section 3.6.7</a> of <a href="#RFC5322" id="rfc.xref.RFC5322.3"><cite title="Internet Message Format">[RFC5322]</cite></a>). Via can be used for tracking message forwards, avoiding request loops, and identifying the protocol capabilities of senders
     1883         along the request/response chain.
     1884      </p>
     1885      <div id="rfc.figure.u.51"></div><pre class="inline"><span id="rfc.iref.g.87"></span><span id="rfc.iref.g.88"></span><span id="rfc.iref.g.89"></span><span id="rfc.iref.g.90"></span><span id="rfc.iref.g.91"></span><span id="rfc.iref.g.92"></span>  <a href="#header.via" class="smpl">Via</a> = 1#( <a href="#header.via" class="smpl">received-protocol</a> <a href="#rule.whitespace" class="smpl">RWS</a> <a href="#header.via" class="smpl">received-by</a> [ <a href="#rule.whitespace" class="smpl">RWS</a> <a href="#rule.comment" class="smpl">comment</a> ] )
     1886
    18861887  <a href="#header.via" class="smpl">received-protocol</a> = [ <a href="#header.upgrade" class="smpl">protocol-name</a> "/" ] <a href="#header.upgrade" class="smpl">protocol-version</a>
    18871888                      ; see <a href="#header.upgrade" id="rfc.xref.header.upgrade.1" title="Upgrade">Section&nbsp;6.7</a>
    18881889  <a href="#header.via" class="smpl">received-by</a>       = ( <a href="#uri" class="smpl">uri-host</a> [ ":" <a href="#uri" class="smpl">port</a> ] ) / <a href="#header.via" class="smpl">pseudonym</a>
    18891890  <a href="#header.via" class="smpl">pseudonym</a>         = <a href="#rule.token.separators" class="smpl">token</a>
    1890 </pre><p id="rfc.section.5.7.1.p.3">The received-protocol indicates the protocol version of the message received by the server or client along each segment of
    1891          the request/response chain. The received-protocol version is appended to the Via field value when the message is forwarded
    1892          so that information about the protocol capabilities of upstream applications remains visible to all recipients.
    1893       </p>
    1894       <p id="rfc.section.5.7.1.p.4">The protocol-name is excluded if and only if it would be "HTTP". The received-by field is normally the host and optional port
    1895          number of a recipient server or client that subsequently forwarded the message. However, if the real host is considered to
    1896          be sensitive information, it <em class="bcp14">MAY</em> be replaced by a pseudonym. If the port is not given, it <em class="bcp14">MAY</em> be assumed to be the default port of the received-protocol.
    1897       </p>
    1898       <p id="rfc.section.5.7.1.p.5">Multiple Via field values represent each proxy or gateway that has forwarded the message. Each recipient <em class="bcp14">MUST</em> append its information such that the end result is ordered according to the sequence of forwarding applications.
    1899       </p>
    1900       <p id="rfc.section.5.7.1.p.6">Comments <em class="bcp14">MAY</em> be used in the Via header field to identify the software of each recipient, analogous to the <a href="p2-semantics.html#header.user-agent" class="smpl">User-Agent</a> and <a href="p2-semantics.html#header.server" class="smpl">Server</a> header fields. However, all comments in the Via field are optional and <em class="bcp14">MAY</em> be removed by any recipient prior to forwarding the message.
    1901       </p>
    1902       <p id="rfc.section.5.7.1.p.7">For example, a request message could be sent from an HTTP/1.0 user agent to an internal proxy code-named "fred", which uses
     1891</pre><p id="rfc.section.5.7.1.p.3">Multiple Via field values represent each proxy or gateway that has forwarded the message. Each intermediary appends its own
     1892         information about how the message was received, such that the end result is ordered according to the sequence of forwarding
     1893         recipients.
     1894      </p>
     1895      <p id="rfc.section.5.7.1.p.4">A proxy <em class="bcp14">MUST</em> send an appropriate Via header field, as described below, in each message that it forwards. An HTTP-to-HTTP gateway <em class="bcp14">MUST</em> send an appropriate Via header field in each inbound request message and <em class="bcp14">MAY</em> send a Via header field in forwarded response messages.
     1896      </p>
     1897      <p id="rfc.section.5.7.1.p.5">For each intermediary, the received-protocol indicates the protocol and protocol version used by the upstream sender of the
     1898         message. Hence, the Via field value records the advertised protocol capabilities of the request/response chain such that they
     1899         remain visible to downstream recipients; this can be useful for determining what backwards-incompatible features might be
     1900         safe to use in response, or within a later request, as described in <a href="#http.version" title="Protocol Versioning">Section&nbsp;2.6</a>. For brevity, the protocol-name is omitted when the received protocol is HTTP.
     1901      </p>
     1902      <p id="rfc.section.5.7.1.p.6">The received-by field is normally the host and optional port number of a recipient server or client that subsequently forwarded
     1903         the message. However, if the real host is considered to be sensitive information, it <em class="bcp14">MAY</em> be replaced by a pseudonym. If the port is not given, it <em class="bcp14">MAY</em> be assumed to be the default port of the received-protocol.
     1904      </p>
     1905      <p id="rfc.section.5.7.1.p.7">Comments <em class="bcp14">MAY</em> be used in the Via header field to identify the software of each recipient, analogous to the <a href="p2-semantics.html#header.user-agent" class="smpl">User-Agent</a> and <a href="p2-semantics.html#header.server" class="smpl">Server</a> header fields. However, all comments in the Via field are optional and <em class="bcp14">MAY</em> be removed by any recipient prior to forwarding the message.
     1906      </p>
     1907      <p id="rfc.section.5.7.1.p.8">For example, a request message could be sent from an HTTP/1.0 user agent to an internal proxy code-named "fred", which uses
    19031908         HTTP/1.1 to forward the request to a public proxy at p.example.net, which completes the request by forwarding it to the origin
    19041909         server at www.example.com. The request received by www.example.com would then have the following Via header field:
    19051910      </p>
    1906       <div id="rfc.figure.u.52"></div><pre class="text">  Via: 1.0 fred, 1.1 p.example.net (Apache/1.1)
    1907 </pre><p id="rfc.section.5.7.1.p.9">A proxy or gateway used as a portal through a network firewall <em class="bcp14">SHOULD NOT</em> forward the names and ports of hosts within the firewall region unless it is explicitly enabled to do so. If not enabled,
     1911      <div id="rfc.figure.u.52"></div><pre class="text">  Via: 1.0 fred, 1.1 p.example.net
     1912</pre><p id="rfc.section.5.7.1.p.10">A proxy or gateway used as a portal through a network firewall <em class="bcp14">SHOULD NOT</em> forward the names and ports of hosts within the firewall region unless it is explicitly enabled to do so. If not enabled,
    19081913         the received-by host of any host behind the firewall <em class="bcp14">SHOULD</em> be replaced by an appropriate pseudonym for that host.
    19091914      </p>
    1910       <p id="rfc.section.5.7.1.p.10">A proxy or gateway <em class="bcp14">MAY</em> combine an ordered subsequence of Via header field entries into a single such entry if the entries have identical received-protocol
     1915      <p id="rfc.section.5.7.1.p.11">A proxy or gateway <em class="bcp14">MAY</em> combine an ordered subsequence of Via header field entries into a single such entry if the entries have identical received-protocol
    19111916         values. For example,
    19121917      </p>
    19131918      <div id="rfc.figure.u.53"></div><pre class="text">  Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy
    1914 </pre><p id="rfc.section.5.7.1.p.12">could be collapsed to</p>
     1919</pre><p id="rfc.section.5.7.1.p.13">could be collapsed to</p>
    19151920      <div id="rfc.figure.u.54"></div><pre class="text">  Via: 1.0 ricky, 1.1 mertz, 1.0 lucy
    1916 </pre><p id="rfc.section.5.7.1.p.14">Senders <em class="bcp14">SHOULD NOT</em> combine multiple entries unless they are all under the same organizational control and the hosts have already been replaced
     1921</pre><p id="rfc.section.5.7.1.p.15">Senders <em class="bcp14">SHOULD NOT</em> combine multiple entries unless they are all under the same organizational control and the hosts have already been replaced
    19171922         by pseudonyms. Senders <em class="bcp14">MUST NOT</em> combine entries that have different received-protocol values.
    19181923      </p>
    … …  
    20892094      <div id="rfc.iref.c.14"></div>
    20902095      <h2 id="rfc.section.6.6"><a href="#rfc.section.6.6">6.6</a>&nbsp;<a id="persistent.tear-down" href="#persistent.tear-down">Tear-down</a></h2>
    2091       <p id="rfc.section.6.6.p.1">The <a href="#header.connection" class="smpl">Connection</a> header field (<a href="#header.connection" id="rfc.xref.header.connection.6" title="Connection">Section&nbsp;6.1</a>) provides a "<a href="#header.connection" class="smpl">close</a>" connection option that a sender <em class="bcp14">SHOULD</em> send when it wishes to close the connection after the current request/response pair.
     2096      <p id="rfc.section.6.6.p.1">The <a href="#header.connection" class="smpl">Connection</a> header field (<a href="#header.connection" id="rfc.xref.header.connection.5" title="Connection">Section&nbsp;6.1</a>) provides a "<a href="#header.connection" class="smpl">close</a>" connection option that a sender <em class="bcp14">SHOULD</em> send when it wishes to close the connection after the current request/response pair.
    20922097      </p>
    20932098      <p id="rfc.section.6.6.p.2">A client that sends a <a href="#header.connection" class="smpl">close</a> connection option <em class="bcp14">MUST NOT</em> send further requests on that connection (after the one containing <a href="#header.connection" class="smpl">close</a>) and <em class="bcp14">MUST</em> close the connection after reading the final response message corresponding to this request.
    … …  
    21552160[... data stream switches to HTTP/2.0 with an appropriate response
    21562161(as defined by new protocol) to the "GET /hello.txt" request ...]
    2157 </pre><p id="rfc.section.6.7.p.10">When Upgrade is sent, the sender <em class="bcp14">MUST</em> also send a <a href="#header.connection" class="smpl">Connection</a> header field (<a href="#header.connection" id="rfc.xref.header.connection.7" title="Connection">Section&nbsp;6.1</a>) that contains an "upgrade" connection option, in order to prevent Upgrade from being accidentally forwarded by intermediaries
     2162</pre><p id="rfc.section.6.7.p.10">When Upgrade is sent, the sender <em class="bcp14">MUST</em> also send a <a href="#header.connection" class="smpl">Connection</a> header field (<a href="#header.connection" id="rfc.xref.header.connection.6" title="Connection">Section&nbsp;6.1</a>) that contains an "upgrade" connection option, in order to prevent Upgrade from being accidentally forwarded by intermediaries
    21582163         that might not implement the listed protocols. A server <em class="bcp14">MUST</em> ignore an Upgrade header field that is received in an HTTP/1.0 request.
    21592164      </p>
    … …  
    21892194                  <td class="left">http</td>
    21902195                  <td class="left">standard</td>
    2191                   <td class="left"> <a href="#header.connection" id="rfc.xref.header.connection.8" title="Connection">Section&nbsp;6.1</a>
     2196                  <td class="left"> <a href="#header.connection" id="rfc.xref.header.connection.7" title="Connection">Section&nbsp;6.1</a>
    21922197                  </td>
    21932198               </tr>
    … …  
    22382243                  <td class="left">http</td>
    22392244                  <td class="left">standard</td>
    2240                   <td class="left"> <a href="#header.via" id="rfc.xref.header.via.2" title="Via">Section&nbsp;5.7.1</a>
     2245                  <td class="left"> <a href="#header.via" id="rfc.xref.header.via.1" title="Via">Section&nbsp;5.7.1</a>
    22412246                  </td>
    22422247               </tr>
    … …  
    22452250      </div>
    22462251      <p id="rfc.section.7.1.p.3">Furthermore, the header field-name "Close" shall be registered as "reserved", since using that name as an HTTP header field
    2247          might conflict with the "close" connection option of the "<a href="#header.connection" class="smpl">Connection</a>" header field (<a href="#header.connection" id="rfc.xref.header.connection.9" title="Connection">Section&nbsp;6.1</a>).
     2252         might conflict with the "close" connection option of the "<a href="#header.connection" class="smpl">Connection</a>" header field (<a href="#header.connection" id="rfc.xref.header.connection.8" title="Connection">Section&nbsp;6.1</a>).
    22482253      </p>
    22492254      <div id="rfc.table.u.1">
    … …  
    29522957      <p id="rfc.section.A.2.p.25">The asterisk form of the request-target is only allowed in the OPTIONS method. (<a href="#request-target" title="Request Target">Section&nbsp;5.3</a>)
    29532958      </p>
    2954       <p id="rfc.section.A.2.p.26">Exactly when "close" connection options have to be sent has been clarified. (<a href="#header.connection" id="rfc.xref.header.connection.10" title="Connection">Section&nbsp;6.1</a>)
     2959      <p id="rfc.section.A.2.p.26">Exactly when "close" connection options have to be sent has been clarified. (<a href="#header.connection" id="rfc.xref.header.connection.9" title="Connection">Section&nbsp;6.1</a>)
    29552960      </p>
    29562961      <p id="rfc.section.A.2.p.27">"hop-by-hop" header fields are required to appear in the Connection header field; just because they're defined as hop-by-hop
    2957          in this specification doesn't exempt them. (<a href="#header.connection" id="rfc.xref.header.connection.11" title="Connection">Section&nbsp;6.1</a>)
     2962         in this specification doesn't exempt them. (<a href="#header.connection" id="rfc.xref.header.connection.10" title="Connection">Section&nbsp;6.1</a>)
    29582963      </p>
    29592964      <p id="rfc.section.A.2.p.28">The limit of two connections per server has been removed. (<a href="#persistent.connections" title="Persistence">Section&nbsp;6.3</a>)
    … …  
    32343239                  <li>chunked (Coding Format)&nbsp;&nbsp;<a href="#rfc.iref.c.6">3.3.1</a>, <a href="#rfc.iref.c.8">3.3.3</a>, <a href="#rfc.iref.c.9"><b>4.1</b></a></li>
    32353240                  <li>client&nbsp;&nbsp;<a href="#rfc.iref.c.1"><b>2.1</b></a></li>
    3236                   <li>close&nbsp;&nbsp;<a href="#rfc.xref.header.connection.1">2.3</a>, <a href="#rfc.xref.header.connection.2">2.6</a>, <a href="#rfc.xref.header.connection.3">3.2.1</a>, <a href="#rfc.xref.header.connection.4">4.3</a>, <a href="#rfc.xref.header.connection.5">5.7</a>, <a href="#rfc.iref.c.12"><b>6.1</b></a>, <a href="#rfc.xref.persistent.tear-down.1">6.1</a>, <a href="#rfc.iref.c.14">6.6</a>, <a href="#rfc.xref.header.connection.6">6.6</a>, <a href="#rfc.xref.header.connection.7">6.7</a>, <a href="#rfc.xref.header.connection.8">7.1</a>, <a href="#rfc.xref.header.connection.9">7.1</a>, <a href="#rfc.xref.header.connection.10">A.2</a>, <a href="#rfc.xref.header.connection.11">A.2</a></li>
     3241                  <li>close&nbsp;&nbsp;<a href="#rfc.xref.header.connection.1">2.6</a>, <a href="#rfc.xref.header.connection.2">3.2.1</a>, <a href="#rfc.xref.header.connection.3">4.3</a>, <a href="#rfc.xref.header.connection.4">5.7</a>, <a href="#rfc.iref.c.12"><b>6.1</b></a>, <a href="#rfc.xref.persistent.tear-down.1">6.1</a>, <a href="#rfc.iref.c.14">6.6</a>, <a href="#rfc.xref.header.connection.5">6.6</a>, <a href="#rfc.xref.header.connection.6">6.7</a>, <a href="#rfc.xref.header.connection.7">7.1</a>, <a href="#rfc.xref.header.connection.8">7.1</a>, <a href="#rfc.xref.header.connection.9">A.2</a>, <a href="#rfc.xref.header.connection.10">A.2</a></li>
    32373242                  <li>compress (Coding Format)&nbsp;&nbsp;<a href="#rfc.iref.c.10">4.2.1</a></li>
    32383243                  <li>connection&nbsp;&nbsp;<a href="#rfc.iref.c.2"><b>2.1</b></a></li>
    3239                   <li>Connection header field&nbsp;&nbsp;<a href="#rfc.xref.header.connection.1">2.3</a>, <a href="#rfc.xref.header.connection.2">2.6</a>, <a href="#rfc.xref.header.connection.3">3.2.1</a>, <a href="#rfc.xref.header.connection.4">4.3</a>, <a href="#rfc.xref.header.connection.5">5.7</a>, <a href="#rfc.iref.c.11"><b>6.1</b></a>, <a href="#rfc.xref.persistent.tear-down.1">6.1</a>, <a href="#rfc.iref.c.13">6.6</a>, <a href="#rfc.xref.header.connection.6">6.6</a>, <a href="#rfc.xref.header.connection.7">6.7</a>, <a href="#rfc.xref.header.connection.8">7.1</a>, <a href="#rfc.xref.header.connection.9">7.1</a>, <a href="#rfc.xref.header.connection.10">A.2</a>, <a href="#rfc.xref.header.connection.11">A.2</a></li>
     3244                  <li>Connection header field&nbsp;&nbsp;<a href="#rfc.xref.header.connection.1">2.6</a>, <a href="#rfc.xref.header.connection.2">3.2.1</a>, <a href="#rfc.xref.header.connection.3">4.3</a>, <a href="#rfc.xref.header.connection.4">5.7</a>, <a href="#rfc.iref.c.11"><b>6.1</b></a>, <a href="#rfc.xref.persistent.tear-down.1">6.1</a>, <a href="#rfc.iref.c.13">6.6</a>, <a href="#rfc.xref.header.connection.5">6.6</a>, <a href="#rfc.xref.header.connection.6">6.7</a>, <a href="#rfc.xref.header.connection.7">7.1</a>, <a href="#rfc.xref.header.connection.8">7.1</a>, <a href="#rfc.xref.header.connection.9">A.2</a>, <a href="#rfc.xref.header.connection.10">A.2</a></li>
    32403245                  <li>Content-Length header field&nbsp;&nbsp;<a href="#rfc.iref.c.7"><b>3.3.2</b></a>, <a href="#rfc.xref.header.content-length.1">7.1</a>, <a href="#rfc.xref.header.content-length.2">A.2</a></li>
    32413246               </ul>
    … …  
    35363541            </li>
    35373542            <li><a id="rfc.index.V" href="#rfc.index.V"><b>V</b></a><ul>
    3538                   <li>Via header field&nbsp;&nbsp;<a href="#rfc.xref.header.via.1">2.3</a>, <a href="#rfc.iref.v.1"><b>5.7.1</b></a>, <a href="#rfc.xref.header.via.2">7.1</a></li>
     3543                  <li>Via header field&nbsp;&nbsp;<a href="#rfc.iref.v.1"><b>5.7.1</b></a>, <a href="#rfc.xref.header.via.1">7.1</a></li>
    35393544               </ul>
    35403545            </li>

  • draft-ietf-httpbis/latest/p1-messaging.xml

    r2285 r2286  
    512512   it desires, including private extensions to HTTP that are outside
    513513   the scope of this specification.  However, an HTTP-to-HTTP gateway
    514    that wishes to interoperate with third-party HTTP servers &MUST;
    515    conform to HTTP user agent requirements on the gateway's inbound
    516    connection and &MUST; implement the <x:ref>Connection</x:ref>
    517    (<xref target="header.connection"/>) and <x:ref>Via</x:ref>
    518    (<xref target="header.via"/>) header fields for both inbound and outbound
    519    connections.
     514   that wishes to interoperate with third-party HTTP servers ought to conform
     515   to user agent requirements on the gateway's inbound connection.
    520516</t>
    521517<t><iref primary="true" item="tunnel"/>
    … …  
    965961<t>
    966962   If the port is equal to the default port for a scheme, the normal form is
    967    to elide the port subcomponent. When not being used in absolute form as the
     963   to omit the port subcomponent. When not being used in absolute form as the
    968964   request target of an OPTIONS request, an empty path component is equivalent
    969965   to an absolute path of "/", so the normal form is to provide a path of "/"
    … …  
    25722568  <x:anchor-alias value="Via"/>
    25732569<t>
    2574    The "Via" header field &MUST; be sent by a proxy or gateway in forwarded
    2575    messages to indicate the intermediate protocols and recipients between the
    2576    user agent and the server on requests, and between the origin server and
    2577    the client on responses. It is analogous to the "Received" field
    2578    used by email systems (<xref target="RFC5322" x:fmt="of" x:sec="3.6.7"/>).
    2579    Via is used in HTTP for tracking message forwards,
     2570   The "Via" header field indicates the presence of intermediate protocols and
     2571   recipients between the user agent and the server (on requests) or between
     2572   the origin server and the client (on responses), similar to the
     2573   "Received" header field in email
     2574   (<xref target="RFC5322" x:fmt="of" x:sec="3.6.7"/>).
     2575   Via can be used for tracking message forwards,
    25802576   avoiding request loops, and identifying the protocol capabilities of
    2581    all senders along the request/response chain.
     2577   senders along the request/response chain.
    25822578</t>
    25832579<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Via"/><iref primary="true" item="Grammar" subitem="received-protocol"/><iref primary="true" item="Grammar" subitem="protocol-name"/><iref primary="true" item="Grammar" subitem="protocol-version"/><iref primary="true" item="Grammar" subitem="received-by"/><iref primary="true" item="Grammar" subitem="pseudonym"/>
    2584   <x:ref>Via</x:ref>               = 1#( <x:ref>received-protocol</x:ref> <x:ref>RWS</x:ref> <x:ref>received-by</x:ref>
    2585                           [ <x:ref>RWS</x:ref> <x:ref>comment</x:ref> ] )
     2580  <x:ref>Via</x:ref> = 1#( <x:ref>received-protocol</x:ref> <x:ref>RWS</x:ref> <x:ref>received-by</x:ref> [ <x:ref>RWS</x:ref> <x:ref>comment</x:ref> ] )
     2581
    25862582  <x:ref>received-protocol</x:ref> = [ <x:ref>protocol-name</x:ref> "/" ] <x:ref>protocol-version</x:ref>
    25872583                      ; see <xref target="header.upgrade"/>
    … …  
    25902586</artwork></figure>
    25912587<t>
    2592    The received-protocol indicates the protocol version of the message
    2593    received by the server or client along each segment of the
    2594    request/response chain. The received-protocol version is appended to
    2595    the Via field value when the message is forwarded so that information
    2596    about the protocol capabilities of upstream applications remains
    2597    visible to all recipients.
    2598 </t>
    2599 <t>
    2600    The protocol-name is excluded if and only if it would be "HTTP". The
    2601    received-by field is normally the host and optional port number of a
     2588   Multiple Via field values represent each proxy or gateway that has
     2589   forwarded the message. Each intermediary appends its own information
     2590   about how the message was received, such that the end result is ordered
     2591   according to the sequence of forwarding recipients.
     2592</t>
     2593<t>
     2594   A proxy &MUST; send an appropriate Via header field, as described below, in
     2595   each message that it forwards.
     2596   An HTTP-to-HTTP gateway &MUST; send an appropriate Via header field in
     2597   each inbound request message and &MAY; send a Via header field in
     2598   forwarded response messages.
     2599</t>
     2600<t>
     2601   For each intermediary, the received-protocol indicates the protocol and
     2602   protocol version used by the upstream sender of the message. Hence, the
     2603   Via field value records the advertised protocol capabilities of the
     2604   request/response chain such that they remain visible to downstream
     2605   recipients; this can be useful for determining what backwards-incompatible
     2606   features might be safe to use in response, or within a later request, as
     2607   described in <xref target="http.version"/>. For brevity, the protocol-name
     2608   is omitted when the received protocol is HTTP.
     2609</t>
     2610<t>
     2611   The received-by field is normally the host and optional port number of a
    26022612   recipient server or client that subsequently forwarded the message.
    2603    However, if the real host is considered to be sensitive information,
    2604    it &MAY; be replaced by a pseudonym. If the port is not given, it &MAY;
    2605    be assumed to be the default port of the received-protocol.
    2606 </t>
    2607 <t>
    2608    Multiple Via field values represent each proxy or gateway that has
    2609    forwarded the message. Each recipient &MUST; append its information
    2610    such that the end result is ordered according to the sequence of
    2611    forwarding applications.
     2613   However, if the real host is considered to be sensitive information, it
     2614   &MAY; be replaced by a pseudonym. If the port is not given, it &MAY; be
     2615   assumed to be the default port of the received-protocol.
    26122616</t>
    26132617<t>
    … …  
    26272631</t>
    26282632<figure><artwork type="example">
    2629   Via: 1.0 fred, 1.1 p.example.net (Apache/1.1)
     2633  Via: 1.0 fred, 1.1 p.example.net
    26302634</artwork></figure>
    26312635<t>
Note: See TracChangeset for help on using the changeset viewer.