![(please configure the [header_logo] section in trac.ini)](https://www.ietf.org/images/ietflogotrans.gif)
Changeset 1582 for draft-ietf-httpbis/latest/p1-messaging.html
- Timestamp:
- 11/03/12 11:49:08 (11 years ago)
- File:
-
- 1 edited
-
draft-ietf-httpbis/latest/p1-messaging.html (modified) (22 diffs)
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.html
r1581 r1582 711 711 <li>5.3 <a href="#request-target">Request Target</a></li> 712 712 <li>5.4 <a href="#header.host">Host</a></li> 713 <li>5.5 <a href="#the.resource.identified.by.a.request">The Resource Identified by a Request</a></li> 714 <li>5.6 <a href="#effective.request.uri">Effective Request URI</a></li> 715 <li>5.7 <a href="#associating.response.to.request">Associating a Response to a Request</a></li> 713 <li>5.5 <a href="#effective.request.uri">Effective Request URI</a></li> 714 <li>5.6 <a href="#associating.response.to.request">Associating a Response to a Request</a></li> 716 715 </ul> 717 716 </li> … … 1852 1851 </p> 1853 1852 <p id="rfc.section.5.1.p.2">HTTP communication is initiated by a user agent for some purpose. The purpose is a combination of request semantics, which 1854 are defined in <a href="#Part2" id="rfc.xref.Part2.8"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>, and a target resource upon which to apply those semantics. A URI reference (<a href="#uri" title="Uniform Resource Identifiers">Section 2.7</a>) is typically used as an identifier for the target resource, which a user agent would resolve to its absolute form in order1855 to obtain the target URI. The target URI excludes the reference's fragment identifier component, if any, since fragment identifiers1856 are reserved for client-side processing (<a href="#RFC3986" id="rfc.xref.RFC3986.18"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-3.5">Section 3.5</a>).1853 are defined in <a href="#Part2" id="rfc.xref.Part2.8"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>, and a target resource upon which to apply those semantics. A URI reference (<a href="#uri" title="Uniform Resource Identifiers">Section 2.7</a>) is typically used as an identifier for the "target resource", which a user agent would resolve to its absolute form in order 1854 to obtain the "target URI". The target URI excludes the reference's fragment identifier component, if any, since fragment 1855 identifiers are reserved for client-side processing (<a href="#RFC3986" id="rfc.xref.RFC3986.18"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-3.5">Section 3.5</a>). 1857 1856 </p> 1858 1857 <p id="rfc.section.5.1.p.3">HTTP intermediaries obtain the request semantics and target URI from the request-line of an incoming request message.</p> … … 1964 1963 message that contains more than one Host header field or a Host header field with an invalid field-value. 1965 1964 </p> 1966 <h2 id="rfc.section.5.5"><a href="#rfc.section.5.5">5.5</a> <a id="the.resource.identified.by.a.request" href="#the.resource.identified.by.a.request">The Resource Identified by a Request</a></h2>1967 <p id="rfc.section.5.5.p.1">The exact resource identified by an Internet request is determined by examining both the request-target and the Host header1968 field.1969 </p>1970 <p id="rfc.section.5.5.p.2">An origin server that does not allow resources to differ by the requested host <em class="bcp14">MAY</em> ignore the Host header field value when determining the resource identified by an HTTP/1.1 request. (But see <a href="#changes.to.simplify.multi-homed.web.servers.and.conserve.ip.addresses" title="Multi-homed Web Servers">Appendix A.1.1</a> for other requirements on Host support in HTTP/1.1.)1971 </p>1972 <p id="rfc.section.5.5.p.3">An origin server that does differentiate resources based on the host requested (sometimes referred to as virtual hosts or1973 vanity host names) <em class="bcp14">MUST</em> use the following rules for determining the requested resource on an HTTP/1.1 request:1974 </p>1975 <ol>1976 <li>If request-target is an absolute-URI, the host is part of the request-target. Any Host header field value in the request <em class="bcp14">MUST</em> be ignored.1977 </li>1978 <li>If the request-target is not an absolute-URI, and the request includes a Host header field, the host is determined by the1979 Host header field value.1980 </li>1981 <li>If the host as determined by rule 1 or 2 is not a valid host on the server, the response <em class="bcp14">MUST</em> be a 400 (Bad Request) error message.1982 </li>1983 </ol>1984 <p id="rfc.section.5.5.p.4">Recipients of an HTTP/1.0 request that lacks a Host header field <em class="bcp14">MAY</em> attempt to use heuristics (e.g., examination of the URI path for something unique to a particular host) in order to determine1985 what exact resource is being requested.1986 </p>1987 1965 <div id="rfc.iref.e.1"></div> 1988 <h2 id="rfc.section.5.6"><a href="#rfc.section.5.6">5.6</a> <a id="effective.request.uri" href="#effective.request.uri">Effective Request URI</a></h2> 1989 <p id="rfc.section.5.6.p.1">HTTP requests often do not carry the absolute URI (<a href="#RFC3986" id="rfc.xref.RFC3986.19"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-4.3">Section 4.3</a>) for the target resource; instead, the URI needs to be inferred from the request-target, Host header field, and connection 1990 context. The result of this process is called the "effective request URI". The "target resource" is the resource identified 1991 by the effective request URI. 1992 </p> 1993 <p id="rfc.section.5.6.p.2">If the request-target is an absolute-URI, then the effective request URI is the request-target.</p> 1994 <p id="rfc.section.5.6.p.3">If the request-target uses the origin form or the asterisk form, and the Host header field is present, then the effective 1995 request URI is constructed by concatenating 1996 </p> 1997 <p id="rfc.section.5.6.p.4"> </p> 1998 <ul> 1999 <li>the scheme name: "http" if the request was received over an insecure TCP connection, or "https" when received over a SSL/TLS-secured 2000 TCP connection, 2001 </li> 2002 <li>the octet sequence "://",</li> 2003 <li>the authority component, as specified in the Host header field (<a href="#header.host" id="rfc.xref.header.host.2" title="Host">Section 5.4</a>), and 2004 </li> 2005 <li>the request-target obtained from the request-line, unless the request-target is just the asterisk "*".</li> 2006 </ul> 2007 <p id="rfc.section.5.6.p.5">If the request-target uses the origin form or the asterisk form, and the Host header field is not present, then the effective 2008 request URI is undefined. 2009 </p> 2010 <p id="rfc.section.5.6.p.6">Otherwise, when request-target uses the authority form, the effective request URI is undefined.</p> 1966 <h2 id="rfc.section.5.5"><a href="#rfc.section.5.5">5.5</a> <a id="effective.request.uri" href="#effective.request.uri">Effective Request URI</a></h2> 1967 <p id="rfc.section.5.5.p.1">A server that receives an HTTP request message <em class="bcp14">MUST</em> reconstruct the user agent's original target URI, based on the pieces of information learned from the request-target, Host, 1968 and connection context, in order to identify the intended target resource and properly service the request. The URI derived 1969 from this reconstruction process is referred to as the "effective request URI". 1970 </p> 1971 <p id="rfc.section.5.5.p.2">If the request-target is in absolute-form, then the effective request URI is the same as the request-target. Otherwise, the 1972 effective request URI is constructed as follows. 1973 </p> 1974 <p id="rfc.section.5.5.p.3">If the request is received over an SSL/TLS-secured TCP connection, then the effective request URI's scheme is "https"; otherwise, 1975 the scheme is "http". 1976 </p> 1977 <p id="rfc.section.5.5.p.4">If the request-target is in authority-form, then the effective request URI's authority component is the same as the request-target. 1978 Otherwise, if a Host header field is supplied with a non-empty field-value, then the authority component is the same as the 1979 Host field-value. Otherwise, the authority component is the concatenation of the default hostname configured for the server, 1980 a colon (":"), and the connection's incoming TCP port number in decimal form. 1981 </p> 1982 <p id="rfc.section.5.5.p.5">If the request-target is in authority-form or asterisk-form, then the effective request URI's combined path and query component 1983 is empty. Otherwise, the combined path and query component is the same as the request-target. 1984 </p> 1985 <p id="rfc.section.5.5.p.6">The components of the effective request URI, once determined as above, can be combined into absolute-URI form by concatenating 1986 the scheme, "://", authority, and combined path and query component. 1987 </p> 2011 1988 <div id="rfc.figure.u.55"></div> 2012 <p>Example 1: the effective request URI for the message</p> <pre class="text">GET /pub/WWW/TheProject.html HTTP/1.11989 <p>Example 1: the following message received over an insecure TCP connection</p> <pre class="text">GET /pub/WWW/TheProject.html HTTP/1.1 2013 1990 Host: www.example.org:8080 2014 </pre> <p>(received over an insecure TCP connection) is "http", plus "://", plus the authority component "www.example.org:8080", plus 2015 the request-target "/pub/WWW/TheProject.html", thus "http://www.example.org:8080/pub/WWW/TheProject.html". 2016 </p> 2017 <div id="rfc.figure.u.56"></div> 2018 <p>Example 2: the effective request URI for the message</p> <pre class="text">OPTIONS * HTTP/1.1 1991 </pre> <div id="rfc.figure.u.56"></div> 1992 <p>has an effective request URI of</p> <pre class="text">http://www.example.org:8080/pub/WWW/TheProject.html 1993 </pre> <div id="rfc.figure.u.57"></div> 1994 <p>Example 2: the following message received over an SSL/TLS-secured TCP connection</p> <pre class="text">OPTIONS * HTTP/1.1 2019 1995 Host: www.example.org 2020 </pre> <p>(received over an SSL/TLS secured TCP connection) is "https", plus "://", plus the authority component "www.example.org", 2021 thus "https://www.example.org". 2022 </p> 2023 <p id="rfc.section.5.6.p.9">Effective request URIs are compared using the rules described in <a href="#uri.comparison" title="http and https URI Normalization and Comparison">Section 2.7.3</a>, except that empty path components <em class="bcp14">MUST NOT</em> be treated as equivalent to an absolute path of "/". 2024 </p> 2025 <h2 id="rfc.section.5.7"><a href="#rfc.section.5.7">5.7</a> <a id="associating.response.to.request" href="#associating.response.to.request">Associating a Response to a Request</a></h2> 2026 <p id="rfc.section.5.7.p.1">HTTP does not include a request identifier for associating a given request message with its corresponding one or more response 1996 </pre> <div id="rfc.figure.u.58"></div> 1997 <p>has an effective request URI of</p> <pre class="text">https://www.example.org 1998 </pre> <p id="rfc.section.5.5.p.11">An origin server that does not allow resources to differ by requested host <em class="bcp14">MAY</em> ignore the Host field-value and instead replace it with a configured server name when constructing the effective request URI. 1999 </p> 2000 <p id="rfc.section.5.5.p.12">Recipients of an HTTP/1.0 request that lacks a Host header field <em class="bcp14">MAY</em> attempt to use heuristics (e.g., examination of the URI path for something unique to a particular host) in order to guess 2001 the effective request URI's authority component. 2002 </p> 2003 <h2 id="rfc.section.5.6"><a href="#rfc.section.5.6">5.6</a> <a id="associating.response.to.request" href="#associating.response.to.request">Associating a Response to a Request</a></h2> 2004 <p id="rfc.section.5.6.p.1">HTTP does not include a request identifier for associating a given request message with its corresponding one or more response 2027 2005 messages. Hence, it relies on the order of response arrival to correspond exactly to the order in which requests are made 2028 2006 on the same connection. More than one response message per request only occurs when one or more informational responses (1xx, 2029 2007 see <a href="p2-semantics.html#status.1xx" title="Informational 1xx">Section 7.1</a> of <a href="#Part2" id="rfc.xref.Part2.11"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) precede a final response to the same request. 2030 2008 </p> 2031 <p id="rfc.section.5. 7.p.2">A client that uses persistent connections and sends more than one request per connection <em class="bcp14">MUST</em> maintain a list of outstanding requests in the order sent on that connection and <em class="bcp14">MUST</em> associate each received response message to the highest ordered request that has not yet received a final (non-1xx) response.2009 <p id="rfc.section.5.6.p.2">A client that uses persistent connections and sends more than one request per connection <em class="bcp14">MUST</em> maintain a list of outstanding requests in the order sent on that connection and <em class="bcp14">MUST</em> associate each received response message to the highest ordered request that has not yet received a final (non-1xx) response. 2032 2010 </p> 2033 2011 <h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a> <a id="connections" href="#connections">Connections</a></h1> … … 2296 2274 <tr> 2297 2275 <td class="left">Host</td> 2298 <td class="left"><a href="#header.host" id="rfc.xref.header.host. 3" title="Host">Section 5.4</a></td>2276 <td class="left"><a href="#header.host" id="rfc.xref.header.host.2" title="Host">Section 5.4</a></td> 2299 2277 </tr> 2300 2278 <tr> … … 2332 2310 </p> 2333 2311 <p id="rfc.section.8.1.p.2">The Connection header field's value has the following grammar:</p> 2334 <div id="rfc.figure.u.5 7"></div><pre class="inline"><span id="rfc.iref.g.85"></span><span id="rfc.iref.g.86"></span> <a href="#header.connection" class="smpl">Connection</a> = 1#<a href="#header.connection" class="smpl">connection-token</a>2312 <div id="rfc.figure.u.59"></div><pre class="inline"><span id="rfc.iref.g.85"></span><span id="rfc.iref.g.86"></span> <a href="#header.connection" class="smpl">Connection</a> = 1#<a href="#header.connection" class="smpl">connection-token</a> 2335 2313 <a href="#header.connection" class="smpl">connection-token</a> = <a href="#rule.token.separators" class="smpl">token</a> 2336 2314 </pre><p id="rfc.section.8.1.p.4">A proxy or gateway <em class="bcp14">MUST</em> parse a received Connection header field before a message is forwarded and, for each connection-token in this field, remove … … 2355 2333 of the response. For example, 2356 2334 </p> 2357 <div id="rfc.figure.u. 58"></div><pre class="text"> Connection: close2335 <div id="rfc.figure.u.60"></div><pre class="text"> Connection: close 2358 2336 </pre><p id="rfc.section.8.1.p.10">in either the request or the response header fields indicates that the connection <em class="bcp14">SHOULD NOT</em> be considered "persistent" (<a href="#persistent.connections" title="Persistent Connections">Section 6.1</a>) after the current request/response is complete. 2359 2337 </p> … … 2368 2346 server chooses to switch protocols. Servers can use it to indicate what protocols they are willing to switch to. 2369 2347 </p> 2370 <div id="rfc.figure.u. 59"></div><pre class="inline"><span id="rfc.iref.g.87"></span> <a href="#header.upgrade" class="smpl">Upgrade</a> = 1#<a href="#header.upgrade" class="smpl">protocol</a>2348 <div id="rfc.figure.u.61"></div><pre class="inline"><span id="rfc.iref.g.87"></span> <a href="#header.upgrade" class="smpl">Upgrade</a> = 1#<a href="#header.upgrade" class="smpl">protocol</a> 2371 2349 2372 2350 <a href="#header.upgrade" class="smpl">protocol</a> = <a href="#header.upgrade" class="smpl">protocol-name</a> ["/" <a href="#header.upgrade" class="smpl">protocol-version</a>] … … 2374 2352 <a href="#header.upgrade" class="smpl">protocol-version</a> = <a href="#rule.token.separators" class="smpl">token</a> 2375 2353 </pre><p id="rfc.section.8.2.p.3">For example,</p> 2376 <div id="rfc.figure.u.6 0"></div><pre class="text"> Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x112354 <div id="rfc.figure.u.62"></div><pre class="text"> Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11 2377 2355 </pre><p id="rfc.section.8.2.p.5">The Upgrade header field is intended to provide a simple mechanism for transitioning from HTTP/1.1 to some other, incompatible 2378 2356 protocol. It does so by allowing the client to advertise its desire to use another protocol, such as a later version of HTTP … … 2430 2408 of all senders along the request/response chain. 2431 2409 </p> 2432 <div id="rfc.figure.u.6 1"></div><pre class="inline"><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><span id="rfc.iref.g.93"></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>2410 <div id="rfc.figure.u.63"></div><pre class="inline"><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><span id="rfc.iref.g.93"></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> 2433 2411 [ <a href="#rule.whitespace" class="smpl">RWS</a> <a href="#rule.comment" class="smpl">comment</a> ] ) 2434 2412 <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> … … 2452 2430 server at www.example.com. The request received by www.example.com would then have the following Via header field: 2453 2431 </p> 2454 <div id="rfc.figure.u.6 2"></div><pre class="text"> Via: 1.0 fred, 1.1 p.example.net (Apache/1.1)2432 <div id="rfc.figure.u.64"></div><pre class="text"> Via: 1.0 fred, 1.1 p.example.net (Apache/1.1) 2455 2433 </pre><p id="rfc.section.8.3.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, 2456 2434 the received-by host of any host behind the firewall <em class="bcp14">SHOULD</em> be replaced by an appropriate pseudonym for that host. … … 2459 2437 For example, 2460 2438 </p> 2461 <div id="rfc.figure.u.6 3"></div><pre class="text"> Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy2439 <div id="rfc.figure.u.65"></div><pre class="text"> Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy 2462 2440 </pre><p id="rfc.section.8.3.p.12">could be collapsed to</p> 2463 <div id="rfc.figure.u.6 4"></div><pre class="text"> Via: 1.0 ricky, 1.1 mertz, 1.0 lucy2441 <div id="rfc.figure.u.66"></div><pre class="text"> Via: 1.0 ricky, 1.1 mertz, 1.0 lucy 2464 2442 </pre><p id="rfc.section.8.3.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 2465 2443 by pseudonyms. Senders <em class="bcp14">MUST NOT</em> combine entries which have different received-protocol values. … … 2499 2477 <td class="left">http</td> 2500 2478 <td class="left">standard</td> 2501 <td class="left"> <a href="#header.host" id="rfc.xref.header.host. 4" title="Host">Section 5.4</a>2479 <td class="left"> <a href="#header.host" id="rfc.xref.header.host.3" title="Host">Section 5.4</a> 2502 2480 </td> 2503 2481 </tr> … … 3078 3056 <p id="rfc.section.A.1.p.1">This section summarizes major differences between versions HTTP/1.0 and HTTP/1.1.</p> 3079 3057 <h3 id="rfc.section.A.1.1"><a href="#rfc.section.A.1.1">A.1.1</a> <a id="changes.to.simplify.multi-homed.web.servers.and.conserve.ip.addresses" href="#changes.to.simplify.multi-homed.web.servers.and.conserve.ip.addresses">Multi-homed Web Servers</a></h3> 3080 <p id="rfc.section.A.1.1.p.1">The requirements that clients and servers support the Host header field (<a href="#header.host" id="rfc.xref.header.host. 5" title="Host">Section 5.4</a>), report an error if it is missing from an HTTP/1.1 request, and accept absolute URIs (<a href="#request-target" title="Request Target">Section 5.3</a>) are among the most important changes defined by HTTP/1.1.3058 <p id="rfc.section.A.1.1.p.1">The requirements that clients and servers support the Host header field (<a href="#header.host" id="rfc.xref.header.host.4" title="Host">Section 5.4</a>), report an error if it is missing from an HTTP/1.1 request, and accept absolute URIs (<a href="#request-target" title="Request Target">Section 5.3</a>) are among the most important changes defined by HTTP/1.1. 3081 3059 </p> 3082 3060 <p id="rfc.section.A.1.1.p.2">Older HTTP/1.0 clients assumed a one-to-one relationship of IP addresses and servers; there was no other established mechanism … … 3147 3125 </p> 3148 3126 <h1 id="rfc.section.B"><a href="#rfc.section.B">B.</a> <a id="collected.abnf" href="#collected.abnf">Collected ABNF</a></h1> 3149 <div id="rfc.figure.u.6 5"></div> <pre class="inline"><a href="#rule.whitespace" class="smpl">BWS</a> = OWS3127 <div id="rfc.figure.u.67"></div> <pre class="inline"><a href="#rule.whitespace" class="smpl">BWS</a> = OWS 3150 3128 3151 3129 <a href="#header.connection" class="smpl">Connection</a> = *( "," OWS ) connection-token *( OWS "," [ OWS … … 3266 3244 3267 3245 <a href="#rule.token.separators" class="smpl">word</a> = token / quoted-string 3268 </pre> <div id="rfc.figure.u.6 6"></div>3246 </pre> <div id="rfc.figure.u.68"></div> 3269 3247 <p>ABNF diagnostics:</p><pre class="inline">; Connection defined but not used 3270 3248 ; Content-Length defined but not used … … 3711 3689 </li> 3712 3690 <li><a id="rfc.index.E" href="#rfc.index.E"><b>E</b></a><ul> 3713 <li>effective request URI <a href="#rfc.iref.e.1"><b>5. 6</b></a></li>3691 <li>effective request URI <a href="#rfc.iref.e.1"><b>5.5</b></a></li> 3714 3692 </ul> 3715 3693 </li> … … 3820 3798 <li>Connection <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</a>, <a href="#rfc.xref.header.connection.4">4.4</a>, <a href="#rfc.xref.header.connection.5">6.1.2</a>, <a href="#rfc.xref.header.connection.6">6.1.3</a>, <a href="#rfc.xref.header.connection.7">6.1.3.1</a>, <a href="#rfc.xref.header.connection.8">8</a>, <a href="#rfc.iref.h.12"><b>8.1</b></a>, <a href="#rfc.xref.header.connection.9">8.2</a>, <a href="#rfc.xref.header.connection.10">9.1</a>, <a href="#rfc.xref.header.connection.11">9.1</a>, <a href="#rfc.xref.header.connection.12">A.2</a></li> 3821 3799 <li>Content-Length <a href="#rfc.iref.h.7"><b>3.3.2</b></a>, <a href="#rfc.xref.header.content-length.1">3.3.2</a>, <a href="#rfc.xref.header.content-length.2">8</a>, <a href="#rfc.xref.header.content-length.3">9.1</a></li> 3822 <li>Host <a href="#rfc.xref.header.host.1">5.3</a>, <a href="#rfc.iref.h.11"><b>5.4</b></a>, <a href="#rfc.xref.header.host.2"> 5.6</a>, <a href="#rfc.xref.header.host.3">8</a>, <a href="#rfc.xref.header.host.4">9.1</a>, <a href="#rfc.xref.header.host.5">A.1.1</a></li>3800 <li>Host <a href="#rfc.xref.header.host.1">5.3</a>, <a href="#rfc.iref.h.11"><b>5.4</b></a>, <a href="#rfc.xref.header.host.2">8</a>, <a href="#rfc.xref.header.host.3">9.1</a>, <a href="#rfc.xref.header.host.4">A.1.1</a></li> 3823 3801 <li>TE <a href="#rfc.xref.header.te.1">4</a>, <a href="#rfc.xref.header.te.2">4.1</a>, <a href="#rfc.iref.h.8"><b>4.4</b></a>, <a href="#rfc.xref.header.te.3">4.4.1</a>, <a href="#rfc.xref.header.te.4">8</a>, <a href="#rfc.xref.header.te.5">9.1</a></li> 3824 3802 <li>Trailer <a href="#rfc.xref.header.trailer.1">4.1</a>, <a href="#rfc.iref.h.9"><b>4.5</b></a>, <a href="#rfc.xref.header.trailer.2">8</a>, <a href="#rfc.xref.header.trailer.3">9.1</a></li> … … 3830 3808 <li>header section <a href="#rfc.iref.h.3">3</a></li> 3831 3809 <li>headers <a href="#rfc.iref.h.4">3</a></li> 3832 <li>Host header field <a href="#rfc.xref.header.host.1">5.3</a>, <a href="#rfc.iref.h.10"><b>5.4</b></a>, <a href="#rfc.xref.header.host.2"> 5.6</a>, <a href="#rfc.xref.header.host.3">8</a>, <a href="#rfc.xref.header.host.4">9.1</a>, <a href="#rfc.xref.header.host.5">A.1.1</a></li>3810 <li>Host header field <a href="#rfc.xref.header.host.1">5.3</a>, <a href="#rfc.iref.h.10"><b>5.4</b></a>, <a href="#rfc.xref.header.host.2">8</a>, <a href="#rfc.xref.header.host.3">9.1</a>, <a href="#rfc.xref.header.host.4">A.1.1</a></li> 3833 3811 <li>http URI scheme <a href="#rfc.iref.h.1"><b>2.7.1</b></a></li> 3834 3812 <li>https URI scheme <a href="#rfc.iref.h.2">2.7.2</a></li> … … 3871 3849 <li><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul> 3872 3850 <li><em>Pad1995</em> <a href="#rfc.xref.Pad1995.1">6.1.1</a>, <a href="#Pad1995"><b>12.2</b></a></li> 3873 <li><em>Part2</em> <a href="#rfc.xref.Part2.1">2.3</a>, <a href="#rfc.xref.Part2.2">2.7.1</a>, <a href="#rfc.xref.Part2.3">3.1.1</a>, <a href="#rfc.xref.Part2.4">3.1.1</a>, <a href="#rfc.xref.Part2.5">3.1.2</a>, <a href="#rfc.xref.Part2.6">3.2</a>, <a href="#rfc.xref.Part2.7">3.2</a>, <a href="#rfc.xref.Part2.8">5.1</a>, <a href="#rfc.xref.Part2.9">5.3</a>, <a href="#rfc.xref.Part2.10">5.3</a>, <a href="#rfc.xref.Part2.11">5. 7</a>, <a href="#rfc.xref.Part2.12">6.1.2.2</a>, <a href="#rfc.xref.Part2.13">6.1.5</a>, <a href="#rfc.xref.Part2.14">6.2.3</a>, <a href="#rfc.xref.Part2.15">6.2.3</a>, <a href="#rfc.xref.Part2.16">6.2.3</a>, <a href="#rfc.xref.Part2.17">6.2.3</a>, <a href="#rfc.xref.Part2.18">8.2</a>, <a href="#rfc.xref.Part2.19">10.6</a>, <a href="#rfc.xref.Part2.20">10.6</a>, <a href="#Part2"><b>12.1</b></a><ul>3851 <li><em>Part2</em> <a href="#rfc.xref.Part2.1">2.3</a>, <a href="#rfc.xref.Part2.2">2.7.1</a>, <a href="#rfc.xref.Part2.3">3.1.1</a>, <a href="#rfc.xref.Part2.4">3.1.1</a>, <a href="#rfc.xref.Part2.5">3.1.2</a>, <a href="#rfc.xref.Part2.6">3.2</a>, <a href="#rfc.xref.Part2.7">3.2</a>, <a href="#rfc.xref.Part2.8">5.1</a>, <a href="#rfc.xref.Part2.9">5.3</a>, <a href="#rfc.xref.Part2.10">5.3</a>, <a href="#rfc.xref.Part2.11">5.6</a>, <a href="#rfc.xref.Part2.12">6.1.2.2</a>, <a href="#rfc.xref.Part2.13">6.1.5</a>, <a href="#rfc.xref.Part2.14">6.2.3</a>, <a href="#rfc.xref.Part2.15">6.2.3</a>, <a href="#rfc.xref.Part2.16">6.2.3</a>, <a href="#rfc.xref.Part2.17">6.2.3</a>, <a href="#rfc.xref.Part2.18">8.2</a>, <a href="#rfc.xref.Part2.19">10.6</a>, <a href="#rfc.xref.Part2.20">10.6</a>, <a href="#Part2"><b>12.1</b></a><ul> 3874 3852 <li><em>Section 2</em> <a href="#rfc.xref.Part2.3">3.1.1</a></li> 3875 3853 <li><em>Section 3.1</em> <a href="#rfc.xref.Part2.7">3.2</a></li> … … 3878 3856 <li><em>Section 6.2</em> <a href="#rfc.xref.Part2.10">5.3</a></li> 3879 3857 <li><em>Section 6.9</em> <a href="#rfc.xref.Part2.9">5.3</a></li> 3880 <li><em>Section 7.1</em> <a href="#rfc.xref.Part2.11">5. 7</a>, <a href="#rfc.xref.Part2.17">6.2.3</a></li>3858 <li><em>Section 7.1</em> <a href="#rfc.xref.Part2.11">5.6</a>, <a href="#rfc.xref.Part2.17">6.2.3</a></li> 3881 3859 <li><em>Section 7.1.1</em> <a href="#rfc.xref.Part2.14">6.2.3</a></li> 3882 3860 <li><em>Section 7.2.4</em> <a href="#rfc.xref.Part2.1">2.3</a></li> … … 3939 3917 <li><em>RFC3040</em> <a href="#rfc.xref.RFC3040.1">2.3</a>, <a href="#RFC3040"><b>12.2</b></a></li> 3940 3918 <li><em>RFC3864</em> <a href="#rfc.xref.RFC3864.1">9.1</a>, <a href="#RFC3864"><b>12.2</b></a></li> 3941 <li><em>RFC3986</em> <a href="#rfc.xref.RFC3986.1">1</a>, <a href="#rfc.xref.RFC3986.2">2.7</a>, <a href="#rfc.xref.RFC3986.3">2.7</a>, <a href="#rfc.xref.RFC3986.4">2.7</a>, <a href="#rfc.xref.RFC3986.5">2.7</a>, <a href="#rfc.xref.RFC3986.6">2.7</a>, <a href="#rfc.xref.RFC3986.7">2.7</a>, <a href="#rfc.xref.RFC3986.8">2.7</a>, <a href="#rfc.xref.RFC3986.9">2.7</a>, <a href="#rfc.xref.RFC3986.10">2.7</a>, <a href="#rfc.xref.RFC3986.11">2.7</a>, <a href="#rfc.xref.RFC3986.12">2.7</a>, <a href="#rfc.xref.RFC3986.13">2.7</a>, <a href="#rfc.xref.RFC3986.14">2.7.1</a>, <a href="#rfc.xref.RFC3986.15">2.7.1</a>, <a href="#rfc.xref.RFC3986.16">2.7.3</a>, <a href="#rfc.xref.RFC3986.17">2.7.3</a>, <a href="#rfc.xref.RFC3986.18">5.1</a>, <a href="# rfc.xref.RFC3986.19">5.6</a>, <a href="#RFC3986"><b>12.1</b></a><ul>3919 <li><em>RFC3986</em> <a href="#rfc.xref.RFC3986.1">1</a>, <a href="#rfc.xref.RFC3986.2">2.7</a>, <a href="#rfc.xref.RFC3986.3">2.7</a>, <a href="#rfc.xref.RFC3986.4">2.7</a>, <a href="#rfc.xref.RFC3986.5">2.7</a>, <a href="#rfc.xref.RFC3986.6">2.7</a>, <a href="#rfc.xref.RFC3986.7">2.7</a>, <a href="#rfc.xref.RFC3986.8">2.7</a>, <a href="#rfc.xref.RFC3986.9">2.7</a>, <a href="#rfc.xref.RFC3986.10">2.7</a>, <a href="#rfc.xref.RFC3986.11">2.7</a>, <a href="#rfc.xref.RFC3986.12">2.7</a>, <a href="#rfc.xref.RFC3986.13">2.7</a>, <a href="#rfc.xref.RFC3986.14">2.7.1</a>, <a href="#rfc.xref.RFC3986.15">2.7.1</a>, <a href="#rfc.xref.RFC3986.16">2.7.3</a>, <a href="#rfc.xref.RFC3986.17">2.7.3</a>, <a href="#rfc.xref.RFC3986.18">5.1</a>, <a href="#RFC3986"><b>12.1</b></a><ul> 3942 3920 <li><em>Section 2.1</em> <a href="#rfc.xref.RFC3986.17">2.7.3</a></li> 3943 3921 <li><em>Section 3.2</em> <a href="#rfc.xref.RFC3986.8">2.7</a></li> … … 3950 3928 <li><em>Section 4.1</em> <a href="#rfc.xref.RFC3986.5">2.7</a></li> 3951 3929 <li><em>Section 4.2</em> <a href="#rfc.xref.RFC3986.7">2.7</a></li> 3952 <li><em>Section 4.3</em> <a href="#rfc.xref.RFC3986.6">2.7</a> , <a href="#rfc.xref.RFC3986.19">5.6</a></li>3930 <li><em>Section 4.3</em> <a href="#rfc.xref.RFC3986.6">2.7</a></li> 3953 3931 <li><em>Section 6</em> <a href="#rfc.xref.RFC3986.16">2.7.3</a></li> 3954 3932 </ul>
Note: See TracChangeset
for help on using the changeset viewer.
