Changeset 1619
- Timestamp:
- 26/03/12 14:44:27 (10 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 2 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p2-semantics.html
r1618 r1619 483 483 <link rel="Index" href="#rfc.index"> 484 484 <link rel="Chapter" title="1 Introduction" href="#rfc.section.1"> 485 <link rel="Chapter" title="2 Method " href="#rfc.section.2">485 <link rel="Chapter" title="2 Methods" href="#rfc.section.2"> 486 486 <link rel="Chapter" title="3 Header Fields" href="#rfc.section.3"> 487 487 <link rel="Chapter" title="4 Status Code and Reason Phrase" href="#rfc.section.4"> 488 488 <link rel="Chapter" title="5 Representation" href="#rfc.section.5"> 489 <link rel="Chapter" title="6 Method Definitions" href="#rfc.section.6"> 490 <link rel="Chapter" title="7 Common Protocol Parameters" href="#rfc.section.7"> 491 <link rel="Chapter" title="8 Header Field Definitions" href="#rfc.section.8"> 492 <link rel="Chapter" title="9 IANA Considerations" href="#rfc.section.9"> 493 <link rel="Chapter" title="10 Security Considerations" href="#rfc.section.10"> 494 <link rel="Chapter" title="11 Acknowledgments" href="#rfc.section.11"> 495 <link rel="Chapter" href="#rfc.section.12" title="12 References"> 489 <link rel="Chapter" title="6 Common Protocol Parameters" href="#rfc.section.6"> 490 <link rel="Chapter" title="7 Header Field Definitions" href="#rfc.section.7"> 491 <link rel="Chapter" title="8 IANA Considerations" href="#rfc.section.8"> 492 <link rel="Chapter" title="9 Security Considerations" href="#rfc.section.9"> 493 <link rel="Chapter" title="10 Acknowledgments" href="#rfc.section.10"> 494 <link rel="Chapter" href="#rfc.section.11" title="11 References"> 496 495 <link rel="Appendix" title="A Changes from RFC 2616" href="#rfc.section.A"> 497 496 <link rel="Appendix" title="B Collected ABNF" href="#rfc.section.B"> … … 598 597 </ul> 599 598 </li> 600 <li>2. <a href="#method">Method</a><ul> 601 <li>2.1 <a href="#overview.of.methods">Overview of Methods</a></li> 599 <li>2. <a href="#methods">Methods</a><ul> 600 <li>2.1 <a href="#safe.and.idempotent">Safe and Idempotent Methods</a><ul> 601 <li>2.1.1 <a href="#safe.methods">Safe Methods</a></li> 602 <li>2.1.2 <a href="#idempotent.methods">Idempotent Methods</a></li> 603 </ul> 604 </li> 602 605 <li>2.2 <a href="#method.registry">Method Registry</a><ul> 603 606 <li>2.2.1 <a href="#considerations.for.new.methods">Considerations for New Methods</a></li> 607 </ul> 608 </li> 609 <li>2.3 <a href="#method.definitions">Method Definitions</a><ul> 610 <li>2.3.1 <a href="#OPTIONS">OPTIONS</a></li> 611 <li>2.3.2 <a href="#GET">GET</a></li> 612 <li>2.3.3 <a href="#HEAD">HEAD</a></li> 613 <li>2.3.4 <a href="#POST">POST</a></li> 614 <li>2.3.5 <a href="#PUT">PUT</a></li> 615 <li>2.3.6 <a href="#DELETE">DELETE</a></li> 616 <li>2.3.7 <a href="#TRACE">TRACE</a></li> 617 <li>2.3.8 <a href="#CONNECT">CONNECT</a></li> 604 618 </ul> 605 619 </li> … … 678 692 </ul> 679 693 </li> 680 <li>6. <a href="#method.definitions">Method Definitions</a><ul> 681 <li>6.1 <a href="#safe.and.idempotent">Safe and Idempotent Methods</a><ul> 682 <li>6.1.1 <a href="#safe.methods">Safe Methods</a></li> 683 <li>6.1.2 <a href="#idempotent.methods">Idempotent Methods</a></li> 684 </ul> 685 </li> 686 <li>6.2 <a href="#OPTIONS">OPTIONS</a></li> 687 <li>6.3 <a href="#GET">GET</a></li> 688 <li>6.4 <a href="#HEAD">HEAD</a></li> 689 <li>6.5 <a href="#POST">POST</a></li> 690 <li>6.6 <a href="#PUT">PUT</a></li> 691 <li>6.7 <a href="#DELETE">DELETE</a></li> 692 <li>6.8 <a href="#TRACE">TRACE</a></li> 693 <li>6.9 <a href="#CONNECT">CONNECT</a></li> 694 <li>6. <a href="#common.protocol.parameters">Common Protocol Parameters</a><ul> 695 <li>6.1 <a href="#http.date">Date/Time Formats</a></li> 696 <li>6.2 <a href="#product.tokens">Product Tokens</a></li> 694 697 </ul> 695 698 </li> 696 <li>7. <a href="#common.protocol.parameters">Common Protocol Parameters</a><ul> 697 <li>7.1 <a href="#http.date">Date/Time Formats</a></li> 698 <li>7.2 <a href="#product.tokens">Product Tokens</a></li> 699 <li>7. <a href="#header.field.definitions">Header Field Definitions</a><ul> 700 <li>7.1 <a href="#header.allow">Allow</a></li> 701 <li>7.2 <a href="#header.date">Date</a></li> 702 <li>7.3 <a href="#header.expect">Expect</a></li> 703 <li>7.4 <a href="#header.from">From</a></li> 704 <li>7.5 <a href="#header.location">Location</a></li> 705 <li>7.6 <a href="#header.max-forwards">Max-Forwards</a></li> 706 <li>7.7 <a href="#header.referer">Referer</a></li> 707 <li>7.8 <a href="#header.retry-after">Retry-After</a></li> 708 <li>7.9 <a href="#header.server">Server</a></li> 709 <li>7.10 <a href="#header.user-agent">User-Agent</a></li> 699 710 </ul> 700 711 </li> 701 <li>8. <a href="#header.field.definitions">Header Field Definitions</a><ul> 702 <li>8.1 <a href="#header.allow">Allow</a></li> 703 <li>8.2 <a href="#header.date">Date</a></li> 704 <li>8.3 <a href="#header.expect">Expect</a></li> 705 <li>8.4 <a href="#header.from">From</a></li> 706 <li>8.5 <a href="#header.location">Location</a></li> 707 <li>8.6 <a href="#header.max-forwards">Max-Forwards</a></li> 708 <li>8.7 <a href="#header.referer">Referer</a></li> 709 <li>8.8 <a href="#header.retry-after">Retry-After</a></li> 710 <li>8.9 <a href="#header.server">Server</a></li> 711 <li>8.10 <a href="#header.user-agent">User-Agent</a></li> 712 <li>8. <a href="#IANA.considerations">IANA Considerations</a><ul> 713 <li>8.1 <a href="#method.registration">Method Registry</a></li> 714 <li>8.2 <a href="#status.code.registration">Status Code Registry</a></li> 715 <li>8.3 <a href="#header.field.registration">Header Field Registration</a></li> 712 716 </ul> 713 717 </li> 714 <li>9. <a href="#IANA.considerations">IANA Considerations</a><ul> 715 <li>9.1 <a href="#method.registration">Method Registry</a></li> 716 <li>9.2 <a href="#status.code.registration">Status Code Registry</a></li> 717 <li>9.3 <a href="#header.field.registration">Header Field Registration</a></li> 718 <li>9. <a href="#security.considerations">Security Considerations</a><ul> 719 <li>9.1 <a href="#security.sensitive">Transfer of Sensitive Information</a></li> 720 <li>9.2 <a href="#encoding.sensitive.information.in.uris">Encoding Sensitive Information in URIs</a></li> 721 <li>9.3 <a href="#location.spoofing-leakage">Location Header Fields: Spoofing and Information Leakage</a></li> 722 <li>9.4 <a href="#rfc.section.9.4">Security Considerations for CONNECT</a></li> 718 723 </ul> 719 724 </li> 720 <li>10. <a href="#security.considerations">Security Considerations</a><ul> 721 <li>10.1 <a href="#security.sensitive">Transfer of Sensitive Information</a></li> 722 <li>10.2 <a href="#encoding.sensitive.information.in.uris">Encoding Sensitive Information in URIs</a></li> 723 <li>10.3 <a href="#location.spoofing-leakage">Location Header Fields: Spoofing and Information Leakage</a></li> 724 <li>10.4 <a href="#rfc.section.10.4">Security Considerations for CONNECT</a></li> 725 </ul> 726 </li> 727 <li>11. <a href="#acks">Acknowledgments</a></li> 728 <li>12. <a href="#rfc.references">References</a><ul> 729 <li>12.1 <a href="#rfc.references.1">Normative References</a></li> 730 <li>12.2 <a href="#rfc.references.2">Informative References</a></li> 725 <li>10. <a href="#acks">Acknowledgments</a></li> 726 <li>11. <a href="#rfc.references">References</a><ul> 727 <li>11.1 <a href="#rfc.references.1">Normative References</a></li> 728 <li>11.2 <a href="#rfc.references.2">Informative References</a></li> 731 729 </ul> 732 730 </li> … … 812 810 <a href="#abnf.dependencies" class="smpl">partial-URI</a> = <partial-URI, defined in <a href="#Part1" id="rfc.xref.Part1.13"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.7</a>> 813 811 <a href="#abnf.dependencies" class="smpl">URI-reference</a> = <URI-reference, defined in <a href="#Part1" id="rfc.xref.Part1.14"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.7</a>> 814 </pre><h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a> <a id="method " href="#method">Method</a></h1>812 </pre><h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a> <a id="methods" href="#methods">Methods</a></h1> 815 813 <p id="rfc.section.2.p.1">The method token indicates the request method to be performed on the target resource (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 5.5</a> of <a href="#Part1" id="rfc.xref.Part1.15"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). The method is case-sensitive. 816 814 </p> 817 <div id="rfc.figure.u.3"></div><pre class="inline"><span id="rfc.iref.g.1"></span> <a href="#method " class="smpl">method</a> = <a href="#core.rules" class="smpl">token</a>818 </pre><p id="rfc.section.2.p.3">The list of methods allowed by a resource can be specified in an Allow header field (<a href="#header.allow" id="rfc.xref.header.allow.1" title="Allow">Section 8.1</a>). The status code of the response always notifies the client whether a method is currently allowed on a resource, since the815 <div id="rfc.figure.u.3"></div><pre class="inline"><span id="rfc.iref.g.1"></span> <a href="#methods" class="smpl">method</a> = <a href="#core.rules" class="smpl">token</a> 816 </pre><p id="rfc.section.2.p.3">The list of methods allowed by a resource can be specified in an Allow header field (<a href="#header.allow" id="rfc.xref.header.allow.1" title="Allow">Section 7.1</a>). The status code of the response always notifies the client whether a method is currently allowed on a resource, since the 819 817 set of allowed methods can change dynamically. An origin server <em class="bcp14">SHOULD</em> respond with the status code 405 (Method Not Allowed) if the method is known by the origin server but not allowed for the 820 818 resource, and 501 (Not Implemented) if the method is unrecognized or not implemented by the origin server. The methods GET 821 and HEAD <em class="bcp14">MUST</em> be supported by all general-purpose servers. All other methods are <em class="bcp14">OPTIONAL</em>; however, if the above methods are implemented, they <em class="bcp14">MUST</em> be implemented with the same semantics as those specified in <a href="#method.definitions" title="Method Definitions">Section 6</a>. 822 </p> 823 <h2 id="rfc.section.2.1"><a href="#rfc.section.2.1">2.1</a> <a id="overview.of.methods" href="#overview.of.methods">Overview of Methods</a></h2> 824 <p id="rfc.section.2.1.p.1">The methods listed below are defined in <a href="#method.definitions" title="Method Definitions">Section 6</a>. 825 </p> 826 <div id="rfc.table.u.1"> 827 <table class="tt full left" cellpadding="3" cellspacing="0"> 828 <thead> 829 <tr> 830 <th>Method Name</th> 831 <th>Defined in...</th> 832 </tr> 833 </thead> 834 <tbody> 835 <tr> 836 <td class="left">OPTIONS</td> 837 <td class="left"><a href="#OPTIONS" id="rfc.xref.OPTIONS.1" title="OPTIONS">Section 6.2</a></td> 838 </tr> 839 <tr> 840 <td class="left">GET</td> 841 <td class="left"><a href="#GET" id="rfc.xref.GET.1" title="GET">Section 6.3</a></td> 842 </tr> 843 <tr> 844 <td class="left">HEAD</td> 845 <td class="left"><a href="#HEAD" id="rfc.xref.HEAD.1" title="HEAD">Section 6.4</a></td> 846 </tr> 847 <tr> 848 <td class="left">POST</td> 849 <td class="left"><a href="#POST" id="rfc.xref.POST.1" title="POST">Section 6.5</a></td> 850 </tr> 851 <tr> 852 <td class="left">PUT</td> 853 <td class="left"><a href="#PUT" id="rfc.xref.PUT.1" title="PUT">Section 6.6</a></td> 854 </tr> 855 <tr> 856 <td class="left">DELETE</td> 857 <td class="left"><a href="#DELETE" id="rfc.xref.DELETE.1" title="DELETE">Section 6.7</a></td> 858 </tr> 859 <tr> 860 <td class="left">TRACE</td> 861 <td class="left"><a href="#TRACE" id="rfc.xref.TRACE.1" title="TRACE">Section 6.8</a></td> 862 </tr> 863 <tr> 864 <td class="left">CONNECT</td> 865 <td class="left"><a href="#CONNECT" id="rfc.xref.CONNECT.1" title="CONNECT">Section 6.9</a></td> 866 </tr> 867 </tbody> 868 </table> 869 </div> 870 <p id="rfc.section.2.1.p.2">Note that this list is not exhaustive — it does not include request methods defined in other specifications.</p> 819 and HEAD <em class="bcp14">MUST</em> be supported by all general-purpose servers. All other methods are <em class="bcp14">OPTIONAL</em>; however, if the above methods are implemented, they <em class="bcp14">MUST</em> be implemented with the same semantics as those specified in <a href="#method.definitions" title="Method Definitions">Section 2.3</a>. 820 </p> 821 <h2 id="rfc.section.2.1"><a href="#rfc.section.2.1">2.1</a> <a id="safe.and.idempotent" href="#safe.and.idempotent">Safe and Idempotent Methods</a></h2> 822 <div id="rfc.iref.s.1"></div> 823 <h3 id="rfc.section.2.1.1"><a href="#rfc.section.2.1.1">2.1.1</a> <a id="safe.methods" href="#safe.methods">Safe Methods</a></h3> 824 <p id="rfc.section.2.1.1.p.1">Implementors need to be aware that the software represents the user in their interactions over the Internet, and need to allow 825 the user to be aware of any actions they take which might have an unexpected significance to themselves or others. 826 </p> 827 <p id="rfc.section.2.1.1.p.2">In particular, the convention has been established that the GET, HEAD, OPTIONS, and TRACE request methods <em class="bcp14">SHOULD NOT</em> have the significance of taking an action other than retrieval. These request methods ought to be considered "<dfn id="safe">safe</dfn>". This allows user agents to represent other methods, such as POST, PUT and DELETE, in a special way, so that the user is 828 made aware of the fact that a possibly unsafe action is being requested. 829 </p> 830 <p id="rfc.section.2.1.1.p.3">Naturally, it is not possible to ensure that the server does not generate side-effects as a result of performing a GET request; 831 in fact, some dynamic resources consider that a feature. The important distinction here is that the user did not request the 832 side-effects, so therefore cannot be held accountable for them. 833 </p> 834 <div id="rfc.iref.i.1"></div> 835 <h3 id="rfc.section.2.1.2"><a href="#rfc.section.2.1.2">2.1.2</a> <a id="idempotent.methods" href="#idempotent.methods">Idempotent Methods</a></h3> 836 <p id="rfc.section.2.1.2.p.1">Request methods can also have the property of "idempotence" in that, aside from error or expiration issues, the intended effect 837 of multiple identical requests is the same as for a single request. PUT, DELETE, and all safe request methods are idempotent. 838 It is important to note that idempotence refers only to changes requested by the client: a server is free to change its state 839 due to multiple requests for the purpose of tracking those requests, versioning of results, etc. 840 </p> 871 841 <h2 id="rfc.section.2.2"><a href="#rfc.section.2.2">2.2</a> <a id="method.registry" href="#method.registry">Method Registry</a></h2> 872 842 <p id="rfc.section.2.2.p.1">The HTTP Method Registry defines the name space for the method token in the Request line of an HTTP request.</p> … … 874 844 </p> 875 845 <ul> 876 <li>Method Name (see <a href="#method " title="Method">Section 2</a>)877 </li> 878 <li>Safe ("yes" or "no", see <a href="#safe.methods" title="Safe Methods">Section 6.1.1</a>)846 <li>Method Name (see <a href="#methods" title="Methods">Section 2</a>) 847 </li> 848 <li>Safe ("yes" or "no", see <a href="#safe.methods" title="Safe Methods">Section 2.1.1</a>) 879 849 </li> 880 850 <li>Pointer to specification text</li> … … 896 866 can specify that only zero-length bodies (as opposed to absent bodies) are allowed. 897 867 </p> 898 <p id="rfc.section.2.2.1.p.4">New method definitions need to indicate whether they are safe (<a href="#safe.methods" title="Safe Methods">Section 6.1.1</a>), what semantics (if any) the request body has, and whether they are idempotent (<a href="#idempotent.methods" title="Idempotent Methods">Section 6.1.2</a>). They also need to state whether they can be cached (<a href="#Part6" id="rfc.xref.Part6.1"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>); in particular what conditions a cache may store the response, and under what conditions such a stored response may be used868 <p id="rfc.section.2.2.1.p.4">New method definitions need to indicate whether they are safe (<a href="#safe.methods" title="Safe Methods">Section 2.1.1</a>), what semantics (if any) the request body has, and whether they are idempotent (<a href="#idempotent.methods" title="Idempotent Methods">Section 2.1.2</a>). They also need to state whether they can be cached (<a href="#Part6" id="rfc.xref.Part6.1"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>); in particular what conditions a cache may store the response, and under what conditions such a stored response may be used 899 869 to satisfy a subsequent request. 870 </p> 871 <h2 id="rfc.section.2.3"><a href="#rfc.section.2.3">2.3</a> <a id="method.definitions" href="#method.definitions">Method Definitions</a></h2> 872 <h3 id="rfc.section.2.3.1"><a href="#rfc.section.2.3.1">2.3.1</a> <a id="OPTIONS" href="#OPTIONS">OPTIONS</a></h3> 873 <div id="rfc.iref.o.1"></div> 874 <div id="rfc.iref.m.1"></div> 875 <p id="rfc.section.2.3.1.p.1">The OPTIONS method requests information about the communication options available on the request/response chain identified 876 by the effective request URI. This method allows a client to determine the options and/or requirements associated with a resource, 877 or the capabilities of a server, without implying a resource action or initiating a resource retrieval. 878 </p> 879 <p id="rfc.section.2.3.1.p.2">Responses to the OPTIONS method are not cacheable.</p> 880 <p id="rfc.section.2.3.1.p.3">If the OPTIONS request includes a message body (as indicated by the presence of Content-Length or Transfer-Encoding), then 881 the media type <em class="bcp14">MUST</em> be indicated by a Content-Type field. Although this specification does not define any use for such a body, future extensions 882 to HTTP might use the OPTIONS body to make more detailed queries on the server. 883 </p> 884 <p id="rfc.section.2.3.1.p.4">If the request-target (<a href="p1-messaging.html#request-target" title="Request Target">Section 5.3</a> of <a href="#Part1" id="rfc.xref.Part1.17"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) is an asterisk ("*"), the OPTIONS request is intended to apply to the server in general rather than to a specific resource. 885 Since a server's communication options typically depend on the resource, the "*" request is only useful as a "ping" or "no-op" 886 type of method; it does nothing beyond allowing the client to test the capabilities of the server. For example, this can be 887 used to test a proxy for HTTP/1.1 conformance (or lack thereof). 888 </p> 889 <p id="rfc.section.2.3.1.p.5">If the request-target is not an asterisk, the OPTIONS request applies only to the options that are available when communicating 890 with that resource. 891 </p> 892 <p id="rfc.section.2.3.1.p.6">A 200 response <em class="bcp14">SHOULD</em> include any header fields that indicate optional features implemented by the server and applicable to that resource (e.g., 893 Allow), possibly including extensions not defined by this specification. The response body, if any, <em class="bcp14">SHOULD</em> also include information about the communication options. The format for such a body is not defined by this specification, 894 but might be defined by future extensions to HTTP. Content negotiation <em class="bcp14">MAY</em> be used to select the appropriate response format. If no response body is included, the response <em class="bcp14">MUST</em> include a Content-Length field with a field-value of "0". 895 </p> 896 <p id="rfc.section.2.3.1.p.7">The Max-Forwards header field <em class="bcp14">MAY</em> be used to target a specific proxy in the request chain (see <a href="#header.max-forwards" id="rfc.xref.header.max-forwards.1" title="Max-Forwards">Section 7.6</a>). If no Max-Forwards field is present in the request, then the forwarded request <em class="bcp14">MUST NOT</em> include a Max-Forwards field. 897 </p> 898 <h3 id="rfc.section.2.3.2"><a href="#rfc.section.2.3.2">2.3.2</a> <a id="GET" href="#GET">GET</a></h3> 899 <div id="rfc.iref.g.2"></div> 900 <div id="rfc.iref.m.2"></div> 901 <p id="rfc.section.2.3.2.p.1">The GET method requests transfer of a current representation of the target resource.</p> 902 <p id="rfc.section.2.3.2.p.2">If the target resource is a data-producing process, it is the produced data which shall be returned as the representation 903 in the response and not the source text of the process, unless that text happens to be the output of the process. 904 </p> 905 <p id="rfc.section.2.3.2.p.3">The semantics of the GET method change to a "conditional GET" if the request message includes an If-Modified-Since, If-Unmodified-Since, 906 If-Match, If-None-Match, or If-Range header field. A conditional GET requests that the representation be transferred only 907 under the circumstances described by the conditional header field(s). The conditional GET request is intended to reduce unnecessary 908 network usage by allowing cached representations to be refreshed without requiring multiple requests or transferring data 909 already held by the client. 910 </p> 911 <p id="rfc.section.2.3.2.p.4">The semantics of the GET method change to a "partial GET" if the request message includes a Range header field. A partial 912 GET requests that only part of the representation be transferred, as described in <a href="p5-range.html#header.range" title="Range">Section 5.4</a> of <a href="#Part5" id="rfc.xref.Part5.1"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>. The partial GET request is intended to reduce unnecessary network usage by allowing partially-retrieved representations 913 to be completed without transferring data already held by the client. 914 </p> 915 <p id="rfc.section.2.3.2.p.5">Bodies on GET requests have no defined semantics. Note that sending a body on a GET request might cause some existing implementations 916 to reject the request. 917 </p> 918 <p id="rfc.section.2.3.2.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.2"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>). 919 </p> 920 <p id="rfc.section.2.3.2.p.7">See <a href="#encoding.sensitive.information.in.uris" title="Encoding Sensitive Information in URIs">Section 9.2</a> for security considerations when used for forms. 921 </p> 922 <h3 id="rfc.section.2.3.3"><a href="#rfc.section.2.3.3">2.3.3</a> <a id="HEAD" href="#HEAD">HEAD</a></h3> 923 <div id="rfc.iref.h.1"></div> 924 <div id="rfc.iref.m.3"></div> 925 <p id="rfc.section.2.3.3.p.1">The HEAD method is identical to GET except that the server <em class="bcp14">MUST NOT</em> return a message body in the response. The metadata contained in the HTTP header fields in response to a HEAD request <em class="bcp14">SHOULD</em> be identical to the information sent in response to a GET request. This method can be used for obtaining metadata about the 926 representation implied by the request without transferring the representation body. This method is often used for testing 927 hypertext links for validity, accessibility, and recent modification. 928 </p> 929 <p id="rfc.section.2.3.3.p.2">The response to a HEAD request is cacheable and <em class="bcp14">MAY</em> be used to satisfy a subsequent HEAD request. It also has potential side effects on previously stored responses to GET; see <a href="p6-cache.html#head.effects" title="Updating Caches with HEAD Responses">Section 2.5</a> of <a href="#Part6" id="rfc.xref.Part6.3"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>. 930 </p> 931 <p id="rfc.section.2.3.3.p.3">Bodies on HEAD requests have no defined semantics. Note that sending a body on a HEAD request might cause some existing implementations 932 to reject the request. 933 </p> 934 <div id="rfc.iref.p.1"></div> 935 <div id="rfc.iref.m.4"></div> 936 <h3 id="rfc.section.2.3.4"><a href="#rfc.section.2.3.4">2.3.4</a> <a id="POST" href="#POST">POST</a></h3> 937 <p id="rfc.section.2.3.4.p.1">The POST method requests that the origin server accept the representation enclosed in the request as data to be processed 938 by the target resource. POST is designed to allow a uniform method to cover the following functions: 939 </p> 940 <ul> 941 <li>Annotation of existing resources;</li> 942 <li>Posting a message to a bulletin board, newsgroup, mailing list, or similar group of articles;</li> 943 <li>Providing a block of data, such as the result of submitting a form, to a data-handling process;</li> 944 <li>Extending a database through an append operation.</li> 945 </ul> 946 <p id="rfc.section.2.3.4.p.2">The actual function performed by the POST method is determined by the server and is usually dependent on the effective request 947 URI. 948 </p> 949 <p id="rfc.section.2.3.4.p.3">The action performed by the POST method might not result in a resource that can be identified by a URI. In this case, either 950 200 (OK) or 204 (No Content) is the appropriate response status code, depending on whether or not the response includes a 951 representation that describes the result. 952 </p> 953 <p id="rfc.section.2.3.4.p.4">If a resource has been created on the origin server, the response <em class="bcp14">SHOULD</em> be 201 (Created) and contain a representation which describes the status of the request and refers to the new resource, and 954 a Location header field (see <a href="#header.location" id="rfc.xref.header.location.1" title="Location">Section 7.5</a>). 955 </p> 956 <p id="rfc.section.2.3.4.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.4"><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.1"><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. 957 </p> 958 <p id="rfc.section.2.3.4.p.6">Note that POST caching is not widely implemented. However, the 303 (See Other) response can be used to direct the user agent 959 to retrieve a cacheable representation of the resource. 960 </p> 961 <div id="rfc.iref.p.2"></div> 962 <div id="rfc.iref.m.5"></div> 963 <h3 id="rfc.section.2.3.5"><a href="#rfc.section.2.3.5">2.3.5</a> <a id="PUT" href="#PUT">PUT</a></h3> 964 <p id="rfc.section.2.3.5.p.1">The PUT method requests that the state of the target resource be created or replaced with the state defined by the representation 965 enclosed in the request message payload. A successful PUT of a given representation would suggest that a subsequent GET on 966 that same target resource will result in an equivalent representation being returned in a 200 (OK) response. However, there 967 is no guarantee that such a state change will be observable, since the target resource might be acted upon by other user agents 968 in parallel, or might be subject to dynamic processing by the origin server, before any subsequent GET is received. A successful 969 response only implies that the user agent's intent was achieved at the time of its processing by the origin server. 970 </p> 971 <p id="rfc.section.2.3.5.p.2">If the target resource does not have a current representation and the PUT successfully creates one, then the origin server <em class="bcp14">MUST</em> inform the user agent by sending a 201 (Created) response. If the target resource does have a current representation and that 972 representation is successfully modified in accordance with the state of the enclosed representation, then either a 200 (OK) 973 or 204 (No Content) response <em class="bcp14">SHOULD</em> be sent to indicate successful completion of the request. 974 </p> 975 <p id="rfc.section.2.3.5.p.3">Unrecognized header fields <em class="bcp14">SHOULD</em> be ignored (i.e., not saved as part of the resource state). 976 </p> 977 <p id="rfc.section.2.3.5.p.4">An origin server <em class="bcp14">SHOULD</em> verify that the PUT representation is consistent with any constraints which the server has for the target resource that cannot 978 or will not be changed by the PUT. This is particularly important when the origin server uses internal configuration information 979 related to the URI in order to set the values for representation metadata on GET responses. When a PUT representation is inconsistent 980 with the target resource, the origin server <em class="bcp14">SHOULD</em> either make them consistent, by transforming the representation or changing the resource configuration, or respond with an 981 appropriate error message containing sufficient information to explain why the representation is unsuitable. The 409 (Conflict) 982 or 415 (Unsupported Media Type) status codes are suggested, with the latter being specific to constraints on Content-Type 983 values. 984 </p> 985 <p id="rfc.section.2.3.5.p.5">For example, if the target resource is configured to always have a Content-Type of "text/html" and the representation being 986 PUT has a Content-Type of "image/jpeg", then the origin server <em class="bcp14">SHOULD</em> do one of: (a) reconfigure the target resource to reflect the new media type; (b) transform the PUT representation to a format 987 consistent with that of the resource before saving it as the new resource state; or, (c) reject the request with a 415 response 988 indicating that the target resource is limited to "text/html", perhaps including a link to a different resource that would 989 be a suitable target for the new representation. 990 </p> 991 <p id="rfc.section.2.3.5.p.6">HTTP does not define exactly how a PUT method affects the state of an origin server beyond what can be expressed by the intent 992 of the user agent request and the semantics of the origin server response. It does not define what a resource might be, in 993 any sense of that word, beyond the interface provided via HTTP. It does not define how resource state is "stored", nor how 994 such storage might change as a result of a change in resource state, nor how the origin server translates resource state into 995 representations. Generally speaking, all implementation details behind the resource interface are intentionally hidden by 996 the server. 997 </p> 998 <p id="rfc.section.2.3.5.p.7">The fundamental difference between the POST and PUT methods is highlighted by the different intent for the target resource. 999 The target resource in a POST request is intended to handle the enclosed representation as a data-accepting process, such 1000 as for a gateway to some other protocol or a document that accepts annotations. In contrast, the target resource in a PUT 1001 request is intended to take the enclosed representation as a new or replacement value. Hence, the intent of PUT is idempotent 1002 and visible to intermediaries, even though the exact effect is only known by the origin server. 1003 </p> 1004 <p id="rfc.section.2.3.5.p.8">Proper interpretation of a PUT request presumes that the user agent knows what target resource is desired. A service that 1005 is intended to select a proper URI on behalf of the client, after receiving a state-changing request, <em class="bcp14">SHOULD</em> be implemented using the POST method rather than PUT. If the origin server will not make the requested PUT state change to 1006 the target resource and instead wishes to have it applied to a different resource, such as when the resource has been moved 1007 to a different URI, then the origin server <em class="bcp14">MUST</em> send a 301 (Moved Permanently) response; the user agent <em class="bcp14">MAY</em> then make its own decision regarding whether or not to redirect the request. 1008 </p> 1009 <p id="rfc.section.2.3.5.p.9">A PUT request applied to the target resource <em class="bcp14">MAY</em> have side-effects on other resources. For example, an article might have a URI for identifying "the current version" (a resource) 1010 which is separate from the URIs identifying each particular version (different resources that at one point shared the same 1011 state as the current version resource). A successful PUT request on "the current version" URI might therefore create a new 1012 version resource in addition to changing the state of the target resource, and might also cause links to be added between 1013 the related resources. 1014 </p> 1015 <p id="rfc.section.2.3.5.p.10">An origin server <em class="bcp14">SHOULD</em> reject any PUT request that contains a Content-Range header field, since it might be misinterpreted as partial content (or 1016 might be partial content that is being mistakenly PUT as a full representation). Partial content updates are possible by targeting 1017 a separately identified resource with state that overlaps a portion of the larger resource, or by using a different method 1018 that has been specifically defined for partial updates (for example, the PATCH method defined in <a href="#RFC5789" id="rfc.xref.RFC5789.1"><cite title="PATCH Method for HTTP">[RFC5789]</cite></a>). 1019 </p> 1020 <p id="rfc.section.2.3.5.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 1021 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.6</a> of <a href="#Part6" id="rfc.xref.Part6.5"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>). 1022 </p> 1023 <div id="rfc.iref.d.1"></div> 1024 <div id="rfc.iref.m.6"></div> 1025 <h3 id="rfc.section.2.3.6"><a href="#rfc.section.2.3.6">2.3.6</a> <a id="DELETE" href="#DELETE">DELETE</a></h3> 1026 <p id="rfc.section.2.3.6.p.1">The DELETE method requests that the origin server delete the target resource. This method <em class="bcp14">MAY</em> be overridden by human intervention (or other means) on the origin server. The client cannot be guaranteed that the operation 1027 has been carried out, even if the status code returned from the origin server indicates that the action has been completed 1028 successfully. However, the server <em class="bcp14">SHOULD NOT</em> indicate success unless, at the time the response is given, it intends to delete the resource or move it to an inaccessible 1029 location. 1030 </p> 1031 <p id="rfc.section.2.3.6.p.2">A successful response <em class="bcp14">SHOULD</em> be 200 (OK) if the response includes an representation describing the status, 202 (Accepted) if the action has not yet been 1032 enacted, or 204 (No Content) if the action has been enacted but the response does not include a representation. 1033 </p> 1034 <p id="rfc.section.2.3.6.p.3">Bodies on DELETE requests have no defined semantics. Note that sending a body on a DELETE request might cause some existing 1035 implementations to reject the request. 1036 </p> 1037 <p id="rfc.section.2.3.6.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 1038 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.6</a> of <a href="#Part6" id="rfc.xref.Part6.6"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>). 1039 </p> 1040 <h3 id="rfc.section.2.3.7"><a href="#rfc.section.2.3.7">2.3.7</a> <a id="TRACE" href="#TRACE">TRACE</a></h3> 1041 <div id="rfc.iref.t.1"></div> 1042 <div id="rfc.iref.m.7"></div> 1043 <p id="rfc.section.2.3.7.p.1">The TRACE method requests a remote, application-layer loop-back of the request message. The final recipient of the request <em class="bcp14">SHOULD</em> reflect the message received back to the client as the message body of a 200 (OK) response. The final recipient is either 1044 the origin server or the first proxy to receive a Max-Forwards value of zero (0) in the request (see <a href="#header.max-forwards" id="rfc.xref.header.max-forwards.2" title="Max-Forwards">Section 7.6</a>). A TRACE request <em class="bcp14">MUST NOT</em> include a message body. 1045 </p> 1046 <p id="rfc.section.2.3.7.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 1047 or diagnostic information. The value of the Via header field (<a href="p1-messaging.html#header.via" title="Via">Section 6.2</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>) is of particular interest, since it acts as a trace of the request chain. Use of the Max-Forwards header field allows the 1048 client to limit the length of the request chain, which is useful for testing a chain of proxies forwarding messages in an 1049 infinite loop. 1050 </p> 1051 <p id="rfc.section.2.3.7.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 7.3.1</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>) and contain a message body that encloses a copy of the entire request message. Responses to the TRACE method are not cacheable. 1052 </p> 1053 <div id="rfc.iref.c.1"></div> 1054 <div id="rfc.iref.m.8"></div> 1055 <h3 id="rfc.section.2.3.8"><a href="#rfc.section.2.3.8">2.3.8</a> <a id="CONNECT" href="#CONNECT">CONNECT</a></h3> 1056 <p id="rfc.section.2.3.8.p.1">The CONNECT method requests that the proxy establish a tunnel to the request-target and, if successful, thereafter restrict 1057 its behavior to blind forwarding of packets until the connection is closed. 1058 </p> 1059 <p id="rfc.section.2.3.8.p.2">When using CONNECT, the request-target <em class="bcp14">MUST</em> use the authority form (<a href="p1-messaging.html#request-target" title="Request Target">Section 5.3</a> of <a href="#Part1" id="rfc.xref.Part1.20"><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. 1060 For example, 1061 </p> 1062 <div id="rfc.figure.u.4"></div><pre class="text2">CONNECT server.example.com:80 HTTP/1.1 1063 Host: server.example.com:80 1064 1065 </pre><p id="rfc.section.2.3.8.p.4">Any successful (2xx) response to a CONNECT request indicates that the proxy has established a connection to the requested 1066 host and port, and has switched to tunneling the current connection to that server connection. The tunneled data from the 1067 server begins immediately after the blank line that concludes the successful response's header block. A server <em class="bcp14">SHOULD NOT</em> send any Transfer-Encoding or Content-Length header fields in a successful response. A client <em class="bcp14">MUST</em> ignore any Content-Length or Transfer-Encoding header fields received in a successful response. 1068 </p> 1069 <p id="rfc.section.2.3.8.p.5">Any response other than a successful response indicates that the tunnel has not yet been formed and that the connection remains 1070 governed by HTTP. 1071 </p> 1072 <p id="rfc.section.2.3.8.p.6">Proxy authentication might be used to establish the authority to create a tunnel:</p> 1073 <div id="rfc.figure.u.5"></div><pre class="text2">CONNECT server.example.com:80 HTTP/1.1 1074 Host: server.example.com:80 1075 Proxy-Authorization: basic aGVsbG86d29ybGQ= 1076 1077 </pre><p id="rfc.section.2.3.8.p.8">A message body on a CONNECT request has no defined semantics. Sending a body on a CONNECT request might cause existing implementations 1078 to reject the request. 1079 </p> 1080 <p id="rfc.section.2.3.8.p.9">Similar to a pipelined HTTP/1.1 request, data to be tunneled from client to server <em class="bcp14">MAY</em> be sent immediately after the request (before a response is received). The usual caveats also apply: data may be discarded 1081 if the eventual response is negative, and the connection may be reset with no response if more than one TCP segment is outstanding. 1082 </p> 1083 <p id="rfc.section.2.3.8.p.10">It may be the case that the proxy itself can only reach the requested origin server through another proxy. In this case, the 1084 first proxy <em class="bcp14">SHOULD</em> make a CONNECT request of that next proxy, requesting a tunnel to the authority. A proxy <em class="bcp14">MUST NOT</em> respond with any 2xx status code unless it has either a direct or tunnel connection established to the authority. 1085 </p> 1086 <p id="rfc.section.2.3.8.p.11">If at any point either one of the peers gets disconnected, any outstanding data that came from that peer will be passed to 1087 the other one, and after that also the other connection will be terminated by the proxy. If there is outstanding data to that 1088 peer undelivered, that data will be discarded. 1089 </p> 1090 <p id="rfc.section.2.3.8.p.12">An origin server which receives a CONNECT request for itself <em class="bcp14">MAY</em> respond with a 2xx status code to indicate that a connection is established. However, most origin servers do not implement 1091 CONNECT. 900 1092 </p> 901 1093 <h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a> <a id="header.fields" href="#header.fields">Header Fields</a></h1> 902 1094 <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, 903 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.1095 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.21"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for a general definition of their syntax. 904 1096 </p> 905 1097 <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> … … 909 1101 with "X-" if they are to be registered (either immediately or in the future). 910 1102 </p> 911 <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 extension defined in <a href="p1-messaging.html#abnf.extension" title="ABNF list extension: #rule">Section 3.2.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> as necessary, and are usually constrained to the range of ASCII characters. Header fields needing a greater range of characters1103 <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 extension defined in <a href="p1-messaging.html#abnf.extension" title="ABNF list extension: #rule">Section 3.2.5</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> as necessary, and are usually constrained to the range of ASCII characters. Header fields needing a greater range of characters 912 1104 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>. 913 1105 </p> 914 1106 <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 915 1107 in the field-value's payload. Typically, components that might contain a comma are protected with double-quotes using the 916 quoted-string ABNF production (<a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.4</a> of <a href="#Part1" id="rfc.xref.Part1. 19"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).1108 quoted-string ABNF production (<a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.4</a> of <a href="#Part1" id="rfc.xref.Part1.23"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). 917 1109 </p> 918 1110 <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 919 1111 these: 920 1112 </p> 921 <div id="rfc.figure.u. 4"></div><pre class="text"> Example-URI-Field: "http://example.com/a.html,foo",1113 <div id="rfc.figure.u.6"></div><pre class="text"> Example-URI-Field: "http://example.com/a.html,foo", 922 1114 "http://without-a-comma.example.com/" 923 1115 Example-Date-Field: "Sat, 04 May 1996", "Wed, 14 Sep 2005" … … 925 1117 double quotes will likely cause unnecessary confusion. 926 1118 </p> 927 <p id="rfc.section.3.1.p.8">Many header fields use a format including (case-insensitively) named parameters (for instance, Content-Type, defined in <a href="p3-payload.html#header.content-type" title="Content-Type">Section 6.8</a> of <a href="#Part3" id="rfc.xref.Part3. 1"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>). Allowing both unquoted (token) and quoted (quoted-string) syntax for the parameter value enables recipients to use existing1119 <p id="rfc.section.3.1.p.8">Many header fields use a format including (case-insensitively) named parameters (for instance, Content-Type, defined in <a href="p3-payload.html#header.content-type" title="Content-Type">Section 6.8</a> of <a href="#Part3" id="rfc.xref.Part3.2"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>). Allowing both unquoted (token) and quoted (quoted-string) syntax for the parameter value enables recipients to use existing 928 1120 parser components. When allowing both forms, the meaning of a parameter value ought to be independent of the syntax used for 929 it (for an example, see the notes on parameter handling for media types in <a href="p3-payload.html#media.types" title="Media Types">Section 2.3</a> of <a href="#Part3" id="rfc.xref.Part3. 2"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>).1121 it (for an example, see the notes on parameter handling for media types in <a href="p3-payload.html#media.types" title="Media Types">Section 2.3</a> of <a href="#Part3" id="rfc.xref.Part3.3"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>). 930 1122 </p> 931 1123 <p id="rfc.section.3.1.p.9">Authors of specifications defining new header fields are advised to consider documenting: </p> 932 1124 <ul> 933 1125 <li> 934 <p>Whether the field is a single value, or whether it can be a list (delimited by commas; see <a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.2 0"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).1126 <p>Whether the field is a single value, or whether it can be a list (delimited by commas; see <a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.24"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). 935 1127 </p> 936 1128 <p>If it does not use the list syntax, document how to treat messages where the header field occurs multiple times (a sensible … … 948 1140 </li> 949 1141 <li> 950 <p>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 6.1</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>).1142 <p>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 6.1</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>). 951 1143 </p> 952 1144 </li> … … 955 1147 </li> 956 1148 <li> 957 <p>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>).1149 <p>How the header might interact with caching (see <a href="#Part6" id="rfc.xref.Part6.7"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>). 958 1150 </p> 959 1151 </li> 960 1152 <li> 961 <p>Whether the header field is useful or allowable in trailers (see <a href="p1-messaging.html#chunked.encoding" title="Chunked Transfer Coding">Section 4.1</a> of <a href="#Part1" id="rfc.xref.Part1.2 2"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).1153 <p>Whether the header field is useful or allowable in trailers (see <a href="p1-messaging.html#chunked.encoding" title="Chunked Transfer Coding">Section 4.1</a> of <a href="#Part1" id="rfc.xref.Part1.26"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). 962 1154 </p> 963 1155 </li> … … 971 1163 method invocation. 972 1164 </p> 973 <div id="rfc.table.u. 2">1165 <div id="rfc.table.u.1"> 974 1166 <table class="tt full left" cellpadding="3" cellspacing="0"> 975 1167 <thead> … … 982 1174 <tr> 983 1175 <td class="left">Accept</td> 984 <td class="left"><a href="p3-payload.html#header.accept" title="Accept">Section 6.1</a> of <a href="#Part3" id="rfc.xref.Part3. 3"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a></td>1176 <td class="left"><a href="p3-payload.html#header.accept" title="Accept">Section 6.1</a> of <a href="#Part3" id="rfc.xref.Part3.4"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a></td> 985 1177 </tr> 986 1178 <tr> 987 1179 <td class="left">Accept-Charset</td> 988 <td class="left"><a href="p3-payload.html#header.accept-charset" title="Accept-Charset">Section 6.2</a> of <a href="#Part3" id="rfc.xref.Part3. 4"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a></td>1180 <td class="left"><a href="p3-payload.html#header.accept-charset" title="Accept-Charset">Section 6.2</a> of <a href="#Part3" id="rfc.xref.Part3.5"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a></td> 989 1181 </tr> 990 1182 <tr> 991 1183 <td class="left">Accept-Encoding</td> 992 <td class="left"><a href="p3-payload.html#header.accept-encoding" title="Accept-Encoding">Section 6.3</a> of <a href="#Part3" id="rfc.xref.Part3. 5"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a></td>1184 <td class="left"><a href="p3-payload.html#header.accept-encoding" title="Accept-Encoding">Section 6.3</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></td> 993 1185 </tr> 994 1186 <tr> 995 1187 <td class="left">Accept-Language</td> 996 <td class="left"><a href="p3-payload.html#header.accept-language" title="Accept-Language">Section 6.4</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></td>1188 <td class="left"><a href="p3-payload.html#header.accept-language" title="Accept-Language">Section 6.4</a> of <a href="#Part3" id="rfc.xref.Part3.7"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a></td> 997 1189 </tr> 998 1190 <tr> … … 1002 1194 <tr> 1003 1195 <td class="left">Expect</td> 1004 <td class="left"><a href="#header.expect" id="rfc.xref.header.expect.1" title="Expect">Section 8.3</a></td>1196 <td class="left"><a href="#header.expect" id="rfc.xref.header.expect.1" title="Expect">Section 7.3</a></td> 1005 1197 </tr> 1006 1198 <tr> 1007 1199 <td class="left">From</td> 1008 <td class="left"><a href="#header.from" id="rfc.xref.header.from.1" title="From">Section 8.4</a></td>1200 <td class="left"><a href="#header.from" id="rfc.xref.header.from.1" title="From">Section 7.4</a></td> 1009 1201 </tr> 1010 1202 <tr> 1011 1203 <td class="left">Host</td> 1012 <td class="left"><a href="p1-messaging.html#header.host" title="Host">Section 5.4</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></td>1204 <td class="left"><a href="p1-messaging.html#header.host" title="Host">Section 5.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></td> 1013 1205 </tr> 1014 1206 <tr> … … 1026 1218 <tr> 1027 1219 <td class="left">If-Range</td> 1028 <td class="left"><a href="p5-range.html#header.if-range" title="If-Range">Section 5.3</a> of <a href="#Part5" id="rfc.xref.Part5. 1"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a></td>1220 <td class="left"><a href="p5-range.html#header.if-range" title="If-Range">Section 5.3</a> of <a href="#Part5" id="rfc.xref.Part5.2"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a></td> 1029 1221 </tr> 1030 1222 <tr> … … 1034 1226 <tr> 1035 1227 <td class="left">Max-Forwards</td> 1036 <td class="left"><a href="#header.max-forwards" id="rfc.xref.header.max-forwards. 1" title="Max-Forwards">Section 8.6</a></td>1228 <td class="left"><a href="#header.max-forwards" id="rfc.xref.header.max-forwards.3" title="Max-Forwards">Section 7.6</a></td> 1037 1229 </tr> 1038 1230 <tr> … … 1042 1234 <tr> 1043 1235 <td class="left">Range</td> 1044 <td class="left"><a href="p5-range.html#header.range" title="Range">Section 5.4</a> of <a href="#Part5" id="rfc.xref.Part5. 2"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a></td>1236 <td class="left"><a href="p5-range.html#header.range" title="Range">Section 5.4</a> of <a href="#Part5" id="rfc.xref.Part5.3"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a></td> 1045 1237 </tr> 1046 1238 <tr> 1047 1239 <td class="left">Referer</td> 1048 <td class="left"><a href="#header.referer" id="rfc.xref.header.referer.1" title="Referer">Section 8.7</a></td>1240 <td class="left"><a href="#header.referer" id="rfc.xref.header.referer.1" title="Referer">Section 7.7</a></td> 1049 1241 </tr> 1050 1242 <tr> 1051 1243 <td class="left">TE</td> 1052 <td class="left"><a href="p1-messaging.html#header.te" title="TE">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.2 4"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a></td>1244 <td class="left"><a href="p1-messaging.html#header.te" title="TE">Section 4.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></td> 1053 1245 </tr> 1054 1246 <tr> 1055 1247 <td class="left">User-Agent</td> 1056 <td class="left"><a href="#header.user-agent" id="rfc.xref.header.user-agent.1" title="User-Agent">Section 8.10</a></td>1248 <td class="left"><a href="#header.user-agent" id="rfc.xref.header.user-agent.1" title="User-Agent">Section 7.10</a></td> 1057 1249 </tr> 1058 1250 </tbody> … … 1061 1253 <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> 1062 1254 <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 1063 status-line. These header fields give information about the server and about further access to the target resource (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 5.5</a> of <a href="#Part1" id="rfc.xref.Part1.2 5"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).1064 </p> 1065 <div id="rfc.table.u. 3">1255 status-line. These header fields give information about the server and about further access to the target resource (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 5.5</a> of <a href="#Part1" id="rfc.xref.Part1.29"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). 1256 </p> 1257 <div id="rfc.table.u.2"> 1066 1258 <table class="tt full left" cellpadding="3" cellspacing="0"> 1067 1259 <thead> … … 1074 1266 <tr> 1075 1267 <td class="left">Accept-Ranges</td> 1076 <td class="left"><a href="p5-range.html#header.accept-ranges" title="Accept-Ranges">Section 5.1</a> of <a href="#Part5" id="rfc.xref.Part5. 3"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a></td>1268 <td class="left"><a href="p5-range.html#header.accept-ranges" title="Accept-Ranges">Section 5.1</a> of <a href="#Part5" id="rfc.xref.Part5.4"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a></td> 1077 1269 </tr> 1078 1270 <tr> 1079 1271 <td class="left">Age</td> 1080 <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>1272 <td class="left"><a href="p6-cache.html#header.age" title="Age">Section 3.1</a> of <a href="#Part6" id="rfc.xref.Part6.8"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a></td> 1081 1273 </tr> 1082 1274 <tr> 1083 1275 <td class="left">Allow</td> 1084 <td class="left"><a href="#header.allow" id="rfc.xref.header.allow.2" title="Allow">Section 8.1</a></td>1276 <td class="left"><a href="#header.allow" id="rfc.xref.header.allow.2" title="Allow">Section 7.1</a></td> 1085 1277 </tr> 1086 1278 <tr> 1087 1279 <td class="left">Date</td> 1088 <td class="left"><a href="#header.date" id="rfc.xref.header.date.1" title="Date">Section 8.2</a></td>1280 <td class="left"><a href="#header.date" id="rfc.xref.header.date.1" title="Date">Section 7.2</a></td> 1089 1281 </tr> 1090 1282 <tr> … … 1094 1286 <tr> 1095 1287 <td class="left">Location</td> 1096 <td class="left"><a href="#header.location" id="rfc.xref.header.location. 1" title="Location">Section 8.5</a></td>1288 <td class="left"><a href="#header.location" id="rfc.xref.header.location.2" title="Location">Section 7.5</a></td> 1097 1289 </tr> 1098 1290 <tr> … … 1102 1294 <tr> 1103 1295 <td class="left">Retry-After</td> 1104 <td class="left"><a href="#header.retry-after" id="rfc.xref.header.retry-after.1" title="Retry-After">Section 8.8</a></td>1296 <td class="left"><a href="#header.retry-after" id="rfc.xref.header.retry-after.1" title="Retry-After">Section 7.8</a></td> 1105 1297 </tr> 1106 1298 <tr> 1107 1299 <td class="left">Server</td> 1108 <td class="left"><a href="#header.server" id="rfc.xref.header.server.1" title="Server">Section 8.9</a></td>1300 <td class="left"><a href="#header.server" id="rfc.xref.header.server.1" title="Server">Section 7.9</a></td> 1109 1301 </tr> 1110 1302 <tr> 1111 1303 <td class="left">Vary</td> 1112 <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>1304 <td class="left"><a href="p6-cache.html#header.vary" title="Vary">Section 3.5</a> of <a href="#Part6" id="rfc.xref.Part6.9"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a></td> 1113 1305 </tr> 1114 1306 <tr> … … 1124 1316 client does not need to examine or display the reason-phrase. 1125 1317 </p> 1126 <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>1318 <div id="rfc.figure.u.7"></div><pre class="inline"><span id="rfc.iref.g.3"></span><span id="rfc.iref.g.4"></span><span id="rfc.iref.g.5"></span> <a href="#status.code.and.reason.phrase" class="smpl">status-code</a> = 3<a href="#notation" class="smpl">DIGIT</a> 1127 1319 <a href="#status.code.and.reason.phrase" class="smpl">reason-phrase</a> = *( <a href="#notation" class="smpl">HTAB</a> / <a href="#notation" class="smpl">SP</a> / <a href="#notation" class="smpl">VCHAR</a> / <a href="#core.rules" class="smpl">obs-text</a> ) 1128 1320 </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, … … 1143 1335 </ul> 1144 1336 <h2 id="rfc.section.4.1"><a href="#rfc.section.4.1">4.1</a> <a id="overview.of.status.codes" href="#overview.of.status.codes">Overview of Status Codes</a></h2> 1145 <p id="rfc.section.4.1.p.1">The status codes listed below are defined in <a href="#status.codes" title="Status Code Definitions">Section 4.3</a> of this specification, <a href="p4-conditional.html#status.code.definitions" title="Status Code Definitions">Section 4</a> of <a href="#Part4" id="rfc.xref.Part4.6"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>, <a href="p5-range.html#status.code.definitions" title="Status Code Definitions">Section 3</a> of <a href="#Part5" id="rfc.xref.Part5. 4"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>, and <a href="p7-auth.html#status.code.definitions" title="Status Code Definitions">Section 3</a> of <a href="#Part7" id="rfc.xref.Part7.5"><cite title="HTTP/1.1, part 7: Authentication">[Part7]</cite></a>. The reason phrases listed here are only recommendations — they can be replaced by local equivalents without affecting the1337 <p id="rfc.section.4.1.p.1">The status codes listed below are defined in <a href="#status.codes" title="Status Code Definitions">Section 4.3</a> of this specification, <a href="p4-conditional.html#status.code.definitions" title="Status Code Definitions">Section 4</a> of <a href="#Part4" id="rfc.xref.Part4.6"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>, <a href="p5-range.html#status.code.definitions" title="Status Code Definitions">Section 3</a> of <a href="#Part5" id="rfc.xref.Part5.5"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>, and <a href="p7-auth.html#status.code.definitions" title="Status Code Definitions">Section 3</a> of <a href="#Part7" id="rfc.xref.Part7.5"><cite title="HTTP/1.1, part 7: Authentication">[Part7]</cite></a>. The reason phrases listed here are only recommendations — they can be replaced by local equivalents without affecting the 1146 1338 protocol. 1147 1339 </p> 1148 <div id="rfc.table.u. 4">1340 <div id="rfc.table.u.3"> 1149 1341 <table class="tt full left" cellpadding="3" cellspacing="0"> 1150 1342 <thead> … … 1199 1391 <td class="left">206</td> 1200 1392 <td class="left">Partial Content</td> 1201 <td id="status.206" class="left"><a href="p5-range.html#status.206" title="206 Partial Content">Section 3.1</a> of <a href="#Part5" id="rfc.xref.Part5. 5"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a></td>1393 <td id="status.206" class="left"><a href="p5-range.html#status.206" title="206 Partial Content">Section 3.1</a> of <a href="#Part5" id="rfc.xref.Part5.6"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a></td> 1202 1394 </tr> 1203 1395 <tr> … … 1319 1511 <td class="left">416</td> 1320 1512 <td class="left">Requested range not satisfiable</td> 1321 <td id="status.416" class="left"><a href="p5-range.html#status.416" title="416 Requested Range Not Satisfiable">Section 3.2</a> of <a href="#Part5" id="rfc.xref.Part5. 6"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a></td>1513 <td id="status.416" class="left"><a href="p5-range.html#status.416" title="416 Requested Range Not Satisfiable">Section 3.2</a> of <a href="#Part5" id="rfc.xref.Part5.7"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a></td> 1322 1514 </tr> 1323 1515 <tr> … … 1386 1578 a zero-length response body. They can require the presence of one or more particular HTTP response header(s). 1387 1579 </p> 1388 <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).1580 <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.10"><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). 1389 1581 </p> 1390 1582 <h2 id="rfc.section.4.3"><a href="#rfc.section.4.3">4.3</a> <a id="status.codes" href="#status.codes">Status Code Definitions</a></h2> 1391 1583 <p id="rfc.section.4.3.p.1">Each status-code is described below, including any metadata required in the response.</p> 1392 1584 <p id="rfc.section.4.3.p.2">For most status codes the response can carry a payload, in which case a Content-Type header field indicates the payload's 1393 media type (<a href="p3-payload.html#header.content-type" title="Content-Type">Section 6.8</a> of <a href="#Part3" id="rfc.xref.Part3. 7"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>).1585 media type (<a href="p3-payload.html#header.content-type" title="Content-Type">Section 6.8</a> of <a href="#Part3" id="rfc.xref.Part3.8"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>). 1394 1586 </p> 1395 1587 <h3 id="rfc.section.4.3.1"><a href="#rfc.section.4.3.1">4.3.1</a> <a id="status.1xx" href="#status.1xx">Informational 1xx</a></h3> … … 1405 1597 a request, then it need not forward the corresponding 100 (Continue) response(s).) 1406 1598 </p> 1407 <div id="rfc.iref. 4"></div>1408 <div id="rfc.iref.s. 1"></div>1599 <div id="rfc.iref.22"></div> 1600 <div id="rfc.iref.s.2"></div> 1409 1601 <h4 id="rfc.section.4.3.1.1"><a href="#rfc.section.4.3.1.1">4.3.1.1</a> <a id="status.100" href="#status.100">100 Continue</a></h4> 1410 1602 <p id="rfc.section.4.3.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 1411 1603 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 1412 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 6.4.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> for detailed discussion of the use and handling of this status code.1413 </p> 1414 <div id="rfc.iref. 5"></div>1415 <div id="rfc.iref.s. 2"></div>1604 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 6.4.3</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> for detailed discussion of the use and handling of this status code. 1605 </p> 1606 <div id="rfc.iref.23"></div> 1607 <div id="rfc.iref.s.3"></div> 1416 1608 <h4 id="rfc.section.4.3.1.2"><a href="#rfc.section.4.3.1.2">4.3.1.2</a> <a id="status.101" href="#status.101">101 Switching Protocols</a></h4> 1417 <p id="rfc.section.4.3.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 6.5</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>), for a change in the application protocol being used on this connection. The server will switch protocols to those defined1609 <p id="rfc.section.4.3.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 6.5</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 a change in the application protocol being used on this connection. The server will switch protocols to those defined 1418 1610 by the response's Upgrade header field immediately after the empty line which terminates the 101 response. 1419 1611 </p> … … 1424 1616 <h3 id="rfc.section.4.3.2"><a href="#rfc.section.4.3.2">4.3.2</a> <a id="status.2xx" href="#status.2xx">Successful 2xx</a></h3> 1425 1617 <p id="rfc.section.4.3.2.p.1">This class of status code indicates that the client's request was successfully received, understood, and accepted.</p> 1426 <div id="rfc.iref. 6"></div>1427 <div id="rfc.iref.s. 3"></div>1618 <div id="rfc.iref.24"></div> 1619 <div id="rfc.iref.s.4"></div> 1428 1620 <h4 id="rfc.section.4.3.2.1"><a href="#rfc.section.4.3.2.1">4.3.2.1</a> <a id="status.200" href="#status.200">200 OK</a></h4> 1429 1621 <p id="rfc.section.4.3.2.1.p.1">The request has succeeded. The payload returned with the response is dependent on the method used in the request, for example: </p> … … 1438 1630 <dd>a representation containing the request message as received by the end server.</dd> 1439 1631 </dl> 1440 <p id="rfc.section.4.3.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. 6"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) to determine freshness for 200 responses.1441 </p> 1442 <div id="rfc.iref. 7"></div>1443 <div id="rfc.iref.s. 4"></div>1632 <p id="rfc.section.4.3.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. 1633 </p> 1634 <div id="rfc.iref.25"></div> 1635 <div id="rfc.iref.s.5"></div> 1444 1636 <h4 id="rfc.section.4.3.2.2"><a href="#rfc.section.4.3.2.2">4.3.2.2</a> <a id="status.201" href="#status.201">201 Created</a></h4> 1445 1637 <p id="rfc.section.4.3.2.2.p.1">The request has been fulfilled and has resulted in a new resource being created.</p> … … 1453 1645 just created (see <a href="p4-conditional.html#header.etag" title="ETag">Section 2.3</a> of <a href="#Part4" id="rfc.xref.Part4.9"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>). 1454 1646 </p> 1455 <div id="rfc.iref. 8"></div>1456 <div id="rfc.iref.s. 5"></div>1647 <div id="rfc.iref.26"></div> 1648 <div id="rfc.iref.s.6"></div> 1457 1649 <h4 id="rfc.section.4.3.2.3"><a href="#rfc.section.4.3.2.3">4.3.2.3</a> <a id="status.202" href="#status.202">202 Accepted</a></h4> 1458 1650 <p id="rfc.section.4.3.2.3.p.1">The request has been accepted for processing, but the processing has not been completed. The request might or might not eventually … … 1465 1657 user can expect the request to be fulfilled. 1466 1658 </p> 1467 <div id="rfc.iref. 9"></div>1468 <div id="rfc.iref.s. 6"></div>1659 <div id="rfc.iref.27"></div> 1660 <div id="rfc.iref.s.7"></div> 1469 1661 <h4 id="rfc.section.4.3.2.4"><a href="#rfc.section.4.3.2.4">4.3.2.4</a> <a id="status.203" href="#status.203">203 Non-Authoritative Information</a></h4> 1470 <p id="rfc.section.4.3.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.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>). Note that the behavior of transforming intermediaries is controlled by the no-transform Cache-Control directive (<a href="p6-cache.html#header.cache-control" title="Cache-Control">Section 3.2</a> of <a href="#Part6" id="rfc.xref.Part6.7"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>).1662 <p id="rfc.section.4.3.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.3</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>). Note that the behavior of transforming intermediaries is controlled by the no-transform Cache-Control directive (<a href="p6-cache.html#header.cache-control" title="Cache-Control">Section 3.2</a> of <a href="#Part6" id="rfc.xref.Part6.12"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>). 1471 1663 </p> 1472 1664 <p id="rfc.section.4.3.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 1473 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. 8"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) is appropriate.1474 </p> 1475 <p id="rfc.section.4.3.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. 9"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) to determine freshness for 203 responses.1476 </p> 1477 <div id="rfc.iref. 10"></div>1478 <div id="rfc.iref.s. 7"></div>1665 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. 1666 </p> 1667 <p id="rfc.section.4.3.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. 1668 </p> 1669 <div id="rfc.iref.28"></div> 1670 <div id="rfc.iref.s.8"></div> 1479 1671 <h4 id="rfc.section.4.3.2.5"><a href="#rfc.section.4.3.2.5">4.3.2.5</a> <a id="status.204" href="#status.204">204 No Content</a></h4> 1480 1672 <p id="rfc.section.4.3.2.5.p.1">The 204 (No Content) status code indicates that the server has successfully fulfilled the request and that there is no additional … … 1496 1688 <p id="rfc.section.4.3.2.5.p.5">The 204 response <em class="bcp14">MUST NOT</em> include a message body, and thus is always terminated by the first empty line after the header fields. 1497 1689 </p> 1498 <div id="rfc.iref. 11"></div>1499 <div id="rfc.iref.s. 8"></div>1690 <div id="rfc.iref.29"></div> 1691 <div id="rfc.iref.s.9"></div> 1500 1692 <h4 id="rfc.section.4.3.2.6"><a href="#rfc.section.4.3.2.6">4.3.2.6</a> <a id="status.205" href="#status.205">205 Reset Content</a></h4> 1501 1693 <p id="rfc.section.4.3.2.6.p.1">The server has fulfilled the request and the user agent <em class="bcp14">SHOULD</em> reset the document view which caused the request to be sent. This response is primarily intended to allow input for actions … … 1503 1695 another input action. 1504 1696 </p> 1505 <p id="rfc.section.4.3.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. 29"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>.1697 <p id="rfc.section.4.3.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.33"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. 1506 1698 </p> 1507 1699 <h3 id="rfc.section.4.3.3"><a href="#rfc.section.4.3.3">4.3.3</a> <a id="status.3xx" href="#status.3xx">Redirection 3xx</a></h3> 1508 1700 <p id="rfc.section.4.3.3.p.1">This class of status code indicates that further action needs to be taken by the user agent in order to fulfill the request. 1509 1701 If the required action involves a subsequent HTTP request, it <em class="bcp14">MAY</em> be carried out by the user agent without interaction with the user if and only if the method used in the second request is 1510 known to be "safe", as defined in <a href="#safe.methods" title="Safe Methods">Section 6.1.1</a>.1702 known to be "safe", as defined in <a href="#safe.methods" title="Safe Methods">Section 2.1.1</a>. 1511 1703 </p> 1512 1704 <p id="rfc.section.4.3.3.p.2">There are several types of redirects: </p> … … 1524 1716 </li> 1525 1717 <li> 1526 <p>Redirection offering a choice of matching resources for use by agent-driven content negotiation (<a href="p3-payload.html#agent-driven.negotiation" title="Agent-driven Negotiation">Section 5.2</a> of <a href="#Part3" id="rfc.xref.Part3. 8"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>). This is status code 300 (Multiple Choices).1718 <p>Redirection offering a choice of matching resources for use by agent-driven content negotiation (<a href="p3-payload.html#agent-driven.negotiation" title="Agent-driven Negotiation">Section 5.2</a> of <a href="#Part3" id="rfc.xref.Part3.9"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>). This is status code 300 (Multiple Choices). 1527 1719 </p> 1528 1720 </li> … … 1541 1733 </p> 1542 1734 </div> 1543 <p id="rfc.section.4.3.3.p.4">A Location header field on a 3xx response indicates that a client <em class="bcp14">MAY</em> automatically redirect to the URI provided; see <a href="#header.location" id="rfc.xref.header.location. 2" title="Location">Section 8.5</a>.1544 </p> 1545 <p id="rfc.section.4.3.3.p.5">Note that for methods not known to be "safe", as defined in <a href="#safe.methods" title="Safe Methods">Section 6.1.1</a>, automatic redirection needs to done with care, since the redirect might change the conditions under which the request was1735 <p id="rfc.section.4.3.3.p.4">A Location header field on a 3xx response indicates that a client <em class="bcp14">MAY</em> automatically redirect to the URI provided; see <a href="#header.location" id="rfc.xref.header.location.3" title="Location">Section 7.5</a>. 1736 </p> 1737 <p id="rfc.section.4.3.3.p.5">Note that for methods not known to be "safe", as defined in <a href="#safe.methods" title="Safe Methods">Section 2.1.1</a>, automatic redirection needs to done with care, since the redirect might change the conditions under which the request was 1546 1738 issued. 1547 1739 </p> … … 1552 1744 </p> 1553 1745 </div> 1554 <div id="rfc.iref. 12"></div>1555 <div id="rfc.iref.s. 9"></div>1746 <div id="rfc.iref.30"></div> 1747 <div id="rfc.iref.s.10"></div> 1556 1748 <h4 id="rfc.section.4.3.3.1"><a href="#rfc.section.4.3.3.1">4.3.3.1</a> <a id="status.300" href="#status.300">300 Multiple Choices</a></h4> 1557 1749 <p id="rfc.section.4.3.3.1.p.1">The target resource has more than one representation, each with its own specific location, and agent-driven negotiation information 1558 (<a href="p3-payload.html#content.negotiation" title="Content Negotiation">Section 5</a> of <a href="#Part3" id="rfc.xref.Part3. 9"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>) is being provided so that the user (or user agent) can select a preferred representation by redirecting its request to that1750 (<a href="p3-payload.html#content.negotiation" title="Content Negotiation">Section 5</a> of <a href="#Part3" id="rfc.xref.Part3.10"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>) is being provided so that the user (or user agent) can select a preferred representation by redirecting its request to that 1559 1751 location. 1560 1752 </p> … … 1565 1757 <p id="rfc.section.4.3.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. 1566 1758 </p> 1567 <p id="rfc.section.4.3.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 0"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) to determine freshness for 300 responses.1568 </p> 1569 <div id="rfc.iref. 13"></div>1570 <div id="rfc.iref.s.1 0"></div>1759 <p id="rfc.section.4.3.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.15"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) to determine freshness for 300 responses. 1760 </p> 1761 <div id="rfc.iref.31"></div> 1762 <div id="rfc.iref.s.11"></div> 1571 1763 <h4 id="rfc.section.4.3.3.2"><a href="#rfc.section.4.3.3.2">4.3.3.2</a> <a id="status.301" href="#status.301">301 Moved Permanently</a></h4> 1572 1764 <p id="rfc.section.4.3.3.2.p.1">The target resource has been assigned a new permanent URI and any future references to this resource <em class="bcp14">SHOULD</em> use one of the returned URIs. Clients with link editing capabilities ought to automatically re-link references to the effective 1573 1765 request URI to one or more of the new references returned by the server, where possible. 1574 1766 </p> 1575 <p id="rfc.section.4.3.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 1"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) to determine freshness for 301 responses.1767 <p id="rfc.section.4.3.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.16"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) to determine freshness for 301 responses. 1576 1768 </p> 1577 1769 <p id="rfc.section.4.3.3.2.p.3">The new permanent URI <em class="bcp14">SHOULD</em> be given by the Location field in the response. A response payload can contain a short hypertext note with a hyperlink to … … 1583 1775 </p> 1584 1776 </div> 1585 <div id="rfc.iref. 14"></div>1586 <div id="rfc.iref.s.1 1"></div>1777 <div id="rfc.iref.32"></div> 1778 <div id="rfc.iref.s.12"></div> 1587 1779 <h4 id="rfc.section.4.3.3.3"><a href="#rfc.section.4.3.3.3">4.3.3.3</a> <a id="status.302" href="#status.302">302 Found</a></h4> 1588 1780 <p id="rfc.section.4.3.3.3.p.1">The target resource resides temporarily under a different URI. Since the redirection might be altered on occasion, the client <em class="bcp14">SHOULD</em> continue to use the effective request URI for future requests. … … 1596 1788 </p> 1597 1789 </div> 1598 <div id="rfc.iref. 15"></div>1599 <div id="rfc.iref.s.1 2"></div>1790 <div id="rfc.iref.33"></div> 1791 <div id="rfc.iref.s.13"></div> 1600 1792 <h4 id="rfc.section.4.3.3.4"><a href="#rfc.section.4.3.3.4">4.3.3.4</a> <a id="status.303" href="#status.303">303 See Other</a></h4> 1601 1793 <p id="rfc.section.4.3.3.4.p.1">The 303 status code indicates that the server is redirecting the user agent to a different resource, as indicated by a URI … … 1617 1809 <p id="rfc.section.4.3.3.4.p.4">Except for responses to a HEAD request, the representation of a 303 response <em class="bcp14">SHOULD</em> contain a short hypertext note with a hyperlink to the Location URI. 1618 1810 </p> 1619 <div id="rfc.iref. 16"></div>1620 <div id="rfc.iref.s.1 3"></div>1811 <div id="rfc.iref.34"></div> 1812 <div id="rfc.iref.s.14"></div> 1621 1813 <h4 id="rfc.section.4.3.3.5"><a href="#rfc.section.4.3.3.5">4.3.3.5</a> <a id="status.305" href="#status.305">305 Use Proxy</a></h4> 1622 1814 <p id="rfc.section.4.3.3.5.p.1">The 305 status code was defined in a previous version of this specification (see <a href="#changes.from.rfc.2616" title="Changes from RFC 2616">Appendix A</a>), and is now deprecated. 1623 1815 </p> 1624 <div id="rfc.iref. 17"></div>1625 <div id="rfc.iref.s.1 4"></div>1816 <div id="rfc.iref.35"></div> 1817 <div id="rfc.iref.s.15"></div> 1626 1818 <h4 id="rfc.section.4.3.3.6"><a href="#rfc.section.4.3.3.6">4.3.3.6</a> <a id="status.306" href="#status.306">306 (Unused)</a></h4> 1627 1819 <p id="rfc.section.4.3.3.6.p.1">The 306 status code was used in a previous version of the specification, is no longer used, and the code is reserved.</p> 1628 <div id="rfc.iref. 18"></div>1629 <div id="rfc.iref.s.1 5"></div>1820 <div id="rfc.iref.36"></div> 1821 <div id="rfc.iref.s.16"></div> 1630 1822 <h4 id="rfc.section.4.3.3.7"><a href="#rfc.section.4.3.3.7">4.3.3.7</a> <a id="status.307" href="#status.307">307 Temporary Redirect</a></h4> 1631 1823 <p id="rfc.section.4.3.3.7.p.1">The target resource resides temporarily under a different URI. Since the redirection can change over time, the client <em class="bcp14">SHOULD</em> continue to use the effective request URI for future requests. … … 1644 1836 These status codes are applicable to any request method. User agents <em class="bcp14">SHOULD</em> display any included representation to the user. 1645 1837 </p> 1646 <div id="rfc.iref. 19"></div>1647 <div id="rfc.iref.s.1 6"></div>1838 <div id="rfc.iref.37"></div> 1839 <div id="rfc.iref.s.17"></div> 1648 1840 <h4 id="rfc.section.4.3.4.1"><a href="#rfc.section.4.3.4.1">4.3.4.1</a> <a id="status.400" href="#status.400">400 Bad Request</a></h4> 1649 1841 <p id="rfc.section.4.3.4.1.p.1">The server cannot or will not process the request, due to a client error (e.g., malformed syntax).</p> 1650 <div id="rfc.iref. 20"></div>1651 <div id="rfc.iref.s.1 7"></div>1842 <div id="rfc.iref.38"></div> 1843 <div id="rfc.iref.s.18"></div> 1652 1844 <h4 id="rfc.section.4.3.4.2"><a href="#rfc.section.4.3.4.2">4.3.4.2</a> <a id="status.402" href="#status.402">402 Payment Required</a></h4> 1653 1845 <p id="rfc.section.4.3.4.2.p.1">This code is reserved for future use.</p> 1654 <div id="rfc.iref. 21"></div>1655 <div id="rfc.iref.s.1 8"></div>1846 <div id="rfc.iref.39"></div> 1847 <div id="rfc.iref.s.19"></div> 1656 1848 <h4 id="rfc.section.4.3.4.3"><a href="#rfc.section.4.3.4.3">4.3.4.3</a> <a id="status.403" href="#status.403">403 Forbidden</a></h4> 1657 1849 <p id="rfc.section.4.3.4.3.p.1">The server understood the request, but refuses to authorize it. Providing different user authentication credentials might … … 1661 1853 to the client, the status code 404 (Not Found) <em class="bcp14">MAY</em> be used instead. 1662 1854 </p> 1663 <div id="rfc.iref. 22"></div>1664 <div id="rfc.iref.s. 19"></div>1855 <div id="rfc.iref.40"></div> 1856 <div id="rfc.iref.s.20"></div> 1665 1857 <h4 id="rfc.section.4.3.4.4"><a href="#rfc.section.4.3.4.4">4.3.4.4</a> <a id="status.404" href="#status.404">404 Not Found</a></h4> 1666 1858 <p id="rfc.section.4.3.4.4.p.1">The server has not found anything matching the effective request URI. No indication is given of whether the condition is temporary … … 1669 1861 has been refused, or when no other response is applicable. 1670 1862 </p> 1671 <div id="rfc.iref. 23"></div>1672 <div id="rfc.iref.s.2 0"></div>1863 <div id="rfc.iref.41"></div> 1864 <div id="rfc.iref.s.21"></div> 1673 1865 <h4 id="rfc.section.4.3.4.5"><a href="#rfc.section.4.3.4.5">4.3.4.5</a> <a id="status.405" href="#status.405">405 Method Not Allowed</a></h4> 1674 1866 <p id="rfc.section.4.3.4.5.p.1">The method specified in the request-line is not allowed for the target resource. The response <em class="bcp14">MUST</em> include an Allow header field containing a list of valid methods for the requested resource. 1675 1867 </p> 1676 <div id="rfc.iref. 24"></div>1677 <div id="rfc.iref.s.2 1"></div>1868 <div id="rfc.iref.42"></div> 1869 <div id="rfc.iref.s.22"></div> 1678 1870 <h4 id="rfc.section.4.3.4.6"><a href="#rfc.section.4.3.4.6">4.3.4.6</a> <a id="status.406" href="#status.406">406 Not Acceptable</a></h4> 1679 1871 <p id="rfc.section.4.3.4.6.p.1">The resource identified by the request is only capable of generating response representations which have content characteristics 1680 not acceptable according to the Accept and Accept-* header fields sent in the request (see <a href="p3-payload.html#header.field.definitions" title="Header Field Definitions">Section 6</a> of <a href="#Part3" id="rfc.xref.Part3.1 0"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>).1872 not acceptable according to the Accept and Accept-* header fields sent in the request (see <a href="p3-payload.html#header.field.definitions" title="Header Field Definitions">Section 6</a> of <a href="#Part3" id="rfc.xref.Part3.11"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>). 1681 1873 </p> 1682 1874 <p id="rfc.section.4.3.4.6.p.2">Unless it was a HEAD request, the response <em class="bcp14">SHOULD</em> include a representation containing a list of available representation characteristics and location(s) from which the user … … 1692 1884 <p id="rfc.section.4.3.4.6.p.4">If the response could be unacceptable, a user agent <em class="bcp14">SHOULD</em> temporarily stop receipt of more data and query the user for a decision on further actions. 1693 1885 </p> 1694 <div id="rfc.iref. 25"></div>1695 <div id="rfc.iref.s.2 2"></div>1886 <div id="rfc.iref.43"></div> 1887 <div id="rfc.iref.s.23"></div> 1696 1888 <h4 id="rfc.section.4.3.4.7"><a href="#rfc.section.4.3.4.7">4.3.4.7</a> <a id="status.408" href="#status.408">408 Request Timeout</a></h4> 1697 1889 <p id="rfc.section.4.3.4.7.p.1">The client did not produce a request within the time that the server was prepared to wait. The client <em class="bcp14">MAY</em> repeat the request without modifications at any later time. 1698 1890 </p> 1699 <div id="rfc.iref. 26"></div>1700 <div id="rfc.iref.s.2 3"></div>1891 <div id="rfc.iref.44"></div> 1892 <div id="rfc.iref.s.24"></div> 1701 1893 <h4 id="rfc.section.4.3.4.8"><a href="#rfc.section.4.3.4.8">4.3.4.8</a> <a id="status.409" href="#status.409">409 Conflict</a></h4> 1702 1894 <p id="rfc.section.4.3.4.8.p.1">The request could not be completed due to a conflict with the current state of the resource. This code is only allowed in … … 1710 1902 contain a list of the differences between the two versions. 1711 1903 </p> 1712 <div id="rfc.iref. 27"></div>1713 <div id="rfc.iref.s.2 4"></div>1904 <div id="rfc.iref.45"></div> 1905 <div id="rfc.iref.s.25"></div> 1714 1906 <h4 id="rfc.section.4.3.4.9"><a href="#rfc.section.4.3.4.9">4.3.4.9</a> <a id="status.410" href="#status.410">410 Gone</a></h4> 1715 1907 <p id="rfc.section.4.3.4.9.p.1">The target resource is no longer available at the server and no forwarding address is known. This condition is expected to … … 1723 1915 — that is left to the discretion of the server owner. 1724 1916 </p> 1725 <p id="rfc.section.4.3.4.9.p.3">Caches <em class="bcp14">MAY</em> use a heuristic (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 2.3.1.1</a> of <a href="#Part6" id="rfc.xref.Part6.1 2"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) to determine freshness for 410 responses.1726 </p> 1727 <div id="rfc.iref. 28"></div>1728 <div id="rfc.iref.s.2 5"></div>1917 <p id="rfc.section.4.3.4.9.p.3">Caches <em class="bcp14">MAY</em> use a heuristic (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 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 410 responses. 1918 </p> 1919 <div id="rfc.iref.46"></div> 1920 <div id="rfc.iref.s.26"></div> 1729 1921 <h4 id="rfc.section.4.3.4.10"><a href="#rfc.section.4.3.4.10">4.3.4.10</a> <a id="status.411" href="#status.411">411 Length Required</a></h4> 1730 1922 <p id="rfc.section.4.3.4.10.p.1">The server refuses to accept the request without a defined Content-Length. The client <em class="bcp14">MAY</em> repeat the request if it adds a valid Content-Length header field containing the length of the message body in the request 1731 1923 message. 1732 1924 </p> 1733 <div id="rfc.iref. 29"></div>1734 <div id="rfc.iref.s.2 6"></div>1925 <div id="rfc.iref.47"></div> 1926 <div id="rfc.iref.s.27"></div> 1735 1927 <h4 id="rfc.section.4.3.4.11"><a href="#rfc.section.4.3.4.11">4.3.4.11</a> <a id="status.413" href="#status.413">413 Request Representation Too Large</a></h4> 1736 1928 <p id="rfc.section.4.3.4.11.p.1">The server is refusing to process a request because the request representation is larger than the server is willing or able … … 1739 1931 <p id="rfc.section.4.3.4.11.p.2">If the condition is temporary, the server <em class="bcp14">SHOULD</em> include a Retry-After header field to indicate that it is temporary and after what time the client <em class="bcp14">MAY</em> try again. 1740 1932 </p> 1741 <div id="rfc.iref. 30"></div>1742 <div id="rfc.iref.s.2 7"></div>1933 <div id="rfc.iref.48"></div> 1934 <div id="rfc.iref.s.28"></div> 1743 1935 <h4 id="rfc.section.4.3.4.12"><a href="#rfc.section.4.3.4.12">4.3.4.12</a> <a id="status.414" href="#status.414">414 URI Too Long</a></h4> 1744 1936 <p id="rfc.section.4.3.4.12.p.1">The server is refusing to service the request because the effective request URI is longer than the server is willing to interpret. … … 1748 1940 in some servers using fixed-length buffers for reading or manipulating the request-target. 1749 1941 </p> 1750 <div id="rfc.iref. 31"></div>1751 <div id="rfc.iref.s.2 8"></div>1942 <div id="rfc.iref.49"></div> 1943 <div id="rfc.iref.s.29"></div> 1752 1944 <h4 id="rfc.section.4.3.4.13"><a href="#rfc.section.4.3.4.13">4.3.4.13</a> <a id="status.415" href="#status.415">415 Unsupported Media Type</a></h4> 1753 1945 <p id="rfc.section.4.3.4.13.p.1">The server is refusing to service the request because the request payload is in a format not supported by this request method 1754 1946 on the target resource. 1755 1947 </p> 1756 <div id="rfc.iref. 32"></div>1757 <div id="rfc.iref.s. 29"></div>1948 <div id="rfc.iref.50"></div> 1949 <div id="rfc.iref.s.30"></div> 1758 1950 <h4 id="rfc.section.4.3.4.14"><a href="#rfc.section.4.3.4.14">4.3.4.14</a> <a id="status.417" href="#status.417">417 Expectation Failed</a></h4> 1759 <p id="rfc.section.4.3.4.14.p.1">The expectation given in an Expect header field (see <a href="#header.expect" id="rfc.xref.header.expect.2" title="Expect">Section 8.3</a>) could not be met by this server, or, if the server is a proxy, the server has unambiguous evidence that the request could1951 <p id="rfc.section.4.3.4.14.p.1">The expectation given in an Expect header field (see <a href="#header.expect" id="rfc.xref.header.expect.2" title="Expect">Section 7.3</a>) could not be met by this server, or, if the server is a proxy, the server has unambiguous evidence that the request could 1760 1952 not be met by the next-hop server. 1761 1953 </p> 1762 <div id="rfc.iref. 33"></div>1763 <div id="rfc.iref.s.3 0"></div>1954 <div id="rfc.iref.51"></div> 1955 <div id="rfc.iref.s.31"></div> 1764 1956 <h4 id="rfc.section.4.3.4.15"><a href="#rfc.section.4.3.4.15">4.3.4.15</a> <a id="status.426" href="#status.426">426 Upgrade Required</a></h4> 1765 <p id="rfc.section.4.3.4.15.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 6.5</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>) specifying the required protocols.1766 </p> 1767 <div id="rfc.figure.u. 6"></div>1957 <p id="rfc.section.4.3.4.15.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 6.5</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>) specifying the required protocols. 1958 </p> 1959 <div id="rfc.figure.u.8"></div> 1768 1960 <p>Example:</p> <pre class="text">HTTP/1.1 426 Upgrade Required 1769 1961 Upgrade: HTTP/3.0 … … 1781 1973 User agents <em class="bcp14">SHOULD</em> display any included representation to the user. These response codes are applicable to any request method. 1782 1974 </p> 1783 <div id="rfc.iref. 34"></div>1784 <div id="rfc.iref.s.3 1"></div>1975 <div id="rfc.iref.52"></div> 1976 <div id="rfc.iref.s.32"></div> 1785 1977 <h4 id="rfc.section.4.3.5.1"><a href="#rfc.section.4.3.5.1">4.3.5.1</a> <a id="status.500" href="#status.500">500 Internal Server Error</a></h4> 1786 1978 <p id="rfc.section.4.3.5.1.p.1">The server encountered an unexpected condition which prevented it from fulfilling the request.</p> 1787 <div id="rfc.iref. 35"></div>1788 <div id="rfc.iref.s.3 2"></div>1979 <div id="rfc.iref.53"></div> 1980 <div id="rfc.iref.s.33"></div> 1789 1981 <h4 id="rfc.section.4.3.5.2"><a href="#rfc.section.4.3.5.2">4.3.5.2</a> <a id="status.501" href="#status.501">501 Not Implemented</a></h4> 1790 1982 <p id="rfc.section.4.3.5.2.p.1">The server does not support the functionality required to fulfill the request. This is the appropriate response when the server 1791 1983 does not recognize the request method and is not capable of supporting it for any resource. 1792 1984 </p> 1793 <div id="rfc.iref. 36"></div>1794 <div id="rfc.iref.s.3 3"></div>1985 <div id="rfc.iref.54"></div> 1986 <div id="rfc.iref.s.34"></div> 1795 1987 <h4 id="rfc.section.4.3.5.3"><a href="#rfc.section.4.3.5.3">4.3.5.3</a> <a id="status.502" href="#status.502">502 Bad Gateway</a></h4> 1796 1988 <p id="rfc.section.4.3.5.3.p.1">The server, while acting as a gateway or proxy, received an invalid response from the upstream server it accessed in attempting 1797 1989 to fulfill the request. 1798 1990 </p> 1799 <div id="rfc.iref. 37"></div>1800 <div id="rfc.iref.s.3 4"></div>1991 <div id="rfc.iref.55"></div> 1992 <div id="rfc.iref.s.35"></div> 1801 1993 <h4 id="rfc.section.4.3.5.4"><a href="#rfc.section.4.3.5.4">4.3.5.4</a> <a id="status.503" href="#status.503">503 Service Unavailable</a></h4> 1802 1994 <p id="rfc.section.4.3.5.4.p.1">The server is currently unable to handle the request due to a temporary overloading or maintenance of the server.</p> 1803 1995 <p id="rfc.section.4.3.5.4.p.2">The implication is that this is a temporary condition which will be alleviated after some delay. If known, the length of the 1804 delay <em class="bcp14">MAY</em> be indicated in a Retry-After header field (<a href="#header.retry-after" id="rfc.xref.header.retry-after.2" title="Retry-After">Section 8.8</a>). If no Retry-After is given, the client <em class="bcp14">SHOULD</em> handle the response as it would for a 500 response.1996 delay <em class="bcp14">MAY</em> be indicated in a Retry-After header field (<a href="#header.retry-after" id="rfc.xref.header.retry-after.2" title="Retry-After">Section 7.8</a>). If no Retry-After is given, the client <em class="bcp14">SHOULD</em> handle the response as it would for a 500 response. 1805 1997 </p> 1806 1998 <div class="note" id="rfc.section.4.3.5.4.p.3"> … … 1809 2001 </p> 1810 2002 </div> 1811 <div id="rfc.iref. 38"></div>1812 <div id="rfc.iref.s.3 5"></div>2003 <div id="rfc.iref.56"></div> 2004 <div id="rfc.iref.s.36"></div> 1813 2005 <h4 id="rfc.section.4.3.5.5"><a href="#rfc.section.4.3.5.5">4.3.5.5</a> <a id="status.504" href="#status.504">504 Gateway Timeout</a></h4> 1814 2006 <p id="rfc.section.4.3.5.5.p.1">The server, while acting as a gateway or proxy, did not receive a timely response from the upstream server specified by the … … 1819 2011 </p> 1820 2012 </div> 1821 <div id="rfc.iref. 39"></div>1822 <div id="rfc.iref.s.3 6"></div>2013 <div id="rfc.iref.57"></div> 2014 <div id="rfc.iref.s.37"></div> 1823 2015 <h4 id="rfc.section.4.3.5.6"><a href="#rfc.section.4.3.5.6">4.3.5.6</a> <a id="status.505" href="#status.505">505 HTTP Version Not Supported</a></h4> 1824 2016 <p id="rfc.section.4.3.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 1825 2017 is indicating that it is unable or unwilling to complete the request using the same major version as the client, as described 1826 in <a href="p1-messaging.html#http.version" title="Protocol Versioning">Section 2.6</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>, 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.2018 in <a href="p1-messaging.html#http.version" title="Protocol Versioning">Section 2.6</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>, 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. 1827 2019 </p> 1828 2020 <h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a> <a id="representation" href="#representation">Representation</a></h1> 1829 2021 <p id="rfc.section.5.p.1">Request and Response messages <em class="bcp14">MAY</em> transfer a representation if not otherwise restricted by the request method or response status code. A representation consists 1830 2022 of metadata (representation header fields) and data (representation body). When a complete or partial representation is enclosed 1831 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.1 1"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>.1832 </p> 1833 <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.3 2"><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 applied2023 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.12"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>. 2024 </p> 2025 <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.36"><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 1834 2026 to ensure safe and proper transfer of the message. 1835 2027 </p> … … 1837 2029 <p id="rfc.section.5.1.p.1">It is sometimes necessary to determine an identifier for the resource associated with a representation.</p> 1838 2030 <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> 1839 <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 5.5</a> of <a href="#Part1" id="rfc.xref.Part1.3 3"><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 following2031 <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 5.5</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>). However, this is not always the case. To determine the URI of the resource a response is associated with, the following 1840 2032 rules are used (with the first applicable one being selected): 1841 2033 </p> … … 1859 2051 cache invalidation.]</span> 1860 2052 </p> 1861 <h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a> <a id="method.definitions" href="#method.definitions">Method Definitions</a></h1> 1862 <p id="rfc.section.6.p.1">The set of common request methods for HTTP/1.1 is defined below. Although this set can be expanded, additional methods cannot 1863 be assumed to share the same semantics for separately extended clients and servers. 1864 </p> 1865 <h2 id="rfc.section.6.1"><a href="#rfc.section.6.1">6.1</a> <a id="safe.and.idempotent" href="#safe.and.idempotent">Safe and Idempotent Methods</a></h2> 1866 <div id="rfc.iref.s.37"></div> 1867 <h3 id="rfc.section.6.1.1"><a href="#rfc.section.6.1.1">6.1.1</a> <a id="safe.methods" href="#safe.methods">Safe Methods</a></h3> 1868 <p id="rfc.section.6.1.1.p.1">Implementors need to be aware that the software represents the user in their interactions over the Internet, and need to allow 1869 the user to be aware of any actions they take which might have an unexpected significance to themselves or others. 1870 </p> 1871 <p id="rfc.section.6.1.1.p.2">In particular, the convention has been established that the GET, HEAD, OPTIONS, and TRACE request methods <em class="bcp14">SHOULD NOT</em> have the significance of taking an action other than retrieval. These request methods ought to be considered "<dfn id="safe">safe</dfn>". This allows user agents to represent other methods, such as POST, PUT and DELETE, in a special way, so that the user is 1872 made aware of the fact that a possibly unsafe action is being requested. 1873 </p> 1874 <p id="rfc.section.6.1.1.p.3">Naturally, it is not possible to ensure that the server does not generate side-effects as a result of performing a GET request; 1875 in fact, some dynamic resources consider that a feature. The important distinction here is that the user did not request the 1876 side-effects, so therefore cannot be held accountable for them. 1877 </p> 1878 <div id="rfc.iref.i.1"></div> 1879 <h3 id="rfc.section.6.1.2"><a href="#rfc.section.6.1.2">6.1.2</a> <a id="idempotent.methods" href="#idempotent.methods">Idempotent Methods</a></h3> 1880 <p id="rfc.section.6.1.2.p.1">Request methods can also have the property of "idempotence" in that, aside from error or expiration issues, the intended effect 1881 of multiple identical requests is the same as for a single request. PUT, DELETE, and all safe request methods are idempotent. 1882 It is important to note that idempotence refers only to changes requested by the client: a server is free to change its state 1883 due to multiple requests for the purpose of tracking those requests, versioning of results, etc. 1884 </p> 1885 <h2 id="rfc.section.6.2"><a href="#rfc.section.6.2">6.2</a> <a id="OPTIONS" href="#OPTIONS">OPTIONS</a></h2> 1886 <div id="rfc.iref.o.1"></div> 1887 <div id="rfc.iref.m.1"></div> 1888 <p id="rfc.section.6.2.p.1">The OPTIONS method requests information about the communication options available on the request/response chain identified 1889 by the effective request URI. This method allows a client to determine the options and/or requirements associated with a resource, 1890 or the capabilities of a server, without implying a resource action or initiating a resource retrieval. 1891 </p> 1892 <p id="rfc.section.6.2.p.2">Responses to the OPTIONS method are not cacheable.</p> 1893 <p id="rfc.section.6.2.p.3">If the OPTIONS request includes a message body (as indicated by the presence of Content-Length or Transfer-Encoding), then 1894 the media type <em class="bcp14">MUST</em> be indicated by a Content-Type field. Although this specification does not define any use for such a body, future extensions 1895 to HTTP might use the OPTIONS body to make more detailed queries on the server. 1896 </p> 1897 <p id="rfc.section.6.2.p.4">If the request-target (<a href="p1-messaging.html#request-target" title="Request Target">Section 5.3</a> of <a href="#Part1" id="rfc.xref.Part1.34"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) is an asterisk ("*"), the OPTIONS request is intended to apply to the server in general rather than to a specific resource. 1898 Since a server's communication options typically depend on the resource, the "*" request is only useful as a "ping" or "no-op" 1899 type of method; it does nothing beyond allowing the client to test the capabilities of the server. For example, this can be 1900 used to test a proxy for HTTP/1.1 conformance (or lack thereof). 1901 </p> 1902 <p id="rfc.section.6.2.p.5">If the request-target is not an asterisk, the OPTIONS request applies only to the options that are available when communicating 1903 with that resource. 1904 </p> 1905 <p id="rfc.section.6.2.p.6">A 200 response <em class="bcp14">SHOULD</em> include any header fields that indicate optional features implemented by the server and applicable to that resource (e.g., 1906 Allow), possibly including extensions not defined by this specification. The response body, if any, <em class="bcp14">SHOULD</em> also include information about the communication options. The format for such a body is not defined by this specification, 1907 but might be defined by future extensions to HTTP. Content negotiation <em class="bcp14">MAY</em> be used to select the appropriate response format. If no response body is included, the response <em class="bcp14">MUST</em> include a Content-Length field with a field-value of "0". 1908 </p> 1909 <p id="rfc.section.6.2.p.7">The Max-Forwards header field <em class="bcp14">MAY</em> be used to target a specific proxy in the request chain (see <a href="#header.max-forwards" id="rfc.xref.header.max-forwards.2" title="Max-Forwards">Section 8.6</a>). If no Max-Forwards field is present in the request, then the forwarded request <em class="bcp14">MUST NOT</em> include a Max-Forwards field. 1910 </p> 1911 <h2 id="rfc.section.6.3"><a href="#rfc.section.6.3">6.3</a> <a id="GET" href="#GET">GET</a></h2> 1912 <div id="rfc.iref.g.5"></div> 1913 <div id="rfc.iref.m.2"></div> 1914 <p id="rfc.section.6.3.p.1">The GET method requests transfer of a current representation of the target resource.</p> 1915 <p id="rfc.section.6.3.p.2">If the target resource is a data-producing process, it is the produced data which shall be returned as the representation 1916 in the response and not the source text of the process, unless that text happens to be the output of the process. 1917 </p> 1918 <p id="rfc.section.6.3.p.3">The semantics of the GET method change to a "conditional GET" if the request message includes an If-Modified-Since, If-Unmodified-Since, 1919 If-Match, If-None-Match, or If-Range header field. A conditional GET requests that the representation be transferred only 1920 under the circumstances described by the conditional header field(s). The conditional GET request is intended to reduce unnecessary 1921 network usage by allowing cached representations to be refreshed without requiring multiple requests or transferring data 1922 already held by the client. 1923 </p> 1924 <p id="rfc.section.6.3.p.4">The semantics of the GET method change to a "partial GET" if the request message includes a Range header field. A partial 1925 GET requests that only part of the representation be transferred, as described in <a href="p5-range.html#header.range" title="Range">Section 5.4</a> of <a href="#Part5" id="rfc.xref.Part5.7"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>. The partial GET request is intended to reduce unnecessary network usage by allowing partially-retrieved representations 1926 to be completed without transferring data already held by the client. 1927 </p> 1928 <p id="rfc.section.6.3.p.5">Bodies on GET requests have no defined semantics. Note that sending a body on a GET request might cause some existing implementations 1929 to reject the request. 1930 </p> 1931 <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.13"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>). 1932 </p> 1933 <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. 1934 </p> 1935 <h2 id="rfc.section.6.4"><a href="#rfc.section.6.4">6.4</a> <a id="HEAD" href="#HEAD">HEAD</a></h2> 1936 <div id="rfc.iref.h.1"></div> 1937 <div id="rfc.iref.m.3"></div> 1938 <p id="rfc.section.6.4.p.1">The HEAD method is identical to GET except that the server <em class="bcp14">MUST NOT</em> return a message body in the response. The metadata contained in the HTTP header fields in response to a HEAD request <em class="bcp14">SHOULD</em> be identical to the information sent in response to a GET request. This method can be used for obtaining metadata about the 1939 representation implied by the request without transferring the representation body. This method is often used for testing 1940 hypertext links for validity, accessibility, and recent modification. 1941 </p> 1942 <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. It also has potential side effects on previously stored responses to GET; see <a href="p6-cache.html#head.effects" title="Updating Caches with HEAD Responses">Section 2.5</a> of <a href="#Part6" id="rfc.xref.Part6.14"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>. 1943 </p> 1944 <p id="rfc.section.6.4.p.3">Bodies on HEAD requests have no defined semantics. Note that sending a body on a HEAD request might cause some existing implementations 1945 to reject the request. 1946 </p> 1947 <div id="rfc.iref.p.1"></div> 1948 <div id="rfc.iref.m.4"></div> 1949 <h2 id="rfc.section.6.5"><a href="#rfc.section.6.5">6.5</a> <a id="POST" href="#POST">POST</a></h2> 1950 <p id="rfc.section.6.5.p.1">The POST method requests that the origin server accept the representation enclosed in the request as data to be processed 1951 by the target resource. POST is designed to allow a uniform method to cover the following functions: 1952 </p> 1953 <ul> 1954 <li>Annotation of existing resources;</li> 1955 <li>Posting a message to a bulletin board, newsgroup, mailing list, or similar group of articles;</li> 1956 <li>Providing a block of data, such as the result of submitting a form, to a data-handling process;</li> 1957 <li>Extending a database through an append operation.</li> 1958 </ul> 1959 <p id="rfc.section.6.5.p.2">The actual function performed by the POST method is determined by the server and is usually dependent on the effective request 1960 URI. 1961 </p> 1962 <p id="rfc.section.6.5.p.3">The action performed by the POST method might not result in a resource that can be identified by a URI. In this case, either 1963 200 (OK) or 204 (No Content) is the appropriate response status code, depending on whether or not the response includes a 1964 representation that describes the result. 1965 </p> 1966 <p id="rfc.section.6.5.p.4">If a resource has been created on the origin server, the response <em class="bcp14">SHOULD</em> be 201 (Created) and contain a representation which describes the status of the request and refers to the new resource, and 1967 a Location header field (see <a href="#header.location" id="rfc.xref.header.location.3" title="Location">Section 8.5</a>). 1968 </p> 1969 <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.15"><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.12"><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. 1970 </p> 1971 <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 1972 to retrieve a cacheable representation of the resource. 1973 </p> 1974 <div id="rfc.iref.p.2"></div> 1975 <div id="rfc.iref.m.5"></div> 1976 <h2 id="rfc.section.6.6"><a href="#rfc.section.6.6">6.6</a> <a id="PUT" href="#PUT">PUT</a></h2> 1977 <p id="rfc.section.6.6.p.1">The PUT method requests that the state of the target resource be created or replaced with the state defined by the representation 1978 enclosed in the request message payload. A successful PUT of a given representation would suggest that a subsequent GET on 1979 that same target resource will result in an equivalent representation being returned in a 200 (OK) response. However, there 1980 is no guarantee that such a state change will be observable, since the target resource might be acted upon by other user agents 1981 in parallel, or might be subject to dynamic processing by the origin server, before any subsequent GET is received. A successful 1982 response only implies that the user agent's intent was achieved at the time of its processing by the origin server. 1983 </p> 1984 <p id="rfc.section.6.6.p.2">If the target resource does not have a current representation and the PUT successfully creates one, then the origin server <em class="bcp14">MUST</em> inform the user agent by sending a 201 (Created) response. If the target resource does have a current representation and that 1985 representation is successfully modified in accordance with the state of the enclosed representation, then either a 200 (OK) 1986 or 204 (No Content) response <em class="bcp14">SHOULD</em> be sent to indicate successful completion of the request. 1987 </p> 1988 <p id="rfc.section.6.6.p.3">Unrecognized header fields <em class="bcp14">SHOULD</em> be ignored (i.e., not saved as part of the resource state). 1989 </p> 1990 <p id="rfc.section.6.6.p.4">An origin server <em class="bcp14">SHOULD</em> verify that the PUT representation is consistent with any constraints which the server has for the target resource that cannot 1991 or will not be changed by the PUT. This is particularly important when the origin server uses internal configuration information 1992 related to the URI in order to set the values for representation metadata on GET responses. When a PUT representation is inconsistent 1993 with the target resource, the origin server <em class="bcp14">SHOULD</em> either make them consistent, by transforming the representation or changing the resource configuration, or respond with an 1994 appropriate error message containing sufficient information to explain why the representation is unsuitable. The 409 (Conflict) 1995 or 415 (Unsupported Media Type) status codes are suggested, with the latter being specific to constraints on Content-Type 1996 values. 1997 </p> 1998 <p id="rfc.section.6.6.p.5">For example, if the target resource is configured to always have a Content-Type of "text/html" and the representation being 1999 PUT has a Content-Type of "image/jpeg", then the origin server <em class="bcp14">SHOULD</em> do one of: (a) reconfigure the target resource to reflect the new media type; (b) transform the PUT representation to a format 2000 consistent with that of the resource before saving it as the new resource state; or, (c) reject the request with a 415 response 2001 indicating that the target resource is limited to "text/html", perhaps including a link to a different resource that would 2002 be a suitable target for the new representation. 2003 </p> 2004 <p id="rfc.section.6.6.p.6">HTTP does not define exactly how a PUT method affects the state of an origin server beyond what can be expressed by the intent 2005 of the user agent request and the semantics of the origin server response. It does not define what a resource might be, in 2006 any sense of that word, beyond the interface provided via HTTP. It does not define how resource state is "stored", nor how 2007 such storage might change as a result of a change in resource state, nor how the origin server translates resource state into 2008 representations. Generally speaking, all implementation details behind the resource interface are intentionally hidden by 2009 the server. 2010 </p> 2011 <p id="rfc.section.6.6.p.7">The fundamental difference between the POST and PUT methods is highlighted by the different intent for the target resource. 2012 The target resource in a POST request is intended to handle the enclosed representation as a data-accepting process, such 2013 as for a gateway to some other protocol or a document that accepts annotations. In contrast, the target resource in a PUT 2014 request is intended to take the enclosed representation as a new or replacement value. Hence, the intent of PUT is idempotent 2015 and visible to intermediaries, even though the exact effect is only known by the origin server. 2016 </p> 2017 <p id="rfc.section.6.6.p.8">Proper interpretation of a PUT request presumes that the user agent knows what target resource is desired. A service that 2018 is intended to select a proper URI on behalf of the client, after receiving a state-changing request, <em class="bcp14">SHOULD</em> be implemented using the POST method rather than PUT. If the origin server will not make the requested PUT state change to 2019 the target resource and instead wishes to have it applied to a different resource, such as when the resource has been moved 2020 to a different URI, then the origin server <em class="bcp14">MUST</em> send a 301 (Moved Permanently) response; the user agent <em class="bcp14">MAY</em> then make its own decision regarding whether or not to redirect the request. 2021 </p> 2022 <p id="rfc.section.6.6.p.9">A PUT request applied to the target resource <em class="bcp14">MAY</em> have side-effects on other resources. For example, an article might have a URI for identifying "the current version" (a resource) 2023 which is separate from the URIs identifying each particular version (different resources that at one point shared the same 2024 state as the current version resource). A successful PUT request on "the current version" URI might therefore create a new 2025 version resource in addition to changing the state of the target resource, and might also cause links to be added between 2026 the related resources. 2027 </p> 2028 <p id="rfc.section.6.6.p.10">An origin server <em class="bcp14">SHOULD</em> reject any PUT request that contains a Content-Range header field, since it might be misinterpreted as partial content (or 2029 might be partial content that is being mistakenly PUT as a full representation). Partial content updates are possible by targeting 2030 a separately identified resource with state that overlaps a portion of the larger resource, or by using a different method 2031 that has been specifically defined for partial updates (for example, the PATCH method defined in <a href="#RFC5789" id="rfc.xref.RFC5789.1"><cite title="PATCH Method for HTTP">[RFC5789]</cite></a>). 2032 </p> 2033 <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 2034 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.6</a> of <a href="#Part6" id="rfc.xref.Part6.16"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>). 2035 </p> 2036 <div id="rfc.iref.d.1"></div> 2037 <div id="rfc.iref.m.6"></div> 2038 <h2 id="rfc.section.6.7"><a href="#rfc.section.6.7">6.7</a> <a id="DELETE" href="#DELETE">DELETE</a></h2> 2039 <p id="rfc.section.6.7.p.1">The DELETE method requests that the origin server delete the target resource. This method <em class="bcp14">MAY</em> be overridden by human intervention (or other means) on the origin server. The client cannot be guaranteed that the operation 2040 has been carried out, even if the status code returned from the origin server indicates that the action has been completed 2041 successfully. However, the server <em class="bcp14">SHOULD NOT</em> indicate success unless, at the time the response is given, it intends to delete the resource or move it to an inaccessible 2042 location. 2043 </p> 2044 <p id="rfc.section.6.7.p.2">A successful response <em class="bcp14">SHOULD</em> be 200 (OK) if the response includes an representation describing the status, 202 (Accepted) if the action has not yet been 2045 enacted, or 204 (No Content) if the action has been enacted but the response does not include a representation. 2046 </p> 2047 <p id="rfc.section.6.7.p.3">Bodies on DELETE requests have no defined semantics. Note that sending a body on a DELETE request might cause some existing 2048 implementations to reject the request. 2049 </p> 2050 <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 2051 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.6</a> of <a href="#Part6" id="rfc.xref.Part6.17"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>). 2052 </p> 2053 <h2 id="rfc.section.6.8"><a href="#rfc.section.6.8">6.8</a> <a id="TRACE" href="#TRACE">TRACE</a></h2> 2054 <div id="rfc.iref.t.1"></div> 2055 <div id="rfc.iref.m.7"></div> 2056 <p id="rfc.section.6.8.p.1">The TRACE method requests a remote, application-layer loop-back of the request message. The final recipient of the request <em class="bcp14">SHOULD</em> reflect the message received back to the client as the message body of a 200 (OK) response. The final recipient is either 2057 the origin server or the first proxy to receive a Max-Forwards value of zero (0) in the request (see <a href="#header.max-forwards" id="rfc.xref.header.max-forwards.3" title="Max-Forwards">Section 8.6</a>). A TRACE request <em class="bcp14">MUST NOT</em> include a message body. 2058 </p> 2059 <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 2060 or diagnostic information. The value of the Via header field (<a href="p1-messaging.html#header.via" title="Via">Section 6.2</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>) is of particular interest, since it acts as a trace of the request chain. Use of the Max-Forwards header field allows the 2061 client to limit the length of the request chain, which is useful for testing a chain of proxies forwarding messages in an 2062 infinite loop. 2063 </p> 2064 <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 7.3.1</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>) and contain a message body that encloses a copy of the entire request message. Responses to the TRACE method are not cacheable. 2065 </p> 2066 <div id="rfc.iref.c.1"></div> 2067 <div id="rfc.iref.m.8"></div> 2068 <h2 id="rfc.section.6.9"><a href="#rfc.section.6.9">6.9</a> <a id="CONNECT" href="#CONNECT">CONNECT</a></h2> 2069 <p id="rfc.section.6.9.p.1">The CONNECT method requests that the proxy establish a tunnel to the request-target and, if successful, thereafter restrict 2070 its behavior to blind forwarding of packets until the connection is closed. 2071 </p> 2072 <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 5.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>); i.e., the request-target consists of only the host name and port number of the tunnel destination, separated by a colon. 2073 For example, 2074 </p> 2075 <div id="rfc.figure.u.7"></div><pre class="text2">CONNECT server.example.com:80 HTTP/1.1 2076 Host: server.example.com:80 2077 2078 </pre><p id="rfc.section.6.9.p.4">Any successful (2xx) response to a CONNECT request indicates that the proxy has established a connection to the requested 2079 host and port, and has switched to tunneling the current connection to that server connection. The tunneled data from the 2080 server begins immediately after the blank line that concludes the successful response's header block. A server <em class="bcp14">SHOULD NOT</em> send any Transfer-Encoding or Content-Length header fields in a successful response. A client <em class="bcp14">MUST</em> ignore any Content-Length or Transfer-Encoding header fields received in a successful response. 2081 </p> 2082 <p id="rfc.section.6.9.p.5">Any response other than a successful response indicates that the tunnel has not yet been formed and that the connection remains 2083 governed by HTTP. 2084 </p> 2085 <p id="rfc.section.6.9.p.6">Proxy authentication might be used to establish the authority to create a tunnel:</p> 2086 <div id="rfc.figure.u.8"></div><pre class="text2">CONNECT server.example.com:80 HTTP/1.1 2087 Host: server.example.com:80 2088 Proxy-Authorization: basic aGVsbG86d29ybGQ= 2089 2090 </pre><p id="rfc.section.6.9.p.8">A message body on a CONNECT request has no defined semantics. Sending a body on a CONNECT request might cause existing implementations 2091 to reject the request. 2092 </p> 2093 <p id="rfc.section.6.9.p.9">Similar to a pipelined HTTP/1.1 request, data to be tunneled from client to server <em class="bcp14">MAY</em> be sent immediately after the request (before a response is received). The usual caveats also apply: data may be discarded 2094 if the eventual response is negative, and the connection may be reset with no response if more than one TCP segment is outstanding. 2095 </p> 2096 <p id="rfc.section.6.9.p.10">It may be the case that the proxy itself can only reach the requested origin server through another proxy. In this case, the 2097 first proxy <em class="bcp14">SHOULD</em> make a CONNECT request of that next proxy, requesting a tunnel to the authority. A proxy <em class="bcp14">MUST NOT</em> respond with any 2xx status code unless it has either a direct or tunnel connection established to the authority. 2098 </p> 2099 <p id="rfc.section.6.9.p.11">If at any point either one of the peers gets disconnected, any outstanding data that came from that peer will be passed to 2100 the other one, and after that also the other connection will be terminated by the proxy. If there is outstanding data to that 2101 peer undelivered, that data will be discarded. 2102 </p> 2103 <p id="rfc.section.6.9.p.12">An origin server which receives a CONNECT request for itself <em class="bcp14">MAY</em> respond with a 2xx status code to indicate that a connection is established. However, most origin servers do not implement 2104 CONNECT. 2105 </p> 2106 <h1 id="rfc.section.7"><a href="#rfc.section.7">7.</a> <a id="common.protocol.parameters" href="#common.protocol.parameters">Common Protocol Parameters</a></h1> 2107 <h2 id="rfc.section.7.1"><a href="#rfc.section.7.1">7.1</a> <a id="http.date" href="#http.date">Date/Time Formats</a></h2> 2108 <p id="rfc.section.7.1.p.1">HTTP applications have historically allowed three different formats for date/time stamps. However, the preferred format is 2053 <h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a> <a id="common.protocol.parameters" href="#common.protocol.parameters">Common Protocol Parameters</a></h1> 2054 <h2 id="rfc.section.6.1"><a href="#rfc.section.6.1">6.1</a> <a id="http.date" href="#http.date">Date/Time Formats</a></h2> 2055 <p id="rfc.section.6.1.p.1">HTTP applications have historically allowed three different formats for date/time stamps. However, the preferred format is 2109 2056 a fixed-length subset of that defined by <a href="#RFC1123" id="rfc.xref.RFC1123.1"><cite title="Requirements for Internet Hosts - Application and Support">[RFC1123]</cite></a>: 2110 2057 </p> 2111 2058 <div id="rfc.figure.u.9"></div><pre class="text">Sun, 06 Nov 1994 08:49:37 GMT ; RFC 1123 2112 </pre><p id="rfc.section. 7.1.p.3">The other formats are described here only for compatibility with obsolete implementations.</p>2059 </pre><p id="rfc.section.6.1.p.3">The other formats are described here only for compatibility with obsolete implementations.</p> 2113 2060 <div id="rfc.figure.u.10"></div><pre class="text">Sunday, 06-Nov-94 08:49:37 GMT ; obsolete RFC 850 format 2114 2061 Sun Nov 6 08:49:37 1994 ; ANSI C's asctime() format 2115 </pre><p id="rfc.section. 7.1.p.5">HTTP/1.1 clients and servers that parse a date value <em class="bcp14">MUST</em> accept all three formats (for compatibility with HTTP/1.0), though they <em class="bcp14">MUST</em> only generate the RFC 1123 format for representing HTTP-date values in header fields.2116 </p> 2117 <p id="rfc.section. 7.1.p.6">All HTTP date/time stamps <em class="bcp14">MUST</em> be represented in Greenwich Mean Time (GMT), without exception. For the purposes of HTTP, GMT is exactly equal to UTC (Coordinated2062 </pre><p id="rfc.section.6.1.p.5">HTTP/1.1 clients and servers that parse a date value <em class="bcp14">MUST</em> accept all three formats (for compatibility with HTTP/1.0), though they <em class="bcp14">MUST</em> only generate the RFC 1123 format for representing HTTP-date values in header fields. 2063 </p> 2064 <p id="rfc.section.6.1.p.6">All HTTP date/time stamps <em class="bcp14">MUST</em> be represented in Greenwich Mean Time (GMT), without exception. For the purposes of HTTP, GMT is exactly equal to UTC (Coordinated 2118 2065 Universal Time). This is indicated in the first two formats by the inclusion of "GMT" as the three-letter abbreviation for 2119 2066 time zone, and <em class="bcp14">MUST</em> be assumed when reading the asctime format. HTTP-date is case sensitive and <em class="bcp14">MUST NOT</em> include additional whitespace beyond that specifically included as SP in the grammar. … … 2121 2068 <div id="rfc.figure.u.11"></div><pre class="inline"><span id="rfc.iref.g.6"></span> <a href="#http.date" class="smpl">HTTP-date</a> = <a href="#preferred.date.format" class="smpl">rfc1123-date</a> / <a href="#obsolete.date.formats" class="smpl">obs-date</a> 2122 2069 </pre><div id="preferred.date.format"> 2123 <p id="rfc.section. 7.1.p.8"> Preferred format:</p>2070 <p id="rfc.section.6.1.p.8"> Preferred format:</p> 2124 2071 </div> 2125 2072 <div id="rfc.figure.u.12"></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><span id="rfc.iref.g.11"></span><span id="rfc.iref.g.12"></span><span id="rfc.iref.g.13"></span><span id="rfc.iref.g.14"></span><span id="rfc.iref.g.15"></span><span id="rfc.iref.g.16"></span><span id="rfc.iref.g.17"></span><span id="rfc.iref.g.18"></span> <a href="#preferred.date.format" class="smpl">rfc1123-date</a> = <a href="#preferred.date.format" class="smpl">day-name</a> "," <a href="#notation" class="smpl">SP</a> date1 <a href="#notation" class="smpl">SP</a> <a href="#preferred.date.format" class="smpl">time-of-day</a> <a href="#notation" class="smpl">SP</a> <a href="#preferred.date.format" class="smpl">GMT</a> … … 2161 2108 <a href="#preferred.date.format" class="smpl">minute</a> = 2<a href="#notation" class="smpl">DIGIT</a> 2162 2109 <a href="#preferred.date.format" class="smpl">second</a> = 2<a href="#notation" class="smpl">DIGIT</a> 2163 </pre><p id="rfc.section. 7.1.p.10">The semantics of <a href="#preferred.date.format" class="smpl">day-name</a>, <a href="#preferred.date.format" class="smpl">day</a>, <a href="#preferred.date.format" class="smpl">month</a>, <a href="#preferred.date.format" class="smpl">year</a>, and <a href="#preferred.date.format" class="smpl">time-of-day</a> are the same as those defined for the RFC 5322 constructs with the corresponding name (<a href="#RFC5322" id="rfc.xref.RFC5322.1"><cite title="Internet Message Format">[RFC5322]</cite></a>, <a href="http://tools.ietf.org/html/rfc5322#section-3.3">Section 3.3</a>).2110 </pre><p id="rfc.section.6.1.p.10">The semantics of <a href="#preferred.date.format" class="smpl">day-name</a>, <a href="#preferred.date.format" class="smpl">day</a>, <a href="#preferred.date.format" class="smpl">month</a>, <a href="#preferred.date.format" class="smpl">year</a>, and <a href="#preferred.date.format" class="smpl">time-of-day</a> are the same as those defined for the RFC 5322 constructs with the corresponding name (<a href="#RFC5322" id="rfc.xref.RFC5322.1"><cite title="Internet Message Format">[RFC5322]</cite></a>, <a href="http://tools.ietf.org/html/rfc5322#section-3.3">Section 3.3</a>). 2164 2111 </p> 2165 2112 <div id="obsolete.date.formats"> 2166 <p id="rfc.section. 7.1.p.11"> Obsolete formats:</p>2113 <p id="rfc.section.6.1.p.11"> Obsolete formats:</p> 2167 2114 </div> 2168 2115 <div id="rfc.figure.u.13"></div><pre class="inline"><span id="rfc.iref.g.19"></span> <a href="#obsolete.date.formats" class="smpl">obs-date</a> = <a href="#obsolete.date.formats" class="smpl">rfc850-date</a> / <a href="#obsolete.date.formats" class="smpl">asctime-date</a> … … 2181 2128 <a href="#obsolete.date.formats" class="smpl">date3</a> = <a href="#preferred.date.format" class="smpl">month</a> <a href="#notation" class="smpl">SP</a> ( 2<a href="#notation" class="smpl">DIGIT</a> / ( <a href="#notation" class="smpl">SP</a> 1<a href="#notation" class="smpl">DIGIT</a> )) 2182 2129 ; month day (e.g., Jun 2) 2183 </pre><div class="note" id="rfc.section. 7.1.p.15">2130 </pre><div class="note" id="rfc.section.6.1.p.15"> 2184 2131 <p> <b>Note:</b> Recipients of date values are encouraged to be robust in accepting date values that might have been sent by non-HTTP applications, 2185 2132 as is sometimes the case when retrieving or posting messages via proxies/gateways to SMTP or NNTP. 2186 2133 </p> 2187 2134 </div> 2188 <div class="note" id="rfc.section. 7.1.p.16">2135 <div class="note" id="rfc.section.6.1.p.16"> 2189 2136 <p> <b>Note:</b> HTTP requirements for the date/time stamp format apply only to their usage within the protocol stream. Clients and servers 2190 2137 are not required to use these formats for user presentation, request logging, etc. 2191 2138 </p> 2192 2139 </div> 2193 <h2 id="rfc.section. 7.2"><a href="#rfc.section.7.2">7.2</a> <a id="product.tokens" href="#product.tokens">Product Tokens</a></h2>2194 <p id="rfc.section. 7.2.p.1">Product tokens are used to allow communicating applications to identify themselves by software name and version. Most fields2140 <h2 id="rfc.section.6.2"><a href="#rfc.section.6.2">6.2</a> <a id="product.tokens" href="#product.tokens">Product Tokens</a></h2> 2141 <p id="rfc.section.6.2.p.1">Product tokens are used to allow communicating applications to identify themselves by software name and version. Most fields 2195 2142 using product tokens also allow sub-products which form a significant part of the application to be listed, separated by whitespace. 2196 2143 By convention, the products are listed in order of their significance for identifying the application. … … 2198 2145 <div id="rfc.figure.u.16"></div><pre class="inline"><span id="rfc.iref.g.22"></span><span id="rfc.iref.g.23"></span> <a href="#product.tokens" class="smpl">product</a> = <a href="#core.rules" class="smpl">token</a> ["/" <a href="#product.tokens" class="smpl">product-version</a>] 2199 2146 <a href="#product.tokens" class="smpl">product-version</a> = <a href="#core.rules" class="smpl">token</a> 2200 </pre><p id="rfc.section. 7.2.p.3">Examples:</p>2147 </pre><p id="rfc.section.6.2.p.3">Examples:</p> 2201 2148 <div id="rfc.figure.u.17"></div><pre class="text"> User-Agent: CERN-LineMode/2.15 libwww/2.17b3 2202 2149 Server: Apache/0.8.4 2203 </pre><p id="rfc.section. 7.2.p.5">Product tokens <em class="bcp14">SHOULD</em> be short and to the point. They <em class="bcp14">MUST NOT</em> be used for advertising or other non-essential information. Although any token octet <em class="bcp14">MAY</em> appear in a product-version, this token <em class="bcp14">SHOULD</em> only be used for a version identifier (i.e., successive versions of the same product <em class="bcp14">SHOULD</em> only differ in the product-version portion of the product value).2204 </p> 2205 <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>2206 <p id="rfc.section. 8.p.1">This section defines the syntax and semantics of HTTP/1.1 header fields related to request and response semantics.</p>2150 </pre><p id="rfc.section.6.2.p.5">Product tokens <em class="bcp14">SHOULD</em> be short and to the point. They <em class="bcp14">MUST NOT</em> be used for advertising or other non-essential information. Although any token octet <em class="bcp14">MAY</em> appear in a product-version, this token <em class="bcp14">SHOULD</em> only be used for a version identifier (i.e., successive versions of the same product <em class="bcp14">SHOULD</em> only differ in the product-version portion of the product value). 2151 </p> 2152 <h1 id="rfc.section.7"><a href="#rfc.section.7">7.</a> <a id="header.field.definitions" href="#header.field.definitions">Header Field Definitions</a></h1> 2153 <p id="rfc.section.7.p.1">This section defines the syntax and semantics of HTTP/1.1 header fields related to request and response semantics.</p> 2207 2154 <div id="rfc.iref.a.1"></div> 2208 2155 <div id="rfc.iref.h.2"></div> 2209 <h2 id="rfc.section. 8.1"><a href="#rfc.section.8.1">8.1</a> <a id="header.allow" href="#header.allow">Allow</a></h2>2210 <p id="rfc.section. 8.1.p.1">The "Allow" header field lists the set of methods advertised as supported by the target resource. The purpose of this field2156 <h2 id="rfc.section.7.1"><a href="#rfc.section.7.1">7.1</a> <a id="header.allow" href="#header.allow">Allow</a></h2> 2157 <p id="rfc.section.7.1.p.1">The "Allow" header field lists the set of methods advertised as supported by the target resource. The purpose of this field 2211 2158 is strictly to inform the recipient of valid request methods associated with the resource. 2212 2159 </p> 2213 <div id="rfc.figure.u.18"></div><pre class="inline"><span id="rfc.iref.g.24"></span> <a href="#header.allow" class="smpl">Allow</a> = #<a href="#method " class="smpl">method</a>2214 </pre><p id="rfc.section. 8.1.p.3">Example of use:</p>2160 <div id="rfc.figure.u.18"></div><pre class="inline"><span id="rfc.iref.g.24"></span> <a href="#header.allow" class="smpl">Allow</a> = #<a href="#methods" class="smpl">method</a> 2161 </pre><p id="rfc.section.7.1.p.3">Example of use:</p> 2215 2162 <div id="rfc.figure.u.19"></div><pre class="text"> Allow: GET, HEAD, PUT 2216 </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>2217 <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 according2163 </pre><p id="rfc.section.7.1.p.5">The actual set of allowed methods is defined by the origin server at the time of each request.</p> 2164 <p id="rfc.section.7.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 2218 2165 to the generic message handling rules. 2219 2166 </p> 2220 2167 <div id="rfc.iref.d.2"></div> 2221 2168 <div id="rfc.iref.h.3"></div> 2222 <h2 id="rfc.section. 8.2"><a href="#rfc.section.8.2">8.2</a> <a id="header.date" href="#header.date">Date</a></h2>2223 <p id="rfc.section. 8.2.p.1">The "Date" header field represents the date and time at which the message was originated, having the same semantics as the2224 Origination Date Field (orig-date) defined in <a href="http://tools.ietf.org/html/rfc5322#section-3.6.1">Section 3.6.1</a> of <a href="#RFC5322" id="rfc.xref.RFC5322.2"><cite title="Internet Message Format">[RFC5322]</cite></a>. The field value is an HTTP-date, as defined in <a href="#http.date" title="Date/Time Formats">Section 7.1</a>; it <em class="bcp14">MUST</em> be sent in rfc1123-date format.2169 <h2 id="rfc.section.7.2"><a href="#rfc.section.7.2">7.2</a> <a id="header.date" href="#header.date">Date</a></h2> 2170 <p id="rfc.section.7.2.p.1">The "Date" header field represents the date and time at which the message was originated, having the same semantics as the 2171 Origination Date Field (orig-date) defined in <a href="http://tools.ietf.org/html/rfc5322#section-3.6.1">Section 3.6.1</a> of <a href="#RFC5322" id="rfc.xref.RFC5322.2"><cite title="Internet Message Format">[RFC5322]</cite></a>. The field value is an HTTP-date, as defined in <a href="#http.date" title="Date/Time Formats">Section 6.1</a>; it <em class="bcp14">MUST</em> be sent in rfc1123-date format. 2225 2172 </p> 2226 2173 <div id="rfc.figure.u.20"></div><pre class="inline"><span id="rfc.iref.g.25"></span> <a href="#header.date" class="smpl">Date</a> = <a href="#http.date" class="smpl">HTTP-date</a> 2227 </pre><p id="rfc.section. 8.2.p.3">An example is</p>2174 </pre><p id="rfc.section.7.2.p.3">An example is</p> 2228 2175 <div id="rfc.figure.u.21"></div><pre class="text"> Date: Tue, 15 Nov 1994 08:12:31 GMT 2229 </pre><p id="rfc.section. 8.2.p.5">Origin servers <em class="bcp14">MUST</em> include a Date header field in all responses, except in these cases:2176 </pre><p id="rfc.section.7.2.p.5">Origin servers <em class="bcp14">MUST</em> include a Date header field in all responses, except in these cases: 2230 2177 </p> 2231 2178 <ol> … … 2238 2185 </li> 2239 2186 </ol> 2240 <p id="rfc.section. 8.2.p.6">A received message that does not have a Date header field <em class="bcp14">MUST</em> be assigned one by the recipient if the message will be cached by that recipient.2241 </p> 2242 <p id="rfc.section. 8.2.p.7">Clients can use the Date header field as well; in order to keep request messages small, they are advised not to include it2187 <p id="rfc.section.7.2.p.6">A received message that does not have a Date header field <em class="bcp14">MUST</em> be assigned one by the recipient if the message will be cached by that recipient. 2188 </p> 2189 <p id="rfc.section.7.2.p.7">Clients can use the Date header field as well; in order to keep request messages small, they are advised not to include it 2243 2190 when it doesn't convey any useful information (as is usually the case for requests that do not contain a payload). 2244 2191 </p> 2245 <p id="rfc.section. 8.2.p.8">The HTTP-date sent in a Date header field <em class="bcp14">SHOULD NOT</em> represent a date and time subsequent to the generation of the message. It <em class="bcp14">SHOULD</em> represent the best available approximation of the date and time of message generation, unless the implementation has no means2192 <p id="rfc.section.7.2.p.8">The HTTP-date sent in a Date header field <em class="bcp14">SHOULD NOT</em> represent a date and time subsequent to the generation of the message. It <em class="bcp14">SHOULD</em> represent the best available approximation of the date and time of message generation, unless the implementation has no means 2246 2193 of generating a reasonably accurate date and time. In theory, the date ought to represent the moment just before the payload 2247 2194 is generated. In practice, the date can be generated at any time during the message origination without affecting its semantic … … 2250 2197 <div id="rfc.iref.e.1"></div> 2251 2198 <div id="rfc.iref.h.4"></div> 2252 <h2 id="rfc.section. 8.3"><a href="#rfc.section.8.3">8.3</a> <a id="header.expect" href="#header.expect">Expect</a></h2>2253 <p id="rfc.section. 8.3.p.1">The "Expect" header field is used to indicate that particular server behaviors are required by the client.</p>2199 <h2 id="rfc.section.7.3"><a href="#rfc.section.7.3">7.3</a> <a id="header.expect" href="#header.expect">Expect</a></h2> 2200 <p id="rfc.section.7.3.p.1">The "Expect" header field is used to indicate that particular server behaviors are required by the client.</p> 2254 2201 <div id="rfc.figure.u.22"></div><pre class="inline"><span id="rfc.iref.g.26"></span><span id="rfc.iref.g.27"></span><span id="rfc.iref.g.28"></span><span id="rfc.iref.g.29"></span><span id="rfc.iref.g.30"></span> <a href="#header.expect" class="smpl">Expect</a> = 1#<a href="#header.expect" class="smpl">expectation</a> 2255 2202 … … 2260 2207 <a href="#header.expect" class="smpl">expect-name</a> = <a href="#core.rules" class="smpl">token</a> 2261 2208 <a href="#header.expect" class="smpl">expect-value</a> = <a href="#core.rules" class="smpl">token</a> / <a href="#core.rules" class="smpl">quoted-string</a> 2262 </pre><p id="rfc.section. 8.3.p.3">If all received Expect header field(s) are syntactically valid but contain an expectation that the recipient does not understand2209 </pre><p id="rfc.section.7.3.p.3">If all received Expect header field(s) are syntactically valid but contain an expectation that the recipient does not understand 2263 2210 or cannot comply with, the recipient <em class="bcp14">MUST</em> respond with a 417 (Expectation Failed) status code. A recipient of a syntactically invalid Expectation header field <em class="bcp14">MUST</em> respond with a 4xx status code other than 417. 2264 2211 </p> 2265 <p id="rfc.section. 8.3.p.4">The only expectation defined by this specification is:</p>2266 <p id="rfc.section. 8.3.p.5"><span id="rfc.iref.89"></span><span id="rfc.iref.e.2"></span> 100-continue2212 <p id="rfc.section.7.3.p.4">The only expectation defined by this specification is:</p> 2213 <p id="rfc.section.7.3.p.5"><span id="rfc.iref.89"></span><span id="rfc.iref.e.2"></span> 100-continue 2267 2214 </p> 2268 2215 <ul class="empty"> … … 2270 2217 </li> 2271 2218 </ul> 2272 <p id="rfc.section. 8.3.p.6">Comparison is case-insensitive for names (expect-name), and case-sensitive for values (expect-value).</p>2273 <p id="rfc.section. 8.3.p.7">The Expect mechanism is hop-by-hop: the above requirements apply to any server, including proxies. However, the Expect header2219 <p id="rfc.section.7.3.p.6">Comparison is case-insensitive for names (expect-name), and case-sensitive for values (expect-value).</p> 2220 <p id="rfc.section.7.3.p.7">The Expect mechanism is hop-by-hop: the above requirements apply to any server, including proxies. However, the Expect header 2274 2221 field itself is end-to-end; it <em class="bcp14">MUST</em> be forwarded if the request is forwarded. 2275 2222 </p> 2276 <p id="rfc.section. 8.3.p.8">Many older HTTP/1.0 and HTTP/1.1 applications do not understand the Expect header field.</p>2223 <p id="rfc.section.7.3.p.8">Many older HTTP/1.0 and HTTP/1.1 applications do not understand the Expect header field.</p> 2277 2224 <div id="rfc.iref.f.1"></div> 2278 2225 <div id="rfc.iref.h.5"></div> 2279 <h2 id="rfc.section. 8.4"><a href="#rfc.section.8.4">8.4</a> <a id="header.from" href="#header.from">From</a></h2>2280 <p id="rfc.section. 8.4.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.3"><cite title="Internet Message Format">[RFC5322]</cite></a>:2226 <h2 id="rfc.section.7.4"><a href="#rfc.section.7.4">7.4</a> <a id="header.from" href="#header.from">From</a></h2> 2227 <p id="rfc.section.7.4.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.3"><cite title="Internet Message Format">[RFC5322]</cite></a>: 2281 2228 </p> 2282 2229 <div id="rfc.figure.u.23"></div><pre class="inline"><span id="rfc.iref.g.31"></span> <a href="#header.from" class="smpl">From</a> = <a href="#header.from" class="smpl">mailbox</a> 2283 2230 2284 2231 <a href="#header.from" class="smpl">mailbox</a> = <mailbox, defined in <a href="#RFC5322" id="rfc.xref.RFC5322.4"><cite title="Internet Message Format">[RFC5322]</cite></a>, <a href="http://tools.ietf.org/html/rfc5322#section-3.4">Section 3.4</a>> 2285 </pre><p id="rfc.section. 8.4.p.3">An example is:</p>2232 </pre><p id="rfc.section.7.4.p.3">An example is:</p> 2286 2233 <div id="rfc.figure.u.24"></div><pre class="text"> From: webmaster@example.org 2287 </pre><p id="rfc.section. 8.4.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 performed2234 </pre><p id="rfc.section.7.4.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 2288 2235 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 2289 2236 end. 2290 2237 </p> 2291 <p id="rfc.section. 8.4.p.6">The Internet e-mail address in this field <em class="bcp14">MAY</em> be separate from the Internet host which issued the request. For example, when a request is passed through a proxy the original2238 <p id="rfc.section.7.4.p.6">The Internet e-mail address in this field <em class="bcp14">MAY</em> be separate from the Internet host which issued the request. For example, when a request is passed through a proxy the original 2292 2239 issuer's address <em class="bcp14">SHOULD</em> be used. 2293 2240 </p> 2294 <p id="rfc.section. 8.4.p.7">The client <em class="bcp14">SHOULD NOT</em> send the From header field without the user's approval, as it might conflict with the user's privacy interests or their site's2241 <p id="rfc.section.7.4.p.7">The client <em class="bcp14">SHOULD NOT</em> send the From header field without the user's approval, as it might conflict with the user's privacy interests or their site's 2295 2242 security policy. It is strongly recommended that the user be able to disable, enable, and modify the value of this field at 2296 2243 any time prior to a request. … … 2298 2245 <div id="rfc.iref.l.1"></div> 2299 2246 <div id="rfc.iref.h.6"></div> 2300 <h2 id="rfc.section. 8.5"><a href="#rfc.section.8.5">8.5</a> <a id="header.location" href="#header.location">Location</a></h2>2301 <p id="rfc.section. 8.5.p.1">The "Location" header field <em class="bcp14">MAY</em> be sent in responses to refer to a specific resource in accordance with the semantics of the status code.2247 <h2 id="rfc.section.7.5"><a href="#rfc.section.7.5">7.5</a> <a id="header.location" href="#header.location">Location</a></h2> 2248 <p id="rfc.section.7.5.p.1">The "Location" header field <em class="bcp14">MAY</em> be sent in responses to refer to a specific resource in accordance with the semantics of the status code. 2302 2249 </p> 2303 2250 <div id="rfc.figure.u.25"></div><pre class="inline"><span id="rfc.iref.g.32"></span> <a href="#header.location" class="smpl">Location</a> = <a href="#abnf.dependencies" class="smpl">URI-reference</a> 2304 </pre><p id="rfc.section. 8.5.p.3">For 201 (Created) responses, the Location is the URI of the new resource which was created by the request. For 3xx responses,2251 </pre><p id="rfc.section.7.5.p.3">For 201 (Created) responses, the Location is the URI of the new resource which was created by the request. For 3xx responses, 2305 2252 the location <em class="bcp14">SHOULD</em> indicate the server's preferred URI for automatic redirection to the resource. 2306 2253 </p> 2307 <p id="rfc.section. 8.5.p.4">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>). If the original URI, as navigated to by the user agent, did contain a fragment identifier, and the final value does not,2254 <p id="rfc.section.7.5.p.4">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>). If the original URI, as navigated to by the user agent, did contain a fragment identifier, and the final value does not, 2308 2255 then the original URI's fragment identifier is added to the final value. 2309 2256 </p> … … 2314 2261 <p>An original URI "http://www.example.org/index.html#larry", combined with a field value given as:</p> <pre class="text"> Location: http://www.example.net/index.html 2315 2262 </pre> <p>would result in a final value of "http://www.example.net/index.html#larry", preserving the original fragment identifier.</p> 2316 <div class="note" id="rfc.section. 8.5.p.7">2263 <div class="note" id="rfc.section.7.5.p.7"> 2317 2264 <p> <b>Note:</b> Some recipients attempt to recover from Location fields that are not valid URI references. This specification does not mandate 2318 2265 or define such processing, but does allow it (see <a href="#intro.conformance.and.error.handling" title="Conformance and Error Handling">Section 1.1</a>). 2319 2266 </p> 2320 2267 </div> 2321 <p id="rfc.section. 8.5.p.8">There are circumstances in which a fragment identifier in a Location URI would not be appropriate. For instance, when it appears2268 <p id="rfc.section.7.5.p.8">There are circumstances in which a fragment identifier in a Location URI would not be appropriate. For instance, when it appears 2322 2269 in a 201 Created response, where the Location header field specifies the URI for the entire created resource. 2323 2270 </p> 2324 <div class="note" id="rfc.section. 8.5.p.9">2271 <div class="note" id="rfc.section.7.5.p.9"> 2325 2272 <p> <b>Note:</b> The Content-Location header field (<a href="p3-payload.html#header.content-location" title="Content-Location">Section 6.7</a> of <a href="#Part3" id="rfc.xref.Part3.13"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>) differs from Location in that the Content-Location identifies the most specific resource corresponding to the enclosed representation. 2326 2273 It is therefore possible for a response to contain header fields for both Location and Content-Location. … … 2329 2276 <div id="rfc.iref.m.9"></div> 2330 2277 <div id="rfc.iref.h.7"></div> 2331 <h2 id="rfc.section. 8.6"><a href="#rfc.section.8.6">8.6</a> <a id="header.max-forwards" href="#header.max-forwards">Max-Forwards</a></h2>2332 <p id="rfc.section. 8.6.p.1">The "Max-Forwards" header field provides a mechanism with the TRACE (<a href="#TRACE" id="rfc.xref.TRACE.2" title="TRACE">Section 6.8</a>) and OPTIONS (<a href="#OPTIONS" id="rfc.xref.OPTIONS.2" title="OPTIONS">Section 6.2</a>) methods to limit the number of times that the request is forwarded by proxies. This can be useful when the client is attempting2278 <h2 id="rfc.section.7.6"><a href="#rfc.section.7.6">7.6</a> <a id="header.max-forwards" href="#header.max-forwards">Max-Forwards</a></h2> 2279 <p id="rfc.section.7.6.p.1">The "Max-Forwards" header field provides a mechanism with the TRACE (<a href="#TRACE" id="rfc.xref.TRACE.1" title="TRACE">Section 2.3.7</a>) and OPTIONS (<a href="#OPTIONS" id="rfc.xref.OPTIONS.1" title="OPTIONS">Section 2.3.1</a>) methods to limit the number of times that the request is forwarded by proxies. This can be useful when the client is attempting 2333 2280 to trace a request which appears to be failing or looping mid-chain. 2334 2281 </p> 2335 2282 <div id="rfc.figure.u.28"></div><pre class="inline"><span id="rfc.iref.g.33"></span> <a href="#header.max-forwards" class="smpl">Max-Forwards</a> = 1*<a href="#notation" class="smpl">DIGIT</a> 2336 </pre><p id="rfc.section. 8.6.p.3">The Max-Forwards value is a decimal integer indicating the remaining number of times this request message can be forwarded.</p>2337 <p id="rfc.section. 8.6.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).2338 </p> 2339 <p id="rfc.section. 8.6.p.5">The Max-Forwards header field <em class="bcp14">MAY</em> be ignored for all other request methods.2283 </pre><p id="rfc.section.7.6.p.3">The Max-Forwards value is a decimal integer indicating the remaining number of times this request message can be forwarded.</p> 2284 <p id="rfc.section.7.6.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). 2285 </p> 2286 <p id="rfc.section.7.6.p.5">The Max-Forwards header field <em class="bcp14">MAY</em> be ignored for all other request methods. 2340 2287 </p> 2341 2288 <div id="rfc.iref.r.1"></div> 2342 2289 <div id="rfc.iref.h.8"></div> 2343 <h2 id="rfc.section. 8.7"><a href="#rfc.section.8.7">8.7</a> <a id="header.referer" href="#header.referer">Referer</a></h2>2344 <p id="rfc.section. 8.7.p.1">The "Referer" [sic] header field allows the client to specify the URI of the resource from which the target URI was obtained2290 <h2 id="rfc.section.7.7"><a href="#rfc.section.7.7">7.7</a> <a id="header.referer" href="#header.referer">Referer</a></h2> 2291 <p id="rfc.section.7.7.p.1">The "Referer" [sic] header field allows the client to specify the URI of the resource from which the target URI was obtained 2345 2292 (the "referrer", although the header field is misspelled.). 2346 2293 </p> 2347 <p id="rfc.section. 8.7.p.2">The Referer header field allows servers to generate lists of back-links to resources for interest, logging, optimized caching,2294 <p id="rfc.section.7.7.p.2">The Referer header field allows servers to generate lists of back-links to resources for interest, logging, optimized caching, 2348 2295 etc. It also allows obsolete or mistyped links to be traced for maintenance. Some servers use Referer as a means of controlling 2349 2296 where they allow links from (so-called "deep linking"), but legitimate requests do not always contain a Referer header field. 2350 2297 </p> 2351 <p id="rfc.section. 8.7.p.3">If the target URI was obtained from a source that does not have its own URI (e.g., input from the user keyboard), the Referer2298 <p id="rfc.section.7.7.p.3">If the target URI was obtained from a source that does not have its own URI (e.g., input from the user keyboard), the Referer 2352 2299 field <em class="bcp14">MUST</em> either be sent with the value "about:blank", or not be sent at all. Note that this requirement does not apply to sources with 2353 2300 non-HTTP URIs (e.g., FTP). 2354 2301 </p> 2355 2302 <div id="rfc.figure.u.29"></div><pre class="inline"><span id="rfc.iref.g.34"></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> 2356 </pre><p id="rfc.section. 8.7.p.5">Example:</p>2303 </pre><p id="rfc.section.7.7.p.5">Example:</p> 2357 2304 <div id="rfc.figure.u.30"></div><pre class="text"> Referer: http://www.example.org/hypertext/Overview.html 2358 </pre><p id="rfc.section. 8.7.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.2305 </pre><p id="rfc.section.7.7.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 9.2</a> for security considerations. 2359 2306 </p> 2360 2307 <div id="rfc.iref.r.2"></div> 2361 2308 <div id="rfc.iref.h.9"></div> 2362 <h2 id="rfc.section. 8.8"><a href="#rfc.section.8.8">8.8</a> <a id="header.retry-after" href="#header.retry-after">Retry-After</a></h2>2363 <p id="rfc.section. 8.8.p.1">The header "Retry-After" field can be used with a 503 (Service Unavailable) response to indicate how long the service is expected2309 <h2 id="rfc.section.7.8"><a href="#rfc.section.7.8">7.8</a> <a id="header.retry-after" href="#header.retry-after">Retry-After</a></h2> 2310 <p id="rfc.section.7.8.p.1">The header "Retry-After" field can be used with a 503 (Service Unavailable) response to indicate how long the service is expected 2364 2311 to be unavailable to the requesting client. This field <em class="bcp14">MAY</em> also be used with any 3xx (Redirection) response to indicate the minimum time the user-agent is asked to wait before issuing 2365 2312 the redirected request. 2366 2313 </p> 2367 <p id="rfc.section. 8.8.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>2314 <p id="rfc.section.7.8.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> 2368 2315 <div id="rfc.figure.u.31"></div><pre class="inline"><span id="rfc.iref.g.35"></span> <a href="#header.retry-after" class="smpl">Retry-After</a> = <a href="#http.date" class="smpl">HTTP-date</a> / <a href="#rule.delta-seconds" class="smpl">delta-seconds</a> 2369 2316 </pre><div id="rule.delta-seconds"> 2370 <p id="rfc.section. 8.8.p.4"> Time spans are non-negative decimal integers, representing time in seconds.</p>2317 <p id="rfc.section.7.8.p.4"> Time spans are non-negative decimal integers, representing time in seconds.</p> 2371 2318 </div> 2372 2319 <div id="rfc.figure.u.32"></div><pre class="inline"><span id="rfc.iref.g.36"></span> <a href="#rule.delta-seconds" class="smpl">delta-seconds</a> = 1*<a href="#notation" class="smpl">DIGIT</a> 2373 </pre><p id="rfc.section. 8.8.p.6">Two examples of its use are</p>2320 </pre><p id="rfc.section.7.8.p.6">Two examples of its use are</p> 2374 2321 <div id="rfc.figure.u.33"></div><pre class="text"> Retry-After: Fri, 31 Dec 1999 23:59:59 GMT 2375 2322 Retry-After: 120 2376 </pre><p id="rfc.section. 8.8.p.8">In the latter example, the delay is 2 minutes.</p>2323 </pre><p id="rfc.section.7.8.p.8">In the latter example, the delay is 2 minutes.</p> 2377 2324 <div id="rfc.iref.s.38"></div> 2378 2325 <div id="rfc.iref.h.10"></div> 2379 <h2 id="rfc.section. 8.9"><a href="#rfc.section.8.9">8.9</a> <a id="header.server" href="#header.server">Server</a></h2>2380 <p id="rfc.section. 8.9.p.1">The "Server" header field contains information about the software used by the origin server to handle the request.</p>2381 <p id="rfc.section. 8.9.p.2">The field can contain multiple product tokens (<a href="#product.tokens" title="Product Tokens">Section 7.2</a>) and comments (<a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.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 for2326 <h2 id="rfc.section.7.9"><a href="#rfc.section.7.9">7.9</a> <a id="header.server" href="#header.server">Server</a></h2> 2327 <p id="rfc.section.7.9.p.1">The "Server" header field contains information about the software used by the origin server to handle the request.</p> 2328 <p id="rfc.section.7.9.p.2">The field can contain multiple product tokens (<a href="#product.tokens" title="Product Tokens">Section 6.2</a>) and comments (<a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.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 2382 2329 identifying the application. 2383 2330 </p> 2384 2331 <div id="rfc.figure.u.34"></div><pre class="inline"><span id="rfc.iref.g.37"></span> <a href="#header.server" class="smpl">Server</a> = <a href="#product.tokens" class="smpl">product</a> *( <a href="#core.rules" class="smpl">RWS</a> ( <a href="#product.tokens" class="smpl">product</a> / <a href="#abnf.dependencies" class="smpl">comment</a> ) ) 2385 </pre><p id="rfc.section. 8.9.p.4">Example:</p>2332 </pre><p id="rfc.section.7.9.p.4">Example:</p> 2386 2333 <div id="rfc.figure.u.35"></div><pre class="text"> Server: CERN/3.0 libwww/2.17 2387 </pre><p id="rfc.section. 8.9.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 6.2</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>).2388 </p> 2389 <div class="note" id="rfc.section. 8.9.p.7">2334 </pre><p id="rfc.section.7.9.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 6.2</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>). 2335 </p> 2336 <div class="note" id="rfc.section.7.9.p.7"> 2390 2337 <p> <b>Note:</b> Revealing the specific software version of the server might allow the server machine to become more vulnerable to attacks 2391 2338 against software that is known to contain security holes. Server implementors are encouraged to make this field a configurable … … 2395 2342 <div id="rfc.iref.u.1"></div> 2396 2343 <div id="rfc.iref.h.11"></div> 2397 <h2 id="rfc.section. 8.10"><a href="#rfc.section.8.10">8.10</a> <a id="header.user-agent" href="#header.user-agent">User-Agent</a></h2>2398 <p id="rfc.section. 8.10.p.1">The "User-Agent" header field contains information about the user agent originating the request. User agents <em class="bcp14">SHOULD</em> include this field with requests.2399 </p> 2400 <p id="rfc.section. 8.10.p.2">Typically, it is used for statistical purposes, the tracing of protocol violations, and tailoring responses to avoid particular2344 <h2 id="rfc.section.7.10"><a href="#rfc.section.7.10">7.10</a> <a id="header.user-agent" href="#header.user-agent">User-Agent</a></h2> 2345 <p id="rfc.section.7.10.p.1">The "User-Agent" header field contains information about the user agent originating the request. User agents <em class="bcp14">SHOULD</em> include this field with requests. 2346 </p> 2347 <p id="rfc.section.7.10.p.2">Typically, it is used for statistical purposes, the tracing of protocol violations, and tailoring responses to avoid particular 2401 2348 user agent limitations. 2402 2349 </p> 2403 <p id="rfc.section. 8.10.p.3">The field can contain multiple product tokens (<a href="#product.tokens" title="Product Tokens">Section 7.2</a>) and comments (<a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.41"><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 significance2350 <p id="rfc.section.7.10.p.3">The field can contain multiple product tokens (<a href="#product.tokens" title="Product Tokens">Section 6.2</a>) and comments (<a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.41"><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 2404 2351 for identifying the application. 2405 2352 </p> 2406 <p id="rfc.section. 8.10.p.4">Because this field is usually sent on every request a user agent makes, implementations are encouraged not to include needlessly2353 <p id="rfc.section.7.10.p.4">Because this field is usually sent on every request a user agent makes, implementations are encouraged not to include needlessly 2407 2354 fine-grained detail, and to limit (or even prohibit) the addition of subproducts by third parties. Overly long and detailed 2408 2355 User-Agent field values make requests larger and can also be used to identify ("fingerprint") the user against their wishes. 2409 2356 </p> 2410 <p id="rfc.section. 8.10.p.5">Likewise, implementations are encouraged not to use the product tokens of other implementations in order to declare compatibility2357 <p id="rfc.section.7.10.p.5">Likewise, implementations are encouraged not to use the product tokens of other implementations in order to declare compatibility 2411 2358 with them, as this circumvents the purpose of the field. Finally, they are encouraged not to use comments to identify products; 2412 2359 doing so makes the field value more difficult to parse. 2413 2360 </p> 2414 2361 <div id="rfc.figure.u.36"></div><pre class="inline"><span id="rfc.iref.g.38"></span> <a href="#header.user-agent" class="smpl">User-Agent</a> = <a href="#product.tokens" class="smpl">product</a> *( <a href="#core.rules" class="smpl">RWS</a> ( <a href="#product.tokens" class="smpl">product</a> / <a href="#abnf.dependencies" class="smpl">comment</a> ) ) 2415 </pre><p id="rfc.section. 8.10.p.7">Example:</p>2362 </pre><p id="rfc.section.7.10.p.7">Example:</p> 2416 2363 <div id="rfc.figure.u.37"></div><pre class="text"> User-Agent: CERN-LineMode/2.15 libwww/2.17b3 2417 </pre><h1 id="rfc.section. 9"><a href="#rfc.section.9">9.</a> <a id="IANA.considerations" href="#IANA.considerations">IANA Considerations</a></h1>2418 <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>2419 <p id="rfc.section. 9.1.p.1">The registration procedure for HTTP request methods is defined by <a href="#method.registry" title="Method Registry">Section 2.2</a> of this document.2420 </p> 2421 <p id="rfc.section. 9.1.p.2">The HTTP Method Registry shall be created at <<a href="http://www.iana.org/assignments/http-methods">http://www.iana.org/assignments/http-methods</a>> and be populated with the registrations below:2364 </pre><h1 id="rfc.section.8"><a href="#rfc.section.8">8.</a> <a id="IANA.considerations" href="#IANA.considerations">IANA Considerations</a></h1> 2365 <h2 id="rfc.section.8.1"><a href="#rfc.section.8.1">8.1</a> <a id="method.registration" href="#method.registration">Method Registry</a></h2> 2366 <p id="rfc.section.8.1.p.1">The registration procedure for HTTP request methods is defined by <a href="#method.registry" title="Method Registry">Section 2.2</a> of this document. 2367 </p> 2368 <p id="rfc.section.8.1.p.2">The HTTP Method Registry shall be created at <<a href="http://www.iana.org/assignments/http-methods">http://www.iana.org/assignments/http-methods</a>> and be populated with the registrations below: 2422 2369 </p> 2423 2370 <div id="rfc.table.1"> … … 2435 2382 <td class="left">CONNECT</td> 2436 2383 <td class="left">no</td> 2437 <td class="left"> <a href="#CONNECT" id="rfc.xref.CONNECT. 2" title="CONNECT">Section 6.9</a>2384 <td class="left"> <a href="#CONNECT" id="rfc.xref.CONNECT.1" title="CONNECT">Section 2.3.8</a> 2438 2385 </td> 2439 2386 </tr> … … 2441 2388 <td class="left">DELETE</td> 2442 2389 <td class="left">no</td> 2443 <td class="left"> <a href="#DELETE" id="rfc.xref.DELETE. 2" title="DELETE">Section 6.7</a>2390 <td class="left"> <a href="#DELETE" id="rfc.xref.DELETE.1" title="DELETE">Section 2.3.6</a> 2444 2391 </td> 2445 2392 </tr> … … 2447 2394 <td class="left">GET</td> 2448 2395 <td class="left">yes</td> 2449 <td class="left"> <a href="#GET" id="rfc.xref.GET. 2" title="GET">Section 6.3</a>2396 <td class="left"> <a href="#GET" id="rfc.xref.GET.1" title="GET">Section 2.3.2</a> 2450 2397 </td> 2451 2398 </tr> … … 2453 2400 <td class="left">HEAD</td> 2454 2401 <td class="left">yes</td> 2455 <td class="left"> <a href="#HEAD" id="rfc.xref.HEAD. 2" title="HEAD">Section 6.4</a>2402 <td class="left"> <a href="#HEAD" id="rfc.xref.HEAD.1" title="HEAD">Section 2.3.3</a> 2456 2403 </td> 2457 2404 </tr> … … 2459 2406 <td class="left">OPTIONS</td> 2460 2407 <td class="left">yes</td> 2461 <td class="left"> <a href="#OPTIONS" id="rfc.xref.OPTIONS. 3" title="OPTIONS">Section 6.2</a>2408 <td class="left"> <a href="#OPTIONS" id="rfc.xref.OPTIONS.2" title="OPTIONS">Section 2.3.1</a> 2462 2409 </td> 2463 2410 </tr> … … 2465 2412 <td class="left">POST</td> 2466 2413 <td class="left">no</td> 2467 <td class="left"> <a href="#POST" id="rfc.xref.POST. 2" title="POST">Section 6.5</a>2414 <td class="left"> <a href="#POST" id="rfc.xref.POST.1" title="POST">Section 2.3.4</a> 2468 2415 </td> 2469 2416 </tr> … … 2471 2418 <td class="left">PUT</td> 2472 2419 <td class="left">no</td> 2473 <td class="left"> <a href="#PUT" id="rfc.xref.PUT. 2" title="PUT">Section 6.6</a>2420 <td class="left"> <a href="#PUT" id="rfc.xref.PUT.1" title="PUT">Section 2.3.5</a> 2474 2421 </td> 2475 2422 </tr> … … 2477 2424 <td class="left">TRACE</td> 2478 2425 <td class="left">yes</td> 2479 <td class="left"> <a href="#TRACE" id="rfc.xref.TRACE. 3" title="TRACE">Section 6.8</a>2426 <td class="left"> <a href="#TRACE" id="rfc.xref.TRACE.2" title="TRACE">Section 2.3.7</a> 2480 2427 </td> 2481 2428 </tr> … … 2483 2430 </table> 2484 2431 </div> 2485 <h2 id="rfc.section. 9.2"><a href="#rfc.section.9.2">9.2</a> <a id="status.code.registration" href="#status.code.registration">Status Code Registry</a></h2>2486 <p id="rfc.section. 9.2.p.1">The registration procedure for HTTP Status Codes — previously defined in <a href="http://tools.ietf.org/html/rfc2817#section-7.1">Section 7.1</a> of <a href="#RFC2817" id="rfc.xref.RFC2817.1"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a> — is now defined by <a href="#status.code.registry" title="Status Code Registry">Section 4.2</a> of this document.2487 </p> 2488 <p id="rfc.section. 9.2.p.2">The HTTP Status Code Registry located at <<a href="http://www.iana.org/assignments/http-status-codes">http://www.iana.org/assignments/http-status-codes</a>> shall be updated with the registrations below:2432 <h2 id="rfc.section.8.2"><a href="#rfc.section.8.2">8.2</a> <a id="status.code.registration" href="#status.code.registration">Status Code Registry</a></h2> 2433 <p id="rfc.section.8.2.p.1">The registration procedure for HTTP Status Codes — previously defined in <a href="http://tools.ietf.org/html/rfc2817#section-7.1">Section 7.1</a> of <a href="#RFC2817" id="rfc.xref.RFC2817.1"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a> — is now defined by <a href="#status.code.registry" title="Status Code Registry">Section 4.2</a> of this document. 2434 </p> 2435 <p id="rfc.section.8.2.p.2">The HTTP Status Code Registry located at <<a href="http://www.iana.org/assignments/http-status-codes">http://www.iana.org/assignments/http-status-codes</a>> shall be updated with the registrations below: 2489 2436 </p> 2490 2437 <div id="rfc.table.2"> … … 2718 2665 </table> 2719 2666 </div> 2720 <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>2721 <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>):2667 <h2 id="rfc.section.8.3"><a href="#rfc.section.8.3">8.3</a> <a id="header.field.registration" href="#header.field.registration">Header Field Registration</a></h2> 2668 <p id="rfc.section.8.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>): 2722 2669 </p> 2723 2670 <div id="rfc.table.3"> … … 2737 2684 <td class="left">http</td> 2738 2685 <td class="left">standard</td> 2739 <td class="left"> <a href="#header.allow" id="rfc.xref.header.allow.3" title="Allow">Section 8.1</a>2686 <td class="left"> <a href="#header.allow" id="rfc.xref.header.allow.3" title="Allow">Section 7.1</a> 2740 2687 </td> 2741 2688 </tr> … … 2744 2691 <td class="left">http</td> 2745 2692 <td class="left">standard</td> 2746 <td class="left"> <a href="#header.date" id="rfc.xref.header.date.2" title="Date">Section 8.2</a>2693 <td class="left"> <a href="#header.date" id="rfc.xref.header.date.2" title="Date">Section 7.2</a> 2747 2694 </td> 2748 2695 </tr> … … 2751 2698 <td class="left">http</td> 2752 2699 <td class="left">standard</td> 2753 <td class="left"> <a href="#header.expect" id="rfc.xref.header.expect.3" title="Expect">Section 8.3</a>2700 <td class="left"> <a href="#header.expect" id="rfc.xref.header.expect.3" title="Expect">Section 7.3</a> 2754 2701 </td> 2755 2702 </tr> … … 2758 2705 <td class="left">http</td> 2759 2706 <td class="left">standard</td> 2760 <td class="left"> <a href="#header.from" id="rfc.xref.header.from.2" title="From">Section 8.4</a>2707 <td class="left"> <a href="#header.from" id="rfc.xref.header.from.2" title="From">Section 7.4</a> 2761 2708 </td> 2762 2709 </tr> … … 2765 2712 <td class="left">http</td> 2766 2713 <td class="left">standard</td> 2767 <td class="left"> <a href="#header.location" id="rfc.xref.header.location.4" title="Location">Section 8.5</a>2714 <td class="left"> <a href="#header.location" id="rfc.xref.header.location.4" title="Location">Section 7.5</a> 2768 2715 </td> 2769 2716 </tr> … … 2772 2719 <td class="left">http</td> 2773 2720 <td class="left">standard</td> 2774 <td class="left"> <a href="#header.max-forwards" id="rfc.xref.header.max-forwards.4" title="Max-Forwards">Section 8.6</a>2721 <td class="left"> <a href="#header.max-forwards" id="rfc.xref.header.max-forwards.4" title="Max-Forwards">Section 7.6</a> 2775 2722 </td> 2776 2723 </tr> … … 2779 2726 <td class="left">http</td> 2780 2727 <td class="left">standard</td> 2781 <td class="left"> <a href="#header.referer" id="rfc.xref.header.referer.2" title="Referer">Section 8.7</a>2728 <td class="left"> <a href="#header.referer" id="rfc.xref.header.referer.2" title="Referer">Section 7.7</a> 2782 2729 </td> 2783 2730 </tr> … … 2786 2733 <td class="left">http</td> 2787 2734 <td class="left">standard</td> 2788 <td class="left"> <a href="#header.retry-after" id="rfc.xref.header.retry-after.3" title="Retry-After">Section 8.8</a>2735 <td class="left"> <a href="#header.retry-after" id="rfc.xref.header.retry-after.3" title="Retry-After">Section 7.8</a> 2789 2736 </td> 2790 2737 </tr> … … 2793 2740 <td class="left">http</td> 2794 2741 <td class="left">standard</td> 2795 <td class="left"> <a href="#header.server" id="rfc.xref.header.server.2" title="Server">Section 8.9</a>2742 <td class="left"> <a href="#header.server" id="rfc.xref.header.server.2" title="Server">Section 7.9</a> 2796 2743 </td> 2797 2744 </tr> … … 2800 2747 <td class="left">http</td> 2801 2748 <td class="left">standard</td> 2802 <td class="left"> <a href="#header.user-agent" id="rfc.xref.header.user-agent.2" title="User-Agent">Section 8.10</a>2749 <td class="left"> <a href="#header.user-agent" id="rfc.xref.header.user-agent.2" title="User-Agent">Section 7.10</a> 2803 2750 </td> 2804 2751 </tr> … … 2806 2753 </table> 2807 2754 </div> 2808 <p id="rfc.section. 9.3.p.2">The change controller is: "IETF (iesg@ietf.org) - Internet Engineering Task Force".</p>2809 <h1 id="rfc.section. 10"><a href="#rfc.section.10">10.</a> <a id="security.considerations" href="#security.considerations">Security Considerations</a></h1>2810 <p id="rfc.section. 10.p.1">This section is meant to inform application developers, information providers, and users of the security limitations in HTTP/1.12755 <p id="rfc.section.8.3.p.2">The change controller is: "IETF (iesg@ietf.org) - Internet Engineering Task Force".</p> 2756 <h1 id="rfc.section.9"><a href="#rfc.section.9">9.</a> <a id="security.considerations" href="#security.considerations">Security Considerations</a></h1> 2757 <p id="rfc.section.9.p.1">This section is meant to inform application developers, information providers, and users of the security limitations in HTTP/1.1 2811 2758 as described by this document. The discussion does not include definitive solutions to the problems revealed, though it does 2812 2759 make some suggestions for reducing security risks. 2813 2760 </p> 2814 <h2 id="rfc.section. 10.1"><a href="#rfc.section.10.1">10.1</a> <a id="security.sensitive" href="#security.sensitive">Transfer of Sensitive Information</a></h2>2815 <p id="rfc.section. 10.1.p.1">Like any generic data transfer protocol, HTTP cannot regulate the content of the data that is transferred, nor is there any2761 <h2 id="rfc.section.9.1"><a href="#rfc.section.9.1">9.1</a> <a id="security.sensitive" href="#security.sensitive">Transfer of Sensitive Information</a></h2> 2762 <p id="rfc.section.9.1.p.1">Like any generic data transfer protocol, HTTP cannot regulate the content of the data that is transferred, nor is there any 2816 2763 a priori method of determining the sensitivity of any particular piece of information within the context of any given request. 2817 2764 Therefore, applications <em class="bcp14">SHOULD</em> supply as much control over this information as possible to the provider of that information. Four header fields are worth 2818 2765 special mention in this context: Server, Via, Referer and From. 2819 2766 </p> 2820 <p id="rfc.section. 10.1.p.2">Revealing the specific software version of the server might allow the server machine to become more vulnerable to attacks2767 <p id="rfc.section.9.1.p.2">Revealing the specific software version of the server might allow the server machine to become more vulnerable to attacks 2821 2768 against software that is known to contain security holes. Implementors <em class="bcp14">SHOULD</em> make the Server header field a configurable option. 2822 2769 </p> 2823 <p id="rfc.section. 10.1.p.3">Proxies which serve as a portal through a network firewall <em class="bcp14">SHOULD</em> take special precautions regarding the transfer of header information that identifies the hosts behind the firewall. In particular,2770 <p id="rfc.section.9.1.p.3">Proxies which serve as a portal through a network firewall <em class="bcp14">SHOULD</em> take special precautions regarding the transfer of header information that identifies the hosts behind the firewall. In particular, 2824 2771 they <em class="bcp14">SHOULD</em> remove, or replace with sanitized versions, any Via fields generated behind the firewall. 2825 2772 </p> 2826 <p id="rfc.section. 10.1.p.4">The Referer header field allows reading patterns to be studied and reverse links drawn. Although it can be very useful, its2773 <p id="rfc.section.9.1.p.4">The Referer header field allows reading patterns to be studied and reverse links drawn. Although it can be very useful, its 2827 2774 power can be abused if user details are not separated from the information contained in the Referer. Even when the personal 2828 2775 information has been removed, the Referer header field might indicate a private document's URI whose publication would be 2829 2776 inappropriate. 2830 2777 </p> 2831 <p id="rfc.section. 10.1.p.5">The information sent in the From field might conflict with the user's privacy interests or their site's security policy, and2778 <p id="rfc.section.9.1.p.5">The information sent in the From field might conflict with the user's privacy interests or their site's security policy, and 2832 2779 hence it <em class="bcp14">SHOULD NOT</em> be transmitted without the user being able to disable, enable, and modify the contents of the field. The user <em class="bcp14">MUST</em> be able to set the contents of this field within a user preference or application defaults configuration. 2833 2780 </p> 2834 <p id="rfc.section. 10.1.p.6">We suggest, though do not require, that a convenient toggle interface be provided for the user to enable or disable the sending2781 <p id="rfc.section.9.1.p.6">We suggest, though do not require, that a convenient toggle interface be provided for the user to enable or disable the sending 2835 2782 of From and Referer information. 2836 2783 </p> 2837 <p id="rfc.section. 10.1.p.7">The User-Agent (<a href="#header.user-agent" id="rfc.xref.header.user-agent.3" title="User-Agent">Section 8.10</a>) or Server (<a href="#header.server" id="rfc.xref.header.server.3" title="Server">Section 8.9</a>) header fields can sometimes be used to determine that a specific client or server has a particular security hole which might2784 <p id="rfc.section.9.1.p.7">The User-Agent (<a href="#header.user-agent" id="rfc.xref.header.user-agent.3" title="User-Agent">Section 7.10</a>) or Server (<a href="#header.server" id="rfc.xref.header.server.3" title="Server">Section 7.9</a>) header fields can sometimes be used to determine that a specific client or server has a particular security hole which might 2838 2785 be exploited. Unfortunately, this same information is often used for other valuable purposes for which HTTP currently has 2839 2786 no better mechanism. 2840 2787 </p> 2841 <p id="rfc.section. 10.1.p.8">Furthermore, the User-Agent header field may contain enough entropy to be used, possibly in conjunction with other material,2788 <p id="rfc.section.9.1.p.8">Furthermore, the User-Agent header field may contain enough entropy to be used, possibly in conjunction with other material, 2842 2789 to uniquely identify the user. 2843 2790 </p> 2844 <p id="rfc.section. 10.1.p.9">Some request methods, like TRACE (<a href="#TRACE" id="rfc.xref.TRACE.4" title="TRACE">Section 6.8</a>), expose information that was sent in request header fields within the body of their response. Clients <em class="bcp14">SHOULD</em> be careful with sensitive information, like Cookies, Authorization credentials, and other header fields that might be used2791 <p id="rfc.section.9.1.p.9">Some request methods, like TRACE (<a href="#TRACE" id="rfc.xref.TRACE.3" title="TRACE">Section 2.3.7</a>), expose information that was sent in request header fields within the body of their response. Clients <em class="bcp14">SHOULD</em> be careful with sensitive information, like Cookies, Authorization credentials, and other header fields that might be used 2845 2792 to collect data from the client. 2846 2793 </p> 2847 <h2 id="rfc.section. 10.2"><a href="#rfc.section.10.2">10.2</a> <a id="encoding.sensitive.information.in.uris" href="#encoding.sensitive.information.in.uris">Encoding Sensitive Information in URIs</a></h2>2848 <p id="rfc.section. 10.2.p.1">Because the source of a link might be private information or might reveal an otherwise private information source, it is strongly2794 <h2 id="rfc.section.9.2"><a href="#rfc.section.9.2">9.2</a> <a id="encoding.sensitive.information.in.uris" href="#encoding.sensitive.information.in.uris">Encoding Sensitive Information in URIs</a></h2> 2795 <p id="rfc.section.9.2.p.1">Because the source of a link might be private information or might reveal an otherwise private information source, it is strongly 2849 2796 recommended that the user be able to select whether or not the Referer field is sent. For example, a browser client could 2850 2797 have a toggle switch for browsing openly/anonymously, which would respectively enable/disable the sending of Referer and From 2851 2798 information. 2852 2799 </p> 2853 <p id="rfc.section. 10.2.p.2">Clients <em class="bcp14">SHOULD NOT</em> include a Referer header field in a (non-secure) HTTP request if the referring page was transferred with a secure protocol.2854 </p> 2855 <p id="rfc.section. 10.2.p.3">Authors of services <em class="bcp14">SHOULD NOT</em> use GET-based forms for the submission of sensitive data because that data will be placed in the request-target. Many existing2800 <p id="rfc.section.9.2.p.2">Clients <em class="bcp14">SHOULD NOT</em> include a Referer header field in a (non-secure) HTTP request if the referring page was transferred with a secure protocol. 2801 </p> 2802 <p id="rfc.section.9.2.p.3">Authors of services <em class="bcp14">SHOULD NOT</em> use GET-based forms for the submission of sensitive data because that data will be placed in the request-target. Many existing 2856 2803 servers, proxies, and user agents log or display the request-target in places where it might be visible to third parties. 2857 2804 Such services can use POST-based form submission instead. 2858 2805 </p> 2859 <h2 id="rfc.section. 10.3"><a href="#rfc.section.10.3">10.3</a> <a id="location.spoofing-leakage" href="#location.spoofing-leakage">Location Header Fields: Spoofing and Information Leakage</a></h2>2860 <p id="rfc.section. 10.3.p.1">If a single server supports multiple organizations that do not trust one another, then it <em class="bcp14">MUST</em> check the values of Location and Content-Location header fields in responses that are generated under control of said organizations2806 <h2 id="rfc.section.9.3"><a href="#rfc.section.9.3">9.3</a> <a id="location.spoofing-leakage" href="#location.spoofing-leakage">Location Header Fields: Spoofing and Information Leakage</a></h2> 2807 <p id="rfc.section.9.3.p.1">If a single server supports multiple organizations that do not trust one another, then it <em class="bcp14">MUST</em> check the values of Location and Content-Location header fields in responses that are generated under control of said organizations 2861 2808 to make sure that they do not attempt to invalidate resources over which they have no authority. 2862 2809 </p> 2863 <p id="rfc.section. 10.3.p.2">Furthermore, appending the fragment identifier from one URI to another one obtained from a Location header field might leak2810 <p id="rfc.section.9.3.p.2">Furthermore, appending the fragment identifier from one URI to another one obtained from a Location header field might leak 2864 2811 confidential information to the target server — although the fragment identifier is not transmitted in the final request, 2865 2812 it might be visible to the user agent through other means, such as scripting. 2866 2813 </p> 2867 <h2 id="rfc.section. 10.4"><a href="#rfc.section.10.4">10.4</a> Security Considerations for CONNECT2814 <h2 id="rfc.section.9.4"><a href="#rfc.section.9.4">9.4</a> Security Considerations for CONNECT 2868 2815 </h2> 2869 <p id="rfc.section. 10.4.p.1">Since tunneled data is opaque to the proxy, there are additional risks to tunneling to other well-known or reserved ports.2816 <p id="rfc.section.9.4.p.1">Since tunneled data is opaque to the proxy, there are additional risks to tunneling to other well-known or reserved ports. 2870 2817 A HTTP client CONNECTing to port 25 could relay spam via SMTP, for example. As such, proxies <em class="bcp14">SHOULD</em> restrict CONNECT access to a small number of known ports. 2871 2818 </p> 2872 <h1 id="rfc.section.1 1"><a href="#rfc.section.11">11.</a> <a id="acks" href="#acks">Acknowledgments</a></h1>2873 <p id="rfc.section.1 1.p.1">See <a href="p1-messaging.html#acks" title="Acknowledgments">Section 9</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>.2874 </p> 2875 <h1 id="rfc.references"><a id="rfc.section.1 2" href="#rfc.section.12">12.</a> References2819 <h1 id="rfc.section.10"><a href="#rfc.section.10">10.</a> <a id="acks" href="#acks">Acknowledgments</a></h1> 2820 <p id="rfc.section.10.p.1">See <a href="p1-messaging.html#acks" title="Acknowledgments">Section 9</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>. 2821 </p> 2822 <h1 id="rfc.references"><a id="rfc.section.11" href="#rfc.section.11">11.</a> References 2876 2823 </h1> 2877 <h2 id="rfc.references.1"><a href="#rfc.section.1 2.1" id="rfc.section.12.1">12.1</a> Normative References2824 <h2 id="rfc.references.1"><a href="#rfc.section.11.1" id="rfc.section.11.1">11.1</a> Normative References 2878 2825 </h2> 2879 2826 <table> … … 2924 2871 </tr> 2925 2872 </table> 2926 <h2 id="rfc.references.2"><a href="#rfc.section.1 2.2" id="rfc.section.12.2">12.2</a> Informative References2873 <h2 id="rfc.references.2"><a href="#rfc.section.11.2" id="rfc.section.11.2">11.2</a> Informative References 2927 2874 </h2> 2928 2875 <table> … … 2996 2943 </div> 2997 2944 <h1 id="rfc.section.A" class="np"><a href="#rfc.section.A">A.</a> <a id="changes.from.rfc.2616" href="#changes.from.rfc.2616">Changes from RFC 2616</a></h1> 2998 <p id="rfc.section.A.p.1">This document takes over the Status Code Registry, previously defined in <a href="http://tools.ietf.org/html/rfc2817#section-7.1">Section 7.1</a> of <a href="#RFC2817" id="rfc.xref.RFC2817.2"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a>. (<a href="#status.code.registry" title="Status Code Registry">Section 4.2</a>) 2999 </p> 3000 <p id="rfc.section.A.p.2">Broadened the definition of 203 (Non-Authoritative Information) to include cases of payload transformations as well. (<a href="#status.203" id="rfc.xref.status.203.3" title="203 Non-Authoritative Information">Section 4.3.2.4</a>) 3001 </p> 3002 <p id="rfc.section.A.p.3">Status codes 301, 302, and 307: removed the normative requirements on both response payloads and user interaction. (<a href="#status.3xx" title="Redirection 3xx">Section 4.3.3</a>) 3003 </p> 3004 <p id="rfc.section.A.p.4">Failed to consider that there are many other request methods that are safe to automatically redirect, and further that the 2945 <p id="rfc.section.A.p.1">Clarify definition of POST. (<a href="#POST" id="rfc.xref.POST.2" title="POST">Section 2.3.4</a>) 2946 </p> 2947 <p id="rfc.section.A.p.2">Remove requirement to handle all Content-* header fields; ban use of Content-Range with PUT. (<a href="#PUT" id="rfc.xref.PUT.2" title="PUT">Section 2.3.5</a>) 2948 </p> 2949 <p id="rfc.section.A.p.3">Take over definition of CONNECT method from <a href="#RFC2817" id="rfc.xref.RFC2817.2"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a>. (<a href="#CONNECT" id="rfc.xref.CONNECT.2" title="CONNECT">Section 2.3.8</a>) 2950 </p> 2951 <p id="rfc.section.A.p.4">This document takes over the Status Code Registry, previously defined in <a href="http://tools.ietf.org/html/rfc2817#section-7.1">Section 7.1</a> of <a href="#RFC2817" id="rfc.xref.RFC2817.3"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a>. (<a href="#status.code.registry" title="Status Code Registry">Section 4.2</a>) 2952 </p> 2953 <p id="rfc.section.A.p.5">Broadened the definition of 203 (Non-Authoritative Information) to include cases of payload transformations as well. (<a href="#status.203" id="rfc.xref.status.203.3" title="203 Non-Authoritative Information">Section 4.3.2.4</a>) 2954 </p> 2955 <p id="rfc.section.A.p.6">Status codes 301, 302, and 307: removed the normative requirements on both response payloads and user interaction. (<a href="#status.3xx" title="Redirection 3xx">Section 4.3.3</a>) 2956 </p> 2957 <p id="rfc.section.A.p.7">Failed to consider that there are many other request methods that are safe to automatically redirect, and further that the 3005 2958 user agent is able to make that determination based on the request method semantics. Furthermore, allow user agents to rewrite 3006 2959 the method from POST to GET for status codes 301 and 302. (Sections <a href="#status.301" id="rfc.xref.status.301.3" title="301 Moved Permanently">4.3.3.2</a>, <a href="#status.302" id="rfc.xref.status.302.3" title="302 Found">4.3.3.3</a> and <a href="#status.307" id="rfc.xref.status.307.3" title="307 Temporary Redirect">4.3.3.7</a>) 3007 2960 </p> 3008 <p id="rfc.section.A.p. 5">Deprecate 305 Use Proxy status code, because user agents did not implement it. It used to indicate that the target resource2961 <p id="rfc.section.A.p.8">Deprecate 305 Use Proxy status code, because user agents did not implement it. It used to indicate that the target resource 3009 2962 needs to be accessed through the proxy given by the Location field. The Location field gave the URI of the proxy. The recipient 3010 2963 was expected to repeat this single request via the proxy. (<a href="#status.305" id="rfc.xref.status.305.3" title="305 Use Proxy">Section 4.3.3.5</a>) 3011 2964 </p> 3012 <p id="rfc.section.A.p.6">Define status 426 (Upgrade Required) (this was incorporated from <a href="#RFC2817" id="rfc.xref.RFC2817.3"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a>). (<a href="#status.426" id="rfc.xref.status.426.3" title="426 Upgrade Required">Section 4.3.4.15</a>) 3013 </p> 3014 <p id="rfc.section.A.p.7">Clarify definition of POST. (<a href="#POST" id="rfc.xref.POST.3" title="POST">Section 6.5</a>) 3015 </p> 3016 <p id="rfc.section.A.p.8">Remove requirement to handle all Content-* header fields; ban use of Content-Range with PUT. (<a href="#PUT" id="rfc.xref.PUT.3" title="PUT">Section 6.6</a>) 3017 </p> 3018 <p id="rfc.section.A.p.9">Take over definition of CONNECT method from <a href="#RFC2817" id="rfc.xref.RFC2817.4"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a>. (<a href="#CONNECT" id="rfc.xref.CONNECT.3" title="CONNECT">Section 6.9</a>) 3019 </p> 3020 <p id="rfc.section.A.p.10">Change ABNF productions for header fields to only define the field value. (<a href="#header.field.definitions" title="Header Field Definitions">Section 8</a>) 2965 <p id="rfc.section.A.p.9">Define status 426 (Upgrade Required) (this was incorporated from <a href="#RFC2817" id="rfc.xref.RFC2817.4"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a>). (<a href="#status.426" id="rfc.xref.status.426.3" title="426 Upgrade Required">Section 4.3.4.15</a>) 2966 </p> 2967 <p id="rfc.section.A.p.10">Change ABNF productions for header fields to only define the field value. (<a href="#header.field.definitions" title="Header Field Definitions">Section 7</a>) 3021 2968 </p> 3022 2969 <p id="rfc.section.A.p.11">Reclassify "Allow" as response header field, removing the option to specify it in a PUT request. Relax the server requirement 3023 on the contents of the Allow header field and remove requirement on clients to always trust the header field value. (<a href="#header.allow" id="rfc.xref.header.allow.4" title="Allow">Section 8.1</a>)2970 on the contents of the Allow header field and remove requirement on clients to always trust the header field value. (<a href="#header.allow" id="rfc.xref.header.allow.4" title="Allow">Section 7.1</a>) 3024 2971 </p> 3025 2972 <p id="rfc.section.A.p.12">The ABNF for the Expect header field has been both fixed (allowing parameters for value-less expectations as well) and simplified 3026 (allowing trailing semicolons after "100-continue" when they were invalid before). (<a href="#header.expect" id="rfc.xref.header.expect.4" title="Expect">Section 8.3</a>)2973 (allowing trailing semicolons after "100-continue" when they were invalid before). (<a href="#header.expect" id="rfc.xref.header.expect.4" title="Expect">Section 7.3</a>) 3027 2974 </p> 3028 2975 <p id="rfc.section.A.p.13">Correct syntax of Location header field to allow URI references (including relative references and fragments), as referred 3029 2976 symbol "absoluteURI" wasn't what was expected, and add some clarifications as to when use of fragments would not be appropriate. 3030 (<a href="#header.location" id="rfc.xref.header.location.5" title="Location">Section 8.5</a>)3031 </p> 3032 <p id="rfc.section.A.p.14">Restrict Max-Forwards header field to OPTIONS and TRACE (previously, extension methods could have used it as well). (<a href="#header.max-forwards" id="rfc.xref.header.max-forwards.5" title="Max-Forwards">Section 8.6</a>)3033 </p> 3034 <p id="rfc.section.A.p.15">Allow Referer field value of "about:blank" as alternative to not specifying it. (<a href="#header.referer" id="rfc.xref.header.referer.3" title="Referer">Section 8.7</a>)2977 (<a href="#header.location" id="rfc.xref.header.location.5" title="Location">Section 7.5</a>) 2978 </p> 2979 <p id="rfc.section.A.p.14">Restrict Max-Forwards header field to OPTIONS and TRACE (previously, extension methods could have used it as well). (<a href="#header.max-forwards" id="rfc.xref.header.max-forwards.5" title="Max-Forwards">Section 7.6</a>) 2980 </p> 2981 <p id="rfc.section.A.p.15">Allow Referer field value of "about:blank" as alternative to not specifying it. (<a href="#header.referer" id="rfc.xref.header.referer.3" title="Referer">Section 7.7</a>) 3035 2982 </p> 3036 2983 <p id="rfc.section.A.p.16">In the description of the Server header field, the Via field was described as a SHOULD. The requirement was and is stated 3037 correctly in the description of the Via header field in <a href="p1-messaging.html#header.via" title="Via">Section 6.2</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>. (<a href="#header.server" id="rfc.xref.header.server.4" title="Server">Section 8.9</a>)2984 correctly in the description of the Via header field in <a href="p1-messaging.html#header.via" title="Via">Section 6.2</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>. (<a href="#header.server" id="rfc.xref.header.server.4" title="Server">Section 7.9</a>) 3038 2985 </p> 3039 2986 <h1 id="rfc.section.B"><a href="#rfc.section.B">B.</a> <a id="collected.abnf" href="#collected.abnf">Collected ABNF</a></h1> … … 3101 3048 3102 3049 <a href="#header.from" class="smpl">mailbox</a> = <mailbox, defined in [RFC5322], Section 3.4> 3103 <a href="#method " class="smpl">method</a> = token3050 <a href="#methods" class="smpl">method</a> = token 3104 3051 <a href="#preferred.date.format" class="smpl">minute</a> = 2DIGIT 3105 3052 <a href="#preferred.date.format" class="smpl">month</a> = %x4A.61.6E ; Jan … … 3478 3425 <ul class="ind"> 3479 3426 <li><a id="rfc.index.1" href="#rfc.index.1"><b>1</b></a><ul> 3480 <li>100 Continue (status code) <a href="#rfc.xref.status.100.1">4.1</a>, <a href="#rfc.iref. 4"><b>4.3.1.1</b></a>, <a href="#rfc.xref.status.100.2">9.2</a></li>3481 <li>100-continue (expect value) <a href="#rfc.iref.89"><b> 8.3</b></a></li>3482 <li>101 Switching Protocols (status code) <a href="#rfc.xref.status.101.1">4.1</a>, <a href="#rfc.iref. 5"><b>4.3.1.2</b></a>, <a href="#rfc.xref.status.101.2">9.2</a></li>3427 <li>100 Continue (status code) <a href="#rfc.xref.status.100.1">4.1</a>, <a href="#rfc.iref.22"><b>4.3.1.1</b></a>, <a href="#rfc.xref.status.100.2">8.2</a></li> 3428 <li>100-continue (expect value) <a href="#rfc.iref.89"><b>7.3</b></a></li> 3429 <li>101 Switching Protocols (status code) <a href="#rfc.xref.status.101.1">4.1</a>, <a href="#rfc.iref.23"><b>4.3.1.2</b></a>, <a href="#rfc.xref.status.101.2">8.2</a></li> 3483 3430 </ul> 3484 3431 </li> 3485 3432 <li><a id="rfc.index.2" href="#rfc.index.2"><b>2</b></a><ul> 3486 <li>200 OK (status code) <a href="#rfc.xref.status.200.1">4.1</a>, <a href="#rfc.iref. 6"><b>4.3.2.1</b></a>, <a href="#rfc.xref.status.200.2">9.2</a></li>3487 <li>201 Created (status code) <a href="#rfc.xref.status.201.1">4.1</a>, <a href="#rfc.iref. 7"><b>4.3.2.2</b></a>, <a href="#rfc.xref.status.201.2">9.2</a></li>3488 <li>202 Accepted (status code) <a href="#rfc.xref.status.202.1">4.1</a>, <a href="#rfc.iref. 8"><b>4.3.2.3</b></a>, <a href="#rfc.xref.status.202.2">9.2</a></li>3489 <li>203 Non-Authoritative Information (status code) <a href="#rfc.xref.status.203.1">4.1</a>, <a href="#rfc.iref. 9"><b>4.3.2.4</b></a>, <a href="#rfc.xref.status.203.2">9.2</a>, <a href="#rfc.xref.status.203.3">A</a></li>3490 <li>204 No Content (status code) <a href="#rfc.xref.status.204.1">4.1</a>, <a href="#rfc.iref. 10"><b>4.3.2.5</b></a>, <a href="#rfc.xref.status.204.2">9.2</a></li>3491 <li>205 Reset Content (status code) <a href="#rfc.xref.status.205.1">4.1</a>, <a href="#rfc.iref. 11"><b>4.3.2.6</b></a>, <a href="#rfc.xref.status.205.2">9.2</a></li>3433 <li>200 OK (status code) <a href="#rfc.xref.status.200.1">4.1</a>, <a href="#rfc.iref.24"><b>4.3.2.1</b></a>, <a href="#rfc.xref.status.200.2">8.2</a></li> 3434 <li>201 Created (status code) <a href="#rfc.xref.status.201.1">4.1</a>, <a href="#rfc.iref.25"><b>4.3.2.2</b></a>, <a href="#rfc.xref.status.201.2">8.2</a></li> 3435 <li>202 Accepted (status code) <a href="#rfc.xref.status.202.1">4.1</a>, <a href="#rfc.iref.26"><b>4.3.2.3</b></a>, <a href="#rfc.xref.status.202.2">8.2</a></li> 3436 <li>203 Non-Authoritative Information (status code) <a href="#rfc.xref.status.203.1">4.1</a>, <a href="#rfc.iref.27"><b>4.3.2.4</b></a>, <a href="#rfc.xref.status.203.2">8.2</a>, <a href="#rfc.xref.status.203.3">A</a></li> 3437 <li>204 No Content (status code) <a href="#rfc.xref.status.204.1">4.1</a>, <a href="#rfc.iref.28"><b>4.3.2.5</b></a>, <a href="#rfc.xref.status.204.2">8.2</a></li> 3438 <li>205 Reset Content (status code) <a href="#rfc.xref.status.205.1">4.1</a>, <a href="#rfc.iref.29"><b>4.3.2.6</b></a>, <a href="#rfc.xref.status.205.2">8.2</a></li> 3492 3439 </ul> 3493 3440 </li> 3494 3441 <li><a id="rfc.index.3" href="#rfc.index.3"><b>3</b></a><ul> 3495 <li>300 Multiple Choices (status code) <a href="#rfc.xref.status.300.1">4.1</a>, <a href="#rfc.iref. 12"><b>4.3.3.1</b></a>, <a href="#rfc.xref.status.300.2">9.2</a></li>3496 <li>301 Moved Permanently (status code) <a href="#rfc.xref.status.301.1">4.1</a>, <a href="#rfc.iref. 13"><b>4.3.3.2</b></a>, <a href="#rfc.xref.status.301.2">9.2</a>, <a href="#rfc.xref.status.301.3">A</a></li>3497 <li>302 Found (status code) <a href="#rfc.xref.status.302.1">4.1</a>, <a href="#rfc.iref. 14"><b>4.3.3.3</b></a>, <a href="#rfc.xref.status.302.2">9.2</a>, <a href="#rfc.xref.status.302.3">A</a></li>3498 <li>303 See Other (status code) <a href="#rfc.xref.status.303.1">4.1</a>, <a href="#rfc.iref. 15"><b>4.3.3.4</b></a>, <a href="#rfc.xref.status.303.2">9.2</a></li>3499 <li>305 Use Proxy (status code) <a href="#rfc.xref.status.305.1">4.1</a>, <a href="#rfc.iref. 16"><b>4.3.3.5</b></a>, <a href="#rfc.xref.status.305.2">9.2</a>, <a href="#rfc.xref.status.305.3">A</a></li>3500 <li>306 (Unused) (status code) <a href="#rfc.iref. 17"><b>4.3.3.6</b></a>, <a href="#rfc.xref.status.306.1">9.2</a></li>3501 <li>307 Temporary Redirect (status code) <a href="#rfc.xref.status.307.1">4.1</a>, <a href="#rfc.iref. 18"><b>4.3.3.7</b></a>, <a href="#rfc.xref.status.307.2">9.2</a>, <a href="#rfc.xref.status.307.3">A</a></li>3442 <li>300 Multiple Choices (status code) <a href="#rfc.xref.status.300.1">4.1</a>, <a href="#rfc.iref.30"><b>4.3.3.1</b></a>, <a href="#rfc.xref.status.300.2">8.2</a></li> 3443 <li>301 Moved Permanently (status code) <a href="#rfc.xref.status.301.1">4.1</a>, <a href="#rfc.iref.31"><b>4.3.3.2</b></a>, <a href="#rfc.xref.status.301.2">8.2</a>, <a href="#rfc.xref.status.301.3">A</a></li> 3444 <li>302 Found (status code) <a href="#rfc.xref.status.302.1">4.1</a>, <a href="#rfc.iref.32"><b>4.3.3.3</b></a>, <a href="#rfc.xref.status.302.2">8.2</a>, <a href="#rfc.xref.status.302.3">A</a></li> 3445 <li>303 See Other (status code) <a href="#rfc.xref.status.303.1">4.1</a>, <a href="#rfc.iref.33"><b>4.3.3.4</b></a>, <a href="#rfc.xref.status.303.2">8.2</a></li> 3446 <li>305 Use Proxy (status code) <a href="#rfc.xref.status.305.1">4.1</a>, <a href="#rfc.iref.34"><b>4.3.3.5</b></a>, <a href="#rfc.xref.status.305.2">8.2</a>, <a href="#rfc.xref.status.305.3">A</a></li> 3447 <li>306 (Unused) (status code) <a href="#rfc.iref.35"><b>4.3.3.6</b></a>, <a href="#rfc.xref.status.306.1">8.2</a></li> 3448 <li>307 Temporary Redirect (status code) <a href="#rfc.xref.status.307.1">4.1</a>, <a href="#rfc.iref.36"><b>4.3.3.7</b></a>, <a href="#rfc.xref.status.307.2">8.2</a>, <a href="#rfc.xref.status.307.3">A</a></li> 3502 3449 </ul> 3503 3450 </li> 3504 3451 <li><a id="rfc.index.4" href="#rfc.index.4"><b>4</b></a><ul> 3505 <li>400 Bad Request (status code) <a href="#rfc.xref.status.400.1">4.1</a>, <a href="#rfc.iref. 19"><b>4.3.4.1</b></a>, <a href="#rfc.xref.status.400.2">9.2</a></li>3506 <li>402 Payment Required (status code) <a href="#rfc.xref.status.402.1">4.1</a>, <a href="#rfc.iref. 20"><b>4.3.4.2</b></a>, <a href="#rfc.xref.status.402.2">9.2</a></li>3507 <li>403 Forbidden (status code) <a href="#rfc.xref.status.403.1">4.1</a>, <a href="#rfc.iref. 21"><b>4.3.4.3</b></a>, <a href="#rfc.xref.status.403.2">9.2</a></li>3508 <li>404 Not Found (status code) <a href="#rfc.xref.status.404.1">4.1</a>, <a href="#rfc.iref. 22"><b>4.3.4.4</b></a>, <a href="#rfc.xref.status.404.2">9.2</a></li>3509 <li>405 Method Not Allowed (status code) <a href="#rfc.xref.status.405.1">4.1</a>, <a href="#rfc.iref. 23"><b>4.3.4.5</b></a>, <a href="#rfc.xref.status.405.2">9.2</a></li>3510 <li>406 Not Acceptable (status code) <a href="#rfc.xref.status.406.1">4.1</a>, <a href="#rfc.iref. 24"><b>4.3.4.6</b></a>, <a href="#rfc.xref.status.406.2">9.2</a></li>3511 <li>408 Request Timeout (status code) <a href="#rfc.xref.status.408.1">4.1</a>, <a href="#rfc.iref. 25"><b>4.3.4.7</b></a>, <a href="#rfc.xref.status.408.2">9.2</a></li>3512 <li>409 Conflict (status code) <a href="#rfc.xref.status.409.1">4.1</a>, <a href="#rfc.iref. 26"><b>4.3.4.8</b></a>, <a href="#rfc.xref.status.409.2">9.2</a></li>3513 <li>410 Gone (status code) <a href="#rfc.xref.status.410.1">4.1</a>, <a href="#rfc.iref. 27"><b>4.3.4.9</b></a>, <a href="#rfc.xref.status.410.2">9.2</a></li>3514 <li>411 Length Required (status code) <a href="#rfc.xref.status.411.1">4.1</a>, <a href="#rfc.iref. 28"><b>4.3.4.10</b></a>, <a href="#rfc.xref.status.411.2">9.2</a></li>3515 <li>413 Request Representation Too Large (status code) <a href="#rfc.xref.status.413.1">4.1</a>, <a href="#rfc.iref. 29"><b>4.3.4.11</b></a>, <a href="#rfc.xref.status.413.2">9.2</a></li>3516 <li>414 URI Too Long (status code) <a href="#rfc.xref.status.414.1">4.1</a>, <a href="#rfc.iref. 30"><b>4.3.4.12</b></a>, <a href="#rfc.xref.status.414.2">9.2</a></li>3517 <li>415 Unsupported Media Type (status code) <a href="#rfc.xref.status.415.1">4.1</a>, <a href="#rfc.iref. 31"><b>4.3.4.13</b></a>, <a href="#rfc.xref.status.415.2">9.2</a></li>3518 <li>417 Expectation Failed (status code) <a href="#rfc.xref.status.417.1">4.1</a>, <a href="#rfc.iref. 32"><b>4.3.4.14</b></a>, <a href="#rfc.xref.status.417.2">9.2</a></li>3519 <li>426 Upgrade Required (status code) <a href="#rfc.xref.status.426.1">4.1</a>, <a href="#rfc.iref. 33"><b>4.3.4.15</b></a>, <a href="#rfc.xref.status.426.2">9.2</a>, <a href="#rfc.xref.status.426.3">A</a></li>3452 <li>400 Bad Request (status code) <a href="#rfc.xref.status.400.1">4.1</a>, <a href="#rfc.iref.37"><b>4.3.4.1</b></a>, <a href="#rfc.xref.status.400.2">8.2</a></li> 3453 <li>402 Payment Required (status code) <a href="#rfc.xref.status.402.1">4.1</a>, <a href="#rfc.iref.38"><b>4.3.4.2</b></a>, <a href="#rfc.xref.status.402.2">8.2</a></li> 3454 <li>403 Forbidden (status code) <a href="#rfc.xref.status.403.1">4.1</a>, <a href="#rfc.iref.39"><b>4.3.4.3</b></a>, <a href="#rfc.xref.status.403.2">8.2</a></li> 3455 <li>404 Not Found (status code) <a href="#rfc.xref.status.404.1">4.1</a>, <a href="#rfc.iref.40"><b>4.3.4.4</b></a>, <a href="#rfc.xref.status.404.2">8.2</a></li> 3456 <li>405 Method Not Allowed (status code) <a href="#rfc.xref.status.405.1">4.1</a>, <a href="#rfc.iref.41"><b>4.3.4.5</b></a>, <a href="#rfc.xref.status.405.2">8.2</a></li> 3457 <li>406 Not Acceptable (status code) <a href="#rfc.xref.status.406.1">4.1</a>, <a href="#rfc.iref.42"><b>4.3.4.6</b></a>, <a href="#rfc.xref.status.406.2">8.2</a></li> 3458 <li>408 Request Timeout (status code) <a href="#rfc.xref.status.408.1">4.1</a>, <a href="#rfc.iref.43"><b>4.3.4.7</b></a>, <a href="#rfc.xref.status.408.2">8.2</a></li> 3459 <li>409 Conflict (status code) <a href="#rfc.xref.status.409.1">4.1</a>, <a href="#rfc.iref.44"><b>4.3.4.8</b></a>, <a href="#rfc.xref.status.409.2">8.2</a></li> 3460 <li>410 Gone (status code) <a href="#rfc.xref.status.410.1">4.1</a>, <a href="#rfc.iref.45"><b>4.3.4.9</b></a>, <a href="#rfc.xref.status.410.2">8.2</a></li> 3461 <li>411 Length Required (status code) <a href="#rfc.xref.status.411.1">4.1</a>, <a href="#rfc.iref.46"><b>4.3.4.10</b></a>, <a href="#rfc.xref.status.411.2">8.2</a></li> 3462 <li>413 Request Representation Too Large (status code) <a href="#rfc.xref.status.413.1">4.1</a>, <a href="#rfc.iref.47"><b>4.3.4.11</b></a>, <a href="#rfc.xref.status.413.2">8.2</a></li> 3463 <li>414 URI Too Long (status code) <a href="#rfc.xref.status.414.1">4.1</a>, <a href="#rfc.iref.48"><b>4.3.4.12</b></a>, <a href="#rfc.xref.status.414.2">8.2</a></li> 3464 <li>415 Unsupported Media Type (status code) <a href="#rfc.xref.status.415.1">4.1</a>, <a href="#rfc.iref.49"><b>4.3.4.13</b></a>, <a href="#rfc.xref.status.415.2">8.2</a></li> 3465 <li>417 Expectation Failed (status code) <a href="#rfc.xref.status.417.1">4.1</a>, <a href="#rfc.iref.50"><b>4.3.4.14</b></a>, <a href="#rfc.xref.status.417.2">8.2</a></li> 3466 <li>426 Upgrade Required (status code) <a href="#rfc.xref.status.426.1">4.1</a>, <a href="#rfc.iref.51"><b>4.3.4.15</b></a>, <a href="#rfc.xref.status.426.2">8.2</a>, <a href="#rfc.xref.status.426.3">A</a></li> 3520 3467 </ul> 3521 3468 </li> 3522 3469 <li><a id="rfc.index.5" href="#rfc.index.5"><b>5</b></a><ul> 3523 <li>500 Internal Server Error (status code) <a href="#rfc.xref.status.500.1">4.1</a>, <a href="#rfc.iref. 34"><b>4.3.5.1</b></a>, <a href="#rfc.xref.status.500.2">9.2</a></li>3524 <li>501 Not Implemented (status code) <a href="#rfc.xref.status.501.1">4.1</a>, <a href="#rfc.iref. 35"><b>4.3.5.2</b></a>, <a href="#rfc.xref.status.501.2">9.2</a></li>3525 <li>502 Bad Gateway (status code) <a href="#rfc.xref.status.502.1">4.1</a>, <a href="#rfc.iref. 36"><b>4.3.5.3</b></a>, <a href="#rfc.xref.status.502.2">9.2</a></li>3526 <li>503 Service Unavailable (status code) <a href="#rfc.xref.status.503.1">4.1</a>, <a href="#rfc.iref. 37"><b>4.3.5.4</b></a>, <a href="#rfc.xref.status.503.2">9.2</a></li>3527 <li>504 Gateway Timeout (status code) <a href="#rfc.xref.status.504.1">4.1</a>, <a href="#rfc.iref. 38"><b>4.3.5.5</b></a>, <a href="#rfc.xref.status.504.2">9.2</a></li>3528 <li>505 HTTP Version Not Supported (status code) <a href="#rfc.xref.status.505.1">4.1</a>, <a href="#rfc.iref. 39"><b>4.3.5.6</b></a>, <a href="#rfc.xref.status.505.2">9.2</a></li>3470 <li>500 Internal Server Error (status code) <a href="#rfc.xref.status.500.1">4.1</a>, <a href="#rfc.iref.52"><b>4.3.5.1</b></a>, <a href="#rfc.xref.status.500.2">8.2</a></li> 3471 <li>501 Not Implemented (status code) <a href="#rfc.xref.status.501.1">4.1</a>, <a href="#rfc.iref.53"><b>4.3.5.2</b></a>, <a href="#rfc.xref.status.501.2">8.2</a></li> 3472 <li>502 Bad Gateway (status code) <a href="#rfc.xref.status.502.1">4.1</a>, <a href="#rfc.iref.54"><b>4.3.5.3</b></a>, <a href="#rfc.xref.status.502.2">8.2</a></li> 3473 <li>503 Service Unavailable (status code) <a href="#rfc.xref.status.503.1">4.1</a>, <a href="#rfc.iref.55"><b>4.3.5.4</b></a>, <a href="#rfc.xref.status.503.2">8.2</a></li> 3474 <li>504 Gateway Timeout (status code) <a href="#rfc.xref.status.504.1">4.1</a>, <a href="#rfc.iref.56"><b>4.3.5.5</b></a>, <a href="#rfc.xref.status.504.2">8.2</a></li> 3475 <li>505 HTTP Version Not Supported (status code) <a href="#rfc.xref.status.505.1">4.1</a>, <a href="#rfc.iref.57"><b>4.3.5.6</b></a>, <a href="#rfc.xref.status.505.2">8.2</a></li> 3529 3476 </ul> 3530 3477 </li> 3531 3478 <li><a id="rfc.index.A" href="#rfc.index.A"><b>A</b></a><ul> 3532 <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>3479 <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>7.1</b></a>, <a href="#rfc.xref.header.allow.3">8.3</a>, <a href="#rfc.xref.header.allow.4">A</a></li> 3533 3480 </ul> 3534 3481 </li> 3535 3482 <li><a id="rfc.index.C" href="#rfc.index.C"><b>C</b></a><ul> 3536 <li>CONNECT method <a href="#rfc. xref.CONNECT.1">2.1</a>, <a href="#rfc.iref.c.1"><b>6.9</b></a>, <a href="#rfc.xref.CONNECT.2">9.1</a>, <a href="#rfc.xref.CONNECT.3">A</a></li>3483 <li>CONNECT method <a href="#rfc.iref.c.1"><b>2.3.8</b></a>, <a href="#rfc.xref.CONNECT.1">8.1</a>, <a href="#rfc.xref.CONNECT.2">A</a></li> 3537 3484 </ul> 3538 3485 </li> 3539 3486 <li><a id="rfc.index.D" href="#rfc.index.D"><b>D</b></a><ul> 3540 <li>Date header field <a href="#rfc.xref.header.date.1">3.3</a>, <a href="#rfc.iref.d.2"><b> 8.2</b></a>, <a href="#rfc.xref.header.date.2">9.3</a></li>3541 <li>DELETE method <a href="#rfc. xref.DELETE.1">2.1</a>, <a href="#rfc.iref.d.1"><b>6.7</b></a>, <a href="#rfc.xref.DELETE.2">9.1</a></li>3542 <li><em>draft-reschke-http-status-308</em> <a href="#rfc.xref.draft-reschke-http-status-308.1">4.3.3.7</a>, <a href="#draft-reschke-http-status-308"><b>1 2.2</b></a></li>3487 <li>Date header field <a href="#rfc.xref.header.date.1">3.3</a>, <a href="#rfc.iref.d.2"><b>7.2</b></a>, <a href="#rfc.xref.header.date.2">8.3</a></li> 3488 <li>DELETE method <a href="#rfc.iref.d.1"><b>2.3.6</b></a>, <a href="#rfc.xref.DELETE.1">8.1</a></li> 3489 <li><em>draft-reschke-http-status-308</em> <a href="#rfc.xref.draft-reschke-http-status-308.1">4.3.3.7</a>, <a href="#draft-reschke-http-status-308"><b>11.2</b></a></li> 3543 3490 </ul> 3544 3491 </li> 3545 3492 <li><a id="rfc.index.E" href="#rfc.index.E"><b>E</b></a><ul> 3546 <li>Expect header field <a href="#rfc.xref.header.expect.1">3.2</a>, <a href="#rfc.xref.header.expect.2">4.3.4.14</a>, <a href="#rfc.iref.e.1"><b> 8.3</b></a>, <a href="#rfc.xref.header.expect.3">9.3</a>, <a href="#rfc.xref.header.expect.4">A</a></li>3493 <li>Expect header field <a href="#rfc.xref.header.expect.1">3.2</a>, <a href="#rfc.xref.header.expect.2">4.3.4.14</a>, <a href="#rfc.iref.e.1"><b>7.3</b></a>, <a href="#rfc.xref.header.expect.3">8.3</a>, <a href="#rfc.xref.header.expect.4">A</a></li> 3547 3494 <li>Expect Values 3548 3495 <ul> 3549 <li>100-continue <a href="#rfc.iref.e.2"><b> 8.3</b></a></li>3496 <li>100-continue <a href="#rfc.iref.e.2"><b>7.3</b></a></li> 3550 3497 </ul> 3551 3498 </li> … … 3553 3500 </li> 3554 3501 <li><a id="rfc.index.F" href="#rfc.index.F"><b>F</b></a><ul> 3555 <li>From header field <a href="#rfc.xref.header.from.1">3.2</a>, <a href="#rfc.iref.f.1"><b> 8.4</b></a>, <a href="#rfc.xref.header.from.2">9.3</a></li>3502 <li>From header field <a href="#rfc.xref.header.from.1">3.2</a>, <a href="#rfc.iref.f.1"><b>7.4</b></a>, <a href="#rfc.xref.header.from.2">8.3</a></li> 3556 3503 </ul> 3557 3504 </li> 3558 3505 <li><a id="rfc.index.G" href="#rfc.index.G"><b>G</b></a><ul> 3559 <li>GET method <a href="#rfc. xref.GET.1">2.1</a>, <a href="#rfc.iref.g.5"><b>6.3</b></a>, <a href="#rfc.xref.GET.2">9.1</a></li>3506 <li>GET method <a href="#rfc.iref.g.2"><b>2.3.2</b></a>, <a href="#rfc.xref.GET.1">8.1</a></li> 3560 3507 <li><tt>Grammar</tt> 3561 3508 <ul> 3562 <li><tt>Allow</tt> <a href="#rfc.iref.g.24"><b> 8.1</b></a></li>3563 <li><tt>asctime-date</tt> <a href="#rfc.iref.g.21"><b> 7.1</b></a></li>3564 <li><tt>Date</tt> <a href="#rfc.iref.g.25"><b> 8.2</b></a></li>3565 <li><tt>date1</tt> <a href="#rfc.iref.g.8"><b> 7.1</b></a></li>3566 <li><tt>day</tt> <a href="#rfc.iref.g.15"><b> 7.1</b></a></li>3567 <li><tt>day-name</tt> <a href="#rfc.iref.g.13"><b> 7.1</b></a></li>3568 <li><tt>day-name-l</tt> <a href="#rfc.iref.g.14"><b> 7.1</b></a></li>3569 <li><tt>delta-seconds</tt> <a href="#rfc.iref.g.36"><b> 8.8</b></a></li>3570 <li><tt>Expect</tt> <a href="#rfc.iref.g.26"><b> 8.3</b></a></li>3571 <li><tt>expect-name</tt> <a href="#rfc.iref.g.30"><b> 8.3</b></a></li>3572 <li><tt>expect-param</tt> <a href="#rfc.iref.g.28"><b> 8.3</b></a></li>3573 <li><tt>expect-value</tt> <a href="#rfc.iref.g.29"><b> 8.3</b></a></li>3574 <li><tt>expectation</tt> <a href="#rfc.iref.g.27"><b> 8.3</b></a></li>3575 <li><tt>extension-code</tt> <a href="#rfc.iref.g. 3"><b>4</b></a></li>3576 <li><tt>From</tt> <a href="#rfc.iref.g.31"><b> 8.4</b></a></li>3577 <li><tt>GMT</tt> <a href="#rfc.iref.g.18"><b> 7.1</b></a></li>3578 <li><tt>hour</tt> <a href="#rfc.iref.g.10"><b> 7.1</b></a></li>3579 <li><tt>HTTP-date</tt> <a href="#rfc.iref.g.6"><b> 7.1</b></a></li>3580 <li><tt>Location</tt> <a href="#rfc.iref.g.32"><b> 8.5</b></a></li>3581 <li><tt>Max-Forwards</tt> <a href="#rfc.iref.g.33"><b> 8.6</b></a></li>3509 <li><tt>Allow</tt> <a href="#rfc.iref.g.24"><b>7.1</b></a></li> 3510 <li><tt>asctime-date</tt> <a href="#rfc.iref.g.21"><b>6.1</b></a></li> 3511 <li><tt>Date</tt> <a href="#rfc.iref.g.25"><b>7.2</b></a></li> 3512 <li><tt>date1</tt> <a href="#rfc.iref.g.8"><b>6.1</b></a></li> 3513 <li><tt>day</tt> <a href="#rfc.iref.g.15"><b>6.1</b></a></li> 3514 <li><tt>day-name</tt> <a href="#rfc.iref.g.13"><b>6.1</b></a></li> 3515 <li><tt>day-name-l</tt> <a href="#rfc.iref.g.14"><b>6.1</b></a></li> 3516 <li><tt>delta-seconds</tt> <a href="#rfc.iref.g.36"><b>7.8</b></a></li> 3517 <li><tt>Expect</tt> <a href="#rfc.iref.g.26"><b>7.3</b></a></li> 3518 <li><tt>expect-name</tt> <a href="#rfc.iref.g.30"><b>7.3</b></a></li> 3519 <li><tt>expect-param</tt> <a href="#rfc.iref.g.28"><b>7.3</b></a></li> 3520 <li><tt>expect-value</tt> <a href="#rfc.iref.g.29"><b>7.3</b></a></li> 3521 <li><tt>expectation</tt> <a href="#rfc.iref.g.27"><b>7.3</b></a></li> 3522 <li><tt>extension-code</tt> <a href="#rfc.iref.g.4"><b>4</b></a></li> 3523 <li><tt>From</tt> <a href="#rfc.iref.g.31"><b>7.4</b></a></li> 3524 <li><tt>GMT</tt> <a href="#rfc.iref.g.18"><b>6.1</b></a></li> 3525 <li><tt>hour</tt> <a href="#rfc.iref.g.10"><b>6.1</b></a></li> 3526 <li><tt>HTTP-date</tt> <a href="#rfc.iref.g.6"><b>6.1</b></a></li> 3527 <li><tt>Location</tt> <a href="#rfc.iref.g.32"><b>7.5</b></a></li> 3528 <li><tt>Max-Forwards</tt> <a href="#rfc.iref.g.33"><b>7.6</b></a></li> 3582 3529 <li><tt>method</tt> <a href="#rfc.iref.g.1"><b>2</b></a></li> 3583 <li><tt>minute</tt> <a href="#rfc.iref.g.11"><b> 7.1</b></a></li>3584 <li><tt>month</tt> <a href="#rfc.iref.g.16"><b> 7.1</b></a></li>3585 <li><tt>obs-date</tt> <a href="#rfc.iref.g.19"><b> 7.1</b></a></li>3586 <li><tt>product</tt> <a href="#rfc.iref.g.22"><b> 7.2</b></a></li>3587 <li><tt>product-version</tt> <a href="#rfc.iref.g.23"><b> 7.2</b></a></li>3588 <li><tt>reason-phrase</tt> <a href="#rfc.iref.g. 4"><b>4</b></a></li>3589 <li><tt>Referer</tt> <a href="#rfc.iref.g.34"><b> 8.7</b></a></li>3590 <li><tt>Retry-After</tt> <a href="#rfc.iref.g.35"><b> 8.8</b></a></li>3591 <li><tt>rfc1123-date</tt> <a href="#rfc.iref.g.7"><b> 7.1</b></a></li>3592 <li><tt>rfc850-date</tt> <a href="#rfc.iref.g.20"><b> 7.1</b></a></li>3593 <li><tt>second</tt> <a href="#rfc.iref.g.12"><b> 7.1</b></a></li>3594 <li><tt>Server</tt> <a href="#rfc.iref.g.37"><b> 8.9</b></a></li>3595 <li><tt>status-code</tt> <a href="#rfc.iref.g. 2"><b>4</b></a></li>3596 <li><tt>time-of-day</tt> <a href="#rfc.iref.g.9"><b> 7.1</b></a></li>3597 <li><tt>User-Agent</tt> <a href="#rfc.iref.g.38"><b> 8.10</b></a></li>3598 <li><tt>year</tt> <a href="#rfc.iref.g.17"><b> 7.1</b></a></li>3530 <li><tt>minute</tt> <a href="#rfc.iref.g.11"><b>6.1</b></a></li> 3531 <li><tt>month</tt> <a href="#rfc.iref.g.16"><b>6.1</b></a></li> 3532 <li><tt>obs-date</tt> <a href="#rfc.iref.g.19"><b>6.1</b></a></li> 3533 <li><tt>product</tt> <a href="#rfc.iref.g.22"><b>6.2</b></a></li> 3534 <li><tt>product-version</tt> <a href="#rfc.iref.g.23"><b>6.2</b></a></li> 3535 <li><tt>reason-phrase</tt> <a href="#rfc.iref.g.5"><b>4</b></a></li> 3536 <li><tt>Referer</tt> <a href="#rfc.iref.g.34"><b>7.7</b></a></li> 3537 <li><tt>Retry-After</tt> <a href="#rfc.iref.g.35"><b>7.8</b></a></li> 3538 <li><tt>rfc1123-date</tt> <a href="#rfc.iref.g.7"><b>6.1</b></a></li> 3539 <li><tt>rfc850-date</tt> <a href="#rfc.iref.g.20"><b>6.1</b></a></li> 3540 <li><tt>second</tt> <a href="#rfc.iref.g.12"><b>6.1</b></a></li> 3541 <li><tt>Server</tt> <a href="#rfc.iref.g.37"><b>7.9</b></a></li> 3542 <li><tt>status-code</tt> <a href="#rfc.iref.g.3"><b>4</b></a></li> 3543 <li><tt>time-of-day</tt> <a href="#rfc.iref.g.9"><b>6.1</b></a></li> 3544 <li><tt>User-Agent</tt> <a href="#rfc.iref.g.38"><b>7.10</b></a></li> 3545 <li><tt>year</tt> <a href="#rfc.iref.g.17"><b>6.1</b></a></li> 3599 3546 </ul> 3600 3547 </li> … … 3602 3549 </li> 3603 3550 <li><a id="rfc.index.H" href="#rfc.index.H"><b>H</b></a><ul> 3604 <li>HEAD method <a href="#rfc. xref.HEAD.1">2.1</a>, <a href="#rfc.iref.h.1"><b>6.4</b></a>, <a href="#rfc.xref.HEAD.2">9.1</a></li>3551 <li>HEAD method <a href="#rfc.iref.h.1"><b>2.3.3</b></a>, <a href="#rfc.xref.HEAD.1">8.1</a></li> 3605 3552 <li>Header Fields 3606 3553 <ul> 3607 <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>3608 <li>Date <a href="#rfc.xref.header.date.1">3.3</a>, <a href="#rfc.iref.h.3"><b> 8.2</b></a>, <a href="#rfc.xref.header.date.2">9.3</a></li>3609 <li>Expect <a href="#rfc.xref.header.expect.1">3.2</a>, <a href="#rfc.xref.header.expect.2">4.3.4.14</a>, <a href="#rfc.iref.h.4"><b> 8.3</b></a>, <a href="#rfc.xref.header.expect.3">9.3</a>, <a href="#rfc.xref.header.expect.4">A</a></li>3610 <li>From <a href="#rfc.xref.header.from.1">3.2</a>, <a href="#rfc.iref.h.5"><b> 8.4</b></a>, <a href="#rfc.xref.header.from.2">9.3</a></li>3611 <li>Location <a href="#rfc.xref.header.location.1"> 3.3</a>, <a href="#rfc.xref.header.location.2">4.3.3</a>, <a href="#rfc.xref.header.location.3">6.5</a>, <a href="#rfc.iref.h.6"><b>8.5</b></a>, <a href="#rfc.xref.header.location.4">9.3</a>, <a href="#rfc.xref.header.location.5">A</a></li>3612 <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.7"><b>8.6</b></a>, <a href="#rfc.xref.header.max-forwards.4">9.3</a>, <a href="#rfc.xref.header.max-forwards.5">A</a></li>3613 <li>Referer <a href="#rfc.xref.header.referer.1">3.2</a>, <a href="#rfc.iref.h.8"><b> 8.7</b></a>, <a href="#rfc.xref.header.referer.2">9.3</a>, <a href="#rfc.xref.header.referer.3">A</a></li>3614 <li>Retry-After <a href="#rfc.xref.header.retry-after.1">3.3</a>, <a href="#rfc.xref.header.retry-after.2">4.3.5.4</a>, <a href="#rfc.iref.h.9"><b> 8.8</b></a>, <a href="#rfc.xref.header.retry-after.3">9.3</a></li>3615 <li>Server <a href="#rfc.xref.header.server.1">3.3</a>, <a href="#rfc.iref.h.10"><b> 8.9</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>3616 <li>User-Agent <a href="#rfc.xref.header.user-agent.1">3.2</a>, <a href="#rfc.iref.h.11"><b> 8.10</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>3554 <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>7.1</b></a>, <a href="#rfc.xref.header.allow.3">8.3</a>, <a href="#rfc.xref.header.allow.4">A</a></li> 3555 <li>Date <a href="#rfc.xref.header.date.1">3.3</a>, <a href="#rfc.iref.h.3"><b>7.2</b></a>, <a href="#rfc.xref.header.date.2">8.3</a></li> 3556 <li>Expect <a href="#rfc.xref.header.expect.1">3.2</a>, <a href="#rfc.xref.header.expect.2">4.3.4.14</a>, <a href="#rfc.iref.h.4"><b>7.3</b></a>, <a href="#rfc.xref.header.expect.3">8.3</a>, <a href="#rfc.xref.header.expect.4">A</a></li> 3557 <li>From <a href="#rfc.xref.header.from.1">3.2</a>, <a href="#rfc.iref.h.5"><b>7.4</b></a>, <a href="#rfc.xref.header.from.2">8.3</a></li> 3558 <li>Location <a href="#rfc.xref.header.location.1">2.3.4</a>, <a href="#rfc.xref.header.location.2">3.3</a>, <a href="#rfc.xref.header.location.3">4.3.3</a>, <a href="#rfc.iref.h.6"><b>7.5</b></a>, <a href="#rfc.xref.header.location.4">8.3</a>, <a href="#rfc.xref.header.location.5">A</a></li> 3559 <li>Max-Forwards <a href="#rfc.xref.header.max-forwards.1">2.3.1</a>, <a href="#rfc.xref.header.max-forwards.2">2.3.7</a>, <a href="#rfc.xref.header.max-forwards.3">3.2</a>, <a href="#rfc.iref.h.7"><b>7.6</b></a>, <a href="#rfc.xref.header.max-forwards.4">8.3</a>, <a href="#rfc.xref.header.max-forwards.5">A</a></li> 3560 <li>Referer <a href="#rfc.xref.header.referer.1">3.2</a>, <a href="#rfc.iref.h.8"><b>7.7</b></a>, <a href="#rfc.xref.header.referer.2">8.3</a>, <a href="#rfc.xref.header.referer.3">A</a></li> 3561 <li>Retry-After <a href="#rfc.xref.header.retry-after.1">3.3</a>, <a href="#rfc.xref.header.retry-after.2">4.3.5.4</a>, <a href="#rfc.iref.h.9"><b>7.8</b></a>, <a href="#rfc.xref.header.retry-after.3">8.3</a></li> 3562 <li>Server <a href="#rfc.xref.header.server.1">3.3</a>, <a href="#rfc.iref.h.10"><b>7.9</b></a>, <a href="#rfc.xref.header.server.2">8.3</a>, <a href="#rfc.xref.header.server.3">9.1</a>, <a href="#rfc.xref.header.server.4">A</a></li> 3563 <li>User-Agent <a href="#rfc.xref.header.user-agent.1">3.2</a>, <a href="#rfc.iref.h.11"><b>7.10</b></a>, <a href="#rfc.xref.header.user-agent.2">8.3</a>, <a href="#rfc.xref.header.user-agent.3">9.1</a></li> 3617 3564 </ul> 3618 3565 </li> … … 3620 3567 </li> 3621 3568 <li><a id="rfc.index.I" href="#rfc.index.I"><b>I</b></a><ul> 3622 <li>Idempotent Methods <a href="#rfc.iref.i.1"><b> 6.1.2</b></a></li>3569 <li>Idempotent Methods <a href="#rfc.iref.i.1"><b>2.1.2</b></a></li> 3623 3570 </ul> 3624 3571 </li> 3625 3572 <li><a id="rfc.index.L" href="#rfc.index.L"><b>L</b></a><ul> 3626 <li>Location header field <a href="#rfc.xref.header.location.1"> 3.3</a>, <a href="#rfc.xref.header.location.2">4.3.3</a>, <a href="#rfc.xref.header.location.3">6.5</a>, <a href="#rfc.iref.l.1"><b>8.5</b></a>, <a href="#rfc.xref.header.location.4">9.3</a>, <a href="#rfc.xref.header.location.5">A</a></li>3573 <li>Location header field <a href="#rfc.xref.header.location.1">2.3.4</a>, <a href="#rfc.xref.header.location.2">3.3</a>, <a href="#rfc.xref.header.location.3">4.3.3</a>, <a href="#rfc.iref.l.1"><b>7.5</b></a>, <a href="#rfc.xref.header.location.4">8.3</a>, <a href="#rfc.xref.header.location.5">A</a></li> 3627 3574 </ul> 3628 3575 </li> 3629 3576 <li><a id="rfc.index.M" href="#rfc.index.M"><b>M</b></a><ul> 3630 <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.6</b></a>, <a href="#rfc.xref.header.max-forwards.4">9.3</a>, <a href="#rfc.xref.header.max-forwards.5">A</a></li>3577 <li>Max-Forwards header field <a href="#rfc.xref.header.max-forwards.1">2.3.1</a>, <a href="#rfc.xref.header.max-forwards.2">2.3.7</a>, <a href="#rfc.xref.header.max-forwards.3">3.2</a>, <a href="#rfc.iref.m.9"><b>7.6</b></a>, <a href="#rfc.xref.header.max-forwards.4">8.3</a>, <a href="#rfc.xref.header.max-forwards.5">A</a></li> 3631 3578 <li>Methods 3632 3579 <ul> 3633 <li>CONNECT <a href="#rfc. xref.CONNECT.1">2.1</a>, <a href="#rfc.iref.m.8"><b>6.9</b></a>, <a href="#rfc.xref.CONNECT.2">9.1</a>, <a href="#rfc.xref.CONNECT.3">A</a></li>3634 <li>DELETE <a href="#rfc. xref.DELETE.1">2.1</a>, <a href="#rfc.iref.m.6"><b>6.7</b></a>, <a href="#rfc.xref.DELETE.2">9.1</a></li>3635 <li>GET <a href="#rfc. xref.GET.1">2.1</a>, <a href="#rfc.iref.m.2"><b>6.3</b></a>, <a href="#rfc.xref.GET.2">9.1</a></li>3636 <li>HEAD <a href="#rfc. xref.HEAD.1">2.1</a>, <a href="#rfc.iref.m.3"><b>6.4</b></a>, <a href="#rfc.xref.HEAD.2">9.1</a></li>3637 <li>OPTIONS <a href="#rfc. xref.OPTIONS.1">2.1</a>, <a href="#rfc.iref.m.1"><b>6.2</b></a>, <a href="#rfc.xref.OPTIONS.2">8.6</a>, <a href="#rfc.xref.OPTIONS.3">9.1</a></li>3638 <li>POST <a href="#rfc. xref.POST.1">2.1</a>, <a href="#rfc.iref.m.4"><b>6.5</b></a>, <a href="#rfc.xref.POST.2">9.1</a>, <a href="#rfc.xref.POST.3">A</a></li>3639 <li>PUT <a href="#rfc. xref.PUT.1">2.1</a>, <a href="#rfc.iref.m.5"><b>6.6</b></a>, <a href="#rfc.xref.PUT.2">9.1</a>, <a href="#rfc.xref.PUT.3">A</a></li>3640 <li>TRACE <a href="#rfc. xref.TRACE.1">2.1</a>, <a href="#rfc.iref.m.7"><b>6.8</b></a>, <a href="#rfc.xref.TRACE.2">8.6</a>, <a href="#rfc.xref.TRACE.3">9.1</a>, <a href="#rfc.xref.TRACE.4">10.1</a></li>3580 <li>CONNECT <a href="#rfc.iref.m.8"><b>2.3.8</b></a>, <a href="#rfc.xref.CONNECT.1">8.1</a>, <a href="#rfc.xref.CONNECT.2">A</a></li> 3581 <li>DELETE <a href="#rfc.iref.m.6"><b>2.3.6</b></a>, <a href="#rfc.xref.DELETE.1">8.1</a></li> 3582 <li>GET <a href="#rfc.iref.m.2"><b>2.3.2</b></a>, <a href="#rfc.xref.GET.1">8.1</a></li> 3583 <li>HEAD <a href="#rfc.iref.m.3"><b>2.3.3</b></a>, <a href="#rfc.xref.HEAD.1">8.1</a></li> 3584 <li>OPTIONS <a href="#rfc.iref.m.1"><b>2.3.1</b></a>, <a href="#rfc.xref.OPTIONS.1">7.6</a>, <a href="#rfc.xref.OPTIONS.2">8.1</a></li> 3585 <li>POST <a href="#rfc.iref.m.4"><b>2.3.4</b></a>, <a href="#rfc.xref.POST.1">8.1</a>, <a href="#rfc.xref.POST.2">A</a></li> 3586 <li>PUT <a href="#rfc.iref.m.5"><b>2.3.5</b></a>, <a href="#rfc.xref.PUT.1">8.1</a>, <a href="#rfc.xref.PUT.2">A</a></li> 3587 <li>TRACE <a href="#rfc.iref.m.7"><b>2.3.7</b></a>, <a href="#rfc.xref.TRACE.1">7.6</a>, <a href="#rfc.xref.TRACE.2">8.1</a>, <a href="#rfc.xref.TRACE.3">9.1</a></li> 3641 3588 </ul> 3642 3589 </li> … … 3644 3591 </li> 3645 3592 <li><a id="rfc.index.O" href="#rfc.index.O"><b>O</b></a><ul> 3646 <li>OPTIONS method <a href="#rfc. xref.OPTIONS.1">2.1</a>, <a href="#rfc.iref.o.1"><b>6.2</b></a>, <a href="#rfc.xref.OPTIONS.2">8.6</a>, <a href="#rfc.xref.OPTIONS.3">9.1</a></li>3593 <li>OPTIONS method <a href="#rfc.iref.o.1"><b>2.3.1</b></a>, <a href="#rfc.xref.OPTIONS.1">7.6</a>, <a href="#rfc.xref.OPTIONS.2">8.1</a></li> 3647 3594 </ul> 3648 3595 </li> 3649 3596 <li><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul> 3650 <li><em>Part1</em> <a href="#rfc.xref.Part1.1">1</a>, <a href="#rfc.xref.Part1.2">1.1</a>, <a href="#rfc.xref.Part1.3">1.2</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.1</a>, <a href="#rfc.xref.Part1.10">1.2.1</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">4.3.1.1</a>, <a href="#rfc.xref.Part1.27">4.3.1.2</a>, <a href="#rfc.xref.Part1.28">4.3.2.4</a>, <a href="#rfc.xref.Part1.29">4.3.2.6</a>, <a href="#rfc.xref.Part1.30">4.3.4.15</a>, <a href="#rfc.xref.Part1.31">4.3.5.6</a>, <a href="#rfc.xref.Part1.32">5</a>, <a href="#rfc.xref.Part1.33">5.1</a>, <a href="#rfc.xref.Part1.34">6.2</a>, <a href="#rfc.xref.Part1.35">6.8</a>, <a href="#rfc.xref.Part1.36">6.8</a>, <a href="#rfc.xref.Part1.37">6.9</a>, <a href="#rfc.xref.Part1.38">8.3</a>, <a href="#rfc.xref.Part1.39">8.9</a>, <a href="#rfc.xref.Part1.40">8.9</a>, <a href="#rfc.xref.Part1.41">8.10</a>, <a href="#rfc.xref.Part1.42">11</a>, <a href="#Part1"><b>12.1</b></a>, <a href="#rfc.xref.Part1.43">A</a><ul>3597 <li><em>Part1</em> <a href="#rfc.xref.Part1.1">1</a>, <a href="#rfc.xref.Part1.2">1.1</a>, <a href="#rfc.xref.Part1.3">1.2</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.1</a>, <a href="#rfc.xref.Part1.10">1.2.1</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">2.3.1</a>, <a href="#rfc.xref.Part1.18">2.3.7</a>, <a href="#rfc.xref.Part1.19">2.3.7</a>, <a href="#rfc.xref.Part1.20">2.3.8</a>, <a href="#rfc.xref.Part1.21">3</a>, <a href="#rfc.xref.Part1.22">3.1</a>, <a href="#rfc.xref.Part1.23">3.1</a>, <a href="#rfc.xref.Part1.24">3.1</a>, <a href="#rfc.xref.Part1.25">3.1</a>, <a href="#rfc.xref.Part1.26">3.1</a>, <a href="#rfc.xref.Part1.27">3.2</a>, <a href="#rfc.xref.Part1.28">3.2</a>, <a href="#rfc.xref.Part1.29">3.3</a>, <a href="#rfc.xref.Part1.30">4.3.1.1</a>, <a href="#rfc.xref.Part1.31">4.3.1.2</a>, <a href="#rfc.xref.Part1.32">4.3.2.4</a>, <a href="#rfc.xref.Part1.33">4.3.2.6</a>, <a href="#rfc.xref.Part1.34">4.3.4.15</a>, <a href="#rfc.xref.Part1.35">4.3.5.6</a>, <a href="#rfc.xref.Part1.36">5</a>, <a href="#rfc.xref.Part1.37">5.1</a>, <a href="#rfc.xref.Part1.38">7.3</a>, <a href="#rfc.xref.Part1.39">7.9</a>, <a href="#rfc.xref.Part1.40">7.9</a>, <a href="#rfc.xref.Part1.41">7.10</a>, <a href="#rfc.xref.Part1.42">10</a>, <a href="#Part1"><b>11.1</b></a>, <a href="#rfc.xref.Part1.43">A</a><ul> 3651 3598 <li><em>Section 1.2</em> <a href="#rfc.xref.Part1.3">1.2</a></li> 3652 3599 <li><em>Section 2</em> <a href="#rfc.xref.Part1.2">1.1</a></li> 3653 <li><em>Section 2.3</em> <a href="#rfc.xref.Part1. 28">4.3.2.4</a></li>3654 <li><em>Section 2.6</em> <a href="#rfc.xref.Part1.3 1">4.3.5.6</a></li>3600 <li><em>Section 2.3</em> <a href="#rfc.xref.Part1.32">4.3.2.4</a></li> 3601 <li><em>Section 2.6</em> <a href="#rfc.xref.Part1.35">4.3.5.6</a></li> 3655 3602 <li><em>Section 2.7</em> <a href="#rfc.xref.Part1.11">1.2.2</a>, <a href="#rfc.xref.Part1.13">1.2.2</a>, <a href="#rfc.xref.Part1.14">1.2.2</a></li> 3656 3603 <li><em>Section 3.2.1</em> <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></li> 3657 <li><em>Section 3.2</em> <a href="#rfc.xref.Part1. 17">3</a>, <a href="#rfc.xref.Part1.20">3.1</a>, <a href="#rfc.xref.Part1.39">8.9</a>, <a href="#rfc.xref.Part1.41">8.10</a></li>3658 <li><em>Section 3.2.4</em> <a href="#rfc.xref.Part1.8">1.2.1</a>, <a href="#rfc.xref.Part1.9">1.2.1</a>, <a href="#rfc.xref.Part1.10">1.2.1</a>, <a href="#rfc.xref.Part1.12">1.2.2</a>, <a href="#rfc.xref.Part1. 19">3.1</a></li>3659 <li><em>Section 3.2.5</em> <a href="#rfc.xref.Part1. 18">3.1</a></li>3660 <li><em>Section 3.3</em> <a href="#rfc.xref.Part1.16">2.2.1</a>, <a href="#rfc.xref.Part1. 29">4.3.2.6</a>, <a href="#rfc.xref.Part1.32">5</a></li>3661 <li><em>Section 4.1</em> <a href="#rfc.xref.Part1.2 2">3.1</a></li>3662 <li><em>Section 4.3</em> <a href="#rfc.xref.Part1.2 4">3.2</a></li>3663 <li><em>Section 5.3</em> <a href="#rfc.xref.Part1. 34">6.2</a>, <a href="#rfc.xref.Part1.37">6.9</a></li>3664 <li><em>Section 5.4</em> <a href="#rfc.xref.Part1.2 3">3.2</a></li>3665 <li><em>Section 5.5</em> <a href="#rfc.xref.Part1.15">2</a>, <a href="#rfc.xref.Part1.2 5">3.3</a>, <a href="#rfc.xref.Part1.33">5.1</a></li>3666 <li><em>Section 6.1</em> <a href="#rfc.xref.Part1.2 1">3.1</a></li>3667 <li><em>Section 6.2</em> <a href="#rfc.xref.Part1. 35">6.8</a>, <a href="#rfc.xref.Part1.40">8.9</a>, <a href="#rfc.xref.Part1.43">A</a></li>3668 <li><em>Section 6.4.3</em> <a href="#rfc.xref.Part1. 26">4.3.1.1</a>, <a href="#rfc.xref.Part1.38">8.3</a></li>3669 <li><em>Section 6.5</em> <a href="#rfc.xref.Part1. 27">4.3.1.2</a>, <a href="#rfc.xref.Part1.30">4.3.4.15</a></li>3670 <li><em>Section 7.3.1</em> <a href="#rfc.xref.Part1. 36">6.8</a></li>3671 <li><em>Section 9</em> <a href="#rfc.xref.Part1.42">1 1</a></li>3604 <li><em>Section 3.2</em> <a href="#rfc.xref.Part1.21">3</a>, <a href="#rfc.xref.Part1.24">3.1</a>, <a href="#rfc.xref.Part1.39">7.9</a>, <a href="#rfc.xref.Part1.41">7.10</a></li> 3605 <li><em>Section 3.2.4</em> <a href="#rfc.xref.Part1.8">1.2.1</a>, <a href="#rfc.xref.Part1.9">1.2.1</a>, <a href="#rfc.xref.Part1.10">1.2.1</a>, <a href="#rfc.xref.Part1.12">1.2.2</a>, <a href="#rfc.xref.Part1.23">3.1</a></li> 3606 <li><em>Section 3.2.5</em> <a href="#rfc.xref.Part1.22">3.1</a></li> 3607 <li><em>Section 3.3</em> <a href="#rfc.xref.Part1.16">2.2.1</a>, <a href="#rfc.xref.Part1.33">4.3.2.6</a>, <a href="#rfc.xref.Part1.36">5</a></li> 3608 <li><em>Section 4.1</em> <a href="#rfc.xref.Part1.26">3.1</a></li> 3609 <li><em>Section 4.3</em> <a href="#rfc.xref.Part1.28">3.2</a></li> 3610 <li><em>Section 5.3</em> <a href="#rfc.xref.Part1.17">2.3.1</a>, <a href="#rfc.xref.Part1.20">2.3.8</a></li> 3611 <li><em>Section 5.4</em> <a href="#rfc.xref.Part1.27">3.2</a></li> 3612 <li><em>Section 5.5</em> <a href="#rfc.xref.Part1.15">2</a>, <a href="#rfc.xref.Part1.29">3.3</a>, <a href="#rfc.xref.Part1.37">5.1</a></li> 3613 <li><em>Section 6.1</em> <a href="#rfc.xref.Part1.25">3.1</a></li> 3614 <li><em>Section 6.2</em> <a href="#rfc.xref.Part1.18">2.3.7</a>, <a href="#rfc.xref.Part1.40">7.9</a>, <a href="#rfc.xref.Part1.43">A</a></li> 3615 <li><em>Section 6.4.3</em> <a href="#rfc.xref.Part1.30">4.3.1.1</a>, <a href="#rfc.xref.Part1.38">7.3</a></li> 3616 <li><em>Section 6.5</em> <a href="#rfc.xref.Part1.31">4.3.1.2</a>, <a href="#rfc.xref.Part1.34">4.3.4.15</a></li> 3617 <li><em>Section 7.3.1</em> <a href="#rfc.xref.Part1.19">2.3.7</a></li> 3618 <li><em>Section 9</em> <a href="#rfc.xref.Part1.42">10</a></li> 3672 3619 </ul> 3673 3620 </li> 3674 <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.2</a>, <a href="#rfc.xref.Part3.4">3.2</a>, <a href="#rfc.xref.Part3.5">3.2</a>, <a href="#rfc.xref.Part3.6">3.2</a>, <a href="#rfc.xref.Part3.7">4.3</a>, <a href="#rfc.xref.Part3.8">4.3.3</a>, <a href="#rfc.xref.Part3.9">4.3.3.1</a>, <a href="#rfc.xref.Part3.10">4.3.4.6</a>, <a href="#rfc.xref.Part3.11">5</a>, <a href="#rfc.xref.Part3.12">6.5</a>, <a href="#rfc.xref.Part3.13">8.5</a>, <a href="#Part3"><b>12.1</b></a><ul>3675 <li><em>Section 2.3</em> <a href="#rfc.xref.Part3. 2">3.1</a></li>3676 <li><em>Section 5</em> <a href="#rfc.xref.Part3. 9">4.3.3.1</a></li>3677 <li><em>Section 5.2</em> <a href="#rfc.xref.Part3. 8">4.3.3</a></li>3678 <li><em>Section 6.1</em> <a href="#rfc.xref.Part3. 3">3.2</a></li>3679 <li><em>Section 6</em> <a href="#rfc.xref.Part3.1 0">4.3.4.6</a></li>3680 <li><em>Section 6.2</em> <a href="#rfc.xref.Part3. 4">3.2</a></li>3681 <li><em>Section 6.3</em> <a href="#rfc.xref.Part3. 5">3.2</a></li>3682 <li><em>Section 6.4</em> <a href="#rfc.xref.Part3. 6">3.2</a></li>3683 <li><em>Section 6.7</em> <a href="#rfc.xref.Part3.1 2">6.5</a>, <a href="#rfc.xref.Part3.13">8.5</a></li>3684 <li><em>Section 6.8</em> <a href="#rfc.xref.Part3. 1">3.1</a>, <a href="#rfc.xref.Part3.7">4.3</a></li>3621 <li><em>Part3</em> <a href="#rfc.xref.Part3.1">2.3.4</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.2</a>, <a href="#rfc.xref.Part3.5">3.2</a>, <a href="#rfc.xref.Part3.6">3.2</a>, <a href="#rfc.xref.Part3.7">3.2</a>, <a href="#rfc.xref.Part3.8">4.3</a>, <a href="#rfc.xref.Part3.9">4.3.3</a>, <a href="#rfc.xref.Part3.10">4.3.3.1</a>, <a href="#rfc.xref.Part3.11">4.3.4.6</a>, <a href="#rfc.xref.Part3.12">5</a>, <a href="#rfc.xref.Part3.13">7.5</a>, <a href="#Part3"><b>11.1</b></a><ul> 3622 <li><em>Section 2.3</em> <a href="#rfc.xref.Part3.3">3.1</a></li> 3623 <li><em>Section 5</em> <a href="#rfc.xref.Part3.10">4.3.3.1</a></li> 3624 <li><em>Section 5.2</em> <a href="#rfc.xref.Part3.9">4.3.3</a></li> 3625 <li><em>Section 6.1</em> <a href="#rfc.xref.Part3.4">3.2</a></li> 3626 <li><em>Section 6</em> <a href="#rfc.xref.Part3.11">4.3.4.6</a></li> 3627 <li><em>Section 6.2</em> <a href="#rfc.xref.Part3.5">3.2</a></li> 3628 <li><em>Section 6.3</em> <a href="#rfc.xref.Part3.6">3.2</a></li> 3629 <li><em>Section 6.4</em> <a href="#rfc.xref.Part3.7">3.2</a></li> 3630 <li><em>Section 6.7</em> <a href="#rfc.xref.Part3.1">2.3.4</a>, <a href="#rfc.xref.Part3.13">7.5</a></li> 3631 <li><em>Section 6.8</em> <a href="#rfc.xref.Part3.2">3.1</a>, <a href="#rfc.xref.Part3.8">4.3</a></li> 3685 3632 </ul> 3686 3633 </li> 3687 <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">4.3.2.2</a>, <a href="#rfc.xref.Part4.10">4.3.3</a>, <a href="#Part4"><b>1 2.1</b></a>, <a href="#rfc.xref.Part4.11">C.2</a><ul>3634 <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">4.3.2.2</a>, <a href="#rfc.xref.Part4.10">4.3.3</a>, <a href="#Part4"><b>11.1</b></a>, <a href="#rfc.xref.Part4.11">C.2</a><ul> 3688 3635 <li><em>Section 2.3</em> <a href="#rfc.xref.Part4.5">3.3</a>, <a href="#rfc.xref.Part4.9">4.3.2.2</a></li> 3689 3636 <li><em>Section 3.1</em> <a href="#rfc.xref.Part4.1">3.2</a></li> … … 3696 3643 </ul> 3697 3644 </li> 3698 <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="#Part5"><b>12.1</b></a><ul>3699 <li><em>Section 3</em> <a href="#rfc.xref.Part5. 4">4.1</a></li>3700 <li><em>Section 3.1</em> <a href="#rfc.xref.Part5. 5">4.1</a></li>3701 <li><em>Section 3.2</em> <a href="#rfc.xref.Part5. 6">4.1</a></li>3702 <li><em>Section 5.1</em> <a href="#rfc.xref.Part5. 3">3.3</a></li>3703 <li><em>Section 5.3</em> <a href="#rfc.xref.Part5. 1">3.2</a></li>3704 <li><em>Section 5.4</em> <a href="#rfc.xref.Part5. 2">3.2</a>, <a href="#rfc.xref.Part5.7">6.3</a></li>3645 <li><em>Part5</em> <a href="#rfc.xref.Part5.1">2.3.2</a>, <a href="#rfc.xref.Part5.2">3.2</a>, <a href="#rfc.xref.Part5.3">3.2</a>, <a href="#rfc.xref.Part5.4">3.3</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">4.1</a>, <a href="#Part5"><b>11.1</b></a><ul> 3646 <li><em>Section 3</em> <a href="#rfc.xref.Part5.5">4.1</a></li> 3647 <li><em>Section 3.1</em> <a href="#rfc.xref.Part5.6">4.1</a></li> 3648 <li><em>Section 3.2</em> <a href="#rfc.xref.Part5.7">4.1</a></li> 3649 <li><em>Section 5.1</em> <a href="#rfc.xref.Part5.4">3.3</a></li> 3650 <li><em>Section 5.3</em> <a href="#rfc.xref.Part5.2">3.2</a></li> 3651 <li><em>Section 5.4</em> <a href="#rfc.xref.Part5.1">2.3.2</a>, <a href="#rfc.xref.Part5.3">3.2</a></li> 3705 3652 </ul> 3706 3653 </li> 3707 <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">4.3.2.1</a>, <a href="#rfc.xref.Part6.7">4.3.2.4</a>, <a href="#rfc.xref.Part6.8">4.3.2.4</a>, <a href="#rfc.xref.Part6.9">4.3.2.4</a>, <a href="#rfc.xref.Part6.10">4.3.3.1</a>, <a href="#rfc.xref.Part6.11">4.3.3.2</a>, <a href="#rfc.xref.Part6.12">4.3.4.9</a>, <a href="#rfc.xref.Part6.13">6.3</a>, <a href="#rfc.xref.Part6.14">6.4</a>, <a href="#rfc.xref.Part6.15">6.5</a>, <a href="#rfc.xref.Part6.16">6.6</a>, <a href="#rfc.xref.Part6.17">6.7</a>, <a href="#Part6"><b>12.1</b></a><ul>3708 <li><em>Section 2.3.1 .1</em> <a href="#rfc.xref.Part6.6">4.3.2.1</a>, <a href="#rfc.xref.Part6.9">4.3.2.4</a>, <a href="#rfc.xref.Part6.10">4.3.3.1</a>, <a href="#rfc.xref.Part6.11">4.3.3.2</a>, <a href="#rfc.xref.Part6.12">4.3.4.9</a></li>3709 <li><em>Section 2.3.1 </em> <a href="#rfc.xref.Part6.15">6.5</a></li>3710 <li><em>Section 2.5</em> <a href="#rfc.xref.Part6. 14">6.4</a></li>3711 <li><em>Section 2.6</em> <a href="#rfc.xref.Part6. 16">6.6</a>, <a href="#rfc.xref.Part6.17">6.7</a></li>3712 <li><em>Section 3.1</em> <a href="#rfc.xref.Part6. 3">3.3</a></li>3713 <li><em>Section 3.2</em> <a href="#rfc.xref.Part6. 7">4.3.2.4</a></li>3714 <li><em>Section 3.5</em> <a href="#rfc.xref.Part6. 4">3.3</a></li>3715 <li><em>Section 3.6</em> <a href="#rfc.xref.Part6. 8">4.3.2.4</a></li>3654 <li><em>Part6</em> <a href="#rfc.xref.Part6.1">2.2.1</a>, <a href="#rfc.xref.Part6.2">2.3.2</a>, <a href="#rfc.xref.Part6.3">2.3.3</a>, <a href="#rfc.xref.Part6.4">2.3.4</a>, <a href="#rfc.xref.Part6.5">2.3.5</a>, <a href="#rfc.xref.Part6.6">2.3.6</a>, <a href="#rfc.xref.Part6.7">3.1</a>, <a href="#rfc.xref.Part6.8">3.3</a>, <a href="#rfc.xref.Part6.9">3.3</a>, <a href="#rfc.xref.Part6.10">4.2.1</a>, <a href="#rfc.xref.Part6.11">4.3.2.1</a>, <a href="#rfc.xref.Part6.12">4.3.2.4</a>, <a href="#rfc.xref.Part6.13">4.3.2.4</a>, <a href="#rfc.xref.Part6.14">4.3.2.4</a>, <a href="#rfc.xref.Part6.15">4.3.3.1</a>, <a href="#rfc.xref.Part6.16">4.3.3.2</a>, <a href="#rfc.xref.Part6.17">4.3.4.9</a>, <a href="#Part6"><b>11.1</b></a><ul> 3655 <li><em>Section 2.3.1</em> <a href="#rfc.xref.Part6.4">2.3.4</a></li> 3656 <li><em>Section 2.3.1.1</em> <a href="#rfc.xref.Part6.11">4.3.2.1</a>, <a href="#rfc.xref.Part6.14">4.3.2.4</a>, <a href="#rfc.xref.Part6.15">4.3.3.1</a>, <a href="#rfc.xref.Part6.16">4.3.3.2</a>, <a href="#rfc.xref.Part6.17">4.3.4.9</a></li> 3657 <li><em>Section 2.5</em> <a href="#rfc.xref.Part6.3">2.3.3</a></li> 3658 <li><em>Section 2.6</em> <a href="#rfc.xref.Part6.5">2.3.5</a>, <a href="#rfc.xref.Part6.6">2.3.6</a></li> 3659 <li><em>Section 3.1</em> <a href="#rfc.xref.Part6.8">3.3</a></li> 3660 <li><em>Section 3.2</em> <a href="#rfc.xref.Part6.12">4.3.2.4</a></li> 3661 <li><em>Section 3.5</em> <a href="#rfc.xref.Part6.9">3.3</a></li> 3662 <li><em>Section 3.6</em> <a href="#rfc.xref.Part6.13">4.3.2.4</a></li> 3716 3663 </ul> 3717 3664 </li> 3718 <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="#Part7"><b>1 2.1</b></a><ul>3665 <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="#Part7"><b>11.1</b></a><ul> 3719 3666 <li><em>Section 3</em> <a href="#rfc.xref.Part7.5">4.1</a></li> 3720 3667 <li><em>Section 3.1</em> <a href="#rfc.xref.Part7.6">4.1</a></li> … … 3726 3673 </ul> 3727 3674 </li> 3728 <li>POST method <a href="#rfc. xref.POST.1">2.1</a>, <a href="#rfc.iref.p.1"><b>6.5</b></a>, <a href="#rfc.xref.POST.2">9.1</a>, <a href="#rfc.xref.POST.3">A</a></li>3729 <li>PUT method <a href="#rfc. xref.PUT.1">2.1</a>, <a href="#rfc.iref.p.2"><b>6.6</b></a>, <a href="#rfc.xref.PUT.2">9.1</a>, <a href="#rfc.xref.PUT.3">A</a></li>3675 <li>POST method <a href="#rfc.iref.p.1"><b>2.3.4</b></a>, <a href="#rfc.xref.POST.1">8.1</a>, <a href="#rfc.xref.POST.2">A</a></li> 3676 <li>PUT method <a href="#rfc.iref.p.2"><b>2.3.5</b></a>, <a href="#rfc.xref.PUT.1">8.1</a>, <a href="#rfc.xref.PUT.2">A</a></li> 3730 3677 </ul> 3731 3678 </li> 3732 3679 <li><a id="rfc.index.R" href="#rfc.index.R"><b>R</b></a><ul> 3733 <li>Referer header field <a href="#rfc.xref.header.referer.1">3.2</a>, <a href="#rfc.iref.r.1"><b> 8.7</b></a>, <a href="#rfc.xref.header.referer.2">9.3</a>, <a href="#rfc.xref.header.referer.3">A</a></li>3734 <li>Retry-After header field <a href="#rfc.xref.header.retry-after.1">3.3</a>, <a href="#rfc.xref.header.retry-after.2">4.3.5.4</a>, <a href="#rfc.iref.r.2"><b> 8.8</b></a>, <a href="#rfc.xref.header.retry-after.3">9.3</a></li>3735 <li><em>RFC1123</em> <a href="#rfc.xref.RFC1123.1"> 7.1</a>, <a href="#rfc.xref.RFC1123.2">7.1</a>, <a href="#RFC1123"><b>12.2</b></a><ul>3736 <li><em>Section 5.2.14</em> <a href="#rfc.xref.RFC1123.2"> 7.1</a></li>3680 <li>Referer header field <a href="#rfc.xref.header.referer.1">3.2</a>, <a href="#rfc.iref.r.1"><b>7.7</b></a>, <a href="#rfc.xref.header.referer.2">8.3</a>, <a href="#rfc.xref.header.referer.3">A</a></li> 3681 <li>Retry-After header field <a href="#rfc.xref.header.retry-after.1">3.3</a>, <a href="#rfc.xref.header.retry-after.2">4.3.5.4</a>, <a href="#rfc.iref.r.2"><b>7.8</b></a>, <a href="#rfc.xref.header.retry-after.3">8.3</a></li> 3682 <li><em>RFC1123</em> <a href="#rfc.xref.RFC1123.1">6.1</a>, <a href="#rfc.xref.RFC1123.2">6.1</a>, <a href="#RFC1123"><b>11.2</b></a><ul> 3683 <li><em>Section 5.2.14</em> <a href="#rfc.xref.RFC1123.2">6.1</a></li> 3737 3684 </ul> 3738 3685 </li> 3739 <li><em>RFC1945</em> <a href="#rfc.xref.RFC1945.1">4.3.3</a>, <a href="#RFC1945"><b>1 2.2</b></a><ul>3686 <li><em>RFC1945</em> <a href="#rfc.xref.RFC1945.1">4.3.3</a>, <a href="#RFC1945"><b>11.2</b></a><ul> 3740 3687 <li><em>Section 9.3</em> <a href="#rfc.xref.RFC1945.1">4.3.3</a></li> 3741 3688 </ul> 3742 3689 </li> 3743 <li><em>RFC2068</em> <a href="#rfc.xref.RFC2068.1">4.3.3</a>, <a href="#rfc.xref.RFC2068.2">4.3.3</a>, <a href="#RFC2068"><b>1 2.2</b></a><ul>3690 <li><em>RFC2068</em> <a href="#rfc.xref.RFC2068.1">4.3.3</a>, <a href="#rfc.xref.RFC2068.2">4.3.3</a>, <a href="#RFC2068"><b>11.2</b></a><ul> 3744 3691 <li><em>Section 10.3</em> <a href="#rfc.xref.RFC2068.2">4.3.3</a></li> 3745 3692 <li><em>Section 10.3.4</em> <a href="#rfc.xref.RFC2068.1">4.3.3</a></li> 3746 3693 </ul> 3747 3694 </li> 3748 <li><em>RFC2119</em> <a href="#rfc.xref.RFC2119.1">1.1</a>, <a href="#RFC2119"><b>1 2.1</b></a></li>3749 <li><em>RFC2616</em> <a href="#rfc.xref.RFC2616.1">1</a>, <a href="#rfc.xref.RFC2616.2">4.3.3</a>, <a href="#RFC2616"><b>1 2.2</b></a>, <a href="#rfc.xref.RFC2616.3">C.1</a><ul>3695 <li><em>RFC2119</em> <a href="#rfc.xref.RFC2119.1">1.1</a>, <a href="#RFC2119"><b>11.1</b></a></li> 3696 <li><em>RFC2616</em> <a href="#rfc.xref.RFC2616.1">1</a>, <a href="#rfc.xref.RFC2616.2">4.3.3</a>, <a href="#RFC2616"><b>11.2</b></a>, <a href="#rfc.xref.RFC2616.3">C.1</a><ul> 3750 3697 <li><em>Section 10.3.8</em> <a href="#rfc.xref.RFC2616.2">4.3.3</a></li> 3751 3698 </ul> 3752 3699 </li> 3753 <li><em>RFC2817</em> <a href="#rfc.xref.RFC2817.1"> 9.2</a>, <a href="#RFC2817"><b>12.2</b></a>, <a href="#rfc.xref.RFC2817.2">A</a>, <a href="#rfc.xref.RFC2817.3">A</a>, <a href="#rfc.xref.RFC2817.4">A</a><ul>3754 <li><em>Section 7.1</em> <a href="#rfc.xref.RFC2817.1"> 9.2</a>, <a href="#rfc.xref.RFC2817.2">A</a></li>3700 <li><em>RFC2817</em> <a href="#rfc.xref.RFC2817.1">8.2</a>, <a href="#RFC2817"><b>11.2</b></a>, <a href="#rfc.xref.RFC2817.2">A</a>, <a href="#rfc.xref.RFC2817.3">A</a>, <a href="#rfc.xref.RFC2817.4">A</a><ul> 3701 <li><em>Section 7.1</em> <a href="#rfc.xref.RFC2817.1">8.2</a>, <a href="#rfc.xref.RFC2817.3">A</a></li> 3755 3702 </ul> 3756 3703 </li> 3757 <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>3704 <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">8.3</a>, <a href="#RFC3864"><b>11.2</b></a><ul> 3758 3705 <li><em>Section 4.1</em> <a href="#rfc.xref.RFC3864.2">3.1</a></li> 3759 3706 </ul> 3760 3707 </li> 3761 <li><em>RFC3986</em> <a href="#rfc.xref.RFC3986.1"> 8.5</a>, <a href="#rfc.xref.RFC3986.2">8.5</a>, <a href="#RFC3986"><b>12.1</b></a><ul>3762 <li><em>Section 4.2</em> <a href="#rfc.xref.RFC3986.1"> 8.5</a></li>3763 <li><em>Section 5</em> <a href="#rfc.xref.RFC3986.2"> 8.5</a></li>3708 <li><em>RFC3986</em> <a href="#rfc.xref.RFC3986.1">7.5</a>, <a href="#rfc.xref.RFC3986.2">7.5</a>, <a href="#RFC3986"><b>11.1</b></a><ul> 3709 <li><em>Section 4.2</em> <a href="#rfc.xref.RFC3986.1">7.5</a></li> 3710 <li><em>Section 5</em> <a href="#rfc.xref.RFC3986.2">7.5</a></li> 3764 3711 </ul> 3765 3712 </li> 3766 <li><em>RFC5226</em> <a href="#rfc.xref.RFC5226.1">2.2</a>, <a href="#rfc.xref.RFC5226.2">4.2</a>, <a href="#RFC5226"><b>1 2.2</b></a><ul>3713 <li><em>RFC5226</em> <a href="#rfc.xref.RFC5226.1">2.2</a>, <a href="#rfc.xref.RFC5226.2">4.2</a>, <a href="#RFC5226"><b>11.2</b></a><ul> 3767 3714 <li><em>Section 4.1</em> <a href="#rfc.xref.RFC5226.1">2.2</a>, <a href="#rfc.xref.RFC5226.2">4.2</a></li> 3768 3715 </ul> 3769 3716 </li> 3770 <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>1 2.1</b></a><ul>3717 <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>11.1</b></a><ul> 3771 3718 <li><em>Appendix B.1</em> <a href="#rfc.xref.RFC5234.2">1.2</a></li> 3772 3719 </ul> 3773 3720 </li> 3774 <li><em>RFC5322</em> <a href="#rfc.xref.RFC5322.1"> 7.1</a>, <a href="#rfc.xref.RFC5322.2">8.2</a>, <a href="#rfc.xref.RFC5322.3">8.4</a>, <a href="#rfc.xref.RFC5322.4">8.4</a>, <a href="#RFC5322"><b>12.2</b></a><ul>3775 <li><em>Section 3.3</em> <a href="#rfc.xref.RFC5322.1"> 7.1</a></li>3776 <li><em>Section 3.4</em> <a href="#rfc.xref.RFC5322.3"> 8.4</a>, <a href="#rfc.xref.RFC5322.4">8.4</a></li>3777 <li><em>Section 3.6.1</em> <a href="#rfc.xref.RFC5322.2"> 8.2</a></li>3721 <li><em>RFC5322</em> <a href="#rfc.xref.RFC5322.1">6.1</a>, <a href="#rfc.xref.RFC5322.2">7.2</a>, <a href="#rfc.xref.RFC5322.3">7.4</a>, <a href="#rfc.xref.RFC5322.4">7.4</a>, <a href="#RFC5322"><b>11.2</b></a><ul> 3722 <li><em>Section 3.3</em> <a href="#rfc.xref.RFC5322.1">6.1</a></li> 3723 <li><em>Section 3.4</em> <a href="#rfc.xref.RFC5322.3">7.4</a>, <a href="#rfc.xref.RFC5322.4">7.4</a></li> 3724 <li><em>Section 3.6.1</em> <a href="#rfc.xref.RFC5322.2">7.2</a></li> 3778 3725 </ul> 3779 3726 </li> 3780 <li><em>RFC5789</em> <a href="#rfc.xref.RFC5789.1"> 6.6</a>, <a href="#RFC5789"><b>12.2</b></a></li>3781 <li><em>RFC5987</em> <a href="#rfc.xref.RFC5987.1">3.1</a>, <a href="#RFC5987"><b>1 2.2</b></a></li>3727 <li><em>RFC5789</em> <a href="#rfc.xref.RFC5789.1">2.3.5</a>, <a href="#RFC5789"><b>11.2</b></a></li> 3728 <li><em>RFC5987</em> <a href="#rfc.xref.RFC5987.1">3.1</a>, <a href="#RFC5987"><b>11.2</b></a></li> 3782 3729 </ul> 3783 3730 </li> 3784 3731 <li><a id="rfc.index.S" href="#rfc.index.S"><b>S</b></a><ul> 3785 <li>Safe Methods <a href="#rfc.iref.s. 37"><b>6.1.1</b></a></li>3786 <li>Server header field <a href="#rfc.xref.header.server.1">3.3</a>, <a href="#rfc.iref.s.38"><b> 8.9</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>3732 <li>Safe Methods <a href="#rfc.iref.s.1"><b>2.1.1</b></a></li> 3733 <li>Server header field <a href="#rfc.xref.header.server.1">3.3</a>, <a href="#rfc.iref.s.38"><b>7.9</b></a>, <a href="#rfc.xref.header.server.2">8.3</a>, <a href="#rfc.xref.header.server.3">9.1</a>, <a href="#rfc.xref.header.server.4">A</a></li> 3787 3734 <li>Status Codes 3788 3735 <ul> 3789 <li>100 Continue <a href="#rfc.xref.status.100.1">4.1</a>, <a href="#rfc.iref.s. 1"><b>4.3.1.1</b></a>, <a href="#rfc.xref.status.100.2">9.2</a></li>3790 <li>101 Switching Protocols <a href="#rfc.xref.status.101.1">4.1</a>, <a href="#rfc.iref.s. 2"><b>4.3.1.2</b></a>, <a href="#rfc.xref.status.101.2">9.2</a></li>3791 <li>200 OK <a href="#rfc.xref.status.200.1">4.1</a>, <a href="#rfc.iref.s. 3"><b>4.3.2.1</b></a>, <a href="#rfc.xref.status.200.2">9.2</a></li>3792 <li>201 Created <a href="#rfc.xref.status.201.1">4.1</a>, <a href="#rfc.iref.s. 4"><b>4.3.2.2</b></a>, <a href="#rfc.xref.status.201.2">9.2</a></li>3793 <li>202 Accepted <a href="#rfc.xref.status.202.1">4.1</a>, <a href="#rfc.iref.s. 5"><b>4.3.2.3</b></a>, <a href="#rfc.xref.status.202.2">9.2</a></li>3794 <li>203 Non-Authoritative Information <a href="#rfc.xref.status.203.1">4.1</a>, <a href="#rfc.iref.s. 6"><b>4.3.2.4</b></a>, <a href="#rfc.xref.status.203.2">9.2</a>, <a href="#rfc.xref.status.203.3">A</a></li>3795 <li>204 No Content <a href="#rfc.xref.status.204.1">4.1</a>, <a href="#rfc.iref.s. 7"><b>4.3.2.5</b></a>, <a href="#rfc.xref.status.204.2">9.2</a></li>3796 <li>205 Reset Content <a href="#rfc.xref.status.205.1">4.1</a>, <a href="#rfc.iref.s. 8"><b>4.3.2.6</b></a>, <a href="#rfc.xref.status.205.2">9.2</a></li>3797 <li>300 Multiple Choices <a href="#rfc.xref.status.300.1">4.1</a>, <a href="#rfc.iref.s. 9"><b>4.3.3.1</b></a>, <a href="#rfc.xref.status.300.2">9.2</a></li>3798 <li>301 Moved Permanently <a href="#rfc.xref.status.301.1">4.1</a>, <a href="#rfc.iref.s.1 0"><b>4.3.3.2</b></a>, <a href="#rfc.xref.status.301.2">9.2</a>, <a href="#rfc.xref.status.301.3">A</a></li>3799 <li>302 Found <a href="#rfc.xref.status.302.1">4.1</a>, <a href="#rfc.iref.s.1 1"><b>4.3.3.3</b></a>, <a href="#rfc.xref.status.302.2">9.2</a>, <a href="#rfc.xref.status.302.3">A</a></li>3800 <li>303 See Other <a href="#rfc.xref.status.303.1">4.1</a>, <a href="#rfc.iref.s.1 2"><b>4.3.3.4</b></a>, <a href="#rfc.xref.status.303.2">9.2</a></li>3801 <li>305 Use Proxy <a href="#rfc.xref.status.305.1">4.1</a>, <a href="#rfc.iref.s.1 3"><b>4.3.3.5</b></a>, <a href="#rfc.xref.status.305.2">9.2</a>, <a href="#rfc.xref.status.305.3">A</a></li>3802 <li>306 (Unused) <a href="#rfc.iref.s.1 4"><b>4.3.3.6</b></a>, <a href="#rfc.xref.status.306.1">9.2</a></li>3803 <li>307 Temporary Redirect <a href="#rfc.xref.status.307.1">4.1</a>, <a href="#rfc.iref.s.1 5"><b>4.3.3.7</b></a>, <a href="#rfc.xref.status.307.2">9.2</a>, <a href="#rfc.xref.status.307.3">A</a></li>3804 <li>400 Bad Request <a href="#rfc.xref.status.400.1">4.1</a>, <a href="#rfc.iref.s.1 6"><b>4.3.4.1</b></a>, <a href="#rfc.xref.status.400.2">9.2</a></li>3805 <li>402 Payment Required <a href="#rfc.xref.status.402.1">4.1</a>, <a href="#rfc.iref.s.1 7"><b>4.3.4.2</b></a>, <a href="#rfc.xref.status.402.2">9.2</a></li>3806 <li>403 Forbidden <a href="#rfc.xref.status.403.1">4.1</a>, <a href="#rfc.iref.s.1 8"><b>4.3.4.3</b></a>, <a href="#rfc.xref.status.403.2">9.2</a></li>3807 <li>404 Not Found <a href="#rfc.xref.status.404.1">4.1</a>, <a href="#rfc.iref.s. 19"><b>4.3.4.4</b></a>, <a href="#rfc.xref.status.404.2">9.2</a></li>3808 <li>405 Method Not Allowed <a href="#rfc.xref.status.405.1">4.1</a>, <a href="#rfc.iref.s.2 0"><b>4.3.4.5</b></a>, <a href="#rfc.xref.status.405.2">9.2</a></li>3809 <li>406 Not Acceptable <a href="#rfc.xref.status.406.1">4.1</a>, <a href="#rfc.iref.s.2 1"><b>4.3.4.6</b></a>, <a href="#rfc.xref.status.406.2">9.2</a></li>3810 <li>408 Request Timeout <a href="#rfc.xref.status.408.1">4.1</a>, <a href="#rfc.iref.s.2 2"><b>4.3.4.7</b></a>, <a href="#rfc.xref.status.408.2">9.2</a></li>3811 <li>409 Conflict <a href="#rfc.xref.status.409.1">4.1</a>, <a href="#rfc.iref.s.2 3"><b>4.3.4.8</b></a>, <a href="#rfc.xref.status.409.2">9.2</a></li>3812 <li>410 Gone <a href="#rfc.xref.status.410.1">4.1</a>, <a href="#rfc.iref.s.2 4"><b>4.3.4.9</b></a>, <a href="#rfc.xref.status.410.2">9.2</a></li>3813 <li>411 Length Required <a href="#rfc.xref.status.411.1">4.1</a>, <a href="#rfc.iref.s.2 5"><b>4.3.4.10</b></a>, <a href="#rfc.xref.status.411.2">9.2</a></li>3814 <li>413 Request Representation Too Large <a href="#rfc.xref.status.413.1">4.1</a>, <a href="#rfc.iref.s.2 6"><b>4.3.4.11</b></a>, <a href="#rfc.xref.status.413.2">9.2</a></li>3815 <li>414 URI Too Long <a href="#rfc.xref.status.414.1">4.1</a>, <a href="#rfc.iref.s.2 7"><b>4.3.4.12</b></a>, <a href="#rfc.xref.status.414.2">9.2</a></li>3816 <li>415 Unsupported Media Type <a href="#rfc.xref.status.415.1">4.1</a>, <a href="#rfc.iref.s.2 8"><b>4.3.4.13</b></a>, <a href="#rfc.xref.status.415.2">9.2</a></li>3817 <li>417 Expectation Failed <a href="#rfc.xref.status.417.1">4.1</a>, <a href="#rfc.iref.s. 29"><b>4.3.4.14</b></a>, <a href="#rfc.xref.status.417.2">9.2</a></li>3818 <li>426 Upgrade Required <a href="#rfc.xref.status.426.1">4.1</a>, <a href="#rfc.iref.s.3 0"><b>4.3.4.15</b></a>, <a href="#rfc.xref.status.426.2">9.2</a>, <a href="#rfc.xref.status.426.3">A</a></li>3819 <li>500 Internal Server Error <a href="#rfc.xref.status.500.1">4.1</a>, <a href="#rfc.iref.s.3 1"><b>4.3.5.1</b></a>, <a href="#rfc.xref.status.500.2">9.2</a></li>3820 <li>501 Not Implemented <a href="#rfc.xref.status.501.1">4.1</a>, <a href="#rfc.iref.s.3 2"><b>4.3.5.2</b></a>, <a href="#rfc.xref.status.501.2">9.2</a></li>3821 <li>502 Bad Gateway <a href="#rfc.xref.status.502.1">4.1</a>, <a href="#rfc.iref.s.3 3"><b>4.3.5.3</b></a>, <a href="#rfc.xref.status.502.2">9.2</a></li>3822 <li>503 Service Unavailable <a href="#rfc.xref.status.503.1">4.1</a>, <a href="#rfc.iref.s.3 4"><b>4.3.5.4</b></a>, <a href="#rfc.xref.status.503.2">9.2</a></li>3823 <li>504 Gateway Timeout <a href="#rfc.xref.status.504.1">4.1</a>, <a href="#rfc.iref.s.3 5"><b>4.3.5.5</b></a>, <a href="#rfc.xref.status.504.2">9.2</a></li>3824 <li>505 HTTP Version Not Supported <a href="#rfc.xref.status.505.1">4.1</a>, <a href="#rfc.iref.s.3 6"><b>4.3.5.6</b></a>, <a href="#rfc.xref.status.505.2">9.2</a></li>3736 <li>100 Continue <a href="#rfc.xref.status.100.1">4.1</a>, <a href="#rfc.iref.s.2"><b>4.3.1.1</b></a>, <a href="#rfc.xref.status.100.2">8.2</a></li> 3737 <li>101 Switching Protocols <a href="#rfc.xref.status.101.1">4.1</a>, <a href="#rfc.iref.s.3"><b>4.3.1.2</b></a>, <a href="#rfc.xref.status.101.2">8.2</a></li> 3738 <li>200 OK <a href="#rfc.xref.status.200.1">4.1</a>, <a href="#rfc.iref.s.4"><b>4.3.2.1</b></a>, <a href="#rfc.xref.status.200.2">8.2</a></li> 3739 <li>201 Created <a href="#rfc.xref.status.201.1">4.1</a>, <a href="#rfc.iref.s.5"><b>4.3.2.2</b></a>, <a href="#rfc.xref.status.201.2">8.2</a></li> 3740 <li>202 Accepted <a href="#rfc.xref.status.202.1">4.1</a>, <a href="#rfc.iref.s.6"><b>4.3.2.3</b></a>, <a href="#rfc.xref.status.202.2">8.2</a></li> 3741 <li>203 Non-Authoritative Information <a href="#rfc.xref.status.203.1">4.1</a>, <a href="#rfc.iref.s.7"><b>4.3.2.4</b></a>, <a href="#rfc.xref.status.203.2">8.2</a>, <a href="#rfc.xref.status.203.3">A</a></li> 3742 <li>204 No Content <a href="#rfc.xref.status.204.1">4.1</a>, <a href="#rfc.iref.s.8"><b>4.3.2.5</b></a>, <a href="#rfc.xref.status.204.2">8.2</a></li> 3743 <li>205 Reset Content <a href="#rfc.xref.status.205.1">4.1</a>, <a href="#rfc.iref.s.9"><b>4.3.2.6</b></a>, <a href="#rfc.xref.status.205.2">8.2</a></li> 3744 <li>300 Multiple Choices <a href="#rfc.xref.status.300.1">4.1</a>, <a href="#rfc.iref.s.10"><b>4.3.3.1</b></a>, <a href="#rfc.xref.status.300.2">8.2</a></li> 3745 <li>301 Moved Permanently <a href="#rfc.xref.status.301.1">4.1</a>, <a href="#rfc.iref.s.11"><b>4.3.3.2</b></a>, <a href="#rfc.xref.status.301.2">8.2</a>, <a href="#rfc.xref.status.301.3">A</a></li> 3746 <li>302 Found <a href="#rfc.xref.status.302.1">4.1</a>, <a href="#rfc.iref.s.12"><b>4.3.3.3</b></a>, <a href="#rfc.xref.status.302.2">8.2</a>, <a href="#rfc.xref.status.302.3">A</a></li> 3747 <li>303 See Other <a href="#rfc.xref.status.303.1">4.1</a>, <a href="#rfc.iref.s.13"><b>4.3.3.4</b></a>, <a href="#rfc.xref.status.303.2">8.2</a></li> 3748 <li>305 Use Proxy <a href="#rfc.xref.status.305.1">4.1</a>, <a href="#rfc.iref.s.14"><b>4.3.3.5</b></a>, <a href="#rfc.xref.status.305.2">8.2</a>, <a href="#rfc.xref.status.305.3">A</a></li> 3749 <li>306 (Unused) <a href="#rfc.iref.s.15"><b>4.3.3.6</b></a>, <a href="#rfc.xref.status.306.1">8.2</a></li> 3750 <li>307 Temporary Redirect <a href="#rfc.xref.status.307.1">4.1</a>, <a href="#rfc.iref.s.16"><b>4.3.3.7</b></a>, <a href="#rfc.xref.status.307.2">8.2</a>, <a href="#rfc.xref.status.307.3">A</a></li> 3751 <li>400 Bad Request <a href="#rfc.xref.status.400.1">4.1</a>, <a href="#rfc.iref.s.17"><b>4.3.4.1</b></a>, <a href="#rfc.xref.status.400.2">8.2</a></li> 3752 <li>402 Payment Required <a href="#rfc.xref.status.402.1">4.1</a>, <a href="#rfc.iref.s.18"><b>4.3.4.2</b></a>, <a href="#rfc.xref.status.402.2">8.2</a></li> 3753 <li>403 Forbidden <a href="#rfc.xref.status.403.1">4.1</a>, <a href="#rfc.iref.s.19"><b>4.3.4.3</b></a>, <a href="#rfc.xref.status.403.2">8.2</a></li> 3754 <li>404 Not Found <a href="#rfc.xref.status.404.1">4.1</a>, <a href="#rfc.iref.s.20"><b>4.3.4.4</b></a>, <a href="#rfc.xref.status.404.2">8.2</a></li> 3755 <li>405 Method Not Allowed <a href="#rfc.xref.status.405.1">4.1</a>, <a href="#rfc.iref.s.21"><b>4.3.4.5</b></a>, <a href="#rfc.xref.status.405.2">8.2</a></li> 3756 <li>406 Not Acceptable <a href="#rfc.xref.status.406.1">4.1</a>, <a href="#rfc.iref.s.22"><b>4.3.4.6</b></a>, <a href="#rfc.xref.status.406.2">8.2</a></li> 3757 <li>408 Request Timeout <a href="#rfc.xref.status.408.1">4.1</a>, <a href="#rfc.iref.s.23"><b>4.3.4.7</b></a>, <a href="#rfc.xref.status.408.2">8.2</a></li> 3758 <li>409 Conflict <a href="#rfc.xref.status.409.1">4.1</a>, <a href="#rfc.iref.s.24"><b>4.3.4.8</b></a>, <a href="#rfc.xref.status.409.2">8.2</a></li> 3759 <li>410 Gone <a href="#rfc.xref.status.410.1">4.1</a>, <a href="#rfc.iref.s.25"><b>4.3.4.9</b></a>, <a href="#rfc.xref.status.410.2">8.2</a></li> 3760 <li>411 Length Required <a href="#rfc.xref.status.411.1">4.1</a>, <a href="#rfc.iref.s.26"><b>4.3.4.10</b></a>, <a href="#rfc.xref.status.411.2">8.2</a></li> 3761 <li>413 Request Representation Too Large <a href="#rfc.xref.status.413.1">4.1</a>, <a href="#rfc.iref.s.27"><b>4.3.4.11</b></a>, <a href="#rfc.xref.status.413.2">8.2</a></li> 3762 <li>414 URI Too Long <a href="#rfc.xref.status.414.1">4.1</a>, <a href="#rfc.iref.s.28"><b>4.3.4.12</b></a>, <a href="#rfc.xref.status.414.2">8.2</a></li> 3763 <li>415 Unsupported Media Type <a href="#rfc.xref.status.415.1">4.1</a>, <a href="#rfc.iref.s.29"><b>4.3.4.13</b></a>, <a href="#rfc.xref.status.415.2">8.2</a></li> 3764 <li>417 Expectation Failed <a href="#rfc.xref.status.417.1">4.1</a>, <a href="#rfc.iref.s.30"><b>4.3.4.14</b></a>, <a href="#rfc.xref.status.417.2">8.2</a></li> 3765 <li>426 Upgrade Required <a href="#rfc.xref.status.426.1">4.1</a>, <a href="#rfc.iref.s.31"><b>4.3.4.15</b></a>, <a href="#rfc.xref.status.426.2">8.2</a>, <a href="#rfc.xref.status.426.3">A</a></li> 3766 <li>500 Internal Server Error <a href="#rfc.xref.status.500.1">4.1</a>, <a href="#rfc.iref.s.32"><b>4.3.5.1</b></a>, <a href="#rfc.xref.status.500.2">8.2</a></li> 3767 <li>501 Not Implemented <a href="#rfc.xref.status.501.1">4.1</a>, <a href="#rfc.iref.s.33"><b>4.3.5.2</b></a>, <a href="#rfc.xref.status.501.2">8.2</a></li> 3768 <li>502 Bad Gateway <a href="#rfc.xref.status.502.1">4.1</a>, <a href="#rfc.iref.s.34"><b>4.3.5.3</b></a>, <a href="#rfc.xref.status.502.2">8.2</a></li> 3769 <li>503 Service Unavailable <a href="#rfc.xref.status.503.1">4.1</a>, <a href="#rfc.iref.s.35"><b>4.3.5.4</b></a>, <a href="#rfc.xref.status.503.2">8.2</a></li> 3770 <li>504 Gateway Timeout <a href="#rfc.xref.status.504.1">4.1</a>, <a href="#rfc.iref.s.36"><b>4.3.5.5</b></a>, <a href="#rfc.xref.status.504.2">8.2</a></li> 3771 <li>505 HTTP Version Not Supported <a href="#rfc.xref.status.505.1">4.1</a>, <a href="#rfc.iref.s.37"><b>4.3.5.6</b></a>, <a href="#rfc.xref.status.505.2">8.2</a></li> 3825 3772 </ul> 3826 3773 </li> … … 3828 3775 </li> 3829 3776 <li><a id="rfc.index.T" href="#rfc.index.T"><b>T</b></a><ul> 3830 <li>TRACE method <a href="#rfc. xref.TRACE.1">2.1</a>, <a href="#rfc.iref.t.1"><b>6.8</b></a>, <a href="#rfc.xref.TRACE.2">8.6</a>, <a href="#rfc.xref.TRACE.3">9.1</a>, <a href="#rfc.xref.TRACE.4">10.1</a></li>3777 <li>TRACE method <a href="#rfc.iref.t.1"><b>2.3.7</b></a>, <a href="#rfc.xref.TRACE.1">7.6</a>, <a href="#rfc.xref.TRACE.2">8.1</a>, <a href="#rfc.xref.TRACE.3">9.1</a></li> 3831 3778 </ul> 3832 3779 </li> 3833 3780 <li><a id="rfc.index.U" href="#rfc.index.U"><b>U</b></a><ul> 3834 <li>User-Agent header field <a href="#rfc.xref.header.user-agent.1">3.2</a>, <a href="#rfc.iref.u.1"><b> 8.10</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>3781 <li>User-Agent header field <a href="#rfc.xref.header.user-agent.1">3.2</a>, <a href="#rfc.iref.u.1"><b>7.10</b></a>, <a href="#rfc.xref.header.user-agent.2">8.3</a>, <a href="#rfc.xref.header.user-agent.3">9.1</a></li> 3835 3782 </ul> 3836 3783 </li> -
draft-ietf-httpbis/latest/p2-semantics.xml
r1618 r1619 311 311 </section> 312 312 313 <section title="Method " anchor="method">313 <section title="Methods" anchor="methods"> 314 314 <x:anchor-alias value="method"/> 315 <x:anchor-alias value="extension-method"/>316 315 <t> 317 316 The method token indicates the request method to be performed on the target … … 336 335 </t> 337 336 338 <section title="Overview of Methods" anchor="overview.of.methods"> 339 <t> 340 The methods listed below are defined in <xref target="method.definitions"/>. 341 </t> 342 <texttable align="left"> 343 <ttcol>Method Name</ttcol><ttcol>Defined in...</ttcol> 344 345 <c>OPTIONS</c> <c><xref target="OPTIONS"/></c> 346 <c>GET</c> <c><xref target="GET"/></c> 347 <c>HEAD</c> <c><xref target="HEAD"/></c> 348 <c>POST</c> <c><xref target="POST"/></c> 349 <c>PUT</c> <c><xref target="PUT"/></c> 350 <c>DELETE</c> <c><xref target="DELETE"/></c> 351 <c>TRACE</c> <c><xref target="TRACE"/></c> 352 <c>CONNECT</c> <c><xref target="CONNECT"/></c> 353 </texttable> 354 <t> 355 Note that this list is not exhaustive — it does not include request methods defined 356 in other specifications. 357 </t> 337 <section title="Safe and Idempotent Methods" anchor="safe.and.idempotent"> 338 339 <section title="Safe Methods" anchor="safe.methods"> 340 <iref item="Safe Methods" primary="true"/> 341 <t> 342 Implementors need to be aware that the software represents the user in 343 their interactions over the Internet, and need to allow 344 the user to be aware of any actions they take which might have an 345 unexpected significance to themselves or others. 346 </t> 347 <t> 348 In particular, the convention has been established that the GET, HEAD, 349 OPTIONS, and TRACE request methods &SHOULD-NOT; have the significance 350 of taking an action other than retrieval. These request methods ought 351 to be considered "<x:dfn anchor="safe">safe</x:dfn>". 352 This allows user agents to represent other methods, such as POST, PUT 353 and DELETE, in a special way, so that the user is made aware of the 354 fact that a possibly unsafe action is being requested. 355 </t> 356 <t> 357 Naturally, it is not possible to ensure that the server does not 358 generate side-effects as a result of performing a GET request; in 359 fact, some dynamic resources consider that a feature. The important 360 distinction here is that the user did not request the side-effects, 361 so therefore cannot be held accountable for them. 362 </t> 363 </section> 364 365 <section title="Idempotent Methods" anchor="idempotent.methods"> 366 <iref item="Idempotent Methods" primary="true"/> 367 <t> 368 Request methods can also have the property of "idempotence" in that, 369 aside from error or expiration issues, the intended effect of multiple 370 identical requests is the same as for a single request. 371 PUT, DELETE, and all safe request methods are idempotent. 372 It is important to note that idempotence refers only to changes 373 requested by the client: a server is free to change its state due 374 to multiple requests for the purpose of tracking those requests, 375 versioning of results, etc. 376 </t> 377 </section> 358 378 </section> 359 379 … … 366 386 Registrations &MUST; include the following fields: 367 387 <list style="symbols"> 368 <t>Method Name (see <xref target="method "/>)</t>388 <t>Method Name (see <xref target="methods"/>)</t> 369 389 <t>Safe ("yes" or "no", see <xref target="safe.methods"/>)</t> 370 390 <t>Pointer to specification text</t> … … 409 429 </t> 410 430 </section> 411 412 </section> 431 </section> 432 433 <section title="Method Definitions" anchor="method.definitions"> 434 435 <section title="OPTIONS" anchor="OPTIONS"> 436 <rdf:Description> 437 <safe xmlns="urn:ietf:id:draft-ietf-httpbis-p2-semantics#">yes</safe> 438 </rdf:Description> 439 <iref primary="true" item="OPTIONS method" x:for-anchor=""/> 440 <iref primary="true" item="Methods" subitem="OPTIONS" x:for-anchor=""/> 441 <t> 442 The OPTIONS method requests information about the 443 communication options available on the request/response chain 444 identified by the effective request URI. This method allows a client to 445 determine the options and/or requirements associated with a resource, 446 or the capabilities of a server, without implying a resource action 447 or initiating a resource retrieval. 448 </t> 449 <t> 450 Responses to the OPTIONS method are not cacheable. 451 </t> 452 <t> 453 If the OPTIONS request includes a message body (as indicated by the 454 presence of Content-Length or Transfer-Encoding), then the media type 455 &MUST; be indicated by a Content-Type field. Although this 456 specification does not define any use for such a body, future 457 extensions to HTTP might use the OPTIONS body to make more detailed 458 queries on the server. 459 </t> 460 <t> 461 If the request-target (&request-target;) is an asterisk ("*"), 462 the OPTIONS request is 463 intended to apply to the server in general rather than to a specific 464 resource. Since a server's communication options typically depend on 465 the resource, the "*" request is only useful as a "ping" or "no-op" 466 type of method; it does nothing beyond allowing the client to test 467 the capabilities of the server. For example, this can be used to test 468 a proxy for HTTP/1.1 conformance (or lack thereof). 469 </t> 470 <t> 471 If the request-target is not an asterisk, the OPTIONS request applies 472 only to the options that are available when communicating with that 473 resource. 474 </t> 475 <t> 476 A 200 response &SHOULD; include any header fields that indicate 477 optional features implemented by the server and applicable to that 478 resource (e.g., Allow), possibly including extensions not defined by 479 this specification. The response body, if any, &SHOULD; also include 480 information about the communication options. The format for such a 481 body is not defined by this specification, but might be defined by 482 future extensions to HTTP. Content negotiation &MAY; be used to select 483 the appropriate response format. If no response body is included, the 484 response &MUST; include a Content-Length field with a field-value of 485 "0". 486 </t> 487 <t> 488 The Max-Forwards header field &MAY; be used to target a 489 specific proxy in the request chain (see <xref target="header.max-forwards"/>). 490 If no Max-Forwards field is present in the request, then the forwarded 491 request &MUST-NOT; include a Max-Forwards field. 492 </t> 493 </section> 494 495 <section title="GET" anchor="GET"> 496 <rdf:Description> 497 <safe xmlns="urn:ietf:id:draft-ietf-httpbis-p2-semantics#">yes</safe> 498 </rdf:Description> 499 <iref primary="true" item="GET method" x:for-anchor=""/> 500 <iref primary="true" item="Methods" subitem="GET" x:for-anchor=""/> 501 <t> 502 The GET method requests transfer of a current representation of 503 the target resource. 504 </t> 505 <t> 506 If the target resource is a data-producing process, it is the 507 produced data which shall be returned as the representation in the response and not 508 the source text of the process, unless that text happens to be the output of 509 the process. 510 </t> 511 <t> 512 The semantics of the GET method change to a "conditional GET" if the 513 request message includes an If-Modified-Since, If-Unmodified-Since, 514 If-Match, If-None-Match, or If-Range header field. A conditional GET 515 requests that the representation be transferred only under the 516 circumstances described by the conditional header field(s). The 517 conditional GET request is intended to reduce unnecessary network 518 usage by allowing cached representations to be refreshed without requiring 519 multiple requests or transferring data already held by the client. 520 </t> 521 <t> 522 The semantics of the GET method change to a "partial GET" if the 523 request message includes a Range header field. A partial GET requests 524 that only part of the representation be transferred, as described in &header-range;. 525 The partial GET request is intended to reduce unnecessary 526 network usage by allowing partially-retrieved representations to be 527 completed without transferring data already held by the client. 528 </t> 529 <t> 530 Bodies on GET requests have no defined semantics. Note that sending a body 531 on a GET request might cause some existing implementations to reject the 532 request. 533 </t> 534 <t> 535 The response to a GET request is cacheable and &MAY; be used to satisfy 536 subsequent GET and HEAD requests (see &caching;). 537 </t> 538 <t> 539 See <xref target="encoding.sensitive.information.in.uris"/> for security considerations when used for forms. 540 </t> 541 </section> 542 543 <section title="HEAD" anchor="HEAD"> 544 <rdf:Description> 545 <safe xmlns="urn:ietf:id:draft-ietf-httpbis-p2-semantics#">yes</safe> 546 </rdf:Description> 547 <iref primary="true" item="HEAD method" x:for-anchor=""/> 548 <iref primary="true" item="Methods" subitem="HEAD" x:for-anchor=""/> 549 <t> 550 The HEAD method is identical to GET except that the server &MUST-NOT; 551 return a message body in the response. The metadata contained 552 in the HTTP header fields in response to a HEAD request &SHOULD; be identical 553 to the information sent in response to a GET request. This method can 554 be used for obtaining metadata about the representation implied by the 555 request without transferring the representation body. This method is 556 often used for testing hypertext links for validity, accessibility, 557 and recent modification. 558 </t> 559 <t> 560 The response to a HEAD request is cacheable and &MAY; be used to satisfy 561 a subsequent HEAD request. It also has potential side effects on 562 previously stored responses to GET; see &p6-head;. 563 </t> 564 <t> 565 Bodies on HEAD requests have no defined semantics. Note that sending a body 566 on a HEAD request might cause some existing implementations to reject the 567 request. 568 </t> 569 </section> 570 571 <section title="POST" anchor="POST"> 572 <iref primary="true" item="POST method" x:for-anchor=""/> 573 <iref primary="true" item="Methods" subitem="POST" x:for-anchor=""/> 574 <t> 575 The POST method requests that the origin server accept the 576 representation enclosed in the request as data to be processed by the 577 target resource. POST is designed to allow a uniform method to cover the 578 following functions: 579 <list style="symbols"> 580 <t> 581 Annotation of existing resources; 582 </t> 583 <t> 584 Posting a message to a bulletin board, newsgroup, mailing list, 585 or similar group of articles; 586 </t> 587 <t> 588 Providing a block of data, such as the result of submitting a 589 form, to a data-handling process; 590 </t> 591 <t> 592 Extending a database through an append operation. 593 </t> 594 </list> 595 </t> 596 <t> 597 The actual function performed by the POST method is determined by the 598 server and is usually dependent on the effective request URI. 599 </t> 600 <t> 601 The action performed by the POST method might not result in a 602 resource that can be identified by a URI. In this case, either 200 603 (OK) or 204 (No Content) is the appropriate response status code, 604 depending on whether or not the response includes a representation that 605 describes the result. 606 </t> 607 <t> 608 If a resource has been created on the origin server, the response 609 &SHOULD; be 201 (Created) and contain a representation which describes the 610 status of the request and refers to the new resource, and a Location 611 header field (see <xref target="header.location"/>). 612 </t> 613 <t> 614 Responses to POST requests are only cacheable when they 615 include explicit freshness information (see &p6-explicit;). A 616 cached POST response with a Content-Location header field 617 (see &header-content-location;) whose value is the effective 618 Request URI &MAY; be used to satisfy subsequent GET and HEAD requests. 619 </t> 620 <t> 621 Note that POST caching is not widely implemented. 622 However, the 303 (See Other) response can be used to direct the 623 user agent to retrieve a cacheable representation of the resource. 624 </t> 625 </section> 626 627 <section title="PUT" anchor="PUT"> 628 <iref primary="true" item="PUT method" x:for-anchor=""/> 629 <iref primary="true" item="Methods" subitem="PUT" x:for-anchor=""/> 630 <t> 631 The PUT method requests that the state of the target resource 632 be created or replaced with the state defined by the representation 633 enclosed in the request message payload. A successful PUT of a given 634 representation would suggest that a subsequent GET on that same target 635 resource will result in an equivalent representation being returned in 636 a 200 (OK) response. However, there is no guarantee that such a state 637 change will be observable, since the target resource might be acted 638 upon by other user agents in parallel, or might be subject to dynamic 639 processing by the origin server, before any subsequent GET is received. 640 A successful response only implies that the user agent's intent was 641 achieved at the time of its processing by the origin server. 642 </t> 643 <t> 644 If the target resource does not have a current representation and 645 the PUT successfully creates one, then the origin server &MUST; inform 646 the user agent by sending a 201 (Created) response. If the target 647 resource does have a current representation and that representation is 648 successfully modified in accordance with the state of the enclosed 649 representation, then either a 200 (OK) or 204 (No Content) response 650 &SHOULD; be sent to indicate successful completion of the request. 651 </t> 652 <t> 653 Unrecognized header fields &SHOULD; be ignored (i.e., not saved 654 as part of the resource state). 655 </t> 656 <t> 657 An origin server &SHOULD; verify that the PUT representation is 658 consistent with any constraints which the server has for the target 659 resource that cannot or will not be changed by the PUT. This is 660 particularly important when the origin server uses internal 661 configuration information related to the URI in order to set the 662 values for representation metadata on GET responses. When a PUT 663 representation is inconsistent with the target resource, the origin 664 server &SHOULD; either make them consistent, by transforming the 665 representation or changing the resource configuration, or respond 666 with an appropriate error message containing sufficient information 667 to explain why the representation is unsuitable. The 409 (Conflict) 668 or 415 (Unsupported Media Type) status codes are suggested, with the 669 latter being specific to constraints on Content-Type values. 670 </t> 671 <t> 672 For example, if the target resource is configured to always have a 673 Content-Type of "text/html" and the representation being PUT has a 674 Content-Type of "image/jpeg", then the origin server &SHOULD; do one of: 675 (a) reconfigure the target resource to reflect the new media type; 676 (b) transform the PUT representation to a format consistent with that 677 of the resource before saving it as the new resource state; or, 678 (c) reject the request with a 415 response indicating that the target 679 resource is limited to "text/html", perhaps including a link to a 680 different resource that would be a suitable target for the new 681 representation. 682 </t> 683 <t> 684 HTTP does not define exactly how a PUT method affects the state 685 of an origin server beyond what can be expressed by the intent of 686 the user agent request and the semantics of the origin server response. 687 It does not define what a resource might be, in any sense of that 688 word, beyond the interface provided via HTTP. It does not define 689 how resource state is "stored", nor how such storage might change 690 as a result of a change in resource state, nor how the origin server 691 translates resource state into representations. Generally speaking, 692 all implementation details behind the resource interface are 693 intentionally hidden by the server. 694 </t> 695 <t> 696 The fundamental difference between the POST and PUT methods is 697 highlighted by the different intent for the target resource. 698 The target resource in a POST request is intended to handle the 699 enclosed representation as a data-accepting process, such as for 700 a gateway to some other protocol or a document that accepts annotations. 701 In contrast, the target resource in a PUT request is intended to 702 take the enclosed representation as a new or replacement value. 703 Hence, the intent of PUT is idempotent and visible to intermediaries, 704 even though the exact effect is only known by the origin server. 705 </t> 706 <t> 707 Proper interpretation of a PUT request presumes that the user agent 708 knows what target resource is desired. A service that is intended 709 to select a proper URI on behalf of the client, after receiving 710 a state-changing request, &SHOULD; be implemented using the POST 711 method rather than PUT. If the origin server will not make the 712 requested PUT state change to the target resource and instead 713 wishes to have it applied to a different resource, such as when the 714 resource has been moved to a different URI, then the origin server 715 &MUST; send a 301 (Moved Permanently) response; the user agent &MAY; 716 then make its own decision regarding whether or not to redirect the 717 request. 718 </t> 719 <t> 720 A PUT request applied to the target resource &MAY; have side-effects 721 on other resources. For example, an article might have a URI for 722 identifying "the current version" (a resource) which is separate 723 from the URIs identifying each particular version (different 724 resources that at one point shared the same state as the current version 725 resource). A successful PUT request on "the current version" URI might 726 therefore create a new version resource in addition to changing the 727 state of the target resource, and might also cause links to be added 728 between the related resources. 729 </t> 730 <t> 731 An origin server &SHOULD; reject any PUT request that contains a 732 Content-Range header field, since it might be misinterpreted as 733 partial content (or might be partial content that is being mistakenly 734 PUT as a full representation). Partial content updates are 735 possible by targeting a separately identified resource with state 736 that overlaps a portion of the larger resource, or by using a 737 different method that has been specifically defined for partial 738 updates (for example, the PATCH method defined in 739 <xref target="RFC5789"/>). 740 </t> 741 <t> 742 Responses to the PUT method are not cacheable. If a PUT request passes 743 through a cache that has one or more stored responses for the effective 744 request URI, those stored responses will be invalidated (see 745 &p6-invalid;). 746 </t> 747 </section> 748 749 <section title="DELETE" anchor="DELETE"> 750 <iref primary="true" item="DELETE method" x:for-anchor=""/> 751 <iref primary="true" item="Methods" subitem="DELETE" x:for-anchor=""/> 752 <t> 753 The DELETE method requests that the origin server delete the target 754 resource. This method &MAY; be overridden by 755 human intervention (or other means) on the origin server. The client cannot 756 be guaranteed that the operation has been carried out, even if the 757 status code returned from the origin server indicates that the action 758 has been completed successfully. However, the server &SHOULD-NOT; 759 indicate success unless, at the time the response is given, it 760 intends to delete the resource or move it to an inaccessible 761 location. 762 </t> 763 <t> 764 A successful response &SHOULD; be 200 (OK) if the response includes an 765 representation describing the status, 202 (Accepted) if the action has not 766 yet been enacted, or 204 (No Content) if the action has been enacted 767 but the response does not include a representation. 768 </t> 769 <t> 770 Bodies on DELETE requests have no defined semantics. Note that sending a body 771 on a DELETE request might cause some existing implementations to reject the 772 request. 773 </t> 774 <t> 775 Responses to the DELETE method are not cacheable. If a DELETE request 776 passes through a cache that has one or more stored responses for the 777 effective request URI, those stored responses will be invalidated (see 778 &p6-invalid;). 779 </t> 780 </section> 781 782 <section title="TRACE" anchor="TRACE"> 783 <rdf:Description> 784 <safe xmlns="urn:ietf:id:draft-ietf-httpbis-p2-semantics#">yes</safe> 785 </rdf:Description> 786 <iref primary="true" item="TRACE method" x:for-anchor=""/> 787 <iref primary="true" item="Methods" subitem="TRACE" x:for-anchor=""/> 788 <t> 789 The TRACE method requests a remote, application-layer loop-back 790 of the request message. The final recipient of the request 791 &SHOULD; reflect the message received back to the client as the 792 message body of a 200 (OK) response. The final recipient is either the 793 origin server or the first proxy to receive a Max-Forwards 794 value of zero (0) in the request (see <xref target="header.max-forwards"/>). 795 A TRACE request &MUST-NOT; include a message body. 796 </t> 797 <t> 798 TRACE allows the client to see what is being received at the other 799 end of the request chain and use that data for testing or diagnostic 800 information. The value of the Via header field (&header-via;) is of 801 particular interest, since it acts as a trace of the request chain. 802 Use of the Max-Forwards header field allows the client to limit the 803 length of the request chain, which is useful for testing a chain of 804 proxies forwarding messages in an infinite loop. 805 </t> 806 <t> 807 If the request is valid, the response &SHOULD; have a Content-Type of 808 "message/http" (see &media-type-message-http;) and contain a message body 809 that encloses a copy of the entire request message. 810 Responses to the TRACE method are not cacheable. 811 </t> 812 </section> 813 814 <section title="CONNECT" anchor="CONNECT"> 815 <iref primary="true" item="CONNECT method" x:for-anchor=""/> 816 <iref primary="true" item="Methods" subitem="CONNECT" x:for-anchor=""/> 817 <t> 818 The CONNECT method requests that the proxy establish a tunnel 819 to the request-target and, if successful, thereafter restrict its behavior 820 to blind forwarding of packets until the connection is closed. 821 </t> 822 <t> 823 When using CONNECT, the request-target &MUST; use the authority form 824 (&request-target;); i.e., the request-target consists of only the 825 host name and port number of the tunnel destination, separated by a colon. 826 For example, 827 </t> 828 <figure><artwork type="message/http; msgtype="request"" x:indent-with=" "> 829 CONNECT server.example.com:80 HTTP/1.1 830 Host: server.example.com:80 831 832 </artwork></figure> 833 <t> 834 Any successful (2xx) response to a CONNECT request indicates that the 835 proxy has established a connection to the requested host and port, 836 and has switched to tunneling the current connection to that server 837 connection. 838 The tunneled data from the server begins immediately after the blank line 839 that concludes the successful response's header block. 840 A server &SHOULD-NOT; send any Transfer-Encoding or Content-Length 841 header fields in a successful response. 842 A client &MUST; ignore any Content-Length or Transfer-Encoding header 843 fields received in a successful response. 844 </t> 845 <t> 846 Any response other than a successful response indicates that the tunnel 847 has not yet been formed and that the connection remains governed by HTTP. 848 </t> 849 <t> 850 Proxy authentication might be used to establish the 851 authority to create a tunnel: 852 </t> 853 <figure><artwork type="message/http; msgtype="request"" x:indent-with=" "> 854 CONNECT server.example.com:80 HTTP/1.1 855 Host: server.example.com:80 856 Proxy-Authorization: basic aGVsbG86d29ybGQ= 857 858 </artwork></figure> 859 <t> 860 A message body on a CONNECT request has no defined semantics. Sending a 861 body on a CONNECT request might cause existing implementations to reject 862 the request. 863 </t> 864 <t> 865 Similar to a pipelined HTTP/1.1 request, data to be tunneled from client 866 to server &MAY; be sent immediately after the request (before a response 867 is received). The usual caveats also apply: 868 data may be discarded if the eventual response is negative, and the 869 connection may be reset with no response if more than one TCP segment 870 is outstanding. 871 </t> 872 <t> 873 It may be the case that the proxy itself can only reach the requested 874 origin server through another proxy. In this case, the first proxy 875 &SHOULD; make a CONNECT request of that next proxy, requesting a tunnel 876 to the authority. A proxy &MUST-NOT; respond with any 2xx status code 877 unless it has either a direct or tunnel connection established to the 878 authority. 879 </t> 880 <t> 881 If at any point either one of the peers gets disconnected, any 882 outstanding data that came from that peer will be passed to the other 883 one, and after that also the other connection will be terminated by 884 the proxy. If there is outstanding data to that peer undelivered, 885 that data will be discarded. 886 </t> 887 <t> 888 An origin server which receives a CONNECT request for itself &MAY; 889 respond with a 2xx status code to indicate that a connection is 890 established. However, most origin servers do not implement CONNECT. 891 </t> 892 </section> 893 </section> 894 413 895 </section> 414 896 … … 1636 2118 1637 2119 1638 <section title="Method Definitions" anchor="method.definitions">1639 <t>1640 The set of common request methods for HTTP/1.1 is defined below. Although1641 this set can be expanded, additional methods cannot be assumed to1642 share the same semantics for separately extended clients and servers.1643 </t>1644 1645 <section title="Safe and Idempotent Methods" anchor="safe.and.idempotent">1646 1647 <section title="Safe Methods" anchor="safe.methods">1648 <iref item="Safe Methods" primary="true"/>1649 <t>1650 Implementors need to be aware that the software represents the user in1651 their interactions over the Internet, and need to allow1652 the user to be aware of any actions they take which might have an1653 unexpected significance to themselves or others.1654 </t>1655 <t>1656 In particular, the convention has been established that the GET, HEAD,1657 OPTIONS, and TRACE request methods &SHOULD-NOT; have the significance1658 of taking an action other than retrieval. These request methods ought1659 to be considered "<x:dfn anchor="safe">safe</x:dfn>".1660 This allows user agents to represent other methods, such as POST, PUT1661 and DELETE, in a special way, so that the user is made aware of the1662 fact that a possibly unsafe action is being requested.1663 </t>1664 <t>1665 Naturally, it is not possible to ensure that the server does not1666 generate side-effects as a result of performing a GET request; in1667 fact, some dynamic resources consider that a feature. The important1668 distinction here is that the user did not request the side-effects,1669 so therefore cannot be held accountable for them.1670 </t>1671 </section>1672 1673 <section title="Idempotent Methods" anchor="idempotent.methods">1674 <iref item="Idempotent Methods" primary="true"/>1675 <t>1676 Request methods can also have the property of "idempotence" in that,1677 aside from error or expiration issues, the intended effect of multiple1678 identical requests is the same as for a single request.1679 PUT, DELETE, and all safe request methods are idempotent.1680 It is important to note that idempotence refers only to changes1681 requested by the client: a server is free to change its state due1682 to multiple requests for the purpose of tracking those requests,1683 versioning of results, etc.1684 </t>1685 </section>1686 </section>1687 1688 <section title="OPTIONS" anchor="OPTIONS">1689 <rdf:Description>1690 <safe xmlns="urn:ietf:id:draft-ietf-httpbis-p2-semantics#">yes</safe>1691 </rdf:Description>1692 <iref primary="true" item="OPTIONS method" x:for-anchor=""/>1693 <iref primary="true" item="Methods" subitem="OPTIONS" x:for-anchor=""/>1694 <t>1695 The OPTIONS method requests information about the1696 communication options available on the request/response chain1697 identified by the effective request URI. This method allows a client to1698 determine the options and/or requirements associated with a resource,1699 or the capabilities of a server, without implying a resource action1700 or initiating a resource retrieval.1701 </t>1702 <t>1703 Responses to the OPTIONS method are not cacheable.1704 </t>1705 <t>1706 If the OPTIONS request includes a message body (as indicated by the1707 presence of Content-Length or Transfer-Encoding), then the media type1708 &MUST; be indicated by a Content-Type field. Although this1709 specification does not define any use for such a body, future1710 extensions to HTTP might use the OPTIONS body to make more detailed1711 queries on the server.1712 </t>1713 <t>1714 If the request-target (&request-target;) is an asterisk ("*"),1715 the OPTIONS request is1716 intended to apply to the server in general rather than to a specific1717 resource. Since a server's communication options typically depend on1718 the resource, the "*" request is only useful as a "ping" or "no-op"1719 type of method; it does nothing beyond allowing the client to test1720 the capabilities of the server. For example, this can be used to test1721 a proxy for HTTP/1.1 conformance (or lack thereof).1722 </t>1723 <t>1724 If the request-target is not an asterisk, the OPTIONS request applies1725 only to the options that are available when communicating with that1726 resource.1727 </t>1728 <t>1729 A 200 response &SHOULD; include any header fields that indicate1730 optional features implemented by the server and applicable to that1731 resource (e.g., Allow), possibly including extensions not defined by1732 this specification. The response body, if any, &SHOULD; also include1733 information about the communication options. The format for such a1734 body is not defined by this specification, but might be defined by1735 future extensions to HTTP. Content negotiation &MAY; be used to select1736 the appropriate response format. If no response body is included, the1737 response &MUST; include a Content-Length field with a field-value of1738 "0".1739 </t>1740 <t>1741 The Max-Forwards header field &MAY; be used to target a1742 specific proxy in the request chain (see <xref target="header.max-forwards"/>).1743 If no Max-Forwards field is present in the request, then the forwarded1744 request &MUST-NOT; include a Max-Forwards field.1745 </t>1746 </section>1747 1748 <section title="GET" anchor="GET">1749 <rdf:Description>1750 <safe xmlns="urn:ietf:id:draft-ietf-httpbis-p2-semantics#">yes</safe>1751 </rdf:Description>1752 <iref primary="true" item="GET method" x:for-anchor=""/>1753 <iref primary="true" item="Methods" subitem="GET" x:for-anchor=""/>1754 <t>1755 The GET method requests transfer of a current representation of1756 the target resource.1757 </t>1758 <t>1759 If the target resource is a data-producing process, it is the1760 produced data which shall be returned as the representation in the response and not1761 the source text of the process, unless that text happens to be the output of1762 the process.1763 </t>1764 <t>1765 The semantics of the GET method change to a "conditional GET" if the1766 request message includes an If-Modified-Since, If-Unmodified-Since,1767 If-Match, If-None-Match, or If-Range header field. A conditional GET1768 requests that the representation be transferred only under the1769 circumstances described by the conditional header field(s). The1770 conditional GET request is intended to reduce unnecessary network1771 usage by allowing cached representations to be refreshed without requiring1772 multiple requests or transferring data already held by the client.1773 </t>1774 <t>1775 The semantics of the GET method change to a "partial GET" if the1776 request message includes a Range header field. A partial GET requests1777 that only part of the representation be transferred, as described in &header-range;.1778 The partial GET request is intended to reduce unnecessary1779 network usage by allowing partially-retrieved representations to be1780 completed without transferring data already held by the client.1781 </t>1782 <t>1783 Bodies on GET requests have no defined semantics. Note that sending a body1784 on a GET request might cause some existing implementations to reject the1785 request.1786 </t>1787 <t>1788 The response to a GET request is cacheable and &MAY; be used to satisfy1789 subsequent GET and HEAD requests (see &caching;).1790 </t>1791 <t>1792 See <xref target="encoding.sensitive.information.in.uris"/> for security considerations when used for forms.1793 </t>1794 </section>1795 1796 <section title="HEAD" anchor="HEAD">1797 <rdf:Description>1798 <safe xmlns="urn:ietf:id:draft-ietf-httpbis-p2-semantics#">yes</safe>1799 </rdf:Description>1800 <iref primary="true" item="HEAD method" x:for-anchor=""/>1801 <iref primary="true" item="Methods" subitem="HEAD" x:for-anchor=""/>1802 <t>1803 The HEAD method is identical to GET except that the server &MUST-NOT;1804 return a message body in the response. The metadata contained1805 in the HTTP header fields in response to a HEAD request &SHOULD; be identical1806 to the information sent in response to a GET request. This method can1807 be used for obtaining metadata about the representation implied by the1808 request without transferring the representation body. This method is1809 often used for testing hypertext links for validity, accessibility,1810 and recent modification.1811 </t>1812 <t>1813 The response to a HEAD request is cacheable and &MAY; be used to satisfy1814 a subsequent HEAD request. It also has potential side effects on1815 previously stored responses to GET; see &p6-head;.1816 </t>1817 <t>1818 Bodies on HEAD requests have no defined semantics. Note that sending a body1819 on a HEAD request might cause some existing implementations to reject the1820 request.1821 </t>1822 </section>1823 1824 <section title="POST" anchor="POST">1825 <iref primary="true" item="POST method" x:for-anchor=""/>1826 <iref primary="true" item="Methods" subitem="POST" x:for-anchor=""/>1827 <t>1828 The POST method requests that the origin server accept the1829 representation enclosed in the request as data to be processed by the1830 target resource. POST is designed to allow a uniform method to cover the1831 following functions:1832 <list style="symbols">1833 <t>1834 Annotation of existing resources;1835 </t>1836 <t>1837 Posting a message to a bulletin board, newsgroup, mailing list,1838 or similar group of articles;1839 </t>1840 <t>1841 Providing a block of data, such as the result of submitting a1842 form, to a data-handling process;1843 </t>1844 <t>1845 Extending a database through an append operation.1846 </t>1847 </list>1848 </t>1849 <t>1850 The actual function performed by the POST method is determined by the1851 server and is usually dependent on the effective request URI.1852 </t>1853 <t>1854 The action performed by the POST method might not result in a1855 resource that can be identified by a URI. In this case, either 2001856 (OK) or 204 (No Content) is the appropriate response status code,1857 depending on whether or not the response includes a representation that1858 describes the result.1859 </t>1860 <t>1861 If a resource has been created on the origin server, the response1862 &SHOULD; be 201 (Created) and contain a representation which describes the1863 status of the request and refers to the new resource, and a Location1864 header field (see <xref target="header.location"/>).1865 </t>1866 <t>1867 Responses to POST requests are only cacheable when they1868 include explicit freshness information (see &p6-explicit;). A1869 cached POST response with a Content-Location header field1870 (see &header-content-location;) whose value is the effective1871 Request URI &MAY; be used to satisfy subsequent GET and HEAD requests.1872 </t>1873 <t>1874 Note that POST caching is not widely implemented.1875 However, the 303 (See Other) response can be used to direct the1876 user agent to retrieve a cacheable representation of the resource.1877 </t>1878 </section>1879 1880 <section title="PUT" anchor="PUT">1881 <iref primary="true" item="PUT method" x:for-anchor=""/>1882 <iref primary="true" item="Methods" subitem="PUT" x:for-anchor=""/>1883 <t>1884 The PUT method requests that the state of the target resource1885 be created or replaced with the state defined by the representation1886 enclosed in the request message payload. A successful PUT of a given1887 representation would suggest that a subsequent GET on that same target1888 resource will result in an equivalent representation being returned in1889 a 200 (OK) response. However, there is no guarantee that such a state1890 change will be observable, since the target resource might be acted1891 upon by other user agents in parallel, or might be subject to dynamic1892 processing by the origin server, before any subsequent GET is received.1893 A successful response only implies that the user agent's intent was1894 achieved at the time of its processing by the origin server.1895 </t>1896 <t>1897 If the target resource does not have a current representation and1898 the PUT successfully creates one, then the origin server &MUST; inform1899 the user agent by sending a 201 (Created) response. If the target1900 resource does have a current representation and that representation is1901 successfully modified in accordance with the state of the enclosed1902 representation, then either a 200 (OK) or 204 (No Content) response1903 &SHOULD; be sent to indicate successful completion of the request.1904 </t>1905 <t>1906 Unrecognized header fields &SHOULD; be ignored (i.e., not saved1907 as part of the resource state).1908 </t>1909 <t>1910 An origin server &SHOULD; verify that the PUT representation is1911 consistent with any constraints which the server has for the target1912 resource that cannot or will not be changed by the PUT. This is1913 particularly important when the origin server uses internal1914 configuration information related to the URI in order to set the1915 values for representation metadata on GET responses. When a PUT1916 representation is inconsistent with the target resource, the origin1917 server &SHOULD; either make them consistent, by transforming the1918 representation or changing the resource configuration, or respond1919 with an appropriate error message containing sufficient information1920 to explain why the representation is unsuitable. The 409 (Conflict)1921 or 415 (Unsupported Media Type) status codes are suggested, with the1922 latter being specific to constraints on Content-Type values.1923 </t>1924 <t>1925 For example, if the target resource is configured to always have a1926 Content-Type of "text/html" and the representation being PUT has a1927 Content-Type of "image/jpeg", then the origin server &SHOULD; do one of:1928 (a) reconfigure the target resource to reflect the new media type;1929 (b) transform the PUT representation to a format consistent with that1930 of the resource before saving it as the new resource state; or,1931 (c) reject the request with a 415 response indicating that the target1932 resource is limited to "text/html", perhaps including a link to a1933 different resource that would be a suitable target for the new1934 representation.1935 </t>1936 <t>1937 HTTP does not define exactly how a PUT method affects the state1938 of an origin server beyond what can be expressed by the intent of1939 the user agent request and the semantics of the origin server response.1940 It does not define what a resource might be, in any sense of that1941 word, beyond the interface provided via HTTP. It does not define1942 how resource state is "stored", nor how such storage might change1943 as a result of a change in resource state, nor how the origin server1944 translates resource state into representations. Generally speaking,1945 all implementation details behind the resource interface are1946 intentionally hidden by the server.1947 </t>1948 <t>1949 The fundamental difference between the POST and PUT methods is1950 highlighted by the different intent for the target resource.1951 The target resource in a POST request is intended to handle the1952 enclosed representation as a data-accepting process, such as for1953 a gateway to some other protocol or a document that accepts annotations.1954 In contrast, the target resource in a PUT request is intended to1955 take the enclosed representation as a new or replacement value.1956 Hence, the intent of PUT is idempotent and visible to intermediaries,1957 even though the exact effect is only known by the origin server.1958 </t>1959 <t>1960 Proper interpretation of a PUT request presumes that the user agent1961 knows what target resource is desired. A service that is intended1962 to select a proper URI on behalf of the client, after receiving1963 a state-changing request, &SHOULD; be implemented using the POST1964 method rather than PUT. If the origin server will not make the1965 requested PUT state change to the target resource and instead1966 wishes to have it applied to a different resource, such as when the1967 resource has been moved to a different URI, then the origin server1968 &MUST; send a 301 (Moved Permanently) response; the user agent &MAY;1969 then make its own decision regarding whether or not to redirect the1970 request.1971 </t>1972 <t>1973 A PUT request applied to the target resource &MAY; have side-effects1974 on other resources. For example, an article might have a URI for1975 identifying "the current version" (a resource) which is separate1976 from the URIs identifying each particular version (different1977 resources that at one point shared the same state as the current version1978 resource). A successful PUT request on "the current version" URI might1979 therefore create a new version resource in addition to changing the1980 state of the target resource, and might also cause links to be added1981 between the related resources.1982 </t>1983 <t>1984 An origin server &SHOULD; reject any PUT request that contains a1985 Content-Range header field, since it might be misinterpreted as1986 partial content (or might be partial content that is being mistakenly1987 PUT as a full representation). Partial content updates are1988 possible by targeting a separately identified resource with state1989 that overlaps a portion of the larger resource, or by using a1990 different method that has been specifically defined for partial1991 updates (for example, the PATCH method defined in1992 <xref target="RFC5789"/>).1993 </t>1994 <t>1995 Responses to the PUT method are not cacheable. If a PUT request passes1996 through a cache that has one or more stored responses for the effective1997 request URI, those stored responses will be invalidated (see1998 &p6-invalid;).1999 </t>2000 </section>2001 2002 <section title="DELETE" anchor="DELETE">2003 <iref primary="true" item="DELETE method" x:for-anchor=""/>2004 <iref primary="true" item="Methods" subitem="DELETE" x:for-anchor=""/>2005 <t>2006 The DELETE method requests that the origin server delete the target2007 resource. This method &MAY; be overridden by2008 human intervention (or other means) on the origin server. The client cannot2009 be guaranteed that the operation has been carried out, even if the2010 status code returned from the origin server indicates that the action2011 has been completed successfully. However, the server &SHOULD-NOT;2012 indicate success unless, at the time the response is given, it2013 intends to delete the resource or move it to an inaccessible2014 location.2015 </t>2016 <t>2017 A successful response &SHOULD; be 200 (OK) if the response includes an2018 representation describing the status, 202 (Accepted) if the action has not2019 yet been enacted, or 204 (No Content) if the action has been enacted2020 but the response does not include a representation.2021 </t>2022 <t>2023 Bodies on DELETE requests have no defined semantics. Note that sending a body2024 on a DELETE request might cause some existing implementations to reject the2025 request.2026 </t>2027 <t>2028 Responses to the DELETE method are not cacheable. If a DELETE request2029 passes through a cache that has one or more stored responses for the2030 effective request URI, those stored responses will be invalidated (see2031 &p6-invalid;).2032 </t>2033 </section>2034 2035 <section title="TRACE" anchor="TRACE">2036 <rdf:Description>2037 <safe xmlns="urn:ietf:id:draft-ietf-httpbis-p2-semantics#">yes</safe>2038 </rdf:Description>2039 <iref primary="true" item="TRACE method" x:for-anchor=""/>2040 <iref primary="true" item="Methods" subitem="TRACE" x:for-anchor=""/>2041 <t>2042 The TRACE method requests a remote, application-layer loop-back2043 of the request message. The final recipient of the request2044 &SHOULD; reflect the message received back to the client as the2045 message body of a 200 (OK) response. The final recipient is either the2046 origin server or the first proxy to receive a Max-Forwards2047 value of zero (0) in the request (see <xref target="header.max-forwards"/>).2048 A TRACE request &MUST-NOT; include a message body.2049 </t>2050 <t>2051 TRACE allows the client to see what is being received at the other2052 end of the request chain and use that data for testing or diagnostic2053 information. The value of the Via header field (&header-via;) is of2054 particular interest, since it acts as a trace of the request chain.2055 Use of the Max-Forwards header field allows the client to limit the2056 length of the request chain, which is useful for testing a chain of2057 proxies forwarding messages in an infinite loop.2058 </t>2059 <t>2060 If the request is valid, the response &SHOULD; have a Content-Type of2061 "message/http" (see &media-type-message-http;) and contain a message body2062 that encloses a copy of the entire request message.2063 Responses to the TRACE method are not cacheable.2064 </t>2065 </section>2066 2067 <section title="CONNECT" anchor="CONNECT">2068 <iref primary="true" item="CONNECT method" x:for-anchor=""/>2069 <iref primary="true" item="Methods" subitem="CONNECT" x:for-anchor=""/>2070 <t>2071 The CONNECT method requests that the proxy establish a tunnel2072 to the request-target and, if successful, thereafter restrict its behavior2073 to blind forwarding of packets until the connection is closed.2074 </t>2075 <t>2076 When using CONNECT, the request-target &MUST; use the authority form2077 (&request-target;); i.e., the request-target consists of only the2078 host name and port number of the tunnel destination, separated by a colon.2079 For example,2080 </t>2081 <figure><artwork type="message/http; msgtype="request"" x:indent-with=" ">2082 CONNECT server.example.com:80 HTTP/1.12083 Host: server.example.com:802084 2085 </artwork></figure>2086 <t>2087 Any successful (2xx) response to a CONNECT request indicates that the2088 proxy has established a connection to the requested host and port,2089 and has switched to tunneling the current connection to that server2090 connection.2091 The tunneled data from the server begins immediately after the blank line2092 that concludes the successful response's header block.2093 A server &SHOULD-NOT; send any Transfer-Encoding or Content-Length2094 header fields in a successful response.2095 A client &MUST; ignore any Content-Length or Transfer-Encoding header2096 fields received in a successful response.2097 </t>2098 <t>2099 Any response other than a successful response indicates that the tunnel2100 has not yet been formed and that the connection remains governed by HTTP.2101 </t>2102 <t>2103 Proxy authentication might be used to establish the2104 authority to create a tunnel:2105 </t>2106 <figure><artwork type="message/http; msgtype="request"" x:indent-with=" ">2107 CONNECT server.example.com:80 HTTP/1.12108 Host: server.example.com:802109 Proxy-Authorization: basic aGVsbG86d29ybGQ=2110 2111 </artwork></figure>2112 <t>2113 A message body on a CONNECT request has no defined semantics. Sending a2114 body on a CONNECT request might cause existing implementations to reject2115 the request.2116 </t>2117 <t>2118 Similar to a pipelined HTTP/1.1 request, data to be tunneled from client2119 to server &MAY; be sent immediately after the request (before a response2120 is received). The usual caveats also apply:2121 data may be discarded if the eventual response is negative, and the2122 connection may be reset with no response if more than one TCP segment2123 is outstanding.2124 </t>2125 <t>2126 It may be the case that the proxy itself can only reach the requested2127 origin server through another proxy. In this case, the first proxy2128 &SHOULD; make a CONNECT request of that next proxy, requesting a tunnel2129 to the authority. A proxy &MUST-NOT; respond with any 2xx status code2130 unless it has either a direct or tunnel connection established to the2131 authority.2132 </t>2133 <t>2134 If at any point either one of the peers gets disconnected, any2135 outstanding data that came from that peer will be passed to the other2136 one, and after that also the other connection will be terminated by2137 the proxy. If there is outstanding data to that peer undelivered,2138 that data will be discarded.2139 </t>2140 <t>2141 An origin server which receives a CONNECT request for itself &MAY;2142 respond with a 2xx status code to indicate that a connection is2143 established. However, most origin servers do not implement CONNECT.2144 </t>2145 </section>2146 </section>2147 2148 2120 <section title="Common Protocol Parameters" anchor="common.protocol.parameters"> 2149 2121 <section title="Date/Time Formats" anchor="http.date"> … … 3679 3651 <section title="Changes from RFC 2616" anchor="changes.from.rfc.2616"> 3680 3652 <t> 3653 Clarify definition of POST. 3654 (<xref target="POST"/>) 3655 </t> 3656 <t> 3657 Remove requirement to handle all Content-* header fields; ban use of 3658 Content-Range with PUT. 3659 (<xref target="PUT"/>) 3660 </t> 3661 <t> 3662 Take over definition of CONNECT method from <xref target="RFC2817"/>. 3663 (<xref target="CONNECT"/>) 3664 </t> 3665 <t> 3681 3666 This document takes over the Status Code Registry, previously defined 3682 3667 in <xref target="RFC2817" x:fmt="of" x:sec="7.1"/>. … … 3714 3699 <xref target="RFC2817"/>). 3715 3700 (<xref target="status.426"/>) 3716 </t>3717 <t>3718 Clarify definition of POST.3719 (<xref target="POST"/>)3720 </t>3721 <t>3722 Remove requirement to handle all Content-* header fields; ban use of3723 Content-Range with PUT.3724 (<xref target="PUT"/>)3725 </t>3726 <t>3727 Take over definition of CONNECT method from <xref target="RFC2817"/>.3728 (<xref target="CONNECT"/>)3729 3701 </t> 3730 3702 <t>
Note: See TracChangeset
for help on using the changeset viewer.