Changeset 1864 for draft-ietf-httpbis
- Timestamp:
- 04/09/12 20:16:43 (9 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 14 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p0-introduction.html
r1845 r1864 393 393 } 394 394 @bottom-center { 395 content: "Expires March 5, 2013";395 content: "Expires March 8, 2013"; 396 396 } 397 397 @bottom-right { … … 426 426 <meta name="dct.creator" content="Reschke, J. F."> 427 427 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p0-introduction-latest"> 428 <meta name="dct.issued" scheme="ISO8601" content="2012-09-0 1">428 <meta name="dct.issued" scheme="ISO8601" content="2012-09-04"> 429 429 <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."> 430 430 <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."> … … 446 446 </tr> 447 447 <tr> 448 <td class="left">Expires: March 5, 2013</td>448 <td class="left">Expires: March 8, 2013</td> 449 449 <td class="right">W3C</td> 450 450 </tr> … … 467 467 <tr> 468 468 <td class="left"></td> 469 <td class="right">September 1, 2012</td>469 <td class="right">September 4, 2012</td> 470 470 </tr> 471 471 </tbody> … … 490 490 in progress”. 491 491 </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> 493 493 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 494 494 <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 4 4 <head profile="http://www.w3.org/2006/03/hcard http://dublincore.org/documents/2008/08/04/dc-html/"> 5 5 <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> 6 <title>H TTP/1.1, part 1: Message Routing and Syntax"</title><script>6 <title>Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing</title><script> 7 7 var buttonsAdded = false; 8 8 … … 443 443 } 444 444 @top-center { 445 content: "HTTP/1.1 , Part 1";445 content: "HTTP/1.1 Message Syntax and Routing"; 446 446 } 447 447 @bottom-left { … … 533 533 </tbody> 534 534 </table> 535 <p class="title">H TTP/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> 536 536 <h1 id="rfc.abstract"><a href="#rfc.abstract">Abstract</a></h1> 537 537 <p>The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information … … 736 736 </p> 737 737 <ul class="empty"> 738 <li>RFC xxx1: Message Routing and Syntax</li>739 <li><cite title="H TTP/1.1, part 2: Semantics and Payloads" id="rfc.xref.Part2.1">RFC xxx2</cite>: Semantics and Payloads740 </li> 741 <li><cite title="H TTP/1.1, part 4: Conditional Requests" id="rfc.xref.Part4.1">RFC xxx3</cite>: Conditional Requests742 </li> 743 <li><cite title="H TTP/1.1, part 5: Range Requests" id="rfc.xref.Part5.1">RFC xxx4</cite>: Range Requests744 </li> 745 <li><cite title="H TTP/1.1, part 6: Caching" id="rfc.xref.Part6.1">RFC xxx5</cite>: Caching746 </li> 747 <li><cite title="H TTP/1.1, part 7: Authentication" id="rfc.xref.Part7.1">RFC xxx6</cite>: Authentication738 <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 748 748 </li> 749 749 </ul> … … 820 820 "<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. 821 821 </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 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="H TTP/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 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). 823 823 </p> 824 824 <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 … … 907 907 or an intranet-to-Internet privacy filter. Such transformations are presumed to be desired by the client (or client organization) 908 908 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="H TTP/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. 910 910 </p> 911 911 <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 … … 951 951 </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 952 952 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="H TTP/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>. 954 954 </p> 955 955 <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 … … 1077 1077 </p> 1078 1078 <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 3</a>) containing the URI's identifying data (<a href="#message.routing" title="Message Routing">Section 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="H TTP/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 3</a>) containing the URI's identifying data (<a href="#message.routing" title="Message Routing">Section 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. 1080 1080 </p> 1081 1081 <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 … … 1102 1102 <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> ] 1103 1103 </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="H TTP/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>). 1105 1105 </p> 1106 1106 <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 … … 1175 1175 </div> 1176 1176 <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="H TTP/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. 1178 1178 </p> 1179 1179 <div id="rfc.iref.r.6"></div> … … 1188 1188 </p> 1189 1189 <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="H TTP/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>). 1191 1191 </p> 1192 1192 <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. … … 1201 1201 <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 1202 1202 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="H TTP/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), 1204 1204 the status codes defined by this specification, considerations for the definition of new status codes, and the IANA registry. 1205 1205 </p> … … 1222 1222 ; see <a href="#field.parsing" title="Field Parsing">Section 3.2.2</a> 1223 1223 </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="H TTP/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. 1225 1225 </p> 1226 1226 <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 … … 1230 1230 them. 1231 1231 </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="H TTP/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 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 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. 1233 1233 </p> 1234 1234 <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" … … 1382 1382 <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 3.2</a>, before determining the message body length. 1383 1383 </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="H TTP/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="H TTP/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 transfer1384 <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 1387 1387 coding to the message body if the request had been an unconditional GET. This indication is not required, however, because 1388 1388 any recipient on the response chain (including the origin server) can remove transfer codings when they are not needed. … … 1404 1404 <div id="rfc.figure.u.29"></div><pre class="text"> Content-Length: 3495 1405 1405 </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="H TTP/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 would1406 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 1407 1407 have been sent in a <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> response. 1408 1408 </p> … … 1499 1499 </p> 1500 1500 <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="H TTP/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>. 1502 1502 </p> 1503 1503 <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 … … 1662 1662 that a client can be assured of buffering the entire response. 1663 1663 </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="H TTP/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; 1665 1665 a value of 0 means "not acceptable". 1666 1666 </p> … … 1683 1683 </p> 1684 1684 <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="H TTP/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 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 reserved1685 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 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 1686 1686 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>). 1687 1687 </p> … … 1690 1690 semantics and, if so, where that request is to be directed. 1691 1691 </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="H TTP/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. 1693 1693 </p> 1694 1694 <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 … … 1742 1742 </p> 1743 1743 <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="H TTP/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, 1745 1745 </p> 1746 1746 </div> 1747 1747 <div id="rfc.figure.u.41"></div><pre class="text2">CONNECT www.example.com:80 HTTP/1.1 1748 1748 </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="H TTP/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, 1750 1750 the client <em class="bcp14">MUST</em> send only "*" (%x2A) as the request-target. For example, 1751 1751 </p> … … 1885 1885 except as noted above to replace an empty path with "/" or "*". 1886 1886 </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="H TTP/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 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 4</a>). 1888 1888 </p> 1889 1889 <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 … … 1893 1893 </p> 1894 1894 <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="H TTP/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="H TTP/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>) 1898 1898 </li> 1899 1899 <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>) 1900 1900 </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="H TTP/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="H TTP/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="H TTP/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="H TTP/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. 1909 1909 </p> 1910 1910 <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: 1911 1911 </p> 1912 1912 <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="H TTP/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="H TTP/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="H TTP/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="H TTP/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>). 1921 1921 </p> 1922 1922 <div class="note" id="rfc.section.5.8.p.9"> … … 1928 1928 <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 1929 1929 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="H TTP/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. 1931 1931 </p> 1932 1932 <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. … … 1967 1967 </pre><p id="rfc.section.6.1.p.6">Connection options are case-insensitive.</p> 1968 1968 <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="H TTP/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>). 1970 1970 </p> 1971 1971 <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 … … 2050 2050 <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. 2051 2051 </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="H TTP/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 to2052 <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 2053 2053 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. 2054 2054 </p> 2055 2055 <h4 id="rfc.section.6.2.2.2"><a href="#rfc.section.6.2.2.2">6.2.2.2</a> <a id="persistent.retrying.requests" href="#persistent.retrying.requests">Retrying Requests</a></h4> 2056 2056 <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="H TTP/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 understanding2057 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 2058 2058 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. 2059 2059 </p> … … 2149 2149 </p> 2150 2150 <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="H TTP/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>). 2152 2152 </p> 2153 2153 <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 … … 2410 2410 <li>Pointer to specification text</li> 2411 2411 </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="H TTP/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 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 4.2</a>. 2413 2413 </p> 2414 2414 <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 … … 2566 2566 that most implementations will choose substantially higher limits. 2567 2567 </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="H TTP/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>). 2569 2569 </p> 2570 2570 <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. … … 2616 2616 <tr> 2617 2617 <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">H TTP/1.1, part 2: Semantics and Payloads</a>”, Internet-Draft draft-ietf-httpbis-p2-semantics-latest (work in progress), September 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 draft-ietf-httpbis-p2-semantics-latest (work in progress), September 2012. 2619 2619 </td> 2620 2620 </tr> 2621 2621 <tr> 2622 2622 <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">H TTP/1.1, part 4: Conditional Requests</a>”, Internet-Draft draft-ietf-httpbis-p4-conditional-latest (work in progress), September 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 draft-ietf-httpbis-p4-conditional-latest (work in progress), September 2012. 2624 2624 </td> 2625 2625 </tr> 2626 2626 <tr> 2627 2627 <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">H TTP/1.1, part 5: Range Requests</a>”, Internet-Draft draft-ietf-httpbis-p5-range-latest (work in progress), September 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 draft-ietf-httpbis-p5-range-latest (work in progress), September 2012. 2629 2629 </td> 2630 2630 </tr> 2631 2631 <tr> 2632 2632 <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">H TTP/1.1, part 6: Caching</a>”, Internet-Draft draft-ietf-httpbis-p6-cache-latest (work in progress), September 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 draft-ietf-httpbis-p6-cache-latest (work in progress), September 2012. 2634 2634 </td> 2635 2635 </tr> 2636 2636 <tr> 2637 2637 <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">H TTP/1.1, part 7: Authentication</a>”, Internet-Draft draft-ietf-httpbis-p7-auth-latest (work in progress), September 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 draft-ietf-httpbis-p7-auth-latest (work in progress), September 2012. 2639 2639 </td> 2640 2640 </tr> -
draft-ietf-httpbis/latest/p1-messaging.xml
r1863 r1864 74 74 <front> 75 75 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> 77 77 78 78 <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor"> … … 161 161 that collectively form the HTTP/1.1 specification: 162 162 <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> 165 165 <t><xref target="Part4" x:fmt="none">RFC xxx3</xref>: Conditional Requests</t> 166 166 <t><xref target="Part5" x:fmt="none">RFC xxx4</xref>: Range Requests</t> … … 3926 3926 <reference anchor="Part2"> 3927 3927 <front> 3928 <title>H TTP/1.1, part 2: Semantics and Payloads</title>3928 <title>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</title> 3929 3929 <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor"> 3930 3930 <organization abbrev="Adobe">Adobe Systems Incorporated</organization> … … 3979 3979 <reference anchor="Part4"> 3980 3980 <front> 3981 <title>H TTP/1.1, part 4: Conditional Requests</title>3981 <title>Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests</title> 3982 3982 <author fullname="Roy T. Fielding" initials="R." role="editor" surname="Fielding"> 3983 3983 <organization abbrev="Adobe">Adobe Systems Incorporated</organization> … … 4004 4004 <reference anchor="Part5"> 4005 4005 <front> 4006 <title>H TTP/1.1, part 5: Range Requests</title>4006 <title>Hypertext Transfer Protocol (HTTP/1.1): Range Requests</title> 4007 4007 <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor"> 4008 4008 <organization abbrev="Adobe">Adobe Systems Incorporated</organization> … … 4027 4027 <reference anchor="Part6"> 4028 4028 <front> 4029 <title>H TTP/1.1, part 6: Caching</title>4029 <title>Hypertext Transfer Protocol (HTTP/1.1): Caching</title> 4030 4030 <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor"> 4031 4031 <organization abbrev="Adobe">Adobe Systems Incorporated</organization> … … 4054 4054 <reference anchor="Part7"> 4055 4055 <front> 4056 <title>H TTP/1.1, part 7: Authentication</title>4056 <title>Hypertext Transfer Protocol (HTTP/1.1): Authentication</title> 4057 4057 <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor"> 4058 4058 <organization abbrev="Adobe">Adobe Systems Incorporated</organization> -
draft-ietf-httpbis/latest/p2-semantics.html
r1862 r1864 4 4 <head profile="http://www.w3.org/2006/03/hcard http://dublincore.org/documents/2008/08/04/dc-html/"> 5 5 <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> 6 <title>H TTP/1.1, part 2: Semantics and Payloads</title><script>6 <title>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</title><script> 7 7 var buttonsAdded = false; 8 8 … … 443 443 } 444 444 @top-center { 445 content: "HTTP/1.1 , Part 2";445 content: "HTTP/1.1 Semantics and Content"; 446 446 } 447 447 @bottom-left { … … 538 538 </tbody> 539 539 </table> 540 <p class="title">H TTP/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> 541 541 <h1 id="rfc.abstract"><a href="#rfc.abstract">Abstract</a></h1> 542 542 <p>The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information … … 845 845 <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, 846 846 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="H TTP/1.1, part 1: Message Routing and Syntax"">[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>. 848 848 </p> 849 849 <p id="rfc.section.1.p.2">HTTP provides a uniform interface for interacting with resources regardless of their type, nature, or implementation. HTTP … … 858 858 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>. 859 859 </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="H TTP/1.1, part 1: Message Routing and Syntax"">[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>. 861 861 </p> 862 862 <h2 id="rfc.section.1.2"><a href="#rfc.section.1.2">1.2</a> <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="H TTP/1.1, part 1: Message Routing and Syntax"">[Part1]</cite></a>. <a href="#imported.abnf" title="Imported ABNF">Appendix D</a> describes rules imported from other documents. <a href="#collected.abnf" title="Collected ABNF">Appendix 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 D</a> describes rules imported from other documents. <a href="#collected.abnf" title="Collected ABNF">Appendix E</a> shows the collected ABNF with the list rule expanded. 864 864 </p> 865 865 <h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a> <a id="resource" href="#resource">Resource</a></h1> 866 866 <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 867 867 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="H TTP/1.1, part 1: Message Routing and Syntax"">[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="H TTP/1.1, part 1: Message Routing and Syntax"">[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"">[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>). 871 871 </p> 872 872 <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 … … 891 891 in an HTTP message, it is referred to as the payload of the message. 892 892 </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="H TTP/1.1, part 1: Message Routing and Syntax"">[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. 894 894 </p> 895 895 <h2 id="rfc.section.3.1"><a href="#rfc.section.3.1">3.1</a> <a id="identifying.response.associated.with.representation" href="#identifying.response.associated.with.representation">Identifying the Resource Associated with a Representation</a></h2> 896 896 <p id="rfc.section.3.1.p.1">It is sometimes necessary to determine an identifier for the resource associated with a representation.</p> 897 897 <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="H TTP/1.1, part 1: Message Routing and Syntax"">[Part1]</cite></a>). However, this is not always the case. To determine the URI of the resource a response is associated with, the following898 <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 899 899 rules are used (with the first applicable one being selected): 900 900 </p> … … 949 949 <tr> 950 950 <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="H TTP/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> 952 952 </tr> 953 953 </tbody> … … 1027 1027 </p> 1028 1028 <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="H TTP/1.1, part 1: Message Routing and Syntax"">[Part1]</cite></a>). It is representation metadata. It has the same syntax and semantics as the header field of the same name defined for MIME1029 </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 1030 1030 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. 1031 1031 </p> … … 1079 1079 <tr> 1080 1080 <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="H TTP/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> 1082 1082 </tr> 1083 1083 <tr> 1084 1084 <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="H TTP/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> 1086 1086 </tr> 1087 1087 </tbody> … … 1218 1218 <tr> 1219 1219 <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="H TTP/1.1, part 1: Message Routing and Syntax"">[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> 1221 1221 </tr> 1222 1222 <tr> 1223 1223 <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="H TTP/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> 1225 1225 </tr> 1226 1226 </tbody> … … 1228 1228 </div> 1229 1229 <h2 id="rfc.section.4.2"><a href="#rfc.section.4.2">4.2</a> <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="H TTP/1.1, part 1: Message Routing and Syntax"">[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. 1231 1231 </p> 1232 1232 <h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a> <a id="methods" href="#methods">Request Methods</a></h1> … … 1360 1360 are defined to be cacheable. In general, safe methods that do not depend on a current or authoritative response are cacheable, 1361 1361 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="H TTP/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>. 1363 1363 </p> 1364 1364 <h2 id="rfc.section.5.3"><a href="#rfc.section.5.3">5.3</a> <a id="method.definitions" href="#method.definitions">Method Definitions</a></h2> … … 1370 1370 in the response and not the source text of the process, unless that text happens to be the output of the process. 1371 1371 </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="H TTP/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 conditional1372 <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 1373 1373 header field(s). The conditional GET request is intended to reduce unnecessary network usage by allowing cached representations 1374 1374 to be refreshed without requiring multiple requests or transferring data already held by the client. 1375 1375 </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="H TTP/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 representations1376 <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 1377 1377 to be completed without transferring data already held by the client. 1378 1378 </p> … … 1380 1380 to reject the request. 1381 1381 </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="H TTP/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>). 1383 1383 </p> 1384 1384 <p id="rfc.section.5.3.1.p.7">See <a href="#encoding.sensitive.information.in.uris" title="Encoding Sensitive Information in URIs">Section 11.2</a> for security considerations when used for forms. … … 1391 1391 hypertext links for validity, accessibility, and recent modification. 1392 1392 </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="H TTP/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>. 1394 1394 </p> 1395 1395 <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 … … 1416 1416 <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 8.1.1</a>). 1417 1417 </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="H TTP/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 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 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. 1419 1419 </p> 1420 1420 <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. … … 1476 1476 the related resources. 1477 1477 </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="H TTP/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 full1478 <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 1479 1479 representation). Partial content updates are possible by targeting a separately identified resource with state that overlaps 1480 1480 a portion of the larger resource, or by using a different method that has been specifically defined for partial updates (for … … 1482 1482 </p> 1483 1483 <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="H TTP/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>). 1485 1485 </p> 1486 1486 <h3 id="rfc.section.5.3.5"><a href="#rfc.section.5.3.5">5.3.5</a> <a id="DELETE" href="#DELETE">DELETE</a></h3> … … 1498 1498 </p> 1499 1499 <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="H TTP/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>). 1501 1501 </p> 1502 1502 <div id="rfc.iref.c.7"></div> … … 1506 1506 its behavior to blind forwarding of packets until the connection is closed. 1507 1507 </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="H TTP/1.1, part 1: Message Routing and Syntax"">[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. 1509 1509 For example, 1510 1510 </p> … … 1552 1552 body to make more detailed queries on the server. 1553 1553 </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="H TTP/1.1, part 1: Message Routing and Syntax"">[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. 1555 1555 Since a server's communication options typically depend on the resource, the "*" request is only useful as a "ping" or "no-op" 1556 1556 type of method; it does nothing beyond allowing the client to test the capabilities of the server. For example, this can be … … 1571 1571 </p> 1572 1572 <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="H TTP/1.1, part 1: Message Routing and Syntax"">[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 forwarding1573 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 1574 1574 messages in an infinite loop. 1575 1575 </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="H TTP/1.1, part 1: Message Routing and Syntax"">[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. 1577 1577 </p> 1578 1578 <h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a> <a id="request.header.fields" href="#request.header.fields">Request Header Fields</a></h1> … … 1595 1595 <tr> 1596 1596 <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="H TTP/1.1, part 1: Message Routing and Syntax"">[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> 1598 1598 </tr> 1599 1599 <tr> … … 1607 1607 <tr> 1608 1608 <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="H TTP/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> 1610 1610 </tr> 1611 1611 </tbody> … … 1702 1702 <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 1703 1703 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="H TTP/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>. 1705 1705 </p> 1706 1706 <div id="rfc.table.u.5"> … … 1715 1715 <tr> 1716 1716 <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="H TTP/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> 1718 1718 </tr> 1719 1719 <tr> 1720 1720 <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="H TTP/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> 1722 1722 </tr> 1723 1723 <tr> 1724 1724 <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="H TTP/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> 1726 1726 </tr> 1727 1727 <tr> 1728 1728 <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="H TTP/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> 1730 1730 </tr> 1731 1731 <tr> 1732 1732 <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="H TTP/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> 1734 1734 </tr> 1735 1735 </tbody> … … 1984 1984 <tr> 1985 1985 <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="H TTP/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> 1987 1987 </tr> 1988 1988 <tr> 1989 1989 <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="H TTP/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> 1991 1991 </tr> 1992 1992 </tbody> … … 2013 2013 <tr> 2014 2014 <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="H TTP/1.1, part 1: Message Routing and Syntax"">[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> 2016 2016 </tr> 2017 2017 <tr> … … 2070 2070 user agent limitations. 2071 2071 </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 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="H TTP/1.1, part 1: Message Routing and Syntax"">[Part1]</cite></a>) identifying the agent and its significant subproducts. By convention, the product tokens are listed in order of their significance2072 <p id="rfc.section.6.5.3.p.3">The field can contain multiple product tokens (<a href="#product.tokens" title="Product Tokens">Section 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 2073 2073 for identifying the application. 2074 2074 </p> … … 2110 2110 </p> 2111 2111 <h2 id="rfc.section.7.1"><a href="#rfc.section.7.1">7.1</a> <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="H TTP/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 the2112 <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 2113 2113 protocol. 2114 2114 </p> … … 2166 2166 <td class="left">206</td> 2167 2167 <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="H TTP/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> 2169 2169 </tr> 2170 2170 <tr> … … 2191 2191 <td class="left">304</td> 2192 2192 <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="H TTP/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> 2194 2194 </tr> 2195 2195 <tr> … … 2211 2211 <td class="left">401</td> 2212 2212 <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="H TTP/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> 2214 2214 </tr> 2215 2215 <tr> … … 2241 2241 <td class="left">407</td> 2242 2242 <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="H TTP/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> 2244 2244 </tr> 2245 2245 <tr> … … 2266 2266 <td class="left">412</td> 2267 2267 <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="H TTP/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> 2269 2269 </tr> 2270 2270 <tr> … … 2286 2286 <td class="left">416</td> 2287 2287 <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="H TTP/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> 2289 2289 </tr> 2290 2290 <tr> … … 2356 2356 <div id="rfc.iref.s.5"></div> 2357 2357 <h3 id="rfc.section.7.2.2"><a href="#rfc.section.7.2.2">7.2.2</a> <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="H TTP/1.1, part 1: Message Routing and Syntax"">[Part1]</cite></a>), for a change in the application protocol being used on this connection. The server will switch protocols to those defined2358 <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 2359 2359 by the response's Upgrade header field immediately after the empty line which terminates the 101 response. 2360 2360 </p> … … 2381 2381 <dd>a representation containing the request message as received by the end server.</dd> 2382 2382 </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="H TTP/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. 2384 2384 </p> 2385 2385 <div id="rfc.iref.80"></div> … … 2394 2394 </p> 2395 2395 <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="H TTP/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>). 2397 2397 </p> 2398 2398 <div id="rfc.iref.81"></div> … … 2411 2411 <div id="rfc.iref.s.10"></div> 2412 2412 <h3 id="rfc.section.7.3.4"><a href="#rfc.section.7.3.4">7.3.4</a> <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="H TTP/1.1, part 1: Message Routing and Syntax"">[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>). 2414 2414 </p> 2415 2415 <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="H TTP/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="H TTP/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. 2419 2419 </p> 2420 2420 <div id="rfc.iref.83"></div> … … 2446 2446 another input action. 2447 2447 </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="H TTP/1.1, part 1: Message Routing and Syntax"">[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>. 2449 2449 </p> 2450 2450 <h2 id="rfc.section.7.4"><a href="#rfc.section.7.4">7.4</a> <a id="status.3xx" href="#status.3xx">Redirection 3xx</a></h2> … … 2474 2474 <li> 2475 2475 <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="H TTP/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>). 2477 2477 </p> 2478 2478 </li> … … 2508 2508 <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. 2509 2509 </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="H TTP/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. 2511 2511 </p> 2512 2512 <div id="rfc.iref.87"></div> … … 2516 2516 request URI to one or more of the new references returned by the server, where possible. 2517 2517 </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="H TTP/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. 2519 2519 </p> 2520 2520 <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). … … 2665 2665 — that is left to the discretion of the server owner. 2666 2666 </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="H TTP/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. 2668 2668 </p> 2669 2669 <div id="rfc.iref.103"></div> … … 2705 2705 <div id="rfc.iref.s.36"></div> 2706 2706 <h3 id="rfc.section.7.5.15"><a href="#rfc.section.7.5.15">7.5.15</a> <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="H TTP/1.1, part 1: Message Routing and Syntax"">[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. 2708 2708 </p> 2709 2709 <div id="rfc.figure.u.33"></div> … … 2770 2770 <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 2771 2771 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="H TTP/1.1, part 1: Message Routing and Syntax"">[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. 2773 2773 </p> 2774 2774 <h1 id="rfc.section.8"><a href="#rfc.section.8">8.</a> <a id="response.header.fields" href="#response.header.fields">Response Header Fields</a></h1> 2775 2775 <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="H TTP/1.1, part 1: Message Routing and Syntax"">[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>). 2777 2777 </p> 2778 2778 <h2 id="rfc.section.8.1"><a href="#rfc.section.8.1">8.1</a> <a id="response.control.data" href="#response.control.data">Control Data</a></h2> … … 2858 2858 <tr> 2859 2859 <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="H TTP/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> 2861 2861 </tr> 2862 2862 <tr> … … 2905 2905 <h3 id="rfc.section.8.2.2"><a href="#rfc.section.8.2.2">8.2.2</a> <a id="header.vary" href="#header.vary">Vary</a></h3> 2906 2906 <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="H TTP/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>). 2908 2908 </p> 2909 2909 <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 … … 2939 2939 <tr> 2940 2940 <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="H TTP/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> 2942 2942 </tr> 2943 2943 <tr> 2944 2944 <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="H TTP/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> 2946 2946 </tr> 2947 2947 </tbody> … … 2961 2961 <tr> 2962 2962 <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="H TTP/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> 2964 2964 </tr> 2965 2965 <tr> … … 2991 2991 <h3 id="rfc.section.8.4.2"><a href="#rfc.section.8.4.2">8.4.2</a> <a id="header.server" href="#header.server">Server</a></h3> 2992 2992 <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 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="H TTP/1.1, part 1: Message Routing and Syntax"">[Part1]</cite></a>) identifying the server and any significant subproducts. The product tokens are listed in order of their significance for2993 <p id="rfc.section.8.4.2.p.2">The field can contain multiple product tokens (<a href="#product.tokens" title="Product Tokens">Section 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 2994 2994 identifying the application. 2995 2995 </p> … … 2997 2997 </pre><p id="rfc.section.8.4.2.p.4">Example:</p> 2998 2998 <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="H TTP/1.1, part 1: Message Routing and Syntax"">[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>). 3000 3000 </p> 3001 3001 <div class="note" id="rfc.section.8.4.2.p.7"> … … 3132 3132 </p> 3133 3133 <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="H TTP/1.1, part 1: Message Routing and Syntax"">[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>. 3135 3135 </li> 3136 3136 </ul> … … 3138 3138 </p> 3139 3139 <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="H TTP/1.1, part 1: Message Routing and Syntax"">[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>. 3141 3141 </li> 3142 3142 </ul> … … 3144 3144 </p> 3145 3145 <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="H TTP/1.1, part 1: Message Routing and Syntax"">[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>. 3147 3147 </li> 3148 3148 </ul> … … 3238 3238 specific to a single application or data format, since orthogonal technologies deserve orthogonal specification. 3239 3239 </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="H TTP/1.1, part 1: Message Routing and Syntax"">[Part1]</cite></a>) is independent of method semantics (aside from responses to HEAD), definitions of new HTTP methods cannot change the parsing3240 <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 3241 3241 algorithm or prohibit the presence of a message body on either the request or the response message. Definitions of new methods 3242 3242 can specify that only zero-length bodies are allowed, which would imply that each such messages would be required to contain … … 3343 3343 a zero-length response body. They can require the presence of one or more particular HTTP response header field(s). 3344 3344 </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="H TTP/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 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 3.1</a>; by default, it is anonymous). 3346 3346 </p> 3347 3347 <h3 id="rfc.section.10.2.3"><a href="#rfc.section.10.2.3">10.2.3</a> <a id="status.code.registration" href="#status.code.registration">Registrations</a></h3> … … 3582 3582 <h3 id="rfc.section.10.3.1"><a href="#rfc.section.10.3.1">10.3.1</a> <a id="considerations.for.new.header.fields" href="#considerations.for.new.header.fields">Considerations for New Header Fields</a></h3> 3583 3583 <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="H TTP/1.1, part 1: Message Routing and Syntax"">[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. 3585 3585 </p> 3586 3586 <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 3587 3587 with "X-" if they are to be registered (either immediately or in the future). 3588 3588 </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="H TTP/1.1, part 1: Message Routing and Syntax"">[Part1]</cite></a> as necessary, and are usually constrained to the range of ASCII characters. Header fields needing a greater range of characters3589 <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 3590 3590 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>. 3591 3591 </p> 3592 3592 <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 3593 3593 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="H TTP/1.1, part 1: Message Routing and Syntax"">[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>). 3595 3595 </p> 3596 3596 <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 … … 3610 3610 <ul> 3611 3611 <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="H TTP/1.1, part 1: Message Routing and Syntax"">[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>). 3613 3613 </p> 3614 3614 <p>If it does not use the list syntax, document how to treat messages where the header field occurs multiple times (a sensible … … 3626 3626 </li> 3627 3627 <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="H TTP/1.1, part 1: Message Routing and Syntax"">[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>). 3629 3629 </p> 3630 3630 </li> … … 3633 3633 </li> 3634 3634 <li> 3635 <p>How the header field might interact with caching (see <a href="#Part6" id="rfc.xref.Part6.18"><cite title="H TTP/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>). 3636 3636 </p> 3637 3637 </li> 3638 3638 <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="H TTP/1.1, part 1: Message Routing and Syntax"">[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>). 3640 3640 </p> 3641 3641 </li> … … 3803 3803 <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> 3804 3804 <h2 id="rfc.section.10.4"><a href="#rfc.section.10.4">10.4</a> <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="H TTP/1.1, part 1: Message Routing and Syntax"">[Part1]</cite></a>). The content coding registry is maintained at <<a href="http://www.iana.org/assignments/http-parameters">http://www.iana.org/assignments/http-parameters</a>>.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 <<a href="http://www.iana.org/assignments/http-parameters">http://www.iana.org/assignments/http-parameters</a>>. 3806 3806 </p> 3807 3807 <h3 id="rfc.section.10.4.1"><a href="#rfc.section.10.4.1">10.4.1</a> <a id="content.coding.procedure" href="#content.coding.procedure">Procedure</a></h3> … … 3813 3813 <li>Pointer to specification text</li> 3814 3814 </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="H TTP/1.1, part 1: Message Routing and Syntax"">[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"">[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>). 3816 3816 </p> 3817 3817 <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. … … 3833 3833 <td class="left">compress</td> 3834 3834 <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="H TTP/1.1, part 1: Message Routing and Syntax"">[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> 3836 3836 </td> 3837 3837 </tr> … … 3840 3840 <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>) 3841 3841 </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="H TTP/1.1, part 1: Message Routing and Syntax"">[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> 3843 3843 </td> 3844 3844 </tr> … … 3846 3846 <td class="left">gzip</td> 3847 3847 <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="H TTP/1.1, part 1: Message Routing and Syntax"">[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> 3849 3849 </td> 3850 3850 </tr> … … 3938 3938 </p> 3939 3939 <h1 id="rfc.section.12"><a href="#rfc.section.12">12.</a> <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="H TTP/1.1, part 1: Message Routing and Syntax"">[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>. 3941 3941 </p> 3942 3942 <h1 id="rfc.references"><a id="rfc.section.13" href="#rfc.section.13">13.</a> References … … 3947 3947 <tr> 3948 3948 <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">H TTP/1.1, part 1: Message Routing and Syntax"</a>”, Internet-Draft draft-ietf-httpbis-p1-messaging-latest (work in progress), September 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 draft-ietf-httpbis-p1-messaging-latest (work in progress), September 2012. 3950 3950 </td> 3951 3951 </tr> 3952 3952 <tr> 3953 3953 <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">H TTP/1.1, part 4: Conditional Requests</a>”, Internet-Draft draft-ietf-httpbis-p4-conditional-latest (work in progress), September 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 draft-ietf-httpbis-p4-conditional-latest (work in progress), September 2012. 3955 3955 </td> 3956 3956 </tr> 3957 3957 <tr> 3958 3958 <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">H TTP/1.1, part 5: Range Requests</a>”, Internet-Draft draft-ietf-httpbis-p5-range-latest (work in progress), September 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 draft-ietf-httpbis-p5-range-latest (work in progress), September 2012. 3960 3960 </td> 3961 3961 </tr> 3962 3962 <tr> 3963 3963 <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">H TTP/1.1, part 6: Caching</a>”, Internet-Draft draft-ietf-httpbis-p6-cache-latest (work in progress), September 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 draft-ietf-httpbis-p6-cache-latest (work in progress), September 2012. 3965 3965 </td> 3966 3966 </tr> 3967 3967 <tr> 3968 3968 <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">H TTP/1.1, part 7: Authentication</a>”, Internet-Draft draft-ietf-httpbis-p7-auth-latest (work in progress), September 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 draft-ietf-httpbis-p7-auth-latest (work in progress), September 2012. 3970 3970 </td> 3971 3971 </tr> … … 4250 4250 <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 6.5.2</a>) 4251 4251 </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="H TTP/1.1, part 1: Message Routing and Syntax"">[Part1]</cite></a>. (<a href="#header.server" id="rfc.xref.header.server.4" title="Server">Section 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 8.4.2</a>) 4253 4253 </p> 4254 4254 <p id="rfc.section.C.p.18">Clarify contexts that charset is used in. (<a href="#character.sets" title="Character Encodings (charset)">Section 9.3</a>) … … 4277 4277 (any visible US-ASCII character). 4278 4278 </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="H TTP/1.1, part 1: Message Routing and Syntax"">[Part1]</cite></a>:4280 </p> 4281 <div id="rfc.figure.u.64"></div><pre class="inline"> <a href="#imported.abnf" class="smpl">BWS</a> = <BWS, defined in <a href="#Part1" id="rfc.xref.Part1.46"><cite title="H TTP/1.1, part 1: Message Routing and Syntax"">[Part1]</cite></a>, <a href="p1-messaging.html#whitespace" title="Whitespace">Section 3.2.1</a>>4282 <a href="#imported.abnf" class="smpl">OWS</a> = <OWS, defined in <a href="#Part1" id="rfc.xref.Part1.47"><cite title="H TTP/1.1, part 1: Message Routing and Syntax"">[Part1]</cite></a>, <a href="p1-messaging.html#whitespace" title="Whitespace">Section 3.2.1</a>>4283 <a href="#imported.abnf" class="smpl">RWS</a> = <RWS, defined in <a href="#Part1" id="rfc.xref.Part1.48"><cite title="H TTP/1.1, part 1: Message Routing and Syntax"">[Part1]</cite></a>, <a href="p1-messaging.html#whitespace" title="Whitespace">Section 3.2.1</a>>4284 <a href="#imported.abnf" class="smpl">quoted-string</a> = <quoted-string, defined in <a href="#Part1" id="rfc.xref.Part1.49"><cite title="H TTP/1.1, part 1: Message Routing and Syntax"">[Part1]</cite></a>, <a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.4</a>>4285 <a href="#imported.abnf" class="smpl">token</a> = <token, defined in <a href="#Part1" id="rfc.xref.Part1.50"><cite title="H TTP/1.1, part 1: Message Routing and Syntax"">[Part1]</cite></a>, <a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.4</a>>4286 <a href="#imported.abnf" class="smpl">word</a> = <word, defined in <a href="#Part1" id="rfc.xref.Part1.51"><cite title="H TTP/1.1, part 1: Message Routing and Syntax"">[Part1]</cite></a>, <a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.4</a>>4287 4288 <a href="#imported.abnf" class="smpl">absolute-URI</a> = <absolute-URI, defined in <a href="#Part1" id="rfc.xref.Part1.52"><cite title="H TTP/1.1, part 1: Message Routing and Syntax"">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.7</a>>4289 <a href="#imported.abnf" class="smpl">comment</a> = <comment, defined in <a href="#Part1" id="rfc.xref.Part1.53"><cite title="H TTP/1.1, part 1: Message Routing and Syntax"">[Part1]</cite></a>, <a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.4</a>>4290 <a href="#imported.abnf" class="smpl">partial-URI</a> = <partial-URI, defined in <a href="#Part1" id="rfc.xref.Part1.54"><cite title="H TTP/1.1, part 1: Message Routing and Syntax"">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.7</a>>4291 <a href="#imported.abnf" class="smpl">URI-reference</a> = <URI-reference, defined in <a href="#Part1" id="rfc.xref.Part1.55"><cite title="H TTP/1.1, part 1: Message Routing and Syntax"">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.7</a>>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> = <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>> 4282 <a href="#imported.abnf" class="smpl">OWS</a> = <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>> 4283 <a href="#imported.abnf" class="smpl">RWS</a> = <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>> 4284 <a href="#imported.abnf" class="smpl">quoted-string</a> = <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>> 4285 <a href="#imported.abnf" class="smpl">token</a> = <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>> 4286 <a href="#imported.abnf" class="smpl">word</a> = <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>> 4287 4288 <a href="#imported.abnf" class="smpl">absolute-URI</a> = <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>> 4289 <a href="#imported.abnf" class="smpl">comment</a> = <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>> 4290 <a href="#imported.abnf" class="smpl">partial-URI</a> = <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>> 4291 <a href="#imported.abnf" class="smpl">URI-reference</a> = <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>> 4292 4292 </pre><h1 id="rfc.section.E"><a href="#rfc.section.E">E.</a> <a id="collected.abnf" href="#collected.abnf">Collected ABNF</a></h1> 4293 4293 <div id="rfc.figure.u.65"></div> <pre class="inline"><a href="#header.accept" class="smpl">Accept</a> = [ ( "," / ( media-range [ accept-params ] ) ) *( OWS "," [ … … 4468 4468 <p id="rfc.section.F.2.p.2">Other changes: </p> 4469 4469 <ul> 4470 <li>Move definitions of 304 and 412 condition codes to <a href="#Part4" id="rfc.xref.Part4.14"><cite title="H TTP/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> 4471 4471 </li> 4472 4472 </ul> -
draft-ietf-httpbis/latest/p2-semantics.xml
r1860 r1864 129 129 <front> 130 130 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> 132 132 133 133 <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor"> … … 4922 4922 <reference anchor="Part1"> 4923 4923 <front> 4924 <title>H TTP/1.1, part 1: Message Routing and Syntax"</title>4924 <title>Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing</title> 4925 4925 <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor"> 4926 4926 <organization abbrev="Adobe">Adobe Systems Incorporated</organization> … … 4950 4950 <reference anchor="Part4"> 4951 4951 <front> 4952 <title>H TTP/1.1, part 4: Conditional Requests</title>4952 <title>Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests</title> 4953 4953 <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor"> 4954 4954 <organization abbrev="Adobe">Adobe Systems Incorporated</organization> … … 4978 4978 <reference anchor="Part5"> 4979 4979 <front> 4980 <title>H TTP/1.1, part 5: Range Requests</title>4980 <title>Hypertext Transfer Protocol (HTTP/1.1): Range Requests</title> 4981 4981 <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor"> 4982 4982 <organization abbrev="Adobe">Adobe Systems Incorporated</organization> … … 5005 5005 <reference anchor="Part6"> 5006 5006 <front> 5007 <title>H TTP/1.1, part 6: Caching</title>5007 <title>Hypertext Transfer Protocol (HTTP/1.1): Caching</title> 5008 5008 <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor"> 5009 5009 <organization abbrev="Adobe">Adobe Systems Incorporated</organization> … … 5030 5030 <reference anchor="Part7"> 5031 5031 <front> 5032 <title>H TTP/1.1, part 7: Authentication</title>5032 <title>Hypertext Transfer Protocol (HTTP/1.1): Authentication</title> 5033 5033 <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor"> 5034 5034 <organization abbrev="Adobe">Adobe Systems Incorporated</organization> -
draft-ietf-httpbis/latest/p3-payload.html
r1845 r1864 374 374 } 375 375 @bottom-center { 376 content: "Expires March 5, 2013";376 content: "Expires March 8, 2013"; 377 377 } 378 378 @bottom-right { … … 404 404 <meta name="dct.creator" content="Reschke, J. F."> 405 405 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p3-payload-latest"> 406 <meta name="dct.issued" scheme="ISO8601" content="2012-09-0 1">406 <meta name="dct.issued" scheme="ISO8601" content="2012-09-04"> 407 407 <meta name="dct.abstract" content="This part is now obsolete. Please see HTTPbis, Part 2."> 408 408 <meta name="description" content="This part is now obsolete. Please see HTTPbis, Part 2."> … … 424 424 </tr> 425 425 <tr> 426 <td class="left">Expires: March 5, 2013</td>426 <td class="left">Expires: March 8, 2013</td> 427 427 <td class="right">W3C</td> 428 428 </tr> … … 437 437 <tr> 438 438 <td class="left"></td> 439 <td class="right">September 1, 2012</td>439 <td class="right">September 4, 2012</td> 440 440 </tr> 441 441 </tbody> … … 453 453 in progress”. 454 454 </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> 456 456 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 457 457 <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 4 4 <head profile="http://www.w3.org/2006/03/hcard http://dublincore.org/documents/2008/08/04/dc-html/"> 5 5 <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> 6 <title>H TTP/1.1, part 4: Conditional Requests</title><script>6 <title>Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests</title><script> 7 7 var buttonsAdded = false; 8 8 … … 443 443 } 444 444 @top-center { 445 content: "HTTP/1.1 , Part 4";445 content: "HTTP/1.1 Conditional Requests"; 446 446 } 447 447 @bottom-left { … … 531 531 </tbody> 532 532 </table> 533 <p class="title">H TTP/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> 534 534 <h1 id="rfc.abstract"><a href="#rfc.abstract">Abstract</a></h1> 535 535 <p>The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information … … 631 631 </ul> 632 632 <h1 id="rfc.section.1" class="np"><a href="#rfc.section.1">1.</a> <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="H TTP/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 the633 <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 634 634 target resource. Each precondition is based on metadata that is expected to change if the selected representation of the target 635 635 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="H TTP/1.1, part 1: Message Routing and Syntax"">[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="H TTP/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: 639 639 one client accidentally overwriting the work of another client that has been acting in parallel. 640 640 </p> … … 657 657 <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 658 658 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="H TTP/1.1, part 1: Message Routing and Syntax"">[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. 660 660 </p> 661 661 <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 … … 675 675 </p> 676 676 <h2 id="rfc.section.1.2"><a href="#rfc.section.1.2">1.2</a> <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="H TTP/1.1, part 1: Message Routing and Syntax"">[Part1]</cite></a>. <a href="#imported.abnf" title="Imported ABNF">Appendix B</a> describes rules imported from other documents. <a href="#collected.abnf" title="Collected ABNF">Appendix 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 B</a> describes rules imported from other documents. <a href="#collected.abnf" title="Collected ABNF">Appendix C</a> shows the collected ABNF with the list rule expanded. 678 678 </p> 679 679 <div id="rfc.iref.m.1"></div> … … 739 739 </pre><h3 id="rfc.section.2.2.1"><a href="#rfc.section.2.2.1">2.2.1</a> <a id="lastmod.generation" href="#lastmod.generation">Generation</a></h3> 740 740 <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="H TTP/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 service741 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 742 742 scalability and reliability. 743 743 </p> … … 831 831 </p> 832 832 <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="H TTP/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 scalability833 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 834 834 and reliability. 835 835 </p> … … 884 884 </div> 885 885 <h3 id="rfc.section.2.3.3"><a href="#rfc.section.2.3.3">2.3.3</a> <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="H TTP/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>): 887 887 </p> 888 888 <div id="rfc.figure.u.5"></div> … … 918 918 <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 919 919 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="H TTP/1.1, part 1: Message Routing and Syntax"">[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. 921 921 </p> 922 922 </div> … … 1052 1052 <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> 1053 1053 <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="H TTP/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. 1055 1055 </li> 1056 1056 <li> <b>Note:</b> If-Modified-Since times are interpreted by the server, whose clock might not be synchronized with the client. … … 1082 1082 </p> 1083 1083 <h2 id="rfc.section.3.5"><a href="#rfc.section.3.5">3.5</a> <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="H TTP/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>. 1085 1085 </p> 1086 1086 <h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a> <a id="status.code.definitions" href="#status.code.definitions">Status Code Definitions</a></h1> … … 1093 1093 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. 1094 1094 </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="H TTP/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">2001095 <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 1096 1096 (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. 1097 1097 </p> … … 1252 1252 <p id="rfc.section.6.2.p.2">The change controller is: "IETF (iesg@ietf.org) - Internet Engineering Task Force".</p> 1253 1253 <h1 id="rfc.section.7"><a href="#rfc.section.7">7.</a> <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="H TTP/1.1, part 1: Message Routing and Syntax"">[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>. 1255 1255 </p> 1256 1256 <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 … … 1260 1260 </p> 1261 1261 <h1 id="rfc.section.8"><a href="#rfc.section.8">8.</a> <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="H TTP/1.1, part 1: Message Routing and Syntax"">[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>. 1263 1263 </p> 1264 1264 <h1 id="rfc.references"><a id="rfc.section.9" href="#rfc.section.9">9.</a> References … … 1269 1269 <tr> 1270 1270 <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">H TTP/1.1, part 1: Message Routing and Syntax"</a>”, Internet-Draft draft-ietf-httpbis-p1-messaging-latest (work in progress), September 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 draft-ietf-httpbis-p1-messaging-latest (work in progress), September 2012. 1272 1272 </td> 1273 1273 </tr> 1274 1274 <tr> 1275 1275 <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">H TTP/1.1, part 2: Semantics and Payloads</a>”, Internet-Draft draft-ietf-httpbis-p2-semantics-latest (work in progress), September 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 draft-ietf-httpbis-p2-semantics-latest (work in progress), September 2012. 1277 1277 </td> 1278 1278 </tr> 1279 1279 <tr> 1280 1280 <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">H TTP/1.1, part 5: Range Requests</a>”, Internet-Draft draft-ietf-httpbis-p5-range-latest (work in progress), September 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 draft-ietf-httpbis-p5-range-latest (work in progress), September 2012. 1282 1282 </td> 1283 1283 </tr> 1284 1284 <tr> 1285 1285 <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">H TTP/1.1, part 6: Caching</a>”, Internet-Draft draft-ietf-httpbis-p6-cache-latest (work in progress), September 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 draft-ietf-httpbis-p6-cache-latest (work in progress), September 2012. 1287 1287 </td> 1288 1288 </tr> … … 1341 1341 character). 1342 1342 </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="H TTP/1.1, part 1: Message Routing and Syntax"">[Part1]</cite></a>:1344 </p> 1345 <div id="rfc.figure.u.16"></div><pre class="inline"> <a href="#imported.abnf" class="smpl">OWS</a> = <OWS, defined in <a href="#Part1" id="rfc.xref.Part1.8"><cite title="H TTP/1.1, part 1: Message Routing and Syntax"">[Part1]</cite></a>, <a href="p1-messaging.html#whitespace" title="Whitespace">Section 3.2.1</a>>1346 <a href="#imported.abnf" class="smpl">obs-text</a> = <obs-text, defined in <a href="#Part1" id="rfc.xref.Part1.9"><cite title="H TTP/1.1, part 1: Message Routing and Syntax"">[Part1]</cite></a>, <a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.4</a>>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> = <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>> 1346 <a href="#imported.abnf" class="smpl">obs-text</a> = <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>> 1347 1347 </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> = <HTTP-date, defined in <a href="#Part2" id="rfc.xref.Part2.5"><cite title="H TTP/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>>1348 <div id="rfc.figure.u.17"></div><pre class="inline"> <a href="#imported.abnf" class="smpl">HTTP-date</a> = <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>> 1349 1349 </pre><h1 id="rfc.section.C"><a href="#rfc.section.C">C.</a> <a id="collected.abnf" href="#collected.abnf">Collected ABNF</a></h1> 1350 1350 <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 53 53 <front> 54 54 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> 56 56 57 57 <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor"> … … 1226 1226 <reference anchor="Part1"> 1227 1227 <front> 1228 <title>H TTP/1.1, part 1: Message Routing and Syntax"</title>1228 <title>Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing</title> 1229 1229 <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor"> 1230 1230 <organization abbrev="Adobe">Adobe Systems Incorporated</organization> … … 1247 1247 <reference anchor="Part2"> 1248 1248 <front> 1249 <title>H TTP/1.1, part 2: Semantics and Payloads</title>1249 <title>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</title> 1250 1250 <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor"> 1251 1251 <organization abbrev="Adobe">Adobe Systems Incorporated</organization> … … 1278 1278 <reference anchor="Part5"> 1279 1279 <front> 1280 <title>H TTP/1.1, part 5: Range Requests</title>1280 <title>Hypertext Transfer Protocol (HTTP/1.1): Range Requests</title> 1281 1281 <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor"> 1282 1282 <organization abbrev="Adobe">Adobe Systems Incorporated</organization> … … 1302 1302 <reference anchor="Part6"> 1303 1303 <front> 1304 <title>H TTP/1.1, part 6: Caching</title>1304 <title>Hypertext Transfer Protocol (HTTP/1.1): Caching</title> 1305 1305 <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor"> 1306 1306 <organization abbrev="Adobe">Adobe Systems Incorporated</organization> -
draft-ietf-httpbis/latest/p5-range.html
r1862 r1864 4 4 <head profile="http://www.w3.org/2006/03/hcard http://dublincore.org/documents/2008/08/04/dc-html/"> 5 5 <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> 6 <title>H TTP/1.1, part 5: Range Requests</title><script>6 <title>Hypertext Transfer Protocol (HTTP/1.1): Range Requests</title><script> 7 7 var buttonsAdded = false; 8 8 … … 443 443 } 444 444 @top-center { 445 content: "HTTP/1.1 , Part 5";445 content: "HTTP/1.1 Range Requests"; 446 446 } 447 447 @bottom-left { … … 532 532 </tbody> 533 533 </table> 534 <p class="title">H TTP/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> 535 535 <h1 id="rfc.abstract"><a href="#rfc.abstract">Abstract</a></h1> 536 536 <p>The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information … … 650 650 <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 651 651 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="H TTP/1.1, part 1: Message Routing and Syntax"">[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. 653 653 </p> 654 654 <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 … … 668 668 </p> 669 669 <h2 id="rfc.section.1.2"><a href="#rfc.section.1.2">1.2</a> <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="H TTP/1.1, part 1: Message Routing and Syntax"">[Part1]</cite></a>. <a href="#imported.abnf" title="Imported ABNF">Appendix C</a> describes rules imported from other documents. <a href="#collected.abnf" title="Collected ABNF">Appendix 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 C</a> describes rules imported from other documents. <a href="#collected.abnf" title="Collected ABNF">Appendix D</a> shows the collected ABNF with the list rule expanded. 671 671 </p> 672 672 <h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a> <a id="range.units" href="#range.units">Range Units</a></h1> … … 712 712 <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. 713 713 </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="H TTP/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. 715 715 </p> 716 716 <div id="rfc.iref.4"></div> … … 759 759 one or more Range specifications. After several such transfers, a client might have received several ranges of the same representation. 760 760 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="H TTP/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>. 762 762 </p> 763 763 <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 … … 861 861 <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> 862 862 </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="H TTP/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>. 864 864 </p> 865 865 <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="H TTP/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.) 867 867 </p> 868 868 <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. … … 1074 1074 </p> 1075 1075 <h1 id="rfc.section.8"><a href="#rfc.section.8">8.</a> <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="H TTP/1.1, part 1: Message Routing and Syntax"">[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>. 1077 1077 </p> 1078 1078 <h1 id="rfc.references"><a id="rfc.section.9" href="#rfc.section.9">9.</a> References … … 1083 1083 <tr> 1084 1084 <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">H TTP/1.1, part 1: Message Routing and Syntax"</a>”, Internet-Draft draft-ietf-httpbis-p1-messaging-latest (work in progress), September 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 draft-ietf-httpbis-p1-messaging-latest (work in progress), September 2012. 1086 1086 </td> 1087 1087 </tr> 1088 1088 <tr> 1089 1089 <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">H TTP/1.1, part 2: Semantics and Payloads</a>”, Internet-Draft draft-ietf-httpbis-p2-semantics-latest (work in progress), September 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 draft-ietf-httpbis-p2-semantics-latest (work in progress), September 2012. 1091 1091 </td> 1092 1092 </tr> 1093 1093 <tr> 1094 1094 <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">H TTP/1.1, part 4: Conditional Requests</a>”, Internet-Draft draft-ietf-httpbis-p4-conditional-latest (work in progress), September 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 draft-ietf-httpbis-p4-conditional-latest (work in progress), September 2012. 1096 1096 </td> 1097 1097 </tr> 1098 1098 <tr> 1099 1099 <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">H TTP/1.1, part 6: Caching</a>”, Internet-Draft draft-ietf-httpbis-p6-cache-latest (work in progress), September 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 draft-ietf-httpbis-p6-cache-latest (work in progress), September 2012. 1101 1101 </td> 1102 1102 </tr> … … 1265 1265 <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>. 1266 1266 </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="H TTP/1.1, part 1: Message Routing and Syntax"">[Part1]</cite></a>:1268 </p> 1269 <div id="rfc.figure.u.24"></div><pre class="inline"> <a href="#imported.abnf" class="smpl">OWS</a> = <OWS, defined in <a href="#Part1" id="rfc.xref.Part1.5"><cite title="H TTP/1.1, part 1: Message Routing and Syntax"">[Part1]</cite></a>, <a href="p1-messaging.html#whitespace" title="Whitespace">Section 3.2.1</a>>1270 <a href="#imported.abnf" class="smpl">token</a> = <token, defined in <a href="#Part1" id="rfc.xref.Part1.6"><cite title="H TTP/1.1, part 1: Message Routing and Syntax"">[Part1]</cite></a>, <a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.4</a>>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> = <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>> 1270 <a href="#imported.abnf" class="smpl">token</a> = <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>> 1271 1271 </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> = <HTTP-date, defined in <a href="#Part2" id="rfc.xref.Part2.1"><cite title="H TTP/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>>1273 <a href="#imported.abnf" class="smpl">entity-tag</a> = <entity-tag, defined in <a href="#Part4" id="rfc.xref.Part4.5"><cite title="H TTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>, <a href="p4-conditional.html#header.etag" title="ETag">Section 2.3</a>>1272 <div id="rfc.figure.u.25"></div><pre class="inline"> <a href="#imported.abnf" class="smpl">HTTP-date</a> = <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>> 1273 <a href="#imported.abnf" class="smpl">entity-tag</a> = <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>> 1274 1274 </pre><h1 id="rfc.section.D"><a href="#rfc.section.D">D.</a> <a id="collected.abnf" href="#collected.abnf">Collected ABNF</a></h1> 1275 1275 <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 49 49 <front> 50 50 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> 52 52 53 53 <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor"> … … 964 964 <reference anchor="Part1"> 965 965 <front> 966 <title>H TTP/1.1, part 1: Message Routing and Syntax"</title>966 <title>Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing</title> 967 967 <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor"> 968 968 <organization abbrev="Adobe">Adobe Systems Incorporated</organization> … … 987 987 <reference anchor="Part2"> 988 988 <front> 989 <title>H TTP/1.1, part 2: Semantics and Payloads</title>989 <title>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</title> 990 990 <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor"> 991 991 <organization abbrev="Adobe">Adobe Systems Incorporated</organization> … … 1015 1015 <reference anchor="Part4"> 1016 1016 <front> 1017 <title>H TTP/1.1, part 4: Conditional Requests</title>1017 <title>Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests</title> 1018 1018 <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor"> 1019 1019 <organization abbrev="Adobe">Adobe Systems Incorporated</organization> … … 1044 1044 <reference anchor="Part6"> 1045 1045 <front> 1046 <title>H TTP/1.1, part 6: Caching</title>1046 <title>Hypertext Transfer Protocol (HTTP/1.1): Caching</title> 1047 1047 <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor"> 1048 1048 <organization abbrev="Adobe">Adobe Systems Incorporated</organization> -
draft-ietf-httpbis/latest/p6-cache.html
r1862 r1864 4 4 <head profile="http://www.w3.org/2006/03/hcard http://dublincore.org/documents/2008/08/04/dc-html/"> 5 5 <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> 6 <title>H TTP/1.1, part 6: Caching</title><script>6 <title>Hypertext Transfer Protocol (HTTP/1.1): Caching</title><script> 7 7 var buttonsAdded = false; 8 8 … … 446 446 } 447 447 @top-center { 448 content: "HTTP/1.1 , Part 6";448 content: "HTTP/1.1 Caching"; 449 449 } 450 450 @bottom-left { … … 546 546 </tbody> 547 547 </table> 548 <p class="title">H TTP/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> 549 549 <h1 id="rfc.abstract"><a href="#rfc.abstract">Abstract</a></h1> 550 550 <p>The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information … … 770 770 </p> 771 771 <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="H TTP/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>. 773 773 </li> 774 774 </ul> … … 777 777 <ul class="empty"> 778 778 <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="H TTP/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>. 780 780 </li> 781 781 </ul> … … 786 786 <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 787 787 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="H TTP/1.1, part 1: Message Routing and Syntax"">[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. 789 789 </p> 790 790 <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 … … 804 804 </p> 805 805 <h2 id="rfc.section.1.4"><a href="#rfc.section.1.4">1.4</a> <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="H TTP/1.1, part 1: Message Routing and Syntax"">[Part1]</cite></a>. <a href="#imported.abnf" title="Imported ABNF">Appendix B</a> describes rules imported from other documents. <a href="#collected.abnf" title="Collected ABNF">Appendix 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 B</a> describes rules imported from other documents. <a href="#collected.abnf" title="Collected ABNF">Appendix C</a> shows the collected ABNF with the list rule expanded. 807 807 </p> 808 808 <h3 id="rfc.section.1.4.1"><a href="#rfc.section.1.4.1">1.4.1</a> <a id="delta-seconds" href="#delta-seconds">Delta Seconds</a></h3> … … 815 815 <div id="rfc.iref.c.5"></div> 816 816 <h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a> <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="H TTP/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 when817 <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 818 818 no requirement or locally-desired configuration prevents it. Therefore, HTTP cache requirements are focused on preventing 819 819 a cache from either storing a non-reusable response or reusing a stored response inappropriately. … … 842 842 <li>the "private" cache response directive (see <a href="#cache-response-directive.private" title="private">Section 7.2.2.2</a>) does not appear in the response, if the cache is shared, and 843 843 </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="H TTP/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 3.2</a>), and844 <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 3.2</a>), and 845 845 </li> 846 846 <li>the response either: … … 867 867 </p> 868 868 <h2 id="rfc.section.3.1"><a href="#rfc.section.3.1">3.1</a> <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="H TTP/1.1, part 1: Message Routing and Syntax"">[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">200869 <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 870 870 (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 871 871 (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. 872 872 </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="H TTP/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 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 specifies873 <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 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 874 874 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. 875 875 </p> 876 876 <h2 id="rfc.section.3.2"><a href="#rfc.section.3.2">3.2</a> <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="H TTP/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. 878 878 </p> 879 879 <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 7.2.2</a>) have such an effect: must-revalidate, public, s-maxage. … … 887 887 </p> 888 888 <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="H TTP/1.1, part 1: Message Routing and Syntax"">[Part1]</cite></a>) and that of the stored response match, and889 <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 890 890 </li> 891 891 <li>the request method associated with the stored response allows it to be used for the presented request, and</li> … … 911 911 <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 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 4.1.3</a>. 912 912 </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="H TTP/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 request913 <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 914 914 and having received a corresponding response. 915 915 </p> … … 965 965 <h3 id="rfc.section.4.1.2"><a href="#rfc.section.4.1.2">4.1.2</a> <a id="heuristic.freshness" href="#heuristic.freshness">Calculating Heuristic Freshness</a></h3> 966 966 <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="H TTP/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 (Partial967 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 968 968 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 969 969 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. … … 972 972 present. 973 973 </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="H TTP/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 that974 <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 975 975 time. A typical setting of this fraction might be 10%. 976 976 </p> … … 998 998 <ul class="empty"> 999 999 <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="H TTP/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. 1001 1001 </li> 1002 1002 </ul> … … 1073 1073 <h2 id="rfc.section.4.2"><a href="#rfc.section.4.2">4.2</a> <a id="validation.model" href="#validation.model">Validation Model</a></h2> 1074 1074 <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 4.3</a>), it can use the conditional request mechanism <a href="#Part4" id="rfc.xref.Part4.5"><cite title="H TTP/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 to1075 fresh, or one cannot be selected; see <a href="#caching.negotiated.responses" title="Using Negotiated Responses">Section 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 1076 1076 update it. This process is known as "validating" or "revalidating" the stored response. 1077 1077 </p> … … 1121 1121 </ul> 1122 1122 <h2 id="rfc.section.4.3"><a href="#rfc.section.4.3">4.3</a> <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="H TTP/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 original1123 <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 1124 1124 request (i.e., that associated with the stored response), and the presented request. 1125 1125 </p> … … 1129 1129 <ul> 1130 1130 <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="H TTP/1.1, part 1: Message Routing and Syntax"">[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>) 1132 1132 </li> 1133 1133 <li>normalizing both header field values in a way that is known to have identical semantics, according to the header field's specification … … 1149 1149 <h2 id="rfc.section.4.4"><a href="#rfc.section.4.4">4.4</a> <a id="combining.responses" href="#combining.responses">Combining Partial Content</a></h2> 1150 1150 <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="H TTP/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 the1152 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="H TTP/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>. 1153 1153 </p> 1154 1154 <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>: … … 1180 1180 </ul> 1181 1181 <h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a> <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="H TTP/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 them1182 <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 1183 1183 to keep their contents up-to-date. 1184 1184 </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="H TTP/1.1, part 1: Message Routing and Syntax"">[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="H TTP/1.1, part 1: Message Routing and Syntax"">[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="H TTP/1.1, part 1: Message Routing and Syntax"">[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. 1190 1190 </p> 1191 1191 <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, … … 1467 1467 that time. 1468 1468 </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="H TTP/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. 1470 1470 </p> 1471 1471 <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> … … 1841 1841 </p> 1842 1842 <h1 id="rfc.section.11"><a href="#rfc.section.11">11.</a> <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="H TTP/1.1, part 1: Message Routing and Syntax"">[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>. 1844 1844 </p> 1845 1845 <h1 id="rfc.references"><a id="rfc.section.12" href="#rfc.section.12">12.</a> References … … 1850 1850 <tr> 1851 1851 <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">H TTP/1.1, part 1: Message Routing and Syntax"</a>”, Internet-Draft draft-ietf-httpbis-p1-messaging-latest (work in progress), September 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 draft-ietf-httpbis-p1-messaging-latest (work in progress), September 2012. 1853 1853 </td> 1854 1854 </tr> 1855 1855 <tr> 1856 1856 <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">H TTP/1.1, part 2: Semantics and Payloads</a>”, Internet-Draft draft-ietf-httpbis-p2-semantics-latest (work in progress), September 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 draft-ietf-httpbis-p2-semantics-latest (work in progress), September 2012. 1858 1858 </td> 1859 1859 </tr> 1860 1860 <tr> 1861 1861 <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">H TTP/1.1, part 4: Conditional Requests</a>”, Internet-Draft draft-ietf-httpbis-p4-conditional-latest (work in progress), September 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 draft-ietf-httpbis-p4-conditional-latest (work in progress), September 2012. 1863 1863 </td> 1864 1864 </tr> 1865 1865 <tr> 1866 1866 <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">H TTP/1.1, part 5: Range Requests</a>”, Internet-Draft draft-ietf-httpbis-p5-range-latest (work in progress), September 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 draft-ietf-httpbis-p5-range-latest (work in progress), September 2012. 1868 1868 </td> 1869 1869 </tr> 1870 1870 <tr> 1871 1871 <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">H TTP/1.1, part 7: Authentication</a>”, Internet-Draft draft-ietf-httpbis-p7-auth-latest (work in progress), September 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 draft-ietf-httpbis-p7-auth-latest (work in progress), September 2012. 1873 1873 </td> 1874 1874 </tr> … … 1946 1946 character). 1947 1947 </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="H TTP/1.1, part 1: Message Routing and Syntax"">[Part1]</cite></a>:1949 </p> 1950 <div id="rfc.figure.u.14"></div><pre class="inline"> <a href="#imported.abnf" class="smpl">OWS</a> = <OWS, defined in <a href="#Part1" id="rfc.xref.Part1.11"><cite title="H TTP/1.1, part 1: Message Routing and Syntax"">[Part1]</cite></a>, <a href="p1-messaging.html#whitespace" title="Whitespace">Section 3.2.1</a>>1951 <a href="#imported.abnf" class="smpl">field-name</a> = <field-name, defined in <a href="#Part1" id="rfc.xref.Part1.12"><cite title="H TTP/1.1, part 1: Message Routing and Syntax"">[Part1]</cite></a>, <a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a>>1952 <a href="#imported.abnf" class="smpl">quoted-string</a> = <quoted-string, defined in <a href="#Part1" id="rfc.xref.Part1.13"><cite title="H TTP/1.1, part 1: Message Routing and Syntax"">[Part1]</cite></a>, <a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.4</a>>1953 <a href="#imported.abnf" class="smpl">token</a> = <token, defined in <a href="#Part1" id="rfc.xref.Part1.14"><cite title="H TTP/1.1, part 1: Message Routing and Syntax"">[Part1]</cite></a>, <a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.4</a>>1954 1955 <a href="#imported.abnf" class="smpl">port</a> = <port, defined in <a href="#Part1" id="rfc.xref.Part1.15"><cite title="H TTP/1.1, part 1: Message Routing and Syntax"">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.7</a>>1956 <a href="#imported.abnf" class="smpl">pseudonym</a> = <pseudonym, defined in <a href="#Part1" id="rfc.xref.Part1.16"><cite title="H TTP/1.1, part 1: Message Routing and Syntax"">[Part1]</cite></a>, <a href="p1-messaging.html#header.via" title="Via">Section 5.7</a>>1957 <a href="#imported.abnf" class="smpl">uri-host</a> = <uri-host, defined in <a href="#Part1" id="rfc.xref.Part1.17"><cite title="H TTP/1.1, part 1: Message Routing and Syntax"">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.7</a>>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> = <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>> 1951 <a href="#imported.abnf" class="smpl">field-name</a> = <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>> 1952 <a href="#imported.abnf" class="smpl">quoted-string</a> = <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>> 1953 <a href="#imported.abnf" class="smpl">token</a> = <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>> 1954 1955 <a href="#imported.abnf" class="smpl">port</a> = <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>> 1956 <a href="#imported.abnf" class="smpl">pseudonym</a> = <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>> 1957 <a href="#imported.abnf" class="smpl">uri-host</a> = <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>> 1958 1958 </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> = <HTTP-date, defined in <a href="#Part2" id="rfc.xref.Part2.8"><cite title="H TTP/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>>1959 <div id="rfc.figure.u.15"></div><pre class="inline"> <a href="#imported.abnf" class="smpl">HTTP-date</a> = <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>> 1960 1960 </pre><h1 id="rfc.section.C"><a href="#rfc.section.C">C.</a> <a id="collected.abnf" href="#collected.abnf">Collected ABNF</a></h1> 1961 1961 <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 63 63 <front> 64 64 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> 66 66 67 67 <author fullname="Roy T. Fielding" initials="R." role="editor" surname="Fielding"> … … 2185 2185 <reference anchor="Part1"> 2186 2186 <front> 2187 <title>H TTP/1.1, part 1: Message Routing and Syntax"</title>2187 <title>Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing</title> 2188 2188 <author fullname="Roy T. Fielding" initials="R." role="editor" surname="Fielding"> 2189 2189 <organization abbrev="Adobe">Adobe Systems Incorporated</organization> … … 2209 2209 <reference anchor="Part2"> 2210 2210 <front> 2211 <title>H TTP/1.1, part 2: Semantics and Payloads</title>2211 <title>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</title> 2212 2212 <author fullname="Roy T. Fielding" initials="R." role="editor" surname="Fielding"> 2213 2213 <organization abbrev="Adobe">Adobe Systems Incorporated</organization> … … 2247 2247 <reference anchor="Part4"> 2248 2248 <front> 2249 <title>H TTP/1.1, part 4: Conditional Requests</title>2249 <title>Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests</title> 2250 2250 <author fullname="Roy T. Fielding" initials="R." role="editor" surname="Fielding"> 2251 2251 <organization abbrev="Adobe">Adobe Systems Incorporated</organization> … … 2275 2275 <reference anchor="Part5"> 2276 2276 <front> 2277 <title>H TTP/1.1, part 5: Range Requests</title>2277 <title>Hypertext Transfer Protocol (HTTP/1.1): Range Requests</title> 2278 2278 <author fullname="Roy T. Fielding" initials="R." role="editor" surname="Fielding"> 2279 2279 <organization abbrev="Adobe">Adobe Systems Incorporated</organization> … … 2300 2300 <reference anchor="Part7"> 2301 2301 <front> 2302 <title>H TTP/1.1, part 7: Authentication</title>2302 <title>Hypertext Transfer Protocol (HTTP/1.1): Authentication</title> 2303 2303 <author fullname="Roy T. Fielding" initials="R." role="editor" surname="Fielding"> 2304 2304 <organization abbrev="Adobe">Adobe Systems Incorporated</organization> -
draft-ietf-httpbis/latest/p7-auth.html
r1845 r1864 4 4 <head profile="http://www.w3.org/2006/03/hcard http://dublincore.org/documents/2008/08/04/dc-html/"> 5 5 <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> 6 <title>H TTP/1.1, part 7: Authentication</title><script>6 <title>Hypertext Transfer Protocol (HTTP/1.1): Authentication</title><script> 7 7 var buttonsAdded = false; 8 8 … … 443 443 } 444 444 @top-center { 445 content: "HTTP/1.1 , Part 7";445 content: "HTTP/1.1 Authentication"; 446 446 } 447 447 @bottom-left { … … 449 449 } 450 450 @bottom-center { 451 content: "Expires March 5, 2013";451 content: "Expires March 8, 2013"; 452 452 } 453 453 @bottom-right { … … 490 490 <meta name="dct.creator" content="Reschke, J. F."> 491 491 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p7-auth-latest"> 492 <meta name="dct.issued" scheme="ISO8601" content="2012-09-0 1">492 <meta name="dct.issued" scheme="ISO8601" content="2012-09-04"> 493 493 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 494 494 <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."> … … 521 521 </tr> 522 522 <tr> 523 <td class="left">Expires: March 5, 2013</td>523 <td class="left">Expires: March 8, 2013</td> 524 524 <td class="right">greenbytes</td> 525 525 </tr> 526 526 <tr> 527 527 <td class="left"></td> 528 <td class="right">September 1, 2012</td>528 <td class="right">September 4, 2012</td> 529 529 </tr> 530 530 </tbody> 531 531 </table> 532 <p class="title">H TTP/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> 533 533 <h1 id="rfc.abstract"><a href="#rfc.abstract">Abstract</a></h1> 534 534 <p>The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information … … 551 551 in progress”. 552 552 </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> 554 554 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 555 555 <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 636 636 <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 637 637 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="H TTP/1.1, part 1: Message Routing and Syntax"">[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. 639 639 </p> 640 640 <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 … … 654 654 </p> 655 655 <h2 id="rfc.section.1.2"><a href="#rfc.section.1.2">1.2</a> <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="H TTP/1.1, part 1: Message Routing and Syntax"">[Part1]</cite></a>. <a href="#imported.abnf" title="Imported ABNF">Appendix B</a> describes rules imported from other documents. <a href="#collected.abnf" title="Collected ABNF">Appendix 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 B</a> describes rules imported from other documents. <a href="#collected.abnf" title="Collected ABNF">Appendix C</a> shows the collected ABNF with the list rule expanded. 657 657 </p> 658 658 <h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a> <a id="access.authentication.framework" href="#access.authentication.framework">Access Authentication Framework</a></h1> … … 705 705 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. 706 706 </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>). 708 708 </p> 709 709 <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 … … 718 718 <h2 id="rfc.section.2.2"><a href="#rfc.section.2.2">2.2</a> <a id="protection.space" href="#protection.space">Protection Space (Realm)</a></h2> 719 719 <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="H TTP/1.1, part 1: Message Routing and Syntax"">[Part1]</cite></a>) of the server being accessed, in combination with the realm value if present. These realms allow the protected resources720 <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 721 721 on a server to be partitioned into a set of protection spaces, each with its own authentication scheme and/or authorization 722 722 database. The realm value is a string, generally assigned by the origin server, which can have additional semantics specific … … 753 753 <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 754 754 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="H TTP/1.1, part 1: Message Routing and Syntax"">[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>). 756 756 </p> 757 757 </li> … … 823 823 such as credentials that vary according to a challenge value or using synchronized clocks). 824 824 </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="H TTP/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: 826 826 </p> 827 827 <p id="rfc.section.4.1.p.5"> </p> … … 840 840 <h2 id="rfc.section.4.2"><a href="#rfc.section.4.2">4.2</a> <a id="header.proxy-authenticate" href="#header.proxy-authenticate">Proxy-Authenticate</a></h2> 841 841 <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="H TTP/1.1, part 1: Message Routing and Syntax"">[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. 843 843 </p> 844 844 <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> … … 865 865 <h2 id="rfc.section.4.4"><a href="#rfc.section.4.4">4.4</a> <a id="header.www-authenticate" href="#header.www-authenticate">WWW-Authenticate</a></h2> 866 866 <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="H TTP/1.1, part 1: Message Routing and Syntax"">[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>). 868 868 </p> 869 869 <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 … … 1006 1006 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. 1007 1007 </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="H TTP/1.1, part 1: Message Routing and Syntax"">[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. 1009 1009 </p> 1010 1010 <h1 id="rfc.references"><a id="rfc.section.8" href="#rfc.section.8">8.</a> References … … 1015 1015 <tr> 1016 1016 <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">H TTP/1.1, part 1: Message Routing and Syntax"</a>”, Internet-Draft draft-ietf-httpbis-p1-messaging-latest (work in progress), September 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 draft-ietf-httpbis-p1-messaging-latest (work in progress), September 2012. 1018 1018 </td> 1019 1019 </tr> 1020 1020 <tr> 1021 1021 <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">H TTP/1.1, part 2: Semantics and Payloads</a>”, Internet-Draft draft-ietf-httpbis-p2-semantics-latest (work in progress), September 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 draft-ietf-httpbis-p2-semantics-latest (work in progress), September 2012. 1023 1023 </td> 1024 1024 </tr> 1025 1025 <tr> 1026 1026 <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">H TTP/1.1, part 6: Caching</a>”, Internet-Draft draft-ietf-httpbis-p6-cache-latest (work in progress), September 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 draft-ietf-httpbis-p6-cache-latest (work in progress), September 2012. 1028 1028 </td> 1029 1029 </tr> … … 1101 1101 character). 1102 1102 </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="H TTP/1.1, part 1: Message Routing and Syntax"">[Part1]</cite></a>:1104 </p> 1105 <div id="rfc.figure.u.9"></div><pre class="inline"> <a href="#imported.abnf" class="smpl">BWS</a> = <BWS, defined in <a href="#Part1" id="rfc.xref.Part1.9"><cite title="H TTP/1.1, part 1: Message Routing and Syntax"">[Part1]</cite></a>, <a href="p1-messaging.html#whitespace" title="Whitespace">Section 3.2.1</a>>1106 <a href="#imported.abnf" class="smpl">OWS</a> = <OWS, defined in <a href="#Part1" id="rfc.xref.Part1.10"><cite title="H TTP/1.1, part 1: Message Routing and Syntax"">[Part1]</cite></a>, <a href="p1-messaging.html#whitespace" title="Whitespace">Section 3.2.1</a>>1107 <a href="#imported.abnf" class="smpl">quoted-string</a> = <quoted-string, defined in <a href="#Part1" id="rfc.xref.Part1.11"><cite title="H TTP/1.1, part 1: Message Routing and Syntax"">[Part1]</cite></a>, <a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.4</a>>1108 <a href="#imported.abnf" class="smpl">token</a> = <token, defined in <a href="#Part1" id="rfc.xref.Part1.12"><cite title="H TTP/1.1, part 1: Message Routing and Syntax"">[Part1]</cite></a>, <a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.4</a>>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> = <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>> 1106 <a href="#imported.abnf" class="smpl">OWS</a> = <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>> 1107 <a href="#imported.abnf" class="smpl">quoted-string</a> = <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>> 1108 <a href="#imported.abnf" class="smpl">token</a> = <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>> 1109 1109 </pre><h1 id="rfc.section.C"><a href="#rfc.section.C">C.</a> <a id="collected.abnf" href="#collected.abnf">Collected ABNF</a></h1> 1110 1110 <div id="rfc.figure.u.10"></div> <pre class="inline"><a href="#header.authorization" class="smpl">Authorization</a> = credentials … … 1218 1218 </li> 1219 1219 <li><em>Part2</em> <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> <a href="#rfc.xref.Part2.1">2.1</a></li>1220 <li><em>Section 7.5.3</em> <a href="#rfc.xref.Part2.1">2.1</a></li> 1221 1221 </ul> 1222 1222 </li> -
draft-ietf-httpbis/latest/p7-auth.xml
r1845 r1864 48 48 <front> 49 49 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> 51 51 52 52 <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor"> … … 834 834 <reference anchor="Part1"> 835 835 <front> 836 <title>H TTP/1.1, part 1: Message Routing and Syntax"</title>836 <title>Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing</title> 837 837 <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor"> 838 838 <organization abbrev="Adobe">Adobe Systems Incorporated</organization> … … 855 855 <reference anchor="Part2"> 856 856 <front> 857 <title>H TTP/1.1, part 2: Semantics and Payloads</title>857 <title>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</title> 858 858 <author fullname="Roy T. Fielding" initials="R." role="editor" surname="Fielding"> 859 859 <organization abbrev="Adobe">Adobe Systems Incorporated</organization> … … 879 879 <reference anchor="Part6"> 880 880 <front> 881 <title>H TTP/1.1, part 6: Caching</title>881 <title>Hypertext Transfer Protocol (HTTP/1.1): Caching</title> 882 882 <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor"> 883 883 <organization abbrev="Adobe">Adobe Systems Incorporated</organization>
Note: See TracChangeset
for help on using the changeset viewer.