Ignore:
Timestamp:
06/05/14 08:10:18 (6 years ago)
Author:
julian.reschke@…
Message:

insert RFC numbers (#553)

File:
1 edited

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpbis/latest/p1-messaging.html

    r2628 r2629  
    463463  }
    464464  @bottom-center {
    465        content: "Expires November 2, 2014";
     465       content: "Expires November 7, 2014";
    466466  }
    467467  @bottom-right {
     
    505505      <meta name="dct.creator" content="Reschke, J. F.">
    506506      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p1-messaging-latest">
    507       <meta name="dct.issued" scheme="ISO8601" content="2014-05-01">
     507      <meta name="dct.issued" scheme="ISO8601" content="2014-05-06">
    508508      <meta name="dct.replaces" content="urn:ietf:rfc:2145">
    509509      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
     
    534534            <tr>
    535535               <td class="left">Intended status: Standards Track</td>
    536                <td class="right">May 1, 2014</td>
     536               <td class="right">May 6, 2014</td>
    537537            </tr>
    538538            <tr>
    539                <td class="left">Expires: November 2, 2014</td>
     539               <td class="left">Expires: November 7, 2014</td>
    540540               <td class="right"></td>
    541541            </tr>
     
    566566            in progress”.
    567567         </p>
    568          <p>This Internet-Draft will expire on November 2, 2014.</p>
     568         <p>This Internet-Draft will expire on November 7, 2014.</p>
    569569      </div>
    570570      <div id="rfc.copyrightnotice">
     
    750750         </p>
    751751         <ul class="empty">
    752             <li>RFC xxx1: Message Syntax and Routing</li>
    753             <li><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content" id="rfc.xref.Part2.1">RFC xxx2</cite>: Semantics and Content
     752            <li>RFC 7230: Message Syntax and Routing</li>
     753            <li><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content" id="rfc.xref.RFC7231.1">RFC 7231</cite>: Semantics and Content
    754754            </li>
    755             <li><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests" id="rfc.xref.Part4.1">RFC xxx3</cite>: Conditional Requests
     755            <li><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests" id="rfc.xref.RFC7232.1">RFC 7232</cite>: Conditional Requests
    756756            </li>
    757             <li><cite title="Hypertext Transfer Protocol (HTTP/1.1): Range Requests" id="rfc.xref.Part5.1">RFC xxx4</cite>: Range Requests
     757            <li><cite title="Hypertext Transfer Protocol (HTTP/1.1): Range Requests" id="rfc.xref.RFC7233.1">RFC 7233</cite>: Range Requests
    758758            </li>
    759             <li><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching" id="rfc.xref.Part6.1">RFC xxx5</cite>: Caching
     759            <li><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching" id="rfc.xref.RFC7234.1">RFC 7234</cite>: Caching
    760760            </li>
    761             <li><cite title="Hypertext Transfer Protocol (HTTP/1.1): Authentication" id="rfc.xref.Part7.1">RFC xxx6</cite>: Authentication
     761            <li><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching" id="rfc.xref.RFC7234.2">RFC 7235</cite>: Authentication
    762762            </li>
    763763         </ul>
     
    842842               robots), command-line tools, custom applications, and mobile apps. The term "<dfn>origin server</dfn>" refers to the program that can originate authoritative responses for a given target resource. The terms "<dfn>sender</dfn>" and "<dfn>recipient</dfn>" refer to any implementation that sends or receives a given message, respectively.
    843843            </p>
    844             <p id="rfc.section.2.1.p.3">HTTP relies upon the Uniform Resource Identifier (URI) standard <a href="#RFC3986" id="rfc.xref.RFC3986.1"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a> to indicate the target resource (<a href="#target-resource" title="Identifying a Target Resource">Section&nbsp;5.1</a>) and relationships between resources. Messages are passed in a format similar to that used by Internet mail <a href="#RFC5322" id="rfc.xref.RFC5322.1"><cite title="Internet Message Format">[RFC5322]</cite></a> and the Multipurpose Internet Mail Extensions (MIME) <a href="#RFC2045" id="rfc.xref.RFC2045.1"><cite title="Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies">[RFC2045]</cite></a> (see <a href="p2-semantics.html#differences.between.http.and.mime" title="Differences between HTTP and MIME">Appendix A</a> of <a href="#Part2" id="rfc.xref.Part2.2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a> for the differences between HTTP and MIME messages).
     844            <p id="rfc.section.2.1.p.3">HTTP relies upon the Uniform Resource Identifier (URI) standard <a href="#RFC3986" id="rfc.xref.RFC3986.1"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a> to indicate the target resource (<a href="#target-resource" title="Identifying a Target Resource">Section&nbsp;5.1</a>) and relationships between resources. Messages are passed in a format similar to that used by Internet mail <a href="#RFC5322" id="rfc.xref.RFC5322.1"><cite title="Internet Message Format">[RFC5322]</cite></a> and the Multipurpose Internet Mail Extensions (MIME) <a href="#RFC2045" id="rfc.xref.RFC2045.1"><cite title="Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies">[RFC2045]</cite></a> (see <a href="p2-semantics.html#differences.between.http.and.mime" title="Differences between HTTP and MIME">Appendix A</a> of <a href="#RFC7231" id="rfc.xref.RFC7231.2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[RFC7231]</cite></a> for the differences between HTTP and MIME messages).
    845845            </p>
    846846            <p id="rfc.section.2.1.p.4">Most HTTP communication consists of a retrieval request (GET) for a representation of some resource identified by a URI. In
     
    861861            <p id="rfc.section.2.1.p.8">A connection might be used for multiple request/response exchanges, as defined in <a href="#persistent.connections" title="Persistence">Section&nbsp;6.3</a>.
    862862            </p>
    863             <p id="rfc.section.2.1.p.9">The following example illustrates a typical message exchange for a GET request (<a href="p2-semantics.html#GET" title="GET">Section 4.3.1</a> of <a href="#Part2" id="rfc.xref.Part2.3"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>) on the URI "http://www.example.com/hello.txt":
     863            <p id="rfc.section.2.1.p.9">The following example illustrates a typical message exchange for a GET request (<a href="p2-semantics.html#GET" title="GET">Section 4.3.1</a> of <a href="#RFC7231" id="rfc.xref.RFC7231.3"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[RFC7231]</cite></a>) on the URI "http://www.example.com/hello.txt":
    864864            </p>
    865865            <div id="rfc.figure.u.2"></div>
     
    977977</pre><p id="rfc.section.2.4.p.4"><span id="rfc.iref.c.5"></span> A response is "<dfn>cacheable</dfn>" if a cache is allowed to store a copy of the response message for use in answering subsequent requests. Even when a response
    978978               is cacheable, there might be additional constraints placed by the client or by the origin server on when that cached response
    979                can be used for a particular request. HTTP requirements for cache behavior and cacheable responses are defined in <a href="p6-cache.html#caching.overview" title="Overview of Cache Operation">Section 2</a> of <a href="#Part6" id="rfc.xref.Part6.2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>.
     979               can be used for a particular request. HTTP requirements for cache behavior and cacheable responses are defined in <a href="p6-cache.html#caching.overview" title="Overview of Cache Operation">Section 2</a> of <a href="#RFC7234" id="rfc.xref.RFC7234.3"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[RFC7234]</cite></a>.
    980980            </p>
    981981            <p id="rfc.section.2.4.p.5">There are a wide variety of architectures and configurations of caches deployed across the World Wide Web and inside large
     
    10901090            <div id="rfc.iref.r.5"></div>
    10911091            <h2 id="rfc.section.2.7"><a href="#rfc.section.2.7">2.7</a>&nbsp;<a href="#uri">Uniform Resource Identifiers</a></h2>
    1092             <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.
     1092            <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="#RFC7231" id="rfc.xref.RFC7231.4"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[RFC7231]</cite></a>). URI references are used to target requests, indicate redirects, and define relationships.
    10931093            </p>
    10941094            <p id="rfc.section.2.7.p.2">The definitions of "URI-reference", "absolute-URI", "relative-part", "scheme", "authority", "port", "host", "path-abempty",
     
    11441144               </p>
    11451145               <p id="rfc.section.2.7.1.p.7">When an "http" URI is used within a context that calls for access to the indicated resource, a client <em class="bcp14">MAY</em> attempt access by resolving the host to an IP address, establishing a TCP connection to that address on the indicated port,
    1146                   and sending an HTTP request message (<a href="#http.message" title="Message Format">Section&nbsp;3</a>) containing the URI's identifying data (<a href="#message.routing" title="Message Routing">Section&nbsp;5</a>) to the server. If the server responds to that request with a non-interim HTTP response message, as described in <a href="p2-semantics.html#status.codes" title="Response Status Codes">Section 6</a> of <a href="#Part2" id="rfc.xref.Part2.5"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>, then that response is considered an authoritative answer to the client's request.
     1146                  and sending an HTTP request message (<a href="#http.message" title="Message Format">Section&nbsp;3</a>) containing the URI's identifying data (<a href="#message.routing" title="Message Routing">Section&nbsp;5</a>) to the server. If the server responds to that request with a non-interim HTTP response message, as described in <a href="p2-semantics.html#status.codes" title="Response Status Codes">Section 6</a> of <a href="#RFC7231" id="rfc.xref.RFC7231.5"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[RFC7231]</cite></a>, then that response is considered an authoritative answer to the client's request.
    11471147               </p>
    11481148               <p id="rfc.section.2.7.1.p.8">Although HTTP is independent of the transport protocol, the "http" scheme is specific to TCP-based services because the name
     
    12571257               </div>
    12581258               <div id="rfc.figure.u.14"></div><pre class="inline"><span id="rfc.iref.g.32"></span>  <a href="#method" class="smpl">method</a>         = <a href="#rule.token.separators" class="smpl">token</a>
    1259 </pre><p id="rfc.section.3.1.1.p.5">The request methods defined by this specification can be found in <a href="p2-semantics.html#methods" title="Request Methods">Section 4</a> of <a href="#Part2" id="rfc.xref.Part2.6"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>, along with information regarding the HTTP method registry and considerations for defining new methods.
     1259</pre><p id="rfc.section.3.1.1.p.5">The request methods defined by this specification can be found in <a href="p2-semantics.html#methods" title="Request Methods">Section 4</a> of <a href="#RFC7231" id="rfc.xref.RFC7231.6"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[RFC7231]</cite></a>, along with information regarding the HTTP method registry and considerations for defining new methods.
    12601260               </p>
    12611261               <div id="rfc.iref.r.6"></div>
     
    12681268                  crafted to bypass security filters along the request chain.
    12691269               </p>
    1270                <p id="rfc.section.3.1.1.p.9">HTTP does not place a pre-defined limit on the length of a request-line, as described in <a href="#conformance" title="Conformance and Error Handling">Section&nbsp;2.5</a>. A server that receives a method longer than any that it implements <em class="bcp14">SHOULD</em> respond with a <a href="p2-semantics.html#status.501" class="smpl">501 (Not Implemented)</a> status code. A server that receives a request-target longer than any URI it wishes to parse <em class="bcp14">MUST</em> respond with a <a href="p2-semantics.html#status.414" class="smpl">414 (URI Too Long)</a> status code (see <a href="p2-semantics.html#status.414" title="414 URI Too Long">Section 6.5.12</a> of <a href="#Part2" id="rfc.xref.Part2.7"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>).
     1270               <p id="rfc.section.3.1.1.p.9">HTTP does not place a pre-defined limit on the length of a request-line, as described in <a href="#conformance" title="Conformance and Error Handling">Section&nbsp;2.5</a>. A server that receives a method longer than any that it implements <em class="bcp14">SHOULD</em> respond with a <a href="p2-semantics.html#status.501" class="smpl">501 (Not Implemented)</a> status code. A server that receives a request-target longer than any URI it wishes to parse <em class="bcp14">MUST</em> respond with a <a href="p2-semantics.html#status.414" class="smpl">414 (URI Too Long)</a> status code (see <a href="p2-semantics.html#status.414" title="414 URI Too Long">Section 6.5.12</a> of <a href="#RFC7231" id="rfc.xref.RFC7231.7"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[RFC7231]</cite></a>).
    12711271               </p>
    12721272               <p id="rfc.section.3.1.1.p.10">Various ad-hoc limitations on request-line length are found in practice. It is <em class="bcp14">RECOMMENDED</em> that all HTTP senders and recipients support, at a minimum, request-line lengths of 8000 octets.
     
    12811281</pre><p id="rfc.section.3.1.2.p.3">The status-code element is a 3-digit integer code describing the result of the server's attempt to understand and satisfy
    12821282                  the client's corresponding request. The rest of the response message is to be interpreted in light of the semantics defined
    1283                   for that status code. See <a href="p2-semantics.html#status.codes" title="Response Status Codes">Section 6</a> of <a href="#Part2" id="rfc.xref.Part2.8"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a> for information about the semantics of status codes, including the classes of status code (indicated by the first digit),
     1283                  for that status code. See <a href="p2-semantics.html#status.codes" title="Response Status Codes">Section 6</a> of <a href="#RFC7231" id="rfc.xref.RFC7231.8"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[RFC7231]</cite></a> for information about the semantics of status codes, including the classes of status code (indicated by the first digit),
    12841284                  the status codes defined by this specification, considerations for the definition of new status codes, and the IANA registry.
    12851285               </p>
     
    13081308                 ; see <a href="#field.parsing" title="Field Parsing">Section&nbsp;3.2.4</a>
    13091309</pre><p id="rfc.section.3.2.p.3">The field-name token labels the corresponding field-value as having the semantics defined by that header field. For example,
    1310                the <a href="p2-semantics.html#header.date" class="smpl">Date</a> header field is defined in <a href="p2-semantics.html#header.date" title="Date">Section 7.1.1.2</a> of <a href="#Part2" id="rfc.xref.Part2.9"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a> as containing the origination timestamp for the message in which it appears.
     1310               the <a href="p2-semantics.html#header.date" class="smpl">Date</a> header field is defined in <a href="p2-semantics.html#header.date" title="Date">Section 7.1.1.2</a> of <a href="#RFC7231" id="rfc.xref.RFC7231.9"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[RFC7231]</cite></a> as containing the origination timestamp for the message in which it appears.
    13111311            </p>
    13121312            <div id="field.extensibility">
     
    13221322                  of deployed intermediaries.
    13231323               </p>
    1324                <p id="rfc.section.3.2.1.p.4">All defined 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>.
     1324               <p id="rfc.section.3.2.1.p.4">All defined 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="#RFC7231" id="rfc.xref.RFC7231.10"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[RFC7231]</cite></a>.
    13251325               </p>
    13261326            </div>
     
    14691469            </p>
    14701470            <p id="rfc.section.3.3.p.5">The presence of a message body in a response depends on both the request method to which it is responding and the response
    1471                status code (<a href="#status.line" title="Status Line">Section&nbsp;3.1.2</a>). Responses to the HEAD request method (<a href="p2-semantics.html#HEAD" title="HEAD">Section 4.3.2</a> of <a href="#Part2" id="rfc.xref.Part2.11"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>) never include a message body because the associated response header fields (e.g., <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a>, <a href="#header.content-length" class="smpl">Content-Length</a>, etc.), if present, indicate only what their values would have been if the request method had been GET (<a href="p2-semantics.html#GET" title="GET">Section 4.3.1</a> of <a href="#Part2" id="rfc.xref.Part2.12"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). <a href="p2-semantics.html#status.2xx" class="smpl">2xx (Successful)</a> responses to a CONNECT request method (<a href="p2-semantics.html#CONNECT" title="CONNECT">Section 4.3.6</a> of <a href="#Part2" id="rfc.xref.Part2.13"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>) switch to tunnel mode instead of having a message body. All <a href="p2-semantics.html#status.1xx" class="smpl">1xx (Informational)</a>, <a href="p2-semantics.html#status.204" class="smpl">204 (No Content)</a>, and <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a> responses do not include a message body. All other responses do include a message body, although the body might be of zero
     1471               status code (<a href="#status.line" title="Status Line">Section&nbsp;3.1.2</a>). Responses to the HEAD request method (<a href="p2-semantics.html#HEAD" title="HEAD">Section 4.3.2</a> of <a href="#RFC7231" id="rfc.xref.RFC7231.11"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[RFC7231]</cite></a>) never include a message body because the associated response header fields (e.g., <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a>, <a href="#header.content-length" class="smpl">Content-Length</a>, etc.), if present, indicate only what their values would have been if the request method had been GET (<a href="p2-semantics.html#GET" title="GET">Section 4.3.1</a> of <a href="#RFC7231" id="rfc.xref.RFC7231.12"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[RFC7231]</cite></a>). <a href="p2-semantics.html#status.2xx" class="smpl">2xx (Successful)</a> responses to a CONNECT request method (<a href="p2-semantics.html#CONNECT" title="CONNECT">Section 4.3.6</a> of <a href="#RFC7231" id="rfc.xref.RFC7231.13"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[RFC7231]</cite></a>) switch to tunnel mode instead of having a message body. All <a href="p2-semantics.html#status.1xx" class="smpl">1xx (Informational)</a>, <a href="p2-semantics.html#status.204" class="smpl">204 (No Content)</a>, and <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a> responses do not include a message body. All other responses do include a message body, although the body might be of zero
    14721472               length.
    14731473            </p>
     
    14941494                  forming the message body.
    14951495               </p>
    1496                <p id="rfc.section.3.3.1.p.6">Unlike <a href="p2-semantics.html#header.content-encoding" class="smpl">Content-Encoding</a> (<a href="p2-semantics.html#content.codings" title="Content Codings">Section 3.1.2.1</a> of <a href="#Part2" id="rfc.xref.Part2.14"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>), Transfer-Encoding is a property of the message, not of the representation, and any recipient along the request/response
     1496               <p id="rfc.section.3.3.1.p.6">Unlike <a href="p2-semantics.html#header.content-encoding" class="smpl">Content-Encoding</a> (<a href="p2-semantics.html#content.codings" title="Content Codings">Section 3.1.2.1</a> of <a href="#RFC7231" id="rfc.xref.RFC7231.14"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[RFC7231]</cite></a>), Transfer-Encoding is a property of the message, not of the representation, and any recipient along the request/response
    14971497                  chain <em class="bcp14">MAY</em> decode the received transfer coding(s) or apply additional transfer coding(s) to the message body, assuming that corresponding
    14981498                  changes are made to the Transfer-Encoding field-value. Additional information about the encoding parameters can be provided
    14991499                  by other header fields not defined by this specification.
    15001500               </p>
    1501                <p id="rfc.section.3.3.1.p.7">Transfer-Encoding <em class="bcp14">MAY</em> be sent in a response to a HEAD request or in a <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a> response (<a href="p4-conditional.html#status.304" title="304 Not Modified">Section 4.1</a> of <a href="#Part4" id="rfc.xref.Part4.2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a>) to a GET request, neither of which includes a message body, to indicate that the origin server would have applied a transfer
     1501               <p id="rfc.section.3.3.1.p.7">Transfer-Encoding <em class="bcp14">MAY</em> be sent in a response to a HEAD request or in a <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a> response (<a href="p4-conditional.html#status.304" title="304 Not Modified">Section 4.1</a> of <a href="#RFC7232" id="rfc.xref.RFC7232.2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[RFC7232]</cite></a>) to a GET request, neither of which includes a message body, to indicate that the origin server would have applied a transfer
    15021502                  coding to the message body if the request had been an unconditional GET. This indication is not required, however, because
    15031503                  any recipient on the response chain (including the origin server) can remove transfer codings when they are not needed.
    15041504               </p>
    1505                <p id="rfc.section.3.3.1.p.8">A server <em class="bcp14">MUST NOT</em> send a Transfer-Encoding header field in any response with a status code of <a href="p2-semantics.html#status.1xx" class="smpl">1xx (Informational)</a> or <a href="p2-semantics.html#status.204" class="smpl">204 (No Content)</a>. A server <em class="bcp14">MUST NOT</em> send a Transfer-Encoding header field in any <a href="p2-semantics.html#status.2xx" class="smpl">2xx (Successful)</a> response to a CONNECT request (<a href="p2-semantics.html#CONNECT" title="CONNECT">Section 4.3.6</a> of <a href="#Part2" id="rfc.xref.Part2.15"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>).
     1505               <p id="rfc.section.3.3.1.p.8">A server <em class="bcp14">MUST NOT</em> send a Transfer-Encoding header field in any response with a status code of <a href="p2-semantics.html#status.1xx" class="smpl">1xx (Informational)</a> or <a href="p2-semantics.html#status.204" class="smpl">204 (No Content)</a>. A server <em class="bcp14">MUST NOT</em> send a Transfer-Encoding header field in any <a href="p2-semantics.html#status.2xx" class="smpl">2xx (Successful)</a> response to a CONNECT request (<a href="p2-semantics.html#CONNECT" title="CONNECT">Section 4.3.6</a> of <a href="#RFC7231" id="rfc.xref.RFC7231.15"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[RFC7231]</cite></a>).
    15061506               </p>
    15071507               <p id="rfc.section.3.3.1.p.9">Transfer-Encoding was added in HTTP/1.1. It is generally assumed that implementations advertising only HTTP/1.0 support will
     
    15181518                  payload body. For messages that do include a payload body, the Content-Length field-value provides the framing information
    15191519                  necessary for determining where the body (and message) ends. For messages that do not include a payload body, the Content-Length
    1520                   indicates the size of the selected representation (<a href="p2-semantics.html#representations" title="Representations">Section 3</a> of <a href="#Part2" id="rfc.xref.Part2.16"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>).
     1520                  indicates the size of the selected representation (<a href="p2-semantics.html#representations" title="Representations">Section 3</a> of <a href="#RFC7231" id="rfc.xref.RFC7231.16"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[RFC7231]</cite></a>).
    15211521               </p>
    15221522               <div id="rfc.figure.u.27"></div><pre class="inline"><span id="rfc.iref.g.55"></span>  <a href="#header.content-length" class="smpl">Content-Length</a> = 1*<a href="#core.rules" class="smpl">DIGIT</a>
     
    15291529                  anticipate such a body.
    15301530               </p>
    1531                <p id="rfc.section.3.3.2.p.7">A server <em class="bcp14">MAY</em> send a Content-Length header field in a response to a HEAD request (<a href="p2-semantics.html#HEAD" title="HEAD">Section 4.3.2</a> of <a href="#Part2" id="rfc.xref.Part2.17"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>); a server <em class="bcp14">MUST NOT</em> send Content-Length in such a response unless its field-value equals the decimal number of octets that would have been sent
     1531               <p id="rfc.section.3.3.2.p.7">A server <em class="bcp14">MAY</em> send a Content-Length header field in a response to a HEAD request (<a href="p2-semantics.html#HEAD" title="HEAD">Section 4.3.2</a> of <a href="#RFC7231" id="rfc.xref.RFC7231.17"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[RFC7231]</cite></a>); a server <em class="bcp14">MUST NOT</em> send Content-Length in such a response unless its field-value equals the decimal number of octets that would have been sent
    15321532                  in the payload body of a response if the same request had used the GET method.
    15331533               </p>
    1534                <p id="rfc.section.3.3.2.p.8">A server <em class="bcp14">MAY</em> send a Content-Length header field in a <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a> response to a conditional GET request (<a href="p4-conditional.html#status.304" title="304 Not Modified">Section 4.1</a> of <a href="#Part4" id="rfc.xref.Part4.3"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a>); a server <em class="bcp14">MUST NOT</em> send Content-Length in such a response unless its field-value equals the decimal number of octets that would have been sent
     1534               <p id="rfc.section.3.3.2.p.8">A server <em class="bcp14">MAY</em> send a Content-Length header field in a <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a> response to a conditional GET request (<a href="p4-conditional.html#status.304" title="304 Not Modified">Section 4.1</a> of <a href="#RFC7232" id="rfc.xref.RFC7232.3"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[RFC7232]</cite></a>); a server <em class="bcp14">MUST NOT</em> send Content-Length in such a response unless its field-value equals the decimal number of octets that would have been sent
    15351535                  in the payload body of a <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> response to the same request.
    15361536               </p>
    1537                <p id="rfc.section.3.3.2.p.9">A server <em class="bcp14">MUST NOT</em> send a Content-Length header field in any response with a status code of <a href="p2-semantics.html#status.1xx" class="smpl">1xx (Informational)</a> or <a href="p2-semantics.html#status.204" class="smpl">204 (No Content)</a>. A server <em class="bcp14">MUST NOT</em> send a Content-Length header field in any <a href="p2-semantics.html#status.2xx" class="smpl">2xx (Successful)</a> response to a CONNECT request (<a href="p2-semantics.html#CONNECT" title="CONNECT">Section 4.3.6</a> of <a href="#Part2" id="rfc.xref.Part2.18"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>).
     1537               <p id="rfc.section.3.3.2.p.9">A server <em class="bcp14">MUST NOT</em> send a Content-Length header field in any response with a status code of <a href="p2-semantics.html#status.1xx" class="smpl">1xx (Informational)</a> or <a href="p2-semantics.html#status.204" class="smpl">204 (No Content)</a>. A server <em class="bcp14">MUST NOT</em> send a Content-Length header field in any <a href="p2-semantics.html#status.2xx" class="smpl">2xx (Successful)</a> response to a CONNECT request (<a href="p2-semantics.html#CONNECT" title="CONNECT">Section 4.3.6</a> of <a href="#RFC7231" id="rfc.xref.RFC7231.18"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[RFC7231]</cite></a>).
    15381538               </p>
    15391539               <p id="rfc.section.3.3.2.p.10">Aside from the cases defined above, in the absence of Transfer-Encoding, an origin server <em class="bcp14">SHOULD</em> send a Content-Length header field when the payload body size is known prior to sending the complete header section. This
     
    16281628            </p>
    16291629            <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
    1630                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.3"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>.
     1630               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="#RFC7234" id="rfc.xref.RFC7234.4"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[RFC7234]</cite></a>.
    16311631            </p>
    16321632            <p id="rfc.section.3.4.p.3">If a response terminates in the middle of the header section (before the empty line is received) and the status code might
     
    17331733               </p>
    17341734               <div id="rfc.figure.u.33"></div><pre class="inline"><span id="rfc.iref.g.70"></span><span id="rfc.iref.g.71"></span>  <a href="#chunked.trailer.part" class="smpl">trailer-part</a>   = *( <a href="#header.fields" class="smpl">header-field</a> <a href="#core.rules" class="smpl">CRLF</a> )
    1735 </pre><p id="rfc.section.4.1.2.p.3">A sender <em class="bcp14">MUST NOT</em> generate a trailer that contains a field necessary for message framing (e.g., <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a> and <a href="#header.content-length" class="smpl">Content-Length</a>), routing (e.g., <a href="#header.host" class="smpl">Host</a>), request modifiers (e.g., controls and conditionals in <a href="p2-semantics.html#request.header.fields" title="Request Header Fields">Section 5</a> of <a href="#Part2" id="rfc.xref.Part2.19"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>), authentication (e.g., see <a href="#Part7" id="rfc.xref.Part7.2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Authentication">[Part7]</cite></a> and <a href="#RFC6265" id="rfc.xref.RFC6265.3"><cite title="HTTP State Management Mechanism">[RFC6265]</cite></a>), response control data (e.g., see <a href="p2-semantics.html#response.control.data" title="Control Data">Section 7.1</a> of <a href="#Part2" id="rfc.xref.Part2.20"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>), or determining how to process the payload (e.g., <a href="p2-semantics.html#header.content-encoding" class="smpl">Content-Encoding</a>, <a href="p2-semantics.html#header.content-type" class="smpl">Content-Type</a>, <a href="p5-range.html#header.content-range" class="smpl">Content-Range</a>, and <a href="#header.trailer" class="smpl">Trailer</a>).
     1735</pre><p id="rfc.section.4.1.2.p.3">A sender <em class="bcp14">MUST NOT</em> generate a trailer that contains a field necessary for message framing (e.g., <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a> and <a href="#header.content-length" class="smpl">Content-Length</a>), routing (e.g., <a href="#header.host" class="smpl">Host</a>), request modifiers (e.g., controls and conditionals in <a href="p2-semantics.html#request.header.fields" title="Request Header Fields">Section 5</a> of <a href="#RFC7231" id="rfc.xref.RFC7231.19"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[RFC7231]</cite></a>), authentication (e.g., see <a href="#RFC7235" id="rfc.xref.RFC7235.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Authentication">[RFC7235]</cite></a> and <a href="#RFC6265" id="rfc.xref.RFC6265.3"><cite title="HTTP State Management Mechanism">[RFC6265]</cite></a>), response control data (e.g., see <a href="p2-semantics.html#response.control.data" title="Control Data">Section 7.1</a> of <a href="#RFC7231" id="rfc.xref.RFC7231.20"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[RFC7231]</cite></a>), or determining how to process the payload (e.g., <a href="p2-semantics.html#header.content-encoding" class="smpl">Content-Encoding</a>, <a href="p2-semantics.html#header.content-type" class="smpl">Content-Type</a>, <a href="p5-range.html#header.content-range" class="smpl">Content-Range</a>, and <a href="#header.trailer" class="smpl">Trailer</a>).
    17361736               </p>
    17371737               <p id="rfc.section.4.1.2.p.4">When a chunked message containing a non-empty trailer is received, the recipient <em class="bcp14">MAY</em> process the fields (aside from those forbidden above) as if they were appended to the message's header section. A recipient <em class="bcp14">MUST</em> ignore (or consider as an error) any fields that are forbidden to be sent in a trailer, since processing them as if they were
     
    18171817            </p>
    18181818            <p id="rfc.section.4.3.p.7">When multiple transfer codings are acceptable, the client <em class="bcp14">MAY</em> rank the codings by preference using a case-insensitive "q" parameter (similar to the qvalues used in content negotiation
    1819                fields, <a href="p2-semantics.html#quality.values" title="Quality Values">Section 5.3.1</a> of <a href="#Part2" id="rfc.xref.Part2.21"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). The rank value is a real number in the range 0 through 1, where 0.001 is the least preferred and 1 is the most preferred;
     1819               fields, <a href="p2-semantics.html#quality.values" title="Quality Values">Section 5.3.1</a> of <a href="#RFC7231" id="rfc.xref.RFC7231.21"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[RFC7231]</cite></a>). The rank value is a real number in the range 0 through 1, where 0.001 is the least preferred and 1 is the most preferred;
    18201820               a value of 0 means "not acceptable".
    18211821            </p>
     
    18521852            </p>
    18531853            <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.22"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>, and a target resource upon which to apply those semantics. A URI reference (<a href="#uri" title="Uniform Resource Identifiers">Section&nbsp;2.7</a>) is typically used as an identifier for the "<dfn>target resource</dfn>", which a user agent would resolve to its absolute form in order to obtain the "<dfn>target URI</dfn>". The target URI excludes the reference's fragment component, if any, since fragment identifiers are reserved for client-side
     1854               are defined in <a href="#RFC7231" id="rfc.xref.RFC7231.22"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[RFC7231]</cite></a>, and a target resource upon which to apply those semantics. A URI reference (<a href="#uri" title="Uniform Resource Identifiers">Section&nbsp;2.7</a>) is typically used as an identifier for the "<dfn>target resource</dfn>", which a user agent would resolve to its absolute form in order to obtain the "<dfn>target URI</dfn>". The target URI excludes the reference's fragment component, if any, since fragment identifiers are reserved for client-side
    18551855               processing (<a href="#RFC3986" id="rfc.xref.RFC3986.21"><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>).
    18561856            </p>
     
    18611861               semantics and, if so, where that request is to be directed.
    18621862            </p>
    1863             <p id="rfc.section.5.2.p.2">If the client has a cache <a href="#Part6" id="rfc.xref.Part6.4"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a> and the request can be satisfied by it, then the request is usually directed there first.
     1863            <p id="rfc.section.5.2.p.2">If the client has a cache <a href="#RFC7234" id="rfc.xref.RFC7234.5"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[RFC7234]</cite></a> and the request can be satisfied by it, then the request is usually directed there first.
    18641864            </p>
    18651865            <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
     
    19221922               <div id="rfc.iref.a.3"></div>
    19231923               <h3 id="rfc.section.5.3.3"><a href="#rfc.section.5.3.3">5.3.3</a>&nbsp;<a href="#authority-form">authority-form</a></h3>
    1924                <p id="rfc.section.5.3.3.p.1">The <dfn>authority-form</dfn> of request-target is only used for CONNECT requests (<a href="p2-semantics.html#CONNECT" title="CONNECT">Section 4.3.6</a> of <a href="#Part2" id="rfc.xref.Part2.23"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>).
     1924               <p id="rfc.section.5.3.3.p.1">The <dfn>authority-form</dfn> of request-target is only used for CONNECT requests (<a href="p2-semantics.html#CONNECT" title="CONNECT">Section 4.3.6</a> of <a href="#RFC7231" id="rfc.xref.RFC7231.23"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[RFC7231]</cite></a>).
    19251925               </p>
    19261926               <div id="rfc.figure.u.44"></div><pre class="inline"><span id="rfc.iref.g.86"></span>  <a href="#authority-form" class="smpl">authority-form</a> = <a href="#uri" class="smpl">authority</a>
     
    19321932               <div id="rfc.iref.a.4"></div>
    19331933               <h3 id="rfc.section.5.3.4"><a href="#rfc.section.5.3.4">5.3.4</a>&nbsp;<a href="#asterisk-form">asterisk-form</a></h3>
    1934                <p id="rfc.section.5.3.4.p.1">The <dfn>asterisk-form</dfn> of request-target is only used for a server-wide OPTIONS request (<a href="p2-semantics.html#OPTIONS" title="OPTIONS">Section 4.3.7</a> of <a href="#Part2" id="rfc.xref.Part2.24"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>).
     1934               <p id="rfc.section.5.3.4.p.1">The <dfn>asterisk-form</dfn> of request-target is only used for a server-wide OPTIONS request (<a href="p2-semantics.html#OPTIONS" title="OPTIONS">Section 4.3.7</a> of <a href="#RFC7231" id="rfc.xref.RFC7231.24"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[RFC7231]</cite></a>).
    19351935               </p>
    19361936               <div id="rfc.figure.u.46"></div><pre class="inline"><span id="rfc.iref.g.87"></span>  <a href="#asterisk-form" class="smpl">asterisk-form</a>  = "*"
     
    20282028            <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
    20292029               messages. Hence, it relies on the order of response arrival to correspond exactly to the order in which requests are made
    2030                on the same connection. More than one response message per request only occurs when one or more informational responses (<a href="p2-semantics.html#status.1xx" class="smpl">1xx</a>, see <a href="p2-semantics.html#status.1xx" title="Informational 1xx">Section 6.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>) precede a final response to the same request.
     2030               on the same connection. More than one response message per request only occurs when one or more informational responses (<a href="p2-semantics.html#status.1xx" class="smpl">1xx</a>, see <a href="p2-semantics.html#status.1xx" title="Informational 1xx">Section 6.2</a> of <a href="#RFC7231" id="rfc.xref.RFC7231.25"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[RFC7231]</cite></a>) precede a final response to the same request.
    20312031            </p>
    20322032            <p id="rfc.section.5.6.p.2">A client that has more than one outstanding request on a connection <em class="bcp14">MUST</em> maintain a list of outstanding requests in the order sent and <em class="bcp14">MUST</em> associate each received response message on that connection to the highest ordered request that has not yet received a final
     
    21172117               <p id="rfc.section.5.7.2.p.5">A proxy <em class="bcp14">MAY</em> modify the message body through application or removal of a transfer coding (<a href="#transfer.codings" title="Transfer Codings">Section&nbsp;4</a>).
    21182118               </p>
    2119                <p id="rfc.section.5.7.2.p.6">A proxy <em class="bcp14">MUST NOT</em> transform the payload (<a href="p2-semantics.html#payload" title="Payload Semantics">Section 3.3</a> of <a href="#Part2" id="rfc.xref.Part2.26"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>) of a message that contains a no-transform cache-control directive (<a href="p6-cache.html#header.cache-control" title="Cache-Control">Section 5.2</a> of <a href="#Part6" id="rfc.xref.Part6.5"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>).
     2119               <p id="rfc.section.5.7.2.p.6">A proxy <em class="bcp14">MUST NOT</em> transform the payload (<a href="p2-semantics.html#payload" title="Payload Semantics">Section 3.3</a> of <a href="#RFC7231" id="rfc.xref.RFC7231.26"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[RFC7231]</cite></a>) of a message that contains a no-transform cache-control directive (<a href="p6-cache.html#header.cache-control" title="Cache-Control">Section 5.2</a> of <a href="#RFC7234" id="rfc.xref.RFC7234.6"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[RFC7234]</cite></a>).
    21202120               </p>
    21212121               <p id="rfc.section.5.7.2.p.7">A proxy <em class="bcp14">MAY</em> transform the payload of a message that does not contain a no-transform cache-control directive. A proxy that transforms a
    2122                   payload <em class="bcp14">MUST</em> add a <a href="p6-cache.html#header.warning" class="smpl">Warning</a> header field with the warn-code of 214 ("Transformation Applied") if one is not already in the message (see <a href="p6-cache.html#header.warning" title="Warning">Section 5.5</a> of <a href="#Part6" id="rfc.xref.Part6.6"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>). A proxy that transforms the payload of a <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> response can further inform downstream recipients that a transformation has been applied by changing the response status code
    2123                   to <a href="p2-semantics.html#status.203" class="smpl">203 (Non-Authoritative Information)</a> (<a href="p2-semantics.html#status.203" title="203 Non-Authoritative Information">Section 6.3.4</a> of <a href="#Part2" id="rfc.xref.Part2.27"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>).
     2122                  payload <em class="bcp14">MUST</em> add a <a href="p6-cache.html#header.warning" class="smpl">Warning</a> header field with the warn-code of 214 ("Transformation Applied") if one is not already in the message (see <a href="p6-cache.html#header.warning" title="Warning">Section 5.5</a> of <a href="#RFC7234" id="rfc.xref.RFC7234.7"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[RFC7234]</cite></a>). A proxy that transforms the payload of a <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> response can further inform downstream recipients that a transformation has been applied by changing the response status code
     2123                  to <a href="p2-semantics.html#status.203" class="smpl">203 (Non-Authoritative Information)</a> (<a href="p2-semantics.html#status.203" title="203 Non-Authoritative Information">Section 6.3.4</a> of <a href="#RFC7231" id="rfc.xref.RFC7231.27"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[RFC7231]</cite></a>).
    21242124               </p>
    21252125               <p id="rfc.section.5.7.2.p.8">A 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
     
    21652165  <a href="#header.connection" class="smpl">connection-option</a> = <a href="#rule.token.separators" class="smpl">token</a>
    21662166</pre><p id="rfc.section.6.1.p.6">Connection options are case-insensitive.</p>
    2167             <p id="rfc.section.6.1.p.7">A sender <em class="bcp14">MUST NOT</em> send a connection option corresponding to a header field that is intended for all recipients of the payload. For example, <a href="p6-cache.html#header.cache-control" class="smpl">Cache-Control</a> is never appropriate as a connection option (<a href="p6-cache.html#header.cache-control" title="Cache-Control">Section 5.2</a> of <a href="#Part6" id="rfc.xref.Part6.7"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>).
     2167            <p id="rfc.section.6.1.p.7">A sender <em class="bcp14">MUST NOT</em> send a connection option corresponding to a header field that is intended for all recipients of the payload. For example, <a href="p6-cache.html#header.cache-control" class="smpl">Cache-Control</a> is never appropriate as a connection option (<a href="p6-cache.html#header.cache-control" title="Cache-Control">Section 5.2</a> of <a href="#RFC7234" id="rfc.xref.RFC7234.8"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[RFC7234]</cite></a>).
    21682168            </p>
    21692169            <p id="rfc.section.6.1.p.8">The connection options do not always correspond to a header field present in the message, since a connection-specific header
     
    22272227               </p>
    22282228               <p id="rfc.section.6.3.1.p.2">When an inbound connection is closed prematurely, a client <em class="bcp14">MAY</em> open a new connection and automatically retransmit an aborted sequence of requests if all of those requests have idempotent
    2229                   methods (<a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 4.2.2</a> of <a href="#Part2" id="rfc.xref.Part2.28"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). A proxy <em class="bcp14">MUST NOT</em> automatically retry non-idempotent requests.
     2229                  methods (<a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 4.2.2</a> of <a href="#RFC7231" id="rfc.xref.RFC7231.28"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[RFC7231]</cite></a>). A proxy <em class="bcp14">MUST NOT</em> automatically retry non-idempotent requests.
    22302230               </p>
    22312231               <p id="rfc.section.6.3.1.p.3">A user agent <em class="bcp14">MUST NOT</em> automatically retry a request with a non-idempotent method unless it has some means to know that the request semantics are
     
    22412241            <div id="pipelining">
    22422242               <h3 id="rfc.section.6.3.2"><a href="#rfc.section.6.3.2">6.3.2</a>&nbsp;<a href="#pipelining">Pipelining</a></h3>
    2243                <p id="rfc.section.6.3.2.p.1">A client that supports persistent connections <em class="bcp14">MAY</em> "<dfn>pipeline</dfn>" its requests (i.e., send multiple requests without waiting for each response). A server <em class="bcp14">MAY</em> process a sequence of pipelined requests in parallel if they all have safe methods (<a href="p2-semantics.html#safe.methods" title="Safe Methods">Section 4.2.1</a> of <a href="#Part2" id="rfc.xref.Part2.29"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>), but <em class="bcp14">MUST</em> send the corresponding responses in the same order that the requests were received.
     2243               <p id="rfc.section.6.3.2.p.1">A client that supports persistent connections <em class="bcp14">MAY</em> "<dfn>pipeline</dfn>" its requests (i.e., send multiple requests without waiting for each response). A server <em class="bcp14">MAY</em> process a sequence of pipelined requests in parallel if they all have safe methods (<a href="p2-semantics.html#safe.methods" title="Safe Methods">Section 4.2.1</a> of <a href="#RFC7231" id="rfc.xref.RFC7231.29"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[RFC7231]</cite></a>), but <em class="bcp14">MUST</em> send the corresponding responses in the same order that the requests were received.
    22442244               </p>
    22452245               <p id="rfc.section.6.3.2.p.2">A client that pipelines requests <em class="bcp14">SHOULD</em> retry unanswered requests if the connection closes before it receives all of the corresponding responses. When retrying pipelined
     
    22482248                  problem described in <a href="#persistent.tear-down" id="rfc.xref.persistent.tear-down.2" title="Tear-down">Section&nbsp;6.6</a>).
    22492249               </p>
    2250                <p id="rfc.section.6.3.2.p.3">Idempotent methods (<a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 4.2.2</a> of <a href="#Part2" id="rfc.xref.Part2.30"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>) are significant to pipelining because they can be automatically retried after a connection failure. A user agent <em class="bcp14">SHOULD NOT</em> pipeline requests after a non-idempotent method, until the final response status code for that method has been received, unless
     2250               <p id="rfc.section.6.3.2.p.3">Idempotent methods (<a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 4.2.2</a> of <a href="#RFC7231" id="rfc.xref.RFC7231.30"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[RFC7231]</cite></a>) are significant to pipelining because they can be automatically retried after a connection failure. A user agent <em class="bcp14">SHOULD NOT</em> pipeline requests after a non-idempotent method, until the final response status code for that method has been received, unless
    22512251                  the user agent has a means to detect and recover from partial failure conditions involving the pipelined sequence.
    22522252               </p>
     
    23732373            </p>
    23742374            <p id="rfc.section.6.7.p.11">A client cannot begin using an upgraded protocol on the connection until it has completely sent the request message (i.e.,
    2375                the client can't change the protocol it is sending in the middle of a message). If a server receives both Upgrade and an <a href="p2-semantics.html#header.expect" class="smpl">Expect</a> header field with the "100-continue" expectation (<a href="p2-semantics.html#header.expect" title="Expect">Section 5.1.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>), the server <em class="bcp14">MUST</em> send a <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> response before sending a <a href="p2-semantics.html#status.101" class="smpl">101 (Switching Protocols)</a> response.
     2375               the client can't change the protocol it is sending in the middle of a message). If a server receives both Upgrade and an <a href="p2-semantics.html#header.expect" class="smpl">Expect</a> header field with the "100-continue" expectation (<a href="p2-semantics.html#header.expect" title="Expect">Section 5.1.1</a> of <a href="#RFC7231" id="rfc.xref.RFC7231.31"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[RFC7231]</cite></a>), the server <em class="bcp14">MUST</em> send a <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> response before sending a <a href="p2-semantics.html#status.101" class="smpl">101 (Switching Protocols)</a> response.
    23762376            </p>
    23772377            <p id="rfc.section.6.7.p.12">The Upgrade header field only applies to switching protocols on top of the existing connection; it cannot be used to switch
    23782378               the underlying connection (transport) protocol, nor to switch the existing communication to a different connection. For those
    2379                purposes, 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 6.4</a> of <a href="#Part2" id="rfc.xref.Part2.32"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>).
     2379               purposes, 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 6.4</a> of <a href="#RFC7231" id="rfc.xref.RFC7231.32"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[RFC7231]</cite></a>).
    23802380            </p>
    23812381            <p id="rfc.section.6.7.p.13">This specification only defines the protocol name "HTTP" for use by the family of Hypertext Transfer Protocols, as defined
     
    27092709                  <li>Pointer to specification text</li>
    27102710               </ul>
    2711                <p id="rfc.section.8.4.1.p.2">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.33"><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&nbsp;4.2</a>.
     2711               <p id="rfc.section.8.4.1.p.2">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="#RFC7231" id="rfc.xref.RFC7231.33"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[RFC7231]</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&nbsp;4.2</a>.
    27122712               </p>
    27132713               <p id="rfc.section.8.4.1.p.3">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 specification.
     
    28822882         <h1 id="rfc.section.9"><a href="#rfc.section.9">9.</a>&nbsp;<a href="#security.considerations">Security Considerations</a></h1>
    28832883         <p id="rfc.section.9.p.1">This section is meant to inform developers, information providers, and users of known security considerations relevant to
    2884             HTTP message syntax, parsing, and routing. Security considerations about HTTP semantics and payloads are addressed in <a href="#Part2" id="rfc.xref.Part2.34"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>.
     2884            HTTP message syntax, parsing, and routing. Security considerations about HTTP semantics and payloads are addressed in <a href="#RFC7231" id="rfc.xref.RFC7231.34"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[RFC7231]</cite></a>.
    28852885         </p>
    28862886         <div id="establishing.authority">
     
    29192919               without regard to security and privacy considerations, might be used in the commission of a wide range of potential attacks.
    29202920            </p>
    2921             <p id="rfc.section.9.2.p.2">Intermediaries that contain a shared cache are especially vulnerable to cache poisoning attacks, as described in <a href="p6-cache.html#security.considerations" title="Security Considerations">Section 8</a> of <a href="#Part6" id="rfc.xref.Part6.8"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>.
     2921            <p id="rfc.section.9.2.p.2">Intermediaries that contain a shared cache are especially vulnerable to cache poisoning attacks, as described in <a href="p6-cache.html#security.considerations" title="Security Considerations">Section 8</a> of <a href="#RFC7234" id="rfc.xref.RFC7234.9"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[RFC7234]</cite></a>.
    29222922            </p>
    29232923            <p id="rfc.section.9.2.p.3">Implementers need to consider the privacy and security implications of their design and coding decisions, and of the configuration
     
    29372937               that most implementations will choose substantially higher limits.
    29382938            </p>
    2939             <p id="rfc.section.9.3.p.3">A server can reject a message that has a request-target that is too long (<a href="p2-semantics.html#status.414" title="414 URI Too Long">Section 6.5.12</a> of <a href="#Part2" id="rfc.xref.Part2.35"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>) or a request payload that is too large (<a href="p2-semantics.html#status.413" title="413 Payload Too Large">Section 6.5.11</a> of <a href="#Part2" id="rfc.xref.Part2.36"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). Additional status codes related to capacity limits have been defined by extensions to HTTP <a href="#RFC6585" id="rfc.xref.RFC6585.1"><cite title="Additional HTTP Status Codes">[RFC6585]</cite></a>.
     2939            <p id="rfc.section.9.3.p.3">A server can reject a message that has a request-target that is too long (<a href="p2-semantics.html#status.414" title="414 URI Too Long">Section 6.5.12</a> of <a href="#RFC7231" id="rfc.xref.RFC7231.35"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[RFC7231]</cite></a>) or a request payload that is too large (<a href="p2-semantics.html#status.413" title="413 Payload Too Large">Section 6.5.11</a> of <a href="#RFC7231" id="rfc.xref.RFC7231.36"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[RFC7231]</cite></a>). Additional status codes related to capacity limits have been defined by extensions to HTTP <a href="#RFC6585" id="rfc.xref.RFC6585.1"><cite title="Additional HTTP Status Codes">[RFC6585]</cite></a>.
    29402940            </p>
    29412941            <p id="rfc.section.9.3.p.4">Recipients ought to carefully limit the extent to which they process other protocol elements, including (but not limited to)
     
    30793079      <table>
    30803080         <tr>
    3081             <td class="reference"><b id="Part2">[Part2]</b></td>
    3082             <td class="top"><a href="mailto:fielding@gbiv.com" title="Adobe Systems Incorporated">Fielding, R., Ed.</a> and <a href="mailto:julian.reschke@greenbytes.de" title="greenbytes GmbH">J. Reschke, Ed.</a>, “<a href="http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-latest">Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</a>”, Internet-Draft&nbsp;draft-ietf-httpbis-p2-semantics-latest (work in progress), May&nbsp;2014.
    3083             </td>
    3084          </tr>
    3085          <tr>
    3086             <td class="reference"><b id="Part4">[Part4]</b></td>
    3087             <td class="top"><a href="mailto:fielding@gbiv.com" title="Adobe Systems Incorporated">Fielding, R., Ed.</a> and <a href="mailto:julian.reschke@greenbytes.de" title="greenbytes GmbH">J. Reschke, Ed.</a>, “<a href="http://tools.ietf.org/html/draft-ietf-httpbis-p4-conditional-latest">Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests</a>”, Internet-Draft&nbsp;draft-ietf-httpbis-p4-conditional-latest (work in progress), May&nbsp;2014.
    3088             </td>
    3089          </tr>
    3090          <tr>
    3091             <td class="reference"><b id="Part5">[Part5]</b></td>
    3092             <td class="top"><a href="mailto:fielding@gbiv.com" title="Adobe Systems Incorporated">Fielding, R., Ed.</a>, <a href="mailto:ylafon@w3.org" title="World Wide Web Consortium">Lafon, Y., Ed.</a>, and <a href="mailto:julian.reschke@greenbytes.de" title="greenbytes GmbH">J. Reschke, Ed.</a>, “<a href="http://tools.ietf.org/html/draft-ietf-httpbis-p5-range-latest">Hypertext Transfer Protocol (HTTP/1.1): Range Requests</a>”, Internet-Draft&nbsp;draft-ietf-httpbis-p5-range-latest (work in progress), May&nbsp;2014.
    3093             </td>
    3094          </tr>
    3095          <tr>
    3096             <td class="reference"><b id="Part6">[Part6]</b></td>
    3097             <td class="top"><a href="mailto:fielding@gbiv.com" title="Adobe Systems Incorporated">Fielding, R., Ed.</a>, <a href="mailto:mnot@mnot.net" title="Akamai">Nottingham, M., Ed.</a>, and <a href="mailto:julian.reschke@greenbytes.de" title="greenbytes GmbH">J. Reschke, Ed.</a>, “<a href="http://tools.ietf.org/html/draft-ietf-httpbis-p6-cache-latest">Hypertext Transfer Protocol (HTTP/1.1): Caching</a>”, Internet-Draft&nbsp;draft-ietf-httpbis-p6-cache-latest (work in progress), May&nbsp;2014.
    3098             </td>
    3099          </tr>
    3100          <tr>
    3101             <td class="reference"><b id="Part7">[Part7]</b></td>
    3102             <td class="top"><a href="mailto:fielding@gbiv.com" title="Adobe Systems Incorporated">Fielding, R., Ed.</a> and <a href="mailto:julian.reschke@greenbytes.de" title="greenbytes GmbH">J. Reschke, Ed.</a>, “<a href="http://tools.ietf.org/html/draft-ietf-httpbis-p7-auth-latest">Hypertext Transfer Protocol (HTTP/1.1): Authentication</a>”, Internet-Draft&nbsp;draft-ietf-httpbis-p7-auth-latest (work in progress), May&nbsp;2014.
    3103             </td>
    3104          </tr>
    3105          <tr>
    31063081            <td class="reference"><b id="RFC0793">[RFC0793]</b></td>
    31073082            <td class="top">Postel, J., “<a href="http://tools.ietf.org/html/rfc793">Transmission Control Protocol</a>”, STD&nbsp;7, RFC&nbsp;793, September&nbsp;1981.
     
    31363111            <td class="reference"><b id="RFC5234">[RFC5234]</b></td>
    31373112            <td class="top"><a href="mailto:dcrocker@bbiw.net" title="Brandenburg InternetWorking">Crocker, D., Ed.</a> and <a href="mailto:paul.overell@thus.net" title="THUS plc.">P. Overell</a>, “<a href="http://tools.ietf.org/html/rfc5234">Augmented BNF for Syntax Specifications: ABNF</a>”, STD&nbsp;68, RFC&nbsp;5234, January&nbsp;2008.
     3113            </td>
     3114         </tr>
     3115         <tr>
     3116            <td class="reference"><b id="RFC7231">[RFC7231]</b></td>
     3117            <td class="top"><a href="mailto:fielding@gbiv.com" title="Adobe Systems Incorporated">Fielding, R., Ed.</a> and <a href="mailto:julian.reschke@greenbytes.de" title="greenbytes GmbH">J. Reschke, Ed.</a>, “<a href="http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-latest">Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</a>”, Internet-Draft&nbsp;draft-ietf-httpbis-p2-semantics-latest (work in progress), May&nbsp;2014.
     3118            </td>
     3119         </tr>
     3120         <tr>
     3121            <td class="reference"><b id="RFC7232">[RFC7232]</b></td>
     3122            <td class="top"><a href="mailto:fielding@gbiv.com" title="Adobe Systems Incorporated">Fielding, R., Ed.</a> and <a href="mailto:julian.reschke@greenbytes.de" title="greenbytes GmbH">J. Reschke, Ed.</a>, “<a href="http://tools.ietf.org/html/draft-ietf-httpbis-p4-conditional-latest">Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests</a>”, Internet-Draft&nbsp;draft-ietf-httpbis-p4-conditional-latest (work in progress), May&nbsp;2014.
     3123            </td>
     3124         </tr>
     3125         <tr>
     3126            <td class="reference"><b id="RFC7233">[RFC7233]</b></td>
     3127            <td class="top"><a href="mailto:fielding@gbiv.com" title="Adobe Systems Incorporated">Fielding, R., Ed.</a>, <a href="mailto:ylafon@w3.org" title="World Wide Web Consortium">Lafon, Y., Ed.</a>, and <a href="mailto:julian.reschke@greenbytes.de" title="greenbytes GmbH">J. Reschke, Ed.</a>, “<a href="http://tools.ietf.org/html/draft-ietf-httpbis-p5-range-latest">Hypertext Transfer Protocol (HTTP/1.1): Range Requests</a>”, Internet-Draft&nbsp;draft-ietf-httpbis-p5-range-latest (work in progress), May&nbsp;2014.
     3128            </td>
     3129         </tr>
     3130         <tr>
     3131            <td class="reference"><b id="RFC7234">[RFC7234]</b></td>
     3132            <td class="top"><a href="mailto:fielding@gbiv.com" title="Adobe Systems Incorporated">Fielding, R., Ed.</a>, <a href="mailto:mnot@mnot.net" title="Akamai">Nottingham, M., Ed.</a>, and <a href="mailto:julian.reschke@greenbytes.de" title="greenbytes GmbH">J. Reschke, Ed.</a>, “<a href="http://tools.ietf.org/html/draft-ietf-httpbis-p6-cache-latest">Hypertext Transfer Protocol (HTTP/1.1): Caching</a>”, Internet-Draft&nbsp;draft-ietf-httpbis-p6-cache-latest (work in progress), May&nbsp;2014.
     3133            </td>
     3134         </tr>
     3135         <tr>
     3136            <td class="reference"><b id="RFC7235">[RFC7235]</b></td>
     3137            <td class="top"><a href="mailto:fielding@gbiv.com" title="Adobe Systems Incorporated">Fielding, R., Ed.</a> and <a href="mailto:julian.reschke@greenbytes.de" title="greenbytes GmbH">J. Reschke, Ed.</a>, “<a href="http://tools.ietf.org/html/draft-ietf-httpbis-p7-auth-latest">Hypertext Transfer Protocol (HTTP/1.1): Authentication</a>”, Internet-Draft&nbsp;draft-ietf-httpbis-p7-auth-latest (work in progress), May&nbsp;2014.
    31383138            </td>
    31393139         </tr>
     
    37663766            </li>
    37673767            <li><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul>
    3768                   <li><em>Part2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.1">1</a>, <a href="#rfc.xref.Part2.2">2.1</a>, <a href="#rfc.xref.Part2.3">2.1</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</a>, <a href="#rfc.xref.Part2.14">3.3.1</a>, <a href="#rfc.xref.Part2.15">3.3.1</a>, <a href="#rfc.xref.Part2.16">3.3.2</a>, <a href="#rfc.xref.Part2.17">3.3.2</a>, <a href="#rfc.xref.Part2.18">3.3.2</a>, <a href="#rfc.xref.Part2.19">4.1.2</a>, <a href="#rfc.xref.Part2.20">4.1.2</a>, <a href="#rfc.xref.Part2.21">4.3</a>, <a href="#rfc.xref.Part2.22">5.1</a>, <a href="#rfc.xref.Part2.23">5.3.3</a>, <a href="#rfc.xref.Part2.24">5.3.4</a>, <a href="#rfc.xref.Part2.25">5.6</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.3.2</a>, <a href="#rfc.xref.Part2.31">6.7</a>, <a href="#rfc.xref.Part2.32">6.7</a>, <a href="#rfc.xref.Part2.33">8.4.1</a>, <a href="#rfc.xref.Part2.34">9</a>, <a href="#rfc.xref.Part2.35">9.3</a>, <a href="#rfc.xref.Part2.36">9.3</a>, <a href="#Part2"><b>11.1</b></a><ul>
    3769                         <li><em>Section 2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.4">2.7</a></li>
    3770                         <li><em>Section 3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.16">3.3.2</a></li>
    3771                         <li><em>Section 3.1.2.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.14">3.3.1</a>, <a href="#rfc.xref.Part2.33">8.4.1</a></li>
    3772                         <li><em>Section 3.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.26">5.7.2</a></li>
    3773                         <li><em>Section 4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.6">3.1.1</a></li>
    3774                         <li><em>Section 4.2.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.29">6.3.2</a></li>
    3775                         <li><em>Section 4.2.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.28">6.3.1</a>, <a href="#rfc.xref.Part2.30">6.3.2</a></li>
    3776                         <li><em>Section 4.3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.3">2.1</a>, <a href="#rfc.xref.Part2.12">3.3</a></li>
    3777                         <li><em>Section 4.3.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.11">3.3</a>, <a href="#rfc.xref.Part2.17">3.3.2</a></li>
    3778                         <li><em>Section 4.3.6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.13">3.3</a>, <a href="#rfc.xref.Part2.15">3.3.1</a>, <a href="#rfc.xref.Part2.18">3.3.2</a>, <a href="#rfc.xref.Part2.23">5.3.3</a></li>
    3779                         <li><em>Section 4.3.7</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.24">5.3.4</a></li>
    3780                         <li><em>Section 5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.19">4.1.2</a></li>
    3781                         <li><em>Section 5.1.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.31">6.7</a></li>
    3782                         <li><em>Section 5.3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.21">4.3</a></li>
    3783                         <li><em>Section 6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.5">2.7.1</a>, <a href="#rfc.xref.Part2.8">3.1.2</a></li>
    3784                         <li><em>Section 6.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.25">5.6</a></li>
    3785                         <li><em>Section 6.3.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.27">5.7.2</a></li>
    3786                         <li><em>Section 6.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.32">6.7</a></li>
    3787                         <li><em>Section 6.5.11</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.36">9.3</a></li>
    3788                         <li><em>Section 6.5.12</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.7">3.1.1</a>, <a href="#rfc.xref.Part2.35">9.3</a></li>
    3789                         <li><em>Section 7.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.20">4.1.2</a></li>
    3790                         <li><em>Section 7.1.1.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.9">3.2</a></li>
    3791                         <li><em>Section 8.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.10">3.2.1</a></li>
    3792                         <li><em>Appendix A</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.2">2.1</a></li>
    3793                      </ul>
    3794                   </li>
    3795                   <li><em>Part4</em>&nbsp;&nbsp;<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>11.1</b></a><ul>
    3796                         <li><em>Section 4.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.2">3.3.1</a>, <a href="#rfc.xref.Part4.3">3.3.2</a></li>
    3797                      </ul>
    3798                   </li>
    3799                   <li><em>Part5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part5.1">1</a>, <a href="#Part5"><b>11.1</b></a></li>
    3800                   <li><em>Part6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.1">1</a>, <a href="#rfc.xref.Part6.2">2.4</a>, <a href="#rfc.xref.Part6.3">3.4</a>, <a href="#rfc.xref.Part6.4">5.2</a>, <a href="#rfc.xref.Part6.5">5.7.2</a>, <a href="#rfc.xref.Part6.6">5.7.2</a>, <a href="#rfc.xref.Part6.7">6.1</a>, <a href="#rfc.xref.Part6.8">9.2</a>, <a href="#Part6"><b>11.1</b></a><ul>
    3801                         <li><em>Section 2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.2">2.4</a></li>
    3802                         <li><em>Section 3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.3">3.4</a></li>
    3803                         <li><em>Section 5.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.5">5.7.2</a>, <a href="#rfc.xref.Part6.7">6.1</a></li>
    3804                         <li><em>Section 5.5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.6">5.7.2</a></li>
    3805                         <li><em>Section 8</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.8">9.2</a></li>
    3806                      </ul>
    3807                   </li>
    3808                   <li><em>Part7</em>&nbsp;&nbsp;<a href="#rfc.xref.Part7.1">1</a>, <a href="#rfc.xref.Part7.2">4.1.2</a>, <a href="#Part7"><b>11.1</b></a></li>
    38093768                  <li>phishing&nbsp;&nbsp;<a href="#rfc.iref.p.2"><b>9.1</b></a></li>
    38103769                  <li>proxy&nbsp;&nbsp;<a href="#rfc.iref.p.1"><b>2.3</b></a></li>
     
    38823841                  <li><em>RFC6265</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC6265.1">2.7.2</a>, <a href="#rfc.xref.RFC6265.2">3.2.2</a>, <a href="#rfc.xref.RFC6265.3">4.1.2</a>, <a href="#RFC6265"><b>11.2</b></a></li>
    38833842                  <li><em>RFC6585</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC6585.1">9.3</a>, <a href="#RFC6585"><b>11.2</b></a></li>
     3843                  <li><em>RFC7231</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7231.1">1</a>, <a href="#rfc.xref.RFC7231.2">2.1</a>, <a href="#rfc.xref.RFC7231.3">2.1</a>, <a href="#rfc.xref.RFC7231.4">2.7</a>, <a href="#rfc.xref.RFC7231.5">2.7.1</a>, <a href="#rfc.xref.RFC7231.6">3.1.1</a>, <a href="#rfc.xref.RFC7231.7">3.1.1</a>, <a href="#rfc.xref.RFC7231.8">3.1.2</a>, <a href="#rfc.xref.RFC7231.9">3.2</a>, <a href="#rfc.xref.RFC7231.10">3.2.1</a>, <a href="#rfc.xref.RFC7231.11">3.3</a>, <a href="#rfc.xref.RFC7231.12">3.3</a>, <a href="#rfc.xref.RFC7231.13">3.3</a>, <a href="#rfc.xref.RFC7231.14">3.3.1</a>, <a href="#rfc.xref.RFC7231.15">3.3.1</a>, <a href="#rfc.xref.RFC7231.16">3.3.2</a>, <a href="#rfc.xref.RFC7231.17">3.3.2</a>, <a href="#rfc.xref.RFC7231.18">3.3.2</a>, <a href="#rfc.xref.RFC7231.19">4.1.2</a>, <a href="#rfc.xref.RFC7231.20">4.1.2</a>, <a href="#rfc.xref.RFC7231.21">4.3</a>, <a href="#rfc.xref.RFC7231.22">5.1</a>, <a href="#rfc.xref.RFC7231.23">5.3.3</a>, <a href="#rfc.xref.RFC7231.24">5.3.4</a>, <a href="#rfc.xref.RFC7231.25">5.6</a>, <a href="#rfc.xref.RFC7231.26">5.7.2</a>, <a href="#rfc.xref.RFC7231.27">5.7.2</a>, <a href="#rfc.xref.RFC7231.28">6.3.1</a>, <a href="#rfc.xref.RFC7231.29">6.3.2</a>, <a href="#rfc.xref.RFC7231.30">6.3.2</a>, <a href="#rfc.xref.RFC7231.31">6.7</a>, <a href="#rfc.xref.RFC7231.32">6.7</a>, <a href="#rfc.xref.RFC7231.33">8.4.1</a>, <a href="#rfc.xref.RFC7231.34">9</a>, <a href="#rfc.xref.RFC7231.35">9.3</a>, <a href="#rfc.xref.RFC7231.36">9.3</a>, <a href="#RFC7231"><b>11.1</b></a><ul>
     3844                        <li><em>Section 2</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7231.4">2.7</a></li>
     3845                        <li><em>Section 3</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7231.16">3.3.2</a></li>
     3846                        <li><em>Section 3.1.2.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7231.14">3.3.1</a>, <a href="#rfc.xref.RFC7231.33">8.4.1</a></li>
     3847                        <li><em>Section 3.3</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7231.26">5.7.2</a></li>
     3848                        <li><em>Section 4</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7231.6">3.1.1</a></li>
     3849                        <li><em>Section 4.2.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7231.29">6.3.2</a></li>
     3850                        <li><em>Section 4.2.2</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7231.28">6.3.1</a>, <a href="#rfc.xref.RFC7231.30">6.3.2</a></li>
     3851                        <li><em>Section 4.3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7231.3">2.1</a>, <a href="#rfc.xref.RFC7231.12">3.3</a></li>
     3852                        <li><em>Section 4.3.2</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7231.11">3.3</a>, <a href="#rfc.xref.RFC7231.17">3.3.2</a></li>
     3853                        <li><em>Section 4.3.6</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7231.13">3.3</a>, <a href="#rfc.xref.RFC7231.15">3.3.1</a>, <a href="#rfc.xref.RFC7231.18">3.3.2</a>, <a href="#rfc.xref.RFC7231.23">5.3.3</a></li>
     3854                        <li><em>Section 4.3.7</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7231.24">5.3.4</a></li>
     3855                        <li><em>Section 5</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7231.19">4.1.2</a></li>
     3856                        <li><em>Section 5.1.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7231.31">6.7</a></li>
     3857                        <li><em>Section 5.3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7231.21">4.3</a></li>
     3858                        <li><em>Section 6</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7231.5">2.7.1</a>, <a href="#rfc.xref.RFC7231.8">3.1.2</a></li>
     3859                        <li><em>Section 6.2</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7231.25">5.6</a></li>
     3860                        <li><em>Section 6.3.4</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7231.27">5.7.2</a></li>
     3861                        <li><em>Section 6.4</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7231.32">6.7</a></li>
     3862                        <li><em>Section 6.5.11</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7231.36">9.3</a></li>
     3863                        <li><em>Section 6.5.12</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7231.7">3.1.1</a>, <a href="#rfc.xref.RFC7231.35">9.3</a></li>
     3864                        <li><em>Section 7.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7231.20">4.1.2</a></li>
     3865                        <li><em>Section 7.1.1.2</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7231.9">3.2</a></li>
     3866                        <li><em>Section 8.3</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7231.10">3.2.1</a></li>
     3867                        <li><em>Appendix A</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7231.2">2.1</a></li>
     3868                     </ul>
     3869                  </li>
     3870                  <li><em>RFC7232</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7232.1">1</a>, <a href="#rfc.xref.RFC7232.2">3.3.1</a>, <a href="#rfc.xref.RFC7232.3">3.3.2</a>, <a href="#RFC7232"><b>11.1</b></a><ul>
     3871                        <li><em>Section 4.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7232.2">3.3.1</a>, <a href="#rfc.xref.RFC7232.3">3.3.2</a></li>
     3872                     </ul>
     3873                  </li>
     3874                  <li><em>RFC7233</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7233.1">1</a>, <a href="#RFC7233"><b>11.1</b></a></li>
     3875                  <li><em>RFC7234</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7234.1">1</a>, <a href="#rfc.xref.RFC7234.2">1</a>, <a href="#rfc.xref.RFC7234.3">2.4</a>, <a href="#rfc.xref.RFC7234.4">3.4</a>, <a href="#rfc.xref.RFC7234.5">5.2</a>, <a href="#rfc.xref.RFC7234.6">5.7.2</a>, <a href="#rfc.xref.RFC7234.7">5.7.2</a>, <a href="#rfc.xref.RFC7234.8">6.1</a>, <a href="#rfc.xref.RFC7234.9">9.2</a>, <a href="#RFC7234"><b>11.1</b></a><ul>
     3876                        <li><em>Section 2</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7234.3">2.4</a></li>
     3877                        <li><em>Section 3</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7234.4">3.4</a></li>
     3878                        <li><em>Section 5.2</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7234.6">5.7.2</a>, <a href="#rfc.xref.RFC7234.8">6.1</a></li>
     3879                        <li><em>Section 5.5</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7234.7">5.7.2</a></li>
     3880                        <li><em>Section 8</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7234.9">9.2</a></li>
     3881                     </ul>
     3882                  </li>
     3883                  <li><em>RFC7235</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7235.1">4.1.2</a>, <a href="#RFC7235"><b>11.1</b></a></li>
    38843884               </ul>
    38853885            </li>
Note: See TracChangeset for help on using the changeset viewer.