Changeset 2286 for draft-ietf-httpbis/latest
- Timestamp:
- 09/06/13 06:05:43 (10 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 2 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.html
r2285 r2286 899 899 <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 900 900 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 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 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. 902 903 </p> 903 904 <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 … … 988 989 <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 989 990 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 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 6.1</a>). These requirements allow HTTP's functionality to be enhanced without requiring prior update of deployed intermediaries. 991 992 </p> 992 993 <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 … … 1107 1108 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. 1108 1109 </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 elidethe port subcomponent. When not being used1110 <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 1110 1111 in absolute form as the request target of an OPTIONS request, an empty path component is equivalent to an absolute path of 1111 1112 "/", so the normal form is to provide a path of "/" instead. The scheme and host are case-insensitive and normally provided … … 1225 1226 the protocol version if their defined semantics allow them to be safely ignored by recipients that do not recognize them. 1226 1227 </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 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 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 1229 </p> 1229 1230 <h3 id="rfc.section.3.2.2"><a href="#rfc.section.3.2.2">3.2.2</a> <a id="field.order" href="#field.order">Field Order</a></h3> … … 1691 1692 no transfer coding is always acceptable. 1692 1693 </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 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 6.1</a>) in order to prevent the TE field from being forwarded by intermediaries that do not support its semantics. 1694 1695 </p> 1695 1696 <h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a> <a id="message.routing" href="#message.routing">Message Routing</a></h1> … … 1871 1872 enhance (or interfere) with either direction of the stream. 1872 1873 </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 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 6.1</a>, to exclude fields that are only intended for the incoming connection. 1874 1875 </p> 1875 1876 <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. … … 1877 1878 <div id="rfc.iref.v.1"></div> 1878 1879 <h3 id="rfc.section.5.7.1"><a href="#rfc.section.5.7.1">5.7.1</a> <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 user1880 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 of1882 al l 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 1886 1887 <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> 1887 1888 ; see <a href="#header.upgrade" id="rfc.xref.header.upgrade.1" title="Upgrade">Section 6.7</a> 1888 1889 <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> 1889 1890 <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 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 1903 1908 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 1904 1909 server at www.example.com. The request received by www.example.com would then have the following Via header field: 1905 1910 </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, 1908 1913 the received-by host of any host behind the firewall <em class="bcp14">SHOULD</em> be replaced by an appropriate pseudonym for that host. 1909 1914 </p> 1910 <p id="rfc.section.5.7.1.p.1 0">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-protocol1915 <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 1911 1916 values. For example, 1912 1917 </p> 1913 1918 <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.1 2">could be collapsed to</p>1919 </pre><p id="rfc.section.5.7.1.p.13">could be collapsed to</p> 1915 1920 <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.1 4">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 replaced1921 </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 1917 1922 by pseudonyms. Senders <em class="bcp14">MUST NOT</em> combine entries that have different received-protocol values. 1918 1923 </p> … … 2089 2094 <div id="rfc.iref.c.14"></div> 2090 2095 <h2 id="rfc.section.6.6"><a href="#rfc.section.6.6">6.6</a> <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 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 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. 2092 2097 </p> 2093 2098 <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. … … 2155 2160 [... data stream switches to HTTP/2.0 with an appropriate response 2156 2161 (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 6.1</a>) that contains an "upgrade" connection option, in order to prevent Upgrade from being accidentally forwarded by intermediaries2162 </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 6.1</a>) that contains an "upgrade" connection option, in order to prevent Upgrade from being accidentally forwarded by intermediaries 2158 2163 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. 2159 2164 </p> … … 2189 2194 <td class="left">http</td> 2190 2195 <td class="left">standard</td> 2191 <td class="left"> <a href="#header.connection" id="rfc.xref.header.connection. 8" title="Connection">Section 6.1</a>2196 <td class="left"> <a href="#header.connection" id="rfc.xref.header.connection.7" title="Connection">Section 6.1</a> 2192 2197 </td> 2193 2198 </tr> … … 2238 2243 <td class="left">http</td> 2239 2244 <td class="left">standard</td> 2240 <td class="left"> <a href="#header.via" id="rfc.xref.header.via. 2" title="Via">Section 5.7.1</a>2245 <td class="left"> <a href="#header.via" id="rfc.xref.header.via.1" title="Via">Section 5.7.1</a> 2241 2246 </td> 2242 2247 </tr> … … 2245 2250 </div> 2246 2251 <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 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 6.1</a>). 2248 2253 </p> 2249 2254 <div id="rfc.table.u.1"> … … 2952 2957 <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 5.3</a>) 2953 2958 </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 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 6.1</a>) 2955 2960 </p> 2956 2961 <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.1 1" title="Connection">Section 6.1</a>)2962 in this specification doesn't exempt them. (<a href="#header.connection" id="rfc.xref.header.connection.10" title="Connection">Section 6.1</a>) 2958 2963 </p> 2959 2964 <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 6.3</a>) … … 3234 3239 <li>chunked (Coding Format) <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> 3235 3240 <li>client <a href="#rfc.iref.c.1"><b>2.1</b></a></li> 3236 <li>close <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 <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> 3237 3242 <li>compress (Coding Format) <a href="#rfc.iref.c.10">4.2.1</a></li> 3238 3243 <li>connection <a href="#rfc.iref.c.2"><b>2.1</b></a></li> 3239 <li>Connection header field <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 <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> 3240 3245 <li>Content-Length header field <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> 3241 3246 </ul> … … 3536 3541 </li> 3537 3542 <li><a id="rfc.index.V" href="#rfc.index.V"><b>V</b></a><ul> 3538 <li>Via header field <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 <a href="#rfc.iref.v.1"><b>5.7.1</b></a>, <a href="#rfc.xref.header.via.1">7.1</a></li> 3539 3544 </ul> 3540 3545 </li> -
draft-ietf-httpbis/latest/p1-messaging.xml
r2285 r2286 512 512 it desires, including private extensions to HTTP that are outside 513 513 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. 520 516 </t> 521 517 <t><iref primary="true" item="tunnel"/> … … 965 961 <t> 966 962 If the port is equal to the default port for a scheme, the normal form is 967 to elidethe port subcomponent. When not being used in absolute form as the963 to omit the port subcomponent. When not being used in absolute form as the 968 964 request target of an OPTIONS request, an empty path component is equivalent 969 965 to an absolute path of "/", so the normal form is to provide a path of "/" … … 2572 2568 <x:anchor-alias value="Via"/> 2573 2569 <t> 2574 The "Via" header field &MUST; be sent by a proxy or gateway in forwarded2575 messages to indicate the intermediate protocols and recipients between the2576 user agent and the server on requests, and between the origin server and2577 the client on responses. It is analogous to the "Received" field2578 used by email systems(<xref target="RFC5322" x:fmt="of" x:sec="3.6.7"/>).2579 Via is used in HTTPfor 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, 2580 2576 avoiding request loops, and identifying the protocol capabilities of 2581 allsenders along the request/response chain.2577 senders along the request/response chain. 2582 2578 </t> 2583 2579 <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 2586 2582 <x:ref>received-protocol</x:ref> = [ <x:ref>protocol-name</x:ref> "/" ] <x:ref>protocol-version</x:ref> 2587 2583 ; see <xref target="header.upgrade"/> … … 2590 2586 </artwork></figure> 2591 2587 <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 2602 2612 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. 2612 2616 </t> 2613 2617 <t> … … 2627 2631 </t> 2628 2632 <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 2630 2634 </artwork></figure> 2631 2635 <t>
Note: See TracChangeset
for help on using the changeset viewer.