Ignore:
Timestamp:
04/09/12 20:16:43 (8 years ago)
Author:
fielding@…
Message:

(editorial) Fix the document titles

File:
1 edited

Legend:

Unmodified
Added
Removed

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

    r1863 r1864  
    44   <head profile="http://www.w3.org/2006/03/hcard http://dublincore.org/documents/2008/08/04/dc-html/">
    55      <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
    6       <title>HTTP/1.1, part 1: Message Routing and Syntax"</title><script>
     6      <title>Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing</title><script>
    77var buttonsAdded = false;
    88
    … …  
    443443  }
    444444  @top-center {
    445        content: "HTTP/1.1, Part 1";
     445       content: "HTTP/1.1 Message Syntax and Routing";
    446446  }
    447447  @bottom-left {
    … …  
    533533         </tbody>
    534534      </table>
    535       <p class="title">HTTP/1.1, part 1: Message Routing and Syntax"<br><span class="filename">draft-ietf-httpbis-p1-messaging-latest</span></p>
     535      <p class="title">Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing<br><span class="filename">draft-ietf-httpbis-p1-messaging-latest</span></p>
    536536      <h1 id="rfc.abstract"><a href="#rfc.abstract">Abstract</a></h1>
    537537      <p>The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information
    … …  
    736736      </p>
    737737      <ul class="empty">
    738          <li>RFC xxx1: Message Routing and Syntax</li>
    739          <li><cite title="HTTP/1.1, part 2: Semantics and Payloads" id="rfc.xref.Part2.1">RFC xxx2</cite>: Semantics and Payloads
    740          </li>
    741          <li><cite title="HTTP/1.1, part 4: Conditional Requests" id="rfc.xref.Part4.1">RFC xxx3</cite>: Conditional Requests
    742          </li>
    743          <li><cite title="HTTP/1.1, part 5: Range Requests" id="rfc.xref.Part5.1">RFC xxx4</cite>: Range Requests
    744          </li>
    745          <li><cite title="HTTP/1.1, part 6: Caching" id="rfc.xref.Part6.1">RFC xxx5</cite>: Caching
    746          </li>
    747          <li><cite title="HTTP/1.1, part 7: Authentication" id="rfc.xref.Part7.1">RFC xxx6</cite>: Authentication
     738         <li>RFC xxx1: Message Syntax and Routing</li>
     739         <li><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content" id="rfc.xref.Part2.1">RFC xxx2</cite>: Semantics and Content
     740         </li>
     741         <li><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests" id="rfc.xref.Part4.1">RFC xxx3</cite>: Conditional Requests
     742         </li>
     743         <li><cite title="Hypertext Transfer Protocol (HTTP/1.1): Range Requests" id="rfc.xref.Part5.1">RFC xxx4</cite>: Range Requests
     744         </li>
     745         <li><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching" id="rfc.xref.Part6.1">RFC xxx5</cite>: Caching
     746         </li>
     747         <li><cite title="Hypertext Transfer Protocol (HTTP/1.1): Authentication" id="rfc.xref.Part7.1">RFC xxx6</cite>: Authentication
    748748         </li>
    749749      </ul>
    … …  
    820820         "<dfn>sender</dfn>" to refer to whichever component sent a given message and the term "<dfn>recipient</dfn>" to refer to any component that receives the message.
    821821      </p>
    822       <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="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a> for the differences between HTTP and MIME messages).
     822      <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).
    823823      </p>
    824824      <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
    … …  
    907907         or an intranet-to-Internet privacy filter. Such transformations are presumed to be desired by the client (or client organization)
    908908         that selected the proxy and are beyond the scope of this specification. However, when a proxy is not intended to transform
    909          a given message, we use the term "<dfn>non-transforming proxy</dfn>" to target requirements that preserve HTTP message semantics. See <a href="p2-semantics.html#status.203" title="203 Non-Authoritative Information">Section 7.3.4</a> of <a href="#Part2" id="rfc.xref.Part2.3"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a> and <a href="p6-cache.html#header.warning" title="Warning">Section 7.5</a> of <a href="#Part6" id="rfc.xref.Part6.2"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a> for status and warning codes related to transformations.
     909         a given message, we use the term "<dfn>non-transforming proxy</dfn>" to target requirements that preserve HTTP message semantics. See <a href="p2-semantics.html#status.203" title="203 Non-Authoritative Information">Section 7.3.4</a> of <a href="#Part2" id="rfc.xref.Part2.3"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a> and <a href="p6-cache.html#header.warning" title="Warning">Section 7.5</a> of <a href="#Part6" id="rfc.xref.Part6.2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a> for status and warning codes related to transformations.
    910910      </p>
    911911      <p id="rfc.section.2.3.p.7"><span id="rfc.iref.g.13"></span><span id="rfc.iref.r.4"></span>  <span id="rfc.iref.a.1"></span> A "<dfn>gateway</dfn>" (a.k.a., "<dfn>reverse proxy</dfn>") is a receiving agent that acts as a layer above some other server(s) and translates the received requests to the underlying
    … …  
    951951</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
    952952         is cacheable, there might be additional constraints placed by the client or by the origin server on when that cached response
    953          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.3"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>.
     953         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.3"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>.
    954954      </p>
    955955      <p id="rfc.section.2.4.p.5">There are a wide variety of architectures and configurations of caches and proxies deployed across the World Wide Web and
    … …  
    10771077      </p>
    10781078      <p id="rfc.section.2.7.1.p.6">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,
    1079          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 7</a> of <a href="#Part2" id="rfc.xref.Part2.4"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>, then that response is considered an authoritative answer to the client's request.
     1079         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 7</a> of <a href="#Part2" id="rfc.xref.Part2.4"><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.
    10801080      </p>
    10811081      <p id="rfc.section.2.7.1.p.7">Although HTTP is independent of the transport protocol, the "http" scheme is specific to TCP-based services because the name
    … …  
    11021102      <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> ]
    11031103</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
    1104          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="HTTP/1.1, part 6: Caching">[Part6]</cite></a>).
     1104         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>).
    11051105      </p>
    11061106      <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
    … …  
    11751175      </div>
    11761176      <div id="rfc.figure.u.14"></div><pre class="inline"><span id="rfc.iref.g.29"></span>  <a href="#method" class="smpl">method</a>         = <a href="#rule.token.separators" class="smpl">token</a>
    1177 </pre><p id="rfc.section.3.1.1.p.6">The methods defined by this specification can be found in <a href="p2-semantics.html#methods" title="Request Methods">Section 5</a> of <a href="#Part2" id="rfc.xref.Part2.5"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>, along with information regarding the HTTP method registry and considerations for defining new methods.
     1177</pre><p id="rfc.section.3.1.1.p.6">The methods defined by this specification can be found in <a href="p2-semantics.html#methods" title="Request Methods">Section 5</a> of <a href="#Part2" id="rfc.xref.Part2.5"><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.
    11781178      </p>
    11791179      <div id="rfc.iref.r.6"></div>
    … …  
    11881188      </p>
    11891189      <p id="rfc.section.3.1.1.p.10">HTTP does not place a pre-defined limit on the length of a request-line. A server that receives a method longer than any that
    1190          it implements <em class="bcp14">SHOULD</em> respond with either a <a href="p2-semantics.html#status.405" class="smpl">405 (Method Not Allowed)</a>, if it is an origin server, or a <a href="p2-semantics.html#status.501" class="smpl">501 (Not Implemented)</a> status code. A server <em class="bcp14">MUST</em> be prepared to receive URIs of unbounded length and respond with the <a href="p2-semantics.html#status.414" class="smpl">414 (URI Too Long)</a> status code if the received request-target would be longer than the server wishes to handle (see <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.6"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>).
     1190         it implements <em class="bcp14">SHOULD</em> respond with either a <a href="p2-semantics.html#status.405" class="smpl">405 (Method Not Allowed)</a>, if it is an origin server, or a <a href="p2-semantics.html#status.501" class="smpl">501 (Not Implemented)</a> status code. A server <em class="bcp14">MUST</em> be prepared to receive URIs of unbounded length and respond with the <a href="p2-semantics.html#status.414" class="smpl">414 (URI Too Long)</a> status code if the received request-target would be longer than the server wishes to handle (see <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.6"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>).
    11911191      </p>
    11921192      <p id="rfc.section.3.1.1.p.11">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 up to 8000 octets.
    … …  
    12011201      <p id="rfc.section.3.1.2.p.4">The status-code element is a 3-digit integer code describing the result of the server's attempt to understand and satisfy
    12021202         the client's corresponding request. The rest of the response message is to be interpreted in light of the semantics defined
    1203          for that status code. See <a href="p2-semantics.html#status.codes" title="Response Status Codes">Section 7</a> of <a href="#Part2" id="rfc.xref.Part2.7"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a> for information about the semantics of status codes, including the classes of status code (indicated by the first digit),
     1203         for that status code. See <a href="p2-semantics.html#status.codes" title="Response Status Codes">Section 7</a> of <a href="#Part2" id="rfc.xref.Part2.7"><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),
    12041204         the status codes defined by this specification, considerations for the definition of new status codes, and the IANA registry.
    12051205      </p>
    … …  
    12221222                 ; see <a href="#field.parsing" title="Field Parsing">Section&nbsp;3.2.2</a>
    12231223</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,
    1224          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 8.2.1</a> of <a href="#Part2" id="rfc.xref.Part2.8"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a> as containing the origination timestamp for the message in which it appears.
     1224         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 8.2.1</a> of <a href="#Part2" id="rfc.xref.Part2.8"><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.
    12251225      </p>
    12261226      <p id="rfc.section.3.2.p.4">HTTP header fields are fully extensible: there is no limit on the introduction of new field names, each presumably defining
    … …  
    12301230         them.
    12311231      </p>
    1232       <p id="rfc.section.3.2.p.5">New HTTP header fields <em class="bcp14">SHOULD</em> 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 10.3</a> of <a href="#Part2" id="rfc.xref.Part2.9"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>. Unrecognized header fields <em class="bcp14">MUST</em> be forwarded by a proxy unless the field-name is listed in the <a href="#header.connection" class="smpl">Connection</a> header field (<a href="#header.connection" id="rfc.xref.header.connection.3" title="Connection">Section&nbsp;6.1</a>) or the proxy is specifically configured to block or otherwise transform such fields. Unrecognized header fields <em class="bcp14">SHOULD</em> be ignored by other recipients.
     1232      <p id="rfc.section.3.2.p.5">New HTTP header fields <em class="bcp14">SHOULD</em> 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 10.3</a> of <a href="#Part2" id="rfc.xref.Part2.9"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>. Unrecognized header fields <em class="bcp14">MUST</em> be forwarded by a proxy unless the field-name is listed in the <a href="#header.connection" class="smpl">Connection</a> header field (<a href="#header.connection" id="rfc.xref.header.connection.3" title="Connection">Section&nbsp;6.1</a>) or the proxy is specifically configured to block or otherwise transform such fields. Unrecognized header fields <em class="bcp14">SHOULD</em> be ignored by other recipients.
    12331233      </p>
    12341234      <p id="rfc.section.3.2.p.6">The order in which header fields with differing field names are received is not significant. However, it is "good practice"
    … …  
    13821382      <p id="rfc.section.3.3.1.p.6">If more than one Transfer-Encoding header field is present in a message, the multiple field-values <em class="bcp14">MUST</em> be combined into one field-value, according to the algorithm defined in <a href="#header.fields" title="Header Fields">Section&nbsp;3.2</a>, before determining the message body length.
    13831383      </p>
    1384       <p id="rfc.section.3.3.1.p.7">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 9.4</a> of <a href="#Part2" id="rfc.xref.Part2.10"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>), Transfer-Encoding is a property of the message, not of the payload, and thus <em class="bcp14">MAY</em> be added or removed by any implementation along the request/response chain. Additional information about the encoding parameters <em class="bcp14">MAY</em> be provided by other header fields not defined by this specification.
    1385       </p>
    1386       <p id="rfc.section.3.3.1.p.8">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="HTTP/1.1, part 4: 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
     1384      <p id="rfc.section.3.3.1.p.7">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 9.4</a> of <a href="#Part2" id="rfc.xref.Part2.10"><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 payload, and thus <em class="bcp14">MAY</em> be added or removed by any implementation along the request/response chain. Additional information about the encoding parameters <em class="bcp14">MAY</em> be provided by other header fields not defined by this specification.
     1385      </p>
     1386      <p id="rfc.section.3.3.1.p.8">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
    13871387         coding to the message body if the request had been an unconditional GET. This indication is not required, however, because
    13881388         any recipient on the response chain (including the origin server) can remove transfer codings when they are not needed.
    … …  
    14041404      <div id="rfc.figure.u.29"></div><pre class="text">  Content-Length: 3495
    14051405</pre><p id="rfc.section.3.3.2.p.5">In the case of a response to a HEAD request, Content-Length indicates the size of the payload body (without any potential
    1406          transfer-coding) that would have been sent had the request been a GET. In the case of 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.3"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>) to a GET request, Content-Length indicates the size of the payload body (without any potential transfer-coding) that would
     1406         transfer-coding) that would have been sent had the request been a GET. In the case of 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.3"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a>) to a GET request, Content-Length indicates the size of the payload body (without any potential transfer-coding) that would
    14071407         have been sent in a <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> response.
    14081408      </p>
    … …  
    14991499      </p>
    15001500      <p id="rfc.section.3.4.p.4">A user agent <em class="bcp14">MUST NOT</em> render an incomplete response message body as if it were complete (i.e., some indication needs to be given to the user that
    1501          an error occurred). 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="HTTP/1.1, part 6: Caching">[Part6]</cite></a>.
     1501         an error occurred). 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>.
    15021502      </p>
    15031503      <p id="rfc.section.3.4.p.5">A server <em class="bcp14">MUST</em> read the entire request message body or close the connection after sending its response, since otherwise the remaining data
    … …  
    16621662         that a client can be assured of buffering the entire response.
    16631663      </p>
    1664       <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 "q" parameter (similar to the qvalues used in content negotiation fields, <a href="p2-semantics.html#quality.values" title="Quality Values">Section 6.3.1</a> of <a href="#Part2" id="rfc.xref.Part2.11"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[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;
     1664      <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 "q" parameter (similar to the qvalues used in content negotiation fields, <a href="p2-semantics.html#quality.values" title="Quality Values">Section 6.3.1</a> of <a href="#Part2" id="rfc.xref.Part2.11"><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;
    16651665         a value of 0 means "not acceptable".
    16661666      </p>
    … …  
    16831683      </p>
    16841684      <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
    1685          are defined in <a href="#Part2" id="rfc.xref.Part2.12"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[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 identifier component, if any, since fragment identifiers are reserved
     1685         are defined in <a href="#Part2" id="rfc.xref.Part2.12"><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 identifier component, if any, since fragment identifiers are reserved
    16861686         for client-side processing (<a href="#RFC3986" id="rfc.xref.RFC3986.18"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-3.5">Section 3.5</a>).
    16871687      </p>
    … …  
    16901690         semantics and, if so, where that request is to be directed.
    16911691      </p>
    1692       <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="HTTP/1.1, part 6: Caching">[Part6]</cite></a>), then the request is usually directed to the cache first.
     1692      <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.
    16931693      </p>
    16941694      <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
    … …  
    17421742      </p>
    17431743      <div id="authority-form">
    1744          <p id="rfc.section.5.3.p.13"><span id="rfc.iref.a.3"></span> The authority-form of request-target is only used for CONNECT requests (<a href="p2-semantics.html#CONNECT" title="CONNECT">Section 5.3.6</a> of <a href="#Part2" id="rfc.xref.Part2.13"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>). When making a CONNECT request to establish a tunnel through one or more proxies, a client <em class="bcp14">MUST</em> send only the target URI's authority component (excluding any userinfo) as the request-target. For example,
     1744         <p id="rfc.section.5.3.p.13"><span id="rfc.iref.a.3"></span> The authority-form of request-target is only used for CONNECT requests (<a href="p2-semantics.html#CONNECT" title="CONNECT">Section 5.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>). When making a CONNECT request to establish a tunnel through one or more proxies, a client <em class="bcp14">MUST</em> send only the target URI's authority component (excluding any userinfo) as the request-target. For example,
    17451745         </p>
    17461746      </div>
    17471747      <div id="rfc.figure.u.41"></div><pre class="text2">CONNECT www.example.com:80 HTTP/1.1
    17481748</pre><div id="asterisk-form">
    1749          <p id="rfc.section.5.3.p.15"><span id="rfc.iref.a.4"></span> The asterisk-form of request-target is only used for a server-wide OPTIONS request (<a href="p2-semantics.html#OPTIONS" title="OPTIONS">Section 5.3.7</a> of <a href="#Part2" id="rfc.xref.Part2.14"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>). When a client wishes to request OPTIONS for the server as a whole, as opposed to a specific named resource of that server,
     1749         <p id="rfc.section.5.3.p.15"><span id="rfc.iref.a.4"></span> The asterisk-form of request-target is only used for a server-wide OPTIONS request (<a href="p2-semantics.html#OPTIONS" title="OPTIONS">Section 5.3.7</a> of <a href="#Part2" id="rfc.xref.Part2.14"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). When a client wishes to request OPTIONS for the server as a whole, as opposed to a specific named resource of that server,
    17501750            the client <em class="bcp14">MUST</em> send only "*" (%x2A) as the request-target. For example,
    17511751         </p>
    … …  
    18851885         except as noted above to replace an empty path with "/" or "*".
    18861886      </p>
    1887       <p id="rfc.section.5.8.p.3">A non-transforming proxy <em class="bcp14">MUST</em> preserve the message payload (<a href="#Part2" id="rfc.xref.Part2.15"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[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&nbsp;4</a>).
     1887      <p id="rfc.section.5.8.p.3">A non-transforming proxy <em class="bcp14">MUST</em> preserve the message payload (<a href="#Part2" id="rfc.xref.Part2.15"><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&nbsp;4</a>).
    18881888      </p>
    18891889      <p id="rfc.section.5.8.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
    … …  
    18931893      </p>
    18941894      <ul>
    1895          <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.16"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>)
    1896          </li>
    1897          <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.2.4</a> of <a href="#Part2" id="rfc.xref.Part2.17"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>)
     1895         <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.16"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>)
     1896         </li>
     1897         <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.2.4</a> of <a href="#Part2" id="rfc.xref.Part2.17"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>)
    18981898         </li>
    18991899         <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>)
    19001900         </li>
    1901          <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="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>)
    1902          </li>
    1903          <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="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>)
    1904          </li>
    1905          <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.18"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>)
    1906          </li>
    1907       </ul>
    1908       <p id="rfc.section.5.8.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="HTTP/1.1, part 6: 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.
     1901         <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>)
     1902         </li>
     1903         <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>)
     1904         </li>
     1905         <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.18"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>)
     1906         </li>
     1907      </ul>
     1908      <p id="rfc.section.5.8.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.
    19091909      </p>
    19101910      <p id="rfc.section.5.8.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:
    19111911      </p>
    19121912      <ul>
    1913          <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.2.2</a> of <a href="#Part2" id="rfc.xref.Part2.19"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>)
    1914          </li>
    1915          <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="HTTP/1.1, part 5: Range Requests">[Part5]</cite></a>)
    1916          </li>
    1917          <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.2.1</a> of <a href="#Part2" id="rfc.xref.Part2.20"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>)
    1918          </li>
    1919       </ul>
    1920       <p id="rfc.section.5.8.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="HTTP/1.1, part 6: Caching">[Part6]</cite></a>).
     1913         <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.2.2</a> of <a href="#Part2" id="rfc.xref.Part2.19"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>)
     1914         </li>
     1915         <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>)
     1916         </li>
     1917         <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.2.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>)
     1918         </li>
     1919      </ul>
     1920      <p id="rfc.section.5.8.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>).
    19211921      </p>
    19221922      <div class="note" id="rfc.section.5.8.p.9">
    … …  
    19281928      <p id="rfc.section.5.9.p.1">HTTP does not include a request identifier for associating a given request message with its corresponding one or more response
    19291929         messages. Hence, it relies on the order of response arrival to correspond exactly to the order in which requests are made
    1930          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 7.2</a> of <a href="#Part2" id="rfc.xref.Part2.21"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>) precede a final response to the same request.
     1930         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 7.2</a> of <a href="#Part2" id="rfc.xref.Part2.21"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>) precede a final response to the same request.
    19311931      </p>
    19321932      <p id="rfc.section.5.9.p.2">A client that uses persistent connections and sends more than one request per connection <em class="bcp14">MUST</em> maintain a list of outstanding requests in the order sent on that connection and <em class="bcp14">MUST</em> associate each received response message to the highest ordered request that has not yet received a final (non-<a href="p2-semantics.html#status.1xx" class="smpl">1xx</a>) response.
    … …  
    19671967</pre><p id="rfc.section.6.1.p.6">Connection options are case-insensitive.</p>
    19681968      <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
    1969          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="HTTP/1.1, part 6: Caching">[Part6]</cite></a>).
     1969         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>).
    19701970      </p>
    19711971      <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
    … …  
    20502050      <p id="rfc.section.6.2.2.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.
    20512051      </p>
    2052       <p id="rfc.section.6.2.2.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.22"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>). Otherwise, a premature termination of the transport connection could lead to indeterminate results. A client wishing to
     2052      <p id="rfc.section.6.2.2.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.22"><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
    20532053         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.
    20542054      </p>
    20552055      <h4 id="rfc.section.6.2.2.2"><a href="#rfc.section.6.2.2.2">6.2.2.2</a>&nbsp;<a id="persistent.retrying.requests" href="#persistent.retrying.requests">Retrying Requests</a></h4>
    20562056      <p id="rfc.section.6.2.2.2.p.1">Senders can close the transport connection at any time. Therefore, clients, servers, and proxies <em class="bcp14">MUST</em> be able to recover from asynchronous close events. Client software <em class="bcp14">MAY</em> reopen the transport connection and retransmit the aborted sequence of requests without user interaction so long as the request
    2057          sequence 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.23"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>). Non-idempotent request methods or sequences <em class="bcp14">MUST NOT</em> be automatically retried, 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
     2057         sequence 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.23"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). Non-idempotent request methods or sequences <em class="bcp14">MUST NOT</em> be automatically retried, 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
    20582058         of the application <em class="bcp14">MAY</em> substitute for user confirmation. The automatic retry <em class="bcp14">SHOULD NOT</em> be repeated if the second sequence of requests fails.
    20592059      </p>
    … …  
    21492149      </p>
    21502150      <p id="rfc.section.6.3.p.9">The Upgrade header field only applies to switching application-layer protocols on the existing transport-layer connection;
    2151          it cannot be used 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.24"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>).
     2151         it cannot be used 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.24"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>).
    21522152      </p>
    21532153      <p id="rfc.section.6.3.p.10">This specification only defines the protocol name "HTTP" for use by the family of Hypertext Transfer Protocols, as defined
    … …  
    24102410         <li>Pointer to specification text</li>
    24112411      </ul>
    2412       <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 9.4</a> of <a href="#Part2" id="rfc.xref.Part2.25"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[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>.
     2412      <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 9.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>) 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>.
    24132413      </p>
    24142414      <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
    … …  
    25662566         that most implementations will choose substantially higher limits.
    25672567      </p>
    2568       <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.26"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[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.27"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>).
     2568      <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.26"><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.27"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>).
    25692569      </p>
    25702570      <p id="rfc.section.8.6.p.4">Other fields (including but not limited to request methods, response status phrases, header field-names, and body chunks) <em class="bcp14">SHOULD</em> be limited by implementations carefully, so as to not impede interoperability.
    … …  
    26162616         <tr>
    26172617            <td class="reference"><b id="Part2">[Part2]</b></td>
    2618             <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-p2-semantics-latest">HTTP/1.1, part 2: Semantics and Payloads</a>”, Internet-Draft&nbsp;draft-ietf-httpbis-p2-semantics-latest (work in progress), September&nbsp;2012.
     2618            <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-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), September&nbsp;2012.
    26192619            </td>
    26202620         </tr>
    26212621         <tr>
    26222622            <td class="reference"><b id="Part4">[Part4]</b></td>
    2623             <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-p4-conditional-latest">HTTP/1.1, part 4: Conditional Requests</a>”, Internet-Draft&nbsp;draft-ietf-httpbis-p4-conditional-latest (work in progress), September&nbsp;2012.
     2623            <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-p4-conditional-latest">Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests</a>”, Internet-Draft&nbsp;draft-ietf-httpbis-p4-conditional-latest (work in progress), September&nbsp;2012.
    26242624            </td>
    26252625         </tr>
    26262626         <tr>
    26272627            <td class="reference"><b id="Part5">[Part5]</b></td>
    2628             <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">HTTP/1.1, part 5: Range Requests</a>”, Internet-Draft&nbsp;draft-ietf-httpbis-p5-range-latest (work in progress), September&nbsp;2012.
     2628            <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), September&nbsp;2012.
    26292629            </td>
    26302630         </tr>
    26312631         <tr>
    26322632            <td class="reference"><b id="Part6">[Part6]</b></td>
    2633             <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>, <a href="mailto:mnot@mnot.net" title="Rackspace">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">HTTP/1.1, part 6: Caching</a>”, Internet-Draft&nbsp;draft-ietf-httpbis-p6-cache-latest (work in progress), September&nbsp;2012.
     2633            <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>, <a href="mailto:mnot@mnot.net" title="Rackspace">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), September&nbsp;2012.
    26342634            </td>
    26352635         </tr>
    26362636         <tr>
    26372637            <td class="reference"><b id="Part7">[Part7]</b></td>
    2638             <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-p7-auth-latest">HTTP/1.1, part 7: Authentication</a>”, Internet-Draft&nbsp;draft-ietf-httpbis-p7-auth-latest (work in progress), September&nbsp;2012.
     2638            <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-p7-auth-latest">Hypertext Transfer Protocol (HTTP/1.1): Authentication</a>”, Internet-Draft&nbsp;draft-ietf-httpbis-p7-auth-latest (work in progress), September&nbsp;2012.
    26392639            </td>
    26402640         </tr>
Note: See TracChangeset for help on using the changeset viewer.