Changeset 1417 for draft-ietf-httpbis/latest
- Timestamp:
- 28/08/11 14:56:24 (11 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 2 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p2-semantics.html
r1416 r1417 359 359 } 360 360 @bottom-center { 361 content: "Expires February 2 7, 2012";361 content: "Expires February 29, 2012"; 362 362 } 363 363 @bottom-right { … … 408 408 <meta name="dct.creator" content="Reschke, J. F."> 409 409 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p2-semantics-latest"> 410 <meta name="dct.issued" scheme="ISO8601" content="2011-08-2 6">410 <meta name="dct.issued" scheme="ISO8601" content="2011-08-28"> 411 411 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 412 412 <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 2 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 2 defines the semantics of HTTP messages as expressed by request methods, request header fields, response status codes, and response header fields."> … … 439 439 </tr> 440 440 <tr> 441 <td class="left">Expires: February 2 7, 2012</td>441 <td class="left">Expires: February 29, 2012</td> 442 442 <td class="right">HP</td> 443 443 </tr> … … 492 492 <tr> 493 493 <td class="left"></td> 494 <td class="right">August 2 6, 2011</td>494 <td class="right">August 28, 2011</td> 495 495 </tr> 496 496 </tbody> … … 522 522 in progress”. 523 523 </p> 524 <p>This Internet-Draft will expire on February 2 7, 2012.</p>524 <p>This Internet-Draft will expire on February 29, 2012.</p> 525 525 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 526 526 <p>Copyright © 2011 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 558 558 </li> 559 559 <li>3. <a href="#header.fields">Header Fields</a><ul> 560 <li>3.1 <a href="#request.header.fields">Request Header Fields</a></li> 561 <li>3.2 <a href="#response.header.fields">Response Header Fields</a></li> 560 <li>3.1 <a href="#considerations.for.creating.header.fields">Considerations for Creating Header Fields</a></li> 561 <li>3.2 <a href="#request.header.fields">Request Header Fields</a></li> 562 <li>3.3 <a href="#response.header.fields">Response Header Fields</a></li> 562 563 </ul> 563 564 </li> … … 842 843 </p> 843 844 <h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a> <a id="header.fields" href="#header.fields">Header Fields</a></h1> 844 <h2 id="rfc.section.3.1"><a href="#rfc.section.3.1">3.1</a> <a id="request.header.fields" href="#request.header.fields">Request Header Fields</a></h2> 845 <p id="rfc.section.3.1.p.1">The request header fields allow the client to pass additional information about the request, and about the client itself, 845 <p id="rfc.section.3.p.1">Header fields are key value pairs that can be used to communicate data about the message, its payload, the target resource, 846 or about the connection itself (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.17"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for a general definition of their syntax. 847 </p> 848 <h2 id="rfc.section.3.1"><a href="#rfc.section.3.1">3.1</a> <a id="considerations.for.creating.header.fields" href="#considerations.for.creating.header.fields">Considerations for Creating Header Fields</a></h2> 849 <p id="rfc.section.3.1.p.1">New header fields are registered using the procedures described in <a href="#RFC3864" id="rfc.xref.RFC3864.1"><cite title="Registration Procedures for Message Header Fields">[RFC3864]</cite></a>. 850 </p> 851 <p id="rfc.section.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 852 with "X-" if they are to be registered (either immediately or in the future). 853 </p> 854 <p id="rfc.section.3.1.p.3">New header field values typically have their syntax defined using ABNF (<a href="#RFC5234" id="rfc.xref.RFC5234.3"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a>), using the extensions defined in <a href="p1-messaging.html#notation.abnf" title="ABNF Extension: #rule">Section 1.2.1</a> of <a href="#Part1" id="rfc.xref.Part1.18"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> as necessary, and are usually constrained to the range of ASCII characters. Header fields needing a greater range of characters 855 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>. 856 </p> 857 <p id="rfc.section.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 858 in the field-value's payload. Typically, components that might contain a comma are protected with double-quotes using the 859 quoted-string ABNF production (<a href="p1-messaging.html#field.rules" title="Common Field ABNF Rules">Section 3.2.3</a> of <a href="#Part1" id="rfc.xref.Part1.19"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). 860 </p> 861 <p id="rfc.section.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 862 these: 863 </p> 864 <div id="rfc.figure.u.4"></div><pre class="text"> Example-URI-Field: "http://example.com/a.html,foo", 865 "http://without-a-comma.example.com/" 866 Example-Date-Field: "Sat, 04 May 1996", "Wed, 14 Sep 2005" 867 </pre><p id="rfc.section.3.1.p.7">Authors of specifications defining new header fields are advised to consider documenting: </p> 868 <ul> 869 <li>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.20"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). 870 </li> 871 <li>Under what conditions the header field can be used; e.g., only i responses or requests, in all messages, only on responses 872 to a particular request method. 873 </li> 874 <li>Whether it is appropriate to list the field-name in the Connection header (i.e., if the header is to be hop-by-hop, see <a href="p1-messaging.html#header.connection" title="Connection">Section 9.1</a> of <a href="#Part1" id="rfc.xref.Part1.21"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). 875 </li> 876 <li>Under what conditions intermediaries are allowed to modify the header field's value, insert or delete it.</li> 877 <li>How the header might interact with caching (see <a href="#Part6" id="rfc.xref.Part6.2"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>). 878 </li> 879 <li>Whether the header field is useful or allowable in trailers (see <a href="p1-messaging.html#chunked.encoding" title="Chunked Transfer Coding">Section 6.2.1</a> of <a href="#Part1" id="rfc.xref.Part1.22"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). 880 </li> 881 <li>Whether the header field should be preserved across redirects.</li> 882 </ul> 883 <h2 id="rfc.section.3.2"><a href="#rfc.section.3.2">3.2</a> <a id="request.header.fields" href="#request.header.fields">Request Header Fields</a></h2> 884 <p id="rfc.section.3.2.p.1">The request header fields allow the client to pass additional information about the request, and about the client itself, 846 885 to the server. These fields act as request modifiers, with semantics equivalent to the parameters on a programming language 847 886 method invocation. … … 886 925 <tr> 887 926 <td class="left">Host</td> 888 <td class="left"><a href="p1-messaging.html#header.host" title="Host">Section 9.4</a> of <a href="#Part1" id="rfc.xref.Part1. 17"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a></td>927 <td class="left"><a href="p1-messaging.html#header.host" title="Host">Section 9.4</a> of <a href="#Part1" id="rfc.xref.Part1.23"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a></td> 889 928 </tr> 890 929 <tr> … … 926 965 <tr> 927 966 <td class="left">TE</td> 928 <td class="left"><a href="p1-messaging.html#header.te" title="TE">Section 9.5</a> of <a href="#Part1" id="rfc.xref.Part1. 18"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a></td>967 <td class="left"><a href="p1-messaging.html#header.te" title="TE">Section 9.5</a> of <a href="#Part1" id="rfc.xref.Part1.24"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a></td> 929 968 </tr> 930 969 <tr> … … 935 974 </table> 936 975 </div> 937 <h2 id="rfc.section.3. 2"><a href="#rfc.section.3.2">3.2</a> <a id="response.header.fields" href="#response.header.fields">Response Header Fields</a></h2>938 <p id="rfc.section.3. 2.p.1">The response header fields allow the server to pass additional information about the response which cannot be placed in the939 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 4.3</a> of <a href="#Part1" id="rfc.xref.Part1. 19"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).976 <h2 id="rfc.section.3.3"><a href="#rfc.section.3.3">3.3</a> <a id="response.header.fields" href="#response.header.fields">Response Header Fields</a></h2> 977 <p id="rfc.section.3.3.p.1">The response header fields allow the server to pass additional information about the response which cannot be placed in the 978 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 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.25"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). 940 979 </p> 941 980 <div id="rfc.table.u.3"> … … 954 993 <tr> 955 994 <td class="left">Age</td> 956 <td class="left"><a href="p6-cache.html#header.age" title="Age">Section 3.1</a> of <a href="#Part6" id="rfc.xref.Part6. 2"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a></td>995 <td class="left"><a href="p6-cache.html#header.age" title="Age">Section 3.1</a> of <a href="#Part6" id="rfc.xref.Part6.3"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a></td> 957 996 </tr> 958 997 <tr> … … 982 1021 <tr> 983 1022 <td class="left">Vary</td> 984 <td class="left"><a href="p6-cache.html#header.vary" title="Vary">Section 3.5</a> of <a href="#Part6" id="rfc.xref.Part6. 3"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a></td>1023 <td class="left"><a href="p6-cache.html#header.vary" title="Vary">Section 3.5</a> of <a href="#Part6" id="rfc.xref.Part6.4"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a></td> 985 1024 </tr> 986 1025 <tr> … … 996 1035 client does not need to examine or display the Reason-Phrase. 997 1036 </p> 998 <div id="rfc.figure.u. 4"></div><pre class="inline"><span id="rfc.iref.g.2"></span><span id="rfc.iref.g.3"></span><span id="rfc.iref.g.4"></span> <a href="#status.code.and.reason.phrase" class="smpl">Status-Code</a> = 3<a href="#notation" class="smpl">DIGIT</a>1037 <div id="rfc.figure.u.5"></div><pre class="inline"><span id="rfc.iref.g.2"></span><span id="rfc.iref.g.3"></span><span id="rfc.iref.g.4"></span> <a href="#status.code.and.reason.phrase" class="smpl">Status-Code</a> = 3<a href="#notation" class="smpl">DIGIT</a> 999 1038 <a href="#status.code.and.reason.phrase" class="smpl">Reason-Phrase</a> = *( <a href="#notation" class="smpl">WSP</a> / <a href="#notation" class="smpl">VCHAR</a> / <a href="#core.rules" class="smpl">obs-text</a> ) 1000 1039 </pre><p id="rfc.section.4.p.4">HTTP status codes are extensible. HTTP applications are not required to understand the meaning of all registered status codes, … … 1248 1287 a zero-length response body. They can require the presence of one or more particular HTTP response header(s). 1249 1288 </p> 1250 <p id="rfc.section.4.2.1.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. 4"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>; by default, it is not allowed), and can define how to determine the resource which they carry a representation for (see <a href="#identifying.response.associated.with.representation" title="Identifying the Resource Associated with a Representation">Section 5.1</a>; by default, it is anonymous).1289 <p id="rfc.section.4.2.1.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.5"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>; by default, it is not allowed), and can define how to determine the resource which they carry a representation for (see <a href="#identifying.response.associated.with.representation" title="Identifying the Resource Associated with a Representation">Section 5.1</a>; by default, it is anonymous). 1251 1290 </p> 1252 1291 <h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a> <a id="representation" href="#representation">Representation</a></h1> … … 1255 1294 in an HTTP message, it is referred to as the payload of the message. HTTP representations are defined in <a href="#Part3" id="rfc.xref.Part3.5"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>. 1256 1295 </p> 1257 <p id="rfc.section.5.p.2">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.2 0"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. The representation body is obtained from the message-body by decoding any Transfer-Encoding that might have been applied1296 <p id="rfc.section.5.p.2">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.26"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. The representation body is obtained from the message-body by decoding any Transfer-Encoding that might have been applied 1258 1297 to ensure safe and proper transfer of the message. 1259 1298 </p> … … 1261 1300 <p id="rfc.section.5.1.p.1">It is sometimes necessary to determine an identifier for the resource associated with a representation.</p> 1262 1301 <p id="rfc.section.5.1.p.2">An HTTP request representation, when present, is always associated with an anonymous (i.e., unidentified) resource.</p> 1263 <p id="rfc.section.5.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 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.2 1"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). However, this is not always the case. To determine the URI of the resource a response is associated with, the following1302 <p id="rfc.section.5.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 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.27"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). However, this is not always the case. To determine the URI of the resource a response is associated with, the following 1264 1303 rules are used (with the first applicable one being selected): 1265 1304 </p> … … 1353 1392 to reject the request. 1354 1393 </p> 1355 <p id="rfc.section.6.3.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. 5"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>).1394 <p id="rfc.section.6.3.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.6"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>). 1356 1395 </p> 1357 1396 <p id="rfc.section.6.3.p.7">See <a href="#encoding.sensitive.information.in.uris" title="Encoding Sensitive Information in URIs">Section 10.2</a> for security considerations when used for forms. … … 1364 1403 hypertext links for validity, accessibility, and recent modification. 1365 1404 </p> 1366 <p id="rfc.section.6.4.p.2">The response to a HEAD request is cacheable and <em class="bcp14">MAY</em> be used to satisfy a subsequent HEAD request; see <a href="#Part6" id="rfc.xref.Part6. 6"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>. It also <em class="bcp14">MAY</em> be used to update a previously cached representation from that resource; if the new field values indicate that the cached1405 <p id="rfc.section.6.4.p.2">The response to a HEAD request is cacheable and <em class="bcp14">MAY</em> be used to satisfy a subsequent HEAD request; see <a href="#Part6" id="rfc.xref.Part6.7"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>. It also <em class="bcp14">MAY</em> be used to update a previously cached representation from that resource; if the new field values indicate that the cached 1367 1406 representation differs from the current representation (as would be indicated by a change in Content-Length, ETag or Last-Modified), 1368 1407 then the cache <em class="bcp14">MUST</em> treat the cache entry as stale. … … 1393 1432 a Location header field (see <a href="#header.location" id="rfc.xref.header.location.2" title="Location">Section 8.4</a>). 1394 1433 </p> 1395 <p id="rfc.section.6.5.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 2.3.1</a> of <a href="#Part6" id="rfc.xref.Part6. 7"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>). A cached POST response with a Content-Location header field (see <a href="p3-payload.html#header.content-location" title="Content-Location">Section 6.7</a> of <a href="#Part3" id="rfc.xref.Part3.6"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>) whose value is the effective Request URI <em class="bcp14">MAY</em> be used to satisfy subsequent GET and HEAD requests.1434 <p id="rfc.section.6.5.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 2.3.1</a> of <a href="#Part6" id="rfc.xref.Part6.8"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>). A cached POST response with a Content-Location header field (see <a href="p3-payload.html#header.content-location" title="Content-Location">Section 6.7</a> of <a href="#Part3" id="rfc.xref.Part3.6"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>) whose value is the effective Request URI <em class="bcp14">MAY</em> be used to satisfy subsequent GET and HEAD requests. 1396 1435 </p> 1397 1436 <p id="rfc.section.6.5.p.6">Note that POST caching is not widely implemented. However, the 303 (See Other) response can be used to direct the user agent … … 1458 1497 </p> 1459 1498 <p id="rfc.section.6.6.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 1460 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 2.5</a> of <a href="#Part6" id="rfc.xref.Part6. 8"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>).1499 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 2.5</a> of <a href="#Part6" id="rfc.xref.Part6.9"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>). 1461 1500 </p> 1462 1501 <div id="rfc.iref.d.1"></div> … … 1475 1514 </p> 1476 1515 <p id="rfc.section.6.7.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 1477 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 2.5</a> of <a href="#Part6" id="rfc.xref.Part6. 9"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>).1516 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 2.5</a> of <a href="#Part6" id="rfc.xref.Part6.10"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>). 1478 1517 </p> 1479 1518 <h2 id="rfc.section.6.8"><a href="#rfc.section.6.8">6.8</a> <a id="TRACE" href="#TRACE">TRACE</a></h2> … … 1484 1523 </p> 1485 1524 <p id="rfc.section.6.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 1486 or diagnostic information. The value of the Via header field (<a href="p1-messaging.html#header.via" title="Via">Section 9.9</a> of <a href="#Part1" id="rfc.xref.Part1.2 2"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) is of particular interest, since it acts as a trace of the request chain. Use of the Max-Forwards header field allows the1525 or diagnostic information. The value of the Via header field (<a href="p1-messaging.html#header.via" title="Via">Section 9.9</a> of <a href="#Part1" id="rfc.xref.Part1.28"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) is of particular interest, since it acts as a trace of the request chain. Use of the Max-Forwards header field allows the 1487 1526 client to limit the length of the request chain, which is useful for testing a chain of proxies forwarding messages in an 1488 1527 infinite loop. 1489 1528 </p> 1490 <p id="rfc.section.6.8.p.3">If the request is valid, the response <em class="bcp14">SHOULD</em> have a Content-Type of "message/http" (see <a href="p1-messaging.html#internet.media.type.message.http" title="Internet Media Type message/http">Section 10.3.1</a> of <a href="#Part1" id="rfc.xref.Part1.2 3"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[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.1529 <p id="rfc.section.6.8.p.3">If the request is valid, the response <em class="bcp14">SHOULD</em> have a Content-Type of "message/http" (see <a href="p1-messaging.html#internet.media.type.message.http" title="Internet Media Type message/http">Section 10.3.1</a> of <a href="#Part1" id="rfc.xref.Part1.29"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[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. 1491 1530 </p> 1492 1531 <div id="rfc.iref.c.1"></div> … … 1496 1535 forwarding of packets until the connection is closed. 1497 1536 </p> 1498 <p id="rfc.section.6.9.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 4.1.2</a> of <a href="#Part1" id="rfc.xref.Part1. 24"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[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.1537 <p id="rfc.section.6.9.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 4.1.2</a> of <a href="#Part1" id="rfc.xref.Part1.30"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[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. 1499 1538 For example, 1500 1539 </p> 1501 <div id="rfc.figure.u. 5"></div><pre class="text2">CONNECT server.example.com:80 HTTP/1.11540 <div id="rfc.figure.u.6"></div><pre class="text2">CONNECT server.example.com:80 HTTP/1.1 1502 1541 Host: server.example.com:80 1503 1542 … … 1506 1545 </p> 1507 1546 <p id="rfc.section.6.9.p.5">For example, proxy authentication might be used to establish the authority to create a tunnel:</p> 1508 <div id="rfc.figure.u. 6"></div><pre class="text2">CONNECT server.example.com:80 HTTP/1.11547 <div id="rfc.figure.u.7"></div><pre class="text2">CONNECT server.example.com:80 HTTP/1.1 1509 1548 Host: server.example.com:80 1510 1549 Proxy-Authorization: basic aGVsbG86d29ybGQ= … … 1550 1589 <p id="rfc.section.7.1.1.p.1">The client <em class="bcp14">SHOULD</em> continue with its request. This interim response is used to inform the client that the initial part of the request has been 1551 1590 received and has not yet been rejected by the server. The client <em class="bcp14">SHOULD</em> continue by sending the remainder of the request or, if the request has already been completed, ignore this response. The 1552 server <em class="bcp14">MUST</em> send a final response after the request has been completed. See <a href="p1-messaging.html#use.of.the.100.status" title="Use of the 100 (Continue) Status">Section 7.2.3</a> of <a href="#Part1" id="rfc.xref.Part1. 25"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for detailed discussion of the use and handling of this status code.1591 server <em class="bcp14">MUST</em> send a final response after the request has been completed. See <a href="p1-messaging.html#use.of.the.100.status" title="Use of the 100 (Continue) Status">Section 7.2.3</a> of <a href="#Part1" id="rfc.xref.Part1.31"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for detailed discussion of the use and handling of this status code. 1553 1592 </p> 1554 1593 <div id="rfc.iref.23"></div> 1555 1594 <div id="rfc.iref.s.3"></div> 1556 1595 <h3 id="rfc.section.7.1.2"><a href="#rfc.section.7.1.2">7.1.2</a> <a id="status.101" href="#status.101">101 Switching Protocols</a></h3> 1557 <p id="rfc.section.7.1.2.p.1">The server understands and is willing to comply with the client's request, via the Upgrade message header field (<a href="p1-messaging.html#header.upgrade" title="Upgrade">Section 9.8</a> of <a href="#Part1" id="rfc.xref.Part1. 26"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>), for a change in the application protocol being used on this connection. The server will switch protocols to those defined1596 <p id="rfc.section.7.1.2.p.1">The server understands and is willing to comply with the client's request, via the Upgrade message header field (<a href="p1-messaging.html#header.upgrade" title="Upgrade">Section 9.8</a> of <a href="#Part1" id="rfc.xref.Part1.32"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>), for a change in the application protocol being used on this connection. The server will switch protocols to those defined 1558 1597 by the response's Upgrade header field immediately after the empty line which terminates the 101 response. 1559 1598 </p> … … 1578 1617 <dd>a representation containing the request message as received by the end server.</dd> 1579 1618 </dl> 1580 <p id="rfc.section.7.2.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 2.3.1.1</a> of <a href="#Part6" id="rfc.xref.Part6.1 0"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) to determine freshness for 200 responses.1619 <p id="rfc.section.7.2.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 2.3.1.1</a> of <a href="#Part6" id="rfc.xref.Part6.11"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) to determine freshness for 200 responses. 1581 1620 </p> 1582 1621 <div id="rfc.iref.25"></div> … … 1607 1646 <div id="rfc.iref.s.7"></div> 1608 1647 <h3 id="rfc.section.7.2.4"><a href="#rfc.section.7.2.4">7.2.4</a> <a id="status.203" href="#status.203">203 Non-Authoritative Information</a></h3> 1609 <p id="rfc.section.7.2.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.4</a> of <a href="#Part1" id="rfc.xref.Part1. 27"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). Note that the behaviour of transforming intermediaries is controlled by the no-transform Cache-Control directive (<a href="p6-cache.html#header.cache-control" title="Cache-Control">Section 3.2</a> of <a href="#Part6" id="rfc.xref.Part6.11"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>).1648 <p id="rfc.section.7.2.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.4</a> of <a href="#Part1" id="rfc.xref.Part1.33"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). Note that the behaviour of transforming intermediaries is controlled by the no-transform Cache-Control directive (<a href="p6-cache.html#header.cache-control" title="Cache-Control">Section 3.2</a> of <a href="#Part6" id="rfc.xref.Part6.12"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>). 1610 1649 </p> 1611 1650 <p id="rfc.section.7.2.4.p.2">This status code is only appropriate when the response status code would have been 200 (OK) otherwise. When the status code 1612 before transformation would have been different, the 214 Transformation Applied warn-code (<a href="p6-cache.html#header.warning" title="Warning">Section 3.6</a> of <a href="#Part6" id="rfc.xref.Part6.1 2"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) is appropriate.1613 </p> 1614 <p id="rfc.section.7.2.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 2.3.1.1</a> of <a href="#Part6" id="rfc.xref.Part6.1 3"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) to determine freshness for 203 responses.1651 before transformation would have been different, the 214 Transformation Applied warn-code (<a href="p6-cache.html#header.warning" title="Warning">Section 3.6</a> of <a href="#Part6" id="rfc.xref.Part6.13"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) is appropriate. 1652 </p> 1653 <p id="rfc.section.7.2.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 2.3.1.1</a> of <a href="#Part6" id="rfc.xref.Part6.14"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) to determine freshness for 203 responses. 1615 1654 </p> 1616 1655 <div id="rfc.iref.28"></div> … … 1642 1681 another input action. 1643 1682 </p> 1644 <p id="rfc.section.7.2.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. 28"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>.1683 <p id="rfc.section.7.2.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.34"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. 1645 1684 </p> 1646 1685 <div id="rfc.iref.30"></div> … … 1650 1689 defined in <a href="p5-range.html#status.206" title="206 Partial Content">Section 3.1</a> of <a href="#Part5" id="rfc.xref.Part5.8"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>. 1651 1690 </p> 1652 <p id="rfc.section.7.2.7.p.2">Caches <em class="bcp14">MAY</em> use a heuristic (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 2.3.1.1</a> of <a href="#Part6" id="rfc.xref.Part6.1 4"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) to determine freshness for 206 responses.1691 <p id="rfc.section.7.2.7.p.2">Caches <em class="bcp14">MAY</em> use a heuristic (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 2.3.1.1</a> of <a href="#Part6" id="rfc.xref.Part6.15"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) to determine freshness for 206 responses. 1653 1692 </p> 1654 1693 <h2 id="rfc.section.7.3"><a href="#rfc.section.7.3">7.3</a> <a id="status.3xx" href="#status.3xx">Redirection 3xx</a></h2> … … 1674 1713 <p id="rfc.section.7.3.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 Location field; user agents <em class="bcp14">MAY</em> use the Location field value for automatic redirection. 1675 1714 </p> 1676 <p id="rfc.section.7.3.1.p.4">Caches <em class="bcp14">MAY</em> use a heuristic (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 2.3.1.1</a> of <a href="#Part6" id="rfc.xref.Part6.1 5"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) to determine freshness for 300 responses.1715 <p id="rfc.section.7.3.1.p.4">Caches <em class="bcp14">MAY</em> use a heuristic (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 2.3.1.1</a> of <a href="#Part6" id="rfc.xref.Part6.16"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) to determine freshness for 300 responses. 1677 1716 </p> 1678 1717 <div id="rfc.iref.32"></div> … … 1682 1721 request URI to one or more of the new references returned by the server, where possible. 1683 1722 </p> 1684 <p id="rfc.section.7.3.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 2.3.1.1</a> of <a href="#Part6" id="rfc.xref.Part6.1 6"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) to determine freshness for 301 responses.1723 <p id="rfc.section.7.3.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 2.3.1.1</a> of <a href="#Part6" id="rfc.xref.Part6.17"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) to determine freshness for 301 responses. 1685 1724 </p> 1686 1725 <p id="rfc.section.7.3.2.p.3">The new permanent URI <em class="bcp14">SHOULD</em> be given by the Location field in the response. Unless the request method was HEAD, the representation of the response <em class="bcp14">SHOULD</em> contain a short hypertext note with a hyperlink to the new URI(s). … … 1855 1894 — that is left to the discretion of the server owner. 1856 1895 </p> 1857 <p id="rfc.section.7.4.11.p.3">Caches <em class="bcp14">MAY</em> use a heuristic (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 2.3.1.1</a> of <a href="#Part6" id="rfc.xref.Part6.1 7"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) to determine freshness for 410 responses.1896 <p id="rfc.section.7.4.11.p.3">Caches <em class="bcp14">MAY</em> use a heuristic (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 2.3.1.1</a> of <a href="#Part6" id="rfc.xref.Part6.18"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) to determine freshness for 410 responses. 1858 1897 </p> 1859 1898 <div id="rfc.iref.50"></div> … … 1906 1945 <div id="rfc.iref.s.37"></div> 1907 1946 <h3 id="rfc.section.7.4.19"><a href="#rfc.section.7.4.19">7.4.19</a> <a id="status.426" href="#status.426">426 Upgrade Required</a></h3> 1908 <p id="rfc.section.7.4.19.p.1">The request can not be completed without a prior protocol upgrade. This response <em class="bcp14">MUST</em> include an Upgrade header field (<a href="p1-messaging.html#header.upgrade" title="Upgrade">Section 9.8</a> of <a href="#Part1" id="rfc.xref.Part1. 29"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) specifying the required protocols.1909 </p> 1910 <div id="rfc.figure.u. 7"></div>1947 <p id="rfc.section.7.4.19.p.1">The request can not be completed without a prior protocol upgrade. This response <em class="bcp14">MUST</em> include an Upgrade header field (<a href="p1-messaging.html#header.upgrade" title="Upgrade">Section 9.8</a> of <a href="#Part1" id="rfc.xref.Part1.35"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) specifying the required protocols. 1948 </p> 1949 <div id="rfc.figure.u.8"></div> 1911 1950 <p>Example:</p> <pre class="text2">HTTP/1.1 426 Upgrade Required 1912 1951 Upgrade: HTTP/2.0 … … 1966 2005 <p id="rfc.section.7.5.6.p.1">The server does not support, or refuses to support, the protocol version that was used in the request message. The server 1967 2006 is indicating that it is unable or unwilling to complete the request using the same major version as the client, as described 1968 in <a href="p1-messaging.html#http.version" title="Protocol Versioning">Section 2.6</a> of <a href="#Part1" id="rfc.xref.Part1.3 0"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[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.2007 in <a href="p1-messaging.html#http.version" title="Protocol Versioning">Section 2.6</a> of <a href="#Part1" id="rfc.xref.Part1.36"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[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. 1969 2008 </p> 1970 2009 <h1 id="rfc.section.8"><a href="#rfc.section.8">8.</a> <a id="header.field.definitions" href="#header.field.definitions">Header Field Definitions</a></h1> … … 1976 2015 is strictly to inform the recipient of valid request methods associated with the resource. 1977 2016 </p> 1978 <div id="rfc.figure.u. 8"></div><pre class="inline"><span id="rfc.iref.g.6"></span> <a href="#header.allow" class="smpl">Allow</a> = #<a href="#method" class="smpl">Method</a>2017 <div id="rfc.figure.u.9"></div><pre class="inline"><span id="rfc.iref.g.6"></span> <a href="#header.allow" class="smpl">Allow</a> = #<a href="#method" class="smpl">Method</a> 1979 2018 </pre><p id="rfc.section.8.1.p.3">Example of use:</p> 1980 <div id="rfc.figure.u. 9"></div><pre class="text"> Allow: GET, HEAD, PUT2019 <div id="rfc.figure.u.10"></div><pre class="text"> Allow: GET, HEAD, PUT 1981 2020 </pre><p id="rfc.section.8.1.p.5">The actual set of allowed methods is defined by the origin server at the time of each request.</p> 1982 2021 <p id="rfc.section.8.1.p.6">A proxy <em class="bcp14">MUST NOT</em> modify the Allow header field — it does not need to understand all the methods specified in order to handle them according … … 1987 2026 <h2 id="rfc.section.8.2"><a href="#rfc.section.8.2">8.2</a> <a id="header.expect" href="#header.expect">Expect</a></h2> 1988 2027 <p id="rfc.section.8.2.p.1">The "Expect" header field is used to indicate that particular server behaviors are required by the client.</p> 1989 <div id="rfc.figure.u.1 0"></div><pre class="inline"><span id="rfc.iref.g.7"></span><span id="rfc.iref.g.8"></span><span id="rfc.iref.g.9"></span><span id="rfc.iref.g.10"></span> <a href="#header.expect" class="smpl">Expect</a> = 1#<a href="#header.expect" class="smpl">expectation</a>2028 <div id="rfc.figure.u.11"></div><pre class="inline"><span id="rfc.iref.g.7"></span><span id="rfc.iref.g.8"></span><span id="rfc.iref.g.9"></span><span id="rfc.iref.g.10"></span> <a href="#header.expect" class="smpl">Expect</a> = 1#<a href="#header.expect" class="smpl">expectation</a> 1990 2029 1991 2030 <a href="#header.expect" class="smpl">expectation</a> = "100-continue" / <a href="#header.expect" class="smpl">expectation-extension</a> … … 2006 2045 </p> 2007 2046 <p id="rfc.section.8.2.p.7">Many older HTTP/1.0 and HTTP/1.1 applications do not understand the Expect header field.</p> 2008 <p id="rfc.section.8.2.p.8">See <a href="p1-messaging.html#use.of.the.100.status" title="Use of the 100 (Continue) Status">Section 7.2.3</a> of <a href="#Part1" id="rfc.xref.Part1.3 1"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for the use of the 100 (Continue) status code.2047 <p id="rfc.section.8.2.p.8">See <a href="p1-messaging.html#use.of.the.100.status" title="Use of the 100 (Continue) Status">Section 7.2.3</a> of <a href="#Part1" id="rfc.xref.Part1.37"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for the use of the 100 (Continue) status code. 2009 2048 </p> 2010 2049 <div id="rfc.iref.f.1"></div> … … 2013 2052 <p id="rfc.section.8.3.p.1">The "From" header field, if given, <em class="bcp14">SHOULD</em> contain an Internet e-mail address for the human user who controls the requesting user agent. The address <em class="bcp14">SHOULD</em> be machine-usable, as defined by "mailbox" in <a href="http://tools.ietf.org/html/rfc5322#section-3.4">Section 3.4</a> of <a href="#RFC5322" id="rfc.xref.RFC5322.1"><cite title="Internet Message Format">[RFC5322]</cite></a>: 2014 2053 </p> 2015 <div id="rfc.figure.u.1 1"></div><pre class="inline"><span id="rfc.iref.g.11"></span> <a href="#header.from" class="smpl">From</a> = <a href="#header.from" class="smpl">mailbox</a>2054 <div id="rfc.figure.u.12"></div><pre class="inline"><span id="rfc.iref.g.11"></span> <a href="#header.from" class="smpl">From</a> = <a href="#header.from" class="smpl">mailbox</a> 2016 2055 2017 2056 <a href="#header.from" class="smpl">mailbox</a> = <mailbox, defined in <a href="#RFC5322" id="rfc.xref.RFC5322.2"><cite title="Internet Message Format">[RFC5322]</cite></a>, <a href="http://tools.ietf.org/html/rfc5322#section-3.4">Section 3.4</a>> 2018 2057 </pre><p id="rfc.section.8.3.p.3">An example is:</p> 2019 <div id="rfc.figure.u.1 2"></div><pre class="text"> From: webmaster@example.org2058 <div id="rfc.figure.u.13"></div><pre class="text"> From: webmaster@example.org 2020 2059 </pre><p id="rfc.section.8.3.p.5">This header field <em class="bcp14">MAY</em> be used for logging purposes and as a means for identifying the source of invalid or unwanted requests. It <em class="bcp14">SHOULD NOT</em> be used as an insecure form of access protection. The interpretation of this field is that the request is being performed 2021 2060 on behalf of the person given, who accepts responsibility for the method performed. In particular, robot agents <em class="bcp14">SHOULD</em> include this header field so that the person responsible for running the robot can be contacted if problems occur on the receiving … … 2040 2079 <p id="rfc.section.8.4.p.3">The field value consists of a single URI-reference. When it has the form of a relative reference (<a href="#RFC3986" id="rfc.xref.RFC3986.1"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-4.2">Section 4.2</a>), the final value is computed by resolving it against the effective request URI (<a href="#RFC3986" id="rfc.xref.RFC3986.2"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-5">Section 5</a>). 2041 2080 </p> 2042 <div id="rfc.figure.u.1 3"></div><pre class="inline"><span id="rfc.iref.g.12"></span> <a href="#header.location" class="smpl">Location</a> = <a href="#abnf.dependencies" class="smpl">URI-reference</a>2043 </pre><div id="rfc.figure.u.1 4"></div>2081 <div id="rfc.figure.u.14"></div><pre class="inline"><span id="rfc.iref.g.12"></span> <a href="#header.location" class="smpl">Location</a> = <a href="#abnf.dependencies" class="smpl">URI-reference</a> 2082 </pre><div id="rfc.figure.u.15"></div> 2044 2083 <p>Examples are:</p> <pre class="text"> Location: http://www.example.org/pub/WWW/People.html#tim 2045 </pre><div id="rfc.figure.u.1 5"></div><pre class="text"> Location: /index.html2084 </pre><div id="rfc.figure.u.16"></div><pre class="text"> Location: /index.html 2046 2085 </pre><p id="rfc.section.8.4.p.7">There are circumstances in which a fragment identifier in a Location URI would not be appropriate. For instance, when it appears 2047 2086 in a 201 Created response, where the Location header field specifies the URI for the entire created resource. … … 2064 2103 to trace a request which appears to be failing or looping in mid-chain. 2065 2104 </p> 2066 <div id="rfc.figure.u.1 6"></div><pre class="inline"><span id="rfc.iref.g.13"></span> <a href="#header.max-forwards" class="smpl">Max-Forwards</a> = 1*<a href="#notation" class="smpl">DIGIT</a>2105 <div id="rfc.figure.u.17"></div><pre class="inline"><span id="rfc.iref.g.13"></span> <a href="#header.max-forwards" class="smpl">Max-Forwards</a> = 1*<a href="#notation" class="smpl">DIGIT</a> 2067 2106 </pre><p id="rfc.section.8.5.p.3">The Max-Forwards value is a decimal integer indicating the remaining number of times this request message can be forwarded.</p> 2068 2107 <p id="rfc.section.8.5.p.4">Each recipient of a TRACE or OPTIONS request containing a Max-Forwards header field <em class="bcp14">MUST</em> check and update its value prior to forwarding the request. If the received value is zero (0), the recipient <em class="bcp14">MUST NOT</em> forward the request; instead, it <em class="bcp14">MUST</em> respond as the final recipient. If the received Max-Forwards value is greater than zero, then the forwarded message <em class="bcp14">MUST</em> contain an updated Max-Forwards field with a value decremented by one (1). … … 2084 2123 non-HTTP URIs (e.g., FTP). 2085 2124 </p> 2086 <div id="rfc.figure.u.1 7"></div><pre class="inline"><span id="rfc.iref.g.14"></span> <a href="#header.referer" class="smpl">Referer</a> = <a href="#abnf.dependencies" class="smpl">absolute-URI</a> / <a href="#abnf.dependencies" class="smpl">partial-URI</a>2125 <div id="rfc.figure.u.18"></div><pre class="inline"><span id="rfc.iref.g.14"></span> <a href="#header.referer" class="smpl">Referer</a> = <a href="#abnf.dependencies" class="smpl">absolute-URI</a> / <a href="#abnf.dependencies" class="smpl">partial-URI</a> 2087 2126 </pre><p id="rfc.section.8.6.p.5">Example:</p> 2088 <div id="rfc.figure.u.1 8"></div><pre class="text"> Referer: http://www.example.org/hypertext/Overview.html2127 <div id="rfc.figure.u.19"></div><pre class="text"> Referer: http://www.example.org/hypertext/Overview.html 2089 2128 </pre><p id="rfc.section.8.6.p.7">If the field value is a relative URI, it <em class="bcp14">SHOULD</em> be interpreted relative to the effective request URI. The URI <em class="bcp14">MUST NOT</em> include a fragment. See <a href="#encoding.sensitive.information.in.uris" title="Encoding Sensitive Information in URIs">Section 10.2</a> for security considerations. 2090 2129 </p> … … 2097 2136 </p> 2098 2137 <p id="rfc.section.8.7.p.2">The value of this field can be either an HTTP-date or an integer number of seconds (in decimal) after the time of the response.</p> 2099 <div id="rfc.figure.u. 19"></div><pre class="inline"><span id="rfc.iref.g.15"></span> <a href="#header.retry-after" class="smpl">Retry-After</a> = <a href="#abnf.dependencies" class="smpl">HTTP-date</a> / <a href="#rule.delta-seconds" class="smpl">delta-seconds</a>2138 <div id="rfc.figure.u.20"></div><pre class="inline"><span id="rfc.iref.g.15"></span> <a href="#header.retry-after" class="smpl">Retry-After</a> = <a href="#abnf.dependencies" class="smpl">HTTP-date</a> / <a href="#rule.delta-seconds" class="smpl">delta-seconds</a> 2100 2139 </pre><div id="rule.delta-seconds"> 2101 2140 <p id="rfc.section.8.7.p.4"> Time spans are non-negative decimal integers, representing time in seconds.</p> 2102 2141 </div> 2103 <div id="rfc.figure.u.2 0"></div><pre class="inline"><span id="rfc.iref.g.16"></span> <a href="#rule.delta-seconds" class="smpl">delta-seconds</a> = 1*<a href="#notation" class="smpl">DIGIT</a>2142 <div id="rfc.figure.u.21"></div><pre class="inline"><span id="rfc.iref.g.16"></span> <a href="#rule.delta-seconds" class="smpl">delta-seconds</a> = 1*<a href="#notation" class="smpl">DIGIT</a> 2104 2143 </pre><p id="rfc.section.8.7.p.6">Two examples of its use are</p> 2105 <div id="rfc.figure.u.2 1"></div><pre class="text"> Retry-After: Fri, 31 Dec 1999 23:59:59 GMT2144 <div id="rfc.figure.u.22"></div><pre class="text"> Retry-After: Fri, 31 Dec 1999 23:59:59 GMT 2106 2145 Retry-After: 120 2107 2146 </pre><p id="rfc.section.8.7.p.8">In the latter example, the delay is 2 minutes.</p> … … 2110 2149 <h2 id="rfc.section.8.8"><a href="#rfc.section.8.8">8.8</a> <a id="header.server" href="#header.server">Server</a></h2> 2111 2150 <p id="rfc.section.8.8.p.1">The "Server" header field contains information about the software used by the origin server to handle the request.</p> 2112 <p id="rfc.section.8.8.p.2">The field can contain multiple product tokens (<a href="p1-messaging.html#product.tokens" title="Product Tokens">Section 6.3</a> of <a href="#Part1" id="rfc.xref.Part1.3 2"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></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.33"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) identifying the server and any significant subproducts. The product tokens are listed in order of their significance for2151 <p id="rfc.section.8.8.p.2">The field can contain multiple product tokens (<a href="p1-messaging.html#product.tokens" title="Product Tokens">Section 6.3</a> of <a href="#Part1" id="rfc.xref.Part1.38"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></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.39"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) identifying the server and any significant subproducts. The product tokens are listed in order of their significance for 2113 2152 identifying the application. 2114 2153 </p> 2115 <div id="rfc.figure.u.2 2"></div><pre class="inline"><span id="rfc.iref.g.17"></span> <a href="#header.server" class="smpl">Server</a> = <a href="#abnf.dependencies" class="smpl">product</a> *( <a href="#core.rules" class="smpl">RWS</a> ( <a href="#abnf.dependencies" class="smpl">product</a> / <a href="#abnf.dependencies" class="smpl">comment</a> ) )2154 <div id="rfc.figure.u.23"></div><pre class="inline"><span id="rfc.iref.g.17"></span> <a href="#header.server" class="smpl">Server</a> = <a href="#abnf.dependencies" class="smpl">product</a> *( <a href="#core.rules" class="smpl">RWS</a> ( <a href="#abnf.dependencies" class="smpl">product</a> / <a href="#abnf.dependencies" class="smpl">comment</a> ) ) 2116 2155 </pre><p id="rfc.section.8.8.p.4">Example:</p> 2117 <div id="rfc.figure.u.2 3"></div><pre class="text"> Server: CERN/3.0 libwww/2.172118 </pre><p id="rfc.section.8.8.p.6">If the response is being forwarded through a proxy, the proxy application <em class="bcp14">MUST NOT</em> modify the Server header field. Instead, it <em class="bcp14">MUST</em> include a Via field (as described in <a href="p1-messaging.html#header.via" title="Via">Section 9.9</a> of <a href="#Part1" id="rfc.xref.Part1. 34"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).2156 <div id="rfc.figure.u.24"></div><pre class="text"> Server: CERN/3.0 libwww/2.17 2157 </pre><p id="rfc.section.8.8.p.6">If the response is being forwarded through a proxy, the proxy application <em class="bcp14">MUST NOT</em> modify the Server header field. Instead, it <em class="bcp14">MUST</em> include a Via field (as described in <a href="p1-messaging.html#header.via" title="Via">Section 9.9</a> of <a href="#Part1" id="rfc.xref.Part1.40"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). 2119 2158 </p> 2120 2159 <div class="note" id="rfc.section.8.8.p.7"> … … 2132 2171 user agent limitations. 2133 2172 </p> 2134 <p id="rfc.section.8.9.p.3">The field can contain multiple product tokens (<a href="p1-messaging.html#product.tokens" title="Product Tokens">Section 6.3</a> of <a href="#Part1" id="rfc.xref.Part1. 35"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></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.36"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) identifying the agent and its significant subproducts. By convention, the product tokens are listed in order of their significance2173 <p id="rfc.section.8.9.p.3">The field can contain multiple product tokens (<a href="p1-messaging.html#product.tokens" title="Product Tokens">Section 6.3</a> of <a href="#Part1" id="rfc.xref.Part1.41"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></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.42"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) identifying the agent and its significant subproducts. By convention, the product tokens are listed in order of their significance 2135 2174 for identifying the application. 2136 2175 </p> … … 2143 2182 doing so makes the field value more difficult to parse. 2144 2183 </p> 2145 <div id="rfc.figure.u.2 4"></div><pre class="inline"><span id="rfc.iref.g.18"></span> <a href="#header.user-agent" class="smpl">User-Agent</a> = <a href="#abnf.dependencies" class="smpl">product</a> *( <a href="#core.rules" class="smpl">RWS</a> ( <a href="#abnf.dependencies" class="smpl">product</a> / <a href="#abnf.dependencies" class="smpl">comment</a> ) )2184 <div id="rfc.figure.u.25"></div><pre class="inline"><span id="rfc.iref.g.18"></span> <a href="#header.user-agent" class="smpl">User-Agent</a> = <a href="#abnf.dependencies" class="smpl">product</a> *( <a href="#core.rules" class="smpl">RWS</a> ( <a href="#abnf.dependencies" class="smpl">product</a> / <a href="#abnf.dependencies" class="smpl">comment</a> ) ) 2146 2185 </pre><p id="rfc.section.8.9.p.7">Example:</p> 2147 <div id="rfc.figure.u.2 5"></div><pre class="text"> User-Agent: CERN-LineMode/2.15 libwww/2.17b32186 <div id="rfc.figure.u.26"></div><pre class="text"> User-Agent: CERN-LineMode/2.15 libwww/2.17b3 2148 2187 </pre><h1 id="rfc.section.9"><a href="#rfc.section.9">9.</a> <a id="IANA.considerations" href="#IANA.considerations">IANA Considerations</a></h1> 2149 2188 <h2 id="rfc.section.9.1"><a href="#rfc.section.9.1">9.1</a> <a id="method.registration" href="#method.registration">Method Registry</a></h2> … … 2456 2495 </div> 2457 2496 <h2 id="rfc.section.9.3"><a href="#rfc.section.9.3">9.3</a> <a id="header.field.registration" href="#header.field.registration">Header Field Registration</a></h2> 2458 <p id="rfc.section.9.3.p.1">The Message Header Field Registry located at <<a href="http://www.iana.org/assignments/message-headers/message-header-index.html">http://www.iana.org/assignments/message-headers/message-header-index.html</a>> shall be updated with the permanent registrations below (see <a href="#RFC3864" id="rfc.xref.RFC3864. 1"><cite title="Registration Procedures for Message Header Fields">[RFC3864]</cite></a>):2497 <p id="rfc.section.9.3.p.1">The Message Header Field Registry located at <<a href="http://www.iana.org/assignments/message-headers/message-header-index.html">http://www.iana.org/assignments/message-headers/message-header-index.html</a>> shall be updated with the permanent registrations below (see <a href="#RFC3864" id="rfc.xref.RFC3864.3"><cite title="Registration Procedures for Message Header Fields">[RFC3864]</cite></a>): 2459 2498 </p> 2460 2499 <div id="rfc.table.3"> … … 2597 2636 </p> 2598 2637 <h1 id="rfc.section.11"><a href="#rfc.section.11">11.</a> <a id="acks" href="#acks">Acknowledgments</a></h1> 2599 <p id="rfc.section.11.p.1">See <a href="p1-messaging.html#acks" title="Acknowledgments">Section 12</a> of <a href="#Part1" id="rfc.xref.Part1. 37"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>.2638 <p id="rfc.section.11.p.1">See <a href="p1-messaging.html#acks" title="Acknowledgments">Section 12</a> of <a href="#Part1" id="rfc.xref.Part1.43"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. 2600 2639 </p> 2601 2640 <h1 id="rfc.references"><a id="rfc.section.12" href="#rfc.section.12">12.</a> References … … 2652 2691 <h2 id="rfc.references.2"><a href="#rfc.section.12.2" id="rfc.section.12.2">12.2</a> Informative References 2653 2692 </h2> 2654 <table> 2693 <table> 2655 2694 <tr> 2656 2695 <td class="reference"><b id="RFC1945">[RFC1945]</b></td> … … 2693 2732 </td> 2694 2733 </tr> 2734 <tr> 2735 <td class="reference"><b id="RFC5987">[RFC5987]</b></td> 2736 <td class="top"><a href="mailto:julian.reschke@greenbytes.de" title="greenbytes GmbH">Reschke, J.</a>, “<a href="http://tools.ietf.org/html/rfc5987">Character Set and Language Encoding for Hypertext Transfer Protocol (HTTP) Header Field Parameters</a>”, RFC 5987, August 2010. 2737 </td> 2738 </tr> 2695 2739 </table> 2696 2740 <div class="avoidbreak"> … … 2746 2790 </p> 2747 2791 <p id="rfc.section.A.p.14">In the description of the Server header field, the Via field was described as a SHOULD. The requirement was and is stated 2748 correctly in the description of the Via header field in <a href="p1-messaging.html#header.via" title="Via">Section 9.9</a> of <a href="#Part1" id="rfc.xref.Part1. 38"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. (<a href="#header.server" id="rfc.xref.header.server.4" title="Server">Section 8.8</a>)2792 correctly in the description of the Via header field in <a href="p1-messaging.html#header.via" title="Via">Section 9.9</a> of <a href="#Part1" id="rfc.xref.Part1.44"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. (<a href="#header.server" id="rfc.xref.header.server.4" title="Server">Section 8.8</a>) 2749 2793 </p> 2750 2794 <h1 id="rfc.section.B"><a href="#rfc.section.B">B.</a> <a id="collected.abnf" href="#collected.abnf">Collected ABNF</a></h1> 2751 <div id="rfc.figure.u.2 6"></div> <pre class="inline"><a href="#header.allow" class="smpl">Allow</a> = [ ( "," / Method ) *( OWS "," [ OWS Method ] ) ]2795 <div id="rfc.figure.u.27"></div> <pre class="inline"><a href="#header.allow" class="smpl">Allow</a> = [ ( "," / Method ) *( OWS "," [ OWS Method ] ) ] 2752 2796 2753 2797 <a href="#header.expect" class="smpl">Expect</a> = *( "," OWS ) expectation *( OWS "," [ OWS expectation ] ) … … 2796 2840 2797 2841 <a href="#core.rules" class="smpl">token</a> = <token, defined in [Part1], Section 3.2.3> 2798 </pre> <div id="rfc.figure.u.2 7"></div>2842 </pre> <div id="rfc.figure.u.28"></div> 2799 2843 <p>ABNF diagnostics:</p><pre class="inline">; Allow defined but not used 2800 2844 ; Expect defined but not used … … 3076 3120 </ul> 3077 3121 <h2 id="rfc.section.C.18"><a href="#rfc.section.C.18">C.18</a> <a id="changes.since.16" href="#changes.since.16">Since draft-ietf-httpbis-p2-semantics-16</a></h2> 3078 <p id="rfc.section.C.18.p.1">None yet.</p> 3122 <p id="rfc.section.C.18.p.1">Work-in-progress: </p> 3123 <ul> 3124 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/231">http://tools.ietf.org/wg/httpbis/trac/ticket/231</a>>: "Considerations for new headers" 3125 </li> 3126 </ul> 3079 3127 <h1 id="rfc.index"><a href="#rfc.index">Index</a></h1> 3080 3128 <p class="noprint"><a href="#rfc.index.1">1</a> <a href="#rfc.index.2">2</a> <a href="#rfc.index.3">3</a> <a href="#rfc.index.4">4</a> <a href="#rfc.index.5">5</a> <a href="#rfc.index.A">A</a> <a href="#rfc.index.C">C</a> <a href="#rfc.index.D">D</a> <a href="#rfc.index.E">E</a> <a href="#rfc.index.F">F</a> <a href="#rfc.index.G">G</a> <a href="#rfc.index.H">H</a> <a href="#rfc.index.I">I</a> <a href="#rfc.index.L">L</a> <a href="#rfc.index.M">M</a> <a href="#rfc.index.O">O</a> <a href="#rfc.index.P">P</a> <a href="#rfc.index.R">R</a> <a href="#rfc.index.S">S</a> <a href="#rfc.index.T">T</a> <a href="#rfc.index.U">U</a> … … 3140 3188 </li> 3141 3189 <li><a id="rfc.index.A" href="#rfc.index.A"><b>A</b></a><ul> 3142 <li>Allow header field <a href="#rfc.xref.header.allow.1">2</a>, <a href="#rfc.xref.header.allow.2">3. 2</a>, <a href="#rfc.iref.a.1"><b>8.1</b></a>, <a href="#rfc.xref.header.allow.3">9.3</a>, <a href="#rfc.xref.header.allow.4">A</a></li>3190 <li>Allow header field <a href="#rfc.xref.header.allow.1">2</a>, <a href="#rfc.xref.header.allow.2">3.3</a>, <a href="#rfc.iref.a.1"><b>8.1</b></a>, <a href="#rfc.xref.header.allow.3">9.3</a>, <a href="#rfc.xref.header.allow.4">A</a></li> 3143 3191 </ul> 3144 3192 </li> … … 3152 3200 </li> 3153 3201 <li><a id="rfc.index.E" href="#rfc.index.E"><b>E</b></a><ul> 3154 <li>Expect header field <a href="#rfc.xref.header.expect.1">3. 1</a>, <a href="#rfc.xref.header.expect.2">7.4.18</a>, <a href="#rfc.iref.e.1"><b>8.2</b></a>, <a href="#rfc.xref.header.expect.3">9.3</a></li>3202 <li>Expect header field <a href="#rfc.xref.header.expect.1">3.2</a>, <a href="#rfc.xref.header.expect.2">7.4.18</a>, <a href="#rfc.iref.e.1"><b>8.2</b></a>, <a href="#rfc.xref.header.expect.3">9.3</a></li> 3155 3203 </ul> 3156 3204 </li> 3157 3205 <li><a id="rfc.index.F" href="#rfc.index.F"><b>F</b></a><ul> 3158 <li>From header field <a href="#rfc.xref.header.from.1">3. 1</a>, <a href="#rfc.iref.f.1"><b>8.3</b></a>, <a href="#rfc.xref.header.from.2">9.3</a></li>3206 <li>From header field <a href="#rfc.xref.header.from.1">3.2</a>, <a href="#rfc.iref.f.1"><b>8.3</b></a>, <a href="#rfc.xref.header.from.2">9.3</a></li> 3159 3207 </ul> 3160 3208 </li> … … 3188 3236 <li>Header Fields 3189 3237 <ul> 3190 <li>Allow <a href="#rfc.xref.header.allow.1">2</a>, <a href="#rfc.xref.header.allow.2">3. 2</a>, <a href="#rfc.iref.h.2"><b>8.1</b></a>, <a href="#rfc.xref.header.allow.3">9.3</a>, <a href="#rfc.xref.header.allow.4">A</a></li>3191 <li>Expect <a href="#rfc.xref.header.expect.1">3. 1</a>, <a href="#rfc.xref.header.expect.2">7.4.18</a>, <a href="#rfc.iref.h.3"><b>8.2</b></a>, <a href="#rfc.xref.header.expect.3">9.3</a></li>3192 <li>From <a href="#rfc.xref.header.from.1">3. 1</a>, <a href="#rfc.iref.h.4"><b>8.3</b></a>, <a href="#rfc.xref.header.from.2">9.3</a></li>3193 <li>Location <a href="#rfc.xref.header.location.1">3. 2</a>, <a href="#rfc.xref.header.location.2">6.5</a>, <a href="#rfc.iref.h.5"><b>8.4</b></a>, <a href="#rfc.xref.header.location.3">9.3</a>, <a href="#rfc.xref.header.location.4">A</a></li>3194 <li>Max-Forwards <a href="#rfc.xref.header.max-forwards.1">3. 1</a>, <a href="#rfc.xref.header.max-forwards.2">6.2</a>, <a href="#rfc.xref.header.max-forwards.3">6.8</a>, <a href="#rfc.iref.h.6"><b>8.5</b></a>, <a href="#rfc.xref.header.max-forwards.4">9.3</a>, <a href="#rfc.xref.header.max-forwards.5">A</a></li>3195 <li>Referer <a href="#rfc.xref.header.referer.1">3. 1</a>, <a href="#rfc.iref.h.7"><b>8.6</b></a>, <a href="#rfc.xref.header.referer.2">9.3</a>, <a href="#rfc.xref.header.referer.3">A</a></li>3196 <li>Retry-After <a href="#rfc.xref.header.retry-after.1">3. 2</a>, <a href="#rfc.xref.header.retry-after.2">7.5.4</a>, <a href="#rfc.iref.h.8"><b>8.7</b></a>, <a href="#rfc.xref.header.retry-after.3">9.3</a></li>3197 <li>Server <a href="#rfc.xref.header.server.1">3. 2</a>, <a href="#rfc.iref.h.9"><b>8.8</b></a>, <a href="#rfc.xref.header.server.2">9.3</a>, <a href="#rfc.xref.header.server.3">10.1</a>, <a href="#rfc.xref.header.server.4">A</a></li>3198 <li>User-Agent <a href="#rfc.xref.header.user-agent.1">3. 1</a>, <a href="#rfc.iref.h.10"><b>8.9</b></a>, <a href="#rfc.xref.header.user-agent.2">9.3</a>, <a href="#rfc.xref.header.user-agent.3">10.1</a></li>3238 <li>Allow <a href="#rfc.xref.header.allow.1">2</a>, <a href="#rfc.xref.header.allow.2">3.3</a>, <a href="#rfc.iref.h.2"><b>8.1</b></a>, <a href="#rfc.xref.header.allow.3">9.3</a>, <a href="#rfc.xref.header.allow.4">A</a></li> 3239 <li>Expect <a href="#rfc.xref.header.expect.1">3.2</a>, <a href="#rfc.xref.header.expect.2">7.4.18</a>, <a href="#rfc.iref.h.3"><b>8.2</b></a>, <a href="#rfc.xref.header.expect.3">9.3</a></li> 3240 <li>From <a href="#rfc.xref.header.from.1">3.2</a>, <a href="#rfc.iref.h.4"><b>8.3</b></a>, <a href="#rfc.xref.header.from.2">9.3</a></li> 3241 <li>Location <a href="#rfc.xref.header.location.1">3.3</a>, <a href="#rfc.xref.header.location.2">6.5</a>, <a href="#rfc.iref.h.5"><b>8.4</b></a>, <a href="#rfc.xref.header.location.3">9.3</a>, <a href="#rfc.xref.header.location.4">A</a></li> 3242 <li>Max-Forwards <a href="#rfc.xref.header.max-forwards.1">3.2</a>, <a href="#rfc.xref.header.max-forwards.2">6.2</a>, <a href="#rfc.xref.header.max-forwards.3">6.8</a>, <a href="#rfc.iref.h.6"><b>8.5</b></a>, <a href="#rfc.xref.header.max-forwards.4">9.3</a>, <a href="#rfc.xref.header.max-forwards.5">A</a></li> 3243 <li>Referer <a href="#rfc.xref.header.referer.1">3.2</a>, <a href="#rfc.iref.h.7"><b>8.6</b></a>, <a href="#rfc.xref.header.referer.2">9.3</a>, <a href="#rfc.xref.header.referer.3">A</a></li> 3244 <li>Retry-After <a href="#rfc.xref.header.retry-after.1">3.3</a>, <a href="#rfc.xref.header.retry-after.2">7.5.4</a>, <a href="#rfc.iref.h.8"><b>8.7</b></a>, <a href="#rfc.xref.header.retry-after.3">9.3</a></li> 3245 <li>Server <a href="#rfc.xref.header.server.1">3.3</a>, <a href="#rfc.iref.h.9"><b>8.8</b></a>, <a href="#rfc.xref.header.server.2">9.3</a>, <a href="#rfc.xref.header.server.3">10.1</a>, <a href="#rfc.xref.header.server.4">A</a></li> 3246 <li>User-Agent <a href="#rfc.xref.header.user-agent.1">3.2</a>, <a href="#rfc.iref.h.10"><b>8.9</b></a>, <a href="#rfc.xref.header.user-agent.2">9.3</a>, <a href="#rfc.xref.header.user-agent.3">10.1</a></li> 3199 3247 </ul> 3200 3248 </li> … … 3206 3254 </li> 3207 3255 <li><a id="rfc.index.L" href="#rfc.index.L"><b>L</b></a><ul> 3208 <li>Location header field <a href="#rfc.xref.header.location.1">3. 2</a>, <a href="#rfc.xref.header.location.2">6.5</a>, <a href="#rfc.iref.l.1"><b>8.4</b></a>, <a href="#rfc.xref.header.location.3">9.3</a>, <a href="#rfc.xref.header.location.4">A</a></li>3256 <li>Location header field <a href="#rfc.xref.header.location.1">3.3</a>, <a href="#rfc.xref.header.location.2">6.5</a>, <a href="#rfc.iref.l.1"><b>8.4</b></a>, <a href="#rfc.xref.header.location.3">9.3</a>, <a href="#rfc.xref.header.location.4">A</a></li> 3209 3257 </ul> 3210 3258 </li> 3211 3259 <li><a id="rfc.index.M" href="#rfc.index.M"><b>M</b></a><ul> 3212 <li>Max-Forwards header field <a href="#rfc.xref.header.max-forwards.1">3. 1</a>, <a href="#rfc.xref.header.max-forwards.2">6.2</a>, <a href="#rfc.xref.header.max-forwards.3">6.8</a>, <a href="#rfc.iref.m.9"><b>8.5</b></a>, <a href="#rfc.xref.header.max-forwards.4">9.3</a>, <a href="#rfc.xref.header.max-forwards.5">A</a></li>3260 <li>Max-Forwards header field <a href="#rfc.xref.header.max-forwards.1">3.2</a>, <a href="#rfc.xref.header.max-forwards.2">6.2</a>, <a href="#rfc.xref.header.max-forwards.3">6.8</a>, <a href="#rfc.iref.m.9"><b>8.5</b></a>, <a href="#rfc.xref.header.max-forwards.4">9.3</a>, <a href="#rfc.xref.header.max-forwards.5">A</a></li> 3213 3261 <li>Methods 3214 3262 <ul> … … 3230 3278 </li> 3231 3279 <li><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul> 3232 <li><em>Part1</em> <a href="#rfc.xref.Part1.1">1</a>, <a href="#rfc.xref.Part1.2">1.2</a>, <a href="#rfc.xref.Part1.3">1.2.1</a>, <a href="#rfc.xref.Part1.4">1.2.1</a>, <a href="#rfc.xref.Part1.5">1.2.1</a>, <a href="#rfc.xref.Part1.6">1.2.1</a>, <a href="#rfc.xref.Part1.7">1.2.1</a>, <a href="#rfc.xref.Part1.8">1.2.1</a>, <a href="#rfc.xref.Part1.9">1.2.2</a>, <a href="#rfc.xref.Part1.10">1.2.2</a>, <a href="#rfc.xref.Part1.11">1.2.2</a>, <a href="#rfc.xref.Part1.12">1.2.2</a>, <a href="#rfc.xref.Part1.13">1.2.2</a>, <a href="#rfc.xref.Part1.14">1.2.2</a>, <a href="#rfc.xref.Part1.15">2</a>, <a href="#rfc.xref.Part1.16">2.2.1</a>, <a href="#rfc.xref.Part1.17">3 .1</a>, <a href="#rfc.xref.Part1.18">3.1</a>, <a href="#rfc.xref.Part1.19">3.2</a>, <a href="#rfc.xref.Part1.20">5</a>, <a href="#rfc.xref.Part1.21">5.1</a>, <a href="#rfc.xref.Part1.22">6.8</a>, <a href="#rfc.xref.Part1.23">6.8</a>, <a href="#rfc.xref.Part1.24">6.9</a>, <a href="#rfc.xref.Part1.25">7.1.1</a>, <a href="#rfc.xref.Part1.26">7.1.2</a>, <a href="#rfc.xref.Part1.27">7.2.4</a>, <a href="#rfc.xref.Part1.28">7.2.6</a>, <a href="#rfc.xref.Part1.29">7.4.19</a>, <a href="#rfc.xref.Part1.30">7.5.6</a>, <a href="#rfc.xref.Part1.31">8.2</a>, <a href="#rfc.xref.Part1.32">8.8</a>, <a href="#rfc.xref.Part1.33">8.8</a>, <a href="#rfc.xref.Part1.34">8.8</a>, <a href="#rfc.xref.Part1.35">8.9</a>, <a href="#rfc.xref.Part1.36">8.9</a>, <a href="#rfc.xref.Part1.37">11</a>, <a href="#Part1"><b>12.1</b></a>, <a href="#rfc.xref.Part1.38">A</a><ul>3280 <li><em>Part1</em> <a href="#rfc.xref.Part1.1">1</a>, <a href="#rfc.xref.Part1.2">1.2</a>, <a href="#rfc.xref.Part1.3">1.2.1</a>, <a href="#rfc.xref.Part1.4">1.2.1</a>, <a href="#rfc.xref.Part1.5">1.2.1</a>, <a href="#rfc.xref.Part1.6">1.2.1</a>, <a href="#rfc.xref.Part1.7">1.2.1</a>, <a href="#rfc.xref.Part1.8">1.2.1</a>, <a href="#rfc.xref.Part1.9">1.2.2</a>, <a href="#rfc.xref.Part1.10">1.2.2</a>, <a href="#rfc.xref.Part1.11">1.2.2</a>, <a href="#rfc.xref.Part1.12">1.2.2</a>, <a href="#rfc.xref.Part1.13">1.2.2</a>, <a href="#rfc.xref.Part1.14">1.2.2</a>, <a href="#rfc.xref.Part1.15">2</a>, <a href="#rfc.xref.Part1.16">2.2.1</a>, <a href="#rfc.xref.Part1.17">3</a>, <a href="#rfc.xref.Part1.18">3.1</a>, <a href="#rfc.xref.Part1.19">3.1</a>, <a href="#rfc.xref.Part1.20">3.1</a>, <a href="#rfc.xref.Part1.21">3.1</a>, <a href="#rfc.xref.Part1.22">3.1</a>, <a href="#rfc.xref.Part1.23">3.2</a>, <a href="#rfc.xref.Part1.24">3.2</a>, <a href="#rfc.xref.Part1.25">3.3</a>, <a href="#rfc.xref.Part1.26">5</a>, <a href="#rfc.xref.Part1.27">5.1</a>, <a href="#rfc.xref.Part1.28">6.8</a>, <a href="#rfc.xref.Part1.29">6.8</a>, <a href="#rfc.xref.Part1.30">6.9</a>, <a href="#rfc.xref.Part1.31">7.1.1</a>, <a href="#rfc.xref.Part1.32">7.1.2</a>, <a href="#rfc.xref.Part1.33">7.2.4</a>, <a href="#rfc.xref.Part1.34">7.2.6</a>, <a href="#rfc.xref.Part1.35">7.4.19</a>, <a href="#rfc.xref.Part1.36">7.5.6</a>, <a href="#rfc.xref.Part1.37">8.2</a>, <a href="#rfc.xref.Part1.38">8.8</a>, <a href="#rfc.xref.Part1.39">8.8</a>, <a href="#rfc.xref.Part1.40">8.8</a>, <a href="#rfc.xref.Part1.41">8.9</a>, <a href="#rfc.xref.Part1.42">8.9</a>, <a href="#rfc.xref.Part1.43">11</a>, <a href="#Part1"><b>12.1</b></a>, <a href="#rfc.xref.Part1.44">A</a><ul> 3233 3281 <li><em>Section 1.2</em> <a href="#rfc.xref.Part1.2">1.2</a></li> 3282 <li><em>Section 1.2.1</em> <a href="#rfc.xref.Part1.18">3.1</a></li> 3234 3283 <li><em>Section 1.2.2</em> <a href="#rfc.xref.Part1.4">1.2.1</a>, <a href="#rfc.xref.Part1.5">1.2.1</a>, <a href="#rfc.xref.Part1.6">1.2.1</a></li> 3235 <li><em>Section 2.4</em> <a href="#rfc.xref.Part1. 27">7.2.4</a></li>3236 <li><em>Section 2.6</em> <a href="#rfc.xref.Part1.3 0">7.5.6</a></li>3284 <li><em>Section 2.4</em> <a href="#rfc.xref.Part1.33">7.2.4</a></li> 3285 <li><em>Section 2.6</em> <a href="#rfc.xref.Part1.36">7.5.6</a></li> 3237 3286 <li><em>Section 2.7</em> <a href="#rfc.xref.Part1.9">1.2.2</a>, <a href="#rfc.xref.Part1.12">1.2.2</a>, <a href="#rfc.xref.Part1.14">1.2.2</a></li> 3238 <li><em>Section 3.2</em> <a href="#rfc.xref.Part1.10">1.2.2</a>, <a href="#rfc.xref.Part1. 33">8.8</a>, <a href="#rfc.xref.Part1.36">8.9</a></li>3239 <li><em>Section 3.2.3</em> <a href="#rfc.xref.Part1.7">1.2.1</a>, <a href="#rfc.xref.Part1.8">1.2.1</a> </li>3240 <li><em>Section 3.3</em> <a href="#rfc.xref.Part1.16">2.2.1</a>, <a href="#rfc.xref.Part1.2 0">5</a>, <a href="#rfc.xref.Part1.28">7.2.6</a></li>3241 <li><em>Section 4.1.2</em> <a href="#rfc.xref.Part1. 24">6.9</a></li>3242 <li><em>Section 4.3</em> <a href="#rfc.xref.Part1.15">2</a>, <a href="#rfc.xref.Part1. 19">3.2</a>, <a href="#rfc.xref.Part1.21">5.1</a></li>3287 <li><em>Section 3.2</em> <a href="#rfc.xref.Part1.10">1.2.2</a>, <a href="#rfc.xref.Part1.17">3</a>, <a href="#rfc.xref.Part1.20">3.1</a>, <a href="#rfc.xref.Part1.39">8.8</a>, <a href="#rfc.xref.Part1.42">8.9</a></li> 3288 <li><em>Section 3.2.3</em> <a href="#rfc.xref.Part1.7">1.2.1</a>, <a href="#rfc.xref.Part1.8">1.2.1</a>, <a href="#rfc.xref.Part1.19">3.1</a></li> 3289 <li><em>Section 3.3</em> <a href="#rfc.xref.Part1.16">2.2.1</a>, <a href="#rfc.xref.Part1.26">5</a>, <a href="#rfc.xref.Part1.34">7.2.6</a></li> 3290 <li><em>Section 4.1.2</em> <a href="#rfc.xref.Part1.30">6.9</a></li> 3291 <li><em>Section 4.3</em> <a href="#rfc.xref.Part1.15">2</a>, <a href="#rfc.xref.Part1.25">3.3</a>, <a href="#rfc.xref.Part1.27">5.1</a></li> 3243 3292 <li><em>Section 6.1</em> <a href="#rfc.xref.Part1.11">1.2.2</a></li> 3244 <li><em>Section 6.3</em> <a href="#rfc.xref.Part1.13">1.2.2</a>, <a href="#rfc.xref.Part1.32">8.8</a>, <a href="#rfc.xref.Part1.35">8.9</a></li> 3245 <li><em>Section 7.2.3</em> <a href="#rfc.xref.Part1.25">7.1.1</a>, <a href="#rfc.xref.Part1.31">8.2</a></li> 3246 <li><em>Section 9.4</em> <a href="#rfc.xref.Part1.17">3.1</a></li> 3247 <li><em>Section 9.5</em> <a href="#rfc.xref.Part1.18">3.1</a></li> 3248 <li><em>Section 9.8</em> <a href="#rfc.xref.Part1.26">7.1.2</a>, <a href="#rfc.xref.Part1.29">7.4.19</a></li> 3249 <li><em>Section 9.9</em> <a href="#rfc.xref.Part1.22">6.8</a>, <a href="#rfc.xref.Part1.34">8.8</a>, <a href="#rfc.xref.Part1.38">A</a></li> 3250 <li><em>Section 10.3.1</em> <a href="#rfc.xref.Part1.23">6.8</a></li> 3251 <li><em>Section 12</em> <a href="#rfc.xref.Part1.37">11</a></li> 3293 <li><em>Section 6.2.1</em> <a href="#rfc.xref.Part1.22">3.1</a></li> 3294 <li><em>Section 6.3</em> <a href="#rfc.xref.Part1.13">1.2.2</a>, <a href="#rfc.xref.Part1.38">8.8</a>, <a href="#rfc.xref.Part1.41">8.9</a></li> 3295 <li><em>Section 7.2.3</em> <a href="#rfc.xref.Part1.31">7.1.1</a>, <a href="#rfc.xref.Part1.37">8.2</a></li> 3296 <li><em>Section 9.1</em> <a href="#rfc.xref.Part1.21">3.1</a></li> 3297 <li><em>Section 9.4</em> <a href="#rfc.xref.Part1.23">3.2</a></li> 3298 <li><em>Section 9.5</em> <a href="#rfc.xref.Part1.24">3.2</a></li> 3299 <li><em>Section 9.8</em> <a href="#rfc.xref.Part1.32">7.1.2</a>, <a href="#rfc.xref.Part1.35">7.4.19</a></li> 3300 <li><em>Section 9.9</em> <a href="#rfc.xref.Part1.28">6.8</a>, <a href="#rfc.xref.Part1.40">8.8</a>, <a href="#rfc.xref.Part1.44">A</a></li> 3301 <li><em>Section 10.3.1</em> <a href="#rfc.xref.Part1.29">6.8</a></li> 3302 <li><em>Section 12</em> <a href="#rfc.xref.Part1.43">11</a></li> 3252 3303 </ul> 3253 3304 </li> 3254 <li><em>Part3</em> <a href="#rfc.xref.Part3.1">3. 1</a>, <a href="#rfc.xref.Part3.2">3.1</a>, <a href="#rfc.xref.Part3.3">3.1</a>, <a href="#rfc.xref.Part3.4">3.1</a>, <a href="#rfc.xref.Part3.5">5</a>, <a href="#rfc.xref.Part3.6">6.5</a>, <a href="#rfc.xref.Part3.7">7.3.1</a>, <a href="#rfc.xref.Part3.8">7.4.7</a>, <a href="#rfc.xref.Part3.9">8.4</a>, <a href="#Part3"><b>12.1</b></a><ul>3305 <li><em>Part3</em> <a href="#rfc.xref.Part3.1">3.2</a>, <a href="#rfc.xref.Part3.2">3.2</a>, <a href="#rfc.xref.Part3.3">3.2</a>, <a href="#rfc.xref.Part3.4">3.2</a>, <a href="#rfc.xref.Part3.5">5</a>, <a href="#rfc.xref.Part3.6">6.5</a>, <a href="#rfc.xref.Part3.7">7.3.1</a>, <a href="#rfc.xref.Part3.8">7.4.7</a>, <a href="#rfc.xref.Part3.9">8.4</a>, <a href="#Part3"><b>12.1</b></a><ul> 3255 3306 <li><em>Section 5</em> <a href="#rfc.xref.Part3.7">7.3.1</a></li> 3256 <li><em>Section 6.1</em> <a href="#rfc.xref.Part3.1">3. 1</a></li>3307 <li><em>Section 6.1</em> <a href="#rfc.xref.Part3.1">3.2</a></li> 3257 3308 <li><em>Section 6</em> <a href="#rfc.xref.Part3.8">7.4.7</a></li> 3258 <li><em>Section 6.2</em> <a href="#rfc.xref.Part3.2">3. 1</a></li>3259 <li><em>Section 6.3</em> <a href="#rfc.xref.Part3.3">3. 1</a></li>3260 <li><em>Section 6.4</em> <a href="#rfc.xref.Part3.4">3. 1</a></li>3309 <li><em>Section 6.2</em> <a href="#rfc.xref.Part3.2">3.2</a></li> 3310 <li><em>Section 6.3</em> <a href="#rfc.xref.Part3.3">3.2</a></li> 3311 <li><em>Section 6.4</em> <a href="#rfc.xref.Part3.4">3.2</a></li> 3261 3312 <li><em>Section 6.7</em> <a href="#rfc.xref.Part3.6">6.5</a>, <a href="#rfc.xref.Part3.9">8.4</a></li> 3262 3313 </ul> 3263 3314 </li> 3264 <li><em>Part4</em> <a href="#rfc.xref.Part4.1">3. 1</a>, <a href="#rfc.xref.Part4.2">3.1</a>, <a href="#rfc.xref.Part4.3">3.1</a>, <a href="#rfc.xref.Part4.4">3.1</a>, <a href="#rfc.xref.Part4.5">3.2</a>, <a href="#rfc.xref.Part4.6">4.1</a>, <a href="#rfc.xref.Part4.7">4.1</a>, <a href="#rfc.xref.Part4.8">4.1</a>, <a href="#rfc.xref.Part4.9">7.2.2</a>, <a href="#rfc.xref.Part4.10">7.3.5</a>, <a href="#rfc.xref.Part4.11">7.4.13</a>, <a href="#Part4"><b>12.1</b></a>, <a href="#rfc.xref.Part4.12">C.2</a><ul>3265 <li><em>Section 2.3</em> <a href="#rfc.xref.Part4.5">3. 2</a>, <a href="#rfc.xref.Part4.9">7.2.2</a></li>3266 <li><em>Section 3.1</em> <a href="#rfc.xref.Part4.1">3. 1</a></li>3267 <li><em>Section 3.2</em> <a href="#rfc.xref.Part4.3">3. 1</a></li>3268 <li><em>Section 3.3</em> <a href="#rfc.xref.Part4.2">3. 1</a></li>3269 <li><em>Section 3.4</em> <a href="#rfc.xref.Part4.4">3. 1</a></li>3315 <li><em>Part4</em> <a href="#rfc.xref.Part4.1">3.2</a>, <a href="#rfc.xref.Part4.2">3.2</a>, <a href="#rfc.xref.Part4.3">3.2</a>, <a href="#rfc.xref.Part4.4">3.2</a>, <a href="#rfc.xref.Part4.5">3.3</a>, <a href="#rfc.xref.Part4.6">4.1</a>, <a href="#rfc.xref.Part4.7">4.1</a>, <a href="#rfc.xref.Part4.8">4.1</a>, <a href="#rfc.xref.Part4.9">7.2.2</a>, <a href="#rfc.xref.Part4.10">7.3.5</a>, <a href="#rfc.xref.Part4.11">7.4.13</a>, <a href="#Part4"><b>12.1</b></a>, <a href="#rfc.xref.Part4.12">C.2</a><ul> 3316 <li><em>Section 2.3</em> <a href="#rfc.xref.Part4.5">3.3</a>, <a href="#rfc.xref.Part4.9">7.2.2</a></li> 3317 <li><em>Section 3.1</em> <a href="#rfc.xref.Part4.1">3.2</a></li> 3318 <li><em>Section 3.2</em> <a href="#rfc.xref.Part4.3">3.2</a></li> 3319 <li><em>Section 3.3</em> <a href="#rfc.xref.Part4.2">3.2</a></li> 3320 <li><em>Section 3.4</em> <a href="#rfc.xref.Part4.4">3.2</a></li> 3270 3321 <li><em>Section 4</em> <a href="#rfc.xref.Part4.6">4.1</a></li> 3271 3322 <li><em>Section 4.1</em> <a href="#rfc.xref.Part4.7">4.1</a>, <a href="#rfc.xref.Part4.10">7.3.5</a></li> … … 3273 3324 </ul> 3274 3325 </li> 3275 <li><em>Part5</em> <a href="#rfc.xref.Part5.1">3. 1</a>, <a href="#rfc.xref.Part5.2">3.1</a>, <a href="#rfc.xref.Part5.3">3.2</a>, <a href="#rfc.xref.Part5.4">4.1</a>, <a href="#rfc.xref.Part5.5">4.1</a>, <a href="#rfc.xref.Part5.6">4.1</a>, <a href="#rfc.xref.Part5.7">6.3</a>, <a href="#rfc.xref.Part5.8">7.2.7</a>, <a href="#rfc.xref.Part5.9">7.4.17</a>, <a href="#rfc.xref.Part5.10">7.4.17</a>, <a href="#Part5"><b>12.1</b></a><ul>3326 <li><em>Part5</em> <a href="#rfc.xref.Part5.1">3.2</a>, <a href="#rfc.xref.Part5.2">3.2</a>, <a href="#rfc.xref.Part5.3">3.3</a>, <a href="#rfc.xref.Part5.4">4.1</a>, <a href="#rfc.xref.Part5.5">4.1</a>, <a href="#rfc.xref.Part5.6">4.1</a>, <a href="#rfc.xref.Part5.7">6.3</a>, <a href="#rfc.xref.Part5.8">7.2.7</a>, <a href="#rfc.xref.Part5.9">7.4.17</a>, <a href="#rfc.xref.Part5.10">7.4.17</a>, <a href="#Part5"><b>12.1</b></a><ul> 3276 3327 <li><em>Section 3</em> <a href="#rfc.xref.Part5.4">4.1</a></li> 3277 3328 <li><em>Section 3.1</em> <a href="#rfc.xref.Part5.5">4.1</a>, <a href="#rfc.xref.Part5.8">7.2.7</a></li> 3278 3329 <li><em>Section 3.2</em> <a href="#rfc.xref.Part5.6">4.1</a>, <a href="#rfc.xref.Part5.10">7.4.17</a></li> 3279 <li><em>Section 5.1</em> <a href="#rfc.xref.Part5.3">3. 2</a></li>3280 <li><em>Section 5.3</em> <a href="#rfc.xref.Part5.1">3. 1</a></li>3281 <li><em>Section 5.4</em> <a href="#rfc.xref.Part5.2">3. 1</a>, <a href="#rfc.xref.Part5.7">6.3</a>, <a href="#rfc.xref.Part5.9">7.4.17</a></li>3330 <li><em>Section 5.1</em> <a href="#rfc.xref.Part5.3">3.3</a></li> 3331 <li><em>Section 5.3</em> <a href="#rfc.xref.Part5.1">3.2</a></li> 3332 <li><em>Section 5.4</em> <a href="#rfc.xref.Part5.2">3.2</a>, <a href="#rfc.xref.Part5.7">6.3</a>, <a href="#rfc.xref.Part5.9">7.4.17</a></li> 3282 3333 </ul> 3283 3334 </li> 3284 <li><em>Part6</em> <a href="#rfc.xref.Part6.1">2.2.1</a>, <a href="#rfc.xref.Part6.2">3. 2</a>, <a href="#rfc.xref.Part6.3">3.2</a>, <a href="#rfc.xref.Part6.4">4.2.1</a>, <a href="#rfc.xref.Part6.5">6.3</a>, <a href="#rfc.xref.Part6.6">6.4</a>, <a href="#rfc.xref.Part6.7">6.5</a>, <a href="#rfc.xref.Part6.8">6.6</a>, <a href="#rfc.xref.Part6.9">6.7</a>, <a href="#rfc.xref.Part6.10">7.2.1</a>, <a href="#rfc.xref.Part6.11">7.2.4</a>, <a href="#rfc.xref.Part6.12">7.2.4</a>, <a href="#rfc.xref.Part6.13">7.2.4</a>, <a href="#rfc.xref.Part6.14">7.2.7</a>, <a href="#rfc.xref.Part6.15">7.3.1</a>, <a href="#rfc.xref.Part6.16">7.3.2</a>, <a href="#rfc.xref.Part6.17">7.4.11</a>, <a href="#Part6"><b>12.1</b></a><ul>3285 <li><em>Section 2.3.1</em> <a href="#rfc.xref.Part6. 7">6.5</a></li>3286 <li><em>Section 2.3.1.1</em> <a href="#rfc.xref.Part6.1 0">7.2.1</a>, <a href="#rfc.xref.Part6.13">7.2.4</a>, <a href="#rfc.xref.Part6.14">7.2.7</a>, <a href="#rfc.xref.Part6.15">7.3.1</a>, <a href="#rfc.xref.Part6.16">7.3.2</a>, <a href="#rfc.xref.Part6.17">7.4.11</a></li>3287 <li><em>Section 2.5</em> <a href="#rfc.xref.Part6. 8">6.6</a>, <a href="#rfc.xref.Part6.9">6.7</a></li>3288 <li><em>Section 3.1</em> <a href="#rfc.xref.Part6. 2">3.2</a></li>3289 <li><em>Section 3.2</em> <a href="#rfc.xref.Part6.1 1">7.2.4</a></li>3290 <li><em>Section 3.5</em> <a href="#rfc.xref.Part6. 3">3.2</a></li>3291 <li><em>Section 3.6</em> <a href="#rfc.xref.Part6.1 2">7.2.4</a></li>3335 <li><em>Part6</em> <a href="#rfc.xref.Part6.1">2.2.1</a>, <a href="#rfc.xref.Part6.2">3.1</a>, <a href="#rfc.xref.Part6.3">3.3</a>, <a href="#rfc.xref.Part6.4">3.3</a>, <a href="#rfc.xref.Part6.5">4.2.1</a>, <a href="#rfc.xref.Part6.6">6.3</a>, <a href="#rfc.xref.Part6.7">6.4</a>, <a href="#rfc.xref.Part6.8">6.5</a>, <a href="#rfc.xref.Part6.9">6.6</a>, <a href="#rfc.xref.Part6.10">6.7</a>, <a href="#rfc.xref.Part6.11">7.2.1</a>, <a href="#rfc.xref.Part6.12">7.2.4</a>, <a href="#rfc.xref.Part6.13">7.2.4</a>, <a href="#rfc.xref.Part6.14">7.2.4</a>, <a href="#rfc.xref.Part6.15">7.2.7</a>, <a href="#rfc.xref.Part6.16">7.3.1</a>, <a href="#rfc.xref.Part6.17">7.3.2</a>, <a href="#rfc.xref.Part6.18">7.4.11</a>, <a href="#Part6"><b>12.1</b></a><ul> 3336 <li><em>Section 2.3.1</em> <a href="#rfc.xref.Part6.8">6.5</a></li> 3337 <li><em>Section 2.3.1.1</em> <a href="#rfc.xref.Part6.11">7.2.1</a>, <a href="#rfc.xref.Part6.14">7.2.4</a>, <a href="#rfc.xref.Part6.15">7.2.7</a>, <a href="#rfc.xref.Part6.16">7.3.1</a>, <a href="#rfc.xref.Part6.17">7.3.2</a>, <a href="#rfc.xref.Part6.18">7.4.11</a></li> 3338 <li><em>Section 2.5</em> <a href="#rfc.xref.Part6.9">6.6</a>, <a href="#rfc.xref.Part6.10">6.7</a></li> 3339 <li><em>Section 3.1</em> <a href="#rfc.xref.Part6.3">3.3</a></li> 3340 <li><em>Section 3.2</em> <a href="#rfc.xref.Part6.12">7.2.4</a></li> 3341 <li><em>Section 3.5</em> <a href="#rfc.xref.Part6.4">3.3</a></li> 3342 <li><em>Section 3.6</em> <a href="#rfc.xref.Part6.13">7.2.4</a></li> 3292 3343 </ul> 3293 3344 </li> 3294 <li><em>Part7</em> <a href="#rfc.xref.Part7.1">3. 1</a>, <a href="#rfc.xref.Part7.2">3.1</a>, <a href="#rfc.xref.Part7.3">3.2</a>, <a href="#rfc.xref.Part7.4">3.2</a>, <a href="#rfc.xref.Part7.5">4.1</a>, <a href="#rfc.xref.Part7.6">4.1</a>, <a href="#rfc.xref.Part7.7">4.1</a>, <a href="#rfc.xref.Part7.8">7.4.2</a>, <a href="#rfc.xref.Part7.9">7.4.8</a>, <a href="#Part7"><b>12.1</b></a><ul>3345 <li><em>Part7</em> <a href="#rfc.xref.Part7.1">3.2</a>, <a href="#rfc.xref.Part7.2">3.2</a>, <a href="#rfc.xref.Part7.3">3.3</a>, <a href="#rfc.xref.Part7.4">3.3</a>, <a href="#rfc.xref.Part7.5">4.1</a>, <a href="#rfc.xref.Part7.6">4.1</a>, <a href="#rfc.xref.Part7.7">4.1</a>, <a href="#rfc.xref.Part7.8">7.4.2</a>, <a href="#rfc.xref.Part7.9">7.4.8</a>, <a href="#Part7"><b>12.1</b></a><ul> 3295 3346 <li><em>Section 3</em> <a href="#rfc.xref.Part7.5">4.1</a></li> 3296 3347 <li><em>Section 3.1</em> <a href="#rfc.xref.Part7.6">4.1</a>, <a href="#rfc.xref.Part7.8">7.4.2</a></li> 3297 3348 <li><em>Section 3.2</em> <a href="#rfc.xref.Part7.7">4.1</a>, <a href="#rfc.xref.Part7.9">7.4.8</a></li> 3298 <li><em>Section 4.1</em> <a href="#rfc.xref.Part7.1">3. 1</a></li>3299 <li><em>Section 4.2</em> <a href="#rfc.xref.Part7.3">3. 2</a></li>3300 <li><em>Section 4.3</em> <a href="#rfc.xref.Part7.2">3. 1</a></li>3301 <li><em>Section 4.4</em> <a href="#rfc.xref.Part7.4">3. 2</a></li>3349 <li><em>Section 4.1</em> <a href="#rfc.xref.Part7.1">3.2</a></li> 3350 <li><em>Section 4.2</em> <a href="#rfc.xref.Part7.3">3.3</a></li> 3351 <li><em>Section 4.3</em> <a href="#rfc.xref.Part7.2">3.2</a></li> 3352 <li><em>Section 4.4</em> <a href="#rfc.xref.Part7.4">3.3</a></li> 3302 3353 </ul> 3303 3354 </li> … … 3307 3358 </li> 3308 3359 <li><a id="rfc.index.R" href="#rfc.index.R"><b>R</b></a><ul> 3309 <li>Referer header field <a href="#rfc.xref.header.referer.1">3. 1</a>, <a href="#rfc.iref.r.1"><b>8.6</b></a>, <a href="#rfc.xref.header.referer.2">9.3</a>, <a href="#rfc.xref.header.referer.3">A</a></li>3310 <li>Retry-After header field <a href="#rfc.xref.header.retry-after.1">3. 2</a>, <a href="#rfc.xref.header.retry-after.2">7.5.4</a>, <a href="#rfc.iref.r.2"><b>8.7</b></a>, <a href="#rfc.xref.header.retry-after.3">9.3</a></li>3360 <li>Referer header field <a href="#rfc.xref.header.referer.1">3.2</a>, <a href="#rfc.iref.r.1"><b>8.6</b></a>, <a href="#rfc.xref.header.referer.2">9.3</a>, <a href="#rfc.xref.header.referer.3">A</a></li> 3361 <li>Retry-After header field <a href="#rfc.xref.header.retry-after.1">3.3</a>, <a href="#rfc.xref.header.retry-after.2">7.5.4</a>, <a href="#rfc.iref.r.2"><b>8.7</b></a>, <a href="#rfc.xref.header.retry-after.3">9.3</a></li> 3311 3362 <li><em>RFC1945</em> <a href="#rfc.xref.RFC1945.1">7.3.3</a>, <a href="#RFC1945"><b>12.2</b></a><ul> 3312 3363 <li><em>Section 9.3</em> <a href="#rfc.xref.RFC1945.1">7.3.3</a></li> … … 3327 3378 </ul> 3328 3379 </li> 3329 <li><em>RFC3864</em> <a href="#rfc.xref.RFC3864.1">9.3</a>, <a href="#RFC3864"><b>12.2</b></a></li> 3380 <li><em>RFC3864</em> <a href="#rfc.xref.RFC3864.1">3.1</a>, <a href="#rfc.xref.RFC3864.2">3.1</a>, <a href="#rfc.xref.RFC3864.3">9.3</a>, <a href="#RFC3864"><b>12.2</b></a><ul> 3381 <li><em>Section 4.1</em> <a href="#rfc.xref.RFC3864.2">3.1</a></li> 3382 </ul> 3383 </li> 3330 3384 <li><em>RFC3986</em> <a href="#rfc.xref.RFC3986.1">8.4</a>, <a href="#rfc.xref.RFC3986.2">8.4</a>, <a href="#RFC3986"><b>12.1</b></a><ul> 3331 3385 <li><em>Section 4.2</em> <a href="#rfc.xref.RFC3986.1">8.4</a></li> … … 3337 3391 </ul> 3338 3392 </li> 3339 <li><em>RFC5234</em> <a href="#rfc.xref.RFC5234.1">1.2</a>, <a href="#rfc.xref.RFC5234.2">1.2</a>, <a href="# RFC5234"><b>12.1</b></a><ul>3393 <li><em>RFC5234</em> <a href="#rfc.xref.RFC5234.1">1.2</a>, <a href="#rfc.xref.RFC5234.2">1.2</a>, <a href="#rfc.xref.RFC5234.3">3.1</a>, <a href="#RFC5234"><b>12.1</b></a><ul> 3340 3394 <li><em>Appendix B.1</em> <a href="#rfc.xref.RFC5234.2">1.2</a></li> 3341 3395 </ul> … … 3346 3400 </li> 3347 3401 <li><em>RFC5789</em> <a href="#rfc.xref.RFC5789.1">6.6</a>, <a href="#RFC5789"><b>12.2</b></a></li> 3402 <li><em>RFC5987</em> <a href="#rfc.xref.RFC5987.1">3.1</a>, <a href="#RFC5987"><b>12.2</b></a></li> 3348 3403 </ul> 3349 3404 </li> 3350 3405 <li><a id="rfc.index.S" href="#rfc.index.S"><b>S</b></a><ul> 3351 3406 <li>Safe Methods <a href="#rfc.iref.s.1"><b>6.1.1</b></a></li> 3352 <li>Server header field <a href="#rfc.xref.header.server.1">3. 2</a>, <a href="#rfc.iref.s.44"><b>8.8</b></a>, <a href="#rfc.xref.header.server.2">9.3</a>, <a href="#rfc.xref.header.server.3">10.1</a>, <a href="#rfc.xref.header.server.4">A</a></li>3407 <li>Server header field <a href="#rfc.xref.header.server.1">3.3</a>, <a href="#rfc.iref.s.44"><b>8.8</b></a>, <a href="#rfc.xref.header.server.2">9.3</a>, <a href="#rfc.xref.header.server.3">10.1</a>, <a href="#rfc.xref.header.server.4">A</a></li> 3353 3408 <li>Status Codes 3354 3409 <ul> … … 3404 3459 </li> 3405 3460 <li><a id="rfc.index.U" href="#rfc.index.U"><b>U</b></a><ul> 3406 <li>User-Agent header field <a href="#rfc.xref.header.user-agent.1">3. 1</a>, <a href="#rfc.iref.u.1"><b>8.9</b></a>, <a href="#rfc.xref.header.user-agent.2">9.3</a>, <a href="#rfc.xref.header.user-agent.3">10.1</a></li>3461 <li>User-Agent header field <a href="#rfc.xref.header.user-agent.1">3.2</a>, <a href="#rfc.iref.u.1"><b>8.9</b></a>, <a href="#rfc.xref.header.user-agent.2">9.3</a>, <a href="#rfc.xref.header.user-agent.3">10.1</a></li> 3407 3462 </ul> 3408 3463 </li> -
draft-ietf-httpbis/latest/p2-semantics.xml
r1416 r1417 31 31 <!ENTITY effective-request-uri "<xref target='Part1' x:rel='#effective.request.uri' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 32 32 <!ENTITY intermediaries "<xref target='Part1' x:rel='#intermediaries' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 33 <!ENTITY chunked-encoding "<xref target='Part1' x:rel='#chunked.encoding' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 33 34 <!ENTITY full-date "<xref target='Part1' x:rel='#date.time.formats.full.date' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 34 35 <!ENTITY http-url "<xref target='Part1' x:rel='#http-url' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> … … 45 46 <!ENTITY header-authorization "<xref target='Part7' x:rel='#header.authorization' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 46 47 <!ENTITY header-cache-control "<xref target='Part6' x:rel='#header.cache-control' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 48 <!ENTITY header-connection "<xref target='Part1' x:rel='#header.connection' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 47 49 <!ENTITY header-content-location "<xref target='Part3' x:rel='#header.content-location' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 48 50 <!ENTITY header-content-range "<xref target='Part5' x:rel='#header.content-range' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> … … 480 482 481 483 <section title="Header Fields" anchor="header.fields"> 484 <t> 485 Header fields are key value pairs that can be used to communicate data about 486 the message, its payload, the target resource, or about the connection 487 itself (i.e., control data). See &header-fields; for a general definition 488 of their syntax. 489 </t> 490 491 <section title="Considerations for Creating Header Fields" anchor="considerations.for.creating.header.fields"> 492 <t> 493 New header fields are registered using the procedures described in 494 <xref target="RFC3864"/>. 495 </t> 496 <t> 497 The requirements for header field names are defined in 498 <xref target="RFC3864" x:fmt="of" x:sec="4.1"/>. Authors of specifications 499 defining new fields are advised to keep the name as short as practical, and 500 not to prefix them with "X-" if they are to be registered (either 501 immediately or in the future). 502 </t> 503 <t> 504 New header field values typically have their syntax defined using ABNF 505 (<xref target="RFC5234"/>), using the extensions defined in ¬ation-abnf; 506 as necessary, and are usually constrained to the range of ASCII characters. 507 Header fields needing a greater range of characters can use an encoding 508 such as the one defined in <xref target="RFC5987"/>. 509 </t> 510 <t> 511 Because commas (",") are used as a generic delimiter between field-values, 512 they need to be treated with care if they are allowed in the field-value's 513 payload. Typically, components that might contain a comma are protected with 514 double-quotes using the quoted-string ABNF production (&field-rules;). 515 </t> 516 <t> 517 For example, a textual date and a URI (either of which might contain a comma) 518 could be safely carried in field-values like these: 519 </t> 520 <figure><artwork type="example"> 521 Example-URI-Field: "http://example.com/a.html,foo", 522 "http://without-a-comma.example.com/" 523 Example-Date-Field: "Sat, 04 May 1996", "Wed, 14 Sep 2005" 524 </artwork></figure> 525 <t> 526 Authors of specifications defining new header fields are advised to consider 527 documenting: 528 <list style="symbols"> 529 <t>Whether the field is a single value, or whether it can be a list 530 (delimited by commas; see &header-fields;).</t> 531 <t>Under what conditions the header field can be used; e.g., only i 532 responses or requests, in all messages, only on responses to a particular 533 request method.</t> 534 <t>Whether it is appropriate to list the field-name in the Connection header 535 (i.e., if the header is to be hop-by-hop, see &header-connection;).</t> 536 <t>Under what conditions intermediaries are allowed to modify the header 537 field's value, insert or delete it.</t> 538 <t>How the header might interact with caching (see <xref target="Part6"/>).</t> 539 <t>Whether the header field is useful or allowable in trailers (see 540 &chunked-encoding;).</t> 541 <t>Whether the header field should be preserved across redirects.</t> 542 </list> 543 </t> 544 </section> 482 545 483 546 <section title="Request Header Fields" anchor="request.header.fields"> … … 3505 3568 </reference> 3506 3569 3570 <reference anchor="RFC5987"> 3571 <front> 3572 <title>Character Set and Language Encoding for Hypertext Transfer Protocol (HTTP) Header Field Parameters</title> 3573 <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke"> 3574 <organization abbrev="greenbytes">greenbytes GmbH</organization> 3575 <address> 3576 <postal> 3577 <street>Hafenweg 16</street> 3578 <city>Muenster</city><region>NW</region><code>48155</code> 3579 <country>Germany</country> 3580 </postal> 3581 <email>julian.reschke@greenbytes.de</email> 3582 <uri>http://greenbytes.de/tech/webdav/</uri> 3583 </address> 3584 </author> 3585 <date month="August" year="2010"/> 3586 </front> 3587 <seriesInfo name="RFC" value="5987"/> 3588 </reference> 3589 3507 3590 </references> 3508 3591 … … 4184 4267 <section title="Since draft-ietf-httpbis-p2-semantics-16" anchor="changes.since.16"> 4185 4268 <t> 4186 None yet. 4269 Work-in-progress: 4270 <list style="symbols"> 4271 <t> 4272 <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/231"/>: 4273 "Considerations for new headers" 4274 </t> 4275 </list> 4187 4276 </t> 4188 4277 </section>
Note: See TracChangeset
for help on using the changeset viewer.