Changeset 1864 for draft-ietf-httpbis/latest/p2-semantics.html
- Timestamp:
- 04/09/12 20:16:43 (10 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
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>
Note: See TracChangeset
for help on using the changeset viewer.