Changeset 1618 for draft-ietf-httpbis
- Timestamp:
- 26/03/12 14:21:18 (10 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 2 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p2-semantics.html
r1617 r1618 488 488 <link rel="Chapter" title="5 Representation" href="#rfc.section.5"> 489 489 <link rel="Chapter" title="6 Method Definitions" href="#rfc.section.6"> 490 <link rel="Chapter" title="7 Status Code Definitions" href="#rfc.section.7"> 491 <link rel="Chapter" title="8 Common Protocol Parameters" href="#rfc.section.8"> 492 <link rel="Chapter" title="9 Header Field Definitions" href="#rfc.section.9"> 493 <link rel="Chapter" title="10 IANA Considerations" href="#rfc.section.10"> 494 <link rel="Chapter" title="11 Security Considerations" href="#rfc.section.11"> 495 <link rel="Chapter" title="12 Acknowledgments" href="#rfc.section.12"> 496 <link rel="Chapter" href="#rfc.section.13" title="13 References"> 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"> 497 496 <link rel="Appendix" title="A Changes from RFC 2616" href="#rfc.section.A"> 498 497 <link rel="Appendix" title="B Collected ABNF" href="#rfc.section.B"> … … 619 618 </ul> 620 619 </li> 620 <li>4.3 <a href="#status.codes">Status Code Definitions</a><ul> 621 <li>4.3.1 <a href="#status.1xx">Informational 1xx</a><ul> 622 <li>4.3.1.1 <a href="#status.100">100 Continue</a></li> 623 <li>4.3.1.2 <a href="#status.101">101 Switching Protocols</a></li> 624 </ul> 625 </li> 626 <li>4.3.2 <a href="#status.2xx">Successful 2xx</a><ul> 627 <li>4.3.2.1 <a href="#status.200">200 OK</a></li> 628 <li>4.3.2.2 <a href="#status.201">201 Created</a></li> 629 <li>4.3.2.3 <a href="#status.202">202 Accepted</a></li> 630 <li>4.3.2.4 <a href="#status.203">203 Non-Authoritative Information</a></li> 631 <li>4.3.2.5 <a href="#status.204">204 No Content</a></li> 632 <li>4.3.2.6 <a href="#status.205">205 Reset Content</a></li> 633 </ul> 634 </li> 635 <li>4.3.3 <a href="#status.3xx">Redirection 3xx</a><ul> 636 <li>4.3.3.1 <a href="#status.300">300 Multiple Choices</a></li> 637 <li>4.3.3.2 <a href="#status.301">301 Moved Permanently</a></li> 638 <li>4.3.3.3 <a href="#status.302">302 Found</a></li> 639 <li>4.3.3.4 <a href="#status.303">303 See Other</a></li> 640 <li>4.3.3.5 <a href="#status.305">305 Use Proxy</a></li> 641 <li>4.3.3.6 <a href="#status.306">306 (Unused)</a></li> 642 <li>4.3.3.7 <a href="#status.307">307 Temporary Redirect</a></li> 643 </ul> 644 </li> 645 <li>4.3.4 <a href="#status.4xx">Client Error 4xx</a><ul> 646 <li>4.3.4.1 <a href="#status.400">400 Bad Request</a></li> 647 <li>4.3.4.2 <a href="#status.402">402 Payment Required</a></li> 648 <li>4.3.4.3 <a href="#status.403">403 Forbidden</a></li> 649 <li>4.3.4.4 <a href="#status.404">404 Not Found</a></li> 650 <li>4.3.4.5 <a href="#status.405">405 Method Not Allowed</a></li> 651 <li>4.3.4.6 <a href="#status.406">406 Not Acceptable</a></li> 652 <li>4.3.4.7 <a href="#status.408">408 Request Timeout</a></li> 653 <li>4.3.4.8 <a href="#status.409">409 Conflict</a></li> 654 <li>4.3.4.9 <a href="#status.410">410 Gone</a></li> 655 <li>4.3.4.10 <a href="#status.411">411 Length Required</a></li> 656 <li>4.3.4.11 <a href="#status.413">413 Request Representation Too Large</a></li> 657 <li>4.3.4.12 <a href="#status.414">414 URI Too Long</a></li> 658 <li>4.3.4.13 <a href="#status.415">415 Unsupported Media Type</a></li> 659 <li>4.3.4.14 <a href="#status.417">417 Expectation Failed</a></li> 660 <li>4.3.4.15 <a href="#status.426">426 Upgrade Required</a></li> 661 </ul> 662 </li> 663 <li>4.3.5 <a href="#status.5xx">Server Error 5xx</a><ul> 664 <li>4.3.5.1 <a href="#status.500">500 Internal Server Error</a></li> 665 <li>4.3.5.2 <a href="#status.501">501 Not Implemented</a></li> 666 <li>4.3.5.3 <a href="#status.502">502 Bad Gateway</a></li> 667 <li>4.3.5.4 <a href="#status.503">503 Service Unavailable</a></li> 668 <li>4.3.5.5 <a href="#status.504">504 Gateway Timeout</a></li> 669 <li>4.3.5.6 <a href="#status.505">505 HTTP Version Not Supported</a></li> 670 </ul> 671 </li> 672 </ul> 673 </li> 621 674 </ul> 622 675 </li> … … 641 694 </ul> 642 695 </li> 643 <li>7. <a href="#status.codes">Status Code Definitions</a><ul> 644 <li>7.1 <a href="#status.1xx">Informational 1xx</a><ul> 645 <li>7.1.1 <a href="#status.100">100 Continue</a></li> 646 <li>7.1.2 <a href="#status.101">101 Switching Protocols</a></li> 647 </ul> 648 </li> 649 <li>7.2 <a href="#status.2xx">Successful 2xx</a><ul> 650 <li>7.2.1 <a href="#status.200">200 OK</a></li> 651 <li>7.2.2 <a href="#status.201">201 Created</a></li> 652 <li>7.2.3 <a href="#status.202">202 Accepted</a></li> 653 <li>7.2.4 <a href="#status.203">203 Non-Authoritative Information</a></li> 654 <li>7.2.5 <a href="#status.204">204 No Content</a></li> 655 <li>7.2.6 <a href="#status.205">205 Reset Content</a></li> 656 </ul> 657 </li> 658 <li>7.3 <a href="#status.3xx">Redirection 3xx</a><ul> 659 <li>7.3.1 <a href="#status.300">300 Multiple Choices</a></li> 660 <li>7.3.2 <a href="#status.301">301 Moved Permanently</a></li> 661 <li>7.3.3 <a href="#status.302">302 Found</a></li> 662 <li>7.3.4 <a href="#status.303">303 See Other</a></li> 663 <li>7.3.5 <a href="#status.305">305 Use Proxy</a></li> 664 <li>7.3.6 <a href="#status.306">306 (Unused)</a></li> 665 <li>7.3.7 <a href="#status.307">307 Temporary Redirect</a></li> 666 </ul> 667 </li> 668 <li>7.4 <a href="#status.4xx">Client Error 4xx</a><ul> 669 <li>7.4.1 <a href="#status.400">400 Bad Request</a></li> 670 <li>7.4.2 <a href="#status.402">402 Payment Required</a></li> 671 <li>7.4.3 <a href="#status.403">403 Forbidden</a></li> 672 <li>7.4.4 <a href="#status.404">404 Not Found</a></li> 673 <li>7.4.5 <a href="#status.405">405 Method Not Allowed</a></li> 674 <li>7.4.6 <a href="#status.406">406 Not Acceptable</a></li> 675 <li>7.4.7 <a href="#status.408">408 Request Timeout</a></li> 676 <li>7.4.8 <a href="#status.409">409 Conflict</a></li> 677 <li>7.4.9 <a href="#status.410">410 Gone</a></li> 678 <li>7.4.10 <a href="#status.411">411 Length Required</a></li> 679 <li>7.4.11 <a href="#status.413">413 Request Representation Too Large</a></li> 680 <li>7.4.12 <a href="#status.414">414 URI Too Long</a></li> 681 <li>7.4.13 <a href="#status.415">415 Unsupported Media Type</a></li> 682 <li>7.4.14 <a href="#status.417">417 Expectation Failed</a></li> 683 <li>7.4.15 <a href="#status.426">426 Upgrade Required</a></li> 684 </ul> 685 </li> 686 <li>7.5 <a href="#status.5xx">Server Error 5xx</a><ul> 687 <li>7.5.1 <a href="#status.500">500 Internal Server Error</a></li> 688 <li>7.5.2 <a href="#status.501">501 Not Implemented</a></li> 689 <li>7.5.3 <a href="#status.502">502 Bad Gateway</a></li> 690 <li>7.5.4 <a href="#status.503">503 Service Unavailable</a></li> 691 <li>7.5.5 <a href="#status.504">504 Gateway Timeout</a></li> 692 <li>7.5.6 <a href="#status.505">505 HTTP Version Not Supported</a></li> 693 </ul> 694 </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> 695 699 </ul> 696 700 </li> 697 <li>8. <a href="#common.protocol.parameters">Common Protocol Parameters</a><ul> 698 <li>8.1 <a href="#http.date">Date/Time Formats</a></li> 699 <li>8.2 <a href="#product.tokens">Product Tokens</a></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> 700 712 </ul> 701 713 </li> 702 <li>9. <a href="#header.field.definitions">Header Field Definitions</a><ul> 703 <li>9.1 <a href="#header.allow">Allow</a></li> 704 <li>9.2 <a href="#header.date">Date</a></li> 705 <li>9.3 <a href="#header.expect">Expect</a></li> 706 <li>9.4 <a href="#header.from">From</a></li> 707 <li>9.5 <a href="#header.location">Location</a></li> 708 <li>9.6 <a href="#header.max-forwards">Max-Forwards</a></li> 709 <li>9.7 <a href="#header.referer">Referer</a></li> 710 <li>9.8 <a href="#header.retry-after">Retry-After</a></li> 711 <li>9.9 <a href="#header.server">Server</a></li> 712 <li>9.10 <a href="#header.user-agent">User-Agent</a></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> 713 718 </ul> 714 719 </li> 715 <li>10. <a href="#IANA.considerations">IANA Considerations</a><ul> 716 <li>10.1 <a href="#method.registration">Method Registry</a></li> 717 <li>10.2 <a href="#status.code.registration">Status Code Registry</a></li> 718 <li>10.3 <a href="#header.field.registration">Header Field Registration</a></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> 719 725 </ul> 720 726 </li> 721 <li>11. <a href="#security.considerations">Security Considerations</a><ul> 722 <li>11.1 <a href="#security.sensitive">Transfer of Sensitive Information</a></li> 723 <li>11.2 <a href="#encoding.sensitive.information.in.uris">Encoding Sensitive Information in URIs</a></li> 724 <li>11.3 <a href="#location.spoofing-leakage">Location Header Fields: Spoofing and Information Leakage</a></li> 725 <li>11.4 <a href="#rfc.section.11.4">Security Considerations for CONNECT</a></li> 726 </ul> 727 </li> 728 <li>12. <a href="#acks">Acknowledgments</a></li> 729 <li>13. <a href="#rfc.references">References</a><ul> 730 <li>13.1 <a href="#rfc.references.1">Normative References</a></li> 731 <li>13.2 <a href="#rfc.references.2">Informative References</a></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> 732 731 </ul> 733 732 </li> … … 817 816 </p> 818 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> 819 </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 9.1</a>). The status code of the response always notifies the client whether a method is currently allowed on a resource, since the818 </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 the 820 819 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 821 820 resource, and 501 (Not Implemented) if the method is unrecognized or not implemented by the origin server. The methods GET … … 1003 1002 <tr> 1004 1003 <td class="left">Expect</td> 1005 <td class="left"><a href="#header.expect" id="rfc.xref.header.expect.1" title="Expect">Section 9.3</a></td>1004 <td class="left"><a href="#header.expect" id="rfc.xref.header.expect.1" title="Expect">Section 8.3</a></td> 1006 1005 </tr> 1007 1006 <tr> 1008 1007 <td class="left">From</td> 1009 <td class="left"><a href="#header.from" id="rfc.xref.header.from.1" title="From">Section 9.4</a></td>1008 <td class="left"><a href="#header.from" id="rfc.xref.header.from.1" title="From">Section 8.4</a></td> 1010 1009 </tr> 1011 1010 <tr> … … 1035 1034 <tr> 1036 1035 <td class="left">Max-Forwards</td> 1037 <td class="left"><a href="#header.max-forwards" id="rfc.xref.header.max-forwards.1" title="Max-Forwards">Section 9.6</a></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> 1038 1037 </tr> 1039 1038 <tr> … … 1047 1046 <tr> 1048 1047 <td class="left">Referer</td> 1049 <td class="left"><a href="#header.referer" id="rfc.xref.header.referer.1" title="Referer">Section 9.7</a></td>1048 <td class="left"><a href="#header.referer" id="rfc.xref.header.referer.1" title="Referer">Section 8.7</a></td> 1050 1049 </tr> 1051 1050 <tr> … … 1055 1054 <tr> 1056 1055 <td class="left">User-Agent</td> 1057 <td class="left"><a href="#header.user-agent" id="rfc.xref.header.user-agent.1" title="User-Agent">Section 9.10</a></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> 1058 1057 </tr> 1059 1058 </tbody> … … 1083 1082 <tr> 1084 1083 <td class="left">Allow</td> 1085 <td class="left"><a href="#header.allow" id="rfc.xref.header.allow.2" title="Allow">Section 9.1</a></td>1084 <td class="left"><a href="#header.allow" id="rfc.xref.header.allow.2" title="Allow">Section 8.1</a></td> 1086 1085 </tr> 1087 1086 <tr> 1088 1087 <td class="left">Date</td> 1089 <td class="left"><a href="#header.date" id="rfc.xref.header.date.1" title="Date">Section 9.2</a></td>1088 <td class="left"><a href="#header.date" id="rfc.xref.header.date.1" title="Date">Section 8.2</a></td> 1090 1089 </tr> 1091 1090 <tr> … … 1095 1094 <tr> 1096 1095 <td class="left">Location</td> 1097 <td class="left"><a href="#header.location" id="rfc.xref.header.location.1" title="Location">Section 9.5</a></td>1096 <td class="left"><a href="#header.location" id="rfc.xref.header.location.1" title="Location">Section 8.5</a></td> 1098 1097 </tr> 1099 1098 <tr> … … 1103 1102 <tr> 1104 1103 <td class="left">Retry-After</td> 1105 <td class="left"><a href="#header.retry-after" id="rfc.xref.header.retry-after.1" title="Retry-After">Section 9.8</a></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> 1106 1105 </tr> 1107 1106 <tr> 1108 1107 <td class="left">Server</td> 1109 <td class="left"><a href="#header.server" id="rfc.xref.header.server.1" title="Server">Section 9.9</a></td>1108 <td class="left"><a href="#header.server" id="rfc.xref.header.server.1" title="Server">Section 8.9</a></td> 1110 1109 </tr> 1111 1110 <tr> … … 1133 1132 information which will explain the unusual status. 1134 1133 </p> 1134 <p id="rfc.section.4.p.5">The first digit of the status-code defines the class of response. The last two digits do not have any categorization role. 1135 There are 5 values for the first digit: 1136 </p> 1137 <ul> 1138 <li>1xx: Informational - Request received, continuing process</li> 1139 <li>2xx: Success - The action was successfully received, understood, and accepted</li> 1140 <li>3xx: Redirection - Further action needs to be taken in order to complete the request</li> 1141 <li>4xx: Client Error - The request contains bad syntax or cannot be fulfilled</li> 1142 <li>5xx: Server Error - The server failed to fulfill an apparently valid request</li> 1143 </ul> 1135 1144 <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> 1136 <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 7</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 the1145 <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 the 1137 1146 protocol. 1138 1147 </p> … … 1150 1159 <td class="left">100</td> 1151 1160 <td class="left">Continue</td> 1152 <td class="left"><a href="#status.100" id="rfc.xref.status.100.1" title="100 Continue">Section 7.1.1</a></td>1161 <td class="left"><a href="#status.100" id="rfc.xref.status.100.1" title="100 Continue">Section 4.3.1.1</a></td> 1153 1162 </tr> 1154 1163 <tr> 1155 1164 <td class="left">101</td> 1156 1165 <td class="left">Switching Protocols</td> 1157 <td class="left"><a href="#status.101" id="rfc.xref.status.101.1" title="101 Switching Protocols">Section 7.1.2</a></td>1166 <td class="left"><a href="#status.101" id="rfc.xref.status.101.1" title="101 Switching Protocols">Section 4.3.1.2</a></td> 1158 1167 </tr> 1159 1168 <tr> 1160 1169 <td class="left">200</td> 1161 1170 <td class="left">OK</td> 1162 <td class="left"><a href="#status.200" id="rfc.xref.status.200.1" title="200 OK">Section 7.2.1</a></td>1171 <td class="left"><a href="#status.200" id="rfc.xref.status.200.1" title="200 OK">Section 4.3.2.1</a></td> 1163 1172 </tr> 1164 1173 <tr> 1165 1174 <td class="left">201</td> 1166 1175 <td class="left">Created</td> 1167 <td class="left"><a href="#status.201" id="rfc.xref.status.201.1" title="201 Created">Section 7.2.2</a></td>1176 <td class="left"><a href="#status.201" id="rfc.xref.status.201.1" title="201 Created">Section 4.3.2.2</a></td> 1168 1177 </tr> 1169 1178 <tr> 1170 1179 <td class="left">202</td> 1171 1180 <td class="left">Accepted</td> 1172 <td class="left"><a href="#status.202" id="rfc.xref.status.202.1" title="202 Accepted">Section 7.2.3</a></td>1181 <td class="left"><a href="#status.202" id="rfc.xref.status.202.1" title="202 Accepted">Section 4.3.2.3</a></td> 1173 1182 </tr> 1174 1183 <tr> 1175 1184 <td class="left">203</td> 1176 1185 <td class="left">Non-Authoritative Information</td> 1177 <td class="left"><a href="#status.203" id="rfc.xref.status.203.1" title="203 Non-Authoritative Information">Section 7.2.4</a></td>1186 <td class="left"><a href="#status.203" id="rfc.xref.status.203.1" title="203 Non-Authoritative Information">Section 4.3.2.4</a></td> 1178 1187 </tr> 1179 1188 <tr> 1180 1189 <td class="left">204</td> 1181 1190 <td class="left">No Content</td> 1182 <td class="left"><a href="#status.204" id="rfc.xref.status.204.1" title="204 No Content">Section 7.2.5</a></td>1191 <td class="left"><a href="#status.204" id="rfc.xref.status.204.1" title="204 No Content">Section 4.3.2.5</a></td> 1183 1192 </tr> 1184 1193 <tr> 1185 1194 <td class="left">205</td> 1186 1195 <td class="left">Reset Content</td> 1187 <td class="left"><a href="#status.205" id="rfc.xref.status.205.1" title="205 Reset Content">Section 7.2.6</a></td>1196 <td class="left"><a href="#status.205" id="rfc.xref.status.205.1" title="205 Reset Content">Section 4.3.2.6</a></td> 1188 1197 </tr> 1189 1198 <tr> … … 1195 1204 <td class="left">300</td> 1196 1205 <td class="left">Multiple Choices</td> 1197 <td class="left"><a href="#status.300" id="rfc.xref.status.300.1" title="300 Multiple Choices">Section 7.3.1</a></td>1206 <td class="left"><a href="#status.300" id="rfc.xref.status.300.1" title="300 Multiple Choices">Section 4.3.3.1</a></td> 1198 1207 </tr> 1199 1208 <tr> 1200 1209 <td class="left">301</td> 1201 1210 <td class="left">Moved Permanently</td> 1202 <td class="left"><a href="#status.301" id="rfc.xref.status.301.1" title="301 Moved Permanently">Section 7.3.2</a></td>1211 <td class="left"><a href="#status.301" id="rfc.xref.status.301.1" title="301 Moved Permanently">Section 4.3.3.2</a></td> 1203 1212 </tr> 1204 1213 <tr> 1205 1214 <td class="left">302</td> 1206 1215 <td class="left">Found</td> 1207 <td class="left"><a href="#status.302" id="rfc.xref.status.302.1" title="302 Found">Section 7.3.3</a></td>1216 <td class="left"><a href="#status.302" id="rfc.xref.status.302.1" title="302 Found">Section 4.3.3.3</a></td> 1208 1217 </tr> 1209 1218 <tr> 1210 1219 <td class="left">303</td> 1211 1220 <td class="left">See Other</td> 1212 <td class="left"><a href="#status.303" id="rfc.xref.status.303.1" title="303 See Other">Section 7.3.4</a></td>1221 <td class="left"><a href="#status.303" id="rfc.xref.status.303.1" title="303 See Other">Section 4.3.3.4</a></td> 1213 1222 </tr> 1214 1223 <tr> … … 1220 1229 <td class="left">305</td> 1221 1230 <td class="left">Use Proxy</td> 1222 <td class="left"><a href="#status.305" id="rfc.xref.status.305.1" title="305 Use Proxy">Section 7.3.5</a></td>1231 <td class="left"><a href="#status.305" id="rfc.xref.status.305.1" title="305 Use Proxy">Section 4.3.3.5</a></td> 1223 1232 </tr> 1224 1233 <tr> 1225 1234 <td class="left">307</td> 1226 1235 <td class="left">Temporary Redirect</td> 1227 <td class="left"><a href="#status.307" id="rfc.xref.status.307.1" title="307 Temporary Redirect">Section 7.3.7</a></td>1236 <td class="left"><a href="#status.307" id="rfc.xref.status.307.1" title="307 Temporary Redirect">Section 4.3.3.7</a></td> 1228 1237 </tr> 1229 1238 <tr> 1230 1239 <td class="left">400</td> 1231 1240 <td class="left">Bad Request</td> 1232 <td class="left"><a href="#status.400" id="rfc.xref.status.400.1" title="400 Bad Request">Section 7.4.1</a></td>1241 <td class="left"><a href="#status.400" id="rfc.xref.status.400.1" title="400 Bad Request">Section 4.3.4.1</a></td> 1233 1242 </tr> 1234 1243 <tr> … … 1240 1249 <td class="left">402</td> 1241 1250 <td class="left">Payment Required</td> 1242 <td class="left"><a href="#status.402" id="rfc.xref.status.402.1" title="402 Payment Required">Section 7.4.2</a></td>1251 <td class="left"><a href="#status.402" id="rfc.xref.status.402.1" title="402 Payment Required">Section 4.3.4.2</a></td> 1243 1252 </tr> 1244 1253 <tr> 1245 1254 <td class="left">403</td> 1246 1255 <td class="left">Forbidden</td> 1247 <td class="left"><a href="#status.403" id="rfc.xref.status.403.1" title="403 Forbidden">Section 7.4.3</a></td>1256 <td class="left"><a href="#status.403" id="rfc.xref.status.403.1" title="403 Forbidden">Section 4.3.4.3</a></td> 1248 1257 </tr> 1249 1258 <tr> 1250 1259 <td class="left">404</td> 1251 1260 <td class="left">Not Found</td> 1252 <td class="left"><a href="#status.404" id="rfc.xref.status.404.1" title="404 Not Found">Section 7.4.4</a></td>1261 <td class="left"><a href="#status.404" id="rfc.xref.status.404.1" title="404 Not Found">Section 4.3.4.4</a></td> 1253 1262 </tr> 1254 1263 <tr> 1255 1264 <td class="left">405</td> 1256 1265 <td class="left">Method Not Allowed</td> 1257 <td class="left"><a href="#status.405" id="rfc.xref.status.405.1" title="405 Method Not Allowed">Section 7.4.5</a></td>1266 <td class="left"><a href="#status.405" id="rfc.xref.status.405.1" title="405 Method Not Allowed">Section 4.3.4.5</a></td> 1258 1267 </tr> 1259 1268 <tr> 1260 1269 <td class="left">406</td> 1261 1270 <td class="left">Not Acceptable</td> 1262 <td class="left"><a href="#status.406" id="rfc.xref.status.406.1" title="406 Not Acceptable">Section 7.4.6</a></td>1271 <td class="left"><a href="#status.406" id="rfc.xref.status.406.1" title="406 Not Acceptable">Section 4.3.4.6</a></td> 1263 1272 </tr> 1264 1273 <tr> … … 1270 1279 <td class="left">408</td> 1271 1280 <td class="left">Request Time-out</td> 1272 <td class="left"><a href="#status.408" id="rfc.xref.status.408.1" title="408 Request Timeout">Section 7.4.7</a></td>1281 <td class="left"><a href="#status.408" id="rfc.xref.status.408.1" title="408 Request Timeout">Section 4.3.4.7</a></td> 1273 1282 </tr> 1274 1283 <tr> 1275 1284 <td class="left">409</td> 1276 1285 <td class="left">Conflict</td> 1277 <td class="left"><a href="#status.409" id="rfc.xref.status.409.1" title="409 Conflict">Section 7.4.8</a></td>1286 <td class="left"><a href="#status.409" id="rfc.xref.status.409.1" title="409 Conflict">Section 4.3.4.8</a></td> 1278 1287 </tr> 1279 1288 <tr> 1280 1289 <td class="left">410</td> 1281 1290 <td class="left">Gone</td> 1282 <td class="left"><a href="#status.410" id="rfc.xref.status.410.1" title="410 Gone">Section 7.4.9</a></td>1291 <td class="left"><a href="#status.410" id="rfc.xref.status.410.1" title="410 Gone">Section 4.3.4.9</a></td> 1283 1292 </tr> 1284 1293 <tr> 1285 1294 <td class="left">411</td> 1286 1295 <td class="left">Length Required</td> 1287 <td class="left"><a href="#status.411" id="rfc.xref.status.411.1" title="411 Length Required">Section 7.4.10</a></td>1296 <td class="left"><a href="#status.411" id="rfc.xref.status.411.1" title="411 Length Required">Section 4.3.4.10</a></td> 1288 1297 </tr> 1289 1298 <tr> … … 1295 1304 <td class="left">413</td> 1296 1305 <td class="left">Request Representation Too Large</td> 1297 <td class="left"><a href="#status.413" id="rfc.xref.status.413.1" title="413 Request Representation Too Large">Section 7.4.11</a></td>1306 <td class="left"><a href="#status.413" id="rfc.xref.status.413.1" title="413 Request Representation Too Large">Section 4.3.4.11</a></td> 1298 1307 </tr> 1299 1308 <tr> 1300 1309 <td class="left">414</td> 1301 1310 <td class="left">URI Too Long</td> 1302 <td class="left"><a href="#status.414" id="rfc.xref.status.414.1" title="414 URI Too Long">Section 7.4.12</a></td>1311 <td class="left"><a href="#status.414" id="rfc.xref.status.414.1" title="414 URI Too Long">Section 4.3.4.12</a></td> 1303 1312 </tr> 1304 1313 <tr> 1305 1314 <td class="left">415</td> 1306 1315 <td class="left">Unsupported Media Type</td> 1307 <td class="left"><a href="#status.415" id="rfc.xref.status.415.1" title="415 Unsupported Media Type">Section 7.4.13</a></td>1316 <td class="left"><a href="#status.415" id="rfc.xref.status.415.1" title="415 Unsupported Media Type">Section 4.3.4.13</a></td> 1308 1317 </tr> 1309 1318 <tr> … … 1315 1324 <td class="left">417</td> 1316 1325 <td class="left">Expectation Failed</td> 1317 <td class="left"><a href="#status.417" id="rfc.xref.status.417.1" title="417 Expectation Failed">Section 7.4.14</a></td>1326 <td class="left"><a href="#status.417" id="rfc.xref.status.417.1" title="417 Expectation Failed">Section 4.3.4.14</a></td> 1318 1327 </tr> 1319 1328 <tr> 1320 1329 <td class="left">426</td> 1321 1330 <td class="left">Upgrade Required</td> 1322 <td class="left"><a href="#status.426" id="rfc.xref.status.426.1" title="426 Upgrade Required">Section 7.4.15</a></td>1331 <td class="left"><a href="#status.426" id="rfc.xref.status.426.1" title="426 Upgrade Required">Section 4.3.4.15</a></td> 1323 1332 </tr> 1324 1333 <tr> 1325 1334 <td class="left">500</td> 1326 1335 <td class="left">Internal Server Error</td> 1327 <td class="left"><a href="#status.500" id="rfc.xref.status.500.1" title="500 Internal Server Error">Section 7.5.1</a></td>1336 <td class="left"><a href="#status.500" id="rfc.xref.status.500.1" title="500 Internal Server Error">Section 4.3.5.1</a></td> 1328 1337 </tr> 1329 1338 <tr> 1330 1339 <td class="left">501</td> 1331 1340 <td class="left">Not Implemented</td> 1332 <td class="left"><a href="#status.501" id="rfc.xref.status.501.1" title="501 Not Implemented">Section 7.5.2</a></td>1341 <td class="left"><a href="#status.501" id="rfc.xref.status.501.1" title="501 Not Implemented">Section 4.3.5.2</a></td> 1333 1342 </tr> 1334 1343 <tr> 1335 1344 <td class="left">502</td> 1336 1345 <td class="left">Bad Gateway</td> 1337 <td class="left"><a href="#status.502" id="rfc.xref.status.502.1" title="502 Bad Gateway">Section 7.5.3</a></td>1346 <td class="left"><a href="#status.502" id="rfc.xref.status.502.1" title="502 Bad Gateway">Section 4.3.5.3</a></td> 1338 1347 </tr> 1339 1348 <tr> 1340 1349 <td class="left">503</td> 1341 1350 <td class="left">Service Unavailable</td> 1342 <td class="left"><a href="#status.503" id="rfc.xref.status.503.1" title="503 Service Unavailable">Section 7.5.4</a></td>1351 <td class="left"><a href="#status.503" id="rfc.xref.status.503.1" title="503 Service Unavailable">Section 4.3.5.4</a></td> 1343 1352 </tr> 1344 1353 <tr> 1345 1354 <td class="left">504</td> 1346 1355 <td class="left">Gateway Time-out</td> 1347 <td class="left"><a href="#status.504" id="rfc.xref.status.504.1" title="504 Gateway Timeout">Section 7.5.5</a></td>1356 <td class="left"><a href="#status.504" id="rfc.xref.status.504.1" title="504 Gateway Timeout">Section 4.3.5.5</a></td> 1348 1357 </tr> 1349 1358 <tr> 1350 1359 <td class="left">505</td> 1351 1360 <td class="left">HTTP Version not supported</td> 1352 <td class="left"><a href="#status.505" id="rfc.xref.status.505.1" title="505 HTTP Version Not Supported">Section 7.5.6</a></td>1361 <td class="left"><a href="#status.505" id="rfc.xref.status.505.1" title="505 HTTP Version Not Supported">Section 4.3.5.6</a></td> 1353 1362 </tr> 1354 1363 </tbody> … … 1374 1383 that are required, those that modify the semantics of the response). 1375 1384 </p> 1376 <p id="rfc.section.4.2.1.p.4">New HTTP status codes are required to fall under one of the categories defined in <a href="#status.codes" title="Status Code Definitions">Section 7</a>. To allow existing parsers to properly handle them, new status codes cannot disallow a response body, although they can mandate1385 <p id="rfc.section.4.2.1.p.4">New HTTP status codes are required to fall under one of the categories defined in <a href="#status.codes" title="Status Code Definitions">Section 4.3</a>. To allow existing parsers to properly handle them, new status codes cannot disallow a response body, although they can mandate 1377 1386 a zero-length response body. They can require the presence of one or more particular HTTP response header(s). 1378 1387 </p> 1379 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). 1380 1389 </p> 1381 <h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a> <a id="representation" href="#representation">Representation</a></h1> 1382 <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 1383 of metadata (representation header fields) and data (representation body). When a complete or partial representation is enclosed 1384 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.7"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>. 1385 </p> 1386 <p id="rfc.section.5.p.2">A representation body is only present in a message when a message body is present, as described in <a href="p1-messaging.html#message.body" title="Message Body">Section 3.3</a> of <a href="#Part1" id="rfc.xref.Part1.26"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. The representation body is obtained from the message body by decoding any Transfer-Encoding that might have been applied 1387 to ensure safe and proper transfer of the message. 1388 </p> 1389 <h2 id="rfc.section.5.1"><a href="#rfc.section.5.1">5.1</a> <a id="identifying.response.associated.with.representation" href="#identifying.response.associated.with.representation">Identifying the Resource Associated with a Representation</a></h2> 1390 <p id="rfc.section.5.1.p.1">It is sometimes necessary to determine an identifier for the resource associated with a representation.</p> 1391 <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> 1392 <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.27"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). However, this is not always the case. To determine the URI of the resource a response is associated with, the following 1393 rules are used (with the first applicable one being selected): 1394 </p> 1395 <ol> 1396 <li>If the response status code is 200 or 203 and the request method was GET, the response payload is a representation of the 1397 target resource. 1398 </li> 1399 <li>If the response status code is 204, 206, or 304 and the request method was GET or HEAD, the response payload is a partial 1400 representation of the target resource. 1401 </li> 1402 <li>If the response has a Content-Location header field, and that URI is the same as the effective request URI, the response payload 1403 is a representation of the target resource. 1404 </li> 1405 <li>If the response has a Content-Location header field, and that URI is not the same as the effective request URI, then the response 1406 asserts that its payload is a representation of the resource identified by the Content-Location URI. However, such an assertion 1407 cannot be trusted unless it can be verified by other means (not defined by HTTP). 1408 </li> 1409 <li>Otherwise, the response is a representation of an anonymous (i.e., unidentified) resource.</li> 1410 </ol> 1411 <p id="rfc.section.5.1.p.5"> <span class="comment" id="TODO-req-uri">[<a href="#TODO-req-uri" class="smpl">TODO-req-uri</a>: The comparison function is going to have to be defined somewhere, because we already need to compare URIs for things like 1412 cache invalidation.]</span> 1413 </p> 1414 <h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a> <a id="method.definitions" href="#method.definitions">Method Definitions</a></h1> 1415 <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 1416 be assumed to share the same semantics for separately extended clients and servers. 1417 </p> 1418 <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> 1419 <div id="rfc.iref.s.1"></div> 1420 <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> 1421 <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 1422 the user to be aware of any actions they take which might have an unexpected significance to themselves or others. 1423 </p> 1424 <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 1425 made aware of the fact that a possibly unsafe action is being requested. 1426 </p> 1427 <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; 1428 in fact, some dynamic resources consider that a feature. The important distinction here is that the user did not request the 1429 side-effects, so therefore cannot be held accountable for them. 1430 </p> 1431 <div id="rfc.iref.i.1"></div> 1432 <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> 1433 <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 1434 of multiple identical requests is the same as for a single request. PUT, DELETE, and all safe request methods are idempotent. 1435 It is important to note that idempotence refers only to changes requested by the client: a server is free to change its state 1436 due to multiple requests for the purpose of tracking those requests, versioning of results, etc. 1437 </p> 1438 <h2 id="rfc.section.6.2"><a href="#rfc.section.6.2">6.2</a> <a id="OPTIONS" href="#OPTIONS">OPTIONS</a></h2> 1439 <div id="rfc.iref.o.1"></div> 1440 <div id="rfc.iref.m.1"></div> 1441 <p id="rfc.section.6.2.p.1">The OPTIONS method requests information about the communication options available on the request/response chain identified 1442 by the effective request URI. This method allows a client to determine the options and/or requirements associated with a resource, 1443 or the capabilities of a server, without implying a resource action or initiating a resource retrieval. 1444 </p> 1445 <p id="rfc.section.6.2.p.2">Responses to the OPTIONS method are not cacheable.</p> 1446 <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 1447 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 1448 to HTTP might use the OPTIONS body to make more detailed queries on the server. 1449 </p> 1450 <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.28"><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. 1451 Since a server's communication options typically depend on the resource, the "*" request is only useful as a "ping" or "no-op" 1452 type of method; it does nothing beyond allowing the client to test the capabilities of the server. For example, this can be 1453 used to test a proxy for HTTP/1.1 conformance (or lack thereof). 1454 </p> 1455 <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 1456 with that resource. 1457 </p> 1458 <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., 1459 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, 1460 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". 1461 </p> 1462 <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 9.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. 1463 </p> 1464 <h2 id="rfc.section.6.3"><a href="#rfc.section.6.3">6.3</a> <a id="GET" href="#GET">GET</a></h2> 1465 <div id="rfc.iref.g.5"></div> 1466 <div id="rfc.iref.m.2"></div> 1467 <p id="rfc.section.6.3.p.1">The GET method requests transfer of a current representation of the target resource.</p> 1468 <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 1469 in the response and not the source text of the process, unless that text happens to be the output of the process. 1470 </p> 1471 <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, 1472 If-Match, If-None-Match, or If-Range header field. A conditional GET requests that the representation be transferred only 1473 under the circumstances described by the conditional header field(s). The conditional GET request is intended to reduce unnecessary 1474 network usage by allowing cached representations to be refreshed without requiring multiple requests or transferring data 1475 already held by the client. 1476 </p> 1477 <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 1478 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 1479 to be completed without transferring data already held by the client. 1480 </p> 1481 <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 1482 to reject the request. 1483 </p> 1484 <p id="rfc.section.6.3.p.6">The response to a GET request is cacheable and <em class="bcp14">MAY</em> be used to satisfy subsequent GET and HEAD requests (see <a href="#Part6" id="rfc.xref.Part6.6"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>). 1485 </p> 1486 <p id="rfc.section.6.3.p.7">See <a href="#encoding.sensitive.information.in.uris" title="Encoding Sensitive Information in URIs">Section 11.2</a> for security considerations when used for forms. 1487 </p> 1488 <h2 id="rfc.section.6.4"><a href="#rfc.section.6.4">6.4</a> <a id="HEAD" href="#HEAD">HEAD</a></h2> 1489 <div id="rfc.iref.h.1"></div> 1490 <div id="rfc.iref.m.3"></div> 1491 <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 1492 representation implied by the request without transferring the representation body. This method is often used for testing 1493 hypertext links for validity, accessibility, and recent modification. 1494 </p> 1495 <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.7"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>. 1496 </p> 1497 <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 1498 to reject the request. 1499 </p> 1500 <div id="rfc.iref.p.1"></div> 1501 <div id="rfc.iref.m.4"></div> 1502 <h2 id="rfc.section.6.5"><a href="#rfc.section.6.5">6.5</a> <a id="POST" href="#POST">POST</a></h2> 1503 <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 1504 by the target resource. POST is designed to allow a uniform method to cover the following functions: 1505 </p> 1506 <ul> 1507 <li>Annotation of existing resources;</li> 1508 <li>Posting a message to a bulletin board, newsgroup, mailing list, or similar group of articles;</li> 1509 <li>Providing a block of data, such as the result of submitting a form, to a data-handling process;</li> 1510 <li>Extending a database through an append operation.</li> 1511 </ul> 1512 <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 1513 URI. 1514 </p> 1515 <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 1516 200 (OK) or 204 (No Content) is the appropriate response status code, depending on whether or not the response includes a 1517 representation that describes the result. 1518 </p> 1519 <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 1520 a Location header field (see <a href="#header.location" id="rfc.xref.header.location.2" title="Location">Section 9.5</a>). 1521 </p> 1522 <p id="rfc.section.6.5.p.5">Responses to POST requests are only cacheable when they include explicit freshness information (see <a href="p6-cache.html#calculating.freshness.lifetime" title="Calculating Freshness Lifetime">Section 2.3.1</a> of <a href="#Part6" id="rfc.xref.Part6.8"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>). A cached POST response with a Content-Location header field (see <a href="p3-payload.html#header.content-location" title="Content-Location">Section 6.7</a> of <a href="#Part3" id="rfc.xref.Part3.8"><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. 1523 </p> 1524 <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 1525 to retrieve a cacheable representation of the resource. 1526 </p> 1527 <div id="rfc.iref.p.2"></div> 1528 <div id="rfc.iref.m.5"></div> 1529 <h2 id="rfc.section.6.6"><a href="#rfc.section.6.6">6.6</a> <a id="PUT" href="#PUT">PUT</a></h2> 1530 <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 1531 enclosed in the request message payload. A successful PUT of a given representation would suggest that a subsequent GET on 1532 that same target resource will result in an equivalent representation being returned in a 200 (OK) response. However, there 1533 is no guarantee that such a state change will be observable, since the target resource might be acted upon by other user agents 1534 in parallel, or might be subject to dynamic processing by the origin server, before any subsequent GET is received. A successful 1535 response only implies that the user agent's intent was achieved at the time of its processing by the origin server. 1536 </p> 1537 <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 1538 representation is successfully modified in accordance with the state of the enclosed representation, then either a 200 (OK) 1539 or 204 (No Content) response <em class="bcp14">SHOULD</em> be sent to indicate successful completion of the request. 1540 </p> 1541 <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). 1542 </p> 1543 <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 1544 or will not be changed by the PUT. This is particularly important when the origin server uses internal configuration information 1545 related to the URI in order to set the values for representation metadata on GET responses. When a PUT representation is inconsistent 1546 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 1547 appropriate error message containing sufficient information to explain why the representation is unsuitable. The 409 (Conflict) 1548 or 415 (Unsupported Media Type) status codes are suggested, with the latter being specific to constraints on Content-Type 1549 values. 1550 </p> 1551 <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 1552 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 1553 consistent with that of the resource before saving it as the new resource state; or, (c) reject the request with a 415 response 1554 indicating that the target resource is limited to "text/html", perhaps including a link to a different resource that would 1555 be a suitable target for the new representation. 1556 </p> 1557 <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 1558 of the user agent request and the semantics of the origin server response. It does not define what a resource might be, in 1559 any sense of that word, beyond the interface provided via HTTP. It does not define how resource state is "stored", nor how 1560 such storage might change as a result of a change in resource state, nor how the origin server translates resource state into 1561 representations. Generally speaking, all implementation details behind the resource interface are intentionally hidden by 1562 the server. 1563 </p> 1564 <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. 1565 The target resource in a POST request is intended to handle the enclosed representation as a data-accepting process, such 1566 as for a gateway to some other protocol or a document that accepts annotations. In contrast, the target resource in a PUT 1567 request is intended to take the enclosed representation as a new or replacement value. Hence, the intent of PUT is idempotent 1568 and visible to intermediaries, even though the exact effect is only known by the origin server. 1569 </p> 1570 <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 1571 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 1572 the target resource and instead wishes to have it applied to a different resource, such as when the resource has been moved 1573 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. 1574 </p> 1575 <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) 1576 which is separate from the URIs identifying each particular version (different resources that at one point shared the same 1577 state as the current version resource). A successful PUT request on "the current version" URI might therefore create a new 1578 version resource in addition to changing the state of the target resource, and might also cause links to be added between 1579 the related resources. 1580 </p> 1581 <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 1582 might be partial content that is being mistakenly PUT as a full representation). Partial content updates are possible by targeting 1583 a separately identified resource with state that overlaps a portion of the larger resource, or by using a different method 1584 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>). 1585 </p> 1586 <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 1587 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.9"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>). 1588 </p> 1589 <div id="rfc.iref.d.1"></div> 1590 <div id="rfc.iref.m.6"></div> 1591 <h2 id="rfc.section.6.7"><a href="#rfc.section.6.7">6.7</a> <a id="DELETE" href="#DELETE">DELETE</a></h2> 1592 <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 1593 has been carried out, even if the status code returned from the origin server indicates that the action has been completed 1594 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 1595 location. 1596 </p> 1597 <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 1598 enacted, or 204 (No Content) if the action has been enacted but the response does not include a representation. 1599 </p> 1600 <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 1601 implementations to reject the request. 1602 </p> 1603 <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 1604 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.10"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>). 1605 </p> 1606 <h2 id="rfc.section.6.8"><a href="#rfc.section.6.8">6.8</a> <a id="TRACE" href="#TRACE">TRACE</a></h2> 1607 <div id="rfc.iref.t.1"></div> 1608 <div id="rfc.iref.m.7"></div> 1609 <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 1610 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 9.6</a>). A TRACE request <em class="bcp14">MUST NOT</em> include a message body. 1611 </p> 1612 <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 1613 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.29"><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 1614 client to limit the length of the request chain, which is useful for testing a chain of proxies forwarding messages in an 1615 infinite loop. 1616 </p> 1617 <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.30"><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. 1618 </p> 1619 <div id="rfc.iref.c.1"></div> 1620 <div id="rfc.iref.m.8"></div> 1621 <h2 id="rfc.section.6.9"><a href="#rfc.section.6.9">6.9</a> <a id="CONNECT" href="#CONNECT">CONNECT</a></h2> 1622 <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 1623 its behavior to blind forwarding of packets until the connection is closed. 1624 </p> 1625 <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.31"><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. 1626 For example, 1627 </p> 1628 <div id="rfc.figure.u.6"></div><pre class="text2">CONNECT server.example.com:80 HTTP/1.1 1629 Host: server.example.com:80 1630 1631 </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 1632 host and port, and has switched to tunneling the current connection to that server connection. The tunneled data from the 1633 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. 1634 </p> 1635 <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 1636 governed by HTTP. 1637 </p> 1638 <p id="rfc.section.6.9.p.6">Proxy authentication might be used to establish the authority to create a tunnel:</p> 1639 <div id="rfc.figure.u.7"></div><pre class="text2">CONNECT server.example.com:80 HTTP/1.1 1640 Host: server.example.com:80 1641 Proxy-Authorization: basic aGVsbG86d29ybGQ= 1642 1643 </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 1644 to reject the request. 1645 </p> 1646 <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 1647 if the eventual response is negative, and the connection may be reset with no response if more than one TCP segment is outstanding. 1648 </p> 1649 <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 1650 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. 1651 </p> 1652 <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 1653 the other one, and after that also the other connection will be terminated by the proxy. If there is outstanding data to that 1654 peer undelivered, that data will be discarded. 1655 </p> 1656 <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 1657 CONNECT. 1658 </p> 1659 <h1 id="rfc.section.7"><a href="#rfc.section.7">7.</a> <a id="status.codes" href="#status.codes">Status Code Definitions</a></h1> 1660 <p id="rfc.section.7.p.1">The first digit of the status-code defines the class of response. The last two digits do not have any categorization role. 1661 There are 5 values for the first digit: 1662 </p> 1663 <ul> 1664 <li>1xx: Informational - Request received, continuing process</li> 1665 <li>2xx: Success - The action was successfully received, understood, and accepted</li> 1666 <li>3xx: Redirection - Further action needs to be taken in order to complete the request</li> 1667 <li>4xx: Client Error - The request contains bad syntax or cannot be fulfilled</li> 1668 <li>5xx: Server Error - The server failed to fulfill an apparently valid request</li> 1669 </ul> 1670 <p id="rfc.section.7.p.2">Each status-code is described below, including any metadata required in the response.</p> 1671 <p id="rfc.section.7.p.3">For most status codes the response can carry a payload, in which case a Content-Type header field indicates the payload's 1672 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.9"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>). 1673 </p> 1674 <h2 id="rfc.section.7.1"><a href="#rfc.section.7.1">7.1</a> <a id="status.1xx" href="#status.1xx">Informational 1xx</a></h2> 1675 <p id="rfc.section.7.1.p.1">This class of status code indicates a provisional response, consisting only of the status-line and optional header fields, 1390 <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 <p id="rfc.section.4.3.p.1">Each status-code is described below, including any metadata required in the response.</p> 1392 <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>). 1394 </p> 1395 <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> 1396 <p id="rfc.section.4.3.1.p.1">This class of status code indicates a provisional response, consisting only of the status-line and optional header fields, 1676 1397 and is terminated by an empty line. There are no required header fields for this class of status code. Since HTTP/1.0 did 1677 1398 not define any 1xx status codes, servers <em class="bcp14">MUST NOT</em> send a 1xx response to an HTTP/1.0 client except under experimental conditions. 1678 1399 </p> 1679 <p id="rfc.section. 7.1.p.2">A client <em class="bcp14">MUST</em> be prepared to accept one or more 1xx status responses prior to a regular response, even if the client does not expect a 1001400 <p id="rfc.section.4.3.1.p.2">A client <em class="bcp14">MUST</em> be prepared to accept one or more 1xx status responses prior to a regular response, even if the client does not expect a 100 1680 1401 (Continue) status message. Unexpected 1xx status responses <em class="bcp14">MAY</em> be ignored by a user agent. 1681 1402 </p> 1682 <p id="rfc.section. 7.1.p.3">Proxies <em class="bcp14">MUST</em> forward 1xx responses, unless the connection between the proxy and its client has been closed, or unless the proxy itself1403 <p id="rfc.section.4.3.1.p.3">Proxies <em class="bcp14">MUST</em> forward 1xx responses, unless the connection between the proxy and its client has been closed, or unless the proxy itself 1683 1404 requested the generation of the 1xx response. (For example, if a proxy adds a "Expect: 100-continue" field when it forwards 1684 1405 a request, then it need not forward the corresponding 100 (Continue) response(s).) 1685 1406 </p> 1686 <div id="rfc.iref.22"></div> 1407 <div id="rfc.iref.4"></div> 1408 <div id="rfc.iref.s.1"></div> 1409 <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 <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 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> 1687 1415 <div id="rfc.iref.s.2"></div> 1688 <h3 id="rfc.section.7.1.1"><a href="#rfc.section.7.1.1">7.1.1</a> <a id="status.100" href="#status.100">100 Continue</a></h3> 1689 <p id="rfc.section.7.1.1.p.1">The client <em class="bcp14">SHOULD</em> continue with its request. This interim response is used to inform the client that the initial part of the request has been 1690 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 1691 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.32"><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. 1692 </p> 1693 <div id="rfc.iref.23"></div> 1694 <div id="rfc.iref.s.3"></div> 1695 <h3 id="rfc.section.7.1.2"><a href="#rfc.section.7.1.2">7.1.2</a> <a id="status.101" href="#status.101">101 Switching Protocols</a></h3> 1696 <p id="rfc.section.7.1.2.p.1">The server understands and is willing to comply with the client's request, via the Upgrade message header field (<a href="p1-messaging.html#header.upgrade" title="Upgrade">Section 6.5</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>), for a change in the application protocol being used on this connection. The server will switch protocols to those defined 1416 <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 defined 1697 1418 by the response's Upgrade header field immediately after the empty line which terminates the 101 response. 1698 1419 </p> 1699 <p id="rfc.section. 7.1.2.p.2">The protocol <em class="bcp14">SHOULD</em> be switched only when it is advantageous to do so. For example, switching to a newer version of HTTP is advantageous over1420 <p id="rfc.section.4.3.1.2.p.2">The protocol <em class="bcp14">SHOULD</em> be switched only when it is advantageous to do so. For example, switching to a newer version of HTTP is advantageous over 1700 1421 older versions, and switching to a real-time, synchronous protocol might be advantageous when delivering resources that use 1701 1422 such features. 1702 1423 </p> 1703 <h 2 id="rfc.section.7.2"><a href="#rfc.section.7.2">7.2</a> <a id="status.2xx" href="#status.2xx">Successful 2xx</a></h2>1704 <p id="rfc.section. 7.2.p.1">This class of status code indicates that the client's request was successfully received, understood, and accepted.</p>1705 <div id="rfc.iref. 24"></div>1706 <div id="rfc.iref.s. 4"></div>1707 <h 3 id="rfc.section.7.2.1"><a href="#rfc.section.7.2.1">7.2.1</a> <a id="status.200" href="#status.200">200 OK</a></h3>1708 <p id="rfc.section. 7.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>1424 <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 <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> 1428 <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 <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> 1709 1430 <dl> 1710 1431 <dt>GET</dt> … … 1717 1438 <dd>a representation containing the request message as received by the end server.</dd> 1718 1439 </dl> 1719 <p id="rfc.section. 7.2.1.p.2">Caches <em class="bcp14">MAY</em> use a heuristic (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 2.3.1.1</a> of <a href="#Part6" id="rfc.xref.Part6.11"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) to determine freshness for 200 responses.1720 </p> 1721 <div id="rfc.iref. 25"></div>1722 <div id="rfc.iref.s. 5"></div>1723 <h 3 id="rfc.section.7.2.2"><a href="#rfc.section.7.2.2">7.2.2</a> <a id="status.201" href="#status.201">201 Created</a></h3>1724 <p id="rfc.section. 7.2.2.p.1">The request has been fulfilled and has resulted in a new resource being created.</p>1725 <p id="rfc.section. 7.2.2.p.2">The newly created resource is typically linked to from the response payload, with the most relevant URI also being carried1440 <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> 1444 <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 <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> 1446 <p id="rfc.section.4.3.2.2.p.2">The newly created resource is typically linked to from the response payload, with the most relevant URI also being carried 1726 1447 in the Location header field. If the newly created resource's URI is the same as the Effective Request URI, this information 1727 1448 can be omitted (e.g., in the case of a response to a PUT request). 1728 1449 </p> 1729 <p id="rfc.section. 7.2.2.p.3">The origin server <em class="bcp14">MUST</em> create the resource before returning the 201 status code. If the action cannot be carried out immediately, the server <em class="bcp14">SHOULD</em> respond with 202 (Accepted) response instead.1730 </p> 1731 <p id="rfc.section. 7.2.2.p.4">A 201 response <em class="bcp14">MAY</em> contain an ETag response header field indicating the current value of the entity-tag for the representation of the resource1450 <p id="rfc.section.4.3.2.2.p.3">The origin server <em class="bcp14">MUST</em> create the resource before returning the 201 status code. If the action cannot be carried out immediately, the server <em class="bcp14">SHOULD</em> respond with 202 (Accepted) response instead. 1451 </p> 1452 <p id="rfc.section.4.3.2.2.p.4">A 201 response <em class="bcp14">MAY</em> contain an ETag response header field indicating the current value of the entity-tag for the representation of the resource 1732 1453 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>). 1733 1454 </p> 1734 <div id="rfc.iref. 26"></div>1735 <div id="rfc.iref.s. 6"></div>1736 <h 3 id="rfc.section.7.2.3"><a href="#rfc.section.7.2.3">7.2.3</a> <a id="status.202" href="#status.202">202 Accepted</a></h3>1737 <p id="rfc.section. 7.2.3.p.1">The request has been accepted for processing, but the processing has not been completed. The request might or might not eventually1455 <div id="rfc.iref.8"></div> 1456 <div id="rfc.iref.s.5"></div> 1457 <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 <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 1738 1459 be acted upon, as it might be disallowed when processing actually takes place. There is no facility for re-sending a status 1739 1460 code from an asynchronous operation such as this. 1740 1461 </p> 1741 <p id="rfc.section. 7.2.3.p.2">The 202 response is intentionally non-committal. Its purpose is to allow a server to accept a request for some other process1462 <p id="rfc.section.4.3.2.3.p.2">The 202 response is intentionally non-committal. Its purpose is to allow a server to accept a request for some other process 1742 1463 (perhaps a batch-oriented process that is only run once per day) without requiring that the user agent's connection to the 1743 1464 server persist until the process is completed. The representation returned with this response <em class="bcp14">SHOULD</em> include an indication of the request's current status and either a pointer to a status monitor or some estimate of when the 1744 1465 user can expect the request to be fulfilled. 1745 1466 </p> 1746 <div id="rfc.iref.27"></div> 1467 <div id="rfc.iref.9"></div> 1468 <div id="rfc.iref.s.6"></div> 1469 <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>). 1471 </p> 1472 <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> 1747 1478 <div id="rfc.iref.s.7"></div> 1748 <h3 id="rfc.section.7.2.4"><a href="#rfc.section.7.2.4">7.2.4</a> <a id="status.203" href="#status.203">203 Non-Authoritative Information</a></h3> 1749 <p id="rfc.section.7.2.4.p.1">The representation in the response has been transformed or otherwise modified by a transforming proxy (<a href="p1-messaging.html#intermediaries" title="Intermediaries">Section 2.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>). 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>). 1750 </p> 1751 <p id="rfc.section.7.2.4.p.2">This status code is only appropriate when the response status code would have been 200 (OK) otherwise. When the status code 1752 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. 1753 </p> 1754 <p id="rfc.section.7.2.4.p.3">Caches <em class="bcp14">MAY</em> use a heuristic (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 2.3.1.1</a> of <a href="#Part6" id="rfc.xref.Part6.14"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) to determine freshness for 203 responses. 1755 </p> 1756 <div id="rfc.iref.28"></div> 1757 <div id="rfc.iref.s.8"></div> 1758 <h3 id="rfc.section.7.2.5"><a href="#rfc.section.7.2.5">7.2.5</a> <a id="status.204" href="#status.204">204 No Content</a></h3> 1759 <p id="rfc.section.7.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 1479 <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 <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 1760 1481 content to return in the response payload body. Metadata in the response header fields refer to the target resource and its 1761 1482 current representation after the requested action. 1762 1483 </p> 1763 <p id="rfc.section. 7.2.5.p.2">For example, if a 204 status code is received in response to a PUT request and the response contains an ETag header field,1484 <p id="rfc.section.4.3.2.5.p.2">For example, if a 204 status code is received in response to a PUT request and the response contains an ETag header field, 1764 1485 then the PUT was successful and the ETag field-value contains the entity-tag for the new representation of that target resource. 1765 1486 </p> 1766 <p id="rfc.section. 7.2.5.p.3">The 204 response allows a server to indicate that the action has been successfully applied to the target resource while implying1487 <p id="rfc.section.4.3.2.5.p.3">The 204 response allows a server to indicate that the action has been successfully applied to the target resource while implying 1767 1488 that the user agent <em class="bcp14">SHOULD NOT</em> traverse away from its current "document view" (if any). The server assumes that the user agent will provide some indication 1768 1489 of the success to its user, in accord with its own interface, and apply any new or updated metadata in the response to the 1769 1490 active representation. 1770 1491 </p> 1771 <p id="rfc.section. 7.2.5.p.4">For example, a 204 status code is commonly used with document editing interfaces corresponding to a "save" action, such that1492 <p id="rfc.section.4.3.2.5.p.4">For example, a 204 status code is commonly used with document editing interfaces corresponding to a "save" action, such that 1772 1493 the document being saved remains available to the user for editing. It is also frequently used with interfaces that expect 1773 1494 automated data transfers to be prevalent, such as within distributed version control systems. 1774 1495 </p> 1775 <p id="rfc.section. 7.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.1776 </p> 1777 <div id="rfc.iref. 29"></div>1778 <div id="rfc.iref.s. 9"></div>1779 <h 3 id="rfc.section.7.2.6"><a href="#rfc.section.7.2.6">7.2.6</a> <a id="status.205" href="#status.205">205 Reset Content</a></h3>1780 <p id="rfc.section. 7.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 actions1496 <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 </p> 1498 <div id="rfc.iref.11"></div> 1499 <div id="rfc.iref.s.8"></div> 1500 <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 <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 1781 1502 to take place via user input, followed by a clearing of the form in which the input is given so that the user can easily initiate 1782 1503 another input action. 1783 1504 </p> 1784 <p id="rfc.section. 7.2.6.p.2">The message body included with the response <em class="bcp14">MUST</em> be empty. Note that receivers still need to parse the response according to the algorithm defined in <a href="p1-messaging.html#message.body" title="Message Body">Section 3.3</a> of <a href="#Part1" id="rfc.xref.Part1.35"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>.1785 </p> 1786 <h 2 id="rfc.section.7.3"><a href="#rfc.section.7.3">7.3</a> <a id="status.3xx" href="#status.3xx">Redirection 3xx</a></h2>1787 <p id="rfc.section. 7.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.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>. 1506 </p> 1507 <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 <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. 1788 1509 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 1789 1510 known to be "safe", as defined in <a href="#safe.methods" title="Safe Methods">Section 6.1.1</a>. 1790 1511 </p> 1791 <p id="rfc.section. 7.3.p.2">There are several types of redirects: </p>1512 <p id="rfc.section.4.3.3.p.2">There are several types of redirects: </p> 1792 1513 <ol> 1793 1514 <li> … … 1803 1524 </li> 1804 1525 <li> 1805 <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. 10"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>). This is status code 300 (Multiple Choices).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). 1806 1527 </p> 1807 1528 </li> … … 1811 1532 </li> 1812 1533 </ol> 1813 <div class="note" id="rfc.section. 7.3.p.3">1534 <div class="note" id="rfc.section.4.3.3.p.3"> 1814 1535 <p> <b>Note:</b> In HTTP/1.0, only the status codes 301 (Moved Permanently) and 302 (Found) were defined for the first type of redirect, and 1815 1536 the second type did not exist at all (<a href="#RFC1945" id="rfc.xref.RFC1945.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.0">[RFC1945]</cite></a>, <a href="http://tools.ietf.org/html/rfc1945#section-9.3">Section 9.3</a>). However it turned out that web forms using POST expected redirects to change the operation for the subsequent request to … … 1820 1541 </p> 1821 1542 </div> 1822 <p id="rfc.section. 7.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 9.5</a>.1823 </p> 1824 <p id="rfc.section. 7.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 was1543 <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 was 1825 1546 issued. 1826 1547 </p> 1827 <p id="rfc.section. 7.3.p.6">Clients <em class="bcp14">SHOULD</em> detect and intervene in cyclical redirections (i.e., "infinite" redirection loops).1828 </p> 1829 <div class="note" id="rfc.section. 7.3.p.7">1548 <p id="rfc.section.4.3.3.p.6">Clients <em class="bcp14">SHOULD</em> detect and intervene in cyclical redirections (i.e., "infinite" redirection loops). 1549 </p> 1550 <div class="note" id="rfc.section.4.3.3.p.7"> 1830 1551 <p> <b>Note:</b> An earlier version of this specification recommended a maximum of five redirections (<a href="#RFC2068" id="rfc.xref.RFC2068.2"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>, <a href="http://tools.ietf.org/html/rfc2068#section-10.3">Section 10.3</a>). Content developers need to be aware that some clients might implement such a fixed limitation. 1831 1552 </p> 1832 1553 </div> 1833 <div id="rfc.iref. 30"></div>1834 <div id="rfc.iref.s. 10"></div>1835 <h 3 id="rfc.section.7.3.1"><a href="#rfc.section.7.3.1">7.3.1</a> <a id="status.300" href="#status.300">300 Multiple Choices</a></h3>1836 <p id="rfc.section. 7.3.1.p.1">The target resource has more than one representation, each with its own specific location, and agent-driven negotiation information1837 (<a href="p3-payload.html#content.negotiation" title="Content Negotiation">Section 5</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>) is being provided so that the user (or user agent) can select a preferred representation by redirecting its request to that1554 <div id="rfc.iref.12"></div> 1555 <div id="rfc.iref.s.9"></div> 1556 <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 <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 that 1838 1559 location. 1839 1560 </p> 1840 <p id="rfc.section. 7.3.1.p.2">Unless it was a HEAD request, the response <em class="bcp14">SHOULD</em> include a representation containing a list of representation metadata and location(s) from which the user or user agent can1561 <p id="rfc.section.4.3.3.1.p.2">Unless it was a HEAD request, the response <em class="bcp14">SHOULD</em> include a representation containing a list of representation metadata and location(s) from which the user or user agent can 1841 1562 choose the one most appropriate. Depending upon the format and the capabilities of the user agent, selection of the most appropriate 1842 1563 choice <em class="bcp14">MAY</em> be performed automatically. However, this specification does not define any standard for such automatic selection. 1843 1564 </p> 1844 <p id="rfc.section. 7.3.1.p.3">If the server has a preferred choice of representation, it <em class="bcp14">SHOULD</em> include the specific URI for that representation in the Location field; user agents <em class="bcp14">MAY</em> use the Location field value for automatic redirection.1845 </p> 1846 <p id="rfc.section. 7.3.1.p.4">Caches <em class="bcp14">MAY</em> use a heuristic (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 2.3.1.1</a> of <a href="#Part6" id="rfc.xref.Part6.15"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) to determine freshness for 300 responses.1847 </p> 1848 <div id="rfc.iref. 31"></div>1849 <div id="rfc.iref.s.1 1"></div>1850 <h 3 id="rfc.section.7.3.2"><a href="#rfc.section.7.3.2">7.3.2</a> <a id="status.301" href="#status.301">301 Moved Permanently</a></h3>1851 <p id="rfc.section. 7.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 effective1565 <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 </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.10"><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.10"></div> 1571 <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 <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 1852 1573 request URI to one or more of the new references returned by the server, where possible. 1853 1574 </p> 1854 <p id="rfc.section. 7.3.2.p.2">Caches <em class="bcp14">MAY</em> use a heuristic (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 2.3.1.1</a> of <a href="#Part6" id="rfc.xref.Part6.16"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) to determine freshness for 301 responses.1855 </p> 1856 <p id="rfc.section. 7.3.2.p.3">The new permanent URI <em class="bcp14">SHOULD</em> be given by the Location field in the response. A response payload can contain a short hypertext note with a hyperlink to1575 <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.11"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) to determine freshness for 301 responses. 1576 </p> 1577 <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 1857 1578 the new URI(s). 1858 1579 </p> 1859 <div class="note" id="rfc.section. 7.3.2.p.4">1580 <div class="note" id="rfc.section.4.3.3.2.p.4"> 1860 1581 <p> <b>Note:</b> For historic reasons, user agents <em class="bcp14">MAY</em> change the request method from POST to GET for the subsequent request. If this behavior is undesired, status code 307 (Temporary 1861 1582 Redirect) can be used instead. 1862 1583 </p> 1863 1584 </div> 1864 <div id="rfc.iref. 32"></div>1865 <div id="rfc.iref.s.1 2"></div>1866 <h 3 id="rfc.section.7.3.3"><a href="#rfc.section.7.3.3">7.3.3</a> <a id="status.302" href="#status.302">302 Found</a></h3>1867 <p id="rfc.section. 7.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.1868 </p> 1869 <p id="rfc.section. 7.3.3.p.2">The temporary 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 to1585 <div id="rfc.iref.14"></div> 1586 <div id="rfc.iref.s.11"></div> 1587 <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 <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. 1589 </p> 1590 <p id="rfc.section.4.3.3.3.p.2">The temporary 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 1870 1591 the new URI(s). 1871 1592 </p> 1872 <div class="note" id="rfc.section. 7.3.3.p.3">1593 <div class="note" id="rfc.section.4.3.3.3.p.3"> 1873 1594 <p> <b>Note:</b> For historic reasons, user agents <em class="bcp14">MAY</em> change the request method from POST to GET for the subsequent request. If this behavior is undesired, status code 307 (Temporary 1874 1595 Redirect) can be used instead. 1875 1596 </p> 1876 1597 </div> 1877 <div id="rfc.iref. 33"></div>1878 <div id="rfc.iref.s.1 3"></div>1879 <h 3 id="rfc.section.7.3.4"><a href="#rfc.section.7.3.4">7.3.4</a> <a id="status.303" href="#status.303">303 See Other</a></h3>1880 <p id="rfc.section. 7.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 URI1598 <div id="rfc.iref.15"></div> 1599 <div id="rfc.iref.s.12"></div> 1600 <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 <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 1881 1602 in the Location header field, that is intended to provide an indirect response to the original request. In order to satisfy 1882 1603 the original request, a user agent <em class="bcp14">SHOULD</em> perform a retrieval request using the Location URI (a GET or HEAD request if using HTTP), which may itself be redirected further, … … 1884 1605 not considered equivalent to the effective request URI. 1885 1606 </p> 1886 <p id="rfc.section. 7.3.4.p.2">This status code is generally applicable to any HTTP method. It is primarily used to allow the output of a POST action to1607 <p id="rfc.section.4.3.3.4.p.2">This status code is generally applicable to any HTTP method. It is primarily used to allow the output of a POST action to 1887 1608 redirect the user agent to a selected resource, since doing so provides the information corresponding to the POST response 1888 1609 in a form that can be separately identified, bookmarked, and cached independent of the original request. 1889 1610 </p> 1890 <p id="rfc.section. 7.3.4.p.3">A 303 response to a GET request indicates that the requested resource does not have a representation of its own that can be1611 <p id="rfc.section.4.3.3.4.p.3">A 303 response to a GET request indicates that the requested resource does not have a representation of its own that can be 1891 1612 transferred by the server over HTTP. The Location URI indicates a resource that is descriptive of the target resource, such 1892 1613 that the follow-on representation might be useful to recipients without implying that it adequately represents the target … … 1894 1615 be a useful description are outside the scope of HTTP and thus entirely determined by the URI owner(s). 1895 1616 </p> 1896 <p id="rfc.section.7.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. 1897 </p> 1898 <div id="rfc.iref.34"></div> 1617 <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 </p> 1619 <div id="rfc.iref.16"></div> 1620 <div id="rfc.iref.s.13"></div> 1621 <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 <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 </p> 1624 <div id="rfc.iref.17"></div> 1899 1625 <div id="rfc.iref.s.14"></div> 1900 <h3 id="rfc.section.7.3.5"><a href="#rfc.section.7.3.5">7.3.5</a> <a id="status.305" href="#status.305">305 Use Proxy</a></h3> 1901 <p id="rfc.section.7.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. 1902 </p> 1903 <div id="rfc.iref.35"></div> 1626 <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 <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> 1904 1629 <div id="rfc.iref.s.15"></div> 1905 <h3 id="rfc.section.7.3.6"><a href="#rfc.section.7.3.6">7.3.6</a> <a id="status.306" href="#status.306">306 (Unused)</a></h3> 1906 <p id="rfc.section.7.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> 1907 <div id="rfc.iref.36"></div> 1908 <div id="rfc.iref.s.16"></div> 1909 <h3 id="rfc.section.7.3.7"><a href="#rfc.section.7.3.7">7.3.7</a> <a id="status.307" href="#status.307">307 Temporary Redirect</a></h3> 1910 <p id="rfc.section.7.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. 1911 </p> 1912 <p id="rfc.section.7.3.7.p.2">The temporary 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 1630 <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 <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. 1632 </p> 1633 <p id="rfc.section.4.3.3.7.p.2">The temporary 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 1913 1634 the new URI(s). 1914 1635 </p> 1915 <div class="note" id="rfc.section. 7.3.7.p.3">1636 <div class="note" id="rfc.section.4.3.3.7.p.3"> 1916 1637 <p> <b>Note:</b> This status code is similar to 302 Found, except that it does not allow rewriting the request method from POST to GET. This 1917 1638 specification defines no equivalent counterpart for 301 Moved Permanently (<a href="#draft-reschke-http-status-308" id="rfc.xref.draft-reschke-http-status-308.1"><cite title="The Hypertext Transfer Protocol (HTTP) Status Code 308 (Permanent Redirect)">[draft-reschke-http-status-308]</cite></a>, however, defines the status code 308 Permanent Redirect for this purpose). 1918 1639 </p> 1919 1640 </div> 1920 <h 2 id="rfc.section.7.4"><a href="#rfc.section.7.4">7.4</a> <a id="status.4xx" href="#status.4xx">Client Error 4xx</a></h2>1921 <p id="rfc.section. 7.4.p.1">The 4xx class of status code is intended for cases in which the client seems to have erred. Except when responding to a HEAD1641 <h3 id="rfc.section.4.3.4"><a href="#rfc.section.4.3.4">4.3.4</a> <a id="status.4xx" href="#status.4xx">Client Error 4xx</a></h3> 1642 <p id="rfc.section.4.3.4.p.1">The 4xx class of status code is intended for cases in which the client seems to have erred. Except when responding to a HEAD 1922 1643 request, the server <em class="bcp14">SHOULD</em> include a representation containing an explanation of the error situation, and whether it is a temporary or permanent condition. 1923 1644 These status codes are applicable to any request method. User agents <em class="bcp14">SHOULD</em> display any included representation to the user. 1924 1645 </p> 1925 <div id="rfc.iref.37"></div> 1646 <div id="rfc.iref.19"></div> 1647 <div id="rfc.iref.s.16"></div> 1648 <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 <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> 1926 1651 <div id="rfc.iref.s.17"></div> 1927 <h 3 id="rfc.section.7.4.1"><a href="#rfc.section.7.4.1">7.4.1</a> <a id="status.400" href="#status.400">400 Bad Request</a></h3>1928 <p id="rfc.section. 7.4.1.p.1">The server cannot or will not process the request, due to a client error (e.g., malformed syntax).</p>1929 <div id="rfc.iref. 38"></div>1652 <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 <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> 1930 1655 <div id="rfc.iref.s.18"></div> 1931 <h3 id="rfc.section.7.4.2"><a href="#rfc.section.7.4.2">7.4.2</a> <a id="status.402" href="#status.402">402 Payment Required</a></h3> 1932 <p id="rfc.section.7.4.2.p.1">This code is reserved for future use.</p> 1933 <div id="rfc.iref.39"></div> 1656 <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 <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 1658 be successful, but any credentials that were provided in the request are insufficient. The request <em class="bcp14">SHOULD NOT</em> be repeated with the same credentials. 1659 </p> 1660 <p id="rfc.section.4.3.4.3.p.2">If the request method was not HEAD and the server wishes to make public why the request has not been fulfilled, it <em class="bcp14">SHOULD</em> describe the reason for the refusal in the representation. If the server does not wish to make this information available 1661 to the client, the status code 404 (Not Found) <em class="bcp14">MAY</em> be used instead. 1662 </p> 1663 <div id="rfc.iref.22"></div> 1934 1664 <div id="rfc.iref.s.19"></div> 1935 <h3 id="rfc.section.7.4.3"><a href="#rfc.section.7.4.3">7.4.3</a> <a id="status.403" href="#status.403">403 Forbidden</a></h3> 1936 <p id="rfc.section.7.4.3.p.1">The server understood the request, but refuses to authorize it. Providing different user authentication credentials might 1937 be successful, but any credentials that were provided in the request are insufficient. The request <em class="bcp14">SHOULD NOT</em> be repeated with the same credentials. 1938 </p> 1939 <p id="rfc.section.7.4.3.p.2">If the request method was not HEAD and the server wishes to make public why the request has not been fulfilled, it <em class="bcp14">SHOULD</em> describe the reason for the refusal in the representation. If the server does not wish to make this information available 1940 to the client, the status code 404 (Not Found) <em class="bcp14">MAY</em> be used instead. 1941 </p> 1942 <div id="rfc.iref.40"></div> 1943 <div id="rfc.iref.s.20"></div> 1944 <h3 id="rfc.section.7.4.4"><a href="#rfc.section.7.4.4">7.4.4</a> <a id="status.404" href="#status.404">404 Not Found</a></h3> 1945 <p id="rfc.section.7.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 1665 <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 <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 1946 1667 or permanent. The 410 (Gone) status code <em class="bcp14">SHOULD</em> be used if the server knows, through some internally configurable mechanism, that an old resource is permanently unavailable 1947 1668 and has no forwarding address. This status code is commonly used when the server does not wish to reveal exactly why the request 1948 1669 has been refused, or when no other response is applicable. 1949 1670 </p> 1950 <div id="rfc.iref.41"></div> 1671 <div id="rfc.iref.23"></div> 1672 <div id="rfc.iref.s.20"></div> 1673 <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 <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 </p> 1676 <div id="rfc.iref.24"></div> 1951 1677 <div id="rfc.iref.s.21"></div> 1952 <h3 id="rfc.section.7.4.5"><a href="#rfc.section.7.4.5">7.4.5</a> <a id="status.405" href="#status.405">405 Method Not Allowed</a></h3> 1953 <p id="rfc.section.7.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. 1954 </p> 1955 <div id="rfc.iref.42"></div> 1956 <div id="rfc.iref.s.22"></div> 1957 <h3 id="rfc.section.7.4.6"><a href="#rfc.section.7.4.6">7.4.6</a> <a id="status.406" href="#status.406">406 Not Acceptable</a></h3> 1958 <p id="rfc.section.7.4.6.p.1">The resource identified by the request is only capable of generating response representations which have content characteristics 1959 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.12"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>). 1960 </p> 1961 <p id="rfc.section.7.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 1678 <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 <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.10"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>). 1681 </p> 1682 <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 1962 1683 or user agent can choose the one most appropriate. Depending upon the format and the capabilities of the user agent, selection 1963 1684 of the most appropriate choice <em class="bcp14">MAY</em> be performed automatically. However, this specification does not define any standard for such automatic selection. 1964 1685 </p> 1965 <div class="note" id="rfc.section. 7.4.6.p.3">1686 <div class="note" id="rfc.section.4.3.4.6.p.3"> 1966 1687 <p> <b>Note:</b> HTTP/1.1 servers are allowed to return responses which are not acceptable according to the accept header fields sent in the 1967 1688 request. In some cases, this might even be preferable to sending a 406 response. User agents are encouraged to inspect the … … 1969 1690 </p> 1970 1691 </div> 1971 <p id="rfc.section.7.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. 1972 </p> 1973 <div id="rfc.iref.43"></div> 1692 <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 </p> 1694 <div id="rfc.iref.25"></div> 1695 <div id="rfc.iref.s.22"></div> 1696 <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 <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 </p> 1699 <div id="rfc.iref.26"></div> 1974 1700 <div id="rfc.iref.s.23"></div> 1975 <h3 id="rfc.section.7.4.7"><a href="#rfc.section.7.4.7">7.4.7</a> <a id="status.408" href="#status.408">408 Request Timeout</a></h3> 1976 <p id="rfc.section.7.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. 1977 </p> 1978 <div id="rfc.iref.44"></div> 1979 <div id="rfc.iref.s.24"></div> 1980 <h3 id="rfc.section.7.4.8"><a href="#rfc.section.7.4.8">7.4.8</a> <a id="status.409" href="#status.409">409 Conflict</a></h3> 1981 <p id="rfc.section.7.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 1701 <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 <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 1982 1703 situations where it is expected that the user might be able to resolve the conflict and resubmit the request. The response 1983 1704 body <em class="bcp14">SHOULD</em> include enough information for the user to recognize the source of the conflict. Ideally, the response representation would 1984 1705 include enough information for the user or user agent to fix the problem; however, that might not be possible and is not required. 1985 1706 </p> 1986 <p id="rfc.section. 7.4.8.p.2">Conflicts are most likely to occur in response to a PUT request. For example, if versioning were being used and the representation1707 <p id="rfc.section.4.3.4.8.p.2">Conflicts are most likely to occur in response to a PUT request. For example, if versioning were being used and the representation 1987 1708 being PUT included changes to a resource which conflict with those made by an earlier (third-party) request, the server might 1988 1709 use the 409 response to indicate that it can't complete the request. In this case, the response representation would likely 1989 1710 contain a list of the differences between the two versions. 1990 1711 </p> 1991 <div id="rfc.iref. 45"></div>1992 <div id="rfc.iref.s.2 5"></div>1993 <h 3 id="rfc.section.7.4.9"><a href="#rfc.section.7.4.9">7.4.9</a> <a id="status.410" href="#status.410">410 Gone</a></h3>1994 <p id="rfc.section. 7.4.9.p.1">The target resource is no longer available at the server and no forwarding address is known. This condition is expected to1712 <div id="rfc.iref.27"></div> 1713 <div id="rfc.iref.s.24"></div> 1714 <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 <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 1995 1716 be considered permanent. Clients with link editing capabilities <em class="bcp14">SHOULD</em> delete references to the effective request URI after user approval. If the server does not know, or has no facility to determine, 1996 1717 whether or not the condition is permanent, the status code 404 (Not Found) <em class="bcp14">SHOULD</em> be used instead. 1997 1718 </p> 1998 <p id="rfc.section. 7.4.9.p.2">The 410 response is primarily intended to assist the task of web maintenance by notifying the recipient that the resource1719 <p id="rfc.section.4.3.4.9.p.2">The 410 response is primarily intended to assist the task of web maintenance by notifying the recipient that the resource 1999 1720 is intentionally unavailable and that the server owners desire that remote links to that resource be removed. Such an event 2000 1721 is common for limited-time, promotional services and for resources belonging to individuals no longer working at the server's … … 2002 1723 — that is left to the discretion of the server owner. 2003 1724 </p> 2004 <p id="rfc.section.7.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. 2005 </p> 2006 <div id="rfc.iref.46"></div> 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.12"><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.25"></div> 1729 <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 <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 message. 1732 </p> 1733 <div id="rfc.iref.29"></div> 2007 1734 <div id="rfc.iref.s.26"></div> 2008 <h3 id="rfc.section.7.4.10"><a href="#rfc.section.7.4.10">7.4.10</a> <a id="status.411" href="#status.411">411 Length Required</a></h3> 2009 <p id="rfc.section.7.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 2010 message. 2011 </p> 2012 <div id="rfc.iref.47"></div> 1735 <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 <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 1737 to process. The server <em class="bcp14">MAY</em> close the connection to prevent the client from continuing the request. 1738 </p> 1739 <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 </p> 1741 <div id="rfc.iref.30"></div> 2013 1742 <div id="rfc.iref.s.27"></div> 2014 <h3 id="rfc.section.7.4.11"><a href="#rfc.section.7.4.11">7.4.11</a> <a id="status.413" href="#status.413">413 Request Representation Too Large</a></h3> 2015 <p id="rfc.section.7.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 2016 to process. The server <em class="bcp14">MAY</em> close the connection to prevent the client from continuing the request. 2017 </p> 2018 <p id="rfc.section.7.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. 2019 </p> 2020 <div id="rfc.iref.48"></div> 2021 <div id="rfc.iref.s.28"></div> 2022 <h3 id="rfc.section.7.4.12"><a href="#rfc.section.7.4.12">7.4.12</a> <a id="status.414" href="#status.414">414 URI Too Long</a></h3> 2023 <p id="rfc.section.7.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. 1743 <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 <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. 2024 1745 This rare condition is only likely to occur when a client has improperly converted a POST request to a GET request with long 2025 1746 query information, when the client has descended into a URI "black hole" of redirection (e.g., a redirected URI prefix that … … 2027 1748 in some servers using fixed-length buffers for reading or manipulating the request-target. 2028 1749 </p> 2029 <div id="rfc.iref.49"></div> 1750 <div id="rfc.iref.31"></div> 1751 <div id="rfc.iref.s.28"></div> 1752 <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 <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 on the target resource. 1755 </p> 1756 <div id="rfc.iref.32"></div> 2030 1757 <div id="rfc.iref.s.29"></div> 2031 <h 3 id="rfc.section.7.4.13"><a href="#rfc.section.7.4.13">7.4.13</a> <a id="status.415" href="#status.415">415 Unsupported Media Type</a></h3>2032 <p id="rfc.section. 7.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 method2033 on the target resource.2034 </p> 2035 <div id="rfc.iref. 50"></div>1758 <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 could 1760 not be met by the next-hop server. 1761 </p> 1762 <div id="rfc.iref.33"></div> 2036 1763 <div id="rfc.iref.s.30"></div> 2037 <h3 id="rfc.section.7.4.14"><a href="#rfc.section.7.4.14">7.4.14</a> <a id="status.417" href="#status.417">417 Expectation Failed</a></h3> 2038 <p id="rfc.section.7.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 9.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 2039 not be met by the next-hop server. 2040 </p> 2041 <div id="rfc.iref.51"></div> 2042 <div id="rfc.iref.s.31"></div> 2043 <h3 id="rfc.section.7.4.15"><a href="#rfc.section.7.4.15">7.4.15</a> <a id="status.426" href="#status.426">426 Upgrade Required</a></h3> 2044 <p id="rfc.section.7.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.36"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) specifying the required protocols. 2045 </p> 2046 <div id="rfc.figure.u.8"></div> 1764 <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.30"><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> 2047 1768 <p>Example:</p> <pre class="text">HTTP/1.1 426 Upgrade Required 2048 1769 Upgrade: HTTP/3.0 … … 2052 1773 2053 1774 <span id="s426body">This service requires use of the HTTP/3.0 protocol. 2054 </span></pre><p id="rfc.section. 7.4.15.p.3">The server <em class="bcp14">SHOULD</em> include a message body in the 426 response which indicates in human readable form the reason for the error and describes any1775 </span></pre><p id="rfc.section.4.3.4.15.p.3">The server <em class="bcp14">SHOULD</em> include a message body in the 426 response which indicates in human readable form the reason for the error and describes any 2055 1776 alternative courses which may be available to the user. 2056 1777 </p> 2057 <h 2 id="rfc.section.7.5"><a href="#rfc.section.7.5">7.5</a> <a id="status.5xx" href="#status.5xx">Server Error 5xx</a></h2>2058 <p id="rfc.section. 7.5.p.1">Response status codes beginning with the digit "5" indicate cases in which the server is aware that it has erred or is incapable1778 <h3 id="rfc.section.4.3.5"><a href="#rfc.section.4.3.5">4.3.5</a> <a id="status.5xx" href="#status.5xx">Server Error 5xx</a></h3> 1779 <p id="rfc.section.4.3.5.p.1">Response status codes beginning with the digit "5" indicate cases in which the server is aware that it has erred or is incapable 2059 1780 of performing the request. Except when responding to a HEAD request, the server <em class="bcp14">SHOULD</em> include a representation containing an explanation of the error situation, and whether it is a temporary or permanent condition. 2060 1781 User agents <em class="bcp14">SHOULD</em> display any included representation to the user. These response codes are applicable to any request method. 2061 1782 </p> 2062 <div id="rfc.iref.52"></div> 1783 <div id="rfc.iref.34"></div> 1784 <div id="rfc.iref.s.31"></div> 1785 <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 <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> 2063 1788 <div id="rfc.iref.s.32"></div> 2064 <h3 id="rfc.section.7.5.1"><a href="#rfc.section.7.5.1">7.5.1</a> <a id="status.500" href="#status.500">500 Internal Server Error</a></h3> 2065 <p id="rfc.section.7.5.1.p.1">The server encountered an unexpected condition which prevented it from fulfilling the request.</p> 2066 <div id="rfc.iref.53"></div> 1789 <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 <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 does not recognize the request method and is not capable of supporting it for any resource. 1792 </p> 1793 <div id="rfc.iref.36"></div> 2067 1794 <div id="rfc.iref.s.33"></div> 2068 <h 3 id="rfc.section.7.5.2"><a href="#rfc.section.7.5.2">7.5.2</a> <a id="status.501" href="#status.501">501 Not Implemented</a></h3>2069 <p id="rfc.section. 7.5.2.p.1">The server does not support the functionality required to fulfill the request. This is the appropriate response when the server2070 does not recognize the request method and is not capable of supporting it for any resource.2071 </p> 2072 <div id="rfc.iref. 54"></div>1795 <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 <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 to fulfill the request. 1798 </p> 1799 <div id="rfc.iref.37"></div> 2073 1800 <div id="rfc.iref.s.34"></div> 2074 <h3 id="rfc.section.7.5.3"><a href="#rfc.section.7.5.3">7.5.3</a> <a id="status.502" href="#status.502">502 Bad Gateway</a></h3> 2075 <p id="rfc.section.7.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 2076 to fulfill the request. 2077 </p> 2078 <div id="rfc.iref.55"></div> 2079 <div id="rfc.iref.s.35"></div> 2080 <h3 id="rfc.section.7.5.4"><a href="#rfc.section.7.5.4">7.5.4</a> <a id="status.503" href="#status.503">503 Service Unavailable</a></h3> 2081 <p id="rfc.section.7.5.4.p.1">The server is currently unable to handle the request due to a temporary overloading or maintenance of the server.</p> 2082 <p id="rfc.section.7.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 2083 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 9.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. 2084 </p> 2085 <div class="note" id="rfc.section.7.5.4.p.3"> 1801 <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 <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 <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. 1805 </p> 1806 <div class="note" id="rfc.section.4.3.5.4.p.3"> 2086 1807 <p> <b>Note:</b> The existence of the 503 status code does not imply that a server has to use it when becoming overloaded. Some servers might 2087 1808 wish to simply refuse the connection. 2088 1809 </p> 2089 1810 </div> 2090 <div id="rfc.iref. 56"></div>2091 <div id="rfc.iref.s.3 6"></div>2092 <h 3 id="rfc.section.7.5.5"><a href="#rfc.section.7.5.5">7.5.5</a> <a id="status.504" href="#status.504">504 Gateway Timeout</a></h3>2093 <p id="rfc.section. 7.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 the1811 <div id="rfc.iref.38"></div> 1812 <div id="rfc.iref.s.35"></div> 1813 <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 <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 2094 1815 URI (e.g., HTTP, FTP, LDAP) or some other auxiliary server (e.g., DNS) it needed to access in attempting to complete the request. 2095 1816 </p> 2096 <div class="note" id="rfc.section. 7.5.5.p.2">1817 <div class="note" id="rfc.section.4.3.5.5.p.2"> 2097 1818 <p> <b>Note</b> to implementors: some deployed proxies are known to return 400 or 500 when DNS lookups time out. 2098 1819 </p> 2099 1820 </div> 2100 <div id="rfc.iref.57"></div> 1821 <div id="rfc.iref.39"></div> 1822 <div id="rfc.iref.s.36"></div> 1823 <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 <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 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.31"><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 </p> 1828 <h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a> <a id="representation" href="#representation">Representation</a></h1> 1829 <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 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.11"><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.32"><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 to ensure safe and proper transfer of the message. 1835 </p> 1836 <h2 id="rfc.section.5.1"><a href="#rfc.section.5.1">5.1</a> <a id="identifying.response.associated.with.representation" href="#identifying.response.associated.with.representation">Identifying the Resource Associated with a Representation</a></h2> 1837 <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 <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.33"><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 rules are used (with the first applicable one being selected): 1841 </p> 1842 <ol> 1843 <li>If the response status code is 200 or 203 and the request method was GET, the response payload is a representation of the 1844 target resource. 1845 </li> 1846 <li>If the response status code is 204, 206, or 304 and the request method was GET or HEAD, the response payload is a partial 1847 representation of the target resource. 1848 </li> 1849 <li>If the response has a Content-Location header field, and that URI is the same as the effective request URI, the response payload 1850 is a representation of the target resource. 1851 </li> 1852 <li>If the response has a Content-Location header field, and that URI is not the same as the effective request URI, then the response 1853 asserts that its payload is a representation of the resource identified by the Content-Location URI. However, such an assertion 1854 cannot be trusted unless it can be verified by other means (not defined by HTTP). 1855 </li> 1856 <li>Otherwise, the response is a representation of an anonymous (i.e., unidentified) resource.</li> 1857 </ol> 1858 <p id="rfc.section.5.1.p.5"> <span class="comment" id="TODO-req-uri">[<a href="#TODO-req-uri" class="smpl">TODO-req-uri</a>: The comparison function is going to have to be defined somewhere, because we already need to compare URIs for things like 1859 cache invalidation.]</span> 1860 </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> 2101 1866 <div id="rfc.iref.s.37"></div> 2102 <h3 id="rfc.section.7.5.6"><a href="#rfc.section.7.5.6">7.5.6</a> <a id="status.505" href="#status.505">505 HTTP Version Not Supported</a></h3> 2103 <p id="rfc.section.7.5.6.p.1">The server does not support, or refuses to support, the protocol version that was used in the request message. The server 2104 is indicating that it is unable or unwilling to complete the request using the same major version as the client, as described 2105 in <a href="p1-messaging.html#http.version" title="Protocol Versioning">Section 2.6</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>, 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. 2106 </p> 2107 <h1 id="rfc.section.8"><a href="#rfc.section.8">8.</a> <a id="common.protocol.parameters" href="#common.protocol.parameters">Common Protocol Parameters</a></h1> 2108 <h2 id="rfc.section.8.1"><a href="#rfc.section.8.1">8.1</a> <a id="http.date" href="#http.date">Date/Time Formats</a></h2> 2109 <p id="rfc.section.8.1.p.1">HTTP applications have historically allowed three different formats for date/time stamps. However, the preferred format is 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 2110 2109 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>: 2111 2110 </p> 2112 2111 <div id="rfc.figure.u.9"></div><pre class="text">Sun, 06 Nov 1994 08:49:37 GMT ; RFC 1123 2113 </pre><p id="rfc.section. 8.1.p.3">The other formats are described here only for compatibility with obsolete implementations.</p>2112 </pre><p id="rfc.section.7.1.p.3">The other formats are described here only for compatibility with obsolete implementations.</p> 2114 2113 <div id="rfc.figure.u.10"></div><pre class="text">Sunday, 06-Nov-94 08:49:37 GMT ; obsolete RFC 850 format 2115 2114 Sun Nov 6 08:49:37 1994 ; ANSI C's asctime() format 2116 </pre><p id="rfc.section. 8.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.2117 </p> 2118 <p id="rfc.section. 8.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 (Coordinated2115 </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 (Coordinated 2119 2118 Universal Time). This is indicated in the first two formats by the inclusion of "GMT" as the three-letter abbreviation for 2120 2119 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. … … 2122 2121 <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> 2123 2122 </pre><div id="preferred.date.format"> 2124 <p id="rfc.section. 8.1.p.8"> Preferred format:</p>2123 <p id="rfc.section.7.1.p.8"> Preferred format:</p> 2125 2124 </div> 2126 2125 <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> … … 2162 2161 <a href="#preferred.date.format" class="smpl">minute</a> = 2<a href="#notation" class="smpl">DIGIT</a> 2163 2162 <a href="#preferred.date.format" class="smpl">second</a> = 2<a href="#notation" class="smpl">DIGIT</a> 2164 </pre><p id="rfc.section. 8.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>).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>). 2165 2164 </p> 2166 2165 <div id="obsolete.date.formats"> 2167 <p id="rfc.section. 8.1.p.11"> Obsolete formats:</p>2166 <p id="rfc.section.7.1.p.11"> Obsolete formats:</p> 2168 2167 </div> 2169 2168 <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> … … 2182 2181 <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> )) 2183 2182 ; month day (e.g., Jun 2) 2184 </pre><div class="note" id="rfc.section. 8.1.p.15">2183 </pre><div class="note" id="rfc.section.7.1.p.15"> 2185 2184 <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, 2186 2185 as is sometimes the case when retrieving or posting messages via proxies/gateways to SMTP or NNTP. 2187 2186 </p> 2188 2187 </div> 2189 <div class="note" id="rfc.section. 8.1.p.16">2188 <div class="note" id="rfc.section.7.1.p.16"> 2190 2189 <p> <b>Note:</b> HTTP requirements for the date/time stamp format apply only to their usage within the protocol stream. Clients and servers 2191 2190 are not required to use these formats for user presentation, request logging, etc. 2192 2191 </p> 2193 2192 </div> 2194 <h2 id="rfc.section. 8.2"><a href="#rfc.section.8.2">8.2</a> <a id="product.tokens" href="#product.tokens">Product Tokens</a></h2>2195 <p id="rfc.section. 8.2.p.1">Product tokens are used to allow communicating applications to identify themselves by software name and version. Most fields2193 <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 fields 2196 2195 using product tokens also allow sub-products which form a significant part of the application to be listed, separated by whitespace. 2197 2196 By convention, the products are listed in order of their significance for identifying the application. … … 2199 2198 <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>] 2200 2199 <a href="#product.tokens" class="smpl">product-version</a> = <a href="#core.rules" class="smpl">token</a> 2201 </pre><p id="rfc.section. 8.2.p.3">Examples:</p>2200 </pre><p id="rfc.section.7.2.p.3">Examples:</p> 2202 2201 <div id="rfc.figure.u.17"></div><pre class="text"> User-Agent: CERN-LineMode/2.15 libwww/2.17b3 2203 2202 Server: Apache/0.8.4 2204 </pre><p id="rfc.section. 8.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).2205 </p> 2206 <h1 id="rfc.section. 9"><a href="#rfc.section.9">9.</a> <a id="header.field.definitions" href="#header.field.definitions">Header Field Definitions</a></h1>2207 <p id="rfc.section. 9.p.1">This section defines the syntax and semantics of HTTP/1.1 header fields related to request and response semantics.</p>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> 2208 2207 <div id="rfc.iref.a.1"></div> 2209 2208 <div id="rfc.iref.h.2"></div> 2210 <h2 id="rfc.section. 9.1"><a href="#rfc.section.9.1">9.1</a> <a id="header.allow" href="#header.allow">Allow</a></h2>2211 <p id="rfc.section. 9.1.p.1">The "Allow" header field lists the set of methods advertised as supported by the target resource. The purpose of this field2209 <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 field 2212 2211 is strictly to inform the recipient of valid request methods associated with the resource. 2213 2212 </p> 2214 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> 2215 </pre><p id="rfc.section. 9.1.p.3">Example of use:</p>2214 </pre><p id="rfc.section.8.1.p.3">Example of use:</p> 2216 2215 <div id="rfc.figure.u.19"></div><pre class="text"> Allow: GET, HEAD, PUT 2217 </pre><p id="rfc.section. 9.1.p.5">The actual set of allowed methods is defined by the origin server at the time of each request.</p>2218 <p id="rfc.section. 9.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 according2216 </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 according 2219 2218 to the generic message handling rules. 2220 2219 </p> 2221 2220 <div id="rfc.iref.d.2"></div> 2222 2221 <div id="rfc.iref.h.3"></div> 2223 <h2 id="rfc.section. 9.2"><a href="#rfc.section.9.2">9.2</a> <a id="header.date" href="#header.date">Date</a></h2>2224 <p id="rfc.section. 9.2.p.1">The "Date" header field represents the date and time at which the message was originated, having the same semantics as the2225 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 8.1</a>; it <em class="bcp14">MUST</em> be sent in rfc1123-date format.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 the 2224 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. 2226 2225 </p> 2227 2226 <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> 2228 </pre><p id="rfc.section. 9.2.p.3">An example is</p>2227 </pre><p id="rfc.section.8.2.p.3">An example is</p> 2229 2228 <div id="rfc.figure.u.21"></div><pre class="text"> Date: Tue, 15 Nov 1994 08:12:31 GMT 2230 </pre><p id="rfc.section. 9.2.p.5">Origin servers <em class="bcp14">MUST</em> include a Date header field in all responses, except in these cases: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: 2231 2230 </p> 2232 2231 <ol> … … 2239 2238 </li> 2240 2239 </ol> 2241 <p id="rfc.section. 9.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.2242 </p> 2243 <p id="rfc.section. 9.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 it2240 <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 it 2244 2243 when it doesn't convey any useful information (as is usually the case for requests that do not contain a payload). 2245 2244 </p> 2246 <p id="rfc.section. 9.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 means2245 <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 means 2247 2246 of generating a reasonably accurate date and time. In theory, the date ought to represent the moment just before the payload 2248 2247 is generated. In practice, the date can be generated at any time during the message origination without affecting its semantic … … 2251 2250 <div id="rfc.iref.e.1"></div> 2252 2251 <div id="rfc.iref.h.4"></div> 2253 <h2 id="rfc.section. 9.3"><a href="#rfc.section.9.3">9.3</a> <a id="header.expect" href="#header.expect">Expect</a></h2>2254 <p id="rfc.section. 9.3.p.1">The "Expect" header field is used to indicate that particular server behaviors are required by the client.</p>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> 2255 2254 <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> 2256 2255 … … 2261 2260 <a href="#header.expect" class="smpl">expect-name</a> = <a href="#core.rules" class="smpl">token</a> 2262 2261 <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> 2263 </pre><p id="rfc.section. 9.3.p.3">If all received Expect header field(s) are syntactically valid but contain an expectation that the recipient does not understand2262 </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 understand 2264 2263 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. 2265 2264 </p> 2266 <p id="rfc.section. 9.3.p.4">The only expectation defined by this specification is:</p>2267 <p id="rfc.section. 9.3.p.5"><span id="rfc.iref.89"></span><span id="rfc.iref.e.2"></span> 100-continue2265 <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-continue 2268 2267 </p> 2269 2268 <ul class="empty"> … … 2271 2270 </li> 2272 2271 </ul> 2273 <p id="rfc.section. 9.3.p.6">Comparison is case-insensitive for names (expect-name), and case-sensitive for values (expect-value).</p>2274 <p id="rfc.section. 9.3.p.7">The Expect mechanism is hop-by-hop: the above requirements apply to any server, including proxies. However, the Expect header2272 <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 header 2275 2274 field itself is end-to-end; it <em class="bcp14">MUST</em> be forwarded if the request is forwarded. 2276 2275 </p> 2277 <p id="rfc.section. 9.3.p.8">Many older HTTP/1.0 and HTTP/1.1 applications do not understand the Expect header field.</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> 2278 2277 <div id="rfc.iref.f.1"></div> 2279 2278 <div id="rfc.iref.h.5"></div> 2280 <h2 id="rfc.section. 9.4"><a href="#rfc.section.9.4">9.4</a> <a id="header.from" href="#header.from">From</a></h2>2281 <p id="rfc.section. 9.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>: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>: 2282 2281 </p> 2283 2282 <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> 2284 2283 2285 2284 <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>> 2286 </pre><p id="rfc.section. 9.4.p.3">An example is:</p>2285 </pre><p id="rfc.section.8.4.p.3">An example is:</p> 2287 2286 <div id="rfc.figure.u.24"></div><pre class="text"> From: webmaster@example.org 2288 </pre><p id="rfc.section. 9.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 performed2287 </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 performed 2289 2288 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 2290 2289 end. 2291 2290 </p> 2292 <p id="rfc.section. 9.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 original2291 <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 original 2293 2292 issuer's address <em class="bcp14">SHOULD</em> be used. 2294 2293 </p> 2295 <p id="rfc.section. 9.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's2294 <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's 2296 2295 security policy. It is strongly recommended that the user be able to disable, enable, and modify the value of this field at 2297 2296 any time prior to a request. … … 2299 2298 <div id="rfc.iref.l.1"></div> 2300 2299 <div id="rfc.iref.h.6"></div> 2301 <h2 id="rfc.section. 9.5"><a href="#rfc.section.9.5">9.5</a> <a id="header.location" href="#header.location">Location</a></h2>2302 <p id="rfc.section. 9.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.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. 2303 2302 </p> 2304 2303 <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> 2305 </pre><p id="rfc.section. 9.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,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, 2306 2305 the location <em class="bcp14">SHOULD</em> indicate the server's preferred URI for automatic redirection to the resource. 2307 2306 </p> 2308 <p id="rfc.section. 9.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,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, 2309 2308 then the original URI's fragment identifier is added to the final value. 2310 2309 </p> … … 2315 2314 <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 2316 2315 </pre> <p>would result in a final value of "http://www.example.net/index.html#larry", preserving the original fragment identifier.</p> 2317 <div class="note" id="rfc.section. 9.5.p.7">2316 <div class="note" id="rfc.section.8.5.p.7"> 2318 2317 <p> <b>Note:</b> Some recipients attempt to recover from Location fields that are not valid URI references. This specification does not mandate 2319 2318 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>). 2320 2319 </p> 2321 2320 </div> 2322 <p id="rfc.section. 9.5.p.8">There are circumstances in which a fragment identifier in a Location URI would not be appropriate. For instance, when it appears2321 <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 appears 2323 2322 in a 201 Created response, where the Location header field specifies the URI for the entire created resource. 2324 2323 </p> 2325 <div class="note" id="rfc.section. 9.5.p.9">2324 <div class="note" id="rfc.section.8.5.p.9"> 2326 2325 <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. 2327 2326 It is therefore possible for a response to contain header fields for both Location and Content-Location. … … 2330 2329 <div id="rfc.iref.m.9"></div> 2331 2330 <div id="rfc.iref.h.7"></div> 2332 <h2 id="rfc.section. 9.6"><a href="#rfc.section.9.6">9.6</a> <a id="header.max-forwards" href="#header.max-forwards">Max-Forwards</a></h2>2333 <p id="rfc.section. 9.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 attempting2331 <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 attempting 2334 2333 to trace a request which appears to be failing or looping mid-chain. 2335 2334 </p> 2336 2335 <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> 2337 </pre><p id="rfc.section. 9.6.p.3">The Max-Forwards value is a decimal integer indicating the remaining number of times this request message can be forwarded.</p>2338 <p id="rfc.section. 9.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).2339 </p> 2340 <p id="rfc.section. 9.6.p.5">The Max-Forwards header field <em class="bcp14">MAY</em> be ignored for all other request methods.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. 2341 2340 </p> 2342 2341 <div id="rfc.iref.r.1"></div> 2343 2342 <div id="rfc.iref.h.8"></div> 2344 <h2 id="rfc.section. 9.7"><a href="#rfc.section.9.7">9.7</a> <a id="header.referer" href="#header.referer">Referer</a></h2>2345 <p id="rfc.section. 9.7.p.1">The "Referer" [sic] header field allows the client to specify the URI of the resource from which the target URI was obtained2343 <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 obtained 2346 2345 (the "referrer", although the header field is misspelled.). 2347 2346 </p> 2348 <p id="rfc.section. 9.7.p.2">The Referer header field allows servers to generate lists of back-links to resources for interest, logging, optimized caching,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, 2349 2348 etc. It also allows obsolete or mistyped links to be traced for maintenance. Some servers use Referer as a means of controlling 2350 2349 where they allow links from (so-called "deep linking"), but legitimate requests do not always contain a Referer header field. 2351 2350 </p> 2352 <p id="rfc.section. 9.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 Referer2351 <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 Referer 2353 2352 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 2354 2353 non-HTTP URIs (e.g., FTP). 2355 2354 </p> 2356 2355 <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> 2357 </pre><p id="rfc.section. 9.7.p.5">Example:</p>2356 </pre><p id="rfc.section.8.7.p.5">Example:</p> 2358 2357 <div id="rfc.figure.u.30"></div><pre class="text"> Referer: http://www.example.org/hypertext/Overview.html 2359 </pre><p id="rfc.section. 9.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 11.2</a> for security considerations.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. 2360 2359 </p> 2361 2360 <div id="rfc.iref.r.2"></div> 2362 2361 <div id="rfc.iref.h.9"></div> 2363 <h2 id="rfc.section. 9.8"><a href="#rfc.section.9.8">9.8</a> <a id="header.retry-after" href="#header.retry-after">Retry-After</a></h2>2364 <p id="rfc.section. 9.8.p.1">The header "Retry-After" field can be used with a 503 (Service Unavailable) response to indicate how long the service is expected2362 <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 expected 2365 2364 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 2366 2365 the redirected request. 2367 2366 </p> 2368 <p id="rfc.section. 9.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>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> 2369 2368 <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> 2370 2369 </pre><div id="rule.delta-seconds"> 2371 <p id="rfc.section. 9.8.p.4"> Time spans are non-negative decimal integers, representing time in seconds.</p>2370 <p id="rfc.section.8.8.p.4"> Time spans are non-negative decimal integers, representing time in seconds.</p> 2372 2371 </div> 2373 2372 <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> 2374 </pre><p id="rfc.section. 9.8.p.6">Two examples of its use are</p>2373 </pre><p id="rfc.section.8.8.p.6">Two examples of its use are</p> 2375 2374 <div id="rfc.figure.u.33"></div><pre class="text"> Retry-After: Fri, 31 Dec 1999 23:59:59 GMT 2376 2375 Retry-After: 120 2377 </pre><p id="rfc.section. 9.8.p.8">In the latter example, the delay is 2 minutes.</p>2376 </pre><p id="rfc.section.8.8.p.8">In the latter example, the delay is 2 minutes.</p> 2378 2377 <div id="rfc.iref.s.38"></div> 2379 2378 <div id="rfc.iref.h.10"></div> 2380 <h2 id="rfc.section. 9.9"><a href="#rfc.section.9.9">9.9</a> <a id="header.server" href="#header.server">Server</a></h2>2381 <p id="rfc.section. 9.9.p.1">The "Server" header field contains information about the software used by the origin server to handle the request.</p>2382 <p id="rfc.section. 9.9.p.2">The field can contain multiple product tokens (<a href="#product.tokens" title="Product Tokens">Section 8.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 for2379 <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 for 2383 2382 identifying the application. 2384 2383 </p> 2385 2384 <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> ) ) 2386 </pre><p id="rfc.section. 9.9.p.4">Example:</p>2385 </pre><p id="rfc.section.8.9.p.4">Example:</p> 2387 2386 <div id="rfc.figure.u.35"></div><pre class="text"> Server: CERN/3.0 libwww/2.17 2388 </pre><p id="rfc.section. 9.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>).2389 </p> 2390 <div class="note" id="rfc.section. 9.9.p.7">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"> 2391 2390 <p> <b>Note:</b> Revealing the specific software version of the server might allow the server machine to become more vulnerable to attacks 2392 2391 against software that is known to contain security holes. Server implementors are encouraged to make this field a configurable … … 2396 2395 <div id="rfc.iref.u.1"></div> 2397 2396 <div id="rfc.iref.h.11"></div> 2398 <h2 id="rfc.section. 9.10"><a href="#rfc.section.9.10">9.10</a> <a id="header.user-agent" href="#header.user-agent">User-Agent</a></h2>2399 <p id="rfc.section. 9.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.2400 </p> 2401 <p id="rfc.section. 9.10.p.2">Typically, it is used for statistical purposes, the tracing of protocol violations, and tailoring responses to avoid particular2397 <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 particular 2402 2401 user agent limitations. 2403 2402 </p> 2404 <p id="rfc.section. 9.10.p.3">The field can contain multiple product tokens (<a href="#product.tokens" title="Product Tokens">Section 8.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 significance2403 <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 significance 2405 2404 for identifying the application. 2406 2405 </p> 2407 <p id="rfc.section. 9.10.p.4">Because this field is usually sent on every request a user agent makes, implementations are encouraged not to include needlessly2406 <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 needlessly 2408 2407 fine-grained detail, and to limit (or even prohibit) the addition of subproducts by third parties. Overly long and detailed 2409 2408 User-Agent field values make requests larger and can also be used to identify ("fingerprint") the user against their wishes. 2410 2409 </p> 2411 <p id="rfc.section. 9.10.p.5">Likewise, implementations are encouraged not to use the product tokens of other implementations in order to declare compatibility2410 <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 compatibility 2412 2411 with them, as this circumvents the purpose of the field. Finally, they are encouraged not to use comments to identify products; 2413 2412 doing so makes the field value more difficult to parse. 2414 2413 </p> 2415 2414 <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> ) ) 2416 </pre><p id="rfc.section. 9.10.p.7">Example:</p>2415 </pre><p id="rfc.section.8.10.p.7">Example:</p> 2417 2416 <div id="rfc.figure.u.37"></div><pre class="text"> User-Agent: CERN-LineMode/2.15 libwww/2.17b3 2418 </pre><h1 id="rfc.section. 10"><a href="#rfc.section.10">10.</a> <a id="IANA.considerations" href="#IANA.considerations">IANA Considerations</a></h1>2419 <h2 id="rfc.section. 10.1"><a href="#rfc.section.10.1">10.1</a> <a id="method.registration" href="#method.registration">Method Registry</a></h2>2420 <p id="rfc.section. 10.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.2421 </p> 2422 <p id="rfc.section. 10.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: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: 2423 2422 </p> 2424 2423 <div id="rfc.table.1"> … … 2484 2483 </table> 2485 2484 </div> 2486 <h2 id="rfc.section. 10.2"><a href="#rfc.section.10.2">10.2</a> <a id="status.code.registration" href="#status.code.registration">Status Code Registry</a></h2>2487 <p id="rfc.section. 10.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.2488 </p> 2489 <p id="rfc.section. 10.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: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: 2490 2489 </p> 2491 2490 <div id="rfc.table.2"> … … 2503 2502 <td class="left">100</td> 2504 2503 <td class="left">Continue</td> 2505 <td class="left"> <a href="#status.100" id="rfc.xref.status.100.2" title="100 Continue">Section 7.1.1</a>2504 <td class="left"> <a href="#status.100" id="rfc.xref.status.100.2" title="100 Continue">Section 4.3.1.1</a> 2506 2505 </td> 2507 2506 </tr> … … 2509 2508 <td class="left">101</td> 2510 2509 <td class="left">Switching Protocols</td> 2511 <td class="left"> <a href="#status.101" id="rfc.xref.status.101.2" title="101 Switching Protocols">Section 7.1.2</a>2510 <td class="left"> <a href="#status.101" id="rfc.xref.status.101.2" title="101 Switching Protocols">Section 4.3.1.2</a> 2512 2511 </td> 2513 2512 </tr> … … 2515 2514 <td class="left">200</td> 2516 2515 <td class="left">OK</td> 2517 <td class="left"> <a href="#status.200" id="rfc.xref.status.200.2" title="200 OK">Section 7.2.1</a>2516 <td class="left"> <a href="#status.200" id="rfc.xref.status.200.2" title="200 OK">Section 4.3.2.1</a> 2518 2517 </td> 2519 2518 </tr> … … 2521 2520 <td class="left">201</td> 2522 2521 <td class="left">Created</td> 2523 <td class="left"> <a href="#status.201" id="rfc.xref.status.201.2" title="201 Created">Section 7.2.2</a>2522 <td class="left"> <a href="#status.201" id="rfc.xref.status.201.2" title="201 Created">Section 4.3.2.2</a> 2524 2523 </td> 2525 2524 </tr> … … 2527 2526 <td class="left">202</td> 2528 2527 <td class="left">Accepted</td> 2529 <td class="left"> <a href="#status.202" id="rfc.xref.status.202.2" title="202 Accepted">Section 7.2.3</a>2528 <td class="left"> <a href="#status.202" id="rfc.xref.status.202.2" title="202 Accepted">Section 4.3.2.3</a> 2530 2529 </td> 2531 2530 </tr> … … 2533 2532 <td class="left">203</td> 2534 2533 <td class="left">Non-Authoritative Information</td> 2535 <td class="left"> <a href="#status.203" id="rfc.xref.status.203.2" title="203 Non-Authoritative Information">Section 7.2.4</a>2534 <td class="left"> <a href="#status.203" id="rfc.xref.status.203.2" title="203 Non-Authoritative Information">Section 4.3.2.4</a> 2536 2535 </td> 2537 2536 </tr> … … 2539 2538 <td class="left">204</td> 2540 2539 <td class="left">No Content</td> 2541 <td class="left"> <a href="#status.204" id="rfc.xref.status.204.2" title="204 No Content">Section 7.2.5</a>2540 <td class="left"> <a href="#status.204" id="rfc.xref.status.204.2" title="204 No Content">Section 4.3.2.5</a> 2542 2541 </td> 2543 2542 </tr> … … 2545 2544 <td class="left">205</td> 2546 2545 <td class="left">Reset Content</td> 2547 <td class="left"> <a href="#status.205" id="rfc.xref.status.205.2" title="205 Reset Content">Section 7.2.6</a>2546 <td class="left"> <a href="#status.205" id="rfc.xref.status.205.2" title="205 Reset Content">Section 4.3.2.6</a> 2548 2547 </td> 2549 2548 </tr> … … 2551 2550 <td class="left">300</td> 2552 2551 <td class="left">Multiple Choices</td> 2553 <td class="left"> <a href="#status.300" id="rfc.xref.status.300.2" title="300 Multiple Choices">Section 7.3.1</a>2552 <td class="left"> <a href="#status.300" id="rfc.xref.status.300.2" title="300 Multiple Choices">Section 4.3.3.1</a> 2554 2553 </td> 2555 2554 </tr> … … 2557 2556 <td class="left">301</td> 2558 2557 <td class="left">Moved Permanently</td> 2559 <td class="left"> <a href="#status.301" id="rfc.xref.status.301.2" title="301 Moved Permanently">Section 7.3.2</a>2558 <td class="left"> <a href="#status.301" id="rfc.xref.status.301.2" title="301 Moved Permanently">Section 4.3.3.2</a> 2560 2559 </td> 2561 2560 </tr> … … 2563 2562 <td class="left">302</td> 2564 2563 <td class="left">Found</td> 2565 <td class="left"> <a href="#status.302" id="rfc.xref.status.302.2" title="302 Found">Section 7.3.3</a>2564 <td class="left"> <a href="#status.302" id="rfc.xref.status.302.2" title="302 Found">Section 4.3.3.3</a> 2566 2565 </td> 2567 2566 </tr> … … 2569 2568 <td class="left">303</td> 2570 2569 <td class="left">See Other</td> 2571 <td class="left"> <a href="#status.303" id="rfc.xref.status.303.2" title="303 See Other">Section 7.3.4</a>2570 <td class="left"> <a href="#status.303" id="rfc.xref.status.303.2" title="303 See Other">Section 4.3.3.4</a> 2572 2571 </td> 2573 2572 </tr> … … 2575 2574 <td class="left">305</td> 2576 2575 <td class="left">Use Proxy</td> 2577 <td class="left"> <a href="#status.305" id="rfc.xref.status.305.2" title="305 Use Proxy">Section 7.3.5</a>2576 <td class="left"> <a href="#status.305" id="rfc.xref.status.305.2" title="305 Use Proxy">Section 4.3.3.5</a> 2578 2577 </td> 2579 2578 </tr> … … 2581 2580 <td class="left">306</td> 2582 2581 <td class="left">(Unused)</td> 2583 <td class="left"> <a href="#status.306" id="rfc.xref.status.306.1" title="306 (Unused)">Section 7.3.6</a>2582 <td class="left"> <a href="#status.306" id="rfc.xref.status.306.1" title="306 (Unused)">Section 4.3.3.6</a> 2584 2583 </td> 2585 2584 </tr> … … 2587 2586 <td class="left">307</td> 2588 2587 <td class="left">Temporary Redirect</td> 2589 <td class="left"> <a href="#status.307" id="rfc.xref.status.307.2" title="307 Temporary Redirect">Section 7.3.7</a>2588 <td class="left"> <a href="#status.307" id="rfc.xref.status.307.2" title="307 Temporary Redirect">Section 4.3.3.7</a> 2590 2589 </td> 2591 2590 </tr> … … 2593 2592 <td class="left">400</td> 2594 2593 <td class="left">Bad Request</td> 2595 <td class="left"> <a href="#status.400" id="rfc.xref.status.400.2" title="400 Bad Request">Section 7.4.1</a>2594 <td class="left"> <a href="#status.400" id="rfc.xref.status.400.2" title="400 Bad Request">Section 4.3.4.1</a> 2596 2595 </td> 2597 2596 </tr> … … 2599 2598 <td class="left">402</td> 2600 2599 <td class="left">Payment Required</td> 2601 <td class="left"> <a href="#status.402" id="rfc.xref.status.402.2" title="402 Payment Required">Section 7.4.2</a>2600 <td class="left"> <a href="#status.402" id="rfc.xref.status.402.2" title="402 Payment Required">Section 4.3.4.2</a> 2602 2601 </td> 2603 2602 </tr> … … 2605 2604 <td class="left">403</td> 2606 2605 <td class="left">Forbidden</td> 2607 <td class="left"> <a href="#status.403" id="rfc.xref.status.403.2" title="403 Forbidden">Section 7.4.3</a>2606 <td class="left"> <a href="#status.403" id="rfc.xref.status.403.2" title="403 Forbidden">Section 4.3.4.3</a> 2608 2607 </td> 2609 2608 </tr> … … 2611 2610 <td class="left">404</td> 2612 2611 <td class="left">Not Found</td> 2613 <td class="left"> <a href="#status.404" id="rfc.xref.status.404.2" title="404 Not Found">Section 7.4.4</a>2612 <td class="left"> <a href="#status.404" id="rfc.xref.status.404.2" title="404 Not Found">Section 4.3.4.4</a> 2614 2613 </td> 2615 2614 </tr> … … 2617 2616 <td class="left">405</td> 2618 2617 <td class="left">Method Not Allowed</td> 2619 <td class="left"> <a href="#status.405" id="rfc.xref.status.405.2" title="405 Method Not Allowed">Section 7.4.5</a>2618 <td class="left"> <a href="#status.405" id="rfc.xref.status.405.2" title="405 Method Not Allowed">Section 4.3.4.5</a> 2620 2619 </td> 2621 2620 </tr> … … 2623 2622 <td class="left">406</td> 2624 2623 <td class="left">Not Acceptable</td> 2625 <td class="left"> <a href="#status.406" id="rfc.xref.status.406.2" title="406 Not Acceptable">Section 7.4.6</a>2624 <td class="left"> <a href="#status.406" id="rfc.xref.status.406.2" title="406 Not Acceptable">Section 4.3.4.6</a> 2626 2625 </td> 2627 2626 </tr> … … 2629 2628 <td class="left">408</td> 2630 2629 <td class="left">Request Timeout</td> 2631 <td class="left"> <a href="#status.408" id="rfc.xref.status.408.2" title="408 Request Timeout">Section 7.4.7</a>2630 <td class="left"> <a href="#status.408" id="rfc.xref.status.408.2" title="408 Request Timeout">Section 4.3.4.7</a> 2632 2631 </td> 2633 2632 </tr> … … 2635 2634 <td class="left">409</td> 2636 2635 <td class="left">Conflict</td> 2637 <td class="left"> <a href="#status.409" id="rfc.xref.status.409.2" title="409 Conflict">Section 7.4.8</a>2636 <td class="left"> <a href="#status.409" id="rfc.xref.status.409.2" title="409 Conflict">Section 4.3.4.8</a> 2638 2637 </td> 2639 2638 </tr> … … 2641 2640 <td class="left">410</td> 2642 2641 <td class="left">Gone</td> 2643 <td class="left"> <a href="#status.410" id="rfc.xref.status.410.2" title="410 Gone">Section 7.4.9</a>2642 <td class="left"> <a href="#status.410" id="rfc.xref.status.410.2" title="410 Gone">Section 4.3.4.9</a> 2644 2643 </td> 2645 2644 </tr> … … 2647 2646 <td class="left">411</td> 2648 2647 <td class="left">Length Required</td> 2649 <td class="left"> <a href="#status.411" id="rfc.xref.status.411.2" title="411 Length Required">Section 7.4.10</a>2648 <td class="left"> <a href="#status.411" id="rfc.xref.status.411.2" title="411 Length Required">Section 4.3.4.10</a> 2650 2649 </td> 2651 2650 </tr> … … 2653 2652 <td class="left">413</td> 2654 2653 <td class="left">Request Representation Too Large</td> 2655 <td class="left"> <a href="#status.413" id="rfc.xref.status.413.2" title="413 Request Representation Too Large">Section 7.4.11</a>2654 <td class="left"> <a href="#status.413" id="rfc.xref.status.413.2" title="413 Request Representation Too Large">Section 4.3.4.11</a> 2656 2655 </td> 2657 2656 </tr> … … 2659 2658 <td class="left">414</td> 2660 2659 <td class="left">URI Too Long</td> 2661 <td class="left"> <a href="#status.414" id="rfc.xref.status.414.2" title="414 URI Too Long">Section 7.4.12</a>2660 <td class="left"> <a href="#status.414" id="rfc.xref.status.414.2" title="414 URI Too Long">Section 4.3.4.12</a> 2662 2661 </td> 2663 2662 </tr> … … 2665 2664 <td class="left">415</td> 2666 2665 <td class="left">Unsupported Media Type</td> 2667 <td class="left"> <a href="#status.415" id="rfc.xref.status.415.2" title="415 Unsupported Media Type">Section 7.4.13</a>2666 <td class="left"> <a href="#status.415" id="rfc.xref.status.415.2" title="415 Unsupported Media Type">Section 4.3.4.13</a> 2668 2667 </td> 2669 2668 </tr> … … 2671 2670 <td class="left">417</td> 2672 2671 <td class="left">Expectation Failed</td> 2673 <td class="left"> <a href="#status.417" id="rfc.xref.status.417.2" title="417 Expectation Failed">Section 7.4.14</a>2672 <td class="left"> <a href="#status.417" id="rfc.xref.status.417.2" title="417 Expectation Failed">Section 4.3.4.14</a> 2674 2673 </td> 2675 2674 </tr> … … 2677 2676 <td class="left">426</td> 2678 2677 <td class="left">Upgrade Required</td> 2679 <td class="left"> <a href="#status.426" id="rfc.xref.status.426.2" title="426 Upgrade Required">Section 7.4.15</a>2678 <td class="left"> <a href="#status.426" id="rfc.xref.status.426.2" title="426 Upgrade Required">Section 4.3.4.15</a> 2680 2679 </td> 2681 2680 </tr> … … 2683 2682 <td class="left">500</td> 2684 2683 <td class="left">Internal Server Error</td> 2685 <td class="left"> <a href="#status.500" id="rfc.xref.status.500.2" title="500 Internal Server Error">Section 7.5.1</a>2684 <td class="left"> <a href="#status.500" id="rfc.xref.status.500.2" title="500 Internal Server Error">Section 4.3.5.1</a> 2686 2685 </td> 2687 2686 </tr> … … 2689 2688 <td class="left">501</td> 2690 2689 <td class="left">Not Implemented</td> 2691 <td class="left"> <a href="#status.501" id="rfc.xref.status.501.2" title="501 Not Implemented">Section 7.5.2</a>2690 <td class="left"> <a href="#status.501" id="rfc.xref.status.501.2" title="501 Not Implemented">Section 4.3.5.2</a> 2692 2691 </td> 2693 2692 </tr> … … 2695 2694 <td class="left">502</td> 2696 2695 <td class="left">Bad Gateway</td> 2697 <td class="left"> <a href="#status.502" id="rfc.xref.status.502.2" title="502 Bad Gateway">Section 7.5.3</a>2696 <td class="left"> <a href="#status.502" id="rfc.xref.status.502.2" title="502 Bad Gateway">Section 4.3.5.3</a> 2698 2697 </td> 2699 2698 </tr> … … 2701 2700 <td class="left">503</td> 2702 2701 <td class="left">Service Unavailable</td> 2703 <td class="left"> <a href="#status.503" id="rfc.xref.status.503.2" title="503 Service Unavailable">Section 7.5.4</a>2702 <td class="left"> <a href="#status.503" id="rfc.xref.status.503.2" title="503 Service Unavailable">Section 4.3.5.4</a> 2704 2703 </td> 2705 2704 </tr> … … 2707 2706 <td class="left">504</td> 2708 2707 <td class="left">Gateway Timeout</td> 2709 <td class="left"> <a href="#status.504" id="rfc.xref.status.504.2" title="504 Gateway Timeout">Section 7.5.5</a>2708 <td class="left"> <a href="#status.504" id="rfc.xref.status.504.2" title="504 Gateway Timeout">Section 4.3.5.5</a> 2710 2709 </td> 2711 2710 </tr> … … 2713 2712 <td class="left">505</td> 2714 2713 <td class="left">HTTP Version Not Supported</td> 2715 <td class="left"> <a href="#status.505" id="rfc.xref.status.505.2" title="505 HTTP Version Not Supported">Section 7.5.6</a>2714 <td class="left"> <a href="#status.505" id="rfc.xref.status.505.2" title="505 HTTP Version Not Supported">Section 4.3.5.6</a> 2716 2715 </td> 2717 2716 </tr> … … 2719 2718 </table> 2720 2719 </div> 2721 <h2 id="rfc.section. 10.3"><a href="#rfc.section.10.3">10.3</a> <a id="header.field.registration" href="#header.field.registration">Header Field Registration</a></h2>2722 <p id="rfc.section. 10.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>):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>): 2723 2722 </p> 2724 2723 <div id="rfc.table.3"> … … 2738 2737 <td class="left">http</td> 2739 2738 <td class="left">standard</td> 2740 <td class="left"> <a href="#header.allow" id="rfc.xref.header.allow.3" title="Allow">Section 9.1</a>2739 <td class="left"> <a href="#header.allow" id="rfc.xref.header.allow.3" title="Allow">Section 8.1</a> 2741 2740 </td> 2742 2741 </tr> … … 2745 2744 <td class="left">http</td> 2746 2745 <td class="left">standard</td> 2747 <td class="left"> <a href="#header.date" id="rfc.xref.header.date.2" title="Date">Section 9.2</a>2746 <td class="left"> <a href="#header.date" id="rfc.xref.header.date.2" title="Date">Section 8.2</a> 2748 2747 </td> 2749 2748 </tr> … … 2752 2751 <td class="left">http</td> 2753 2752 <td class="left">standard</td> 2754 <td class="left"> <a href="#header.expect" id="rfc.xref.header.expect.3" title="Expect">Section 9.3</a>2753 <td class="left"> <a href="#header.expect" id="rfc.xref.header.expect.3" title="Expect">Section 8.3</a> 2755 2754 </td> 2756 2755 </tr> … … 2759 2758 <td class="left">http</td> 2760 2759 <td class="left">standard</td> 2761 <td class="left"> <a href="#header.from" id="rfc.xref.header.from.2" title="From">Section 9.4</a>2760 <td class="left"> <a href="#header.from" id="rfc.xref.header.from.2" title="From">Section 8.4</a> 2762 2761 </td> 2763 2762 </tr> … … 2766 2765 <td class="left">http</td> 2767 2766 <td class="left">standard</td> 2768 <td class="left"> <a href="#header.location" id="rfc.xref.header.location.4" title="Location">Section 9.5</a>2767 <td class="left"> <a href="#header.location" id="rfc.xref.header.location.4" title="Location">Section 8.5</a> 2769 2768 </td> 2770 2769 </tr> … … 2773 2772 <td class="left">http</td> 2774 2773 <td class="left">standard</td> 2775 <td class="left"> <a href="#header.max-forwards" id="rfc.xref.header.max-forwards.4" title="Max-Forwards">Section 9.6</a>2774 <td class="left"> <a href="#header.max-forwards" id="rfc.xref.header.max-forwards.4" title="Max-Forwards">Section 8.6</a> 2776 2775 </td> 2777 2776 </tr> … … 2780 2779 <td class="left">http</td> 2781 2780 <td class="left">standard</td> 2782 <td class="left"> <a href="#header.referer" id="rfc.xref.header.referer.2" title="Referer">Section 9.7</a>2781 <td class="left"> <a href="#header.referer" id="rfc.xref.header.referer.2" title="Referer">Section 8.7</a> 2783 2782 </td> 2784 2783 </tr> … … 2787 2786 <td class="left">http</td> 2788 2787 <td class="left">standard</td> 2789 <td class="left"> <a href="#header.retry-after" id="rfc.xref.header.retry-after.3" title="Retry-After">Section 9.8</a>2788 <td class="left"> <a href="#header.retry-after" id="rfc.xref.header.retry-after.3" title="Retry-After">Section 8.8</a> 2790 2789 </td> 2791 2790 </tr> … … 2794 2793 <td class="left">http</td> 2795 2794 <td class="left">standard</td> 2796 <td class="left"> <a href="#header.server" id="rfc.xref.header.server.2" title="Server">Section 9.9</a>2795 <td class="left"> <a href="#header.server" id="rfc.xref.header.server.2" title="Server">Section 8.9</a> 2797 2796 </td> 2798 2797 </tr> … … 2801 2800 <td class="left">http</td> 2802 2801 <td class="left">standard</td> 2803 <td class="left"> <a href="#header.user-agent" id="rfc.xref.header.user-agent.2" title="User-Agent">Section 9.10</a>2802 <td class="left"> <a href="#header.user-agent" id="rfc.xref.header.user-agent.2" title="User-Agent">Section 8.10</a> 2804 2803 </td> 2805 2804 </tr> … … 2807 2806 </table> 2808 2807 </div> 2809 <p id="rfc.section. 10.3.p.2">The change controller is: "IETF (iesg@ietf.org) - Internet Engineering Task Force".</p>2810 <h1 id="rfc.section.1 1"><a href="#rfc.section.11">11.</a> <a id="security.considerations" href="#security.considerations">Security Considerations</a></h1>2811 <p id="rfc.section.1 1.p.1">This section is meant to inform application developers, information providers, and users of the security limitations in HTTP/1.12808 <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.1 2812 2811 as described by this document. The discussion does not include definitive solutions to the problems revealed, though it does 2813 2812 make some suggestions for reducing security risks. 2814 2813 </p> 2815 <h2 id="rfc.section.1 1.1"><a href="#rfc.section.11.1">11.1</a> <a id="security.sensitive" href="#security.sensitive">Transfer of Sensitive Information</a></h2>2816 <p id="rfc.section.1 1.1.p.1">Like any generic data transfer protocol, HTTP cannot regulate the content of the data that is transferred, nor is there any2814 <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 any 2817 2816 a priori method of determining the sensitivity of any particular piece of information within the context of any given request. 2818 2817 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 2819 2818 special mention in this context: Server, Via, Referer and From. 2820 2819 </p> 2821 <p id="rfc.section.1 1.1.p.2">Revealing the specific software version of the server might allow the server machine to become more vulnerable to attacks2820 <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 attacks 2822 2821 against software that is known to contain security holes. Implementors <em class="bcp14">SHOULD</em> make the Server header field a configurable option. 2823 2822 </p> 2824 <p id="rfc.section.1 1.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,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, 2825 2824 they <em class="bcp14">SHOULD</em> remove, or replace with sanitized versions, any Via fields generated behind the firewall. 2826 2825 </p> 2827 <p id="rfc.section.1 1.1.p.4">The Referer header field allows reading patterns to be studied and reverse links drawn. Although it can be very useful, its2826 <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, its 2828 2827 power can be abused if user details are not separated from the information contained in the Referer. Even when the personal 2829 2828 information has been removed, the Referer header field might indicate a private document's URI whose publication would be 2830 2829 inappropriate. 2831 2830 </p> 2832 <p id="rfc.section.1 1.1.p.5">The information sent in the From field might conflict with the user's privacy interests or their site's security policy, and2831 <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, and 2833 2832 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. 2834 2833 </p> 2835 <p id="rfc.section.1 1.1.p.6">We suggest, though do not require, that a convenient toggle interface be provided for the user to enable or disable the sending2834 <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 sending 2836 2835 of From and Referer information. 2837 2836 </p> 2838 <p id="rfc.section.1 1.1.p.7">The User-Agent (<a href="#header.user-agent" id="rfc.xref.header.user-agent.3" title="User-Agent">Section 9.10</a>) or Server (<a href="#header.server" id="rfc.xref.header.server.3" title="Server">Section 9.9</a>) header fields can sometimes be used to determine that a specific client or server has a particular security hole which might2837 <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 might 2839 2838 be exploited. Unfortunately, this same information is often used for other valuable purposes for which HTTP currently has 2840 2839 no better mechanism. 2841 2840 </p> 2842 <p id="rfc.section.1 1.1.p.8">Furthermore, the User-Agent header field may contain enough entropy to be used, possibly in conjunction with other material,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, 2843 2842 to uniquely identify the user. 2844 2843 </p> 2845 <p id="rfc.section.1 1.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 used2844 <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 used 2846 2845 to collect data from the client. 2847 2846 </p> 2848 <h2 id="rfc.section.1 1.2"><a href="#rfc.section.11.2">11.2</a> <a id="encoding.sensitive.information.in.uris" href="#encoding.sensitive.information.in.uris">Encoding Sensitive Information in URIs</a></h2>2849 <p id="rfc.section.1 1.2.p.1">Because the source of a link might be private information or might reveal an otherwise private information source, it is strongly2847 <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 strongly 2850 2849 recommended that the user be able to select whether or not the Referer field is sent. For example, a browser client could 2851 2850 have a toggle switch for browsing openly/anonymously, which would respectively enable/disable the sending of Referer and From 2852 2851 information. 2853 2852 </p> 2854 <p id="rfc.section.1 1.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.2855 </p> 2856 <p id="rfc.section.1 1.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 existing2853 <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 existing 2857 2856 servers, proxies, and user agents log or display the request-target in places where it might be visible to third parties. 2858 2857 Such services can use POST-based form submission instead. 2859 2858 </p> 2860 <h2 id="rfc.section.1 1.3"><a href="#rfc.section.11.3">11.3</a> <a id="location.spoofing-leakage" href="#location.spoofing-leakage">Location Header Fields: Spoofing and Information Leakage</a></h2>2861 <p id="rfc.section.1 1.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 organizations2859 <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 organizations 2862 2861 to make sure that they do not attempt to invalidate resources over which they have no authority. 2863 2862 </p> 2864 <p id="rfc.section.1 1.3.p.2">Furthermore, appending the fragment identifier from one URI to another one obtained from a Location header field might leak2863 <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 leak 2865 2864 confidential information to the target server — although the fragment identifier is not transmitted in the final request, 2866 2865 it might be visible to the user agent through other means, such as scripting. 2867 2866 </p> 2868 <h2 id="rfc.section.1 1.4"><a href="#rfc.section.11.4">11.4</a> Security Considerations for CONNECT2867 <h2 id="rfc.section.10.4"><a href="#rfc.section.10.4">10.4</a> Security Considerations for CONNECT 2869 2868 </h2> 2870 <p id="rfc.section.1 1.4.p.1">Since tunneled data is opaque to the proxy, there are additional risks to tunneling to other well-known or reserved ports.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. 2871 2870 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. 2872 2871 </p> 2873 <h1 id="rfc.section.1 2"><a href="#rfc.section.12">12.</a> <a id="acks" href="#acks">Acknowledgments</a></h1>2874 <p id="rfc.section.1 2.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>.2875 </p> 2876 <h1 id="rfc.references"><a id="rfc.section.1 3" href="#rfc.section.13">13.</a> References2872 <h1 id="rfc.section.11"><a href="#rfc.section.11">11.</a> <a id="acks" href="#acks">Acknowledgments</a></h1> 2873 <p id="rfc.section.11.p.1">See <a href="p1-messaging.html#acks" title="Acknowledgments">Section 9</a> of <a href="#Part1" id="rfc.xref.Part1.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.12" href="#rfc.section.12">12.</a> References 2877 2876 </h1> 2878 <h2 id="rfc.references.1"><a href="#rfc.section.1 3.1" id="rfc.section.13.1">13.1</a> Normative References2877 <h2 id="rfc.references.1"><a href="#rfc.section.12.1" id="rfc.section.12.1">12.1</a> Normative References 2879 2878 </h2> 2880 2879 <table> … … 2925 2924 </tr> 2926 2925 </table> 2927 <h2 id="rfc.references.2"><a href="#rfc.section.1 3.2" id="rfc.section.13.2">13.2</a> Informative References2926 <h2 id="rfc.references.2"><a href="#rfc.section.12.2" id="rfc.section.12.2">12.2</a> Informative References 2928 2927 </h2> 2929 2928 <table> … … 2999 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>) 3000 2999 </p> 3001 <p id="rfc.section.A.p.2">Clarify definition of POST. (<a href="#POST" id="rfc.xref.POST.3" title="POST">Section 6.5</a>) 3002 </p> 3003 <p id="rfc.section.A.p.3">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>) 3004 </p> 3005 <p id="rfc.section.A.p.4">Take over definition of CONNECT method from <a href="#RFC2817" id="rfc.xref.RFC2817.3"><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>) 3006 </p> 3007 <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 7.2.4</a>) 3008 </p> 3009 <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 7.3</a>) 3010 </p> 3011 <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 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 3012 3005 user agent is able to make that determination based on the request method semantics. Furthermore, allow user agents to rewrite 3013 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"> 7.3.2</a>, <a href="#status.302" id="rfc.xref.status.302.3" title="302 Found">7.3.3</a> and <a href="#status.307" id="rfc.xref.status.307.3" title="307 Temporary Redirect">7.3.7</a>)3014 </p> 3015 <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 resource3006 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 </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 resource 3016 3009 needs to be accessed through the proxy given by the Location field. The Location field gave the URI of the proxy. The recipient 3017 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 7.3.5</a>) 3018 </p> 3019 <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 7.4.15</a>) 3020 </p> 3021 <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 9</a>) 3010 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 </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>) 3022 3021 </p> 3023 3022 <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 3024 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 9.1</a>)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>) 3025 3024 </p> 3026 3025 <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 3027 (allowing trailing semicolons after "100-continue" when they were invalid before). (<a href="#header.expect" id="rfc.xref.header.expect.4" title="Expect">Section 9.3</a>)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>) 3028 3027 </p> 3029 3028 <p id="rfc.section.A.p.13">Correct syntax of Location header field to allow URI references (including relative references and fragments), as referred 3030 3029 symbol "absoluteURI" wasn't what was expected, and add some clarifications as to when use of fragments would not be appropriate. 3031 (<a href="#header.location" id="rfc.xref.header.location.5" title="Location">Section 9.5</a>)3032 </p> 3033 <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 9.6</a>)3034 </p> 3035 <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 9.7</a>)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>) 3036 3035 </p> 3037 3036 <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 3038 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 9.9</a>)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>) 3039 3038 </p> 3040 3039 <h1 id="rfc.section.B"><a href="#rfc.section.B">B.</a> <a id="collected.abnf" href="#collected.abnf">Collected ABNF</a></h1> … … 3479 3478 <ul class="ind"> 3480 3479 <li><a id="rfc.index.1" href="#rfc.index.1"><b>1</b></a><ul> 3481 <li>100 Continue (status code) <a href="#rfc.xref.status.100.1">4.1</a>, <a href="#rfc.iref. 22"><b>7.1.1</b></a>, <a href="#rfc.xref.status.100.2">10.2</a></li>3482 <li>100-continue (expect value) <a href="#rfc.iref.89"><b> 9.3</b></a></li>3483 <li>101 Switching Protocols (status code) <a href="#rfc.xref.status.101.1">4.1</a>, <a href="#rfc.iref. 23"><b>7.1.2</b></a>, <a href="#rfc.xref.status.101.2">10.2</a></li>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> 3484 3483 </ul> 3485 3484 </li> 3486 3485 <li><a id="rfc.index.2" href="#rfc.index.2"><b>2</b></a><ul> 3487 <li>200 OK (status code) <a href="#rfc.xref.status.200.1">4.1</a>, <a href="#rfc.iref. 24"><b>7.2.1</b></a>, <a href="#rfc.xref.status.200.2">10.2</a></li>3488 <li>201 Created (status code) <a href="#rfc.xref.status.201.1">4.1</a>, <a href="#rfc.iref. 25"><b>7.2.2</b></a>, <a href="#rfc.xref.status.201.2">10.2</a></li>3489 <li>202 Accepted (status code) <a href="#rfc.xref.status.202.1">4.1</a>, <a href="#rfc.iref. 26"><b>7.2.3</b></a>, <a href="#rfc.xref.status.202.2">10.2</a></li>3490 <li>203 Non-Authoritative Information (status code) <a href="#rfc.xref.status.203.1">4.1</a>, <a href="#rfc.iref. 27"><b>7.2.4</b></a>, <a href="#rfc.xref.status.203.2">10.2</a>, <a href="#rfc.xref.status.203.3">A</a></li>3491 <li>204 No Content (status code) <a href="#rfc.xref.status.204.1">4.1</a>, <a href="#rfc.iref. 28"><b>7.2.5</b></a>, <a href="#rfc.xref.status.204.2">10.2</a></li>3492 <li>205 Reset Content (status code) <a href="#rfc.xref.status.205.1">4.1</a>, <a href="#rfc.iref. 29"><b>7.2.6</b></a>, <a href="#rfc.xref.status.205.2">10.2</a></li>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> 3493 3492 </ul> 3494 3493 </li> 3495 3494 <li><a id="rfc.index.3" href="#rfc.index.3"><b>3</b></a><ul> 3496 <li>300 Multiple Choices (status code) <a href="#rfc.xref.status.300.1">4.1</a>, <a href="#rfc.iref. 30"><b>7.3.1</b></a>, <a href="#rfc.xref.status.300.2">10.2</a></li>3497 <li>301 Moved Permanently (status code) <a href="#rfc.xref.status.301.1">4.1</a>, <a href="#rfc.iref. 31"><b>7.3.2</b></a>, <a href="#rfc.xref.status.301.2">10.2</a>, <a href="#rfc.xref.status.301.3">A</a></li>3498 <li>302 Found (status code) <a href="#rfc.xref.status.302.1">4.1</a>, <a href="#rfc.iref. 32"><b>7.3.3</b></a>, <a href="#rfc.xref.status.302.2">10.2</a>, <a href="#rfc.xref.status.302.3">A</a></li>3499 <li>303 See Other (status code) <a href="#rfc.xref.status.303.1">4.1</a>, <a href="#rfc.iref. 33"><b>7.3.4</b></a>, <a href="#rfc.xref.status.303.2">10.2</a></li>3500 <li>305 Use Proxy (status code) <a href="#rfc.xref.status.305.1">4.1</a>, <a href="#rfc.iref. 34"><b>7.3.5</b></a>, <a href="#rfc.xref.status.305.2">10.2</a>, <a href="#rfc.xref.status.305.3">A</a></li>3501 <li>306 (Unused) (status code) <a href="#rfc.iref. 35"><b>7.3.6</b></a>, <a href="#rfc.xref.status.306.1">10.2</a></li>3502 <li>307 Temporary Redirect (status code) <a href="#rfc.xref.status.307.1">4.1</a>, <a href="#rfc.iref. 36"><b>7.3.7</b></a>, <a href="#rfc.xref.status.307.2">10.2</a>, <a href="#rfc.xref.status.307.3">A</a></li>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> 3503 3502 </ul> 3504 3503 </li> 3505 3504 <li><a id="rfc.index.4" href="#rfc.index.4"><b>4</b></a><ul> 3506 <li>400 Bad Request (status code) <a href="#rfc.xref.status.400.1">4.1</a>, <a href="#rfc.iref. 37"><b>7.4.1</b></a>, <a href="#rfc.xref.status.400.2">10.2</a></li>3507 <li>402 Payment Required (status code) <a href="#rfc.xref.status.402.1">4.1</a>, <a href="#rfc.iref. 38"><b>7.4.2</b></a>, <a href="#rfc.xref.status.402.2">10.2</a></li>3508 <li>403 Forbidden (status code) <a href="#rfc.xref.status.403.1">4.1</a>, <a href="#rfc.iref. 39"><b>7.4.3</b></a>, <a href="#rfc.xref.status.403.2">10.2</a></li>3509 <li>404 Not Found (status code) <a href="#rfc.xref.status.404.1">4.1</a>, <a href="#rfc.iref. 40"><b>7.4.4</b></a>, <a href="#rfc.xref.status.404.2">10.2</a></li>3510 <li>405 Method Not Allowed (status code) <a href="#rfc.xref.status.405.1">4.1</a>, <a href="#rfc.iref. 41"><b>7.4.5</b></a>, <a href="#rfc.xref.status.405.2">10.2</a></li>3511 <li>406 Not Acceptable (status code) <a href="#rfc.xref.status.406.1">4.1</a>, <a href="#rfc.iref. 42"><b>7.4.6</b></a>, <a href="#rfc.xref.status.406.2">10.2</a></li>3512 <li>408 Request Timeout (status code) <a href="#rfc.xref.status.408.1">4.1</a>, <a href="#rfc.iref. 43"><b>7.4.7</b></a>, <a href="#rfc.xref.status.408.2">10.2</a></li>3513 <li>409 Conflict (status code) <a href="#rfc.xref.status.409.1">4.1</a>, <a href="#rfc.iref. 44"><b>7.4.8</b></a>, <a href="#rfc.xref.status.409.2">10.2</a></li>3514 <li>410 Gone (status code) <a href="#rfc.xref.status.410.1">4.1</a>, <a href="#rfc.iref. 45"><b>7.4.9</b></a>, <a href="#rfc.xref.status.410.2">10.2</a></li>3515 <li>411 Length Required (status code) <a href="#rfc.xref.status.411.1">4.1</a>, <a href="#rfc.iref. 46"><b>7.4.10</b></a>, <a href="#rfc.xref.status.411.2">10.2</a></li>3516 <li>413 Request Representation Too Large (status code) <a href="#rfc.xref.status.413.1">4.1</a>, <a href="#rfc.iref. 47"><b>7.4.11</b></a>, <a href="#rfc.xref.status.413.2">10.2</a></li>3517 <li>414 URI Too Long (status code) <a href="#rfc.xref.status.414.1">4.1</a>, <a href="#rfc.iref. 48"><b>7.4.12</b></a>, <a href="#rfc.xref.status.414.2">10.2</a></li>3518 <li>415 Unsupported Media Type (status code) <a href="#rfc.xref.status.415.1">4.1</a>, <a href="#rfc.iref. 49"><b>7.4.13</b></a>, <a href="#rfc.xref.status.415.2">10.2</a></li>3519 <li>417 Expectation Failed (status code) <a href="#rfc.xref.status.417.1">4.1</a>, <a href="#rfc.iref. 50"><b>7.4.14</b></a>, <a href="#rfc.xref.status.417.2">10.2</a></li>3520 <li>426 Upgrade Required (status code) <a href="#rfc.xref.status.426.1">4.1</a>, <a href="#rfc.iref. 51"><b>7.4.15</b></a>, <a href="#rfc.xref.status.426.2">10.2</a>, <a href="#rfc.xref.status.426.3">A</a></li>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> 3521 3520 </ul> 3522 3521 </li> 3523 3522 <li><a id="rfc.index.5" href="#rfc.index.5"><b>5</b></a><ul> 3524 <li>500 Internal Server Error (status code) <a href="#rfc.xref.status.500.1">4.1</a>, <a href="#rfc.iref. 52"><b>7.5.1</b></a>, <a href="#rfc.xref.status.500.2">10.2</a></li>3525 <li>501 Not Implemented (status code) <a href="#rfc.xref.status.501.1">4.1</a>, <a href="#rfc.iref. 53"><b>7.5.2</b></a>, <a href="#rfc.xref.status.501.2">10.2</a></li>3526 <li>502 Bad Gateway (status code) <a href="#rfc.xref.status.502.1">4.1</a>, <a href="#rfc.iref. 54"><b>7.5.3</b></a>, <a href="#rfc.xref.status.502.2">10.2</a></li>3527 <li>503 Service Unavailable (status code) <a href="#rfc.xref.status.503.1">4.1</a>, <a href="#rfc.iref. 55"><b>7.5.4</b></a>, <a href="#rfc.xref.status.503.2">10.2</a></li>3528 <li>504 Gateway Timeout (status code) <a href="#rfc.xref.status.504.1">4.1</a>, <a href="#rfc.iref. 56"><b>7.5.5</b></a>, <a href="#rfc.xref.status.504.2">10.2</a></li>3529 <li>505 HTTP Version Not Supported (status code) <a href="#rfc.xref.status.505.1">4.1</a>, <a href="#rfc.iref. 57"><b>7.5.6</b></a>, <a href="#rfc.xref.status.505.2">10.2</a></li>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> 3530 3529 </ul> 3531 3530 </li> 3532 3531 <li><a id="rfc.index.A" href="#rfc.index.A"><b>A</b></a><ul> 3533 <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> 9.1</b></a>, <a href="#rfc.xref.header.allow.3">10.3</a>, <a href="#rfc.xref.header.allow.4">A</a></li>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> 3534 3533 </ul> 3535 3534 </li> 3536 3535 <li><a id="rfc.index.C" href="#rfc.index.C"><b>C</b></a><ul> 3537 <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"> 10.1</a>, <a href="#rfc.xref.CONNECT.3">A</a></li>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> 3538 3537 </ul> 3539 3538 </li> 3540 3539 <li><a id="rfc.index.D" href="#rfc.index.D"><b>D</b></a><ul> 3541 <li>Date header field <a href="#rfc.xref.header.date.1">3.3</a>, <a href="#rfc.iref.d.2"><b> 9.2</b></a>, <a href="#rfc.xref.header.date.2">10.3</a></li>3542 <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"> 10.1</a></li>3543 <li><em>draft-reschke-http-status-308</em> <a href="#rfc.xref.draft-reschke-http-status-308.1"> 7.3.7</a>, <a href="#draft-reschke-http-status-308"><b>13.2</b></a></li>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>12.2</b></a></li> 3544 3543 </ul> 3545 3544 </li> 3546 3545 <li><a id="rfc.index.E" href="#rfc.index.E"><b>E</b></a><ul> 3547 <li>Expect header field <a href="#rfc.xref.header.expect.1">3.2</a>, <a href="#rfc.xref.header.expect.2"> 7.4.14</a>, <a href="#rfc.iref.e.1"><b>9.3</b></a>, <a href="#rfc.xref.header.expect.3">10.3</a>, <a href="#rfc.xref.header.expect.4">A</a></li>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> 3548 3547 <li>Expect Values 3549 3548 <ul> 3550 <li>100-continue <a href="#rfc.iref.e.2"><b> 9.3</b></a></li>3549 <li>100-continue <a href="#rfc.iref.e.2"><b>8.3</b></a></li> 3551 3550 </ul> 3552 3551 </li> … … 3554 3553 </li> 3555 3554 <li><a id="rfc.index.F" href="#rfc.index.F"><b>F</b></a><ul> 3556 <li>From header field <a href="#rfc.xref.header.from.1">3.2</a>, <a href="#rfc.iref.f.1"><b> 9.4</b></a>, <a href="#rfc.xref.header.from.2">10.3</a></li>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> 3557 3556 </ul> 3558 3557 </li> 3559 3558 <li><a id="rfc.index.G" href="#rfc.index.G"><b>G</b></a><ul> 3560 <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"> 10.1</a></li>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> 3561 3560 <li><tt>Grammar</tt> 3562 3561 <ul> 3563 <li><tt>Allow</tt> <a href="#rfc.iref.g.24"><b> 9.1</b></a></li>3564 <li><tt>asctime-date</tt> <a href="#rfc.iref.g.21"><b> 8.1</b></a></li>3565 <li><tt>Date</tt> <a href="#rfc.iref.g.25"><b> 9.2</b></a></li>3566 <li><tt>date1</tt> <a href="#rfc.iref.g.8"><b> 8.1</b></a></li>3567 <li><tt>day</tt> <a href="#rfc.iref.g.15"><b> 8.1</b></a></li>3568 <li><tt>day-name</tt> <a href="#rfc.iref.g.13"><b> 8.1</b></a></li>3569 <li><tt>day-name-l</tt> <a href="#rfc.iref.g.14"><b> 8.1</b></a></li>3570 <li><tt>delta-seconds</tt> <a href="#rfc.iref.g.36"><b> 9.8</b></a></li>3571 <li><tt>Expect</tt> <a href="#rfc.iref.g.26"><b> 9.3</b></a></li>3572 <li><tt>expect-name</tt> <a href="#rfc.iref.g.30"><b> 9.3</b></a></li>3573 <li><tt>expect-param</tt> <a href="#rfc.iref.g.28"><b> 9.3</b></a></li>3574 <li><tt>expect-value</tt> <a href="#rfc.iref.g.29"><b> 9.3</b></a></li>3575 <li><tt>expectation</tt> <a href="#rfc.iref.g.27"><b> 9.3</b></a></li>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> 3576 3575 <li><tt>extension-code</tt> <a href="#rfc.iref.g.3"><b>4</b></a></li> 3577 <li><tt>From</tt> <a href="#rfc.iref.g.31"><b> 9.4</b></a></li>3578 <li><tt>GMT</tt> <a href="#rfc.iref.g.18"><b> 8.1</b></a></li>3579 <li><tt>hour</tt> <a href="#rfc.iref.g.10"><b> 8.1</b></a></li>3580 <li><tt>HTTP-date</tt> <a href="#rfc.iref.g.6"><b> 8.1</b></a></li>3581 <li><tt>Location</tt> <a href="#rfc.iref.g.32"><b> 9.5</b></a></li>3582 <li><tt>Max-Forwards</tt> <a href="#rfc.iref.g.33"><b> 9.6</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> 3583 3582 <li><tt>method</tt> <a href="#rfc.iref.g.1"><b>2</b></a></li> 3584 <li><tt>minute</tt> <a href="#rfc.iref.g.11"><b> 8.1</b></a></li>3585 <li><tt>month</tt> <a href="#rfc.iref.g.16"><b> 8.1</b></a></li>3586 <li><tt>obs-date</tt> <a href="#rfc.iref.g.19"><b> 8.1</b></a></li>3587 <li><tt>product</tt> <a href="#rfc.iref.g.22"><b> 8.2</b></a></li>3588 <li><tt>product-version</tt> <a href="#rfc.iref.g.23"><b> 8.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> 3589 3588 <li><tt>reason-phrase</tt> <a href="#rfc.iref.g.4"><b>4</b></a></li> 3590 <li><tt>Referer</tt> <a href="#rfc.iref.g.34"><b> 9.7</b></a></li>3591 <li><tt>Retry-After</tt> <a href="#rfc.iref.g.35"><b> 9.8</b></a></li>3592 <li><tt>rfc1123-date</tt> <a href="#rfc.iref.g.7"><b> 8.1</b></a></li>3593 <li><tt>rfc850-date</tt> <a href="#rfc.iref.g.20"><b> 8.1</b></a></li>3594 <li><tt>second</tt> <a href="#rfc.iref.g.12"><b> 8.1</b></a></li>3595 <li><tt>Server</tt> <a href="#rfc.iref.g.37"><b> 9.9</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> 3596 3595 <li><tt>status-code</tt> <a href="#rfc.iref.g.2"><b>4</b></a></li> 3597 <li><tt>time-of-day</tt> <a href="#rfc.iref.g.9"><b> 8.1</b></a></li>3598 <li><tt>User-Agent</tt> <a href="#rfc.iref.g.38"><b> 9.10</b></a></li>3599 <li><tt>year</tt> <a href="#rfc.iref.g.17"><b> 8.1</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> 3600 3599 </ul> 3601 3600 </li> … … 3603 3602 </li> 3604 3603 <li><a id="rfc.index.H" href="#rfc.index.H"><b>H</b></a><ul> 3605 <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"> 10.1</a></li>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> 3606 3605 <li>Header Fields 3607 3606 <ul> 3608 <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> 9.1</b></a>, <a href="#rfc.xref.header.allow.3">10.3</a>, <a href="#rfc.xref.header.allow.4">A</a></li>3609 <li>Date <a href="#rfc.xref.header.date.1">3.3</a>, <a href="#rfc.iref.h.3"><b> 9.2</b></a>, <a href="#rfc.xref.header.date.2">10.3</a></li>3610 <li>Expect <a href="#rfc.xref.header.expect.1">3.2</a>, <a href="#rfc.xref.header.expect.2"> 7.4.14</a>, <a href="#rfc.iref.h.4"><b>9.3</b></a>, <a href="#rfc.xref.header.expect.3">10.3</a>, <a href="#rfc.xref.header.expect.4">A</a></li>3611 <li>From <a href="#rfc.xref.header.from.1">3.2</a>, <a href="#rfc.iref.h.5"><b> 9.4</b></a>, <a href="#rfc.xref.header.from.2">10.3</a></li>3612 <li>Location <a href="#rfc.xref.header.location.1">3.3</a>, <a href="#rfc.xref.header.location.2"> 6.5</a>, <a href="#rfc.xref.header.location.3">7.3</a>, <a href="#rfc.iref.h.6"><b>9.5</b></a>, <a href="#rfc.xref.header.location.4">10.3</a>, <a href="#rfc.xref.header.location.5">A</a></li>3613 <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> 9.6</b></a>, <a href="#rfc.xref.header.max-forwards.4">10.3</a>, <a href="#rfc.xref.header.max-forwards.5">A</a></li>3614 <li>Referer <a href="#rfc.xref.header.referer.1">3.2</a>, <a href="#rfc.iref.h.8"><b> 9.7</b></a>, <a href="#rfc.xref.header.referer.2">10.3</a>, <a href="#rfc.xref.header.referer.3">A</a></li>3615 <li>Retry-After <a href="#rfc.xref.header.retry-after.1">3.3</a>, <a href="#rfc.xref.header.retry-after.2"> 7.5.4</a>, <a href="#rfc.iref.h.9"><b>9.8</b></a>, <a href="#rfc.xref.header.retry-after.3">10.3</a></li>3616 <li>Server <a href="#rfc.xref.header.server.1">3.3</a>, <a href="#rfc.iref.h.10"><b> 9.9</b></a>, <a href="#rfc.xref.header.server.2">10.3</a>, <a href="#rfc.xref.header.server.3">11.1</a>, <a href="#rfc.xref.header.server.4">A</a></li>3617 <li>User-Agent <a href="#rfc.xref.header.user-agent.1">3.2</a>, <a href="#rfc.iref.h.11"><b> 9.10</b></a>, <a href="#rfc.xref.header.user-agent.2">10.3</a>, <a href="#rfc.xref.header.user-agent.3">11.1</a></li>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> 3618 3617 </ul> 3619 3618 </li> … … 3625 3624 </li> 3626 3625 <li><a id="rfc.index.L" href="#rfc.index.L"><b>L</b></a><ul> 3627 <li>Location header field <a href="#rfc.xref.header.location.1">3.3</a>, <a href="#rfc.xref.header.location.2"> 6.5</a>, <a href="#rfc.xref.header.location.3">7.3</a>, <a href="#rfc.iref.l.1"><b>9.5</b></a>, <a href="#rfc.xref.header.location.4">10.3</a>, <a href="#rfc.xref.header.location.5">A</a></li>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> 3628 3627 </ul> 3629 3628 </li> 3630 3629 <li><a id="rfc.index.M" href="#rfc.index.M"><b>M</b></a><ul> 3631 <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> 9.6</b></a>, <a href="#rfc.xref.header.max-forwards.4">10.3</a>, <a href="#rfc.xref.header.max-forwards.5">A</a></li>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> 3632 3631 <li>Methods 3633 3632 <ul> 3634 <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"> 10.1</a>, <a href="#rfc.xref.CONNECT.3">A</a></li>3635 <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"> 10.1</a></li>3636 <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"> 10.1</a></li>3637 <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"> 10.1</a></li>3638 <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"> 9.6</a>, <a href="#rfc.xref.OPTIONS.3">10.1</a></li>3639 <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"> 10.1</a>, <a href="#rfc.xref.POST.3">A</a></li>3640 <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"> 10.1</a>, <a href="#rfc.xref.PUT.3">A</a></li>3641 <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"> 9.6</a>, <a href="#rfc.xref.TRACE.3">10.1</a>, <a href="#rfc.xref.TRACE.4">11.1</a></li>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> 3642 3641 </ul> 3643 3642 </li> … … 3645 3644 </li> 3646 3645 <li><a id="rfc.index.O" href="#rfc.index.O"><b>O</b></a><ul> 3647 <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"> 9.6</a>, <a href="#rfc.xref.OPTIONS.3">10.1</a></li>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> 3648 3647 </ul> 3649 3648 </li> 3650 3649 <li><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul> 3651 <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"> 5</a>, <a href="#rfc.xref.Part1.27">5.1</a>, <a href="#rfc.xref.Part1.28">6.2</a>, <a href="#rfc.xref.Part1.29">6.8</a>, <a href="#rfc.xref.Part1.30">6.8</a>, <a href="#rfc.xref.Part1.31">6.9</a>, <a href="#rfc.xref.Part1.32">7.1.1</a>, <a href="#rfc.xref.Part1.33">7.1.2</a>, <a href="#rfc.xref.Part1.34">7.2.4</a>, <a href="#rfc.xref.Part1.35">7.2.6</a>, <a href="#rfc.xref.Part1.36">7.4.15</a>, <a href="#rfc.xref.Part1.37">7.5.6</a>, <a href="#rfc.xref.Part1.38">9.3</a>, <a href="#rfc.xref.Part1.39">9.9</a>, <a href="#rfc.xref.Part1.40">9.9</a>, <a href="#rfc.xref.Part1.41">9.10</a>, <a href="#rfc.xref.Part1.42">12</a>, <a href="#Part1"><b>13.1</b></a>, <a href="#rfc.xref.Part1.43">A</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> 3652 3651 <li><em>Section 1.2</em> <a href="#rfc.xref.Part1.3">1.2</a></li> 3653 3652 <li><em>Section 2</em> <a href="#rfc.xref.Part1.2">1.1</a></li> 3654 <li><em>Section 2.3</em> <a href="#rfc.xref.Part1. 34">7.2.4</a></li>3655 <li><em>Section 2.6</em> <a href="#rfc.xref.Part1.3 7">7.5.6</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.31">4.3.5.6</a></li> 3656 3655 <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> 3657 3656 <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> 3658 <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"> 9.9</a>, <a href="#rfc.xref.Part1.41">9.10</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> 3659 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> 3660 3659 <li><em>Section 3.2.5</em> <a href="#rfc.xref.Part1.18">3.1</a></li> 3661 <li><em>Section 3.3</em> <a href="#rfc.xref.Part1.16">2.2.1</a>, <a href="#rfc.xref.Part1.2 6">5</a>, <a href="#rfc.xref.Part1.35">7.2.6</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> 3662 3661 <li><em>Section 4.1</em> <a href="#rfc.xref.Part1.22">3.1</a></li> 3663 3662 <li><em>Section 4.3</em> <a href="#rfc.xref.Part1.24">3.2</a></li> 3664 <li><em>Section 5.3</em> <a href="#rfc.xref.Part1. 28">6.2</a>, <a href="#rfc.xref.Part1.31">6.9</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> 3665 3664 <li><em>Section 5.4</em> <a href="#rfc.xref.Part1.23">3.2</a></li> 3666 <li><em>Section 5.5</em> <a href="#rfc.xref.Part1.15">2</a>, <a href="#rfc.xref.Part1.25">3.3</a>, <a href="#rfc.xref.Part1. 27">5.1</a></li>3665 <li><em>Section 5.5</em> <a href="#rfc.xref.Part1.15">2</a>, <a href="#rfc.xref.Part1.25">3.3</a>, <a href="#rfc.xref.Part1.33">5.1</a></li> 3667 3666 <li><em>Section 6.1</em> <a href="#rfc.xref.Part1.21">3.1</a></li> 3668 <li><em>Section 6.2</em> <a href="#rfc.xref.Part1. 29">6.8</a>, <a href="#rfc.xref.Part1.40">9.9</a>, <a href="#rfc.xref.Part1.43">A</a></li>3669 <li><em>Section 6.4.3</em> <a href="#rfc.xref.Part1. 32">7.1.1</a>, <a href="#rfc.xref.Part1.38">9.3</a></li>3670 <li><em>Section 6.5</em> <a href="#rfc.xref.Part1. 33">7.1.2</a>, <a href="#rfc.xref.Part1.36">7.4.15</a></li>3671 <li><em>Section 7.3.1</em> <a href="#rfc.xref.Part1.3 0">6.8</a></li>3672 <li><em>Section 9</em> <a href="#rfc.xref.Part1.42">1 2</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">11</a></li> 3673 3672 </ul> 3674 3673 </li> 3675 <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"> 5</a>, <a href="#rfc.xref.Part3.8">6.5</a>, <a href="#rfc.xref.Part3.9">7</a>, <a href="#rfc.xref.Part3.10">7.3</a>, <a href="#rfc.xref.Part3.11">7.3.1</a>, <a href="#rfc.xref.Part3.12">7.4.6</a>, <a href="#rfc.xref.Part3.13">9.5</a>, <a href="#Part3"><b>13.1</b></a><ul>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> 3676 3675 <li><em>Section 2.3</em> <a href="#rfc.xref.Part3.2">3.1</a></li> 3677 <li><em>Section 5</em> <a href="#rfc.xref.Part3. 11">7.3.1</a></li>3678 <li><em>Section 5.2</em> <a href="#rfc.xref.Part3. 10">7.3</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> 3679 3678 <li><em>Section 6.1</em> <a href="#rfc.xref.Part3.3">3.2</a></li> 3680 <li><em>Section 6</em> <a href="#rfc.xref.Part3.1 2">7.4.6</a></li>3679 <li><em>Section 6</em> <a href="#rfc.xref.Part3.10">4.3.4.6</a></li> 3681 3680 <li><em>Section 6.2</em> <a href="#rfc.xref.Part3.4">3.2</a></li> 3682 3681 <li><em>Section 6.3</em> <a href="#rfc.xref.Part3.5">3.2</a></li> 3683 3682 <li><em>Section 6.4</em> <a href="#rfc.xref.Part3.6">3.2</a></li> 3684 <li><em>Section 6.7</em> <a href="#rfc.xref.Part3. 8">6.5</a>, <a href="#rfc.xref.Part3.13">9.5</a></li>3685 <li><em>Section 6.8</em> <a href="#rfc.xref.Part3.1">3.1</a>, <a href="#rfc.xref.Part3. 9">7</a></li>3683 <li><em>Section 6.7</em> <a href="#rfc.xref.Part3.12">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> 3686 3685 </ul> 3687 3686 </li> 3688 <li><em>Part4</em> <a href="#rfc.xref.Part4.1">3.2</a>, <a href="#rfc.xref.Part4.2">3.2</a>, <a href="#rfc.xref.Part4.3">3.2</a>, <a href="#rfc.xref.Part4.4">3.2</a>, <a href="#rfc.xref.Part4.5">3.3</a>, <a href="#rfc.xref.Part4.6">4.1</a>, <a href="#rfc.xref.Part4.7">4.1</a>, <a href="#rfc.xref.Part4.8">4.1</a>, <a href="#rfc.xref.Part4.9"> 7.2.2</a>, <a href="#rfc.xref.Part4.10">7.3</a>, <a href="#Part4"><b>13.1</b></a>, <a href="#rfc.xref.Part4.11">C.2</a><ul>3689 <li><em>Section 2.3</em> <a href="#rfc.xref.Part4.5">3.3</a>, <a href="#rfc.xref.Part4.9"> 7.2.2</a></li>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>12.1</b></a>, <a href="#rfc.xref.Part4.11">C.2</a><ul> 3688 <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> 3690 3689 <li><em>Section 3.1</em> <a href="#rfc.xref.Part4.1">3.2</a></li> 3691 3690 <li><em>Section 3.2</em> <a href="#rfc.xref.Part4.3">3.2</a></li> … … 3693 3692 <li><em>Section 3.4</em> <a href="#rfc.xref.Part4.4">3.2</a></li> 3694 3693 <li><em>Section 4</em> <a href="#rfc.xref.Part4.6">4.1</a></li> 3695 <li><em>Section 4.1</em> <a href="#rfc.xref.Part4.7">4.1</a>, <a href="#rfc.xref.Part4.10"> 7.3</a></li>3694 <li><em>Section 4.1</em> <a href="#rfc.xref.Part4.7">4.1</a>, <a href="#rfc.xref.Part4.10">4.3.3</a></li> 3696 3695 <li><em>Section 4.2</em> <a href="#rfc.xref.Part4.8">4.1</a></li> 3697 3696 </ul> 3698 3697 </li> 3699 <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>1 3.1</b></a><ul>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> 3700 3699 <li><em>Section 3</em> <a href="#rfc.xref.Part5.4">4.1</a></li> 3701 3700 <li><em>Section 3.1</em> <a href="#rfc.xref.Part5.5">4.1</a></li> … … 3706 3705 </ul> 3707 3706 </li> 3708 <li><em>Part6</em> <a href="#rfc.xref.Part6.1">2.2.1</a>, <a href="#rfc.xref.Part6.2">3.1</a>, <a href="#rfc.xref.Part6.3">3.3</a>, <a href="#rfc.xref.Part6.4">3.3</a>, <a href="#rfc.xref.Part6.5">4.2.1</a>, <a href="#rfc.xref.Part6.6"> 6.3</a>, <a href="#rfc.xref.Part6.7">6.4</a>, <a href="#rfc.xref.Part6.8">6.5</a>, <a href="#rfc.xref.Part6.9">6.6</a>, <a href="#rfc.xref.Part6.10">6.7</a>, <a href="#rfc.xref.Part6.11">7.2.1</a>, <a href="#rfc.xref.Part6.12">7.2.4</a>, <a href="#rfc.xref.Part6.13">7.2.4</a>, <a href="#rfc.xref.Part6.14">7.2.4</a>, <a href="#rfc.xref.Part6.15">7.3.1</a>, <a href="#rfc.xref.Part6.16">7.3.2</a>, <a href="#rfc.xref.Part6.17">7.4.9</a>, <a href="#Part6"><b>13.1</b></a><ul>3709 <li><em>Section 2.3.1 </em> <a href="#rfc.xref.Part6.8">6.5</a></li>3710 <li><em>Section 2.3.1 .1</em> <a href="#rfc.xref.Part6.11">7.2.1</a>, <a href="#rfc.xref.Part6.14">7.2.4</a>, <a href="#rfc.xref.Part6.15">7.3.1</a>, <a href="#rfc.xref.Part6.16">7.3.2</a>, <a href="#rfc.xref.Part6.17">7.4.9</a></li>3711 <li><em>Section 2.5</em> <a href="#rfc.xref.Part6. 7">6.4</a></li>3712 <li><em>Section 2.6</em> <a href="#rfc.xref.Part6. 9">6.6</a>, <a href="#rfc.xref.Part6.10">6.7</a></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> 3713 3712 <li><em>Section 3.1</em> <a href="#rfc.xref.Part6.3">3.3</a></li> 3714 <li><em>Section 3.2</em> <a href="#rfc.xref.Part6. 12">7.2.4</a></li>3713 <li><em>Section 3.2</em> <a href="#rfc.xref.Part6.7">4.3.2.4</a></li> 3715 3714 <li><em>Section 3.5</em> <a href="#rfc.xref.Part6.4">3.3</a></li> 3716 <li><em>Section 3.6</em> <a href="#rfc.xref.Part6. 13">7.2.4</a></li>3715 <li><em>Section 3.6</em> <a href="#rfc.xref.Part6.8">4.3.2.4</a></li> 3717 3716 </ul> 3718 3717 </li> 3719 <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 3.1</b></a><ul>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>12.1</b></a><ul> 3720 3719 <li><em>Section 3</em> <a href="#rfc.xref.Part7.5">4.1</a></li> 3721 3720 <li><em>Section 3.1</em> <a href="#rfc.xref.Part7.6">4.1</a></li> … … 3727 3726 </ul> 3728 3727 </li> 3729 <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"> 10.1</a>, <a href="#rfc.xref.POST.3">A</a></li>3730 <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"> 10.1</a>, <a href="#rfc.xref.PUT.3">A</a></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> 3731 3730 </ul> 3732 3731 </li> 3733 3732 <li><a id="rfc.index.R" href="#rfc.index.R"><b>R</b></a><ul> 3734 <li>Referer header field <a href="#rfc.xref.header.referer.1">3.2</a>, <a href="#rfc.iref.r.1"><b> 9.7</b></a>, <a href="#rfc.xref.header.referer.2">10.3</a>, <a href="#rfc.xref.header.referer.3">A</a></li>3735 <li>Retry-After header field <a href="#rfc.xref.header.retry-after.1">3.3</a>, <a href="#rfc.xref.header.retry-after.2"> 7.5.4</a>, <a href="#rfc.iref.r.2"><b>9.8</b></a>, <a href="#rfc.xref.header.retry-after.3">10.3</a></li>3736 <li><em>RFC1123</em> <a href="#rfc.xref.RFC1123.1"> 8.1</a>, <a href="#rfc.xref.RFC1123.2">8.1</a>, <a href="#RFC1123"><b>13.2</b></a><ul>3737 <li><em>Section 5.2.14</em> <a href="#rfc.xref.RFC1123.2"> 8.1</a></li>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> 3738 3737 </ul> 3739 3738 </li> 3740 <li><em>RFC1945</em> <a href="#rfc.xref.RFC1945.1"> 7.3</a>, <a href="#RFC1945"><b>13.2</b></a><ul>3741 <li><em>Section 9.3</em> <a href="#rfc.xref.RFC1945.1"> 7.3</a></li>3739 <li><em>RFC1945</em> <a href="#rfc.xref.RFC1945.1">4.3.3</a>, <a href="#RFC1945"><b>12.2</b></a><ul> 3740 <li><em>Section 9.3</em> <a href="#rfc.xref.RFC1945.1">4.3.3</a></li> 3742 3741 </ul> 3743 3742 </li> 3744 <li><em>RFC2068</em> <a href="#rfc.xref.RFC2068.1"> 7.3</a>, <a href="#rfc.xref.RFC2068.2">7.3</a>, <a href="#RFC2068"><b>13.2</b></a><ul>3745 <li><em>Section 10.3</em> <a href="#rfc.xref.RFC2068.2"> 7.3</a></li>3746 <li><em>Section 10.3.4</em> <a href="#rfc.xref.RFC2068.1"> 7.3</a></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>12.2</b></a><ul> 3744 <li><em>Section 10.3</em> <a href="#rfc.xref.RFC2068.2">4.3.3</a></li> 3745 <li><em>Section 10.3.4</em> <a href="#rfc.xref.RFC2068.1">4.3.3</a></li> 3747 3746 </ul> 3748 3747 </li> 3749 <li><em>RFC2119</em> <a href="#rfc.xref.RFC2119.1">1.1</a>, <a href="#RFC2119"><b>1 3.1</b></a></li>3750 <li><em>RFC2616</em> <a href="#rfc.xref.RFC2616.1">1</a>, <a href="#rfc.xref.RFC2616.2"> 7.3</a>, <a href="#RFC2616"><b>13.2</b></a>, <a href="#rfc.xref.RFC2616.3">C.1</a><ul>3751 <li><em>Section 10.3.8</em> <a href="#rfc.xref.RFC2616.2"> 7.3</a></li>3748 <li><em>RFC2119</em> <a href="#rfc.xref.RFC2119.1">1.1</a>, <a href="#RFC2119"><b>12.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>12.2</b></a>, <a href="#rfc.xref.RFC2616.3">C.1</a><ul> 3750 <li><em>Section 10.3.8</em> <a href="#rfc.xref.RFC2616.2">4.3.3</a></li> 3752 3751 </ul> 3753 3752 </li> 3754 <li><em>RFC2817</em> <a href="#rfc.xref.RFC2817.1"> 10.2</a>, <a href="#RFC2817"><b>13.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>3755 <li><em>Section 7.1</em> <a href="#rfc.xref.RFC2817.1"> 10.2</a>, <a href="#rfc.xref.RFC2817.2">A</a></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> 3756 3755 </ul> 3757 3756 </li> 3758 <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"> 10.3</a>, <a href="#RFC3864"><b>13.2</b></a><ul>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> 3759 3758 <li><em>Section 4.1</em> <a href="#rfc.xref.RFC3864.2">3.1</a></li> 3760 3759 </ul> 3761 3760 </li> 3762 <li><em>RFC3986</em> <a href="#rfc.xref.RFC3986.1"> 9.5</a>, <a href="#rfc.xref.RFC3986.2">9.5</a>, <a href="#RFC3986"><b>13.1</b></a><ul>3763 <li><em>Section 4.2</em> <a href="#rfc.xref.RFC3986.1"> 9.5</a></li>3764 <li><em>Section 5</em> <a href="#rfc.xref.RFC3986.2"> 9.5</a></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> 3765 3764 </ul> 3766 3765 </li> 3767 <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 3.2</b></a><ul>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>12.2</b></a><ul> 3768 3767 <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> 3769 3768 </ul> 3770 3769 </li> 3771 <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 3.1</b></a><ul>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>12.1</b></a><ul> 3772 3771 <li><em>Appendix B.1</em> <a href="#rfc.xref.RFC5234.2">1.2</a></li> 3773 3772 </ul> 3774 3773 </li> 3775 <li><em>RFC5322</em> <a href="#rfc.xref.RFC5322.1"> 8.1</a>, <a href="#rfc.xref.RFC5322.2">9.2</a>, <a href="#rfc.xref.RFC5322.3">9.4</a>, <a href="#rfc.xref.RFC5322.4">9.4</a>, <a href="#RFC5322"><b>13.2</b></a><ul>3776 <li><em>Section 3.3</em> <a href="#rfc.xref.RFC5322.1"> 8.1</a></li>3777 <li><em>Section 3.4</em> <a href="#rfc.xref.RFC5322.3"> 9.4</a>, <a href="#rfc.xref.RFC5322.4">9.4</a></li>3778 <li><em>Section 3.6.1</em> <a href="#rfc.xref.RFC5322.2"> 9.2</a></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> 3779 3778 </ul> 3780 3779 </li> 3781 <li><em>RFC5789</em> <a href="#rfc.xref.RFC5789.1">6.6</a>, <a href="#RFC5789"><b>1 3.2</b></a></li>3782 <li><em>RFC5987</em> <a href="#rfc.xref.RFC5987.1">3.1</a>, <a href="#RFC5987"><b>1 3.2</b></a></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>12.2</b></a></li> 3783 3782 </ul> 3784 3783 </li> 3785 3784 <li><a id="rfc.index.S" href="#rfc.index.S"><b>S</b></a><ul> 3786 <li>Safe Methods <a href="#rfc.iref.s. 1"><b>6.1.1</b></a></li>3787 <li>Server header field <a href="#rfc.xref.header.server.1">3.3</a>, <a href="#rfc.iref.s.38"><b> 9.9</b></a>, <a href="#rfc.xref.header.server.2">10.3</a>, <a href="#rfc.xref.header.server.3">11.1</a>, <a href="#rfc.xref.header.server.4">A</a></li>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> 3788 3787 <li>Status Codes 3789 3788 <ul> 3790 <li>100 Continue <a href="#rfc.xref.status.100.1">4.1</a>, <a href="#rfc.iref.s. 2"><b>7.1.1</b></a>, <a href="#rfc.xref.status.100.2">10.2</a></li>3791 <li>101 Switching Protocols <a href="#rfc.xref.status.101.1">4.1</a>, <a href="#rfc.iref.s. 3"><b>7.1.2</b></a>, <a href="#rfc.xref.status.101.2">10.2</a></li>3792 <li>200 OK <a href="#rfc.xref.status.200.1">4.1</a>, <a href="#rfc.iref.s. 4"><b>7.2.1</b></a>, <a href="#rfc.xref.status.200.2">10.2</a></li>3793 <li>201 Created <a href="#rfc.xref.status.201.1">4.1</a>, <a href="#rfc.iref.s. 5"><b>7.2.2</b></a>, <a href="#rfc.xref.status.201.2">10.2</a></li>3794 <li>202 Accepted <a href="#rfc.xref.status.202.1">4.1</a>, <a href="#rfc.iref.s. 6"><b>7.2.3</b></a>, <a href="#rfc.xref.status.202.2">10.2</a></li>3795 <li>203 Non-Authoritative Information <a href="#rfc.xref.status.203.1">4.1</a>, <a href="#rfc.iref.s. 7"><b>7.2.4</b></a>, <a href="#rfc.xref.status.203.2">10.2</a>, <a href="#rfc.xref.status.203.3">A</a></li>3796 <li>204 No Content <a href="#rfc.xref.status.204.1">4.1</a>, <a href="#rfc.iref.s. 8"><b>7.2.5</b></a>, <a href="#rfc.xref.status.204.2">10.2</a></li>3797 <li>205 Reset Content <a href="#rfc.xref.status.205.1">4.1</a>, <a href="#rfc.iref.s. 9"><b>7.2.6</b></a>, <a href="#rfc.xref.status.205.2">10.2</a></li>3798 <li>300 Multiple Choices <a href="#rfc.xref.status.300.1">4.1</a>, <a href="#rfc.iref.s. 10"><b>7.3.1</b></a>, <a href="#rfc.xref.status.300.2">10.2</a></li>3799 <li>301 Moved Permanently <a href="#rfc.xref.status.301.1">4.1</a>, <a href="#rfc.iref.s.1 1"><b>7.3.2</b></a>, <a href="#rfc.xref.status.301.2">10.2</a>, <a href="#rfc.xref.status.301.3">A</a></li>3800 <li>302 Found <a href="#rfc.xref.status.302.1">4.1</a>, <a href="#rfc.iref.s.1 2"><b>7.3.3</b></a>, <a href="#rfc.xref.status.302.2">10.2</a>, <a href="#rfc.xref.status.302.3">A</a></li>3801 <li>303 See Other <a href="#rfc.xref.status.303.1">4.1</a>, <a href="#rfc.iref.s.1 3"><b>7.3.4</b></a>, <a href="#rfc.xref.status.303.2">10.2</a></li>3802 <li>305 Use Proxy <a href="#rfc.xref.status.305.1">4.1</a>, <a href="#rfc.iref.s.1 4"><b>7.3.5</b></a>, <a href="#rfc.xref.status.305.2">10.2</a>, <a href="#rfc.xref.status.305.3">A</a></li>3803 <li>306 (Unused) <a href="#rfc.iref.s.1 5"><b>7.3.6</b></a>, <a href="#rfc.xref.status.306.1">10.2</a></li>3804 <li>307 Temporary Redirect <a href="#rfc.xref.status.307.1">4.1</a>, <a href="#rfc.iref.s.1 6"><b>7.3.7</b></a>, <a href="#rfc.xref.status.307.2">10.2</a>, <a href="#rfc.xref.status.307.3">A</a></li>3805 <li>400 Bad Request <a href="#rfc.xref.status.400.1">4.1</a>, <a href="#rfc.iref.s.1 7"><b>7.4.1</b></a>, <a href="#rfc.xref.status.400.2">10.2</a></li>3806 <li>402 Payment Required <a href="#rfc.xref.status.402.1">4.1</a>, <a href="#rfc.iref.s.1 8"><b>7.4.2</b></a>, <a href="#rfc.xref.status.402.2">10.2</a></li>3807 <li>403 Forbidden <a href="#rfc.xref.status.403.1">4.1</a>, <a href="#rfc.iref.s.1 9"><b>7.4.3</b></a>, <a href="#rfc.xref.status.403.2">10.2</a></li>3808 <li>404 Not Found <a href="#rfc.xref.status.404.1">4.1</a>, <a href="#rfc.iref.s. 20"><b>7.4.4</b></a>, <a href="#rfc.xref.status.404.2">10.2</a></li>3809 <li>405 Method Not Allowed <a href="#rfc.xref.status.405.1">4.1</a>, <a href="#rfc.iref.s.2 1"><b>7.4.5</b></a>, <a href="#rfc.xref.status.405.2">10.2</a></li>3810 <li>406 Not Acceptable <a href="#rfc.xref.status.406.1">4.1</a>, <a href="#rfc.iref.s.2 2"><b>7.4.6</b></a>, <a href="#rfc.xref.status.406.2">10.2</a></li>3811 <li>408 Request Timeout <a href="#rfc.xref.status.408.1">4.1</a>, <a href="#rfc.iref.s.2 3"><b>7.4.7</b></a>, <a href="#rfc.xref.status.408.2">10.2</a></li>3812 <li>409 Conflict <a href="#rfc.xref.status.409.1">4.1</a>, <a href="#rfc.iref.s.2 4"><b>7.4.8</b></a>, <a href="#rfc.xref.status.409.2">10.2</a></li>3813 <li>410 Gone <a href="#rfc.xref.status.410.1">4.1</a>, <a href="#rfc.iref.s.2 5"><b>7.4.9</b></a>, <a href="#rfc.xref.status.410.2">10.2</a></li>3814 <li>411 Length Required <a href="#rfc.xref.status.411.1">4.1</a>, <a href="#rfc.iref.s.2 6"><b>7.4.10</b></a>, <a href="#rfc.xref.status.411.2">10.2</a></li>3815 <li>413 Request Representation Too Large <a href="#rfc.xref.status.413.1">4.1</a>, <a href="#rfc.iref.s.2 7"><b>7.4.11</b></a>, <a href="#rfc.xref.status.413.2">10.2</a></li>3816 <li>414 URI Too Long <a href="#rfc.xref.status.414.1">4.1</a>, <a href="#rfc.iref.s.2 8"><b>7.4.12</b></a>, <a href="#rfc.xref.status.414.2">10.2</a></li>3817 <li>415 Unsupported Media Type <a href="#rfc.xref.status.415.1">4.1</a>, <a href="#rfc.iref.s.2 9"><b>7.4.13</b></a>, <a href="#rfc.xref.status.415.2">10.2</a></li>3818 <li>417 Expectation Failed <a href="#rfc.xref.status.417.1">4.1</a>, <a href="#rfc.iref.s. 30"><b>7.4.14</b></a>, <a href="#rfc.xref.status.417.2">10.2</a></li>3819 <li>426 Upgrade Required <a href="#rfc.xref.status.426.1">4.1</a>, <a href="#rfc.iref.s.3 1"><b>7.4.15</b></a>, <a href="#rfc.xref.status.426.2">10.2</a>, <a href="#rfc.xref.status.426.3">A</a></li>3820 <li>500 Internal Server Error <a href="#rfc.xref.status.500.1">4.1</a>, <a href="#rfc.iref.s.3 2"><b>7.5.1</b></a>, <a href="#rfc.xref.status.500.2">10.2</a></li>3821 <li>501 Not Implemented <a href="#rfc.xref.status.501.1">4.1</a>, <a href="#rfc.iref.s.3 3"><b>7.5.2</b></a>, <a href="#rfc.xref.status.501.2">10.2</a></li>3822 <li>502 Bad Gateway <a href="#rfc.xref.status.502.1">4.1</a>, <a href="#rfc.iref.s.3 4"><b>7.5.3</b></a>, <a href="#rfc.xref.status.502.2">10.2</a></li>3823 <li>503 Service Unavailable <a href="#rfc.xref.status.503.1">4.1</a>, <a href="#rfc.iref.s.3 5"><b>7.5.4</b></a>, <a href="#rfc.xref.status.503.2">10.2</a></li>3824 <li>504 Gateway Timeout <a href="#rfc.xref.status.504.1">4.1</a>, <a href="#rfc.iref.s.3 6"><b>7.5.5</b></a>, <a href="#rfc.xref.status.504.2">10.2</a></li>3825 <li>505 HTTP Version Not Supported <a href="#rfc.xref.status.505.1">4.1</a>, <a href="#rfc.iref.s.3 7"><b>7.5.6</b></a>, <a href="#rfc.xref.status.505.2">10.2</a></li>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.10"><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.11"><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.12"><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.13"><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.14"><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.15"><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.16"><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.17"><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.18"><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.20"><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.21"><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.22"><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.23"><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.24"><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.25"><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.26"><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.27"><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.28"><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.30"><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.31"><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.32"><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.33"><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.34"><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.35"><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.36"><b>4.3.5.6</b></a>, <a href="#rfc.xref.status.505.2">9.2</a></li> 3826 3825 </ul> 3827 3826 </li> … … 3829 3828 </li> 3830 3829 <li><a id="rfc.index.T" href="#rfc.index.T"><b>T</b></a><ul> 3831 <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"> 9.6</a>, <a href="#rfc.xref.TRACE.3">10.1</a>, <a href="#rfc.xref.TRACE.4">11.1</a></li>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> 3832 3831 </ul> 3833 3832 </li> 3834 3833 <li><a id="rfc.index.U" href="#rfc.index.U"><b>U</b></a><ul> 3835 <li>User-Agent header field <a href="#rfc.xref.header.user-agent.1">3.2</a>, <a href="#rfc.iref.u.1"><b> 9.10</b></a>, <a href="#rfc.xref.header.user-agent.2">10.3</a>, <a href="#rfc.xref.header.user-agent.3">11.1</a></li>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> 3836 3835 </ul> 3837 3836 </li> -
draft-ietf-httpbis/latest/p2-semantics.xml
r1617 r1618 596 596 information which will explain the unusual status. 597 597 </t> 598 <t> 599 The first digit of the status-code defines the class of response. The 600 last two digits do not have any categorization role. There are 5 601 values for the first digit: 602 <list style="symbols"> 603 <t> 604 1xx: Informational - Request received, continuing process 605 </t> 606 <t> 607 2xx: Success - The action was successfully received, 608 understood, and accepted 609 </t> 610 <t> 611 3xx: Redirection - Further action needs to be taken in order to 612 complete the request 613 </t> 614 <t> 615 4xx: Client Error - The request contains bad syntax or cannot 616 be fulfilled 617 </t> 618 <t> 619 5xx: Server Error - The server failed to fulfill an apparently 620 valid request 621 </t> 622 </list> 623 </t> 598 624 599 625 <section title="Overview of Status Codes" anchor="overview.of.status.codes"> … … 713 739 </section> 714 740 715 </section>716 717 <section title="Representation" anchor="representation">718 <t>719 Request and Response messages &MAY; transfer a representation if not otherwise720 restricted by the request method or response status code. A representation721 consists of metadata (representation header fields) and data (representation722 body). When a complete or partial representation is enclosed in an HTTP message,723 it is referred to as the payload of the message. HTTP representations724 are defined in &payload;.725 </t>726 <t>727 A representation body is only present in a message when a message body is728 present, as described in &message-body;. The representation body is obtained729 from the message body by decoding any Transfer-Encoding that might730 have been applied to ensure safe and proper transfer of the message.731 </t>732 733 <section title="Identifying the Resource Associated with a Representation" anchor="identifying.response.associated.with.representation">734 <t>735 It is sometimes necessary to determine an identifier for the resource736 associated with a representation.737 </t>738 <t>739 An HTTP request representation, when present, is always associated with an740 anonymous (i.e., unidentified) resource.741 </t>742 <t>743 In the common case, an HTTP response is a representation of the target744 resource (see &effective-request-uri;). However, this is not always the745 case. To determine the URI of the resource a response is associated with,746 the following rules are used (with the first applicable one being selected):747 </t>748 <t><list style="numbers">749 <t>If the response status code is 200 or 203 and the request method was GET,750 the response payload is a representation of the target resource.</t>751 <t>If the response status code is 204, 206, or 304 and the request method was GET752 or HEAD, the response payload is a partial representation of the target753 resource.</t>754 <t>If the response has a Content-Location header field, and that URI is the same755 as the effective request URI, the response payload is a representation of the756 target resource.</t>757 <t>If the response has a Content-Location header field, and that URI is not the758 same as the effective request URI, then the response asserts that its759 payload is a representation of the resource identified by the760 Content-Location URI. However, such an assertion cannot be trusted unless761 it can be verified by other means (not defined by HTTP).</t>762 <t>Otherwise, the response is a representation of an anonymous (i.e.,763 unidentified) resource.</t>764 </list></t>765 <t>766 <cref anchor="TODO-req-uri">767 The comparison function is going to have to be defined somewhere,768 because we already need to compare URIs for things like cache invalidation.</cref>769 </t>770 </section>771 772 </section>773 774 775 <section title="Method Definitions" anchor="method.definitions">776 <t>777 The set of common request methods for HTTP/1.1 is defined below. Although778 this set can be expanded, additional methods cannot be assumed to779 share the same semantics for separately extended clients and servers.780 </t>781 782 <section title="Safe and Idempotent Methods" anchor="safe.and.idempotent">783 784 <section title="Safe Methods" anchor="safe.methods">785 <iref item="Safe Methods" primary="true"/>786 <t>787 Implementors need to be aware that the software represents the user in788 their interactions over the Internet, and need to allow789 the user to be aware of any actions they take which might have an790 unexpected significance to themselves or others.791 </t>792 <t>793 In particular, the convention has been established that the GET, HEAD,794 OPTIONS, and TRACE request methods &SHOULD-NOT; have the significance795 of taking an action other than retrieval. These request methods ought796 to be considered "<x:dfn anchor="safe">safe</x:dfn>".797 This allows user agents to represent other methods, such as POST, PUT798 and DELETE, in a special way, so that the user is made aware of the799 fact that a possibly unsafe action is being requested.800 </t>801 <t>802 Naturally, it is not possible to ensure that the server does not803 generate side-effects as a result of performing a GET request; in804 fact, some dynamic resources consider that a feature. The important805 distinction here is that the user did not request the side-effects,806 so therefore cannot be held accountable for them.807 </t>808 </section>809 810 <section title="Idempotent Methods" anchor="idempotent.methods">811 <iref item="Idempotent Methods" primary="true"/>812 <t>813 Request methods can also have the property of "idempotence" in that,814 aside from error or expiration issues, the intended effect of multiple815 identical requests is the same as for a single request.816 PUT, DELETE, and all safe request methods are idempotent.817 It is important to note that idempotence refers only to changes818 requested by the client: a server is free to change its state due819 to multiple requests for the purpose of tracking those requests,820 versioning of results, etc.821 </t>822 </section>823 </section>824 825 <section title="OPTIONS" anchor="OPTIONS">826 <rdf:Description>827 <safe xmlns="urn:ietf:id:draft-ietf-httpbis-p2-semantics#">yes</safe>828 </rdf:Description>829 <iref primary="true" item="OPTIONS method" x:for-anchor=""/>830 <iref primary="true" item="Methods" subitem="OPTIONS" x:for-anchor=""/>831 <t>832 The OPTIONS method requests information about the833 communication options available on the request/response chain834 identified by the effective request URI. This method allows a client to835 determine the options and/or requirements associated with a resource,836 or the capabilities of a server, without implying a resource action837 or initiating a resource retrieval.838 </t>839 <t>840 Responses to the OPTIONS method are not cacheable.841 </t>842 <t>843 If the OPTIONS request includes a message body (as indicated by the844 presence of Content-Length or Transfer-Encoding), then the media type845 &MUST; be indicated by a Content-Type field. Although this846 specification does not define any use for such a body, future847 extensions to HTTP might use the OPTIONS body to make more detailed848 queries on the server.849 </t>850 <t>851 If the request-target (&request-target;) is an asterisk ("*"),852 the OPTIONS request is853 intended to apply to the server in general rather than to a specific854 resource. Since a server's communication options typically depend on855 the resource, the "*" request is only useful as a "ping" or "no-op"856 type of method; it does nothing beyond allowing the client to test857 the capabilities of the server. For example, this can be used to test858 a proxy for HTTP/1.1 conformance (or lack thereof).859 </t>860 <t>861 If the request-target is not an asterisk, the OPTIONS request applies862 only to the options that are available when communicating with that863 resource.864 </t>865 <t>866 A 200 response &SHOULD; include any header fields that indicate867 optional features implemented by the server and applicable to that868 resource (e.g., Allow), possibly including extensions not defined by869 this specification. The response body, if any, &SHOULD; also include870 information about the communication options. The format for such a871 body is not defined by this specification, but might be defined by872 future extensions to HTTP. Content negotiation &MAY; be used to select873 the appropriate response format. If no response body is included, the874 response &MUST; include a Content-Length field with a field-value of875 "0".876 </t>877 <t>878 The Max-Forwards header field &MAY; be used to target a879 specific proxy in the request chain (see <xref target="header.max-forwards"/>).880 If no Max-Forwards field is present in the request, then the forwarded881 request &MUST-NOT; include a Max-Forwards field.882 </t>883 </section>884 885 <section title="GET" anchor="GET">886 <rdf:Description>887 <safe xmlns="urn:ietf:id:draft-ietf-httpbis-p2-semantics#">yes</safe>888 </rdf:Description>889 <iref primary="true" item="GET method" x:for-anchor=""/>890 <iref primary="true" item="Methods" subitem="GET" x:for-anchor=""/>891 <t>892 The GET method requests transfer of a current representation of893 the target resource.894 </t>895 <t>896 If the target resource is a data-producing process, it is the897 produced data which shall be returned as the representation in the response and not898 the source text of the process, unless that text happens to be the output of899 the process.900 </t>901 <t>902 The semantics of the GET method change to a "conditional GET" if the903 request message includes an If-Modified-Since, If-Unmodified-Since,904 If-Match, If-None-Match, or If-Range header field. A conditional GET905 requests that the representation be transferred only under the906 circumstances described by the conditional header field(s). The907 conditional GET request is intended to reduce unnecessary network908 usage by allowing cached representations to be refreshed without requiring909 multiple requests or transferring data already held by the client.910 </t>911 <t>912 The semantics of the GET method change to a "partial GET" if the913 request message includes a Range header field. A partial GET requests914 that only part of the representation be transferred, as described in &header-range;.915 The partial GET request is intended to reduce unnecessary916 network usage by allowing partially-retrieved representations to be917 completed without transferring data already held by the client.918 </t>919 <t>920 Bodies on GET requests have no defined semantics. Note that sending a body921 on a GET request might cause some existing implementations to reject the922 request.923 </t>924 <t>925 The response to a GET request is cacheable and &MAY; be used to satisfy926 subsequent GET and HEAD requests (see &caching;).927 </t>928 <t>929 See <xref target="encoding.sensitive.information.in.uris"/> for security considerations when used for forms.930 </t>931 </section>932 933 <section title="HEAD" anchor="HEAD">934 <rdf:Description>935 <safe xmlns="urn:ietf:id:draft-ietf-httpbis-p2-semantics#">yes</safe>936 </rdf:Description>937 <iref primary="true" item="HEAD method" x:for-anchor=""/>938 <iref primary="true" item="Methods" subitem="HEAD" x:for-anchor=""/>939 <t>940 The HEAD method is identical to GET except that the server &MUST-NOT;941 return a message body in the response. The metadata contained942 in the HTTP header fields in response to a HEAD request &SHOULD; be identical943 to the information sent in response to a GET request. This method can944 be used for obtaining metadata about the representation implied by the945 request without transferring the representation body. This method is946 often used for testing hypertext links for validity, accessibility,947 and recent modification.948 </t>949 <t>950 The response to a HEAD request is cacheable and &MAY; be used to satisfy951 a subsequent HEAD request. It also has potential side effects on952 previously stored responses to GET; see &p6-head;.953 </t>954 <t>955 Bodies on HEAD requests have no defined semantics. Note that sending a body956 on a HEAD request might cause some existing implementations to reject the957 request.958 </t>959 </section>960 961 <section title="POST" anchor="POST">962 <iref primary="true" item="POST method" x:for-anchor=""/>963 <iref primary="true" item="Methods" subitem="POST" x:for-anchor=""/>964 <t>965 The POST method requests that the origin server accept the966 representation enclosed in the request as data to be processed by the967 target resource. POST is designed to allow a uniform method to cover the968 following functions:969 <list style="symbols">970 <t>971 Annotation of existing resources;972 </t>973 <t>974 Posting a message to a bulletin board, newsgroup, mailing list,975 or similar group of articles;976 </t>977 <t>978 Providing a block of data, such as the result of submitting a979 form, to a data-handling process;980 </t>981 <t>982 Extending a database through an append operation.983 </t>984 </list>985 </t>986 <t>987 The actual function performed by the POST method is determined by the988 server and is usually dependent on the effective request URI.989 </t>990 <t>991 The action performed by the POST method might not result in a992 resource that can be identified by a URI. In this case, either 200993 (OK) or 204 (No Content) is the appropriate response status code,994 depending on whether or not the response includes a representation that995 describes the result.996 </t>997 <t>998 If a resource has been created on the origin server, the response999 &SHOULD; be 201 (Created) and contain a representation which describes the1000 status of the request and refers to the new resource, and a Location1001 header field (see <xref target="header.location"/>).1002 </t>1003 <t>1004 Responses to POST requests are only cacheable when they1005 include explicit freshness information (see &p6-explicit;). A1006 cached POST response with a Content-Location header field1007 (see &header-content-location;) whose value is the effective1008 Request URI &MAY; be used to satisfy subsequent GET and HEAD requests.1009 </t>1010 <t>1011 Note that POST caching is not widely implemented.1012 However, the 303 (See Other) response can be used to direct the1013 user agent to retrieve a cacheable representation of the resource.1014 </t>1015 </section>1016 1017 <section title="PUT" anchor="PUT">1018 <iref primary="true" item="PUT method" x:for-anchor=""/>1019 <iref primary="true" item="Methods" subitem="PUT" x:for-anchor=""/>1020 <t>1021 The PUT method requests that the state of the target resource1022 be created or replaced with the state defined by the representation1023 enclosed in the request message payload. A successful PUT of a given1024 representation would suggest that a subsequent GET on that same target1025 resource will result in an equivalent representation being returned in1026 a 200 (OK) response. However, there is no guarantee that such a state1027 change will be observable, since the target resource might be acted1028 upon by other user agents in parallel, or might be subject to dynamic1029 processing by the origin server, before any subsequent GET is received.1030 A successful response only implies that the user agent's intent was1031 achieved at the time of its processing by the origin server.1032 </t>1033 <t>1034 If the target resource does not have a current representation and1035 the PUT successfully creates one, then the origin server &MUST; inform1036 the user agent by sending a 201 (Created) response. If the target1037 resource does have a current representation and that representation is1038 successfully modified in accordance with the state of the enclosed1039 representation, then either a 200 (OK) or 204 (No Content) response1040 &SHOULD; be sent to indicate successful completion of the request.1041 </t>1042 <t>1043 Unrecognized header fields &SHOULD; be ignored (i.e., not saved1044 as part of the resource state).1045 </t>1046 <t>1047 An origin server &SHOULD; verify that the PUT representation is1048 consistent with any constraints which the server has for the target1049 resource that cannot or will not be changed by the PUT. This is1050 particularly important when the origin server uses internal1051 configuration information related to the URI in order to set the1052 values for representation metadata on GET responses. When a PUT1053 representation is inconsistent with the target resource, the origin1054 server &SHOULD; either make them consistent, by transforming the1055 representation or changing the resource configuration, or respond1056 with an appropriate error message containing sufficient information1057 to explain why the representation is unsuitable. The 409 (Conflict)1058 or 415 (Unsupported Media Type) status codes are suggested, with the1059 latter being specific to constraints on Content-Type values.1060 </t>1061 <t>1062 For example, if the target resource is configured to always have a1063 Content-Type of "text/html" and the representation being PUT has a1064 Content-Type of "image/jpeg", then the origin server &SHOULD; do one of:1065 (a) reconfigure the target resource to reflect the new media type;1066 (b) transform the PUT representation to a format consistent with that1067 of the resource before saving it as the new resource state; or,1068 (c) reject the request with a 415 response indicating that the target1069 resource is limited to "text/html", perhaps including a link to a1070 different resource that would be a suitable target for the new1071 representation.1072 </t>1073 <t>1074 HTTP does not define exactly how a PUT method affects the state1075 of an origin server beyond what can be expressed by the intent of1076 the user agent request and the semantics of the origin server response.1077 It does not define what a resource might be, in any sense of that1078 word, beyond the interface provided via HTTP. It does not define1079 how resource state is "stored", nor how such storage might change1080 as a result of a change in resource state, nor how the origin server1081 translates resource state into representations. Generally speaking,1082 all implementation details behind the resource interface are1083 intentionally hidden by the server.1084 </t>1085 <t>1086 The fundamental difference between the POST and PUT methods is1087 highlighted by the different intent for the target resource.1088 The target resource in a POST request is intended to handle the1089 enclosed representation as a data-accepting process, such as for1090 a gateway to some other protocol or a document that accepts annotations.1091 In contrast, the target resource in a PUT request is intended to1092 take the enclosed representation as a new or replacement value.1093 Hence, the intent of PUT is idempotent and visible to intermediaries,1094 even though the exact effect is only known by the origin server.1095 </t>1096 <t>1097 Proper interpretation of a PUT request presumes that the user agent1098 knows what target resource is desired. A service that is intended1099 to select a proper URI on behalf of the client, after receiving1100 a state-changing request, &SHOULD; be implemented using the POST1101 method rather than PUT. If the origin server will not make the1102 requested PUT state change to the target resource and instead1103 wishes to have it applied to a different resource, such as when the1104 resource has been moved to a different URI, then the origin server1105 &MUST; send a 301 (Moved Permanently) response; the user agent &MAY;1106 then make its own decision regarding whether or not to redirect the1107 request.1108 </t>1109 <t>1110 A PUT request applied to the target resource &MAY; have side-effects