Changeset 1864


Ignore:
Timestamp:
Sep 4, 2012, 1:16:43 PM (7 years ago)
Author:
fielding@…
Message:

(editorial) Fix the document titles

Location:
draft-ietf-httpbis/latest
Files:
14 edited

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpbis/latest/p0-introduction.html

    r1845 r1864  
    393393  }
    394394  @bottom-center {
    395        content: "Expires March 5, 2013";
     395       content: "Expires March 8, 2013";
    396396  }
    397397  @bottom-right {
     
    426426      <meta name="dct.creator" content="Reschke, J. F.">
    427427      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p0-introduction-latest">
    428       <meta name="dct.issued" scheme="ISO8601" content="2012-09-01">
     428      <meta name="dct.issued" scheme="ISO8601" content="2012-09-04">
    429429      <meta name="dct.abstract" content="This document is the first in a series that, collectively, define the HyperText Transfer Protocol, version 1.1; otherwise known as HTTP/1.1.">
    430430      <meta name="description" content="This document is the first in a series that, collectively, define the HyperText Transfer Protocol, version 1.1; otherwise known as HTTP/1.1.">
     
    446446            </tr>
    447447            <tr>
    448                <td class="left">Expires: March 5, 2013</td>
     448               <td class="left">Expires: March 8, 2013</td>
    449449               <td class="right">W3C</td>
    450450            </tr>
     
    467467            <tr>
    468468               <td class="left"></td>
    469                <td class="right">September 1, 2012</td>
     469               <td class="right">September 4, 2012</td>
    470470            </tr>
    471471         </tbody>
     
    490490         in progress”.
    491491      </p>
    492       <p>This Internet-Draft will expire on March 5, 2013.</p>
     492      <p>This Internet-Draft will expire on March 8, 2013.</p>
    493493      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    494494      <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
  • 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>
  • draft-ietf-httpbis/latest/p1-messaging.xml

    r1863 r1864  
    7474<front>
    7575
    76   <title abbrev="HTTP/1.1, Part 1">HTTP/1.1, part 1: Message Routing and Syntax"</title>
     76  <title abbrev="HTTP/1.1 Message Syntax and Routing">Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing</title>
    7777
    7878  <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor">
     
    161161   that collectively form the HTTP/1.1 specification:
    162162   <list style="empty">
    163     <t>RFC xxx1: Message Routing and Syntax</t>
    164     <t><xref target="Part2" x:fmt="none">RFC xxx2</xref>: Semantics and Payloads</t>
     163    <t>RFC xxx1: Message Syntax and Routing</t>
     164    <t><xref target="Part2" x:fmt="none">RFC xxx2</xref>: Semantics and Content</t>
    165165    <t><xref target="Part4" x:fmt="none">RFC xxx3</xref>: Conditional Requests</t>
    166166    <t><xref target="Part5" x:fmt="none">RFC xxx4</xref>: Range Requests</t>
     
    39263926<reference anchor="Part2">
    39273927  <front>
    3928     <title>HTTP/1.1, part 2: Semantics and Payloads</title>
     3928    <title>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</title>
    39293929    <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor">
    39303930      <organization abbrev="Adobe">Adobe Systems Incorporated</organization>
     
    39793979<reference anchor="Part4">
    39803980  <front>
    3981     <title>HTTP/1.1, part 4: Conditional Requests</title>
     3981    <title>Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests</title>
    39823982    <author fullname="Roy T. Fielding" initials="R." role="editor" surname="Fielding">
    39833983      <organization abbrev="Adobe">Adobe Systems Incorporated</organization>
     
    40044004<reference anchor="Part5">
    40054005  <front>
    4006     <title>HTTP/1.1, part 5: Range Requests</title>
     4006    <title>Hypertext Transfer Protocol (HTTP/1.1): Range Requests</title>
    40074007    <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor">
    40084008      <organization abbrev="Adobe">Adobe Systems Incorporated</organization>
     
    40274027<reference anchor="Part6">
    40284028  <front>
    4029     <title>HTTP/1.1, part 6: Caching</title>
     4029    <title>Hypertext Transfer Protocol (HTTP/1.1): Caching</title>
    40304030    <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor">
    40314031      <organization abbrev="Adobe">Adobe Systems Incorporated</organization>
     
    40544054<reference anchor="Part7">
    40554055  <front>
    4056     <title>HTTP/1.1, part 7: Authentication</title>
     4056    <title>Hypertext Transfer Protocol (HTTP/1.1): Authentication</title>
    40574057    <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor">
    40584058      <organization abbrev="Adobe">Adobe Systems Incorporated</organization>
  • draft-ietf-httpbis/latest/p2-semantics.html

    r1862 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 2: Semantics and Payloads</title><script>
     6      <title>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</title><script>
    77var buttonsAdded = false;
    88
     
    443443  }
    444444  @top-center {
    445        content: "HTTP/1.1, Part 2";
     445       content: "HTTP/1.1 Semantics and Content";
    446446  }
    447447  @bottom-left {
     
    538538         </tbody>
    539539      </table>
    540       <p class="title">HTTP/1.1, part 2: Semantics and Payloads<br><span class="filename">draft-ietf-httpbis-p2-semantics-latest</span></p>
     540      <p class="title">Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content<br><span class="filename">draft-ietf-httpbis-p2-semantics-latest</span></p>
    541541      <h1 id="rfc.abstract"><a href="#rfc.abstract">Abstract</a></h1>
    542542      <p>The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information
     
    845845      <p id="rfc.section.1.p.1">Each HTTP message is either a request or a response. A server listens on a connection for a request, parses each message received,
    846846         interprets the message semantics in relation to the identified request target, and responds to that request with one or more
    847          response messages. This document defines HTTP/1.1 request and response semantics in terms of the architecture defined in <a href="#Part1" id="rfc.xref.Part1.1"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>.
     847         response messages. This document defines HTTP/1.1 request and response semantics in terms of the architecture defined in <a href="#Part1" id="rfc.xref.Part1.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>.
    848848      </p>
    849849      <p id="rfc.section.1.p.2">HTTP provides a uniform interface for interacting with resources regardless of their type, nature, or implementation. HTTP
     
    858858         in this document are to be interpreted as described in <a href="#RFC2119" id="rfc.xref.RFC2119.1"><cite title="Key words for use in RFCs to Indicate Requirement Levels">[RFC2119]</cite></a>.
    859859      </p>
    860       <p id="rfc.section.1.1.p.2">Conformance criteria and considerations regarding error handling are defined in <a href="p1-messaging.html#conformance" title="Conformance and Error Handling">Section 2.5</a> of <a href="#Part1" id="rfc.xref.Part1.2"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>.
     860      <p id="rfc.section.1.1.p.2">Conformance criteria and considerations regarding error handling are defined in <a href="p1-messaging.html#conformance" title="Conformance and Error Handling">Section 2.5</a> of <a href="#Part1" id="rfc.xref.Part1.2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>.
    861861      </p>
    862862      <h2 id="rfc.section.1.2"><a href="#rfc.section.1.2">1.2</a>&nbsp;<a id="notation" href="#notation">Syntax Notation</a></h2>
    863       <p id="rfc.section.1.2.p.1">This specification uses the Augmented Backus-Naur Form (ABNF) notation of <a href="#RFC5234" id="rfc.xref.RFC5234.1"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a> with the list rule extension defined in <a href="p1-messaging.html#notation" title="Syntax Notation">Section 1.2</a> of <a href="#Part1" id="rfc.xref.Part1.3"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>. <a href="#imported.abnf" title="Imported ABNF">Appendix&nbsp;D</a> describes rules imported from other documents. <a href="#collected.abnf" title="Collected ABNF">Appendix&nbsp;E</a> shows the collected ABNF with the list rule expanded.
     863      <p id="rfc.section.1.2.p.1">This specification uses the Augmented Backus-Naur Form (ABNF) notation of <a href="#RFC5234" id="rfc.xref.RFC5234.1"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a> with the list rule extension defined in <a href="p1-messaging.html#notation" title="Syntax Notation">Section 1.2</a> of <a href="#Part1" id="rfc.xref.Part1.3"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>. <a href="#imported.abnf" title="Imported ABNF">Appendix&nbsp;D</a> describes rules imported from other documents. <a href="#collected.abnf" title="Collected ABNF">Appendix&nbsp;E</a> shows the collected ABNF with the list rule expanded.
    864864      </p>
    865865      <h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a>&nbsp;<a id="resource" href="#resource">Resource</a></h1>
    866866      <p id="rfc.section.2.p.1">The target of each HTTP request is called a resource. HTTP does not limit the nature of a resource; it merely defines an interface
    867867         that might be used to interact with resources. Each resource is identified by a Uniform Resource Identifier (URI), as described
    868          in <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.7</a> of <a href="#Part1" id="rfc.xref.Part1.4"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>.
    869       </p>
    870       <p id="rfc.section.2.p.2">When a client constructs an HTTP/1.1 request message, it sends the "target URI" in one of various forms, as defined in (<a href="p1-messaging.html#request-target" title="Request Target">Section 5.3</a> of <a href="#Part1" id="rfc.xref.Part1.5"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>). When a request is received, the server reconstructs an "effective request URI" for the target resource (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 5.5</a> of <a href="#Part1" id="rfc.xref.Part1.6"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>).
     868         in <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.7</a> of <a href="#Part1" id="rfc.xref.Part1.4"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>.
     869      </p>
     870      <p id="rfc.section.2.p.2">When a client constructs an HTTP/1.1 request message, it sends the "target URI" in one of various forms, as defined in (<a href="p1-messaging.html#request-target" title="Request Target">Section 5.3</a> of <a href="#Part1" id="rfc.xref.Part1.5"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>). When a request is received, the server reconstructs an "effective request URI" for the target resource (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 5.5</a> of <a href="#Part1" id="rfc.xref.Part1.6"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>).
    871871      </p>
    872872      <p id="rfc.section.2.p.3">One design goal of HTTP is to separate resource identification from request semantics, which is made possible by vesting the
     
    891891         in an HTTP message, it is referred to as the payload of the message.
    892892      </p>
    893       <p id="rfc.section.3.p.4">A representation body is only present in a message when a message body is present, as described in <a href="p1-messaging.html#message.body" title="Message Body">Section 3.3</a> of <a href="#Part1" id="rfc.xref.Part1.7"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>. The representation body is obtained from the message body by decoding any <a href="p1-messaging.html#header.transfer-encoding" class="smpl">Transfer-Encoding</a> that might have been applied to ensure safe and proper transfer of the message.
     893      <p id="rfc.section.3.p.4">A representation body is only present in a message when a message body is present, as described in <a href="p1-messaging.html#message.body" title="Message Body">Section 3.3</a> of <a href="#Part1" id="rfc.xref.Part1.7"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>. The representation body is obtained from the message body by decoding any <a href="p1-messaging.html#header.transfer-encoding" class="smpl">Transfer-Encoding</a> that might have been applied to ensure safe and proper transfer of the message.
    894894      </p>
    895895      <h2 id="rfc.section.3.1"><a href="#rfc.section.3.1">3.1</a>&nbsp;<a id="identifying.response.associated.with.representation" href="#identifying.response.associated.with.representation">Identifying the Resource Associated with a Representation</a></h2>
    896896      <p id="rfc.section.3.1.p.1">It is sometimes necessary to determine an identifier for the resource associated with a representation.</p>
    897897      <p id="rfc.section.3.1.p.2">An HTTP request representation, when present, is always associated with an anonymous (i.e., unidentified) resource.</p>
    898       <p id="rfc.section.3.1.p.3">In the common case, an HTTP response is a representation of the target resource (see <a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 5.5</a> of <a href="#Part1" id="rfc.xref.Part1.8"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>). However, this is not always the case. To determine the URI of the resource a response is associated with, the following
     898      <p id="rfc.section.3.1.p.3">In the common case, an HTTP response is a representation of the target resource (see <a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 5.5</a> of <a href="#Part1" id="rfc.xref.Part1.8"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>). However, this is not always the case. To determine the URI of the resource a response is associated with, the following
    899899         rules are used (with the first applicable one being selected):
    900900      </p>
     
    949949               <tr>
    950950                  <td class="left">Expires</td>
    951                   <td class="left"><a href="p6-cache.html#header.expires" title="Expires">Section 7.3</a> of <a href="#Part6" id="rfc.xref.Part6.1"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a></td>
     951                  <td class="left"><a href="p6-cache.html#header.expires" title="Expires">Section 7.3</a> of <a href="#Part6" id="rfc.xref.Part6.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a></td>
    952952               </tr>
    953953            </tbody>
     
    10271027      </p>
    10281028      <div id="rfc.figure.u.8"></div><pre class="inline"><span id="rfc.iref.g.4"></span>  <a href="#header.content-location" class="smpl">Content-Location</a> = <a href="#imported.abnf" class="smpl">absolute-URI</a> / <a href="#imported.abnf" class="smpl">partial-URI</a>
    1029 </pre><p id="rfc.section.3.2.4.p.3">The Content-Location value is not a replacement for the effective Request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 5.5</a> of <a href="#Part1" id="rfc.xref.Part1.9"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>). It is representation metadata. It has the same syntax and semantics as the header field of the same name defined for MIME
     1029</pre><p id="rfc.section.3.2.4.p.3">The Content-Location value is not a replacement for the effective Request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 5.5</a> of <a href="#Part1" id="rfc.xref.Part1.9"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>). It is representation metadata. It has the same syntax and semantics as the header field of the same name defined for MIME
    10301030         body parts in <a href="http://tools.ietf.org/html/rfc2557#section-4">Section 4</a> of <a href="#RFC2557" id="rfc.xref.RFC2557.1"><cite title="MIME Encapsulation of Aggregate Documents, such as HTML (MHTML)">[RFC2557]</cite></a>. However, its appearance in an HTTP message has some special implications for HTTP recipients.
    10311031      </p>
     
    10791079               <tr>
    10801080                  <td class="left">ETag</td>
    1081                   <td class="left"><a href="p4-conditional.html#header.etag" title="ETag">Section 2.3</a> of <a href="#Part4" id="rfc.xref.Part4.1"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a></td>
     1081                  <td class="left"><a href="p4-conditional.html#header.etag" title="ETag">Section 2.3</a> of <a href="#Part4" id="rfc.xref.Part4.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a></td>
    10821082               </tr>
    10831083               <tr>
    10841084                  <td class="left">Last-Modified</td>
    1085                   <td class="left"><a href="p4-conditional.html#header.last-modified" title="Last-Modified">Section 2.2</a> of <a href="#Part4" id="rfc.xref.Part4.2"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a></td>
     1085                  <td class="left"><a href="p4-conditional.html#header.last-modified" title="Last-Modified">Section 2.2</a> of <a href="#Part4" id="rfc.xref.Part4.2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a></td>
    10861086               </tr>
    10871087            </tbody>
     
    12181218               <tr>
    12191219                  <td class="left">Content-Length</td>
    1220                   <td class="left"><a href="p1-messaging.html#header.content-length" title="Content-Length">Section 3.3.2</a> of <a href="#Part1" id="rfc.xref.Part1.10"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a></td>
     1220                  <td class="left"><a href="p1-messaging.html#header.content-length" title="Content-Length">Section 3.3.2</a> of <a href="#Part1" id="rfc.xref.Part1.10"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a></td>
    12211221               </tr>
    12221222               <tr>
    12231223                  <td class="left">Content-Range</td>
    1224                   <td class="left"><a href="p5-range.html#header.content-range" title="Content-Range">Section 5.2</a> of <a href="#Part5" id="rfc.xref.Part5.1"><cite title="HTTP/1.1, part 5: Range Requests">[Part5]</cite></a></td>
     1224                  <td class="left"><a href="p5-range.html#header.content-range" title="Content-Range">Section 5.2</a> of <a href="#Part5" id="rfc.xref.Part5.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Range Requests">[Part5]</cite></a></td>
    12251225               </tr>
    12261226            </tbody>
     
    12281228      </div>
    12291229      <h2 id="rfc.section.4.2"><a href="#rfc.section.4.2">4.2</a>&nbsp;<a id="payload.body" href="#payload.body">Payload Body</a></h2>
    1230       <p id="rfc.section.4.2.p.1">A payload body is only present in a message when a message body is present, as described in <a href="p1-messaging.html#message.body" title="Message Body">Section 3.3</a> of <a href="#Part1" id="rfc.xref.Part1.11"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>. The payload body is obtained from the message body by decoding any <a href="p1-messaging.html#header.transfer-encoding" class="smpl">Transfer-Encoding</a> that might have been applied to ensure safe and proper transfer of the message.
     1230      <p id="rfc.section.4.2.p.1">A payload body is only present in a message when a message body is present, as described in <a href="p1-messaging.html#message.body" title="Message Body">Section 3.3</a> of <a href="#Part1" id="rfc.xref.Part1.11"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>. The payload body is obtained from the message body by decoding any <a href="p1-messaging.html#header.transfer-encoding" class="smpl">Transfer-Encoding</a> that might have been applied to ensure safe and proper transfer of the message.
    12311231      </p>
    12321232      <h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a>&nbsp;<a id="methods" href="#methods">Request Methods</a></h1>
     
    13601360         are defined to be cacheable. In general, safe methods that do not depend on a current or authoritative response are cacheable,
    13611361         though the overwhelming majority of caches only support GET and HEAD. HTTP requirements for cache behavior and cacheable responses
    1362          are defined in <a href="#Part6" id="rfc.xref.Part6.2"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>.
     1362         are defined in <a href="#Part6" id="rfc.xref.Part6.2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>.
    13631363      </p>
    13641364      <h2 id="rfc.section.5.3"><a href="#rfc.section.5.3">5.3</a>&nbsp;<a id="method.definitions" href="#method.definitions">Method Definitions</a></h2>
     
    13701370         in the response and not the source text of the process, unless that text happens to be the output of the process.
    13711371      </p>
    1372       <p id="rfc.section.5.3.1.p.3">The semantics of the GET method change to a "conditional GET" if the request message includes an <a href="p4-conditional.html#header.if-modified-since" class="smpl">If-Modified-Since</a>, <a href="p4-conditional.html#header.if-unmodified-since" class="smpl">If-Unmodified-Since</a>, <a href="p4-conditional.html#header.if-match" class="smpl">If-Match</a>, <a href="p4-conditional.html#header.if-none-match" class="smpl">If-None-Match</a>, or <a href="p5-range.html#header.if-range" class="smpl">If-Range</a> header field (<a href="#Part4" id="rfc.xref.Part4.3"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>). A conditional GET requests that the representation be transferred only under the circumstances described by the conditional
     1372      <p id="rfc.section.5.3.1.p.3">The semantics of the GET method change to a "conditional GET" if the request message includes an <a href="p4-conditional.html#header.if-modified-since" class="smpl">If-Modified-Since</a>, <a href="p4-conditional.html#header.if-unmodified-since" class="smpl">If-Unmodified-Since</a>, <a href="p4-conditional.html#header.if-match" class="smpl">If-Match</a>, <a href="p4-conditional.html#header.if-none-match" class="smpl">If-None-Match</a>, or <a href="p5-range.html#header.if-range" class="smpl">If-Range</a> header field (<a href="#Part4" id="rfc.xref.Part4.3"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a>). A conditional GET requests that the representation be transferred only under the circumstances described by the conditional
    13731373         header field(s). The conditional GET request is intended to reduce unnecessary network usage by allowing cached representations
    13741374         to be refreshed without requiring multiple requests or transferring data already held by the client.
    13751375      </p>
    1376       <p id="rfc.section.5.3.1.p.4">The semantics of the GET method change to a "partial GET" if the request message includes a <a href="p5-range.html#range.retrieval.requests" class="smpl">Range</a> header field (<a href="#Part5" id="rfc.xref.Part5.2"><cite title="HTTP/1.1, part 5: Range Requests">[Part5]</cite></a>). A partial GET requests that only part of the representation be transferred, as described in <a href="p5-range.html#header.range" title="Range">Section 5.4</a> of <a href="#Part5" id="rfc.xref.Part5.3"><cite title="HTTP/1.1, part 5: Range Requests">[Part5]</cite></a>. The partial GET request is intended to reduce unnecessary network usage by allowing partially-retrieved representations
     1376      <p id="rfc.section.5.3.1.p.4">The semantics of the GET method change to a "partial GET" if the request message includes a <a href="p5-range.html#range.retrieval.requests" class="smpl">Range</a> header field (<a href="#Part5" id="rfc.xref.Part5.2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Range Requests">[Part5]</cite></a>). A partial GET requests that only part of the representation be transferred, as described in <a href="p5-range.html#header.range" title="Range">Section 5.4</a> of <a href="#Part5" id="rfc.xref.Part5.3"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Range Requests">[Part5]</cite></a>. The partial GET request is intended to reduce unnecessary network usage by allowing partially-retrieved representations
    13771377         to be completed without transferring data already held by the client.
    13781378      </p>
     
    13801380         to reject the request.
    13811381      </p>
    1382       <p id="rfc.section.5.3.1.p.6">The response to a GET request is cacheable and <em class="bcp14">MAY</em> be used to satisfy subsequent GET and HEAD requests (see <a href="#Part6" id="rfc.xref.Part6.3"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>).
     1382      <p id="rfc.section.5.3.1.p.6">The response to a GET request is cacheable and <em class="bcp14">MAY</em> be used to satisfy subsequent GET and HEAD requests (see <a href="#Part6" id="rfc.xref.Part6.3"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>).
    13831383      </p>
    13841384      <p id="rfc.section.5.3.1.p.7">See <a href="#encoding.sensitive.information.in.uris" title="Encoding Sensitive Information in URIs">Section&nbsp;11.2</a> for security considerations when used for forms.
     
    13911391         hypertext links for validity, accessibility, and recent modification.
    13921392      </p>
    1393       <p id="rfc.section.5.3.2.p.2">The response to a HEAD request is cacheable and <em class="bcp14">MAY</em> be used to satisfy a subsequent HEAD request. It also has potential side effects on previously stored responses to GET; see <a href="p6-cache.html#head.effects" title="Updating Caches with HEAD Responses">Section 5</a> of <a href="#Part6" id="rfc.xref.Part6.4"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>.
     1393      <p id="rfc.section.5.3.2.p.2">The response to a HEAD request is cacheable and <em class="bcp14">MAY</em> be used to satisfy a subsequent HEAD request. It also has potential side effects on previously stored responses to GET; see <a href="p6-cache.html#head.effects" title="Updating Caches with HEAD Responses">Section 5</a> of <a href="#Part6" id="rfc.xref.Part6.4"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>.
    13941394      </p>
    13951395      <p id="rfc.section.5.3.2.p.3">Bodies on HEAD requests have no defined semantics. Note that sending a body on a HEAD request might cause some existing implementations
     
    14161416      <p id="rfc.section.5.3.3.p.4">If a resource has been created on the origin server, the response <em class="bcp14">SHOULD</em> be <a href="#status.201" class="smpl">201 (Created)</a> and contain a representation which describes the status of the request and refers to the new resource, and a <a href="#header.location" class="smpl">Location</a> header field (see <a href="#header.location" id="rfc.xref.header.location.1" title="Location">Section&nbsp;8.1.1</a>).
    14171417      </p>
    1418       <p id="rfc.section.5.3.3.p.5">Responses to POST requests are only cacheable when they include explicit freshness information (see <a href="p6-cache.html#calculating.freshness.lifetime" title="Calculating Freshness Lifetime">Section 4.1.1</a> of <a href="#Part6" id="rfc.xref.Part6.5"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>). A cached POST response with a <a href="#header.content-location" class="smpl">Content-Location</a> header field (see <a href="#header.content-location" id="rfc.xref.header.content-location.2" title="Content-Location">Section&nbsp;3.2.4</a>) whose value is the effective Request URI <em class="bcp14">MAY</em> be used to satisfy subsequent GET and HEAD requests.
     1418      <p id="rfc.section.5.3.3.p.5">Responses to POST requests are only cacheable when they include explicit freshness information (see <a href="p6-cache.html#calculating.freshness.lifetime" title="Calculating Freshness Lifetime">Section 4.1.1</a> of <a href="#Part6" id="rfc.xref.Part6.5"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>). A cached POST response with a <a href="#header.content-location" class="smpl">Content-Location</a> header field (see <a href="#header.content-location" id="rfc.xref.header.content-location.2" title="Content-Location">Section&nbsp;3.2.4</a>) whose value is the effective Request URI <em class="bcp14">MAY</em> be used to satisfy subsequent GET and HEAD requests.
    14191419      </p>
    14201420      <p id="rfc.section.5.3.3.p.6">Note that POST caching is not widely implemented. However, the <a href="#status.303" class="smpl">303 (See Other)</a> response can be used to direct the user agent to retrieve a cacheable representation of the resource.
     
    14761476         the related resources.
    14771477      </p>
    1478       <p id="rfc.section.5.3.4.p.10">An origin server <em class="bcp14">SHOULD</em> reject any PUT request that contains a <a href="p5-range.html#header.content-range" class="smpl">Content-Range</a> header field (<a href="p5-range.html#header.content-range" title="Content-Range">Section 5.2</a> of <a href="#Part5" id="rfc.xref.Part5.4"><cite title="HTTP/1.1, part 5: Range Requests">[Part5]</cite></a>), since it might be misinterpreted as partial content (or might be partial content that is being mistakenly PUT as a full
     1478      <p id="rfc.section.5.3.4.p.10">An origin server <em class="bcp14">SHOULD</em> reject any PUT request that contains a <a href="p5-range.html#header.content-range" class="smpl">Content-Range</a> header field (<a href="p5-range.html#header.content-range" title="Content-Range">Section 5.2</a> of <a href="#Part5" id="rfc.xref.Part5.4"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Range Requests">[Part5]</cite></a>), since it might be misinterpreted as partial content (or might be partial content that is being mistakenly PUT as a full
    14791479         representation). Partial content updates are possible by targeting a separately identified resource with state that overlaps
    14801480         a portion of the larger resource, or by using a different method that has been specifically defined for partial updates (for
     
    14821482      </p>
    14831483      <p id="rfc.section.5.3.4.p.11">Responses to the PUT method are not cacheable. If a PUT request passes through a cache that has one or more stored responses
    1484          for the effective request URI, those stored responses will be invalidated (see <a href="p6-cache.html#invalidation.after.updates.or.deletions" title="Request Methods that Invalidate">Section 6</a> of <a href="#Part6" id="rfc.xref.Part6.6"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>).
     1484         for the effective request URI, those stored responses will be invalidated (see <a href="p6-cache.html#invalidation.after.updates.or.deletions" title="Request Methods that Invalidate">Section 6</a> of <a href="#Part6" id="rfc.xref.Part6.6"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>).
    14851485      </p>
    14861486      <h3 id="rfc.section.5.3.5"><a href="#rfc.section.5.3.5">5.3.5</a>&nbsp;<a id="DELETE" href="#DELETE">DELETE</a></h3>
     
    14981498      </p>
    14991499      <p id="rfc.section.5.3.5.p.4">Responses to the DELETE method are not cacheable. If a DELETE request passes through a cache that has one or more stored responses
    1500          for the effective request URI, those stored responses will be invalidated (see <a href="p6-cache.html#invalidation.after.updates.or.deletions" title="Request Methods that Invalidate">Section 6</a> of <a href="#Part6" id="rfc.xref.Part6.7"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>).
     1500         for the effective request URI, those stored responses will be invalidated (see <a href="p6-cache.html#invalidation.after.updates.or.deletions" title="Request Methods that Invalidate">Section 6</a> of <a href="#Part6" id="rfc.xref.Part6.7"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>).
    15011501      </p>
    15021502      <div id="rfc.iref.c.7"></div>
     
    15061506         its behavior to blind forwarding of packets until the connection is closed.
    15071507      </p>
    1508       <p id="rfc.section.5.3.6.p.2">When using CONNECT, the request-target <em class="bcp14">MUST</em> use the authority form (<a href="p1-messaging.html#request-target" title="Request Target">Section 5.3</a> of <a href="#Part1" id="rfc.xref.Part1.12"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>); i.e., the request-target consists of only the host name and port number of the tunnel destination, separated by a colon.
     1508      <p id="rfc.section.5.3.6.p.2">When using CONNECT, the request-target <em class="bcp14">MUST</em> use the authority form (<a href="p1-messaging.html#request-target" title="Request Target">Section 5.3</a> of <a href="#Part1" id="rfc.xref.Part1.12"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>); i.e., the request-target consists of only the host name and port number of the tunnel destination, separated by a colon.
    15091509         For example,
    15101510      </p>
     
    15521552         body to make more detailed queries on the server.
    15531553      </p>
    1554       <p id="rfc.section.5.3.7.p.4">If the request-target (<a href="p1-messaging.html#request-target" title="Request Target">Section 5.3</a> of <a href="#Part1" id="rfc.xref.Part1.13"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>) is an asterisk ("*"), the OPTIONS request is intended to apply to the server in general rather than to a specific resource.
     1554      <p id="rfc.section.5.3.7.p.4">If the request-target (<a href="p1-messaging.html#request-target" title="Request Target">Section 5.3</a> of <a href="#Part1" id="rfc.xref.Part1.13"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>) is an asterisk ("*"), the OPTIONS request is intended to apply to the server in general rather than to a specific resource.
    15551555         Since a server's communication options typically depend on the resource, the "*" request is only useful as a "ping" or "no-op"
    15561556         type of method; it does nothing beyond allowing the client to test the capabilities of the server. For example, this can be
     
    15711571      </p>
    15721572      <p id="rfc.section.5.3.8.p.2">TRACE allows the client to see what is being received at the other end of the request chain and use that data for testing
    1573          or diagnostic information. The value of the <a href="p1-messaging.html#header.via" class="smpl">Via</a> header field (<a href="p1-messaging.html#header.via" title="Via">Section 5.7</a> of <a href="#Part1" id="rfc.xref.Part1.14"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>) is of particular interest, since it acts as a trace of the request chain. Use of the <a href="#header.max-forwards" class="smpl">Max-Forwards</a> header field allows the client to limit the length of the request chain, which is useful for testing a chain of proxies forwarding
     1573         or diagnostic information. The value of the <a href="p1-messaging.html#header.via" class="smpl">Via</a> header field (<a href="p1-messaging.html#header.via" title="Via">Section 5.7</a> of <a href="#Part1" id="rfc.xref.Part1.14"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>) is of particular interest, since it acts as a trace of the request chain. Use of the <a href="#header.max-forwards" class="smpl">Max-Forwards</a> header field allows the client to limit the length of the request chain, which is useful for testing a chain of proxies forwarding
    15741574         messages in an infinite loop.
    15751575      </p>
    1576       <p id="rfc.section.5.3.8.p.3">If the request is valid, the response <em class="bcp14">SHOULD</em> have a <a href="#header.content-type" class="smpl">Content-Type</a> of "message/http" (see <a href="p1-messaging.html#internet.media.type.message.http" title="Internet Media Type message/http">Section 7.3.1</a> of <a href="#Part1" id="rfc.xref.Part1.15"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>) and contain a message body that encloses a copy of the entire request message. Responses to the TRACE method are not cacheable.
     1576      <p id="rfc.section.5.3.8.p.3">If the request is valid, the response <em class="bcp14">SHOULD</em> have a <a href="#header.content-type" class="smpl">Content-Type</a> of "message/http" (see <a href="p1-messaging.html#internet.media.type.message.http" title="Internet Media Type message/http">Section 7.3.1</a> of <a href="#Part1" id="rfc.xref.Part1.15"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>) and contain a message body that encloses a copy of the entire request message. Responses to the TRACE method are not cacheable.
    15771577      </p>
    15781578      <h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a>&nbsp;<a id="request.header.fields" href="#request.header.fields">Request Header Fields</a></h1>
     
    15951595               <tr>
    15961596                  <td class="left">Host</td>
    1597                   <td class="left"><a href="p1-messaging.html#header.host" title="Host">Section 5.4</a> of <a href="#Part1" id="rfc.xref.Part1.16"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a></td>
     1597                  <td class="left"><a href="p1-messaging.html#header.host" title="Host">Section 5.4</a> of <a href="#Part1" id="rfc.xref.Part1.16"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a></td>
    15981598               </tr>
    15991599               <tr>
     
    16071607               <tr>
    16081608                  <td class="left">Range</td>
    1609                   <td class="left"><a href="p5-range.html#header.range" title="Range">Section 5.4</a> of <a href="#Part5" id="rfc.xref.Part5.5"><cite title="HTTP/1.1, part 5: Range Requests">[Part5]</cite></a></td>
     1609                  <td class="left"><a href="p5-range.html#header.range" title="Range">Section 5.4</a> of <a href="#Part5" id="rfc.xref.Part5.5"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Range Requests">[Part5]</cite></a></td>
    16101610               </tr>
    16111611            </tbody>
     
    17021702      <p id="rfc.section.6.2.p.1">Conditionals are request header fields that indicate a precondition to be tested before applying the method semantics to the
    17031703         target resource. Each precondition is based on metadata that is expected to change if the selected representation of the target
    1704          resource is changed. The HTTP/1.1 conditional request mechanisms are defined in <a href="#Part4" id="rfc.xref.Part4.4"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>.
     1704         resource is changed. The HTTP/1.1 conditional request mechanisms are defined in <a href="#Part4" id="rfc.xref.Part4.4"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a>.
    17051705      </p>
    17061706      <div id="rfc.table.u.5">
     
    17151715               <tr>
    17161716                  <td class="left">If-Match</td>
    1717                   <td class="left"><a href="p4-conditional.html#header.if-match" title="If-Match">Section 3.1</a> of <a href="#Part4" id="rfc.xref.Part4.5"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a></td>
     1717                  <td class="left"><a href="p4-conditional.html#header.if-match" title="If-Match">Section 3.1</a> of <a href="#Part4" id="rfc.xref.Part4.5"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a></td>
    17181718               </tr>
    17191719               <tr>
    17201720                  <td class="left">If-None-Match</td>
    1721                   <td class="left"><a href="p4-conditional.html#header.if-none-match" title="If-None-Match">Section 3.2</a> of <a href="#Part4" id="rfc.xref.Part4.6"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a></td>
     1721                  <td class="left"><a href="p4-conditional.html#header.if-none-match" title="If-None-Match">Section 3.2</a> of <a href="#Part4" id="rfc.xref.Part4.6"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a></td>
    17221722               </tr>
    17231723               <tr>
    17241724                  <td class="left">If-Modified-Since</td>
    1725                   <td class="left"><a href="p4-conditional.html#header.if-modified-since" title="If-Modified-Since">Section 3.3</a> of <a href="#Part4" id="rfc.xref.Part4.7"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a></td>
     1725                  <td class="left"><a href="p4-conditional.html#header.if-modified-since" title="If-Modified-Since">Section 3.3</a> of <a href="#Part4" id="rfc.xref.Part4.7"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a></td>
    17261726               </tr>
    17271727               <tr>
    17281728                  <td class="left">If-Unmodified-Since</td>
    1729                   <td class="left"><a href="p4-conditional.html#header.if-unmodified-since" title="If-Unmodified-Since">Section 3.4</a> of <a href="#Part4" id="rfc.xref.Part4.8"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a></td>
     1729                  <td class="left"><a href="p4-conditional.html#header.if-unmodified-since" title="If-Unmodified-Since">Section 3.4</a> of <a href="#Part4" id="rfc.xref.Part4.8"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a></td>
    17301730               </tr>
    17311731               <tr>
    17321732                  <td class="left">If-Range</td>
    1733                   <td class="left"><a href="p5-range.html#header.if-range" title="If-Range">Section 5.3</a> of <a href="#Part5" id="rfc.xref.Part5.6"><cite title="HTTP/1.1, part 5: Range Requests">[Part5]</cite></a></td>
     1733                  <td class="left"><a href="p5-range.html#header.if-range" title="If-Range">Section 5.3</a> of <a href="#Part5" id="rfc.xref.Part5.6"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Range Requests">[Part5]</cite></a></td>
    17341734               </tr>
    17351735            </tbody>
     
    19841984               <tr>
    19851985                  <td class="left">Authorization</td>
    1986                   <td class="left"><a href="p7-auth.html#header.authorization" title="Authorization">Section 4.1</a> of <a href="#Part7" id="rfc.xref.Part7.1"><cite title="HTTP/1.1, part 7: Authentication">[Part7]</cite></a></td>
     1986                  <td class="left"><a href="p7-auth.html#header.authorization" title="Authorization">Section 4.1</a> of <a href="#Part7" id="rfc.xref.Part7.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Authentication">[Part7]</cite></a></td>
    19871987               </tr>
    19881988               <tr>
    19891989                  <td class="left">Proxy-Authorization</td>
    1990                   <td class="left"><a href="p7-auth.html#header.proxy-authorization" title="Proxy-Authorization">Section 4.3</a> of <a href="#Part7" id="rfc.xref.Part7.2"><cite title="HTTP/1.1, part 7: Authentication">[Part7]</cite></a></td>
     1990                  <td class="left"><a href="p7-auth.html#header.proxy-authorization" title="Proxy-Authorization">Section 4.3</a> of <a href="#Part7" id="rfc.xref.Part7.2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Authentication">[Part7]</cite></a></td>
    19911991               </tr>
    19921992            </tbody>
     
    20132013               <tr>
    20142014                  <td class="left">TE</td>
    2015                   <td class="left"><a href="p1-messaging.html#header.te" title="TE">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.17"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a></td>
     2015                  <td class="left"><a href="p1-messaging.html#header.te" title="TE">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.17"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a></td>
    20162016               </tr>
    20172017               <tr>
     
    20702070         user agent limitations.
    20712071      </p>
    2072       <p id="rfc.section.6.5.3.p.3">The field can contain multiple product tokens (<a href="#product.tokens" title="Product Tokens">Section&nbsp;9.2</a>) and comments (<a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.18"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>) identifying the agent and its significant subproducts. By convention, the product tokens are listed in order of their significance
     2072      <p id="rfc.section.6.5.3.p.3">The field can contain multiple product tokens (<a href="#product.tokens" title="Product Tokens">Section&nbsp;9.2</a>) and comments (<a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.18"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>) identifying the agent and its significant subproducts. By convention, the product tokens are listed in order of their significance
    20732073         for identifying the application.
    20742074      </p>
     
    21102110      </p>
    21112111      <h2 id="rfc.section.7.1"><a href="#rfc.section.7.1">7.1</a>&nbsp;<a id="overview.of.status.codes" href="#overview.of.status.codes">Overview of Status Codes</a></h2>
    2112       <p id="rfc.section.7.1.p.1">The status codes listed below are defined in this specification, <a href="p4-conditional.html#status.code.definitions" title="Status Code Definitions">Section 4</a> of <a href="#Part4" id="rfc.xref.Part4.9"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>, <a href="p5-range.html#status.code.definitions" title="Status Code Definitions">Section 3</a> of <a href="#Part5" id="rfc.xref.Part5.7"><cite title="HTTP/1.1, part 5: Range Requests">[Part5]</cite></a>, and <a href="p7-auth.html#status.code.definitions" title="Status Code Definitions">Section 3</a> of <a href="#Part7" id="rfc.xref.Part7.3"><cite title="HTTP/1.1, part 7: Authentication">[Part7]</cite></a>. The reason phrases listed here are only recommendations — they can be replaced by local equivalents without affecting the
     2112      <p id="rfc.section.7.1.p.1">The status codes listed below are defined in this specification, <a href="p4-conditional.html#status.code.definitions" title="Status Code Definitions">Section 4</a> of <a href="#Part4" id="rfc.xref.Part4.9"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a>, <a href="p5-range.html#status.code.definitions" title="Status Code Definitions">Section 3</a> of <a href="#Part5" id="rfc.xref.Part5.7"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Range Requests">[Part5]</cite></a>, and <a href="p7-auth.html#status.code.definitions" title="Status Code Definitions">Section 3</a> of <a href="#Part7" id="rfc.xref.Part7.3"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Authentication">[Part7]</cite></a>. The reason phrases listed here are only recommendations — they can be replaced by local equivalents without affecting the
    21132113         protocol.
    21142114      </p>
     
    21662166                  <td class="left">206</td>
    21672167                  <td class="left">Partial Content</td>
    2168                   <td id="status.206" class="left"><a href="p5-range.html#status.206" title="206 Partial Content">Section 3.1</a> of <a href="#Part5" id="rfc.xref.Part5.8"><cite title="HTTP/1.1, part 5: Range Requests">[Part5]</cite></a></td>
     2168                  <td id="status.206" class="left"><a href="p5-range.html#status.206" title="206 Partial Content">Section 3.1</a> of <a href="#Part5" id="rfc.xref.Part5.8"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Range Requests">[Part5]</cite></a></td>
    21692169               </tr>
    21702170               <tr>
     
    21912191                  <td class="left">304</td>
    21922192                  <td class="left">Not Modified</td>
    2193                   <td id="status.304" class="left"><a href="p4-conditional.html#status.304" title="304 Not Modified">Section 4.1</a> of <a href="#Part4" id="rfc.xref.Part4.10"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a></td>
     2193                  <td id="status.304" class="left"><a href="p4-conditional.html#status.304" title="304 Not Modified">Section 4.1</a> of <a href="#Part4" id="rfc.xref.Part4.10"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a></td>
    21942194               </tr>
    21952195               <tr>
     
    22112211                  <td class="left">401</td>
    22122212                  <td class="left">Unauthorized</td>
    2213                   <td id="status.401" class="left"><a href="p7-auth.html#status.401" title="401 Unauthorized">Section 3.1</a> of <a href="#Part7" id="rfc.xref.Part7.4"><cite title="HTTP/1.1, part 7: Authentication">[Part7]</cite></a></td>
     2213                  <td id="status.401" class="left"><a href="p7-auth.html#status.401" title="401 Unauthorized">Section 3.1</a> of <a href="#Part7" id="rfc.xref.Part7.4"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Authentication">[Part7]</cite></a></td>
    22142214               </tr>
    22152215               <tr>
     
    22412241                  <td class="left">407</td>
    22422242                  <td class="left">Proxy Authentication Required</td>
    2243                   <td id="status.407" class="left"><a href="p7-auth.html#status.407" title="407 Proxy Authentication Required">Section 3.2</a> of <a href="#Part7" id="rfc.xref.Part7.5"><cite title="HTTP/1.1, part 7: Authentication">[Part7]</cite></a></td>
     2243                  <td id="status.407" class="left"><a href="p7-auth.html#status.407" title="407 Proxy Authentication Required">Section 3.2</a> of <a href="#Part7" id="rfc.xref.Part7.5"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Authentication">[Part7]</cite></a></td>
    22442244               </tr>
    22452245               <tr>
     
    22662266                  <td class="left">412</td>
    22672267                  <td class="left">Precondition Failed</td>
    2268                   <td id="status.412" class="left"><a href="p4-conditional.html#status.412" title="412 Precondition Failed">Section 4.2</a> of <a href="#Part4" id="rfc.xref.Part4.11"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a></td>
     2268                  <td id="status.412" class="left"><a href="p4-conditional.html#status.412" title="412 Precondition Failed">Section 4.2</a> of <a href="#Part4" id="rfc.xref.Part4.11"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a></td>
    22692269               </tr>
    22702270               <tr>
     
    22862286                  <td class="left">416</td>
    22872287                  <td class="left">Requested range not satisfiable</td>
    2288                   <td id="status.416" class="left"><a href="p5-range.html#status.416" title="416 Requested Range Not Satisfiable">Section 3.2</a> of <a href="#Part5" id="rfc.xref.Part5.9"><cite title="HTTP/1.1, part 5: Range Requests">[Part5]</cite></a></td>
     2288                  <td id="status.416" class="left"><a href="p5-range.html#status.416" title="416 Requested Range Not Satisfiable">Section 3.2</a> of <a href="#Part5" id="rfc.xref.Part5.9"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Range Requests">[Part5]</cite></a></td>
    22892289               </tr>
    22902290               <tr>
     
    23562356      <div id="rfc.iref.s.5"></div>
    23572357      <h3 id="rfc.section.7.2.2"><a href="#rfc.section.7.2.2">7.2.2</a>&nbsp;<a id="status.101" href="#status.101">101 Switching Protocols</a></h3>
    2358       <p id="rfc.section.7.2.2.p.1">The server understands and is willing to comply with the client's request, via the <a href="p1-messaging.html#header.upgrade" class="smpl">Upgrade</a> message header field (<a href="p1-messaging.html#header.upgrade" title="Upgrade">Section 6.3</a> of <a href="#Part1" id="rfc.xref.Part1.19"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>), for a change in the application protocol being used on this connection. The server will switch protocols to those defined
     2358      <p id="rfc.section.7.2.2.p.1">The server understands and is willing to comply with the client's request, via the <a href="p1-messaging.html#header.upgrade" class="smpl">Upgrade</a> message header field (<a href="p1-messaging.html#header.upgrade" title="Upgrade">Section 6.3</a> of <a href="#Part1" id="rfc.xref.Part1.19"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>), for a change in the application protocol being used on this connection. The server will switch protocols to those defined
    23592359         by the response's Upgrade header field immediately after the empty line which terminates the 101 response.
    23602360      </p>
     
    23812381         <dd>a representation containing the request message as received by the end server.</dd>
    23822382      </dl>
    2383       <p id="rfc.section.7.3.1.p.2">Caches <em class="bcp14">MAY</em> use a heuristic (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 4.1.2</a> of <a href="#Part6" id="rfc.xref.Part6.8"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) to determine freshness for 200 responses.
     2383      <p id="rfc.section.7.3.1.p.2">Caches <em class="bcp14">MAY</em> use a heuristic (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 4.1.2</a> of <a href="#Part6" id="rfc.xref.Part6.8"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>) to determine freshness for 200 responses.
    23842384      </p>
    23852385      <div id="rfc.iref.80"></div>
     
    23942394      </p>
    23952395      <p id="rfc.section.7.3.2.p.4">A 201 response <em class="bcp14">MAY</em> contain an <a href="p4-conditional.html#header.etag" class="smpl">ETag</a> response header field indicating the current value of the entity-tag for the representation of the resource identified by
    2396          the <a href="#header.location" class="smpl">Location</a> header field or, in case the Location header field was omitted, by the Effective Request URI (see <a href="p4-conditional.html#header.etag" title="ETag">Section 2.3</a> of <a href="#Part4" id="rfc.xref.Part4.12"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>).
     2396         the <a href="#header.location" class="smpl">Location</a> header field or, in case the Location header field was omitted, by the Effective Request URI (see <a href="p4-conditional.html#header.etag" title="ETag">Section 2.3</a> of <a href="#Part4" id="rfc.xref.Part4.12"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a>).
    23972397      </p>
    23982398      <div id="rfc.iref.81"></div>
     
    24112411      <div id="rfc.iref.s.10"></div>
    24122412      <h3 id="rfc.section.7.3.4"><a href="#rfc.section.7.3.4">7.3.4</a>&nbsp;<a id="status.203" href="#status.203">203 Non-Authoritative Information</a></h3>
    2413       <p id="rfc.section.7.3.4.p.1">The representation in the response has been transformed or otherwise modified by a transforming proxy (<a href="p1-messaging.html#intermediaries" title="Intermediaries">Section 2.3</a> of <a href="#Part1" id="rfc.xref.Part1.20"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>). Note that the behavior of transforming intermediaries is controlled by the no-transform Cache-Control directive (<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>).
     2413      <p id="rfc.section.7.3.4.p.1">The representation in the response has been transformed or otherwise modified by a transforming proxy (<a href="p1-messaging.html#intermediaries" title="Intermediaries">Section 2.3</a> of <a href="#Part1" id="rfc.xref.Part1.20"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>). Note that the behavior of transforming intermediaries is controlled by the no-transform Cache-Control directive (<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>).
    24142414      </p>
    24152415      <p id="rfc.section.7.3.4.p.2">This status code is only appropriate when the response status code would have been <a href="#status.200" class="smpl">200 (OK)</a> otherwise. When the status code before transformation would have been different, the 214 Transformation Applied warn-code
    2416          (<a href="p6-cache.html#header.warning" title="Warning">Section 7.5</a> of <a href="#Part6" id="rfc.xref.Part6.10"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) is appropriate.
    2417       </p>
    2418       <p id="rfc.section.7.3.4.p.3">Caches <em class="bcp14">MAY</em> use a heuristic (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 4.1.2</a> of <a href="#Part6" id="rfc.xref.Part6.11"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) to determine freshness for 203 responses.
     2416         (<a href="p6-cache.html#header.warning" title="Warning">Section 7.5</a> of <a href="#Part6" id="rfc.xref.Part6.10"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>) is appropriate.
     2417      </p>
     2418      <p id="rfc.section.7.3.4.p.3">Caches <em class="bcp14">MAY</em> use a heuristic (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 4.1.2</a> of <a href="#Part6" id="rfc.xref.Part6.11"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>) to determine freshness for 203 responses.
    24192419      </p>
    24202420      <div id="rfc.iref.83"></div>
     
    24462446         another input action.
    24472447      </p>
    2448       <p id="rfc.section.7.3.6.p.2">The message body included with the response <em class="bcp14">MUST</em> be empty. Note that receivers still need to parse the response according to the algorithm defined in <a href="p1-messaging.html#message.body" title="Message Body">Section 3.3</a> of <a href="#Part1" id="rfc.xref.Part1.21"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>.
     2448      <p id="rfc.section.7.3.6.p.2">The message body included with the response <em class="bcp14">MUST</em> be empty. Note that receivers still need to parse the response according to the algorithm defined in <a href="p1-messaging.html#message.body" title="Message Body">Section 3.3</a> of <a href="#Part1" id="rfc.xref.Part1.21"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>.
    24492449      </p>
    24502450      <h2 id="rfc.section.7.4"><a href="#rfc.section.7.4">7.4</a>&nbsp;<a id="status.3xx" href="#status.3xx">Redirection 3xx</a></h2>
     
    24742474         <li>
    24752475            <p>Other kinds of redirection, such as to a cached result (status code <a href="p4-conditional.html#status.304" class="smpl">304
    2476                   (Not Modified)</a>, see <a href="p4-conditional.html#status.304" title="304 Not Modified">Section 4.1</a> of <a href="#Part4" id="rfc.xref.Part4.13"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>).
     2476                  (Not Modified)</a>, see <a href="p4-conditional.html#status.304" title="304 Not Modified">Section 4.1</a> of <a href="#Part4" id="rfc.xref.Part4.13"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a>).
    24772477            </p>
    24782478         </li>
     
    25082508      <p id="rfc.section.7.4.1.p.3">If the server has a preferred choice of representation, it <em class="bcp14">SHOULD</em> include the specific URI for that representation in the <a href="#header.location" class="smpl">Location</a> field; user agents <em class="bcp14">MAY</em> use the Location field value for automatic redirection.
    25092509      </p>
    2510       <p id="rfc.section.7.4.1.p.4">Caches <em class="bcp14">MAY</em> use a heuristic (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 4.1.2</a> of <a href="#Part6" id="rfc.xref.Part6.12"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) to determine freshness for 300 responses.
     2510      <p id="rfc.section.7.4.1.p.4">Caches <em class="bcp14">MAY</em> use a heuristic (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 4.1.2</a> of <a href="#Part6" id="rfc.xref.Part6.12"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>) to determine freshness for 300 responses.
    25112511      </p>
    25122512      <div id="rfc.iref.87"></div>
     
    25162516         request URI to one or more of the new references returned by the server, where possible.
    25172517      </p>
    2518       <p id="rfc.section.7.4.2.p.2">Caches <em class="bcp14">MAY</em> use a heuristic (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 4.1.2</a> of <a href="#Part6" id="rfc.xref.Part6.13"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) to determine freshness for 301 responses.
     2518      <p id="rfc.section.7.4.2.p.2">Caches <em class="bcp14">MAY</em> use a heuristic (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 4.1.2</a> of <a href="#Part6" id="rfc.xref.Part6.13"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>) to determine freshness for 301 responses.
    25192519      </p>
    25202520      <p id="rfc.section.7.4.2.p.3">The new permanent URI <em class="bcp14">SHOULD</em> be given by the <a href="#header.location" class="smpl">Location</a> field in the response. A response payload can contain a short hypertext note with a hyperlink to the new URI(s).
     
    26652665         — that is left to the discretion of the server owner.
    26662666      </p>
    2667       <p id="rfc.section.7.5.9.p.3">Caches <em class="bcp14">MAY</em> use a heuristic (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 4.1.2</a> of <a href="#Part6" id="rfc.xref.Part6.14"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) to determine freshness for 410 responses.
     2667      <p id="rfc.section.7.5.9.p.3">Caches <em class="bcp14">MAY</em> use a heuristic (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 4.1.2</a> of <a href="#Part6" id="rfc.xref.Part6.14"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>) to determine freshness for 410 responses.
    26682668      </p>
    26692669      <div id="rfc.iref.103"></div>
     
    27052705      <div id="rfc.iref.s.36"></div>
    27062706      <h3 id="rfc.section.7.5.15"><a href="#rfc.section.7.5.15">7.5.15</a>&nbsp;<a id="status.426" href="#status.426">426 Upgrade Required</a></h3>
    2707       <p id="rfc.section.7.5.15.p.1">The request can not be completed without a prior protocol upgrade. This response <em class="bcp14">MUST</em> include an <a href="p1-messaging.html#header.upgrade" class="smpl">Upgrade</a> header field (<a href="p1-messaging.html#header.upgrade" title="Upgrade">Section 6.3</a> of <a href="#Part1" id="rfc.xref.Part1.22"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>) specifying the required protocols.
     2707      <p id="rfc.section.7.5.15.p.1">The request can not be completed without a prior protocol upgrade. This response <em class="bcp14">MUST</em> include an <a href="p1-messaging.html#header.upgrade" class="smpl">Upgrade</a> header field (<a href="p1-messaging.html#header.upgrade" title="Upgrade">Section 6.3</a> of <a href="#Part1" id="rfc.xref.Part1.22"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>) specifying the required protocols.
    27082708      </p>
    27092709      <div id="rfc.figure.u.33"></div>
     
    27702770      <p id="rfc.section.7.6.6.p.1">The server does not support, or refuses to support, the protocol version that was used in the request message. The server
    27712771         is indicating that it is unable or unwilling to complete the request using the same major version as the client, as described
    2772          in <a href="p1-messaging.html#http.version" title="Protocol Versioning">Section 2.6</a> of <a href="#Part1" id="rfc.xref.Part1.23"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>, other than with this error message. The response <em class="bcp14">SHOULD</em> contain a representation describing why that version is not supported and what other protocols are supported by that server.
     2772         in <a href="p1-messaging.html#http.version" title="Protocol Versioning">Section 2.6</a> of <a href="#Part1" id="rfc.xref.Part1.23"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, other than with this error message. The response <em class="bcp14">SHOULD</em> contain a representation describing why that version is not supported and what other protocols are supported by that server.
    27732773      </p>
    27742774      <h1 id="rfc.section.8"><a href="#rfc.section.8">8.</a>&nbsp;<a id="response.header.fields" href="#response.header.fields">Response Header Fields</a></h1>
    27752775      <p id="rfc.section.8.p.1">The response header fields allow the server to pass additional information about the response which cannot be placed in the
    2776          status-line. These header fields give information about the server and about further access to the target resource (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 5.5</a> of <a href="#Part1" id="rfc.xref.Part1.24"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>).
     2776         status-line. These header fields give information about the server and about further access to the target resource (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 5.5</a> of <a href="#Part1" id="rfc.xref.Part1.24"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>).
    27772777      </p>
    27782778      <h2 id="rfc.section.8.1"><a href="#rfc.section.8.1">8.1</a>&nbsp;<a id="response.control.data" href="#response.control.data">Control Data</a></h2>
     
    28582858               <tr>
    28592859                  <td class="left">Age</td>
    2860                   <td class="left"><a href="p6-cache.html#header.age" title="Age">Section 7.1</a> of <a href="#Part6" id="rfc.xref.Part6.15"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a></td>
     2860                  <td class="left"><a href="p6-cache.html#header.age" title="Age">Section 7.1</a> of <a href="#Part6" id="rfc.xref.Part6.15"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a></td>
    28612861               </tr>
    28622862               <tr>
     
    29052905      <h3 id="rfc.section.8.2.2"><a href="#rfc.section.8.2.2">8.2.2</a>&nbsp;<a id="header.vary" href="#header.vary">Vary</a></h3>
    29062906      <p id="rfc.section.8.2.2.p.1">The "Vary" header field conveys the set of header fields that were used to select the representation.</p>
    2907       <p id="rfc.section.8.2.2.p.2">Caches use this information as part of determining whether a stored response can be used to satisfy a given request (<a href="p6-cache.html#caching.negotiated.responses" title="Using Negotiated Responses">Section 4.3</a> of <a href="#Part6" id="rfc.xref.Part6.16"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>).
     2907      <p id="rfc.section.8.2.2.p.2">Caches use this information as part of determining whether a stored response can be used to satisfy a given request (<a href="p6-cache.html#caching.negotiated.responses" title="Using Negotiated Responses">Section 4.3</a> of <a href="#Part6" id="rfc.xref.Part6.16"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>).
    29082908      </p>
    29092909      <p id="rfc.section.8.2.2.p.3">In uncacheable or stale responses, the Vary field value advises the user agent about the criteria that were used to select
     
    29392939               <tr>
    29402940                  <td class="left">WWW-Authenticate</td>
    2941                   <td class="left"><a href="p7-auth.html#header.www-authenticate" title="WWW-Authenticate">Section 4.4</a> of <a href="#Part7" id="rfc.xref.Part7.6"><cite title="HTTP/1.1, part 7: Authentication">[Part7]</cite></a></td>
     2941                  <td class="left"><a href="p7-auth.html#header.www-authenticate" title="WWW-Authenticate">Section 4.4</a> of <a href="#Part7" id="rfc.xref.Part7.6"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Authentication">[Part7]</cite></a></td>
    29422942               </tr>
    29432943               <tr>
    29442944                  <td class="left">Proxy-Authenticate</td>
    2945                   <td class="left"><a href="p7-auth.html#header.proxy-authenticate" title="Proxy-Authenticate">Section 4.2</a> of <a href="#Part7" id="rfc.xref.Part7.7"><cite title="HTTP/1.1, part 7: Authentication">[Part7]</cite></a></td>
     2945                  <td class="left"><a href="p7-auth.html#header.proxy-authenticate" title="Proxy-Authenticate">Section 4.2</a> of <a href="#Part7" id="rfc.xref.Part7.7"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Authentication">[Part7]</cite></a></td>
    29462946               </tr>
    29472947            </tbody>
     
    29612961               <tr>
    29622962                  <td class="left">Accept-Ranges</td>
    2963                   <td class="left"><a href="p5-range.html#header.accept-ranges" title="Accept-Ranges">Section 5.1</a> of <a href="#Part5" id="rfc.xref.Part5.10"><cite title="HTTP/1.1, part 5: Range Requests">[Part5]</cite></a></td>
     2963                  <td class="left"><a href="p5-range.html#header.accept-ranges" title="Accept-Ranges">Section 5.1</a> of <a href="#Part5" id="rfc.xref.Part5.10"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Range Requests">[Part5]</cite></a></td>
    29642964               </tr>
    29652965               <tr>
     
    29912991      <h3 id="rfc.section.8.4.2"><a href="#rfc.section.8.4.2">8.4.2</a>&nbsp;<a id="header.server" href="#header.server">Server</a></h3>
    29922992      <p id="rfc.section.8.4.2.p.1">The "Server" header field contains information about the software used by the origin server to handle the request.</p>
    2993       <p id="rfc.section.8.4.2.p.2">The field can contain multiple product tokens (<a href="#product.tokens" title="Product Tokens">Section&nbsp;9.2</a>) and comments (<a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.25"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>) identifying the server and any significant subproducts. The product tokens are listed in order of their significance for
     2993      <p id="rfc.section.8.4.2.p.2">The field can contain multiple product tokens (<a href="#product.tokens" title="Product Tokens">Section&nbsp;9.2</a>) and comments (<a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.25"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>) identifying the server and any significant subproducts. The product tokens are listed in order of their significance for
    29942994         identifying the application.
    29952995      </p>
     
    29972997</pre><p id="rfc.section.8.4.2.p.4">Example:</p>
    29982998      <div id="rfc.figure.u.46"></div><pre class="text">  Server: CERN/3.0 libwww/2.17
    2999 </pre><p id="rfc.section.8.4.2.p.6">If the response is being forwarded through a proxy, the proxy application <em class="bcp14">MUST NOT</em> modify the <a href="#header.server" class="smpl">Server</a> header field. Instead, it <em class="bcp14">MUST</em> include a <a href="p1-messaging.html#header.via" class="smpl">Via</a> field (as described in <a href="p1-messaging.html#header.via" title="Via">Section 5.7</a> of <a href="#Part1" id="rfc.xref.Part1.26"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>).
     2999</pre><p id="rfc.section.8.4.2.p.6">If the response is being forwarded through a proxy, the proxy application <em class="bcp14">MUST NOT</em> modify the <a href="#header.server" class="smpl">Server</a> header field. Instead, it <em class="bcp14">MUST</em> include a <a href="p1-messaging.html#header.via" class="smpl">Via</a> field (as described in <a href="p1-messaging.html#header.via" title="Via">Section 5.7</a> of <a href="#Part1" id="rfc.xref.Part1.26"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>).
    30003000      </p>
    30013001      <div class="note" id="rfc.section.8.4.2.p.7">
     
    31323132      </p>
    31333133      <ul class="empty">
    3134          <li>See <a href="p1-messaging.html#compress.coding" title="Compress Coding">Section 4.2.1</a> of <a href="#Part1" id="rfc.xref.Part1.27"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>.
     3134         <li>See <a href="p1-messaging.html#compress.coding" title="Compress Coding">Section 4.2.1</a> of <a href="#Part1" id="rfc.xref.Part1.27"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>.
    31353135         </li>
    31363136      </ul>
     
    31383138      </p>
    31393139      <ul class="empty">
    3140          <li>See <a href="p1-messaging.html#deflate.coding" title="Deflate Coding">Section 4.2.2</a> of <a href="#Part1" id="rfc.xref.Part1.28"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>.
     3140         <li>See <a href="p1-messaging.html#deflate.coding" title="Deflate Coding">Section 4.2.2</a> of <a href="#Part1" id="rfc.xref.Part1.28"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>.
    31413141         </li>
    31423142      </ul>
     
    31443144      </p>
    31453145      <ul class="empty">
    3146          <li>See <a href="p1-messaging.html#gzip.coding" title="Gzip Coding">Section 4.2.3</a> of <a href="#Part1" id="rfc.xref.Part1.29"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>.
     3146         <li>See <a href="p1-messaging.html#gzip.coding" title="Gzip Coding">Section 4.2.3</a> of <a href="#Part1" id="rfc.xref.Part1.29"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>.
    31473147         </li>
    31483148      </ul>
     
    32383238         specific to a single application or data format, since orthogonal technologies deserve orthogonal specification.
    32393239      </p>
    3240       <p id="rfc.section.10.1.2.p.2">Since HTTP message parsing (<a href="p1-messaging.html#message.body" title="Message Body">Section 3.3</a> of <a href="#Part1" id="rfc.xref.Part1.30"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>) is independent of method semantics (aside from responses to HEAD), definitions of new HTTP methods cannot change the parsing
     3240      <p id="rfc.section.10.1.2.p.2">Since HTTP message parsing (<a href="p1-messaging.html#message.body" title="Message Body">Section 3.3</a> of <a href="#Part1" id="rfc.xref.Part1.30"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>) is independent of method semantics (aside from responses to HEAD), definitions of new HTTP methods cannot change the parsing
    32413241         algorithm or prohibit the presence of a message body on either the request or the response message. Definitions of new methods
    32423242         can specify that only zero-length bodies are allowed, which would imply that each such messages would be required to contain
     
    33433343         a zero-length response body. They can require the presence of one or more particular HTTP response header field(s).
    33443344      </p>
    3345       <p id="rfc.section.10.2.2.p.5">Likewise, their definitions can specify that caches are allowed to use heuristics to determine their freshness (see <a href="#Part6" id="rfc.xref.Part6.17"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>; by default, it is not allowed), and can define how to determine the resource which they carry a representation for (see <a href="#identifying.response.associated.with.representation" title="Identifying the Resource Associated with a Representation">Section&nbsp;3.1</a>; by default, it is anonymous).
     3345      <p id="rfc.section.10.2.2.p.5">Likewise, their definitions can specify that caches are allowed to use heuristics to determine their freshness (see <a href="#Part6" id="rfc.xref.Part6.17"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>; by default, it is not allowed), and can define how to determine the resource which they carry a representation for (see <a href="#identifying.response.associated.with.representation" title="Identifying the Resource Associated with a Representation">Section&nbsp;3.1</a>; by default, it is anonymous).
    33463346      </p>
    33473347      <h3 id="rfc.section.10.2.3"><a href="#rfc.section.10.2.3">10.2.3</a>&nbsp;<a id="status.code.registration" href="#status.code.registration">Registrations</a></h3>
     
    35823582      <h3 id="rfc.section.10.3.1"><a href="#rfc.section.10.3.1">10.3.1</a>&nbsp;<a id="considerations.for.new.header.fields" href="#considerations.for.new.header.fields">Considerations for New Header Fields</a></h3>
    35833583      <p id="rfc.section.10.3.1.p.1">Header fields are key:value pairs that can be used to communicate data about the message, its payload, the target resource,
    3584          or the connection (i.e., control data). See <a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.31"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a> for a general definition of header field syntax in HTTP messages.
     3584         or the connection (i.e., control data). See <a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.31"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a> for a general definition of header field syntax in HTTP messages.
    35853585      </p>
    35863586      <p id="rfc.section.10.3.1.p.2">The requirements for header field names are defined in <a href="http://tools.ietf.org/html/rfc3864#section-4.1">Section 4.1</a> of <a href="#RFC3864" id="rfc.xref.RFC3864.2"><cite title="Registration Procedures for Message Header Fields">[RFC3864]</cite></a>. Authors of specifications defining new fields are advised to keep the name as short as practical, and not to prefix them
    35873587         with "X-" if they are to be registered (either immediately or in the future).
    35883588      </p>
    3589       <p id="rfc.section.10.3.1.p.3">New header field values typically have their syntax defined using ABNF (<a href="#RFC5234" id="rfc.xref.RFC5234.2"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a>), using the extension defined in <a href="p1-messaging.html#abnf.extension" title="ABNF list extension: #rule">Appendix B</a> of <a href="#Part1" id="rfc.xref.Part1.32"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a> as necessary, and are usually constrained to the range of ASCII characters. Header fields needing a greater range of characters
     3589      <p id="rfc.section.10.3.1.p.3">New header field values typically have their syntax defined using ABNF (<a href="#RFC5234" id="rfc.xref.RFC5234.2"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a>), using the extension defined in <a href="p1-messaging.html#abnf.extension" title="ABNF list extension: #rule">Appendix B</a> of <a href="#Part1" id="rfc.xref.Part1.32"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a> as necessary, and are usually constrained to the range of ASCII characters. Header fields needing a greater range of characters
    35903590         can use an encoding such as the one defined in <a href="#RFC5987" id="rfc.xref.RFC5987.1"><cite title="Character Set and Language Encoding for Hypertext Transfer Protocol (HTTP) Header Field Parameters">[RFC5987]</cite></a>.
    35913591      </p>
    35923592      <p id="rfc.section.10.3.1.p.4">Because commas (",") are used as a generic delimiter between field-values, they need to be treated with care if they are allowed
    35933593         in the field-value's payload. Typically, components that might contain a comma are protected with double-quotes using the
    3594          quoted-string ABNF production (<a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.4</a> of <a href="#Part1" id="rfc.xref.Part1.33"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>).
     3594         quoted-string ABNF production (<a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.4</a> of <a href="#Part1" id="rfc.xref.Part1.33"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>).
    35953595      </p>
    35963596      <p id="rfc.section.10.3.1.p.5">For example, a textual date and a URI (either of which might contain a comma) could be safely carried in field-values like
     
    36103610      <ul>
    36113611         <li>
    3612             <p>Whether the field is a single value, or whether it can be a list (delimited by commas; see <a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.34"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>).
     3612            <p>Whether the field is a single value, or whether it can be a list (delimited by commas; see <a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.34"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>).
    36133613            </p>
    36143614            <p>If it does not use the list syntax, document how to treat messages where the header field occurs multiple times (a sensible
     
    36263626         </li>
    36273627         <li>
    3628             <p>Whether it is appropriate to list the field-name in the <a href="p1-messaging.html#header.connection" class="smpl">Connection</a> header field (i.e., if the header field is to be hop-by-hop, see <a href="p1-messaging.html#header.connection" title="Connection">Section 6.1</a> of <a href="#Part1" id="rfc.xref.Part1.35"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>).
     3628            <p>Whether it is appropriate to list the field-name in the <a href="p1-messaging.html#header.connection" class="smpl">Connection</a> header field (i.e., if the header field is to be hop-by-hop, see <a href="p1-messaging.html#header.connection" title="Connection">Section 6.1</a> of <a href="#Part1" id="rfc.xref.Part1.35"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>).
    36293629            </p>
    36303630         </li>
     
    36333633         </li>
    36343634         <li>
    3635             <p>How the header field might interact with caching (see <a href="#Part6" id="rfc.xref.Part6.18"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>).
     3635            <p>How the header field might interact with caching (see <a href="#Part6" id="rfc.xref.Part6.18"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>).
    36363636            </p>
    36373637         </li>
    36383638         <li>
    3639             <p>Whether the header field is useful or allowable in trailers (see <a href="p1-messaging.html#chunked.encoding" title="Chunked Transfer Coding">Section 4.1</a> of <a href="#Part1" id="rfc.xref.Part1.36"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>).
     3639            <p>Whether the header field is useful or allowable in trailers (see <a href="p1-messaging.html#chunked.encoding" title="Chunked Transfer Coding">Section 4.1</a> of <a href="#Part1" id="rfc.xref.Part1.36"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>).
    36403640            </p>
    36413641         </li>
     
    38033803      <p id="rfc.section.10.3.2.p.2">The change controller for the above registrations is: "IETF (iesg@ietf.org) - Internet Engineering Task Force".</p>
    38043804      <h2 id="rfc.section.10.4"><a href="#rfc.section.10.4">10.4</a>&nbsp;<a id="content.coding.registry" href="#content.coding.registry">Content Coding Registry</a></h2>
    3805       <p id="rfc.section.10.4.p.1">The HTTP Content Coding Registry defines the name space for content coding names (<a href="p1-messaging.html#compression.codings" title="Compression Codings">Section 4.2</a> of <a href="#Part1" id="rfc.xref.Part1.37"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>). The content coding registry is maintained at &lt;<a href="http://www.iana.org/assignments/http-parameters">http://www.iana.org/assignments/http-parameters</a>&gt;.
     3805      <p id="rfc.section.10.4.p.1">The HTTP Content Coding Registry defines the name space for content coding names (<a href="p1-messaging.html#compression.codings" title="Compression Codings">Section 4.2</a> of <a href="#Part1" id="rfc.xref.Part1.37"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>). The content coding registry is maintained at &lt;<a href="http://www.iana.org/assignments/http-parameters">http://www.iana.org/assignments/http-parameters</a>&gt;.
    38063806      </p>
    38073807      <h3 id="rfc.section.10.4.1"><a href="#rfc.section.10.4.1">10.4.1</a>&nbsp;<a id="content.coding.procedure" href="#content.coding.procedure">Procedure</a></h3>
     
    38133813         <li>Pointer to specification text</li>
    38143814      </ul>
    3815       <p id="rfc.section.10.4.1.p.2">Names of content codings <em class="bcp14">MUST NOT</em> overlap with names of transfer codings (<a href="p1-messaging.html#transfer.codings" title="Transfer Codings">Section 4</a> of <a href="#Part1" id="rfc.xref.Part1.38"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>), unless the encoding transformation is identical (as is the case for the compression codings defined in <a href="p1-messaging.html#compression.codings" title="Compression Codings">Section 4.2</a> of <a href="#Part1" id="rfc.xref.Part1.39"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>).
     3815      <p id="rfc.section.10.4.1.p.2">Names of content codings <em class="bcp14">MUST NOT</em> overlap with names of transfer codings (<a href="p1-messaging.html#transfer.codings" title="Transfer Codings">Section 4</a> of <a href="#Part1" id="rfc.xref.Part1.38"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>), unless the encoding transformation is identical (as is the case for the compression codings defined in <a href="p1-messaging.html#compression.codings" title="Compression Codings">Section 4.2</a> of <a href="#Part1" id="rfc.xref.Part1.39"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>).
    38163816      </p>
    38173817      <p id="rfc.section.10.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.3"><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 content coding defined in this section.
     
    38333833                  <td class="left">compress</td>
    38343834                  <td class="left">UNIX "compress" program method</td>
    3835                   <td class="left"> <a href="p1-messaging.html#compress.coding" title="Compress Coding">Section 4.2.1</a> of <a href="#Part1" id="rfc.xref.Part1.40"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>
     3835                  <td class="left"> <a href="p1-messaging.html#compress.coding" title="Compress Coding">Section 4.2.1</a> of <a href="#Part1" id="rfc.xref.Part1.40"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>
    38363836                  </td>
    38373837               </tr>
     
    38403840                  <td class="left">"deflate" compression mechanism (<a href="#RFC1951" id="rfc.xref.RFC1951.1"><cite title="DEFLATE Compressed Data Format Specification version 1.3">[RFC1951]</cite></a>) used inside the "zlib" data format (<a href="#RFC1950" id="rfc.xref.RFC1950.1"><cite title="ZLIB Compressed Data Format Specification version 3.3">[RFC1950]</cite></a>)
    38413841                  </td>
    3842                   <td class="left"> <a href="p1-messaging.html#deflate.coding" title="Deflate Coding">Section 4.2.2</a> of <a href="#Part1" id="rfc.xref.Part1.41"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>
     3842                  <td class="left"> <a href="p1-messaging.html#deflate.coding" title="Deflate Coding">Section 4.2.2</a> of <a href="#Part1" id="rfc.xref.Part1.41"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>
    38433843                  </td>
    38443844               </tr>
     
    38463846                  <td class="left">gzip</td>
    38473847                  <td class="left">Same as GNU zip <a href="#RFC1952" id="rfc.xref.RFC1952.1"><cite title="GZIP file format specification version 4.3">[RFC1952]</cite></a></td>
    3848                   <td class="left"> <a href="p1-messaging.html#gzip.coding" title="Gzip Coding">Section 4.2.3</a> of <a href="#Part1" id="rfc.xref.Part1.42"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>
     3848                  <td class="left"> <a href="p1-messaging.html#gzip.coding" title="Gzip Coding">Section 4.2.3</a> of <a href="#Part1" id="rfc.xref.Part1.42"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>
    38493849                  </td>
    38503850               </tr>
     
    39383938      </p>
    39393939      <h1 id="rfc.section.12"><a href="#rfc.section.12">12.</a>&nbsp;<a id="acks" href="#acks">Acknowledgments</a></h1>
    3940       <p id="rfc.section.12.p.1">See <a href="p1-messaging.html#acks" title="Acknowledgments">Section 9</a> of <a href="#Part1" id="rfc.xref.Part1.43"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>.
     3940      <p id="rfc.section.12.p.1">See <a href="p1-messaging.html#acks" title="Acknowledgments">Section 9</a> of <a href="#Part1" id="rfc.xref.Part1.43"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>.
    39413941      </p>
    39423942      <h1 id="rfc.references"><a id="rfc.section.13" href="#rfc.section.13">13.</a> References
     
    39473947         <tr>
    39483948            <td class="reference"><b id="Part1">[Part1]</b></td>
    3949             <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-p1-messaging-latest">HTTP/1.1, part 1: Message Routing and Syntax"</a>”, Internet-Draft&nbsp;draft-ietf-httpbis-p1-messaging-latest (work in progress), September&nbsp;2012.
     3949            <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-p1-messaging-latest">Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing</a>”, Internet-Draft&nbsp;draft-ietf-httpbis-p1-messaging-latest (work in progress), September&nbsp;2012.
    39503950            </td>
    39513951         </tr>
    39523952         <tr>
    39533953            <td class="reference"><b id="Part4">[Part4]</b></td>
    3954             <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.
     3954            <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.
    39553955            </td>
    39563956         </tr>
    39573957         <tr>
    39583958            <td class="reference"><b id="Part5">[Part5]</b></td>
    3959             <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.
     3959            <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.
    39603960            </td>
    39613961         </tr>
    39623962         <tr>
    39633963            <td class="reference"><b id="Part6">[Part6]</b></td>
    3964             <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.
     3964            <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.
    39653965            </td>
    39663966         </tr>
    39673967         <tr>
    39683968            <td class="reference"><b id="Part7">[Part7]</b></td>
    3969             <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.
     3969            <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.
    39703970            </td>
    39713971         </tr>
     
    42504250      <p id="rfc.section.C.p.16">Allow <a href="#header.referer" class="smpl">Referer</a> field value of "about:blank" as alternative to not specifying it. (<a href="#header.referer" id="rfc.xref.header.referer.3" title="Referer">Section&nbsp;6.5.2</a>)
    42514251      </p>
    4252       <p id="rfc.section.C.p.17">In the description of the <a href="#header.server" class="smpl">Server</a> header field, the <a href="p1-messaging.html#header.via" class="smpl">Via</a> field was described as a SHOULD. The requirement was and is stated correctly in the description of the Via header field in <a href="p1-messaging.html#header.via" title="Via">Section 5.7</a> of <a href="#Part1" id="rfc.xref.Part1.44"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>. (<a href="#header.server" id="rfc.xref.header.server.4" title="Server">Section&nbsp;8.4.2</a>)
     4252      <p id="rfc.section.C.p.17">In the description of the <a href="#header.server" class="smpl">Server</a> header field, the <a href="p1-messaging.html#header.via" class="smpl">Via</a> field was described as a SHOULD. The requirement was and is stated correctly in the description of the Via header field in <a href="p1-messaging.html#header.via" title="Via">Section 5.7</a> of <a href="#Part1" id="rfc.xref.Part1.44"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>. (<a href="#header.server" id="rfc.xref.header.server.4" title="Server">Section&nbsp;8.4.2</a>)
    42534253      </p>
    42544254      <p id="rfc.section.C.p.18">Clarify contexts that charset is used in. (<a href="#character.sets" title="Character Encodings (charset)">Section&nbsp;9.3</a>)
     
    42774277         (any visible US-ASCII character).
    42784278      </p>
    4279       <p id="rfc.section.D.p.2">The rules below are defined in <a href="#Part1" id="rfc.xref.Part1.45"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>:
    4280       </p>
    4281       <div id="rfc.figure.u.64"></div><pre class="inline">  <a href="#imported.abnf" class="smpl">BWS</a>           = &lt;BWS, defined in <a href="#Part1" id="rfc.xref.Part1.46"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>, <a href="p1-messaging.html#whitespace" title="Whitespace">Section 3.2.1</a>&gt;
    4282   <a href="#imported.abnf" class="smpl">OWS</a>           = &lt;OWS, defined in <a href="#Part1" id="rfc.xref.Part1.47"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>, <a href="p1-messaging.html#whitespace" title="Whitespace">Section 3.2.1</a>&gt;
    4283   <a href="#imported.abnf" class="smpl">RWS</a>           = &lt;RWS, defined in <a href="#Part1" id="rfc.xref.Part1.48"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>, <a href="p1-messaging.html#whitespace" title="Whitespace">Section 3.2.1</a>&gt;
    4284   <a href="#imported.abnf" class="smpl">quoted-string</a> = &lt;quoted-string, defined in <a href="#Part1" id="rfc.xref.Part1.49"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>, <a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.4</a>&gt;
    4285   <a href="#imported.abnf" class="smpl">token</a>         = &lt;token, defined in <a href="#Part1" id="rfc.xref.Part1.50"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>, <a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.4</a>&gt;
    4286   <a href="#imported.abnf" class="smpl">word</a>          = &lt;word, defined in <a href="#Part1" id="rfc.xref.Part1.51"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>, <a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.4</a>&gt;
    4287 
    4288   <a href="#imported.abnf" class="smpl">absolute-URI</a>  = &lt;absolute-URI, defined in <a href="#Part1" id="rfc.xref.Part1.52"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.7</a>&gt;
    4289   <a href="#imported.abnf" class="smpl">comment</a>       = &lt;comment, defined in <a href="#Part1" id="rfc.xref.Part1.53"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>, <a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.4</a>&gt;
    4290   <a href="#imported.abnf" class="smpl">partial-URI</a>   = &lt;partial-URI, defined in <a href="#Part1" id="rfc.xref.Part1.54"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.7</a>&gt;
    4291   <a href="#imported.abnf" class="smpl">URI-reference</a> = &lt;URI-reference, defined in <a href="#Part1" id="rfc.xref.Part1.55"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.7</a>&gt;
     4279      <p id="rfc.section.D.p.2">The rules below are defined in <a href="#Part1" id="rfc.xref.Part1.45"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>:
     4280      </p>
     4281      <div id="rfc.figure.u.64"></div><pre class="inline">  <a href="#imported.abnf" class="smpl">BWS</a>           = &lt;BWS, defined in <a href="#Part1" id="rfc.xref.Part1.46"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#whitespace" title="Whitespace">Section 3.2.1</a>&gt;
     4282  <a href="#imported.abnf" class="smpl">OWS</a>           = &lt;OWS, defined in <a href="#Part1" id="rfc.xref.Part1.47"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#whitespace" title="Whitespace">Section 3.2.1</a>&gt;
     4283  <a href="#imported.abnf" class="smpl">RWS</a>           = &lt;RWS, defined in <a href="#Part1" id="rfc.xref.Part1.48"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#whitespace" title="Whitespace">Section 3.2.1</a>&gt;
     4284  <a href="#imported.abnf" class="smpl">quoted-string</a> = &lt;quoted-string, defined in <a href="#Part1" id="rfc.xref.Part1.49"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.4</a>&gt;
     4285  <a href="#imported.abnf" class="smpl">token</a>         = &lt;token, defined in <a href="#Part1" id="rfc.xref.Part1.50"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.4</a>&gt;
     4286  <a href="#imported.abnf" class="smpl">word</a>          = &lt;word, defined in <a href="#Part1" id="rfc.xref.Part1.51"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.4</a>&gt;
     4287
     4288  <a href="#imported.abnf" class="smpl">absolute-URI</a>  = &lt;absolute-URI, defined in <a href="#Part1" id="rfc.xref.Part1.52"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.7</a>&gt;
     4289  <a href="#imported.abnf" class="smpl">comment</a>       = &lt;comment, defined in <a href="#Part1" id="rfc.xref.Part1.53"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.4</a>&gt;
     4290  <a href="#imported.abnf" class="smpl">partial-URI</a>   = &lt;partial-URI, defined in <a href="#Part1" id="rfc.xref.Part1.54"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.7</a>&gt;
     4291  <a href="#imported.abnf" class="smpl">URI-reference</a> = &lt;URI-reference, defined in <a href="#Part1" id="rfc.xref.Part1.55"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.7</a>&gt;
    42924292</pre><h1 id="rfc.section.E"><a href="#rfc.section.E">E.</a>&nbsp;<a id="collected.abnf" href="#collected.abnf">Collected ABNF</a></h1>
    42934293      <div id="rfc.figure.u.65"></div> <pre class="inline"><a href="#header.accept" class="smpl">Accept</a> = [ ( "," / ( media-range [ accept-params ] ) ) *( OWS "," [
     
    44684468      <p id="rfc.section.F.2.p.2">Other changes: </p>
    44694469      <ul>
    4470          <li>Move definitions of 304 and 412 condition codes to <a href="#Part4" id="rfc.xref.Part4.14"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>
     4470         <li>Move definitions of 304 and 412 condition codes to <a href="#Part4" id="rfc.xref.Part4.14"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a>
    44714471         </li>
    44724472      </ul>
  • draft-ietf-httpbis/latest/p2-semantics.xml

    r1860 r1864  
    129129<front>
    130130
    131   <title abbrev="HTTP/1.1, Part 2">HTTP/1.1, part 2: Semantics and Payloads</title>
     131  <title abbrev="HTTP/1.1 Semantics and Content">Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</title>
    132132
    133133  <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor">
     
    49224922<reference anchor="Part1">
    49234923  <front>
    4924     <title>HTTP/1.1, part 1: Message Routing and Syntax"</title>
     4924    <title>Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing</title>
    49254925    <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor">
    49264926      <organization abbrev="Adobe">Adobe Systems Incorporated</organization>
     
    49504950<reference anchor="Part4">
    49514951  <front>
    4952     <title>HTTP/1.1, part 4: Conditional Requests</title>
     4952    <title>Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests</title>
    49534953    <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor">
    49544954      <organization abbrev="Adobe">Adobe Systems Incorporated</organization>
     
    49784978<reference anchor="Part5">
    49794979  <front>
    4980     <title>HTTP/1.1, part 5: Range Requests</title>
     4980    <title>Hypertext Transfer Protocol (HTTP/1.1): Range Requests</title>
    49814981    <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor">
    49824982      <organization abbrev="Adobe">Adobe Systems Incorporated</organization>
     
    50055005<reference anchor="Part6">
    50065006  <front>
    5007     <title>HTTP/1.1, part 6: Caching</title>
     5007    <title>Hypertext Transfer Protocol (HTTP/1.1): Caching</title>
    50085008    <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor">
    50095009      <organization abbrev="Adobe">Adobe Systems Incorporated</organization>
     
    50305030<reference anchor="Part7">
    50315031  <front>
    5032     <title>HTTP/1.1, part 7: Authentication</title>
     5032    <title>Hypertext Transfer Protocol (HTTP/1.1): Authentication</title>
    50335033    <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor">
    50345034      <organization abbrev="Adobe">Adobe Systems Incorporated</organization>
  • draft-ietf-httpbis/latest/p3-payload.html

    r1845 r1864  
    374374  }
    375375  @bottom-center {
    376        content: "Expires March 5, 2013";
     376       content: "Expires March 8, 2013";
    377377  }
    378378  @bottom-right {
     
    404404      <meta name="dct.creator" content="Reschke, J. F.">
    405405      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p3-payload-latest">
    406       <meta name="dct.issued" scheme="ISO8601" content="2012-09-01">
     406      <meta name="dct.issued" scheme="ISO8601" content="2012-09-04">
    407407      <meta name="dct.abstract" content="This part is now obsolete. Please see HTTPbis, Part 2.">
    408408      <meta name="description" content="This part is now obsolete. Please see HTTPbis, Part 2.">
     
    424424            </tr>
    425425            <tr>
    426                <td class="left">Expires: March 5, 2013</td>
     426               <td class="left">Expires: March 8, 2013</td>
    427427               <td class="right">W3C</td>
    428428            </tr>
     
    437437            <tr>
    438438               <td class="left"></td>
    439                <td class="right">September 1, 2012</td>
     439               <td class="right">September 4, 2012</td>
    440440            </tr>
    441441         </tbody>
     
    453453         in progress”.
    454454      </p>
    455       <p>This Internet-Draft will expire on March 5, 2013.</p>
     455      <p>This Internet-Draft will expire on March 8, 2013.</p>
    456456      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    457457      <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
  • draft-ietf-httpbis/latest/p4-conditional.html

    r1862 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 4: Conditional Requests</title><script>
     6      <title>Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests</title><script>
    77var buttonsAdded = false;
    88
     
    443443  }
    444444  @top-center {
    445        content: "HTTP/1.1, Part 4";
     445       content: "HTTP/1.1 Conditional Requests";
    446446  }
    447447  @bottom-left {
     
    531531         </tbody>
    532532      </table>
    533       <p class="title">HTTP/1.1, part 4: Conditional Requests<br><span class="filename">draft-ietf-httpbis-p4-conditional-latest</span></p>
     533      <p class="title">Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests<br><span class="filename">draft-ietf-httpbis-p4-conditional-latest</span></p>
    534534      <h1 id="rfc.abstract"><a href="#rfc.abstract">Abstract</a></h1>
    535535      <p>The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information
     
    631631      </ul>
    632632      <h1 id="rfc.section.1" class="np"><a href="#rfc.section.1">1.</a>&nbsp;<a id="introduction" href="#introduction">Introduction</a></h1>
    633       <p id="rfc.section.1.p.1">Conditional requests are HTTP requests <a href="#Part2" id="rfc.xref.Part2.1"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a> that include one or more header fields indicating a precondition to be tested before applying the method semantics to the
     633      <p id="rfc.section.1.p.1">Conditional requests are HTTP requests <a href="#Part2" id="rfc.xref.Part2.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a> that include one or more header fields indicating a precondition to be tested before applying the method semantics to the
    634634         target resource. Each precondition is based on metadata that is expected to change if the selected representation of the target
    635635         resource is changed. This document defines the HTTP/1.1 conditional request mechanisms in terms of the architecture, syntax
    636          notation, and conformance criteria defined in <a href="#Part1" id="rfc.xref.Part1.1"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>.
    637       </p>
    638       <p id="rfc.section.1.p.2">Conditional GET requests are the most efficient mechanism for HTTP cache updates <a href="#Part6" id="rfc.xref.Part6.1"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>. Conditionals can also be applied to state-changing methods, such as PUT and DELETE, to prevent the "lost update" problem:
     636         notation, and conformance criteria defined in <a href="#Part1" id="rfc.xref.Part1.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>.
     637      </p>
     638      <p id="rfc.section.1.p.2">Conditional GET requests are the most efficient mechanism for HTTP cache updates <a href="#Part6" id="rfc.xref.Part6.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>. Conditionals can also be applied to state-changing methods, such as PUT and DELETE, to prevent the "lost update" problem:
    639639         one client accidentally overwriting the work of another client that has been acting in parallel.
    640640      </p>
     
    657657      <p id="rfc.section.1.1.p.2">This specification targets conformance criteria according to the role of a participant in HTTP communication. Hence, HTTP
    658658         requirements are placed on senders, recipients, clients, servers, user agents, intermediaries, origin servers, proxies, gateways,
    659          or caches, depending on what behavior is being constrained by the requirement. See <a href="p1-messaging.html#architecture" title="Architecture">Section 2</a> of <a href="#Part1" id="rfc.xref.Part1.2"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a> for definitions of these terms.
     659         or caches, depending on what behavior is being constrained by the requirement. See <a href="p1-messaging.html#architecture" title="Architecture">Section 2</a> of <a href="#Part1" id="rfc.xref.Part1.2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a> for definitions of these terms.
    660660      </p>
    661661      <p id="rfc.section.1.1.p.3">The verb "generate" is used instead of "send" where a requirement differentiates between creating a protocol element and merely
     
    675675      </p>
    676676      <h2 id="rfc.section.1.2"><a href="#rfc.section.1.2">1.2</a>&nbsp;<a id="notation" href="#notation">Syntax Notation</a></h2>
    677       <p id="rfc.section.1.2.p.1">This specification uses the Augmented Backus-Naur Form (ABNF) notation of <a href="#RFC5234" id="rfc.xref.RFC5234.1"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a> with the list rule extension defined in <a href="p1-messaging.html#notation" title="Syntax Notation">Section 1.2</a> of <a href="#Part1" id="rfc.xref.Part1.3"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>. <a href="#imported.abnf" title="Imported ABNF">Appendix&nbsp;B</a> describes rules imported from other documents. <a href="#collected.abnf" title="Collected ABNF">Appendix&nbsp;C</a> shows the collected ABNF with the list rule expanded.
     677      <p id="rfc.section.1.2.p.1">This specification uses the Augmented Backus-Naur Form (ABNF) notation of <a href="#RFC5234" id="rfc.xref.RFC5234.1"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a> with the list rule extension defined in <a href="p1-messaging.html#notation" title="Syntax Notation">Section 1.2</a> of <a href="#Part1" id="rfc.xref.Part1.3"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>. <a href="#imported.abnf" title="Imported ABNF">Appendix&nbsp;B</a> describes rules imported from other documents. <a href="#collected.abnf" title="Collected ABNF">Appendix&nbsp;C</a> shows the collected ABNF with the list rule expanded.
    678678      </p>
    679679      <div id="rfc.iref.m.1"></div>
     
    739739</pre><h3 id="rfc.section.2.2.1"><a href="#rfc.section.2.2.1">2.2.1</a>&nbsp;<a id="lastmod.generation" href="#lastmod.generation">Generation</a></h3>
    740740      <p id="rfc.section.2.2.1.p.1">Origin servers <em class="bcp14">SHOULD</em> send Last-Modified for any selected representation for which a last modification date can be reasonably and consistently determined,
    741          since its use in conditional requests and evaluating cache freshness (<a href="#Part6" id="rfc.xref.Part6.2"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) results in a substantial reduction of HTTP traffic on the Internet and can be a significant factor in improving service
     741         since its use in conditional requests and evaluating cache freshness (<a href="#Part6" id="rfc.xref.Part6.2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>) results in a substantial reduction of HTTP traffic on the Internet and can be a significant factor in improving service
    742742         scalability and reliability.
    743743      </p>
     
    831831      </p>
    832832      <p id="rfc.section.2.3.1.p.3">Origin servers <em class="bcp14">SHOULD</em> send ETag for any selected representation for which detection of changes can be reasonably and consistently determined, since
    833          the entity-tag's use in conditional requests and evaluating cache freshness (<a href="#Part6" id="rfc.xref.Part6.3"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) can result in a substantial reduction of HTTP network traffic and can be a significant factor in improving service scalability
     833         the entity-tag's use in conditional requests and evaluating cache freshness (<a href="#Part6" id="rfc.xref.Part6.3"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>) can result in a substantial reduction of HTTP network traffic and can be a significant factor in improving service scalability
    834834         and reliability.
    835835      </p>
     
    884884      </div>
    885885      <h3 id="rfc.section.2.3.3"><a href="#rfc.section.2.3.3">2.3.3</a>&nbsp;<a id="example.entity.tag.vs.conneg" href="#example.entity.tag.vs.conneg">Example: Entity-tags varying on Content-Negotiated Resources</a></h3>
    886       <p id="rfc.section.2.3.3.p.1">Consider a resource that is subject to content negotiation (<a href="p2-semantics.html#content.negotiation" title="Content Negotiation">Section 3.5</a> of <a href="#Part2" id="rfc.xref.Part2.2"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>), and where the representations returned upon a GET request vary based on the <a href="p2-semantics.html#header.accept-encoding" class="smpl">Accept-Encoding</a> request header field (<a href="p2-semantics.html#header.accept-encoding" title="Accept-Encoding">Section 6.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>):
     886      <p id="rfc.section.2.3.3.p.1">Consider a resource that is subject to content negotiation (<a href="p2-semantics.html#content.negotiation" title="Content Negotiation">Section 3.5</a> of <a href="#Part2" id="rfc.xref.Part2.2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>), and where the representations returned upon a GET request vary based on the <a href="p2-semantics.html#header.accept-encoding" class="smpl">Accept-Encoding</a> request header field (<a href="p2-semantics.html#header.accept-encoding" title="Accept-Encoding">Section 6.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>):
    887887      </p>
    888888      <div id="rfc.figure.u.5"></div>
     
    918918         <p> <b>Note:</b> Content codings are a property of the representation, so therefore an entity-tag of an encoded representation has to be distinct
    919919            from an unencoded representation to prevent conflicts during cache updates and range requests. In contrast, transfer codings
    920             (<a href="p1-messaging.html#transfer.codings" title="Transfer Codings">Section 4</a> of <a href="#Part1" id="rfc.xref.Part1.4"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>) apply only during message transfer and do not require distinct entity-tags.
     920            (<a href="p1-messaging.html#transfer.codings" title="Transfer Codings">Section 4</a> of <a href="#Part1" id="rfc.xref.Part1.4"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>) apply only during message transfer and do not require distinct entity-tags.
    921921         </p>
    922922      </div>
     
    10521052      <p id="rfc.section.3.3.p.6">The purpose of this feature is to allow efficient updates of cached information with a minimum amount of transaction overhead. </p>
    10531053      <ul class="empty">
    1054          <li> <b>Note:</b> The <a href="p5-range.html#range.retrieval.requests" class="smpl">Range</a> header field modifies the meaning of If-Modified-Since; see <a href="p5-range.html#header.range" title="Range">Section 5.4</a> of <a href="#Part5" id="rfc.xref.Part5.1"><cite title="HTTP/1.1, part 5: Range Requests">[Part5]</cite></a> for full details.
     1054         <li> <b>Note:</b> The <a href="p5-range.html#range.retrieval.requests" class="smpl">Range</a> header field modifies the meaning of If-Modified-Since; see <a href="p5-range.html#header.range" title="Range">Section 5.4</a> of <a href="#Part5" id="rfc.xref.Part5.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Range Requests">[Part5]</cite></a> for full details.
    10551055         </li>
    10561056         <li> <b>Note:</b> If-Modified-Since times are interpreted by the server, whose clock might not be synchronized with the client.
     
    10821082      </p>
    10831083      <h2 id="rfc.section.3.5"><a href="#rfc.section.3.5">3.5</a>&nbsp;<a id="header.if-range" href="#header.if-range">If-Range</a></h2>
    1084       <p id="rfc.section.3.5.p.1">The "If-Range" header field provides a special conditional request mechanism that is similar to <a href="#header.if-match" class="smpl">If-Match</a> and <a href="#header.if-unmodified-since" class="smpl">If-Unmodified-Since</a> but specific to HTTP range requests. If-Range is defined in <a href="p5-range.html#header.if-range" title="If-Range">Section 5.3</a> of <a href="#Part5" id="rfc.xref.Part5.2"><cite title="HTTP/1.1, part 5: Range Requests">[Part5]</cite></a>.
     1084      <p id="rfc.section.3.5.p.1">The "If-Range" header field provides a special conditional request mechanism that is similar to <a href="#header.if-match" class="smpl">If-Match</a> and <a href="#header.if-unmodified-since" class="smpl">If-Unmodified-Since</a> but specific to HTTP range requests. If-Range is defined in <a href="p5-range.html#header.if-range" title="If-Range">Section 5.3</a> of <a href="#Part5" id="rfc.xref.Part5.2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Range Requests">[Part5]</cite></a>.
    10851085      </p>
    10861086      <h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a>&nbsp;<a id="status.code.definitions" href="#status.code.definitions">Status Code Definitions</a></h1>
     
    10931093         as if it were the payload of a 200 response. The 304 response <em class="bcp14">MUST NOT</em> contain a message-body, and thus is always terminated by the first empty line after the header fields.
    10941094      </p>
    1095       <p id="rfc.section.4.1.p.2">A 304 response <em class="bcp14">MUST</em> include a <a href="p2-semantics.html#header.date" class="smpl">Date</a> header field (<a href="p2-semantics.html#header.date" title="Date">Section 8.2.1</a> of <a href="#Part2" id="rfc.xref.Part2.4"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>) unless the origin server does not have a clock that can provide a reasonable approximation of the current time. If a <a href="p2-semantics.html#status.200" class="smpl">200
     1095      <p id="rfc.section.4.1.p.2">A 304 response <em class="bcp14">MUST</em> include a <a href="p2-semantics.html#header.date" class="smpl">Date</a> header field (<a href="p2-semantics.html#header.date" title="Date">Section 8.2.1</a> of <a href="#Part2" id="rfc.xref.Part2.4"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>) unless the origin server does not have a clock that can provide a reasonable approximation of the current time. If a <a href="p2-semantics.html#status.200" class="smpl">200
    10961096            (OK)</a> response to the same request would have included any of the header fields <a href="p6-cache.html#header.cache-control" class="smpl">Cache-Control</a>, <a href="p2-semantics.html#header.content-location" class="smpl">Content-Location</a>, <a href="#header.etag" class="smpl">ETag</a>, <a href="p6-cache.html#header.expires" class="smpl">Expires</a>, or <a href="p2-semantics.html#header.vary" class="smpl">Vary</a>, then those same header fields <em class="bcp14">MUST</em> be sent in a 304 response.
    10971097      </p>
     
    12521252      <p id="rfc.section.6.2.p.2">The change controller is: "IETF (iesg@ietf.org) - Internet Engineering Task Force".</p>
    12531253      <h1 id="rfc.section.7"><a href="#rfc.section.7">7.</a>&nbsp;<a id="security.considerations" href="#security.considerations">Security Considerations</a></h1>
    1254       <p id="rfc.section.7.p.1">No additional security considerations have been identified beyond those applicable to HTTP in general <a href="#Part1" id="rfc.xref.Part1.5"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>.
     1254      <p id="rfc.section.7.p.1">No additional security considerations have been identified beyond those applicable to HTTP in general <a href="#Part1" id="rfc.xref.Part1.5"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>.
    12551255      </p>
    12561256      <p id="rfc.section.7.p.2">The validators defined by this specification are not intended to ensure the validity of a representation, guard against malicious
     
    12601260      </p>
    12611261      <h1 id="rfc.section.8"><a href="#rfc.section.8">8.</a>&nbsp;<a id="acks" href="#acks">Acknowledgments</a></h1>
    1262       <p id="rfc.section.8.p.1">See <a href="p1-messaging.html#acks" title="Acknowledgments">Section 9</a> of <a href="#Part1" id="rfc.xref.Part1.6"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>.
     1262      <p id="rfc.section.8.p.1">See <a href="p1-messaging.html#acks" title="Acknowledgments">Section 9</a> of <a href="#Part1" id="rfc.xref.Part1.6"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>.
    12631263      </p>
    12641264      <h1 id="rfc.references"><a id="rfc.section.9" href="#rfc.section.9">9.</a> References
     
    12691269         <tr>
    12701270            <td class="reference"><b id="Part1">[Part1]</b></td>
    1271             <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-p1-messaging-latest">HTTP/1.1, part 1: Message Routing and Syntax"</a>”, Internet-Draft&nbsp;draft-ietf-httpbis-p1-messaging-latest (work in progress), September&nbsp;2012.
     1271            <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-p1-messaging-latest">Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing</a>”, Internet-Draft&nbsp;draft-ietf-httpbis-p1-messaging-latest (work in progress), September&nbsp;2012.
    12721272            </td>
    12731273         </tr>
    12741274         <tr>
    12751275            <td class="reference"><b id="Part2">[Part2]</b></td>
    1276             <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.
     1276            <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.
    12771277            </td>
    12781278         </tr>
    12791279         <tr>
    12801280            <td class="reference"><b id="Part5">[Part5]</b></td>
    1281             <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.
     1281            <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.
    12821282            </td>
    12831283         </tr>
    12841284         <tr>
    12851285            <td class="reference"><b id="Part6">[Part6]</b></td>
    1286             <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.
     1286            <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.
    12871287            </td>
    12881288         </tr>
     
    13411341         character).
    13421342      </p>
    1343       <p id="rfc.section.B.p.2">The rules below are defined in <a href="#Part1" id="rfc.xref.Part1.7"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>:
    1344       </p>
    1345       <div id="rfc.figure.u.16"></div><pre class="inline">  <a href="#imported.abnf" class="smpl">OWS</a>           = &lt;OWS, defined in <a href="#Part1" id="rfc.xref.Part1.8"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>, <a href="p1-messaging.html#whitespace" title="Whitespace">Section 3.2.1</a>&gt;
    1346   <a href="#imported.abnf" class="smpl">obs-text</a>      = &lt;obs-text, defined in <a href="#Part1" id="rfc.xref.Part1.9"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>, <a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.4</a>&gt;
     1343      <p id="rfc.section.B.p.2">The rules below are defined in <a href="#Part1" id="rfc.xref.Part1.7"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>:
     1344      </p>
     1345      <div id="rfc.figure.u.16"></div><pre class="inline">  <a href="#imported.abnf" class="smpl">OWS</a>           = &lt;OWS, defined in <a href="#Part1" id="rfc.xref.Part1.8"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#whitespace" title="Whitespace">Section 3.2.1</a>&gt;
     1346  <a href="#imported.abnf" class="smpl">obs-text</a>      = &lt;obs-text, defined in <a href="#Part1" id="rfc.xref.Part1.9"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.4</a>&gt;
    13471347</pre><p id="rfc.section.B.p.4">The rules below are defined in other parts:</p>
    1348       <div id="rfc.figure.u.17"></div><pre class="inline">  <a href="#imported.abnf" class="smpl">HTTP-date</a>     = &lt;HTTP-date, defined in <a href="#Part2" id="rfc.xref.Part2.5"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>, <a href="p2-semantics.html#http.date" title="Date/Time Formats">Section 9.1</a>&gt;
     1348      <div id="rfc.figure.u.17"></div><pre class="inline">  <a href="#imported.abnf" class="smpl">HTTP-date</a>     = &lt;HTTP-date, defined in <a href="#Part2" id="rfc.xref.Part2.5"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>, <a href="p2-semantics.html#http.date" title="Date/Time Formats">Section 9.1</a>&gt;
    13491349</pre><h1 id="rfc.section.C"><a href="#rfc.section.C">C.</a>&nbsp;<a id="collected.abnf" href="#collected.abnf">Collected ABNF</a></h1>
    13501350      <div id="rfc.figure.u.18"></div> <pre class="inline"><a href="#header.etag" class="smpl">ETag</a> = entity-tag
  • draft-ietf-httpbis/latest/p4-conditional.xml

    r1860 r1864  
    5353<front>
    5454
    55   <title abbrev="HTTP/1.1, Part 4">HTTP/1.1, part 4: Conditional Requests</title>
     55  <title abbrev="HTTP/1.1 Conditional Requests">Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests</title>
    5656
    5757  <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor">
     
    12261226<reference anchor="Part1">
    12271227  <front>
    1228     <title>HTTP/1.1, part 1: Message Routing and Syntax"</title>
     1228    <title>Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing</title>
    12291229    <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor">
    12301230      <organization abbrev="Adobe">Adobe Systems Incorporated</organization>
     
    12471247<reference anchor="Part2">
    12481248  <front>
    1249     <title>HTTP/1.1, part 2: Semantics and Payloads</title>
     1249    <title>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</title>
    12501250    <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor">
    12511251      <organization abbrev="Adobe">Adobe Systems Incorporated</organization>
     
    12781278<reference anchor="Part5">
    12791279  <front>
    1280     <title>HTTP/1.1, part 5: Range Requests</title>
     1280    <title>Hypertext Transfer Protocol (HTTP/1.1): Range Requests</title>
    12811281    <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor">
    12821282      <organization abbrev="Adobe">Adobe Systems Incorporated</organization>
     
    13021302<reference anchor="Part6">
    13031303  <front>
    1304     <title>HTTP/1.1, part 6: Caching</title>
     1304    <title>Hypertext Transfer Protocol (HTTP/1.1): Caching</title>
    13051305    <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor">
    13061306      <organization abbrev="Adobe">Adobe Systems Incorporated</organization>
  • draft-ietf-httpbis/latest/p5-range.html

    r1862 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 5: Range Requests</title><script>
     6      <title>Hypertext Transfer Protocol (HTTP/1.1): Range Requests</title><script>
    77var buttonsAdded = false;
    88
     
    443443  }
    444444  @top-center {
    445        content: "HTTP/1.1, Part 5";
     445       content: "HTTP/1.1 Range Requests";
    446446  }
    447447  @bottom-left {
     
    532532         </tbody>
    533533      </table>
    534       <p class="title">HTTP/1.1, part 5: Range Requests<br><span class="filename">draft-ietf-httpbis-p5-range-latest</span></p>
     534      <p class="title">Hypertext Transfer Protocol (HTTP/1.1): Range Requests<br><span class="filename">draft-ietf-httpbis-p5-range-latest</span></p>
    535535      <h1 id="rfc.abstract"><a href="#rfc.abstract">Abstract</a></h1>
    536536      <p>The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information
     
    650650      <p id="rfc.section.1.1.p.2">This specification targets conformance criteria according to the role of a participant in HTTP communication. Hence, HTTP
    651651         requirements are placed on senders, recipients, clients, servers, user agents, intermediaries, origin servers, proxies, gateways,
    652          or caches, depending on what behavior is being constrained by the requirement. See <a href="p1-messaging.html#architecture" title="Architecture">Section 2</a> of <a href="#Part1" id="rfc.xref.Part1.1"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a> for definitions of these terms.
     652         or caches, depending on what behavior is being constrained by the requirement. See <a href="p1-messaging.html#architecture" title="Architecture">Section 2</a> of <a href="#Part1" id="rfc.xref.Part1.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a> for definitions of these terms.
    653653      </p>
    654654      <p id="rfc.section.1.1.p.3">The verb "generate" is used instead of "send" where a requirement differentiates between creating a protocol element and merely
     
    668668      </p>
    669669      <h2 id="rfc.section.1.2"><a href="#rfc.section.1.2">1.2</a>&nbsp;<a id="notation" href="#notation">Syntax Notation</a></h2>
    670       <p id="rfc.section.1.2.p.1">This specification uses the Augmented Backus-Naur Form (ABNF) notation of <a href="#RFC5234" id="rfc.xref.RFC5234.1"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a> with the list rule extension defined in <a href="p1-messaging.html#notation" title="Syntax Notation">Section 1.2</a> of <a href="#Part1" id="rfc.xref.Part1.2"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>. <a href="#imported.abnf" title="Imported ABNF">Appendix&nbsp;C</a> describes rules imported from other documents. <a href="#collected.abnf" title="Collected ABNF">Appendix&nbsp;D</a> shows the collected ABNF with the list rule expanded.
     670      <p id="rfc.section.1.2.p.1">This specification uses the Augmented Backus-Naur Form (ABNF) notation of <a href="#RFC5234" id="rfc.xref.RFC5234.1"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a> with the list rule extension defined in <a href="p1-messaging.html#notation" title="Syntax Notation">Section 1.2</a> of <a href="#Part1" id="rfc.xref.Part1.2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>. <a href="#imported.abnf" title="Imported ABNF">Appendix&nbsp;C</a> describes rules imported from other documents. <a href="#collected.abnf" title="Collected ABNF">Appendix&nbsp;D</a> shows the collected ABNF with the list rule expanded.
    671671      </p>
    672672      <h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a>&nbsp;<a id="range.units" href="#range.units">Range Units</a></h1>
     
    712712      <p id="rfc.section.3.1.p.3">If a 206 is sent in response to a request with an <a href="#header.if-range" class="smpl">If-Range</a> header field, it <em class="bcp14">SHOULD NOT</em> include other representation header fields. Otherwise, the response <em class="bcp14">MUST</em> include all of the representation header fields that would have been returned with a <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> response to the same request.
    713713      </p>
    714       <p id="rfc.section.3.1.p.4">Caches <em class="bcp14">MAY</em> use a heuristic (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 4.1.2</a> of <a href="#Part6" id="rfc.xref.Part6.1"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) to determine freshness for 206 responses.
     714      <p id="rfc.section.3.1.p.4">Caches <em class="bcp14">MAY</em> use a heuristic (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 4.1.2</a> of <a href="#Part6" id="rfc.xref.Part6.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>) to determine freshness for 206 responses.
    715715      </p>
    716716      <div id="rfc.iref.4"></div>
     
    759759         one or more Range specifications. After several such transfers, a client might have received several ranges of the same representation.
    760760         These ranges can only be safely combined if they all have in common the same strong validator, where "strong validator" is
    761          defined to be either an entity-tag that is not marked as weak (<a href="p4-conditional.html#header.etag" title="ETag">Section 2.3</a> of <a href="#Part4" id="rfc.xref.Part4.1"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>) or, if no entity-tag is provided, a <a href="p4-conditional.html#header.last-modified" class="smpl">Last-Modified</a> value that is strong in the sense defined by <a href="p4-conditional.html#lastmod.comparison" title="Comparison">Section 2.2.2</a> of <a href="#Part4" id="rfc.xref.Part4.2"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>.
     761         defined to be either an entity-tag that is not marked as weak (<a href="p4-conditional.html#header.etag" title="ETag">Section 2.3</a> of <a href="#Part4" id="rfc.xref.Part4.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a>) or, if no entity-tag is provided, a <a href="p4-conditional.html#header.last-modified" class="smpl">Last-Modified</a> value that is strong in the sense defined by <a href="p4-conditional.html#lastmod.comparison" title="Comparison">Section 2.2.2</a> of <a href="#Part4" id="rfc.xref.Part4.2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a>.
    762762      </p>
    763763      <p id="rfc.section.4.2.p.2">When a client receives an incomplete <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> or <a href="#status.206" class="smpl">206 (Partial Content)</a> response and already has one or more stored responses for the same method and effective request URI, all of the stored responses
     
    861861      <div id="rfc.figure.u.12"></div><pre class="inline"><span id="rfc.iref.g.10"></span>  <a href="#header.if-range" class="smpl">If-Range</a> = <a href="#imported.abnf" class="smpl">entity-tag</a> / <a href="#imported.abnf" class="smpl">HTTP-date</a>
    862862</pre><p id="rfc.section.5.3.p.4">Clients <em class="bcp14">MUST NOT</em> use an entity-tag marked as weak in an If-Range field value and <em class="bcp14">MUST NOT</em> use a <a href="p4-conditional.html#header.last-modified" class="smpl">Last-Modified</a> date in an If-Range field value unless it has no entity-tag for the representation and the Last-Modified date it does have
    863          for the representation is strong in the sense defined by <a href="p4-conditional.html#lastmod.comparison" title="Comparison">Section 2.2.2</a> of <a href="#Part4" id="rfc.xref.Part4.3"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>.
     863         for the representation is strong in the sense defined by <a href="p4-conditional.html#lastmod.comparison" title="Comparison">Section 2.2.2</a> of <a href="#Part4" id="rfc.xref.Part4.3"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a>.
    864864      </p>
    865865      <p id="rfc.section.5.3.p.5">A server that evaluates a conditional range request that is applicable to one of its representations <em class="bcp14">MUST</em> evaluate the condition as false if the entity-tag used as a validator is marked as weak or, when an HTTP-date is used as the
    866          validator, if the date value is not strong in the sense defined by <a href="p4-conditional.html#lastmod.comparison" title="Comparison">Section 2.2.2</a> of <a href="#Part4" id="rfc.xref.Part4.4"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>. (A server can distinguish between a valid HTTP-date and any form of entity-tag by examining the first two characters.)
     866         validator, if the date value is not strong in the sense defined by <a href="p4-conditional.html#lastmod.comparison" title="Comparison">Section 2.2.2</a> of <a href="#Part4" id="rfc.xref.Part4.4"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a>. (A server can distinguish between a valid HTTP-date and any form of entity-tag by examining the first two characters.)
    867867      </p>
    868868      <p id="rfc.section.5.3.p.6">The If-Range header field <em class="bcp14">SHOULD</em> only be sent by clients together with a Range header field. The If-Range header field <em class="bcp14">MUST</em> be ignored if it is received in a request that does not include a Range header field. The If-Range header field <em class="bcp14">MUST</em> be ignored by a server that does not support the sub-range operation.
     
    10741074      </p>
    10751075      <h1 id="rfc.section.8"><a href="#rfc.section.8">8.</a>&nbsp;<a id="acks" href="#acks">Acknowledgments</a></h1>
    1076       <p id="rfc.section.8.p.1">See <a href="p1-messaging.html#acks" title="Acknowledgments">Section 9</a> of <a href="#Part1" id="rfc.xref.Part1.3"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>.
     1076      <p id="rfc.section.8.p.1">See <a href="p1-messaging.html#acks" title="Acknowledgments">Section 9</a> of <a href="#Part1" id="rfc.xref.Part1.3"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>.
    10771077      </p>
    10781078      <h1 id="rfc.references"><a id="rfc.section.9" href="#rfc.section.9">9.</a> References
     
    10831083         <tr>
    10841084            <td class="reference"><b id="Part1">[Part1]</b></td>
    1085             <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-p1-messaging-latest">HTTP/1.1, part 1: Message Routing and Syntax"</a>”, Internet-Draft&nbsp;draft-ietf-httpbis-p1-messaging-latest (work in progress), September&nbsp;2012.
     1085            <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-p1-messaging-latest">Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing</a>”, Internet-Draft&nbsp;draft-ietf-httpbis-p1-messaging-latest (work in progress), September&nbsp;2012.
    10861086            </td>
    10871087         </tr>
    10881088         <tr>
    10891089            <td class="reference"><b id="Part2">[Part2]</b></td>
    1090             <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.
     1090            <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.
    10911091            </td>
    10921092         </tr>
    10931093         <tr>
    10941094            <td class="reference"><b id="Part4">[Part4]</b></td>
    1095             <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.
     1095            <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.
    10961096            </td>
    10971097         </tr>
    10981098         <tr>
    10991099            <td class="reference"><b id="Part6">[Part6]</b></td>
    1100             <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.
     1100            <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.
    11011101            </td>
    11021102         </tr>
     
    12651265      <p id="rfc.section.C.p.2">Note that all rules derived from <a href="#imported.abnf" class="smpl">token</a> are to be compared case-insensitively, like <a href="#range.units" class="smpl">range-unit</a> and <a href="#header.accept-ranges" class="smpl">acceptable-ranges</a>.
    12661266      </p>
    1267       <p id="rfc.section.C.p.3">The rules below are defined in <a href="#Part1" id="rfc.xref.Part1.4"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>:
    1268       </p>
    1269       <div id="rfc.figure.u.24"></div><pre class="inline">  <a href="#imported.abnf" class="smpl">OWS</a>        = &lt;OWS, defined in <a href="#Part1" id="rfc.xref.Part1.5"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>, <a href="p1-messaging.html#whitespace" title="Whitespace">Section 3.2.1</a>&gt;
    1270   <a href="#imported.abnf" class="smpl">token</a>      = &lt;token, defined in <a href="#Part1" id="rfc.xref.Part1.6"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>, <a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.4</a>&gt;
     1267      <p id="rfc.section.C.p.3">The rules below are defined in <a href="#Part1" id="rfc.xref.Part1.4"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>:
     1268      </p>
     1269      <div id="rfc.figure.u.24"></div><pre class="inline">  <a href="#imported.abnf" class="smpl">OWS</a>        = &lt;OWS, defined in <a href="#Part1" id="rfc.xref.Part1.5"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#whitespace" title="Whitespace">Section 3.2.1</a>&gt;
     1270  <a href="#imported.abnf" class="smpl">token</a>      = &lt;token, defined in <a href="#Part1" id="rfc.xref.Part1.6"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.4</a>&gt;
    12711271</pre><p id="rfc.section.C.p.5">The rules below are defined in other parts:</p>
    1272       <div id="rfc.figure.u.25"></div><pre class="inline">  <a href="#imported.abnf" class="smpl">HTTP-date</a>  = &lt;HTTP-date, defined in <a href="#Part2" id="rfc.xref.Part2.1"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>, <a href="p2-semantics.html#http.date" title="Date/Time Formats">Section 9.1</a>&gt;
    1273   <a href="#imported.abnf" class="smpl">entity-tag</a> = &lt;entity-tag, defined in <a href="#Part4" id="rfc.xref.Part4.5"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>, <a href="p4-conditional.html#header.etag" title="ETag">Section 2.3</a>&gt;
     1272      <div id="rfc.figure.u.25"></div><pre class="inline">  <a href="#imported.abnf" class="smpl">HTTP-date</a>  = &lt;HTTP-date, defined in <a href="#Part2" id="rfc.xref.Part2.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>, <a href="p2-semantics.html#http.date" title="Date/Time Formats">Section 9.1</a>&gt;
     1273  <a href="#imported.abnf" class="smpl">entity-tag</a> = &lt;entity-tag, defined in <a href="#Part4" id="rfc.xref.Part4.5"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a>, <a href="p4-conditional.html#header.etag" title="ETag">Section 2.3</a>&gt;
    12741274</pre><h1 id="rfc.section.D"><a href="#rfc.section.D">D.</a>&nbsp;<a id="collected.abnf" href="#collected.abnf">Collected ABNF</a></h1>
    12751275      <div id="rfc.figure.u.26"></div> <pre class="inline"><a href="#header.accept-ranges" class="smpl">Accept-Ranges</a> = acceptable-ranges
  • draft-ietf-httpbis/latest/p5-range.xml

    r1862 r1864  
    4949<front>
    5050
    51   <title abbrev="HTTP/1.1, Part 5">HTTP/1.1, part 5: Range Requests</title>
     51  <title abbrev="HTTP/1.1 Range Requests">Hypertext Transfer Protocol (HTTP/1.1): Range Requests</title>
    5252
    5353  <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor">
     
    964964<reference anchor="Part1">
    965965  <front>
    966     <title>HTTP/1.1, part 1: Message Routing and Syntax"</title>
     966    <title>Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing</title>
    967967    <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor">
    968968      <organization abbrev="Adobe">Adobe Systems Incorporated</organization>
     
    987987<reference anchor="Part2">
    988988  <front>
    989     <title>HTTP/1.1, part 2: Semantics and Payloads</title>
     989    <title>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</title>
    990990    <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor">
    991991      <organization abbrev="Adobe">Adobe Systems Incorporated</organization>
     
    10151015<reference anchor="Part4">
    10161016  <front>
    1017     <title>HTTP/1.1, part 4: Conditional Requests</title>
     1017    <title>Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests</title>
    10181018    <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor">
    10191019      <organization abbrev="Adobe">Adobe Systems Incorporated</organization>
     
    10441044<reference anchor="Part6">
    10451045  <front>
    1046     <title>HTTP/1.1, part 6: Caching</title>
     1046    <title>Hypertext Transfer Protocol (HTTP/1.1): Caching</title>
    10471047    <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor">
    10481048      <organization abbrev="Adobe">Adobe Systems Incorporated</organization>
  • draft-ietf-httpbis/latest/p6-cache.html

    r1862 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 6: Caching</title><script>
     6      <title>Hypertext Transfer Protocol (HTTP/1.1): Caching</title><script>
    77var buttonsAdded = false;
    88
     
    446446  }
    447447  @top-center {
    448        content: "HTTP/1.1, Part 6";
     448       content: "HTTP/1.1 Caching";
    449449  }
    450450  @bottom-left {
     
    546546         </tbody>
    547547      </table>
    548       <p class="title">HTTP/1.1, part 6: Caching<br><span class="filename">draft-ietf-httpbis-p6-cache-latest</span></p>
     548      <p class="title">Hypertext Transfer Protocol (HTTP/1.1): Caching<br><span class="filename">draft-ietf-httpbis-p6-cache-latest</span></p>
    549549      <h1 id="rfc.abstract"><a href="#rfc.abstract">Abstract</a></h1>
    550550      <p>The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information
     
    770770      </p>
    771771      <ul class="empty">
    772          <li>A protocol element (e.g., an entity-tag or a <a href="p4-conditional.html#header.last-modified" class="smpl">Last-Modified</a> time) that is used to find out whether a stored response is an equivalent copy of a representation. See <a href="p4-conditional.html#weak.and.strong.validators" title="Weak versus Strong">Section 2.1</a> of <a href="#Part4" id="rfc.xref.Part4.1"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>.
     772         <li>A protocol element (e.g., an entity-tag or a <a href="p4-conditional.html#header.last-modified" class="smpl">Last-Modified</a> time) that is used to find out whether a stored response is an equivalent copy of a representation. See <a href="p4-conditional.html#weak.and.strong.validators" title="Weak versus Strong">Section 2.1</a> of <a href="#Part4" id="rfc.xref.Part4.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a>.
    773773         </li>
    774774      </ul>
     
    777777      <ul class="empty">
    778778         <li>A validator that is defined by the origin server such that its current value will change if the representation body changes;
    779             i.e., an entity-tag that is not marked as weak (<a href="p4-conditional.html#header.etag" title="ETag">Section 2.3</a> of <a href="#Part4" id="rfc.xref.Part4.2"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>) or, if no entity-tag is provided, a <a href="p4-conditional.html#header.last-modified" class="smpl">Last-Modified</a> value that is strong in the sense defined by <a href="p4-conditional.html#lastmod.comparison" title="Comparison">Section 2.2.2</a> of <a href="#Part4" id="rfc.xref.Part4.3"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>.
     779            i.e., an entity-tag that is not marked as weak (<a href="p4-conditional.html#header.etag" title="ETag">Section 2.3</a> of <a href="#Part4" id="rfc.xref.Part4.2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a>) or, if no entity-tag is provided, a <a href="p4-conditional.html#header.last-modified" class="smpl">Last-Modified</a> value that is strong in the sense defined by <a href="p4-conditional.html#lastmod.comparison" title="Comparison">Section 2.2.2</a> of <a href="#Part4" id="rfc.xref.Part4.3"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a>.
    780780         </li>
    781781      </ul>
     
    786786      <p id="rfc.section.1.3.p.2">This specification targets conformance criteria according to the role of a participant in HTTP communication. Hence, HTTP
    787787         requirements are placed on senders, recipients, clients, servers, user agents, intermediaries, origin servers, proxies, gateways,
    788          or caches, depending on what behavior is being constrained by the requirement. See <a href="p1-messaging.html#architecture" title="Architecture">Section 2</a> of <a href="#Part1" id="rfc.xref.Part1.1"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a> for definitions of these terms.
     788         or caches, depending on what behavior is being constrained by the requirement. See <a href="p1-messaging.html#architecture" title="Architecture">Section 2</a> of <a href="#Part1" id="rfc.xref.Part1.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a> for definitions of these terms.
    789789      </p>
    790790      <p id="rfc.section.1.3.p.3">The verb "generate" is used instead of "send" where a requirement differentiates between creating a protocol element and merely
     
    804804      </p>
    805805      <h2 id="rfc.section.1.4"><a href="#rfc.section.1.4">1.4</a>&nbsp;<a id="notation" href="#notation">Syntax Notation</a></h2>
    806       <p id="rfc.section.1.4.p.1">This specification uses the Augmented Backus-Naur Form (ABNF) notation of <a href="#RFC5234" id="rfc.xref.RFC5234.1"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a> with the list rule extension defined in <a href="p1-messaging.html#notation" title="Syntax Notation">Section 1.2</a> of <a href="#Part1" id="rfc.xref.Part1.2"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>. <a href="#imported.abnf" title="Imported ABNF">Appendix&nbsp;B</a> describes rules imported from other documents. <a href="#collected.abnf" title="Collected ABNF">Appendix&nbsp;C</a> shows the collected ABNF with the list rule expanded.
     806      <p id="rfc.section.1.4.p.1">This specification uses the Augmented Backus-Naur Form (ABNF) notation of <a href="#RFC5234" id="rfc.xref.RFC5234.1"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a> with the list rule extension defined in <a href="p1-messaging.html#notation" title="Syntax Notation">Section 1.2</a> of <a href="#Part1" id="rfc.xref.Part1.2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>. <a href="#imported.abnf" title="Imported ABNF">Appendix&nbsp;B</a> describes rules imported from other documents. <a href="#collected.abnf" title="Collected ABNF">Appendix&nbsp;C</a> shows the collected ABNF with the list rule expanded.
    807807      </p>
    808808      <h3 id="rfc.section.1.4.1"><a href="#rfc.section.1.4.1">1.4.1</a>&nbsp;<a id="delta-seconds" href="#delta-seconds">Delta Seconds</a></h3>
     
    815815      <div id="rfc.iref.c.5"></div>
    816816      <h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a>&nbsp;<a id="caching.overview" href="#caching.overview">Overview of Cache Operation</a></h1>
    817       <p id="rfc.section.2.p.1">Proper cache operation preserves the semantics of HTTP transfers (<a href="#Part2" id="rfc.xref.Part2.1"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>) while eliminating the transfer of information already held in the cache. Although caching is an entirely <em class="bcp14">OPTIONAL</em> feature of HTTP, we assume that reusing the cached response is desirable and that such reuse is the default behavior when
     817      <p id="rfc.section.2.p.1">Proper cache operation preserves the semantics of HTTP transfers (<a href="#Part2" id="rfc.xref.Part2.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>) while eliminating the transfer of information already held in the cache. Although caching is an entirely <em class="bcp14">OPTIONAL</em> feature of HTTP, we assume that reusing the cached response is desirable and that such reuse is the default behavior when
    818818         no requirement or locally-desired configuration prevents it. Therefore, HTTP cache requirements are focused on preventing
    819819         a cache from either storing a non-reusable response or reusing a stored response inappropriately.
     
    842842         <li>the "private" cache response directive (see <a href="#cache-response-directive.private" title="private">Section&nbsp;7.2.2.2</a>) does not appear in the response, if the cache is shared, and
    843843         </li>
    844          <li>the <a href="p7-auth.html#header.authorization" class="smpl">Authorization</a> header field (see <a href="p7-auth.html#header.authorization" title="Authorization">Section 4.1</a> of <a href="#Part7" id="rfc.xref.Part7.1"><cite title="HTTP/1.1, part 7: Authentication">[Part7]</cite></a>) does not appear in the request, if the cache is shared, unless the response explicitly allows it (see <a href="#caching.authenticated.responses" title="Storing Responses to Authenticated Requests">Section&nbsp;3.2</a>), and
     844         <li>the <a href="p7-auth.html#header.authorization" class="smpl">Authorization</a> header field (see <a href="p7-auth.html#header.authorization" title="Authorization">Section 4.1</a> of <a href="#Part7" id="rfc.xref.Part7.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Authentication">[Part7]</cite></a>) does not appear in the request, if the cache is shared, unless the response explicitly allows it (see <a href="#caching.authenticated.responses" title="Storing Responses to Authenticated Requests">Section&nbsp;3.2</a>), and
    845845         </li>
    846846         <li>the response either:
     
    867867      </p>
    868868      <h2 id="rfc.section.3.1"><a href="#rfc.section.3.1">3.1</a>&nbsp;<a id="incomplete.responses" href="#incomplete.responses">Storing Incomplete Responses</a></h2>
    869       <p id="rfc.section.3.1.p.1">A response message is considered complete when all of the octets indicated by the message framing (<a href="#Part1" id="rfc.xref.Part1.3"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>) are received prior to the connection being closed. If the request is GET, the response status is <a href="p2-semantics.html#status.200" class="smpl">200
     869      <p id="rfc.section.3.1.p.1">A response message is considered complete when all of the octets indicated by the message framing (<a href="#Part1" id="rfc.xref.Part1.3"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>) are received prior to the connection being closed. If the request is GET, the response status is <a href="p2-semantics.html#status.200" class="smpl">200
    870870            (OK)</a>, and the entire response header block has been received, a cache <em class="bcp14">MAY</em> store an incomplete response message body if the cache entry is recorded as incomplete. Likewise, a <a href="p5-range.html#status.206" class="smpl">206 (Partial Content)</a> response <em class="bcp14">MAY</em> be stored as if it were an incomplete <a href="p2-semantics.html#status.200" class="smpl">200
    871871            (OK)</a> cache entry. However, a cache <em class="bcp14">MUST NOT</em> store incomplete or partial content responses if it does not support the <a href="p5-range.html#range.retrieval.requests" class="smpl">Range</a> and <a href="p5-range.html#header.content-range" class="smpl">Content-Range</a> header fields or if it does not understand the range units used in those fields.
    872872      </p>
    873       <p id="rfc.section.3.1.p.2">A cache <em class="bcp14">MAY</em> complete a stored incomplete response by making a subsequent range request (<a href="#Part5" id="rfc.xref.Part5.1"><cite title="HTTP/1.1, part 5: Range Requests">[Part5]</cite></a>) and combining the successful response with the stored entry, as defined in <a href="#combining.responses" title="Combining Partial Content">Section&nbsp;4.4</a>. A cache <em class="bcp14">MUST NOT</em> use an incomplete response to answer requests unless the response has been made complete or the request is partial and specifies
     873      <p id="rfc.section.3.1.p.2">A cache <em class="bcp14">MAY</em> complete a stored incomplete response by making a subsequent range request (<a href="#Part5" id="rfc.xref.Part5.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Range Requests">[Part5]</cite></a>) and combining the successful response with the stored entry, as defined in <a href="#combining.responses" title="Combining Partial Content">Section&nbsp;4.4</a>. A cache <em class="bcp14">MUST NOT</em> use an incomplete response to answer requests unless the response has been made complete or the request is partial and specifies
    874874         a range that is wholly within the incomplete response. A cache <em class="bcp14">MUST NOT</em> send a partial response to a client without explicitly marking it as such using the <a href="p5-range.html#status.206" class="smpl">206 (Partial Content)</a> status code.
    875875      </p>
    876876      <h2 id="rfc.section.3.2"><a href="#rfc.section.3.2">3.2</a>&nbsp;<a id="caching.authenticated.responses" href="#caching.authenticated.responses">Storing Responses to Authenticated Requests</a></h2>
    877       <p id="rfc.section.3.2.p.1">A shared cache <em class="bcp14">MUST NOT</em> use a cached response to a request with an <a href="p7-auth.html#header.authorization" class="smpl">Authorization</a> header field (<a href="p7-auth.html#header.authorization" title="Authorization">Section 4.1</a> of <a href="#Part7" id="rfc.xref.Part7.2"><cite title="HTTP/1.1, part 7: Authentication">[Part7]</cite></a>) to satisfy any subsequent request unless a cache directive that allows such responses to be stored is present in the response.
     877      <p id="rfc.section.3.2.p.1">A shared cache <em class="bcp14">MUST NOT</em> use a cached response to a request with an <a href="p7-auth.html#header.authorization" class="smpl">Authorization</a> header field (<a href="p7-auth.html#header.authorization" title="Authorization">Section 4.1</a> of <a href="#Part7" id="rfc.xref.Part7.2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Authentication">[Part7]</cite></a>) to satisfy any subsequent request unless a cache directive that allows such responses to be stored is present in the response.
    878878      </p>
    879879      <p id="rfc.section.3.2.p.2">In this specification, the following <a href="#header.cache-control" class="smpl">Cache-Control</a> response directives (<a href="#cache-response-directive" title="Response Cache-Control Directives">Section&nbsp;7.2.2</a>) have such an effect: must-revalidate, public, s-maxage.
     
    887887      </p>
    888888      <ul>
    889          <li>The presented effective request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 5.5</a> of <a href="#Part1" id="rfc.xref.Part1.4"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>) and that of the stored response match, and
     889         <li>The presented effective request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 5.5</a> of <a href="#Part1" id="rfc.xref.Part1.4"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>) and that of the stored response match, and
    890890         </li>
    891891         <li>the request method associated with the stored response allows it to be used for the presented request, and</li>
     
    911911      <p id="rfc.section.4.p.3">When a stored response is used to satisfy a request without validation, a cache <em class="bcp14">MUST</em> include a single <a href="#header.age" class="smpl">Age</a> header field (<a href="#header.age" id="rfc.xref.header.age.1" title="Age">Section&nbsp;7.1</a>) in the response with a value equal to the stored response's current_age; see <a href="#age.calculations" title="Calculating Age">Section&nbsp;4.1.3</a>.
    912912      </p>
    913       <p id="rfc.section.4.p.4">A cache <em class="bcp14">MUST</em> write through requests with methods that are unsafe (<a href="p2-semantics.html#safe.methods" title="Safe Methods">Section 5.2.1</a> of <a href="#Part2" id="rfc.xref.Part2.2"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>) to the origin server; i.e., a cache is not allowed to generate a reply to such a request before having forwarded the request
     913      <p id="rfc.section.4.p.4">A cache <em class="bcp14">MUST</em> write through requests with methods that are unsafe (<a href="p2-semantics.html#safe.methods" title="Safe Methods">Section 5.2.1</a> of <a href="#Part2" id="rfc.xref.Part2.2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>) to the origin server; i.e., a cache is not allowed to generate a reply to such a request before having forwarded the request
    914914         and having received a corresponding response.
    915915      </p>
     
    965965      <h3 id="rfc.section.4.1.2"><a href="#rfc.section.4.1.2">4.1.2</a>&nbsp;<a id="heuristic.freshness" href="#heuristic.freshness">Calculating Heuristic Freshness</a></h3>
    966966      <p id="rfc.section.4.1.2.p.1">If no explicit expiration time is present in a stored response that has a status code whose definition allows heuristic freshness
    967          to be used (including the following in <a href="p2-semantics.html#status.codes" title="Response Status Codes">Section 7</a> of <a href="#Part2" id="rfc.xref.Part2.3"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>: <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a>, <a href="p2-semantics.html#status.203" class="smpl">203 (Non-Authoritative Information)</a>, <a href="p5-range.html#status.206" class="smpl">206 (Partial
     967         to be used (including the following in <a href="p2-semantics.html#status.codes" title="Response Status Codes">Section 7</a> of <a href="#Part2" id="rfc.xref.Part2.3"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>: <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a>, <a href="p2-semantics.html#status.203" class="smpl">203 (Non-Authoritative Information)</a>, <a href="p5-range.html#status.206" class="smpl">206 (Partial
    968968            Content)</a>, <a href="p2-semantics.html#status.300" class="smpl">300 (Multiple Choices)</a>, <a href="p2-semantics.html#status.301" class="smpl">301 (Moved
    969969            Permanently)</a> and <a href="p2-semantics.html#status.410" class="smpl">410 (Gone)</a>), a cache <em class="bcp14">MAY</em> calculate a heuristic expiration time. A cache <em class="bcp14">MUST NOT</em> use heuristics to determine freshness for responses with status codes that do not explicitly allow it.
     
    972972         present.
    973973      </p>
    974       <p id="rfc.section.4.1.2.p.3">Also, if the response has a <a href="p4-conditional.html#header.last-modified" class="smpl">Last-Modified</a> header field (<a href="p4-conditional.html#header.last-modified" title="Last-Modified">Section 2.2</a> of <a href="#Part4" id="rfc.xref.Part4.4"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>), caches are encouraged to use a heuristic expiration value that is no more than some fraction of the interval since that
     974      <p id="rfc.section.4.1.2.p.3">Also, if the response has a <a href="p4-conditional.html#header.last-modified" class="smpl">Last-Modified</a> header field (<a href="p4-conditional.html#header.last-modified" title="Last-Modified">Section 2.2</a> of <a href="#Part4" id="rfc.xref.Part4.4"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a>), caches are encouraged to use a heuristic expiration value that is no more than some fraction of the interval since that
    975975         time. A typical setting of this fraction might be 10%.
    976976      </p>
     
    998998      <ul class="empty">
    999999         <li>HTTP/1.1 requires origin servers to send a <a href="p2-semantics.html#header.date" class="smpl">Date</a> header field, if possible, with every response, giving the time at which the response was generated. The term "date_value"
    1000             denotes the value of the Date header field, in a form appropriate for arithmetic operations. See <a href="p2-semantics.html#header.date" title="Date">Section 8.2.1</a> of <a href="#Part2" id="rfc.xref.Part2.4"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a> for the definition of the Date header field, and for requirements regarding responses without it.
     1000            denotes the value of the Date header field, in a form appropriate for arithmetic operations. See <a href="p2-semantics.html#header.date" title="Date">Section 8.2.1</a> of <a href="#Part2" id="rfc.xref.Part2.4"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a> for the definition of the Date header field, and for requirements regarding responses without it.
    10011001         </li>
    10021002      </ul>
     
    10731073      <h2 id="rfc.section.4.2"><a href="#rfc.section.4.2">4.2</a>&nbsp;<a id="validation.model" href="#validation.model">Validation Model</a></h2>
    10741074      <p id="rfc.section.4.2.p.1">When a cache has one or more stored responses for a requested URI, but cannot serve any of them (e.g., because they are not
    1075          fresh, or one cannot be selected; see <a href="#caching.negotiated.responses" title="Using Negotiated Responses">Section&nbsp;4.3</a>), it can use the conditional request mechanism <a href="#Part4" id="rfc.xref.Part4.5"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a> in the forwarded request to give the origin server an opportunity to both select a valid stored response to be used, and to
     1075         fresh, or one cannot be selected; see <a href="#caching.negotiated.responses" title="Using Negotiated Responses">Section&nbsp;4.3</a>), it can use the conditional request mechanism <a href="#Part4" id="rfc.xref.Part4.5"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a> in the forwarded request to give the origin server an opportunity to both select a valid stored response to be used, and to
    10761076         update it. This process is known as "validating" or "revalidating" the stored response.
    10771077      </p>
     
    11211121      </ul>
    11221122      <h2 id="rfc.section.4.3"><a href="#rfc.section.4.3">4.3</a>&nbsp;<a id="caching.negotiated.responses" href="#caching.negotiated.responses">Using Negotiated Responses</a></h2>
    1123       <p id="rfc.section.4.3.p.1">When a cache receives a request that can be satisfied by a stored response that has a <a href="p2-semantics.html#header.vary" class="smpl">Vary</a> header field (<a href="p2-semantics.html#header.vary" title="Vary">Section 8.2.2</a> of <a href="#Part2" id="rfc.xref.Part2.5"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>), it <em class="bcp14">MUST NOT</em> use that response unless all of the selecting header fields nominated by the Vary header field match in both the original
     1123      <p id="rfc.section.4.3.p.1">When a cache receives a request that can be satisfied by a stored response that has a <a href="p2-semantics.html#header.vary" class="smpl">Vary</a> header field (<a href="p2-semantics.html#header.vary" title="Vary">Section 8.2.2</a> of <a href="#Part2" id="rfc.xref.Part2.5"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>), it <em class="bcp14">MUST NOT</em> use that response unless all of the selecting header fields nominated by the Vary header field match in both the original
    11241124         request (i.e., that associated with the stored response), and the presented request.
    11251125      </p>
     
    11291129      <ul>
    11301130         <li>adding or removing whitespace, where allowed in the header field's syntax</li>
    1131          <li>combining multiple header fields with the same field name (see <a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.5"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>)
     1131         <li>combining multiple header fields with the same field name (see <a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.5"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>)
    11321132         </li>
    11331133         <li>normalizing both header field values in a way that is known to have identical semantics, according to the header field's specification
     
    11491149      <h2 id="rfc.section.4.4"><a href="#rfc.section.4.4">4.4</a>&nbsp;<a id="combining.responses" href="#combining.responses">Combining Partial Content</a></h2>
    11501150      <p id="rfc.section.4.4.p.1">A response might transfer only a partial representation if the connection closed prematurely or if the request used one or
    1151          more Range specifiers (<a href="#Part5" id="rfc.xref.Part5.2"><cite title="HTTP/1.1, part 5: Range Requests">[Part5]</cite></a>). After several such transfers, a cache might have received several ranges of the same representation. A cache <em class="bcp14">MAY</em> combine these ranges into a single stored response, and reuse that response to satisfy later requests, if they all share the
    1152          same strong validator and the cache complies with the client requirements in <a href="p5-range.html#combining.byte.ranges" title="Combining Ranges">Section 4.2</a> of <a href="#Part5" id="rfc.xref.Part5.3"><cite title="HTTP/1.1, part 5: Range Requests">[Part5]</cite></a>.
     1151         more Range specifiers (<a href="#Part5" id="rfc.xref.Part5.2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Range Requests">[Part5]</cite></a>). After several such transfers, a cache might have received several ranges of the same representation. A cache <em class="bcp14">MAY</em> combine these ranges into a single stored response, and reuse that response to satisfy later requests, if they all share the
     1152         same strong validator and the cache complies with the client requirements in <a href="p5-range.html#combining.byte.ranges" title="Combining Ranges">Section 4.2</a> of <a href="#Part5" id="rfc.xref.Part5.3"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Range Requests">[Part5]</cite></a>.
    11531153      </p>
    11541154      <p id="rfc.section.4.4.p.2">When combining the new response with one or more stored responses, a cache <em class="bcp14">MUST</em>:
     
    11801180      </ul>
    11811181      <h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a>&nbsp;<a id="invalidation.after.updates.or.deletions" href="#invalidation.after.updates.or.deletions">Request Methods that Invalidate</a></h1>
    1182       <p id="rfc.section.6.p.1">Because unsafe request methods (<a href="p2-semantics.html#safe.methods" title="Safe Methods">Section 5.2.1</a> of <a href="#Part2" id="rfc.xref.Part2.6"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>) such as PUT, POST or DELETE have the potential for changing state on the origin server, intervening caches can use them
     1182      <p id="rfc.section.6.p.1">Because unsafe request methods (<a href="p2-semantics.html#safe.methods" title="Safe Methods">Section 5.2.1</a> of <a href="#Part2" id="rfc.xref.Part2.6"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>) such as PUT, POST or DELETE have the potential for changing state on the origin server, intervening caches can use them
    11831183         to keep their contents up-to-date.
    11841184      </p>
    1185       <p id="rfc.section.6.p.2">A cache <em class="bcp14">MUST</em> invalidate the effective Request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 5.5</a> of <a href="#Part1" id="rfc.xref.Part1.6"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>) as well as the URI(s) in the <a href="p2-semantics.html#header.location" class="smpl">Location</a> and <a href="p2-semantics.html#header.content-location" class="smpl">Content-Location</a> response header fields (if present) when a non-error response to a request with an unsafe method is received.
    1186       </p>
    1187       <p id="rfc.section.6.p.3">However, a cache <em class="bcp14">MUST NOT</em> invalidate a URI from a <a href="p2-semantics.html#header.location" class="smpl">Location</a> or <a href="p2-semantics.html#header.content-location" class="smpl">Content-Location</a> response header field if the host part of that URI differs from the host part in the effective request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 5.5</a> of <a href="#Part1" id="rfc.xref.Part1.7"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>). This helps prevent denial of service attacks.
    1188       </p>
    1189       <p id="rfc.section.6.p.4">A cache <em class="bcp14">MUST</em> invalidate the effective request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 5.5</a> of <a href="#Part1" id="rfc.xref.Part1.8"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>) when it receives a non-error response to a request with a method whose safety is unknown.
     1185      <p id="rfc.section.6.p.2">A cache <em class="bcp14">MUST</em> invalidate the effective Request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 5.5</a> of <a href="#Part1" id="rfc.xref.Part1.6"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>) as well as the URI(s) in the <a href="p2-semantics.html#header.location" class="smpl">Location</a> and <a href="p2-semantics.html#header.content-location" class="smpl">Content-Location</a> response header fields (if present) when a non-error response to a request with an unsafe method is received.
     1186      </p>
     1187      <p id="rfc.section.6.p.3">However, a cache <em class="bcp14">MUST NOT</em> invalidate a URI from a <a href="p2-semantics.html#header.location" class="smpl">Location</a> or <a href="p2-semantics.html#header.content-location" class="smpl">Content-Location</a> response header field if the host part of that URI differs from the host part in the effective request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 5.5</a> of <a href="#Part1" id="rfc.xref.Part1.7"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>). This helps prevent denial of service attacks.
     1188      </p>
     1189      <p id="rfc.section.6.p.4">A cache <em class="bcp14">MUST</em> invalidate the effective request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 5.5</a> of <a href="#Part1" id="rfc.xref.Part1.8"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>) when it receives a non-error response to a request with a method whose safety is unknown.
    11901190      </p>
    11911191      <p id="rfc.section.6.p.5">Here, a "non-error response" is one with a <a href="p2-semantics.html#status.2xx" class="smpl">2xx (Successful)</a> or <a href="p2-semantics.html#status.3xx" class="smpl">3xx (Redirection)</a> status code. "Invalidate" means that the cache will either remove all stored responses related to the effective request URI,
     
    14671467         that time.
    14681468      </p>
    1469       <p id="rfc.section.7.3.p.3">The field-value is an absolute date and time as defined by HTTP-date in <a href="p2-semantics.html#http.date" title="Date/Time Formats">Section 9.1</a> of <a href="#Part2" id="rfc.xref.Part2.7"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>; a sender <em class="bcp14">MUST</em> use the rfc1123-date format.
     1469      <p id="rfc.section.7.3.p.3">The field-value is an absolute date and time as defined by HTTP-date in <a href="p2-semantics.html#http.date" title="Date/Time Formats">Section 9.1</a> of <a href="#Part2" id="rfc.xref.Part2.7"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>; a sender <em class="bcp14">MUST</em> use the rfc1123-date format.
    14701470      </p>
    14711471      <div id="rfc.figure.u.9"></div><pre class="inline"><span id="rfc.iref.g.5"></span>  <a href="#header.expires" class="smpl">Expires</a> = <a href="#imported.abnf" class="smpl">HTTP-date</a>
     
    18411841      </p>
    18421842      <h1 id="rfc.section.11"><a href="#rfc.section.11">11.</a>&nbsp;<a id="acks" href="#acks">Acknowledgments</a></h1>
    1843       <p id="rfc.section.11.p.1">See <a href="p1-messaging.html#acks" title="Acknowledgments">Section 9</a> of <a href="#Part1" id="rfc.xref.Part1.9"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>.
     1843      <p id="rfc.section.11.p.1">See <a href="p1-messaging.html#acks" title="Acknowledgments">Section 9</a> of <a href="#Part1" id="rfc.xref.Part1.9"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>.
    18441844      </p>
    18451845      <h1 id="rfc.references"><a id="rfc.section.12" href="#rfc.section.12">12.</a> References
     
    18501850         <tr>
    18511851            <td class="reference"><b id="Part1">[Part1]</b></td>
    1852             <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-p1-messaging-latest">HTTP/1.1, part 1: Message Routing and Syntax"</a>”, Internet-Draft&nbsp;draft-ietf-httpbis-p1-messaging-latest (work in progress), September&nbsp;2012.
     1852            <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-p1-messaging-latest">Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing</a>”, Internet-Draft&nbsp;draft-ietf-httpbis-p1-messaging-latest (work in progress), September&nbsp;2012.
    18531853            </td>
    18541854         </tr>
    18551855         <tr>
    18561856            <td class="reference"><b id="Part2">[Part2]</b></td>
    1857             <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.
     1857            <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.
    18581858            </td>
    18591859         </tr>
    18601860         <tr>
    18611861            <td class="reference"><b id="Part4">[Part4]</b></td>
    1862             <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.
     1862            <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.
    18631863            </td>
    18641864         </tr>
    18651865         <tr>
    18661866            <td class="reference"><b id="Part5">[Part5]</b></td>
    1867             <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.
     1867            <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.
    18681868            </td>
    18691869         </tr>
    18701870         <tr>
    18711871            <td class="reference"><b id="Part7">[Part7]</b></td>
    1872             <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.
     1872            <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.
    18731873            </td>
    18741874         </tr>
     
    19461946         character).
    19471947      </p>
    1948       <p id="rfc.section.B.p.2">The rules below are defined in <a href="#Part1" id="rfc.xref.Part1.10"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>:
    1949       </p>
    1950       <div id="rfc.figure.u.14"></div><pre class="inline">  <a href="#imported.abnf" class="smpl">OWS</a>           = &lt;OWS, defined in <a href="#Part1" id="rfc.xref.Part1.11"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>, <a href="p1-messaging.html#whitespace" title="Whitespace">Section 3.2.1</a>&gt;
    1951   <a href="#imported.abnf" class="smpl">field-name</a>    = &lt;field-name, defined in <a href="#Part1" id="rfc.xref.Part1.12"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>, <a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a>&gt;
    1952   <a href="#imported.abnf" class="smpl">quoted-string</a> = &lt;quoted-string, defined in <a href="#Part1" id="rfc.xref.Part1.13"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>, <a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.4</a>&gt;
    1953   <a href="#imported.abnf" class="smpl">token</a>         = &lt;token, defined in <a href="#Part1" id="rfc.xref.Part1.14"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>, <a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.4</a>&gt;
    1954 
    1955   <a href="#imported.abnf" class="smpl">port</a>          = &lt;port, defined in <a href="#Part1" id="rfc.xref.Part1.15"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.7</a>&gt;
    1956   <a href="#imported.abnf" class="smpl">pseudonym</a>     = &lt;pseudonym, defined in <a href="#Part1" id="rfc.xref.Part1.16"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>, <a href="p1-messaging.html#header.via" title="Via">Section 5.7</a>&gt;
    1957   <a href="#imported.abnf" class="smpl">uri-host</a>      = &lt;uri-host, defined in <a href="#Part1" id="rfc.xref.Part1.17"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.7</a>&gt;
     1948      <p id="rfc.section.B.p.2">The rules below are defined in <a href="#Part1" id="rfc.xref.Part1.10"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>:
     1949      </p>
     1950      <div id="rfc.figure.u.14"></div><pre class="inline">  <a href="#imported.abnf" class="smpl">OWS</a>           = &lt;OWS, defined in <a href="#Part1" id="rfc.xref.Part1.11"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#whitespace" title="Whitespace">Section 3.2.1</a>&gt;
     1951  <a href="#imported.abnf" class="smpl">field-name</a>    = &lt;field-name, defined in <a href="#Part1" id="rfc.xref.Part1.12"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a>&gt;
     1952  <a href="#imported.abnf" class="smpl">quoted-string</a> = &lt;quoted-string, defined in <a href="#Part1" id="rfc.xref.Part1.13"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.4</a>&gt;
     1953  <a href="#imported.abnf" class="smpl">token</a>         = &lt;token, defined in <a href="#Part1" id="rfc.xref.Part1.14"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.4</a>&gt;
     1954
     1955  <a href="#imported.abnf" class="smpl">port</a>          = &lt;port, defined in <a href="#Part1" id="rfc.xref.Part1.15"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.7</a>&gt;
     1956  <a href="#imported.abnf" class="smpl">pseudonym</a>     = &lt;pseudonym, defined in <a href="#Part1" id="rfc.xref.Part1.16"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#header.via" title="Via">Section 5.7</a>&gt;
     1957  <a href="#imported.abnf" class="smpl">uri-host</a>      = &lt;uri-host, defined in <a href="#Part1" id="rfc.xref.Part1.17"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.7</a>&gt;
    19581958</pre><p id="rfc.section.B.p.4">The rules below are defined in other parts:</p>
    1959       <div id="rfc.figure.u.15"></div><pre class="inline">  <a href="#imported.abnf" class="smpl">HTTP-date</a>     = &lt;HTTP-date, defined in <a href="#Part2" id="rfc.xref.Part2.8"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>, <a href="p2-semantics.html#http.date" title="Date/Time Formats">Section 9.1</a>&gt;
     1959      <div id="rfc.figure.u.15"></div><pre class="inline">  <a href="#imported.abnf" class="smpl">HTTP-date</a>     = &lt;HTTP-date, defined in <a href="#Part2" id="rfc.xref.Part2.8"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>, <a href="p2-semantics.html#http.date" title="Date/Time Formats">Section 9.1</a>&gt;
    19601960</pre><h1 id="rfc.section.C"><a href="#rfc.section.C">C.</a>&nbsp;<a id="collected.abnf" href="#collected.abnf">Collected ABNF</a></h1>
    19611961      <div id="rfc.figure.u.16"></div> <pre class="inline"><a href="#header.age" class="smpl">Age</a> = delta-seconds
  • draft-ietf-httpbis/latest/p6-cache.xml

    r1860 r1864  
    6363<front>
    6464
    65   <title abbrev="HTTP/1.1, Part 6">HTTP/1.1, part 6: Caching</title>
     65  <title abbrev="HTTP/1.1 Caching">Hypertext Transfer Protocol (HTTP/1.1): Caching</title>
    6666
    6767  <author fullname="Roy T. Fielding" initials="R." role="editor" surname="Fielding">
     
    21852185  <reference anchor="Part1">
    21862186    <front>
    2187       <title>HTTP/1.1, part 1: Message Routing and Syntax"</title>
     2187      <title>Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing</title>
    21882188      <author fullname="Roy T. Fielding" initials="R." role="editor" surname="Fielding">
    21892189        <organization abbrev="Adobe">Adobe Systems Incorporated</organization>
     
    22092209  <reference anchor="Part2">
    22102210    <front>
    2211       <title>HTTP/1.1, part 2: Semantics and Payloads</title>
     2211      <title>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</title>
    22122212      <author fullname="Roy T. Fielding" initials="R." role="editor" surname="Fielding">
    22132213        <organization abbrev="Adobe">Adobe Systems Incorporated</organization>
     
    22472247  <reference anchor="Part4">
    22482248    <front>
    2249       <title>HTTP/1.1, part 4: Conditional Requests</title>
     2249      <title>Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests</title>
    22502250      <author fullname="Roy T. Fielding" initials="R." role="editor" surname="Fielding">
    22512251        <organization abbrev="Adobe">Adobe Systems Incorporated</organization>
     
    22752275  <reference anchor="Part5">
    22762276    <front>
    2277       <title>HTTP/1.1, part 5: Range Requests</title>
     2277      <title>Hypertext Transfer Protocol (HTTP/1.1): Range Requests</title>
    22782278      <author fullname="Roy T. Fielding" initials="R." role="editor" surname="Fielding">
    22792279        <organization abbrev="Adobe">Adobe Systems Incorporated</organization>
     
    23002300  <reference anchor="Part7">
    23012301    <front>
    2302       <title>HTTP/1.1, part 7: Authentication</title>
     2302      <title>Hypertext Transfer Protocol (HTTP/1.1): Authentication</title>
    23032303      <author fullname="Roy T. Fielding" initials="R." role="editor" surname="Fielding">
    23042304        <organization abbrev="Adobe">Adobe Systems Incorporated</organization>
  • draft-ietf-httpbis/latest/p7-auth.html

    r1845 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 7: Authentication</title><script>
     6      <title>Hypertext Transfer Protocol (HTTP/1.1): Authentication</title><script>
    77var buttonsAdded = false;
    88
     
    443443  }
    444444  @top-center {
    445        content: "HTTP/1.1, Part 7";
     445       content: "HTTP/1.1 Authentication";
    446446  }
    447447  @bottom-left {
     
    449449  }
    450450  @bottom-center {
    451        content: "Expires March 5, 2013";
     451       content: "Expires March 8, 2013";
    452452  }
    453453  @bottom-right {
     
    490490      <meta name="dct.creator" content="Reschke, J. F.">
    491491      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p7-auth-latest">
    492       <meta name="dct.issued" scheme="ISO8601" content="2012-09-01">
     492      <meta name="dct.issued" scheme="ISO8601" content="2012-09-04">
    493493      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    494494      <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. This document defines the HTTP Authentication framework.">
     
    521521            </tr>
    522522            <tr>
    523                <td class="left">Expires: March 5, 2013</td>
     523               <td class="left">Expires: March 8, 2013</td>
    524524               <td class="right">greenbytes</td>
    525525            </tr>
    526526            <tr>
    527527               <td class="left"></td>
    528                <td class="right">September 1, 2012</td>
     528               <td class="right">September 4, 2012</td>
    529529            </tr>
    530530         </tbody>
    531531      </table>
    532       <p class="title">HTTP/1.1, part 7: Authentication<br><span class="filename">draft-ietf-httpbis-p7-auth-latest</span></p>
     532      <p class="title">Hypertext Transfer Protocol (HTTP/1.1): Authentication<br><span class="filename">draft-ietf-httpbis-p7-auth-latest</span></p>
    533533      <h1 id="rfc.abstract"><a href="#rfc.abstract">Abstract</a></h1>
    534534      <p>The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information
     
    551551         in progress”.
    552552      </p>
    553       <p>This Internet-Draft will expire on March 5, 2013.</p>
     553      <p>This Internet-Draft will expire on March 8, 2013.</p>
    554554      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    555555      <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
     
    636636      <p id="rfc.section.1.1.p.2">This specification targets conformance criteria according to the role of a participant in HTTP communication. Hence, HTTP
    637637         requirements are placed on senders, recipients, clients, servers, user agents, intermediaries, origin servers, proxies, gateways,
    638          or caches, depending on what behavior is being constrained by the requirement. See <a href="p1-messaging.html#architecture" title="Architecture">Section 2</a> of <a href="#Part1" id="rfc.xref.Part1.1"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a> for definitions of these terms.
     638         or caches, depending on what behavior is being constrained by the requirement. See <a href="p1-messaging.html#architecture" title="Architecture">Section 2</a> of <a href="#Part1" id="rfc.xref.Part1.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a> for definitions of these terms.
    639639      </p>
    640640      <p id="rfc.section.1.1.p.3">The verb "generate" is used instead of "send" where a requirement differentiates between creating a protocol element and merely
     
    654654      </p>
    655655      <h2 id="rfc.section.1.2"><a href="#rfc.section.1.2">1.2</a>&nbsp;<a id="notation" href="#notation">Syntax Notation</a></h2>
    656       <p id="rfc.section.1.2.p.1">This specification uses the Augmented Backus-Naur Form (ABNF) notation of <a href="#RFC5234" id="rfc.xref.RFC5234.1"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a> with the list rule extension defined in <a href="p1-messaging.html#notation" title="Syntax Notation">Section 1.2</a> of <a href="#Part1" id="rfc.xref.Part1.2"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>. <a href="#imported.abnf" title="Imported ABNF">Appendix&nbsp;B</a> describes rules imported from other documents. <a href="#collected.abnf" title="Collected ABNF">Appendix&nbsp;C</a> shows the collected ABNF with the list rule expanded.
     656      <p id="rfc.section.1.2.p.1">This specification uses the Augmented Backus-Naur Form (ABNF) notation of <a href="#RFC5234" id="rfc.xref.RFC5234.1"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a> with the list rule extension defined in <a href="p1-messaging.html#notation" title="Syntax Notation">Section 1.2</a> of <a href="#Part1" id="rfc.xref.Part1.2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>. <a href="#imported.abnf" title="Imported ABNF">Appendix&nbsp;B</a> describes rules imported from other documents. <a href="#collected.abnf" title="Collected ABNF">Appendix&nbsp;C</a> shows the collected ABNF with the list rule expanded.
    657657      </p>
    658658      <h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a>&nbsp;<a id="access.authentication.framework" href="#access.authentication.framework">Access Authentication Framework</a></h1>
     
    705705         a proxy <em class="bcp14">SHOULD</em> return a <a href="#status.407" class="smpl">407 (Proxy Authentication Required)</a> response. Such responses <em class="bcp14">MUST</em> include a <a href="#header.proxy-authenticate" class="smpl">Proxy-Authenticate</a> header field containing a (possibly new) challenge applicable to the proxy.
    706706      </p>
    707       <p id="rfc.section.2.1.p.16">A server receiving credentials that are valid, but not adequate to gain access, ought to respond with the <a href="p2-semantics.html#status.403" class="smpl">403 (Forbidden)</a> status code (<a href="p2-semantics.html#status.403" title="403 Forbidden">Section 5.5.3</a> of <a href="#Part2" id="rfc.xref.Part2.1"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>).
     707      <p id="rfc.section.2.1.p.16">A server receiving credentials that are valid, but not adequate to gain access, ought to respond with the <a href="p2-semantics.html#status.403" class="smpl">403 (Forbidden)</a> status code (<a href="p2-semantics.html#status.403" title="403 Forbidden">Section 7.5.3</a> of <a href="#Part2" id="rfc.xref.Part2.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>).
    708708      </p>
    709709      <p id="rfc.section.2.1.p.17">The HTTP protocol does not restrict applications to this simple challenge-response mechanism for access authentication. Additional
     
    718718      <h2 id="rfc.section.2.2"><a href="#rfc.section.2.2">2.2</a>&nbsp;<a id="protection.space" href="#protection.space">Protection Space (Realm)</a></h2>
    719719      <p id="rfc.section.2.2.p.1">The authentication parameter realm is reserved for use by authentication schemes that wish to indicate the scope of protection.</p>
    720       <p id="rfc.section.2.2.p.2">A <dfn>protection space</dfn> is defined by the canonical root URI (the scheme and authority components of the effective request URI; see <a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 5.5</a> of <a href="#Part1" id="rfc.xref.Part1.3"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>) of the server being accessed, in combination with the realm value if present. These realms allow the protected resources
     720      <p id="rfc.section.2.2.p.2">A <dfn>protection space</dfn> is defined by the canonical root URI (the scheme and authority components of the effective request URI; see <a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 5.5</a> of <a href="#Part1" id="rfc.xref.Part1.3"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>) of the server being accessed, in combination with the realm value if present. These realms allow the protected resources
    721721         on a server to be partitioned into a set of protection spaces, each with its own authentication scheme and/or authorization
    722722         database. The realm value is a string, generally assigned by the origin server, which can have additional semantics specific
     
    753753            <p>HTTP authentication is presumed to be stateless: all of the information necessary to authenticate a request <em class="bcp14">MUST</em> be provided in the request, rather than be dependent on the server remembering prior requests. Authentication based on, or
    754754               bound to, the underlying connection is outside the scope of this specification and inherently flawed unless steps are taken
    755                to ensure that the connection cannot be used by any party other than the authenticated user (see <a href="p1-messaging.html#intermediaries" title="Intermediaries">Section 2.3</a> of <a href="#Part1" id="rfc.xref.Part1.4"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>).
     755               to ensure that the connection cannot be used by any party other than the authenticated user (see <a href="p1-messaging.html#intermediaries" title="Intermediaries">Section 2.3</a> of <a href="#Part1" id="rfc.xref.Part1.4"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>).
    756756            </p>
    757757         </li>
     
    823823         such as credentials that vary according to a challenge value or using synchronized clocks).
    824824      </p>
    825       <p id="rfc.section.4.1.p.4">When a shared cache (see <a href="p6-cache.html#shared.and.non-shared.caches">Section 1.2</a> of <a href="#Part6" id="rfc.xref.Part6.1"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) receives a request containing an Authorization field, it <em class="bcp14">MUST NOT</em> return the corresponding response as a reply to any other request, unless one of the following specific exceptions holds:
     825      <p id="rfc.section.4.1.p.4">When a shared cache (see <a href="p6-cache.html#shared.and.non-shared.caches">Section 1.2</a> of <a href="#Part6" id="rfc.xref.Part6.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>) receives a request containing an Authorization field, it <em class="bcp14">MUST NOT</em> return the corresponding response as a reply to any other request, unless one of the following specific exceptions holds:
    826826      </p>
    827827      <p id="rfc.section.4.1.p.5"> </p>
     
    840840      <h2 id="rfc.section.4.2"><a href="#rfc.section.4.2">4.2</a>&nbsp;<a id="header.proxy-authenticate" href="#header.proxy-authenticate">Proxy-Authenticate</a></h2>
    841841      <p id="rfc.section.4.2.p.1">The "Proxy-Authenticate" header field consists of at least one challenge that indicates the authentication scheme(s) and parameters
    842          applicable to the proxy for this effective request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 5.5</a> of <a href="#Part1" id="rfc.xref.Part1.5"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>). It <em class="bcp14">MUST</em> be included as part of a <a href="#status.407" class="smpl">407 (Proxy Authentication Required)</a> response.
     842         applicable to the proxy for this effective request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 5.5</a> of <a href="#Part1" id="rfc.xref.Part1.5"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>). It <em class="bcp14">MUST</em> be included as part of a <a href="#status.407" class="smpl">407 (Proxy Authentication Required)</a> response.
    843843      </p>
    844844      <div id="rfc.figure.u.5"></div><pre class="inline"><span id="rfc.iref.g.7"></span>  <a href="#header.proxy-authenticate" class="smpl">Proxy-Authenticate</a> = 1#<a href="#challenge.and.response" class="smpl">challenge</a>
     
    865865      <h2 id="rfc.section.4.4"><a href="#rfc.section.4.4">4.4</a>&nbsp;<a id="header.www-authenticate" href="#header.www-authenticate">WWW-Authenticate</a></h2>
    866866      <p id="rfc.section.4.4.p.1">The "WWW-Authenticate" header field consists of at least one challenge that indicates the authentication scheme(s) and parameters
    867          applicable to the effective request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 5.5</a> of <a href="#Part1" id="rfc.xref.Part1.6"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>).
     867         applicable to the effective request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 5.5</a> of <a href="#Part1" id="rfc.xref.Part1.6"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>).
    868868      </p>
    869869      <p id="rfc.section.4.4.p.2">It <em class="bcp14">MUST</em> be included in <a href="#status.401" class="smpl">401 (Unauthorized)</a> response messages and <em class="bcp14">MAY</em> be included in other response messages to indicate that supplying credentials (or different credentials) might affect the
     
    10061006         Lawrence C. Stewart for their work on that specification. See <a href="http://tools.ietf.org/html/rfc2617#section-6">Section 6</a> of <a href="#RFC2617" id="rfc.xref.RFC2617.4"><cite title="HTTP Authentication: Basic and Digest Access Authentication">[RFC2617]</cite></a> for further acknowledgements.
    10071007      </p>
    1008       <p id="rfc.section.7.p.2">See <a href="p1-messaging.html#acks" title="Acknowledgments">Section 9</a> of <a href="#Part1" id="rfc.xref.Part1.7"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a> for the Acknowledgments related to this document revision.
     1008      <p id="rfc.section.7.p.2">See <a href="p1-messaging.html#acks" title="Acknowledgments">Section 9</a> of <a href="#Part1" id="rfc.xref.Part1.7"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a> for the Acknowledgments related to this document revision.
    10091009      </p>
    10101010      <h1 id="rfc.references"><a id="rfc.section.8" href="#rfc.section.8">8.</a> References
     
    10151015         <tr>
    10161016            <td class="reference"><b id="Part1">[Part1]</b></td>
    1017             <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-p1-messaging-latest">HTTP/1.1, part 1: Message Routing and Syntax"</a>”, Internet-Draft&nbsp;draft-ietf-httpbis-p1-messaging-latest (work in progress), September&nbsp;2012.
     1017            <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-p1-messaging-latest">Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing</a>”, Internet-Draft&nbsp;draft-ietf-httpbis-p1-messaging-latest (work in progress), September&nbsp;2012.
    10181018            </td>
    10191019         </tr>
    10201020         <tr>
    10211021            <td class="reference"><b id="Part2">[Part2]</b></td>
    1022             <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.
     1022            <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.
    10231023            </td>
    10241024         </tr>
    10251025         <tr>
    10261026            <td class="reference"><b id="Part6">[Part6]</b></td>
    1027             <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.
     1027            <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.
    10281028            </td>
    10291029         </tr>
     
    11011101         character).
    11021102      </p>
    1103       <p id="rfc.section.B.p.2">The rules below are defined in <a href="#Part1" id="rfc.xref.Part1.8"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>:
    1104       </p>
    1105       <div id="rfc.figure.u.9"></div><pre class="inline">  <a href="#imported.abnf" class="smpl">BWS</a>           = &lt;BWS, defined in <a href="#Part1" id="rfc.xref.Part1.9"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>, <a href="p1-messaging.html#whitespace" title="Whitespace">Section 3.2.1</a>&gt;
    1106   <a href="#imported.abnf" class="smpl">OWS</a>           = &lt;OWS, defined in <a href="#Part1" id="rfc.xref.Part1.10"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>, <a href="p1-messaging.html#whitespace" title="Whitespace">Section 3.2.1</a>&gt;
    1107   <a href="#imported.abnf" class="smpl">quoted-string</a> = &lt;quoted-string, defined in <a href="#Part1" id="rfc.xref.Part1.11"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>, <a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.4</a>&gt;
    1108   <a href="#imported.abnf" class="smpl">token</a>         = &lt;token, defined in <a href="#Part1" id="rfc.xref.Part1.12"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>, <a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.4</a>&gt;
     1103      <p id="rfc.section.B.p.2">The rules below are defined in <a href="#Part1" id="rfc.xref.Part1.8"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>:
     1104      </p>
     1105      <div id="rfc.figure.u.9"></div><pre class="inline">  <a href="#imported.abnf" class="smpl">BWS</a>           = &lt;BWS, defined in <a href="#Part1" id="rfc.xref.Part1.9"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#whitespace" title="Whitespace">Section 3.2.1</a>&gt;
     1106  <a href="#imported.abnf" class="smpl">OWS</a>           = &lt;OWS, defined in <a href="#Part1" id="rfc.xref.Part1.10"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#whitespace" title="Whitespace">Section 3.2.1</a>&gt;
     1107  <a href="#imported.abnf" class="smpl">quoted-string</a> = &lt;quoted-string, defined in <a href="#Part1" id="rfc.xref.Part1.11"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.4</a>&gt;
     1108  <a href="#imported.abnf" class="smpl">token</a>         = &lt;token, defined in <a href="#Part1" id="rfc.xref.Part1.12"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.4</a>&gt;
    11091109</pre><h1 id="rfc.section.C"><a href="#rfc.section.C">C.</a>&nbsp;<a id="collected.abnf" href="#collected.abnf">Collected ABNF</a></h1>
    11101110      <div id="rfc.figure.u.10"></div> <pre class="inline"><a href="#header.authorization" class="smpl">Authorization</a> = credentials
     
    12181218                  </li>
    12191219                  <li><em>Part2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.1">2.1</a>, <a href="#Part2"><b>8.1</b></a><ul>
    1220                         <li><em>Section 5.5.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.1">2.1</a></li>
     1220                        <li><em>Section 7.5.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.1">2.1</a></li>
    12211221                     </ul>
    12221222                  </li>
  • draft-ietf-httpbis/latest/p7-auth.xml

    r1845 r1864  
    4848<front>
    4949
    50   <title abbrev="HTTP/1.1, Part 7">HTTP/1.1, part 7: Authentication</title>
     50  <title abbrev="HTTP/1.1 Authentication">Hypertext Transfer Protocol (HTTP/1.1): Authentication</title>
    5151
    5252  <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor">
     
    834834<reference anchor="Part1">
    835835  <front>
    836     <title>HTTP/1.1, part 1: Message Routing and Syntax"</title>
     836    <title>Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing</title>
    837837    <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor">
    838838      <organization abbrev="Adobe">Adobe Systems Incorporated</organization>
     
    855855<reference anchor="Part2">
    856856  <front>
    857     <title>HTTP/1.1, part 2: Semantics and Payloads</title>
     857    <title>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</title>
    858858    <author fullname="Roy T. Fielding" initials="R." role="editor" surname="Fielding">
    859859      <organization abbrev="Adobe">Adobe Systems Incorporated</organization>
     
    879879<reference anchor="Part6">
    880880  <front>
    881     <title>HTTP/1.1, part 6: Caching</title>
     881    <title>Hypertext Transfer Protocol (HTTP/1.1): Caching</title>
    882882    <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor">
    883883      <organization abbrev="Adobe">Adobe Systems Incorporated</organization>
Note: See TracChangeset for help on using the changeset viewer.