Changeset 2044 for draft-ietf-httpbis/latest/p1-messaging.html
- Timestamp:
- 08/12/12 08:20:18 (10 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.html
r2035 r2044 449 449 } 450 450 @bottom-center { 451 content: "Expires June 1 0, 2013";451 content: "Expires June 11, 2013"; 452 452 } 453 453 @bottom-right { … … 491 491 <meta name="dct.creator" content="Reschke, J. F."> 492 492 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p1-messaging-latest"> 493 <meta name="dct.issued" scheme="ISO8601" content="2012-12-0 7">493 <meta name="dct.issued" scheme="ISO8601" content="2012-12-08"> 494 494 <meta name="dct.replaces" content="urn:ietf:rfc:2145"> 495 495 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> … … 520 520 <tr> 521 521 <td class="left">Intended status: Standards Track</td> 522 <td class="right">December 7, 2012</td>522 <td class="right">December 8, 2012</td> 523 523 </tr> 524 524 <tr> 525 <td class="left">Expires: June 1 0, 2013</td>525 <td class="left">Expires: June 11, 2013</td> 526 526 <td class="right"></td> 527 527 </tr> … … 551 551 in progress”. 552 552 </p> 553 <p>This Internet-Draft will expire on June 1 0, 2013.</p>553 <p>This Internet-Draft will expire on June 11, 2013.</p> 554 554 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 555 555 <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 638 638 <li><a href="#rfc.section.5.7">5.7</a> <a href="#message.forwarding">Message Forwarding</a><ul> 639 639 <li><a href="#rfc.section.5.7.1">5.7.1</a> <a href="#header.via">Via</a></li> 640 <li><a href="#rfc.section.5.7.2">5.7.2</a> <a href="#message.transformation ">Transformation</a></li>640 <li><a href="#rfc.section.5.7.2">5.7.2</a> <a href="#message.transformations">Transformations</a></li> 641 641 </ul> 642 642 </li> … … 660 660 <li><a href="#rfc.section.7.1">7.1</a> <a href="#header.field.registration">Header Field Registration</a></li> 661 661 <li><a href="#rfc.section.7.2">7.2</a> <a href="#uri.scheme.registration">URI Scheme Registration</a></li> 662 <li><a href="#rfc.section.7.3">7.3</a> <a href="#internet.media.type.http">Internet Media Type Registration s</a><ul>662 <li><a href="#rfc.section.7.3">7.3</a> <a href="#internet.media.type.http">Internet Media Type Registration</a><ul> 663 663 <li><a href="#rfc.section.7.3.1">7.3.1</a> <a href="#internet.media.type.message.http">Internet Media Type message/http</a></li> 664 664 <li><a href="#rfc.section.7.3.2">7.3.2</a> <a href="#internet.media.type.application.http">Internet Media Type application/http</a></li> … … 666 666 </li> 667 667 <li><a href="#rfc.section.7.4">7.4</a> <a href="#transfer.coding.registry">Transfer Coding Registry</a></li> 668 <li><a href="#rfc.section.7.5">7.5</a> <a href="#transfer.coding.registration">Transfer Coding Registration s</a></li>668 <li><a href="#rfc.section.7.5">7.5</a> <a href="#transfer.coding.registration">Transfer Coding Registration</a></li> 669 669 <li><a href="#rfc.section.7.6">7.6</a> <a href="#upgrade.token.registry">Upgrade Token Registry</a></li> 670 670 <li><a href="#rfc.section.7.7">7.7</a> <a href="#upgrade.token.registration">Upgrade Token Registration</a></li> … … 1010 1010 <div id="rfc.iref.r.5"></div> 1011 1011 <h2 id="rfc.section.2.7"><a href="#rfc.section.2.7">2.7</a> <a id="uri" href="#uri">Uniform Resource Identifiers</a></h2> 1012 <p id="rfc.section.2.7.p.1">Uniform Resource Identifiers (URIs) <a href="#RFC3986" id="rfc.xref.RFC3986.2"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a> are used throughout HTTP as the means for identifying resources (<a href="p2-semantics.html#resource " title="Resource">Section 2</a> of <a href="#Part2" id="rfc.xref.Part2.4"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). URI references are used to target requests, indicate redirects, and define relationships.1012 <p id="rfc.section.2.7.p.1">Uniform Resource Identifiers (URIs) <a href="#RFC3986" id="rfc.xref.RFC3986.2"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a> are used throughout HTTP as the means for identifying resources (<a href="p2-semantics.html#resources" title="Resources">Section 2</a> of <a href="#Part2" id="rfc.xref.Part2.4"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). URI references are used to target requests, indicate redirects, and define relationships. 1013 1013 </p> 1014 1014 <p id="rfc.section.2.7.p.2">This specification adopts the definitions of "URI-reference", "absolute-URI", "relative-part", "port", "host", "path-abempty", … … 1078 1078 </p> 1079 1079 <div id="rfc.figure.u.9"></div><pre class="inline"><span id="rfc.iref.g.25"></span> <a href="#https.uri" class="smpl">https-URI</a> = "https:" "//" <a href="#uri" class="smpl">authority</a> <a href="#uri" class="smpl">path-abempty</a> [ "?" <a href="#uri" class="smpl">query</a> ] 1080 </pre><p id="rfc.section.2.7.2.p.4">Unlike the "http" scheme, responses to "https" identified requests are never "public" and thus <em class="bcp14">MUST NOT</em> be reused for shared caching. They can, however, be reused in a private cache if the message is cacheable by default in HTTP 1081 or specifically indicated as such by the Cache-Control header field (<a href="p6-cache.html#header.cache-control" title="Cache-Control">Section 7.2</a> of <a href="#Part6" id="rfc.xref.Part6.4"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>). 1082 </p> 1083 <p id="rfc.section.2.7.2.p.5">Resources made available via the "https" scheme have no shared identity with the "http" scheme even if their resource identifiers 1080 </pre><p id="rfc.section.2.7.2.p.4">Resources made available via the "https" scheme have no shared identity with the "http" scheme even if their resource identifiers 1084 1081 indicate the same authority (the same host listening to the same TCP port). They are distinct name spaces and are considered 1085 1082 to be distinct origin servers. However, an extension to HTTP that is defined to apply to entire host domains, such as the 1086 1083 Cookie protocol <a href="#RFC6265" id="rfc.xref.RFC6265.1"><cite title="HTTP State Management Mechanism">[RFC6265]</cite></a>, can allow information set by one service to impact communication with other services within a matching group of host domains. 1087 1084 </p> 1088 <p id="rfc.section.2.7.2.p. 6">The process for authoritative access to an "https" identified resource is defined in <a href="#RFC2818" id="rfc.xref.RFC2818.2"><cite title="HTTP Over TLS">[RFC2818]</cite></a>.1085 <p id="rfc.section.2.7.2.p.5">The process for authoritative access to an "https" identified resource is defined in <a href="#RFC2818" id="rfc.xref.RFC2818.2"><cite title="HTTP Over TLS">[RFC2818]</cite></a>. 1089 1086 </p> 1090 1087 <h3 id="rfc.section.2.7.3"><a href="#rfc.section.2.7.3">2.7.3</a> <a id="uri.comparison" href="#uri.comparison">http and https URI Normalization and Comparison</a></h3> … … 1092 1089 the algorithm defined in <a href="#RFC3986" id="rfc.xref.RFC3986.14"><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. 1093 1090 </p> 1094 <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. Likewise, an empty 1095 path component is equivalent to an absolute path of "/", so the normal form is to provide a path of "/" instead. The scheme 1096 and host are case-insensitive and normally provided in lowercase; all other components are compared in a case-sensitive manner. 1097 Characters other than those in the "reserved" set are equivalent to their percent-encoded octets (see <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-2.1">Section 2.1</a>): the normal form is to not encode them. 1091 <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 1092 in absolute form as the request target of an OPTIONS request, an empty path component is equivalent to an absolute path of 1093 "/", so the normal form is to provide a path of "/" instead. The scheme and host are case-insensitive and normally provided 1094 in lowercase; all other components are compared in a case-sensitive manner. Characters other than those in the "reserved" 1095 set are equivalent to their percent-encoded octets (see <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-2.1">Section 2.1</a>): the normal form is to not encode them. 1098 1096 </p> 1099 1097 <p id="rfc.section.2.7.3.p.3">For example, the following three URIs are equivalent:</p> … … 1260 1258 </pre><h3 id="rfc.section.3.2.4"><a href="#rfc.section.3.2.4">3.2.4</a> <a id="field.parsing" href="#field.parsing">Field Parsing</a></h3> 1261 1259 <p id="rfc.section.3.2.4.p.1">No whitespace is allowed between the header field-name and colon. In the past, differences in the handling of such whitespace 1262 have led to security vulnerabilities in request routing and response handling. Any received request message that contains 1263 whitespace between a header field-name and colon <em class="bcp14">MUST</em> be rejected with a response code of 400 (Bad Request). A proxy <em class="bcp14">MUST</em> remove any such whitespace from a response message before forwarding the message downstream. 1260 have led to security vulnerabilities in request routing and response handling. A server <em class="bcp14">MUST</em> reject any received request message that contains whitespace between a header field-name and colon with a response code of <a href="p2-semantics.html#status.400" class="smpl">400 (Bad Request)</a>. A proxy <em class="bcp14">MUST</em> remove any such whitespace from a response message before forwarding the message downstream. 1264 1261 </p> 1265 1262 <p id="rfc.section.3.2.4.p.2">A field value is preceded by optional whitespace (OWS); a single SP is preferred. The field value does not include any leading … … 1269 1266 <p id="rfc.section.3.2.4.p.3">Historically, HTTP header field values could be extended over multiple lines by preceding each extra line with at least one 1270 1267 space or horizontal tab (obs-fold). This specification deprecates such line folding except within the message/http media type 1271 (<a href="#internet.media.type.message.http" title="Internet Media Type message/http">Section 7.3.1</a>). HTTP senders <em class="bcp14">MUST NOT</em> generate messages that include line folding (i.e., that contain any field-value that matches the obs-fold rule) unless the1272 message is intended for packaging within the message/http media type. HTTP recipients <em class="bcp14">SHOULD</em> accept line folding and replace any embedded obs-fold whitespace with either a single SP or a matching number of SP octets1268 (<a href="#internet.media.type.message.http" title="Internet Media Type message/http">Section 7.3.1</a>). Senders <em class="bcp14">MUST NOT</em> generate messages that include line folding (i.e., that contain any field-value that matches the obs-fold rule) unless the 1269 message is intended for packaging within the message/http media type. Recipients <em class="bcp14">MUST</em> accept line folding and replace any embedded obs-fold whitespace with either a single SP or a matching number of SP octets 1273 1270 (to avoid buffer copying) prior to interpreting the field value or forwarding the message downstream. 1274 1271 </p> … … 1456 1453 </li> 1457 1454 <li> 1458 <p>If a valid <a href="#header.content-length" class="smpl">Content-Length</a> header field is present without <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a>, its decimal value defines the message body length in octets. If the actual number of octets sent in the message is less 1459 than the indicated Content-Length, the recipient <em class="bcp14">MUST</em> consider the message to be incomplete and treat the connection as no longer usable. If the actual number of octets sent in 1460 the message is more than the indicated Content-Length, the recipient <em class="bcp14">MUST</em> only process the message body up to the field value's number of octets; the remainder of the message <em class="bcp14">MUST</em> either be discarded or treated as the next message in a pipeline. For the sake of robustness, a user agent <em class="bcp14">MAY</em> attempt to detect and correct such an error in message framing if it is parsing the response to the last request on a connection 1461 and the connection has been closed by the server. 1455 <p>If a valid <a href="#header.content-length" class="smpl">Content-Length</a> header field is present without <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a>, its decimal value defines the expected message body length in octets. If the sender closes the connection or the recipient 1456 times out before the indicated number of octets are received, the recipient <em class="bcp14">MUST</em> consider the message to be incomplete and close the connection. 1462 1457 </p> 1463 1458 </li> … … 1485 1480 specific user configuration or by remembering the version of a prior received response. 1486 1481 </p> 1482 <p id="rfc.section.3.3.3.p.7">If the final response to the last request on a connection has been completely received and there remains additional data to 1483 read, a user agent <em class="bcp14">MAY</em> discard the remaining data or attempt to determine if that data belongs as part of the prior response body, which might be 1484 the case if the prior message's Content-Length value is incorrect. A client <em class="bcp14">MUST NOT</em> process, cache, or forward such extra data as a separate response, since such behavior would be vulnerable to cache poisoning. 1485 </p> 1487 1486 <h2 id="rfc.section.3.4"><a href="#rfc.section.3.4">3.4</a> <a id="incomplete.messages" href="#incomplete.messages">Handling Incomplete Messages</a></h2> 1488 1487 <p id="rfc.section.3.4.p.1">A server that receives an incomplete request message, usually due to a canceled request or a triggered time-out exception, <em class="bcp14">MAY</em> send an error response prior to closing the connection. 1489 1488 </p> 1490 1489 <p id="rfc.section.3.4.p.2">A client that receives an incomplete response message, which can occur when a connection is closed prematurely or when decoding 1491 a supposedly chunked transfer coding fails, <em class="bcp14">MUST</em> record the message as incomplete. Cache requirements for incomplete responses are defined in <a href="p6-cache.html#response.cacheability" title="Storing Responses in Caches">Section 3</a> of <a href="#Part6" id="rfc.xref.Part6. 5"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>.1490 a supposedly chunked transfer coding fails, <em class="bcp14">MUST</em> record the message as incomplete. Cache requirements for incomplete responses are defined in <a href="p6-cache.html#response.cacheability" title="Storing Responses in Caches">Section 3</a> of <a href="#Part6" id="rfc.xref.Part6.4"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>. 1492 1491 </p> 1493 1492 <p id="rfc.section.3.4.p.3">If a response terminates in the middle of the header block (before the empty line is received) and the status code might rely … … 1687 1686 semantics and, if so, where that request is to be directed. 1688 1687 </p> 1689 <p id="rfc.section.5.2.p.2">If the client has a response cache and the request semantics can be satisfied by a cache (<a href="#Part6" id="rfc.xref.Part6. 6"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>), then the request is usually directed to the cache first.1688 <p id="rfc.section.5.2.p.2">If the client has a response cache and the request semantics can be satisfied by a cache (<a href="#Part6" id="rfc.xref.Part6.5"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>), then the request is usually directed to the cache first. 1690 1689 </p> 1691 1690 <p id="rfc.section.5.2.p.3">If the request is not satisfied by a cache, then a typical client will check its configuration to determine whether a proxy … … 1883 1882 by pseudonyms. Senders <em class="bcp14">MUST NOT</em> combine entries which have different received-protocol values. 1884 1883 </p> 1885 <h3 id="rfc.section.5.7.2"><a href="#rfc.section.5.7.2">5.7.2</a> <a id="message.transformation" href="#message.transformation">Transformation</a></h3> 1886 <p id="rfc.section.5.7.2.p.1">If a proxy receives a request-target with a host name that is not a fully qualified domain name, it <em class="bcp14">MAY</em> add its own domain to the host name it received when forwarding the request. A proxy <em class="bcp14">MUST NOT</em> change the host name if it is a fully qualified domain name. 1887 </p> 1888 <p id="rfc.section.5.7.2.p.2">A non-transforming proxy <em class="bcp14">MUST NOT</em> modify the "path-absolute" and "query" parts of the received request-target when forwarding it to the next inbound server, 1884 <h3 id="rfc.section.5.7.2"><a href="#rfc.section.5.7.2">5.7.2</a> <a id="message.transformations" href="#message.transformations">Transformations</a></h3> 1885 <p id="rfc.section.5.7.2.p.1">Some intermediaries include features for transforming messages and their payloads. A transforming proxy might, for example, 1886 convert between image formats in order to save cache space or to reduce the amount of traffic on a slow link. However, operational 1887 problems might occur when these transformations are applied to payloads intended for critical applications, such as medical 1888 imaging or scientific data analysis, particularly when integrity checks or digital signatures are used to ensure that the 1889 payload received is identical to the original. 1890 </p> 1891 <p id="rfc.section.5.7.2.p.2">If a proxy receives a request-target with a host name that is not a fully qualified domain name, it <em class="bcp14">MAY</em> add its own domain to the host name it received when forwarding the request. A proxy <em class="bcp14">MUST NOT</em> change the host name if it is a fully qualified domain name. 1892 </p> 1893 <p id="rfc.section.5.7.2.p.3">A proxy <em class="bcp14">MUST NOT</em> modify the "path-absolute" and "query" parts of the received request-target when forwarding it to the next inbound server, 1889 1894 except as noted above to replace an empty path with "/" or "*". 1890 1895 </p> 1891 <p id="rfc.section.5.7.2.p.3">A non-transforming proxy <em class="bcp14">MUST</em> preserve the message payload (<a href="p2-semantics.html#payload" title="Payload Semantics">Section 3.3</a> of <a href="#Part2" id="rfc.xref.Part2.22"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>), though it <em class="bcp14">MAY</em> change the message body through application or removal of a transfer coding (<a href="#transfer.codings" title="Transfer Codings">Section 4</a>). 1892 </p> 1893 <p id="rfc.section.5.7.2.p.4">A non-transforming proxy <em class="bcp14">SHOULD NOT</em> modify header fields that provide information about the end points of the communication chain, the resource state, or the 1894 selected representation. 1895 </p> 1896 <p id="rfc.section.5.7.2.p.5">A non-transforming proxy <em class="bcp14">MUST NOT</em> modify any of the following fields in a request or response, and it <em class="bcp14">MUST NOT</em> add any of these fields if not already present: 1897 </p> 1898 <ul> 1899 <li><a href="p2-semantics.html#header.allow" class="smpl">Allow</a> (<a href="p2-semantics.html#header.allow" title="Allow">Section 8.4.1</a> of <a href="#Part2" id="rfc.xref.Part2.23"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>) 1900 </li> 1901 <li><a href="p2-semantics.html#header.content-location" class="smpl">Content-Location</a> (<a href="p2-semantics.html#header.content-location" title="Content-Location">Section 3.1.4.2</a> of <a href="#Part2" id="rfc.xref.Part2.24"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>) 1902 </li> 1903 <li>Content-MD5 (<a href="http://tools.ietf.org/html/rfc2616#section-14.15">Section 14.15</a> of <a href="#RFC2616" id="rfc.xref.RFC2616.3"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>) 1904 </li> 1905 <li><a href="p4-conditional.html#header.etag" class="smpl">ETag</a> (<a href="p4-conditional.html#header.etag" title="ETag">Section 2.3</a> of <a href="#Part4" id="rfc.xref.Part4.4"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a>) 1906 </li> 1907 <li><a href="p4-conditional.html#header.last-modified" class="smpl">Last-Modified</a> (<a href="p4-conditional.html#header.last-modified" title="Last-Modified">Section 2.2</a> of <a href="#Part4" id="rfc.xref.Part4.5"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a>) 1908 </li> 1909 <li><a href="p2-semantics.html#header.server" class="smpl">Server</a> (<a href="p2-semantics.html#header.server" title="Server">Section 8.4.2</a> of <a href="#Part2" id="rfc.xref.Part2.25"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>) 1910 </li> 1911 </ul> 1912 <p id="rfc.section.5.7.2.p.6">A non-transforming proxy <em class="bcp14">MUST NOT</em> modify an <a href="p6-cache.html#header.expires" class="smpl">Expires</a> header field (<a href="p6-cache.html#header.expires" title="Expires">Section 7.3</a> of <a href="#Part6" id="rfc.xref.Part6.7"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>) if already present in a response, but it <em class="bcp14">MAY</em> add an <a href="p6-cache.html#header.expires" class="smpl">Expires</a> header field with a field-value identical to that of the <a href="p2-semantics.html#header.date" class="smpl">Date</a> header field. 1913 </p> 1914 <p id="rfc.section.5.7.2.p.7">A proxy <em class="bcp14">MUST NOT</em> modify or add any of the following fields in a message that contains the no-transform cache-control directive: 1915 </p> 1916 <ul> 1917 <li><a href="p2-semantics.html#header.content-encoding" class="smpl">Content-Encoding</a> (<a href="p2-semantics.html#header.content-encoding" title="Content-Encoding">Section 3.1.2.2</a> of <a href="#Part2" id="rfc.xref.Part2.26"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>) 1918 </li> 1919 <li><a href="p5-range.html#header.content-range" class="smpl">Content-Range</a> (<a href="p5-range.html#header.content-range" title="Content-Range">Section 5.2</a> of <a href="#Part5" id="rfc.xref.Part5.2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Range Requests">[Part5]</cite></a>) 1920 </li> 1921 <li><a href="p2-semantics.html#header.content-type" class="smpl">Content-Type</a> (<a href="p2-semantics.html#header.content-type" title="Content-Type">Section 3.1.1.5</a> of <a href="#Part2" id="rfc.xref.Part2.27"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>) 1922 </li> 1923 </ul> 1924 <p id="rfc.section.5.7.2.p.8">A transforming proxy <em class="bcp14">MAY</em> modify or add these fields to a message that does not include no-transform, but if it does so, it <em class="bcp14">MUST</em> add a Warning 214 (Transformation applied) if one does not already appear in the message (see <a href="p6-cache.html#header.warning" title="Warning">Section 7.5</a> of <a href="#Part6" id="rfc.xref.Part6.8"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>). 1925 </p> 1926 <div class="note" id="rfc.section.5.7.2.p.9"> 1927 <p> <b>Warning:</b> Unnecessary modification of header fields might cause authentication failures if stronger authentication mechanisms are introduced 1928 in later versions of HTTP. Such authentication mechanisms <em class="bcp14">MAY</em> rely on the values of header fields not listed here. 1929 </p> 1930 </div> 1896 <p id="rfc.section.5.7.2.p.4">A proxy <em class="bcp14">MUST NOT</em> modify header fields that provide information about the end points of the communication chain, the resource state, or the 1897 selected representation. A proxy <em class="bcp14">MAY</em> change the message body through application or removal of a transfer coding (<a href="#transfer.codings" title="Transfer Codings">Section 4</a>). 1898 </p> 1899 <p id="rfc.section.5.7.2.p.5">A non-transforming proxy <em class="bcp14">MUST</em> preserve the message payload (<a href="p2-semantics.html#payload" title="Payload Semantics">Section 3.3</a> of <a href="#Part2" id="rfc.xref.Part2.22"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). A transforming proxy <em class="bcp14">MUST</em> preserve the payload of a message that contains the no-transform cache-control directive. 1900 </p> 1901 <p id="rfc.section.5.7.2.p.6">A transforming proxy <em class="bcp14">MAY</em> transform the payload of a message that does not contain the no-transform cache-control directive; if the payload is transformed, 1902 the transforming proxy <em class="bcp14">MUST</em> add a Warning 214 (Transformation applied) header field if one does not already appear in the message (see <a href="p6-cache.html#header.warning" title="Warning">Section 7.5</a> of <a href="#Part6" id="rfc.xref.Part6.6"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>). 1903 </p> 1931 1904 <h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a> <a id="connection.management" href="#connection.management">Connection Management</a></h1> 1932 1905 <p id="rfc.section.6.p.1">HTTP messaging is independent of the underlying transport or session-layer connection protocol(s). HTTP only presumes a reliable … … 1949 1922 avoid confusing downstream recipients, a proxy or gateway <em class="bcp14">MUST</em> remove or replace any received connection options before forwarding the message. 1950 1923 </p> 1951 <p id="rfc.section.6.1.p.2">When a header field is used to supply control information for or about the current connection, the sender <em class="bcp14">SHOULD</em> list the corresponding field-name within the "Connection" header field. A proxy or gateway <em class="bcp14">MUST</em> parse a received Connection header field before a message is forwarded and, for each connection-option in this field, remove1924 <p id="rfc.section.6.1.p.2">When a header field aside from Connection is used to supply control information for or about the current connection, the sender <em class="bcp14">MUST</em> list the corresponding field-name within the "Connection" header field. A proxy or gateway <em class="bcp14">MUST</em> parse a received Connection header field before a message is forwarded and, for each connection-option in this field, remove 1952 1925 any header field(s) from the message with the same name as the connection-option, and then remove the Connection header field 1953 1926 itself (or replace it with the intermediary's own connection options for the forwarded message). … … 1963 1936 </pre><p id="rfc.section.6.1.p.6">Connection options are case-insensitive.</p> 1964 1937 <p id="rfc.section.6.1.p.7">A sender <em class="bcp14">MUST NOT</em> include field-names in the Connection header field-value for fields that are defined as expressing constraints for all recipients 1965 in the request or response chain, such as the Cache-Control header field (<a href="p6-cache.html#header.cache-control" title="Cache-Control">Section 7.2</a> of <a href="#Part6" id="rfc.xref.Part6. 9"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>).1938 in the request or response chain, such as the Cache-Control header field (<a href="p6-cache.html#header.cache-control" title="Cache-Control">Section 7.2</a> of <a href="#Part6" id="rfc.xref.Part6.7"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>). 1966 1939 </p> 1967 1940 <p id="rfc.section.6.1.p.8">The connection options do not have to correspond to a header field present in the message, since a connection-specific header … … 1981 1954 </p> 1982 1955 <div id="rfc.figure.u.56"></div><pre class="text"> Connection: close 1983 </pre><p id="rfc.section.6.1.p.12">in either the request or the response header fields indicates that the connection <em class="bcp14"> SHOULD</em> be closed after the current request/response is complete (<a href="#persistent.tear-down" id="rfc.xref.persistent.tear-down.1" title="Tear-down">Section 6.6</a>).1956 </pre><p id="rfc.section.6.1.p.12">in either the request or the response header fields indicates that the connection <em class="bcp14">MUST</em> be closed after the current request/response is complete (<a href="#persistent.tear-down" id="rfc.xref.persistent.tear-down.1" title="Tear-down">Section 6.6</a>). 1984 1957 </p> 1985 1958 <p id="rfc.section.6.1.p.13">A client that does not support <a href="#persistent.connections" class="smpl">persistent connections</a> <em class="bcp14">MUST</em> send the "close" connection option in every request message. … … 2022 1995 <p id="rfc.section.6.3.1.p.2">Clients which assume persistent connections and pipeline immediately after connection establishment <em class="bcp14">SHOULD</em> be prepared to retry their connection if the first pipelined attempt fails. If a client does such a retry, it <em class="bcp14">MUST NOT</em> pipeline before it knows the connection is persistent. Clients <em class="bcp14">MUST</em> also be prepared to resend their requests if the server closes the connection before sending all of the corresponding responses. 2023 1996 </p> 2024 <p id="rfc.section.6.3.1.p.3">Clients <em class="bcp14">SHOULD NOT</em> pipeline requests using non-idempotent request methods or non-idempotent sequences of request methods (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 5.2.2</a> of <a href="#Part2" id="rfc.xref.Part2.2 8"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). Otherwise, a premature termination of the transport connection could lead to indeterminate results. A client wishing to1997 <p id="rfc.section.6.3.1.p.3">Clients <em class="bcp14">SHOULD NOT</em> pipeline requests using non-idempotent request methods or non-idempotent sequences of request methods (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 5.2.2</a> of <a href="#Part2" id="rfc.xref.Part2.23"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). Otherwise, a premature termination of the transport connection could lead to indeterminate results. A client wishing to 2025 1998 send a non-idempotent request <em class="bcp14">SHOULD</em> wait to send that request until it has received the response status line for the previous request. 2026 1999 </p> … … 2028 2001 <p id="rfc.section.6.3.2.p.1">Connections can be closed at any time, with or without intention. Implementations ought to anticipate the need to recover 2029 2002 from asynchronous close events. A client <em class="bcp14">MAY</em> open a new connection and retransmit an aborted sequence of requests without user interaction so long as the request sequence 2030 is idempotent (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 5.2.2</a> of <a href="#Part2" id="rfc.xref.Part2.2 9"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). A client <em class="bcp14">MUST NOT</em> automatically retry non-idempotent request sequences, although user agents <em class="bcp14">MAY</em> offer a human operator the choice of retrying the request(s). Confirmation by user agent software with semantic understanding2003 is idempotent (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 5.2.2</a> of <a href="#Part2" id="rfc.xref.Part2.24"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). A client <em class="bcp14">MUST NOT</em> automatically retry non-idempotent request sequences, although user agents <em class="bcp14">MAY</em> offer a human operator the choice of retrying the request(s). Confirmation by user agent software with semantic understanding 2031 2004 of the application <em class="bcp14">MAY</em> substitute for user confirmation. An automatic retry <em class="bcp14">SHOULD NOT</em> be repeated if a second sequence of requests fails. 2032 2005 </p> … … 2121 2094 </p> 2122 2095 <p id="rfc.section.6.7.p.9">The Upgrade header field only applies to switching application-level protocols on the existing connection; it cannot be used 2123 to switch to a protocol on a different connection. For that purpose, it is more appropriate to use a <a href="p2-semantics.html#status.3xx" class="smpl">3xx (Redirection)</a> response (<a href="p2-semantics.html#status.3xx" title="Redirection 3xx">Section 7.4</a> of <a href="#Part2" id="rfc.xref.Part2. 30"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>).2096 to switch to a protocol on a different connection. For that purpose, it is more appropriate to use a <a href="p2-semantics.html#status.3xx" class="smpl">3xx (Redirection)</a> response (<a href="p2-semantics.html#status.3xx" title="Redirection 3xx">Section 7.4</a> of <a href="#Part2" id="rfc.xref.Part2.25"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). 2124 2097 </p> 2125 2098 <p id="rfc.section.6.7.p.10">This specification only defines the protocol name "HTTP" for use by the family of Hypertext Transfer Protocols, as defined … … 2259 2232 </table> 2260 2233 </div> 2261 <h2 id="rfc.section.7.3"><a href="#rfc.section.7.3">7.3</a> <a id="internet.media.type.http" href="#internet.media.type.http">Internet Media Type Registration s</a></h2>2234 <h2 id="rfc.section.7.3"><a href="#rfc.section.7.3">7.3</a> <a id="internet.media.type.http" href="#internet.media.type.http">Internet Media Type Registration</a></h2> 2262 2235 <p id="rfc.section.7.3.p.1">This document serves as the specification for the Internet media types "message/http" and "application/http". The following 2263 2236 is to be registered with IANA (see <a href="#RFC4288" id="rfc.xref.RFC4288.1"><cite title="Media Type Specifications and Registration Procedures">[RFC4288]</cite></a>). … … 2382 2355 <li>Pointer to specification text</li> 2383 2356 </ul> 2384 <p id="rfc.section.7.4.p.3">Names of transfer codings <em class="bcp14">MUST NOT</em> overlap with names of content codings (<a href="p2-semantics.html#content.codings" title="Content Codings">Section 3.1.2.1</a> of <a href="#Part2" id="rfc.xref.Part2. 31"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>) unless the encoding transformation is identical, as is the case for the compression codings defined in <a href="#compression.codings" title="Compression Codings">Section 4.2</a>.2357 <p id="rfc.section.7.4.p.3">Names of transfer codings <em class="bcp14">MUST NOT</em> overlap with names of content codings (<a href="p2-semantics.html#content.codings" title="Content Codings">Section 3.1.2.1</a> of <a href="#Part2" id="rfc.xref.Part2.26"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>) unless the encoding transformation is identical, as is the case for the compression codings defined in <a href="#compression.codings" title="Compression Codings">Section 4.2</a>. 2385 2358 </p> 2386 2359 <p id="rfc.section.7.4.p.4">Values to be added to this name space require IETF Review (see <a href="http://tools.ietf.org/html/rfc5226#section-4.1">Section 4.1</a> of <a href="#RFC5226" id="rfc.xref.RFC5226.1"><cite title="Guidelines for Writing an IANA Considerations Section in RFCs">[RFC5226]</cite></a>), and <em class="bcp14">MUST</em> conform to the purpose of transfer coding defined in this section. Use of program names for the identification of encoding … … 2389 2362 <p id="rfc.section.7.4.p.5">The registry itself is maintained at <<a href="http://www.iana.org/assignments/http-parameters">http://www.iana.org/assignments/http-parameters</a>>. 2390 2363 </p> 2391 <h2 id="rfc.section.7.5"><a href="#rfc.section.7.5">7.5</a> <a id="transfer.coding.registration" href="#transfer.coding.registration">Transfer Coding Registration s</a></h2>2364 <h2 id="rfc.section.7.5"><a href="#rfc.section.7.5">7.5</a> <a id="transfer.coding.registration" href="#transfer.coding.registration">Transfer Coding Registration</a></h2> 2392 2365 <p id="rfc.section.7.5.p.1">The HTTP Transfer Coding Registry shall be updated with the registrations below:</p> 2393 2366 <div id="rfc.table.2"> … … 2537 2510 that most implementations will choose substantially higher limits. 2538 2511 </p> 2539 <p id="rfc.section.8.6.p.3">This specification also provides a way for servers to reject messages that have request-targets that are too long (<a href="p2-semantics.html#status.414" title="414 URI Too Long">Section 7.5.12</a> of <a href="#Part2" id="rfc.xref.Part2. 32"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>) or request entities that are too large (<a href="p2-semantics.html#status.4xx" title="Client Error 4xx">Section 7.5</a> of <a href="#Part2" id="rfc.xref.Part2.33"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>).2512 <p id="rfc.section.8.6.p.3">This specification also provides a way for servers to reject messages that have request-targets that are too long (<a href="p2-semantics.html#status.414" title="414 URI Too Long">Section 7.5.12</a> of <a href="#Part2" id="rfc.xref.Part2.27"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>) or request entities that are too large (<a href="p2-semantics.html#status.4xx" title="Client Error 4xx">Section 7.5</a> of <a href="#Part2" id="rfc.xref.Part2.28"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). 2540 2513 </p> 2541 2514 <p id="rfc.section.8.6.p.4">Recipients <em class="bcp14">SHOULD</em> carefully limit the extent to which they read other fields, including (but not limited to) request methods, response status … … 2558 2531 </p> 2559 2532 <h1 id="rfc.section.9"><a href="#rfc.section.9">9.</a> <a id="acks" href="#acks">Acknowledgments</a></h1> 2560 <p id="rfc.section.9.p.1">This edition of HTTP/1.1 builds on the many contributions that went into <a href="#RFC1945" id="rfc.xref.RFC1945.2">RFC 1945</a>, <a href="#RFC2068" id="rfc.xref.RFC2068.4">RFC 2068</a>, <a href="#RFC2145" id="rfc.xref.RFC2145.2">RFC 2145</a>, and <a href="#RFC2616" id="rfc.xref.RFC2616. 4">RFC 2616</a>, including substantial contributions made by the previous authors, editors, and working group chairs: Tim Berners-Lee, Ari2533 <p id="rfc.section.9.p.1">This edition of HTTP/1.1 builds on the many contributions that went into <a href="#RFC1945" id="rfc.xref.RFC1945.2">RFC 1945</a>, <a href="#RFC2068" id="rfc.xref.RFC2068.4">RFC 2068</a>, <a href="#RFC2145" id="rfc.xref.RFC2145.2">RFC 2145</a>, and <a href="#RFC2616" id="rfc.xref.RFC2616.3">RFC 2616</a>, including substantial contributions made by the previous authors, editors, and working group chairs: Tim Berners-Lee, Ari 2561 2534 Luotonen, Roy T. Fielding, Henrik Frystyk Nielsen, Jim Gettys, Jeffrey C. Mogul, Larry Masinter, and Paul J. Leach. Mark Nottingham 2562 2535 oversaw this effort as working group chair. … … 2597 2570 A. Shaw, and Zhong Yu. 2598 2571 </p> 2599 <p id="rfc.section.9.p.4">See <a href="http://tools.ietf.org/html/rfc2616#section-16">Section 16</a> of <a href="#RFC2616" id="rfc.xref.RFC2616. 5"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a> for additional acknowledgements from prior revisions.2572 <p id="rfc.section.9.p.4">See <a href="http://tools.ietf.org/html/rfc2616#section-16">Section 16</a> of <a href="#RFC2616" id="rfc.xref.RFC2616.4"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a> for additional acknowledgements from prior revisions. 2600 2573 </p> 2601 2574 <h1 id="rfc.references"><a id="rfc.section.10" href="#rfc.section.10">10.</a> References … … 3265 3238 </li> 3266 3239 <li><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul> 3267 <li><em>Part2</em> <a href="#rfc.xref.Part2.1">1</a>, <a href="#rfc.xref.Part2.2">2.1</a>, <a href="#rfc.xref.Part2.3">2.3</a>, <a href="#rfc.xref.Part2.4">2.7</a>, <a href="#rfc.xref.Part2.5">2.7.1</a>, <a href="#rfc.xref.Part2.6">3.1.1</a>, <a href="#rfc.xref.Part2.7">3.1.1</a>, <a href="#rfc.xref.Part2.8">3.1.2</a>, <a href="#rfc.xref.Part2.9">3.2</a>, <a href="#rfc.xref.Part2.10">3.2.1</a>, <a href="#rfc.xref.Part2.11">3.3</a>, <a href="#rfc.xref.Part2.12">3.3</a>, <a href="#rfc.xref.Part2.13">3.3.1</a>, <a href="#rfc.xref.Part2.14">3.3.2</a>, <a href="#rfc.xref.Part2.15">3.3.2</a>, <a href="#rfc.xref.Part2.16">3.3.2</a>, <a href="#rfc.xref.Part2.17">4.3</a>, <a href="#rfc.xref.Part2.18">5.1</a>, <a href="#rfc.xref.Part2.19">5.3</a>, <a href="#rfc.xref.Part2.20">5.3</a>, <a href="#rfc.xref.Part2.21">5.6</a>, <a href="#rfc.xref.Part2.22">5.7.2</a>, <a href="#rfc.xref.Part2.23"> 5.7.2</a>, <a href="#rfc.xref.Part2.24">5.7.2</a>, <a href="#rfc.xref.Part2.25">5.7.2</a>, <a href="#rfc.xref.Part2.26">5.7.2</a>, <a href="#rfc.xref.Part2.27">5.7.2</a>, <a href="#rfc.xref.Part2.28">6.3.1</a>, <a href="#rfc.xref.Part2.29">6.3.2</a>, <a href="#rfc.xref.Part2.30">6.7</a>, <a href="#rfc.xref.Part2.31">7.4</a>, <a href="#rfc.xref.Part2.32">8.6</a>, <a href="#rfc.xref.Part2.33">8.6</a>, <a href="#Part2"><b>10.1</b></a><ul>3240 <li><em>Part2</em> <a href="#rfc.xref.Part2.1">1</a>, <a href="#rfc.xref.Part2.2">2.1</a>, <a href="#rfc.xref.Part2.3">2.3</a>, <a href="#rfc.xref.Part2.4">2.7</a>, <a href="#rfc.xref.Part2.5">2.7.1</a>, <a href="#rfc.xref.Part2.6">3.1.1</a>, <a href="#rfc.xref.Part2.7">3.1.1</a>, <a href="#rfc.xref.Part2.8">3.1.2</a>, <a href="#rfc.xref.Part2.9">3.2</a>, <a href="#rfc.xref.Part2.10">3.2.1</a>, <a href="#rfc.xref.Part2.11">3.3</a>, <a href="#rfc.xref.Part2.12">3.3</a>, <a href="#rfc.xref.Part2.13">3.3.1</a>, <a href="#rfc.xref.Part2.14">3.3.2</a>, <a href="#rfc.xref.Part2.15">3.3.2</a>, <a href="#rfc.xref.Part2.16">3.3.2</a>, <a href="#rfc.xref.Part2.17">4.3</a>, <a href="#rfc.xref.Part2.18">5.1</a>, <a href="#rfc.xref.Part2.19">5.3</a>, <a href="#rfc.xref.Part2.20">5.3</a>, <a href="#rfc.xref.Part2.21">5.6</a>, <a href="#rfc.xref.Part2.22">5.7.2</a>, <a href="#rfc.xref.Part2.23">6.3.1</a>, <a href="#rfc.xref.Part2.24">6.3.2</a>, <a href="#rfc.xref.Part2.25">6.7</a>, <a href="#rfc.xref.Part2.26">7.4</a>, <a href="#rfc.xref.Part2.27">8.6</a>, <a href="#rfc.xref.Part2.28">8.6</a>, <a href="#Part2"><b>10.1</b></a><ul> 3268 3241 <li><em>Section 2</em> <a href="#rfc.xref.Part2.4">2.7</a></li> 3269 <li><em>Section 3.1.1.5</em> <a href="#rfc.xref.Part2.27">5.7.2</a></li> 3270 <li><em>Section 3.1.2.1</em> <a href="#rfc.xref.Part2.13">3.3.1</a>, <a href="#rfc.xref.Part2.31">7.4</a></li> 3271 <li><em>Section 3.1.2.2</em> <a href="#rfc.xref.Part2.26">5.7.2</a></li> 3272 <li><em>Section 3.1.4.2</em> <a href="#rfc.xref.Part2.24">5.7.2</a></li> 3242 <li><em>Section 3.1.2.1</em> <a href="#rfc.xref.Part2.13">3.3.1</a>, <a href="#rfc.xref.Part2.26">7.4</a></li> 3273 3243 <li><em>Section 3.3</em> <a href="#rfc.xref.Part2.22">5.7.2</a></li> 3274 3244 <li><em>Section 5</em> <a href="#rfc.xref.Part2.6">3.1.1</a></li> 3275 <li><em>Section 5.2.2</em> <a href="#rfc.xref.Part2.2 8">6.3.1</a>, <a href="#rfc.xref.Part2.29">6.3.2</a></li>3245 <li><em>Section 5.2.2</em> <a href="#rfc.xref.Part2.23">6.3.1</a>, <a href="#rfc.xref.Part2.24">6.3.2</a></li> 3276 3246 <li><em>Section 5.3.2</em> <a href="#rfc.xref.Part2.11">3.3</a>, <a href="#rfc.xref.Part2.15">3.3.2</a></li> 3277 3247 <li><em>Section 5.3.6</em> <a href="#rfc.xref.Part2.12">3.3</a>, <a href="#rfc.xref.Part2.16">3.3.2</a>, <a href="#rfc.xref.Part2.19">5.3</a></li> … … 3281 3251 <li><em>Section 7.2</em> <a href="#rfc.xref.Part2.21">5.6</a></li> 3282 3252 <li><em>Section 7.3.4</em> <a href="#rfc.xref.Part2.3">2.3</a></li> 3283 <li><em>Section 7.4</em> <a href="#rfc.xref.Part2. 30">6.7</a></li>3284 <li><em>Section 7.5</em> <a href="#rfc.xref.Part2. 33">8.6</a></li>3285 <li><em>Section 7.5.12</em> <a href="#rfc.xref.Part2.7">3.1.1</a>, <a href="#rfc.xref.Part2. 32">8.6</a></li>3253 <li><em>Section 7.4</em> <a href="#rfc.xref.Part2.25">6.7</a></li> 3254 <li><em>Section 7.5</em> <a href="#rfc.xref.Part2.28">8.6</a></li> 3255 <li><em>Section 7.5.12</em> <a href="#rfc.xref.Part2.7">3.1.1</a>, <a href="#rfc.xref.Part2.27">8.6</a></li> 3286 3256 <li><em>Section 8.1.1.2</em> <a href="#rfc.xref.Part2.9">3.2</a></li> 3287 3257 <li><em>Section 8.2</em> <a href="#rfc.xref.Part2.14">3.3.2</a></li> 3288 <li><em>Section 8.4.1</em> <a href="#rfc.xref.Part2.23">5.7.2</a></li>3289 <li><em>Section 8.4.2</em> <a href="#rfc.xref.Part2.25">5.7.2</a></li>3290 3258 <li><em>Section 9.3</em> <a href="#rfc.xref.Part2.10">3.2.1</a></li> 3291 3259 <li><em>Appendix A</em> <a href="#rfc.xref.Part2.2">2.1</a></li> 3292 3260 </ul> 3293 3261 </li> 3294 <li><em>Part4</em> <a href="#rfc.xref.Part4.1">1</a>, <a href="#rfc.xref.Part4.2">3.3.1</a>, <a href="#rfc.xref.Part4.3">3.3.2</a>, <a href="#rfc.xref.Part4.4">5.7.2</a>, <a href="#rfc.xref.Part4.5">5.7.2</a>, <a href="#Part4"><b>10.1</b></a><ul> 3295 <li><em>Section 2.2</em> <a href="#rfc.xref.Part4.5">5.7.2</a></li> 3296 <li><em>Section 2.3</em> <a href="#rfc.xref.Part4.4">5.7.2</a></li> 3262 <li><em>Part4</em> <a href="#rfc.xref.Part4.1">1</a>, <a href="#rfc.xref.Part4.2">3.3.1</a>, <a href="#rfc.xref.Part4.3">3.3.2</a>, <a href="#Part4"><b>10.1</b></a><ul> 3297 3263 <li><em>Section 4.1</em> <a href="#rfc.xref.Part4.2">3.3.1</a>, <a href="#rfc.xref.Part4.3">3.3.2</a></li> 3298 3264 </ul> 3299 3265 </li> 3300 <li><em>Part5</em> <a href="#rfc.xref.Part5.1">1</a>, <a href="#rfc.xref.Part5.2">5.7.2</a>, <a href="#Part5"><b>10.1</b></a><ul> 3301 <li><em>Section 5.2</em> <a href="#rfc.xref.Part5.2">5.7.2</a></li> 3302 </ul> 3303 </li> 3304 <li><em>Part6</em> <a href="#rfc.xref.Part6.1">1</a>, <a href="#rfc.xref.Part6.2">2.3</a>, <a href="#rfc.xref.Part6.3">2.4</a>, <a href="#rfc.xref.Part6.4">2.7.2</a>, <a href="#rfc.xref.Part6.5">3.4</a>, <a href="#rfc.xref.Part6.6">5.2</a>, <a href="#rfc.xref.Part6.7">5.7.2</a>, <a href="#rfc.xref.Part6.8">5.7.2</a>, <a href="#rfc.xref.Part6.9">6.1</a>, <a href="#Part6"><b>10.1</b></a><ul> 3266 <li><em>Part5</em> <a href="#rfc.xref.Part5.1">1</a>, <a href="#Part5"><b>10.1</b></a></li> 3267 <li><em>Part6</em> <a href="#rfc.xref.Part6.1">1</a>, <a href="#rfc.xref.Part6.2">2.3</a>, <a href="#rfc.xref.Part6.3">2.4</a>, <a href="#rfc.xref.Part6.4">3.4</a>, <a href="#rfc.xref.Part6.5">5.2</a>, <a href="#rfc.xref.Part6.6">5.7.2</a>, <a href="#rfc.xref.Part6.7">6.1</a>, <a href="#Part6"><b>10.1</b></a><ul> 3305 3268 <li><em>Section 2</em> <a href="#rfc.xref.Part6.3">2.4</a></li> 3306 <li><em>Section 3</em> <a href="#rfc.xref.Part6.5">3.4</a></li> 3307 <li><em>Section 7.2</em> <a href="#rfc.xref.Part6.4">2.7.2</a>, <a href="#rfc.xref.Part6.9">6.1</a></li> 3308 <li><em>Section 7.3</em> <a href="#rfc.xref.Part6.7">5.7.2</a></li> 3309 <li><em>Section 7.5</em> <a href="#rfc.xref.Part6.2">2.3</a>, <a href="#rfc.xref.Part6.8">5.7.2</a></li> 3269 <li><em>Section 3</em> <a href="#rfc.xref.Part6.4">3.4</a></li> 3270 <li><em>Section 7.2</em> <a href="#rfc.xref.Part6.7">6.1</a></li> 3271 <li><em>Section 7.5</em> <a href="#rfc.xref.Part6.2">2.3</a>, <a href="#rfc.xref.Part6.6">5.7.2</a></li> 3310 3272 </ul> 3311 3273 </li> … … 3337 3299 <li><em>RFC2119</em> <a href="#rfc.xref.RFC2119.1">1.1</a>, <a href="#RFC2119"><b>10.1</b></a></li> 3338 3300 <li><em>RFC2145</em> <a href="#rfc.xref.RFC2145.1">1</a>, <a href="#rfc.xref.RFC2145.2">9</a>, <a href="#RFC2145"><b>10.2</b></a></li> 3339 <li><em>RFC2616</em> <a href="#rfc.xref.RFC2616.1">1</a>, <a href="#rfc.xref.RFC2616.2">2.6</a>, <a href="#rfc.xref.RFC2616.3">5.7.2</a>, <a href="#rfc.xref.RFC2616.4">9</a>, <a href="#rfc.xref.RFC2616.5">9</a>, <a href="#RFC2616"><b>10.2</b></a><ul> 3340 <li><em>Section 14.15</em> <a href="#rfc.xref.RFC2616.3">5.7.2</a></li> 3341 <li><em>Section 16</em> <a href="#rfc.xref.RFC2616.5">9</a></li> 3301 <li><em>RFC2616</em> <a href="#rfc.xref.RFC2616.1">1</a>, <a href="#rfc.xref.RFC2616.2">2.6</a>, <a href="#rfc.xref.RFC2616.3">9</a>, <a href="#rfc.xref.RFC2616.4">9</a>, <a href="#RFC2616"><b>10.2</b></a><ul> 3302 <li><em>Section 16</em> <a href="#rfc.xref.RFC2616.4">9</a></li> 3342 3303 </ul> 3343 3304 </li>
Note: See TracChangeset
for help on using the changeset viewer.