You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@labs.apache.org by fi...@apache.org on 2007/10/12 02:33:48 UTC
svn commit: r583996 [4/5] - in /labs/webarch/trunk/http/draft-fielding-http:
outline2616.html outlineALL.html p1-messaging.html p1-messaging.xml
p2-semantics.html p2-semantics.xml
Modified: labs/webarch/trunk/http/draft-fielding-http/p2-semantics.html
URL: http://svn.apache.org/viewvc/labs/webarch/trunk/http/draft-fielding-http/p2-semantics.html?rev=583996&r1=583995&r2=583996&view=diff
==============================================================================
--- labs/webarch/trunk/http/draft-fielding-http/p2-semantics.html (original)
+++ labs/webarch/trunk/http/draft-fielding-http/p2-semantics.html Thu Oct 11 17:33:46 2007
@@ -333,17 +333,18 @@
<link rel="Index" href="#rfc.index">
<link rel="Chapter" title="1 Introduction" href="#rfc.section.1">
<link rel="Chapter" title="2 Product Tokens" href="#rfc.section.2">
- <link rel="Chapter" title="3 Request" href="#rfc.section.3">
- <link rel="Chapter" title="4 Response" href="#rfc.section.4">
- <link rel="Chapter" title="5 Entity" href="#rfc.section.5">
- <link rel="Chapter" title="6 Method Definitions" href="#rfc.section.6">
- <link rel="Chapter" title="7 Status Code Definitions" href="#rfc.section.7">
- <link rel="Chapter" title="8 Header Field Definitions" href="#rfc.section.8">
- <link rel="Chapter" title="9 Security Considerations" href="#rfc.section.9">
- <link rel="Chapter" title="10 Acknowledgments" href="#rfc.section.10">
- <link rel="Chapter" href="#rfc.section.11" title="11 References">
- <link rel="Appendix" title="A Changes from HTTP/1.0" href="#rfc.section.A">
- <link rel="Appendix" title="B Changes from RFC 2068" href="#rfc.section.B">
+ <link rel="Chapter" title="3 Method" href="#rfc.section.3">
+ <link rel="Chapter" title="4 Request Header Fields" href="#rfc.section.4">
+ <link rel="Chapter" title="5 Status Code and Reason Phrase" href="#rfc.section.5">
+ <link rel="Chapter" title="6 Response Header Fields" href="#rfc.section.6">
+ <link rel="Chapter" title="7 Entity" href="#rfc.section.7">
+ <link rel="Chapter" title="8 Method Definitions" href="#rfc.section.8">
+ <link rel="Chapter" title="9 Status Code Definitions" href="#rfc.section.9">
+ <link rel="Chapter" title="10 Header Field Definitions" href="#rfc.section.10">
+ <link rel="Chapter" title="11 Security Considerations" href="#rfc.section.11">
+ <link rel="Chapter" title="12 Acknowledgments" href="#rfc.section.12">
+ <link rel="Chapter" href="#rfc.section.13" title="13 References">
+ <link rel="Appendix" title="A Changes from RFC 2068" href="#rfc.section.A">
<meta name="generator" content="http://greenbytes.de/tech/webdav/rfc2629.xslt, Revision 1.346, 2007/10/07 13:54:24, XSLT vendor: SAXON 8.9 from Saxonica http://www.saxonica.com/">
<link rel="schema.DC" href="http://purl.org/dc/elements/1.1/">
<meta name="DC.Creator" content="Fielding, R.">
@@ -461,127 +462,108 @@
<ul class="toc">
<li class="tocline0">1. <a href="#introduction">Introduction</a></li>
<li class="tocline0">2. <a href="#product.tokens">Product Tokens</a></li>
- <li class="tocline0">3. <a href="#request">Request</a><ul class="toc">
- <li class="tocline1">3.1 <a href="#request-line">Request-Line</a><ul class="toc">
- <li class="tocline1">3.1.1 <a href="#method">Method</a></li>
- <li class="tocline1">3.1.2 <a href="#request-uri">Request-URI</a></li>
+ <li class="tocline0">3. <a href="#method">Method</a></li>
+ <li class="tocline0">4. <a href="#request.header.fields">Request Header Fields</a></li>
+ <li class="tocline0">5. <a href="#status.code.and.reason.phrase">Status Code and Reason Phrase</a></li>
+ <li class="tocline0">6. <a href="#response.header.fields">Response Header Fields</a></li>
+ <li class="tocline0">7. <a href="#entity">Entity</a></li>
+ <li class="tocline0">8. <a href="#method.definitions">Method Definitions</a><ul class="toc">
+ <li class="tocline1">8.1 <a href="#safe.and.idempotent">Safe and Idempotent Methods</a><ul class="toc">
+ <li class="tocline1">8.1.1 <a href="#safe.methods">Safe Methods</a></li>
+ <li class="tocline1">8.1.2 <a href="#idempotent.methods">Idempotent Methods</a></li>
</ul>
</li>
- <li class="tocline1">3.2 <a href="#the.resource.identified.by.a.request">The Resource Identified by a Request</a></li>
- <li class="tocline1">3.3 <a href="#request.header.fields">Request Header Fields</a></li>
+ <li class="tocline1">8.2 <a href="#OPTIONS">OPTIONS</a></li>
+ <li class="tocline1">8.3 <a href="#GET">GET</a></li>
+ <li class="tocline1">8.4 <a href="#HEAD">HEAD</a></li>
+ <li class="tocline1">8.5 <a href="#POST">POST</a></li>
+ <li class="tocline1">8.6 <a href="#PUT">PUT</a></li>
+ <li class="tocline1">8.7 <a href="#DELETE">DELETE</a></li>
+ <li class="tocline1">8.8 <a href="#TRACE">TRACE</a></li>
+ <li class="tocline1">8.9 <a href="#CONNECT">CONNECT</a></li>
</ul>
</li>
- <li class="tocline0">4. <a href="#response">Response</a><ul class="toc">
- <li class="tocline1">4.1 <a href="#status-line">Status-Line</a><ul class="toc">
- <li class="tocline1">4.1.1 <a href="#status.code.and.reason.phrase">Status Code and Reason Phrase</a></li>
+ <li class="tocline0">9. <a href="#status.codes">Status Code Definitions</a><ul class="toc">
+ <li class="tocline1">9.1 <a href="#status.1xx">Informational 1xx</a><ul class="toc">
+ <li class="tocline1">9.1.1 <a href="#status.100">100 Continue</a></li>
+ <li class="tocline1">9.1.2 <a href="#status.101">101 Switching Protocols</a></li>
</ul>
</li>
- <li class="tocline1">4.2 <a href="#response.header.fields">Response Header Fields</a></li>
- </ul>
- </li>
- <li class="tocline0">5. <a href="#entity">Entity</a></li>
- <li class="tocline0">6. <a href="#method.definitions">Method Definitions</a><ul class="toc">
- <li class="tocline1">6.1 <a href="#safe.and.idempotent">Safe and Idempotent Methods</a><ul class="toc">
- <li class="tocline1">6.1.1 <a href="#safe.methods">Safe Methods</a></li>
- <li class="tocline1">6.1.2 <a href="#idempotent.methods">Idempotent Methods</a></li>
- </ul>
- </li>
- <li class="tocline1">6.2 <a href="#OPTIONS">OPTIONS</a></li>
- <li class="tocline1">6.3 <a href="#GET">GET</a></li>
- <li class="tocline1">6.4 <a href="#HEAD">HEAD</a></li>
- <li class="tocline1">6.5 <a href="#POST">POST</a></li>
- <li class="tocline1">6.6 <a href="#PUT">PUT</a></li>
- <li class="tocline1">6.7 <a href="#DELETE">DELETE</a></li>
- <li class="tocline1">6.8 <a href="#TRACE">TRACE</a></li>
- <li class="tocline1">6.9 <a href="#CONNECT">CONNECT</a></li>
- </ul>
- </li>
- <li class="tocline0">7. <a href="#status.codes">Status Code Definitions</a><ul class="toc">
- <li class="tocline1">7.1 <a href="#status.1xx">Informational 1xx</a><ul class="toc">
- <li class="tocline1">7.1.1 <a href="#status.100">100 Continue</a></li>
- <li class="tocline1">7.1.2 <a href="#status.101">101 Switching Protocols</a></li>
- </ul>
- </li>
- <li class="tocline1">7.2 <a href="#status.2xx">Successful 2xx</a><ul class="toc">
- <li class="tocline1">7.2.1 <a href="#status.200">200 OK</a></li>
- <li class="tocline1">7.2.2 <a href="#status.201">201 Created</a></li>
- <li class="tocline1">7.2.3 <a href="#status.202">202 Accepted</a></li>
- <li class="tocline1">7.2.4 <a href="#status.203">203 Non-Authoritative Information</a></li>
- <li class="tocline1">7.2.5 <a href="#status.204">204 No Content</a></li>
- <li class="tocline1">7.2.6 <a href="#status.205">205 Reset Content</a></li>
- <li class="tocline1">7.2.7 <a href="#status.206">206 Partial Content</a></li>
+ <li class="tocline1">9.2 <a href="#status.2xx">Successful 2xx</a><ul class="toc">
+ <li class="tocline1">9.2.1 <a href="#status.200">200 OK</a></li>
+ <li class="tocline1">9.2.2 <a href="#status.201">201 Created</a></li>
+ <li class="tocline1">9.2.3 <a href="#status.202">202 Accepted</a></li>
+ <li class="tocline1">9.2.4 <a href="#status.203">203 Non-Authoritative Information</a></li>
+ <li class="tocline1">9.2.5 <a href="#status.204">204 No Content</a></li>
+ <li class="tocline1">9.2.6 <a href="#status.205">205 Reset Content</a></li>
+ <li class="tocline1">9.2.7 <a href="#status.206">206 Partial Content</a></li>
</ul>
</li>
- <li class="tocline1">7.3 <a href="#status.3xx">Redirection 3xx</a><ul class="toc">
- <li class="tocline1">7.3.1 <a href="#status.300">300 Multiple Choices</a></li>
- <li class="tocline1">7.3.2 <a href="#status.301">301 Moved Permanently</a></li>
- <li class="tocline1">7.3.3 <a href="#status.302">302 Found</a></li>
- <li class="tocline1">7.3.4 <a href="#status.303">303 See Other</a></li>
- <li class="tocline1">7.3.5 <a href="#status.304">304 Not Modified</a></li>
- <li class="tocline1">7.3.6 <a href="#status.305">305 Use Proxy</a></li>
- <li class="tocline1">7.3.7 <a href="#status.306">306 (Unused)</a></li>
- <li class="tocline1">7.3.8 <a href="#status.307">307 Temporary Redirect</a></li>
+ <li class="tocline1">9.3 <a href="#status.3xx">Redirection 3xx</a><ul class="toc">
+ <li class="tocline1">9.3.1 <a href="#status.300">300 Multiple Choices</a></li>
+ <li class="tocline1">9.3.2 <a href="#status.301">301 Moved Permanently</a></li>
+ <li class="tocline1">9.3.3 <a href="#status.302">302 Found</a></li>
+ <li class="tocline1">9.3.4 <a href="#status.303">303 See Other</a></li>
+ <li class="tocline1">9.3.5 <a href="#status.304">304 Not Modified</a></li>
+ <li class="tocline1">9.3.6 <a href="#status.305">305 Use Proxy</a></li>
+ <li class="tocline1">9.3.7 <a href="#status.306">306 (Unused)</a></li>
+ <li class="tocline1">9.3.8 <a href="#status.307">307 Temporary Redirect</a></li>
</ul>
</li>
- <li class="tocline1">7.4 <a href="#status.4xx">Client Error 4xx</a><ul class="toc">
- <li class="tocline1">7.4.1 <a href="#status.400">400 Bad Request</a></li>
- <li class="tocline1">7.4.2 <a href="#status.401">401 Unauthorized</a></li>
- <li class="tocline1">7.4.3 <a href="#status.402">402 Payment Required</a></li>
- <li class="tocline1">7.4.4 <a href="#status.403">403 Forbidden</a></li>
- <li class="tocline1">7.4.5 <a href="#status.404">404 Not Found</a></li>
- <li class="tocline1">7.4.6 <a href="#status.405">405 Method Not Allowed</a></li>
- <li class="tocline1">7.4.7 <a href="#status.406">406 Not Acceptable</a></li>
- <li class="tocline1">7.4.8 <a href="#status.407">407 Proxy Authentication Required</a></li>
- <li class="tocline1">7.4.9 <a href="#status.408">408 Request Timeout</a></li>
- <li class="tocline1">7.4.10 <a href="#status.409">409 Conflict</a></li>
- <li class="tocline1">7.4.11 <a href="#status.410">410 Gone</a></li>
- <li class="tocline1">7.4.12 <a href="#status.411">411 Length Required</a></li>
- <li class="tocline1">7.4.13 <a href="#status.412">412 Precondition Failed</a></li>
- <li class="tocline1">7.4.14 <a href="#status.413">413 Request Entity Too Large</a></li>
- <li class="tocline1">7.4.15 <a href="#status.414">414 Request-URI Too Long</a></li>
- <li class="tocline1">7.4.16 <a href="#status.415">415 Unsupported Media Type</a></li>
- <li class="tocline1">7.4.17 <a href="#status.416">416 Requested Range Not Satisfiable</a></li>
- <li class="tocline1">7.4.18 <a href="#status.417">417 Expectation Failed</a></li>
+ <li class="tocline1">9.4 <a href="#status.4xx">Client Error 4xx</a><ul class="toc">
+ <li class="tocline1">9.4.1 <a href="#status.400">400 Bad Request</a></li>
+ <li class="tocline1">9.4.2 <a href="#status.401">401 Unauthorized</a></li>
+ <li class="tocline1">9.4.3 <a href="#status.402">402 Payment Required</a></li>
+ <li class="tocline1">9.4.4 <a href="#status.403">403 Forbidden</a></li>
+ <li class="tocline1">9.4.5 <a href="#status.404">404 Not Found</a></li>
+ <li class="tocline1">9.4.6 <a href="#status.405">405 Method Not Allowed</a></li>
+ <li class="tocline1">9.4.7 <a href="#status.406">406 Not Acceptable</a></li>
+ <li class="tocline1">9.4.8 <a href="#status.407">407 Proxy Authentication Required</a></li>
+ <li class="tocline1">9.4.9 <a href="#status.408">408 Request Timeout</a></li>
+ <li class="tocline1">9.4.10 <a href="#status.409">409 Conflict</a></li>
+ <li class="tocline1">9.4.11 <a href="#status.410">410 Gone</a></li>
+ <li class="tocline1">9.4.12 <a href="#status.411">411 Length Required</a></li>
+ <li class="tocline1">9.4.13 <a href="#status.412">412 Precondition Failed</a></li>
+ <li class="tocline1">9.4.14 <a href="#status.413">413 Request Entity Too Large</a></li>
+ <li class="tocline1">9.4.15 <a href="#status.414">414 Request-URI Too Long</a></li>
+ <li class="tocline1">9.4.16 <a href="#status.415">415 Unsupported Media Type</a></li>
+ <li class="tocline1">9.4.17 <a href="#status.416">416 Requested Range Not Satisfiable</a></li>
+ <li class="tocline1">9.4.18 <a href="#status.417">417 Expectation Failed</a></li>
</ul>
</li>
- <li class="tocline1">7.5 <a href="#status.5xx">Server Error 5xx</a><ul class="toc">
- <li class="tocline1">7.5.1 <a href="#status.500">500 Internal Server Error</a></li>
- <li class="tocline1">7.5.2 <a href="#status.501">501 Not Implemented</a></li>
- <li class="tocline1">7.5.3 <a href="#status.502">502 Bad Gateway</a></li>
- <li class="tocline1">7.5.4 <a href="#status.503">503 Service Unavailable</a></li>
- <li class="tocline1">7.5.5 <a href="#status.504">504 Gateway Timeout</a></li>
- <li class="tocline1">7.5.6 <a href="#status.505">505 HTTP Version Not Supported</a></li>
+ <li class="tocline1">9.5 <a href="#status.5xx">Server Error 5xx</a><ul class="toc">
+ <li class="tocline1">9.5.1 <a href="#status.500">500 Internal Server Error</a></li>
+ <li class="tocline1">9.5.2 <a href="#status.501">501 Not Implemented</a></li>
+ <li class="tocline1">9.5.3 <a href="#status.502">502 Bad Gateway</a></li>
+ <li class="tocline1">9.5.4 <a href="#status.503">503 Service Unavailable</a></li>
+ <li class="tocline1">9.5.5 <a href="#status.504">504 Gateway Timeout</a></li>
+ <li class="tocline1">9.5.6 <a href="#status.505">505 HTTP Version Not Supported</a></li>
</ul>
</li>
</ul>
</li>
- <li class="tocline0">8. <a href="#header.fields">Header Field Definitions</a><ul class="toc">
- <li class="tocline1">8.1 <a href="#header.allow">Allow</a></li>
- <li class="tocline1">8.2 <a href="#header.expect">Expect</a></li>
- <li class="tocline1">8.3 <a href="#header.from">From</a></li>
- <li class="tocline1">8.4 <a href="#header.host">Host</a></li>
- <li class="tocline1">8.5 <a href="#header.location">Location</a></li>
- <li class="tocline1">8.6 <a href="#header.max-forwards">Max-Forwards</a></li>
- <li class="tocline1">8.7 <a href="#header.referer">Referer</a></li>
- <li class="tocline1">8.8 <a href="#header.retry-after">Retry-After</a></li>
- <li class="tocline1">8.9 <a href="#header.server">Server</a></li>
- <li class="tocline1">8.10 <a href="#header.user-agent">User-Agent</a></li>
+ <li class="tocline0">10. <a href="#header.fields">Header Field Definitions</a><ul class="toc">
+ <li class="tocline1">10.1 <a href="#header.allow">Allow</a></li>
+ <li class="tocline1">10.2 <a href="#header.expect">Expect</a></li>
+ <li class="tocline1">10.3 <a href="#header.from">From</a></li>
+ <li class="tocline1">10.4 <a href="#header.location">Location</a></li>
+ <li class="tocline1">10.5 <a href="#header.max-forwards">Max-Forwards</a></li>
+ <li class="tocline1">10.6 <a href="#header.referer">Referer</a></li>
+ <li class="tocline1">10.7 <a href="#header.retry-after">Retry-After</a></li>
+ <li class="tocline1">10.8 <a href="#header.server">Server</a></li>
+ <li class="tocline1">10.9 <a href="#header.user-agent">User-Agent</a></li>
</ul>
</li>
- <li class="tocline0">9. <a href="#security.considerations">Security Considerations</a><ul class="toc">
- <li class="tocline1">9.1 <a href="#security.sensitive">Transfer of Sensitive Information</a></li>
- <li class="tocline1">9.2 <a href="#encoding.sensitive.information.in.uris">Encoding Sensitive Information in URI's</a></li>
- <li class="tocline1">9.3 <a href="#location.spoofing">Location Headers and Spoofing</a></li>
+ <li class="tocline0">11. <a href="#security.considerations">Security Considerations</a><ul class="toc">
+ <li class="tocline1">11.1 <a href="#security.sensitive">Transfer of Sensitive Information</a></li>
+ <li class="tocline1">11.2 <a href="#encoding.sensitive.information.in.uris">Encoding Sensitive Information in URI's</a></li>
+ <li class="tocline1">11.3 <a href="#location.spoofing">Location Headers and Spoofing</a></li>
</ul>
</li>
- <li class="tocline0">10. <a href="#ack">Acknowledgments</a></li>
- <li class="tocline0">11. <a href="#rfc.references">References</a></li>
+ <li class="tocline0">12. <a href="#ack">Acknowledgments</a></li>
+ <li class="tocline0">13. <a href="#rfc.references">References</a></li>
<li class="tocline0"><a href="#rfc.authors">Authors' Addresses</a></li>
- <li class="tocline0">A. <a href="#changes.from.1.0">Changes from HTTP/1.0</a><ul class="toc">
- <li class="tocline1">A.1 <a href="#changes.to.simplify.multi-homed.web.servers.and.conserve.ip.addresses">Changes to Simplify Multi-homed Web Servers and Conserve IP Addresses</a></li>
- </ul>
- </li>
- <li class="tocline0">B. <a href="#changes.from.rfc.2068">Changes from RFC 2068</a></li>
+ <li class="tocline0">A. <a href="#changes.from.rfc.2068">Changes from RFC 2068</a></li>
<li class="tocline0"><a href="#rfc.ipr">Intellectual Property and Copyright Statements</a></li>
<li class="tocline0"><a href="#rfc.index">Index</a></li>
</ul>
@@ -607,329 +589,232 @@
Server: Apache/0.8.4
</pre><p id="rfc.section.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 character <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).
</p>
- <h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a> <a id="request" href="#request">Request</a></h1>
- <p id="rfc.section.3.p.1">A request message from a client to a server includes, within the first line of that message, the method to be applied to the
- resource, the identifier of the resource, and the protocol version in use.
- </p>
- <div id="rfc.figure.u.3"></div><pre class="inline"><span id="rfc.iref.g.3"></span> Request = Request-Line ; <a href="#request-line" title="Request-Line">Section 3.1</a>
- *(( general-header ; [Part 1]
- | request-header ; <a href="#request.header.fields" title="Request Header Fields">Section 3.3</a>
- | entity-header ) CRLF) ; [Part 3]
- CRLF
- [ message-body ] ; [Part 1]
-</pre><h2 id="rfc.section.3.1"><a href="#rfc.section.3.1">3.1</a> <a id="request-line" href="#request-line">Request-Line</a></h2>
- <p id="rfc.section.3.1.p.1">The Request-Line begins with a method token, followed by the Request-URI and the protocol version, and ending with CRLF. The
- elements are separated by SP characters. No CR or LF is allowed except in the final CRLF sequence.
- </p>
- <div id="rfc.figure.u.4"></div><pre class="inline"><span id="rfc.iref.g.4"></span> Request-Line = Method SP Request-URI SP HTTP-Version CRLF
-</pre><h3 id="rfc.section.3.1.1"><a href="#rfc.section.3.1.1">3.1.1</a> <a id="method" href="#method">Method</a></h3>
- <p id="rfc.section.3.1.1.p.1">The Method token indicates the method to be performed on the resource identified by the Request-URI. The method is case-sensitive.</p>
- <div id="rfc.figure.u.5"></div><pre class="inline"><span id="rfc.iref.g.5"></span><span id="rfc.iref.g.6"></span> Method = "OPTIONS" ; <a href="#OPTIONS" id="rfc.xref.OPTIONS.1" title="OPTIONS">Section 6.2</a>
- | "GET" ; <a href="#GET" id="rfc.xref.GET.1" title="GET">Section 6.3</a>
- | "HEAD" ; <a href="#HEAD" id="rfc.xref.HEAD.1" title="HEAD">Section 6.4</a>
- | "POST" ; <a href="#POST" id="rfc.xref.POST.1" title="POST">Section 6.5</a>
- | "PUT" ; <a href="#PUT" id="rfc.xref.PUT.1" title="PUT">Section 6.6</a>
- | "DELETE" ; <a href="#DELETE" id="rfc.xref.DELETE.1" title="DELETE">Section 6.7</a>
- | "TRACE" ; <a href="#TRACE" id="rfc.xref.TRACE.1" title="TRACE">Section 6.8</a>
- | "CONNECT" ; <a href="#CONNECT" id="rfc.xref.CONNECT.1" title="CONNECT">Section 6.9</a>
+ <h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a> <a id="method" href="#method">Method</a></h1>
+ <p id="rfc.section.3.p.1">The Method token indicates the method to be performed on the resource identified by the Request-URI. The method is case-sensitive.</p>
+ <div id="rfc.figure.u.3"></div><pre class="inline"><span id="rfc.iref.g.3"></span><span id="rfc.iref.g.4"></span> Method = "OPTIONS" ; <a href="#OPTIONS" id="rfc.xref.OPTIONS.1" title="OPTIONS">Section 8.2</a>
+ | "GET" ; <a href="#GET" id="rfc.xref.GET.1" title="GET">Section 8.3</a>
+ | "HEAD" ; <a href="#HEAD" id="rfc.xref.HEAD.1" title="HEAD">Section 8.4</a>
+ | "POST" ; <a href="#POST" id="rfc.xref.POST.1" title="POST">Section 8.5</a>
+ | "PUT" ; <a href="#PUT" id="rfc.xref.PUT.1" title="PUT">Section 8.6</a>
+ | "DELETE" ; <a href="#DELETE" id="rfc.xref.DELETE.1" title="DELETE">Section 8.7</a>
+ | "TRACE" ; <a href="#TRACE" id="rfc.xref.TRACE.1" title="TRACE">Section 8.8</a>
+ | "CONNECT" ; <a href="#CONNECT" id="rfc.xref.CONNECT.1" title="CONNECT">Section 8.9</a>
| extension-method
extension-method = token
-</pre><p id="rfc.section.3.1.1.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 return code of the response always notifies the client whether a method is currently allowed on a resource, since the
+</pre><p id="rfc.section.3.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 10.1</a>). The return code of the response always notifies the client whether a method is currently allowed on a resource, since the
set of allowed methods can change dynamically. An origin server <em class="bcp14">SHOULD</em> return the status code 405 (Method Not Allowed) if the method is known by the origin server but not allowed for the requested
resource, and 501 (Not Implemented) if the method is unrecognized or not implemented by the origin server. The methods GET
- and HEAD <em class="bcp14">MUST</em> be supported by all general-purpose servers. All other methods are <em class="bcp14">OPTIONAL</em>; however, if the above methods are implemented, they <em class="bcp14">MUST</em> be implemented with the same semantics as those specified in <a href="#method.definitions" title="Method Definitions">Section 6</a>.
- </p>
- <h3 id="rfc.section.3.1.2"><a href="#rfc.section.3.1.2">3.1.2</a> <a id="request-uri" href="#request-uri">Request-URI</a></h3>
- <p id="rfc.section.3.1.2.p.1">The Request-URI is a Uniform Resource Identifier ([Part 1]) and identifies the resource upon which to apply the request.</p>
- <div id="rfc.figure.u.6"></div><pre class="inline"><span id="rfc.iref.g.7"></span> Request-URI = "*" | absoluteURI | abs_path | authority
-</pre><p id="rfc.section.3.1.2.p.3">The four options for Request-URI are dependent on the nature of the request. The asterisk "*" means that the request does
- not apply to a particular resource, but to the server itself, and is only allowed when the method used does not necessarily
- apply to a resource. One example would be
- </p>
- <div id="rfc.figure.u.7"></div><pre class="text"> OPTIONS * HTTP/1.1
-</pre><p id="rfc.section.3.1.2.p.5">The absoluteURI form is <em class="bcp14">REQUIRED</em> when the request is being made to a proxy. The proxy is requested to forward the request or service it from a valid cache,
- and return the response. Note that the proxy <em class="bcp14">MAY</em> forward the request on to another proxy or directly to the server specified by the absoluteURI. In order to avoid request
- loops, a proxy <em class="bcp14">MUST</em> be able to recognize all of its server names, including any aliases, local variations, and the numeric IP address. An example
- Request-Line would be:
- </p>
- <div id="rfc.figure.u.8"></div><pre class="text"> GET http://www.w3.org/pub/WWW/TheProject.html HTTP/1.1
-</pre><p id="rfc.section.3.1.2.p.7">To allow for transition to absoluteURIs in all requests in future versions of HTTP, all HTTP/1.1 servers <em class="bcp14">MUST</em> accept the absoluteURI form in requests, even though HTTP/1.1 clients will only generate them in requests to proxies.
- </p>
- <p id="rfc.section.3.1.2.p.8">The authority form is only used by the CONNECT method (<a href="#CONNECT" id="rfc.xref.CONNECT.2" title="CONNECT">Section 6.9</a>).
- </p>
- <p id="rfc.section.3.1.2.p.9">The most common form of Request-URI is that used to identify a resource on an origin server or gateway. In this case the absolute
- path of the URI <em class="bcp14">MUST</em> be transmitted (see [Part 1], abs_path) as the Request-URI, and the network location of the URI (authority) <em class="bcp14">MUST</em> be transmitted in a Host header field. For example, a client wishing to retrieve the resource above directly from the origin
- server would create a TCP connection to port 80 of the host "www.w3.org" and send the lines:
- </p>
- <div id="rfc.figure.u.9"></div><pre class="text"> GET /pub/WWW/TheProject.html HTTP/1.1
- Host: www.w3.org
-</pre><p id="rfc.section.3.1.2.p.11">followed by the remainder of the Request. Note that the absolute path cannot be empty; if none is present in the original
- URI, it <em class="bcp14">MUST</em> be given as "/" (the server root).
+ and HEAD <em class="bcp14">MUST</em> be supported by all general-purpose servers. All other methods are <em class="bcp14">OPTIONAL</em>; however, if the above methods are implemented, they <em class="bcp14">MUST</em> be implemented with the same semantics as those specified in <a href="#method.definitions" title="Method Definitions">Section 8</a>.
</p>
- <p id="rfc.section.3.1.2.p.12">The Request-URI is transmitted in the format specified in [Part 1]. If the Request-URI is encoded using the "% HEX HEX" encoding <a href="#RFC2396" id="rfc.xref.RFC2396.1"><cite title="Uniform Resource Identifiers (URI): Generic Syntax">[4]</cite></a>, the origin server <em class="bcp14">MUST</em> decode the Request-URI in order to properly interpret the request. Servers <em class="bcp14">SHOULD</em> respond to invalid Request-URIs with an appropriate status code.
- </p>
- <p id="rfc.section.3.1.2.p.13">A transparent proxy <em class="bcp14">MUST NOT</em> rewrite the "abs_path" part of the received Request-URI when forwarding it to the next inbound server, except as noted above
- to replace a null abs_path with "/".
- </p>
- <p id="rfc.section.3.1.2.p.14"> </p>
- <dl class="empty">
- <dd> <b>Note:</b> The "no rewrite" rule prevents the proxy from changing the meaning of the request when the origin server is improperly using
- a non-reserved URI character for a reserved purpose. Implementors should be aware that some pre-HTTP/1.1 proxies have been
- known to rewrite the Request-URI.
- </dd>
- </dl>
- <h2 id="rfc.section.3.2"><a href="#rfc.section.3.2">3.2</a> <a id="the.resource.identified.by.a.request" href="#the.resource.identified.by.a.request">The Resource Identified by a Request</a></h2>
- <p id="rfc.section.3.2.p.1">The exact resource identified by an Internet request is determined by examining both the Request-URI and the Host header field.</p>
- <p id="rfc.section.3.2.p.2">An origin server that does not allow resources to differ by the requested host <em class="bcp14">MAY</em> ignore the Host header field value when determining the resource identified by an HTTP/1.1 request. (But see <a href="#changes.to.simplify.multi-homed.web.servers.and.conserve.ip.addresses" title="Changes to Simplify Multi-homed Web Servers and Conserve IP Addresses">Appendix A.1</a> for other requirements on Host support in HTTP/1.1.)
- </p>
- <p id="rfc.section.3.2.p.3">An origin server that does differentiate resources based on the host requested (sometimes referred to as virtual hosts or
- vanity host names) <em class="bcp14">MUST</em> use the following rules for determining the requested resource on an HTTP/1.1 request:
- </p>
- <ol>
- <li>If Request-URI is an absoluteURI, the host is part of the Request-URI. Any Host header field value in the request <em class="bcp14">MUST</em> be ignored.
- </li>
- <li>If the Request-URI is not an absoluteURI, and the request includes a Host header field, the host is determined by the Host
- header field value.
- </li>
- <li>If the host as determined by rule 1 or 2 is not a valid host on the server, the response <em class="bcp14">MUST</em> be a 400 (Bad Request) error message.
- </li>
- </ol>
- <p id="rfc.section.3.2.p.4">Recipients of an HTTP/1.0 request that lacks a Host header field <em class="bcp14">MAY</em> attempt to use heuristics (e.g., examination of the URI path for something unique to a particular host) in order to determine
- what exact resource is being requested.
- </p>
- <h2 id="rfc.section.3.3"><a href="#rfc.section.3.3">3.3</a> <a id="request.header.fields" href="#request.header.fields">Request Header Fields</a></h2>
- <p id="rfc.section.3.3.p.1">The request-header fields allow the client to pass additional information about the request, and about the client itself,
+ <h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a> <a id="request.header.fields" href="#request.header.fields">Request Header Fields</a></h1>
+ <p id="rfc.section.4.p.1">The request-header fields allow the client to pass additional information about the request, and about the client itself,
to the server. These fields act as request modifiers, with semantics equivalent to the parameters on a programming language
method invocation.
</p>
- <div id="rfc.figure.u.10"></div><pre class="inline"><span id="rfc.iref.g.8"></span> request-header = Accept ; [Part 3]
+ <div id="rfc.figure.u.4"></div><pre class="inline"><span id="rfc.iref.g.5"></span> request-header = Accept ; [Part 3]
| Accept-Charset ; [Part 3]
| Accept-Encoding ; [Part 3]
| Accept-Language ; [Part 3]
| Authorization ; [Part 7]
- | Expect ; <a href="#header.expect" id="rfc.xref.header.expect.1" title="Expect">Section 8.2</a>
- | From ; <a href="#header.from" id="rfc.xref.header.from.1" title="From">Section 8.3</a>
- | Host ; <a href="#header.host" id="rfc.xref.header.host.1" title="Host">Section 8.4</a>
+ | Expect ; <a href="#header.expect" id="rfc.xref.header.expect.1" title="Expect">Section 10.2</a>
+ | From ; <a href="#header.from" id="rfc.xref.header.from.1" title="From">Section 10.3</a>
+ | Host ; [Part 1]
| If-Match ; [Part 4]
| If-Modified-Since ; [Part 4]
| If-None-Match ; [Part 4]
| If-Range ; [Part 5]
| If-Unmodified-Since ; [Part 4]
- | Max-Forwards ; <a href="#header.max-forwards" id="rfc.xref.header.max-forwards.1" title="Max-Forwards">Section 8.6</a>
+ | Max-Forwards ; <a href="#header.max-forwards" id="rfc.xref.header.max-forwards.1" title="Max-Forwards">Section 10.5</a>
| Proxy-Authorization ; [Part 7]
| Range ; [Part 5]
- | Referer ; <a href="#header.referer" id="rfc.xref.header.referer.1" title="Referer">Section 8.7</a>
+ | Referer ; <a href="#header.referer" id="rfc.xref.header.referer.1" title="Referer">Section 10.6</a>
| TE ; [Part 1]
- | User-Agent ; <a href="#header.user-agent" id="rfc.xref.header.user-agent.1" title="User-Agent">Section 8.10</a>
-</pre><p id="rfc.section.3.3.p.3">Request-header field names can be extended reliably only in combination with a change in the protocol version. However, new
+ | User-Agent ; <a href="#header.user-agent" id="rfc.xref.header.user-agent.1" title="User-Agent">Section 10.9</a>
+</pre><p id="rfc.section.4.p.3">Request-header field names can be extended reliably only in combination with a change in the protocol version. However, new
or experimental header fields <em class="bcp14">MAY</em> be given the semantics of request-header fields if all parties in the communication recognize them to be request-header fields.
Unrecognized header fields are treated as entity-header fields.
</p>
- <h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a> <a id="response" href="#response">Response</a></h1>
- <p id="rfc.section.4.p.1">After receiving and interpreting a request message, a server responds with an HTTP response message.</p>
- <div id="rfc.figure.u.11"></div><pre class="inline"><span id="rfc.iref.g.9"></span> Response = Status-Line ; <a href="#status-line" title="Status-Line">Section 4.1</a>
- *(( general-header ; [Part 1]
- | response-header ; <a href="#response.header.fields" title="Response Header Fields">Section 4.2</a>
- | entity-header ) CRLF) ; [Part 3]
- CRLF
- [ message-body ] ; [Part 1]
-</pre><h2 id="rfc.section.4.1"><a href="#rfc.section.4.1">4.1</a> <a id="status-line" href="#status-line">Status-Line</a></h2>
- <p id="rfc.section.4.1.p.1">The first line of a Response message is the Status-Line, consisting of the protocol version followed by a numeric status code
- and its associated textual phrase, with each element separated by SP characters. No CR or LF is allowed except in the final
- CRLF sequence.
- </p>
- <div id="rfc.figure.u.12"></div><pre class="inline"><span id="rfc.iref.g.10"></span> Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF
-</pre><h3 id="rfc.section.4.1.1"><a href="#rfc.section.4.1.1">4.1.1</a> <a id="status.code.and.reason.phrase" href="#status.code.and.reason.phrase">Status Code and Reason Phrase</a></h3>
- <p id="rfc.section.4.1.1.p.1">The Status-Code element is a 3-digit integer result code of the attempt to understand and satisfy the request. These codes
- are fully defined in <a href="#status.codes" title="Status Code Definitions">Section 7</a>. The Reason-Phrase is intended to give a short textual description of the Status-Code. The Status-Code is intended for use
+ <h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a> <a id="status.code.and.reason.phrase" href="#status.code.and.reason.phrase">Status Code and Reason Phrase</a></h1>
+ <p id="rfc.section.5.p.1">The Status-Code element is a 3-digit integer result code of the attempt to understand and satisfy the request. These codes
+ are fully defined in <a href="#status.codes" title="Status Code Definitions">Section 9</a>. The Reason-Phrase is intended to give a short textual description of the Status-Code. The Status-Code is intended for use
by automata and the Reason-Phrase is intended for the human user. The client is not required to examine or display the Reason-Phrase.
</p>
- <p id="rfc.section.4.1.1.p.2">The first digit of the Status-Code defines the class of response. The last two digits do not have any categorization role.
- There are 5 values for the first digit:
- </p>
- <ul>
- <li>1xx: Informational - Request received, continuing process</li>
- <li>2xx: Success - The action was successfully received, understood, and accepted</li>
- <li>3xx: Redirection - Further action must be taken in order to complete the request</li>
- <li>4xx: Client Error - The request contains bad syntax or cannot be fulfilled</li>
- <li>5xx: Server Error - The server failed to fulfill an apparently valid request</li>
- </ul>
- <p id="rfc.section.4.1.1.p.3">The individual values of the numeric status codes defined for HTTP/1.1, and an example set of corresponding Reason-Phrase's,
+ <p id="rfc.section.5.p.2">The individual values of the numeric status codes defined for HTTP/1.1, and an example set of corresponding Reason-Phrase's,
are presented below. The reason phrases listed here are only recommendations -- they <em class="bcp14">MAY</em> be replaced by local equivalents without affecting the protocol.
</p>
- <div id="rfc.figure.u.13"></div><pre class="inline"><span id="rfc.iref.g.11"></span><span id="rfc.iref.g.12"></span><span id="rfc.iref.g.13"></span> Status-Code =
- "100" ; <a href="#status.100" id="rfc.xref.status.100.1" title="100 Continue">Section 7.1.1</a>: Continue
- | "101" ; <a href="#status.101" id="rfc.xref.status.101.1" title="101 Switching Protocols">Section 7.1.2</a>: Switching Protocols
- | "200" ; <a href="#status.200" id="rfc.xref.status.200.1" title="200 OK">Section 7.2.1</a>: OK
- | "201" ; <a href="#status.201" id="rfc.xref.status.201.1" title="201 Created">Section 7.2.2</a>: Created
- | "202" ; <a href="#status.202" id="rfc.xref.status.202.1" title="202 Accepted">Section 7.2.3</a>: Accepted
- | "203" ; <a href="#status.203" id="rfc.xref.status.203.1" title="203 Non-Authoritative Information">Section 7.2.4</a>: Non-Authoritative Information
- | "204" ; <a href="#status.204" id="rfc.xref.status.204.1" title="204 No Content">Section 7.2.5</a>: No Content
- | "205" ; <a href="#status.205" id="rfc.xref.status.205.1" title="205 Reset Content">Section 7.2.6</a>: Reset Content
- | "206" ; <a href="#status.206" id="rfc.xref.status.206.1" title="206 Partial Content">Section 7.2.7</a>: Partial Content
- | "300" ; <a href="#status.300" id="rfc.xref.status.300.1" title="300 Multiple Choices">Section 7.3.1</a>: Multiple Choices
- | "301" ; <a href="#status.301" id="rfc.xref.status.301.1" title="301 Moved Permanently">Section 7.3.2</a>: Moved Permanently
- | "302" ; <a href="#status.302" id="rfc.xref.status.302.1" title="302 Found">Section 7.3.3</a>: Found
- | "303" ; <a href="#status.303" id="rfc.xref.status.303.1" title="303 See Other">Section 7.3.4</a>: See Other
- | "304" ; <a href="#status.304" id="rfc.xref.status.304.1" title="304 Not Modified">Section 7.3.5</a>: Not Modified
- | "305" ; <a href="#status.305" id="rfc.xref.status.305.1" title="305 Use Proxy">Section 7.3.6</a>: Use Proxy
- | "307" ; <a href="#status.307" id="rfc.xref.status.307.1" title="307 Temporary Redirect">Section 7.3.8</a>: Temporary Redirect
- | "400" ; <a href="#status.400" id="rfc.xref.status.400.1" title="400 Bad Request">Section 7.4.1</a>: Bad Request
- | "401" ; <a href="#status.401" id="rfc.xref.status.401.1" title="401 Unauthorized">Section 7.4.2</a>: Unauthorized
- | "402" ; <a href="#status.402" id="rfc.xref.status.402.1" title="402 Payment Required">Section 7.4.3</a>: Payment Required
- | "403" ; <a href="#status.403" id="rfc.xref.status.403.1" title="403 Forbidden">Section 7.4.4</a>: Forbidden
- | "404" ; <a href="#status.404" id="rfc.xref.status.404.1" title="404 Not Found">Section 7.4.5</a>: Not Found
- | "405" ; <a href="#status.405" id="rfc.xref.status.405.1" title="405 Method Not Allowed">Section 7.4.6</a>: Method Not Allowed
- | "406" ; <a href="#status.406" id="rfc.xref.status.406.1" title="406 Not Acceptable">Section 7.4.7</a>: Not Acceptable
- | "407" ; <a href="#status.407" id="rfc.xref.status.407.1" title="407 Proxy Authentication Required">Section 7.4.8</a>: Proxy Authentication Required
- | "408" ; <a href="#status.408" id="rfc.xref.status.408.1" title="408 Request Timeout">Section 7.4.9</a>: Request Time-out
- | "409" ; <a href="#status.409" id="rfc.xref.status.409.1" title="409 Conflict">Section 7.4.10</a>: Conflict
- | "410" ; <a href="#status.410" id="rfc.xref.status.410.1" title="410 Gone">Section 7.4.11</a>: Gone
- | "411" ; <a href="#status.411" id="rfc.xref.status.411.1" title="411 Length Required">Section 7.4.12</a>: Length Required
- | "412" ; <a href="#status.412" id="rfc.xref.status.412.1" title="412 Precondition Failed">Section 7.4.13</a>: Precondition Failed
- | "413" ; <a href="#status.413" id="rfc.xref.status.413.1" title="413 Request Entity Too Large">Section 7.4.14</a>: Request Entity Too Large
- | "414" ; <a href="#status.414" id="rfc.xref.status.414.1" title="414 Request-URI Too Long">Section 7.4.15</a>: Request-URI Too Large
- | "415" ; <a href="#status.415" id="rfc.xref.status.415.1" title="415 Unsupported Media Type">Section 7.4.16</a>: Unsupported Media Type
- | "416" ; <a href="#status.416" id="rfc.xref.status.416.1" title="416 Requested Range Not Satisfiable">Section 7.4.17</a>: Requested range not satisfiable
- | "417" ; <a href="#status.417" id="rfc.xref.status.417.1" title="417 Expectation Failed">Section 7.4.18</a>: Expectation Failed
- | "500" ; <a href="#status.500" id="rfc.xref.status.500.1" title="500 Internal Server Error">Section 7.5.1</a>: Internal Server Error
- | "501" ; <a href="#status.501" id="rfc.xref.status.501.1" title="501 Not Implemented">Section 7.5.2</a>: Not Implemented
- | "502" ; <a href="#status.502" id="rfc.xref.status.502.1" title="502 Bad Gateway">Section 7.5.3</a>: Bad Gateway
- | "503" ; <a href="#status.503" id="rfc.xref.status.503.1" title="503 Service Unavailable">Section 7.5.4</a>: Service Unavailable
- | "504" ; <a href="#status.504" id="rfc.xref.status.504.1" title="504 Gateway Timeout">Section 7.5.5</a>: Gateway Time-out
- | "505" ; <a href="#status.505" id="rfc.xref.status.505.1" title="505 HTTP Version Not Supported">Section 7.5.6</a>: HTTP Version not supported
+ <div id="rfc.figure.u.5"></div><pre class="inline"><span id="rfc.iref.g.6"></span><span id="rfc.iref.g.7"></span><span id="rfc.iref.g.8"></span> Status-Code =
+ "100" ; <a href="#status.100" id="rfc.xref.status.100.1" title="100 Continue">Section 9.1.1</a>: Continue
+ | "101" ; <a href="#status.101" id="rfc.xref.status.101.1" title="101 Switching Protocols">Section 9.1.2</a>: Switching Protocols
+ | "200" ; <a href="#status.200" id="rfc.xref.status.200.1" title="200 OK">Section 9.2.1</a>: OK
+ | "201" ; <a href="#status.201" id="rfc.xref.status.201.1" title="201 Created">Section 9.2.2</a>: Created
+ | "202" ; <a href="#status.202" id="rfc.xref.status.202.1" title="202 Accepted">Section 9.2.3</a>: Accepted
+ | "203" ; <a href="#status.203" id="rfc.xref.status.203.1" title="203 Non-Authoritative Information">Section 9.2.4</a>: Non-Authoritative Information
+ | "204" ; <a href="#status.204" id="rfc.xref.status.204.1" title="204 No Content">Section 9.2.5</a>: No Content
+ | "205" ; <a href="#status.205" id="rfc.xref.status.205.1" title="205 Reset Content">Section 9.2.6</a>: Reset Content
+ | "206" ; <a href="#status.206" id="rfc.xref.status.206.1" title="206 Partial Content">Section 9.2.7</a>: Partial Content
+ | "300" ; <a href="#status.300" id="rfc.xref.status.300.1" title="300 Multiple Choices">Section 9.3.1</a>: Multiple Choices
+ | "301" ; <a href="#status.301" id="rfc.xref.status.301.1" title="301 Moved Permanently">Section 9.3.2</a>: Moved Permanently
+ | "302" ; <a href="#status.302" id="rfc.xref.status.302.1" title="302 Found">Section 9.3.3</a>: Found
+ | "303" ; <a href="#status.303" id="rfc.xref.status.303.1" title="303 See Other">Section 9.3.4</a>: See Other
+ | "304" ; <a href="#status.304" id="rfc.xref.status.304.1" title="304 Not Modified">Section 9.3.5</a>: Not Modified
+ | "305" ; <a href="#status.305" id="rfc.xref.status.305.1" title="305 Use Proxy">Section 9.3.6</a>: Use Proxy
+ | "307" ; <a href="#status.307" id="rfc.xref.status.307.1" title="307 Temporary Redirect">Section 9.3.8</a>: Temporary Redirect
+ | "400" ; <a href="#status.400" id="rfc.xref.status.400.1" title="400 Bad Request">Section 9.4.1</a>: Bad Request
+ | "401" ; <a href="#status.401" id="rfc.xref.status.401.1" title="401 Unauthorized">Section 9.4.2</a>: Unauthorized
+ | "402" ; <a href="#status.402" id="rfc.xref.status.402.1" title="402 Payment Required">Section 9.4.3</a>: Payment Required
+ | "403" ; <a href="#status.403" id="rfc.xref.status.403.1" title="403 Forbidden">Section 9.4.4</a>: Forbidden
+ | "404" ; <a href="#status.404" id="rfc.xref.status.404.1" title="404 Not Found">Section 9.4.5</a>: Not Found
+ | "405" ; <a href="#status.405" id="rfc.xref.status.405.1" title="405 Method Not Allowed">Section 9.4.6</a>: Method Not Allowed
+ | "406" ; <a href="#status.406" id="rfc.xref.status.406.1" title="406 Not Acceptable">Section 9.4.7</a>: Not Acceptable
+ | "407" ; <a href="#status.407" id="rfc.xref.status.407.1" title="407 Proxy Authentication Required">Section 9.4.8</a>: Proxy Authentication Required
+ | "408" ; <a href="#status.408" id="rfc.xref.status.408.1" title="408 Request Timeout">Section 9.4.9</a>: Request Time-out
+ | "409" ; <a href="#status.409" id="rfc.xref.status.409.1" title="409 Conflict">Section 9.4.10</a>: Conflict
+ | "410" ; <a href="#status.410" id="rfc.xref.status.410.1" title="410 Gone">Section 9.4.11</a>: Gone
+ | "411" ; <a href="#status.411" id="rfc.xref.status.411.1" title="411 Length Required">Section 9.4.12</a>: Length Required
+ | "412" ; <a href="#status.412" id="rfc.xref.status.412.1" title="412 Precondition Failed">Section 9.4.13</a>: Precondition Failed
+ | "413" ; <a href="#status.413" id="rfc.xref.status.413.1" title="413 Request Entity Too Large">Section 9.4.14</a>: Request Entity Too Large
+ | "414" ; <a href="#status.414" id="rfc.xref.status.414.1" title="414 Request-URI Too Long">Section 9.4.15</a>: Request-URI Too Large
+ | "415" ; <a href="#status.415" id="rfc.xref.status.415.1" title="415 Unsupported Media Type">Section 9.4.16</a>: Unsupported Media Type
+ | "416" ; <a href="#status.416" id="rfc.xref.status.416.1" title="416 Requested Range Not Satisfiable">Section 9.4.17</a>: Requested range not satisfiable
+ | "417" ; <a href="#status.417" id="rfc.xref.status.417.1" title="417 Expectation Failed">Section 9.4.18</a>: Expectation Failed
+ | "500" ; <a href="#status.500" id="rfc.xref.status.500.1" title="500 Internal Server Error">Section 9.5.1</a>: Internal Server Error
+ | "501" ; <a href="#status.501" id="rfc.xref.status.501.1" title="501 Not Implemented">Section 9.5.2</a>: Not Implemented
+ | "502" ; <a href="#status.502" id="rfc.xref.status.502.1" title="502 Bad Gateway">Section 9.5.3</a>: Bad Gateway
+ | "503" ; <a href="#status.503" id="rfc.xref.status.503.1" title="503 Service Unavailable">Section 9.5.4</a>: Service Unavailable
+ | "504" ; <a href="#status.504" id="rfc.xref.status.504.1" title="504 Gateway Timeout">Section 9.5.5</a>: Gateway Time-out
+ | "505" ; <a href="#status.505" id="rfc.xref.status.505.1" title="505 HTTP Version Not Supported">Section 9.5.6</a>: HTTP Version not supported
| extension-code
extension-code = 3DIGIT
Reason-Phrase = *<TEXT, excluding CR, LF>
-</pre><p id="rfc.section.4.1.1.p.5">HTTP status codes are extensible. HTTP applications are not required to understand the meaning of all registered status codes,
+</pre><p id="rfc.section.5.p.4">HTTP status codes are extensible. HTTP applications are not required to understand the meaning of all registered status codes,
though such understanding is obviously desirable. However, applications <em class="bcp14">MUST</em> understand the class of any status code, as indicated by the first digit, and treat any unrecognized response as being equivalent
to the x00 status code of that class, with the exception that an unrecognized response <em class="bcp14">MUST NOT</em> be cached. For example, if an unrecognized status code of 431 is received by the client, it can safely assume that there was
something wrong with its request and treat the response as if it had received a 400 status code. In such cases, user agents <em class="bcp14">SHOULD</em> present to the user the entity returned with the response, since that entity is likely to include human-readable information
which will explain the unusual status.
</p>
- <h2 id="rfc.section.4.2"><a href="#rfc.section.4.2">4.2</a> <a id="response.header.fields" href="#response.header.fields">Response Header Fields</a></h2>
- <p id="rfc.section.4.2.p.1">The response-header fields allow the server to pass additional information about the response which cannot be placed in the
+ <h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a> <a id="response.header.fields" href="#response.header.fields">Response Header Fields</a></h1>
+ <p id="rfc.section.6.p.1">The response-header fields allow the server to pass additional information about the response which cannot be placed in the
Status-Line. These header fields give information about the server and about further access to the resource identified by
the Request-URI.
</p>
- <div id="rfc.figure.u.14"></div><pre class="inline"><span id="rfc.iref.g.14"></span> response-header = Accept-Ranges ; [Part 3]
+ <div id="rfc.figure.u.6"></div><pre class="inline"><span id="rfc.iref.g.9"></span> response-header = Accept-Ranges ; [Part 3]
| Age ; [Part 6]
| ETag ; [Part 4]
- | Location ; <a href="#header.location" id="rfc.xref.header.location.1" title="Location">Section 8.5</a>
+ | Location ; <a href="#header.location" id="rfc.xref.header.location.1" title="Location">Section 10.4</a>
| Proxy-Authenticate ; [Part 7]
- | Retry-After ; <a href="#header.retry-after" id="rfc.xref.header.retry-after.1" title="Retry-After">Section 8.8</a>
- | Server ; <a href="#header.server" id="rfc.xref.header.server.1" title="Server">Section 8.9</a>
+ | Retry-After ; <a href="#header.retry-after" id="rfc.xref.header.retry-after.1" title="Retry-After">Section 10.7</a>
+ | Server ; <a href="#header.server" id="rfc.xref.header.server.1" title="Server">Section 10.8</a>
| Vary ; [Part 6]
| WWW-Authenticate ; [Part 7]
-</pre><p id="rfc.section.4.2.p.3">Response-header field names can be extended reliably only in combination with a change in the protocol version. However, new
+</pre><p id="rfc.section.6.p.3">Response-header field names can be extended reliably only in combination with a change in the protocol version. However, new
or experimental header fields <em class="bcp14">MAY</em> be given the semantics of response-header fields if all parties in the communication recognize them to be response-header
fields. Unrecognized header fields are treated as entity-header fields.
</p>
- <h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a> <a id="entity" href="#entity">Entity</a></h1>
- <p id="rfc.section.5.p.1">Request and Response messages <em class="bcp14">MAY</em> transfer an entity if not otherwise restricted by the request method or response status code. An entity consists of entity-header
+ <h1 id="rfc.section.7"><a href="#rfc.section.7">7.</a> <a id="entity" href="#entity">Entity</a></h1>
+ <p id="rfc.section.7.p.1">Request and Response messages <em class="bcp14">MAY</em> transfer an entity if not otherwise restricted by the request method or response status code. An entity consists of entity-header
fields and an entity-body, although some responses will only include the entity-headers. HTTP entity-body and entity-header
fields are defined in [Part 3].
</p>
- <p id="rfc.section.5.p.2">An entity-body is only present in a message when a message-body is present, as described in [Part 1]. The entity-body is obtained
+ <p id="rfc.section.7.p.2">An entity-body is only present in a message when a message-body is present, as described in [Part 1]. The entity-body is obtained
from the message-body by decoding any Transfer-Encoding that might have been applied to ensure safe and proper transfer of
the message.
</p>
- <h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a> <a id="method.definitions" href="#method.definitions">Method Definitions</a></h1>
- <p id="rfc.section.6.p.1">The set of common methods for HTTP/1.1 is defined below. Although this set can be expanded, additional methods cannot be assumed
- to share the same semantics for separately extended clients and servers. The Host request-header field (<a href="#header.host" id="rfc.xref.header.host.2" title="Host">Section 8.4</a>) <em class="bcp14">MUST</em> accompany all HTTP/1.1 requests.
- </p>
- <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>
- <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>
- <p id="rfc.section.6.1.1.p.1">Implementors should be aware that the software represents the user in their interactions over the Internet, and should be
+ <h1 id="rfc.section.8"><a href="#rfc.section.8">8.</a> <a id="method.definitions" href="#method.definitions">Method Definitions</a></h1>
+ <p id="rfc.section.8.p.1">The set of common methods for HTTP/1.1 is defined below. Although this set can be expanded, additional methods cannot be assumed
+ to share the same semantics for separately extended clients and servers. The Host request-header field ([Part 1]) <em class="bcp14">MUST</em> accompany all HTTP/1.1 requests.
+ </p>
+ <h2 id="rfc.section.8.1"><a href="#rfc.section.8.1">8.1</a> <a id="safe.and.idempotent" href="#safe.and.idempotent">Safe and Idempotent Methods</a></h2>
+ <h3 id="rfc.section.8.1.1"><a href="#rfc.section.8.1.1">8.1.1</a> <a id="safe.methods" href="#safe.methods">Safe Methods</a></h3>
+ <p id="rfc.section.8.1.1.p.1">Implementors should be aware that the software represents the user in their interactions over the Internet, and should be
careful to allow the user to be aware of any actions they might take which may have an unexpected significance to themselves
or others.
</p>
- <p id="rfc.section.6.1.1.p.2">In particular, the convention has been established that the GET and HEAD methods <em class="bcp14">SHOULD NOT</em> have the significance of taking an action other than retrieval. These methods ought to be considered "safe". This allows user
+ <p id="rfc.section.8.1.1.p.2">In particular, the convention has been established that the GET and HEAD methods <em class="bcp14">SHOULD NOT</em> have the significance of taking an action other than retrieval. These methods ought to be considered "safe". This allows user
agents to represent other methods, such as POST, PUT and DELETE, in a special way, so that the user is made aware of the fact
that a possibly unsafe action is being requested.
</p>
- <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;
+ <p id="rfc.section.8.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;
in fact, some dynamic resources consider that a feature. The important distinction here is that the user did not request the
side-effects, so therefore cannot be held accountable for them.
</p>
- <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>
- <p id="rfc.section.6.1.2.p.1">Methods can also have the property of "idempotence" in that (aside from error or expiration issues) the side-effects of N
+ <h3 id="rfc.section.8.1.2"><a href="#rfc.section.8.1.2">8.1.2</a> <a id="idempotent.methods" href="#idempotent.methods">Idempotent Methods</a></h3>
+ <p id="rfc.section.8.1.2.p.1">Methods can also have the property of "idempotence" in that (aside from error or expiration issues) the side-effects of N
> 0 identical requests is the same as for a single request. The methods GET, HEAD, PUT and DELETE share this property. Also,
the methods OPTIONS and TRACE <em class="bcp14">SHOULD NOT</em> have side effects, and so are inherently idempotent.
</p>
- <p id="rfc.section.6.1.2.p.2">However, it is possible that a sequence of several requests is non-idempotent, even if all of the methods executed in that
+ <p id="rfc.section.8.1.2.p.2">However, it is possible that a sequence of several requests is non-idempotent, even if all of the methods executed in that
sequence are idempotent. (A sequence is idempotent if a single execution of the entire sequence always yields a result that
is not changed by a reexecution of all, or part, of that sequence.) For example, a sequence is non-idempotent if its result
depends on a value that is later modified in the same sequence.
</p>
- <p id="rfc.section.6.1.2.p.3">A sequence that never has side effects is idempotent, by definition (provided that no concurrent operations are being executed
+ <p id="rfc.section.8.1.2.p.3">A sequence that never has side effects is idempotent, by definition (provided that no concurrent operations are being executed
on the same set of resources).
</p>
<div id="rfc.iref.o.1"></div>
<div id="rfc.iref.m.1"></div>
- <h2 id="rfc.section.6.2"><a href="#rfc.section.6.2">6.2</a> <a id="OPTIONS" href="#OPTIONS">OPTIONS</a></h2>
- <p id="rfc.section.6.2.p.1">The OPTIONS method represents a request for information about the communication options available on the request/response
+ <h2 id="rfc.section.8.2"><a href="#rfc.section.8.2">8.2</a> <a id="OPTIONS" href="#OPTIONS">OPTIONS</a></h2>
+ <p id="rfc.section.8.2.p.1">The OPTIONS method represents a request for information about the communication options available on the request/response
chain identified by the Request-URI. This method allows the client to determine the options and/or requirements associated
with a resource, or the capabilities of a server, without implying a resource action or initiating a resource retrieval.
</p>
- <p id="rfc.section.6.2.p.2">Responses to this method are not cacheable.</p>
- <p id="rfc.section.6.2.p.3">If the OPTIONS request includes an entity-body (as indicated by the presence of Content-Length or Transfer-Encoding), then
+ <p id="rfc.section.8.2.p.2">Responses to this method are not cacheable.</p>
+ <p id="rfc.section.8.2.p.3">If the OPTIONS request includes an entity-body (as indicated by the presence of Content-Length or Transfer-Encoding), then
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
to HTTP might use the OPTIONS body to make more detailed queries on the server. A server that does not support such an extension <em class="bcp14">MAY</em> discard the request body.
</p>
- <p id="rfc.section.6.2.p.4">If the Request-URI is an asterisk ("*"), the OPTIONS request is intended to apply to the server in general rather than to
+ <p id="rfc.section.8.2.p.4">If the Request-URI is an asterisk ("*"), the OPTIONS request is intended to apply to the server in general rather than to
a specific resource. Since a server's communication options typically depend on the resource, the "*" request is only useful
as a "ping" or "no-op" type of method; it does nothing beyond allowing the client to test the capabilities of the server.
For example, this can be used to test a proxy for HTTP/1.1 compliance (or lack thereof).
</p>
- <p id="rfc.section.6.2.p.5">If the Request-URI is not an asterisk, the OPTIONS request applies only to the options that are available when communicating
+ <p id="rfc.section.8.2.p.5">If the Request-URI is not an asterisk, the OPTIONS request applies only to the options that are available when communicating
with that resource.
</p>
- <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.,
+ <p id="rfc.section.8.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.,
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,
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".
</p>
- <p id="rfc.section.6.2.p.7">The Max-Forwards request-header field <em class="bcp14">MAY</em> be used to target a specific proxy in the request chain. When a proxy receives an OPTIONS request on an absoluteURI for which
+ <p id="rfc.section.8.2.p.7">The Max-Forwards request-header field <em class="bcp14">MAY</em> be used to target a specific proxy in the request chain. When a proxy receives an OPTIONS request on an absoluteURI for which
request forwarding is permitted, the proxy <em class="bcp14">MUST</em> check for a Max-Forwards field. If the Max-Forwards field-value is zero ("0"), the proxy <em class="bcp14">MUST NOT</em> forward the message; instead, the proxy <em class="bcp14">SHOULD</em> respond with its own communication options. If the Max-Forwards field-value is an integer greater than zero, the proxy <em class="bcp14">MUST</em> decrement the field-value when it forwards the request. 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.
</p>
- <div id="rfc.iref.g.15"></div>
+ <div id="rfc.iref.g.10"></div>
<div id="rfc.iref.m.2"></div>
- <h2 id="rfc.section.6.3"><a href="#rfc.section.6.3">6.3</a> <a id="GET" href="#GET">GET</a></h2>
- <p id="rfc.section.6.3.p.1">The GET method means retrieve whatever information (in the form of an entity) is identified by the Request-URI. If the Request-URI
+ <h2 id="rfc.section.8.3"><a href="#rfc.section.8.3">8.3</a> <a id="GET" href="#GET">GET</a></h2>
+ <p id="rfc.section.8.3.p.1">The GET method means retrieve whatever information (in the form of an entity) is identified by the Request-URI. If the Request-URI
refers to a data-producing process, it is the produced data which shall be returned as the entity in the response and not
the source text of the process, unless that text happens to be the output of the process.
</p>
- <p id="rfc.section.6.3.p.2">The semantics of the GET method change to a "conditional GET" if the request message includes an If-Modified-Since, If-Unmodified-Since,
+ <p id="rfc.section.8.3.p.2">The semantics of the GET method change to a "conditional GET" if the request message includes an If-Modified-Since, If-Unmodified-Since,
If-Match, If-None-Match, or If-Range header field. A conditional GET method requests that the entity be transferred only under
the circumstances described by the conditional header field(s). The conditional GET method is intended to reduce unnecessary
network usage by allowing cached entities to be refreshed without requiring multiple requests or transferring data already
held by the client.
</p>
- <p id="rfc.section.6.3.p.3">The semantics of the GET method change to a "partial GET" if the request message includes a Range header field. A partial
+ <p id="rfc.section.8.3.p.3">The semantics of the GET method change to a "partial GET" if the request message includes a Range header field. A partial
GET requests that only part of the entity be transferred, as described in [Part 5]. The partial GET method is intended to
reduce unnecessary network usage by allowing partially-retrieved entities to be completed without transferring data already
held by the client.
</p>
- <p id="rfc.section.6.3.p.4">The response to a GET request is cacheable if and only if it meets the requirements for HTTP caching described in [Part 6].</p>
- <p id="rfc.section.6.3.p.5">See <a href="#encoding.sensitive.information.in.uris" title="Encoding Sensitive Information in URI's">Section 9.2</a> for security considerations when used for forms.
+ <p id="rfc.section.8.3.p.4">The response to a GET request is cacheable if and only if it meets the requirements for HTTP caching described in [Part 6].</p>
+ <p id="rfc.section.8.3.p.5">See <a href="#encoding.sensitive.information.in.uris" title="Encoding Sensitive Information in URI's">Section 11.2</a> for security considerations when used for forms.
</p>
<div id="rfc.iref.h.1"></div>
<div id="rfc.iref.m.3"></div>
- <h2 id="rfc.section.6.4"><a href="#rfc.section.6.4">6.4</a> <a id="HEAD" href="#HEAD">HEAD</a></h2>
- <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 metainformation contained in the HTTP headers 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 metainformation about
+ <h2 id="rfc.section.8.4"><a href="#rfc.section.8.4">8.4</a> <a id="HEAD" href="#HEAD">HEAD</a></h2>
+ <p id="rfc.section.8.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 metainformation contained in the HTTP headers 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 metainformation about
the entity implied by the request without transferring the entity-body itself. This method is often used for testing hypertext
links for validity, accessibility, and recent modification.
</p>
- <p id="rfc.section.6.4.p.2">The response to a HEAD request <em class="bcp14">MAY</em> be cacheable in the sense that the information contained in the response <em class="bcp14">MAY</em> be used to update a previously cached entity from that resource. If the new field values indicate that the cached entity differs
+ <p id="rfc.section.8.4.p.2">The response to a HEAD request <em class="bcp14">MAY</em> be cacheable in the sense that the information contained in the response <em class="bcp14">MAY</em> be used to update a previously cached entity from that resource. If the new field values indicate that the cached entity differs
from the current entity (as would be indicated by a change in Content-Length, Content-MD5, ETag or Last-Modified), then the
cache <em class="bcp14">MUST</em> treat the cache entry as stale.
</p>
<div id="rfc.iref.p.1"></div>
<div id="rfc.iref.m.4"></div>
- <h2 id="rfc.section.6.5"><a href="#rfc.section.6.5">6.5</a> <a id="POST" href="#POST">POST</a></h2>
- <p id="rfc.section.6.5.p.1">The POST method is used to request that the origin server accept the entity enclosed in the request as a new subordinate of
+ <h2 id="rfc.section.8.5"><a href="#rfc.section.8.5">8.5</a> <a id="POST" href="#POST">POST</a></h2>
+ <p id="rfc.section.8.5.p.1">The POST method is used to request that the origin server accept the entity enclosed in the request as a new subordinate of
the resource identified by the Request-URI in the Request-Line. POST is designed to allow a uniform method to cover the following
functions:
</p>
@@ -939,125 +824,125 @@
<li>Providing a block of data, such as the result of submitting a form, to a data-handling process;</li>
<li>Extending a database through an append operation.</li>
</ul>
- <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 Request-URI.
+ <p id="rfc.section.8.5.p.2">The actual function performed by the POST method is determined by the server and is usually dependent on the Request-URI.
The posted entity is subordinate to that URI in the same way that a file is subordinate to a directory containing it, a news
article is subordinate to a newsgroup to which it is posted, or a record is subordinate to a database.
</p>
- <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
+ <p id="rfc.section.8.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
200 (OK) or 204 (No Content) is the appropriate response status, depending on whether or not the response includes an entity
that describes the result.
</p>
- <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 an entity which describes the status of the request and refers to the new resource, and a Location
- header (see <a href="#header.location" id="rfc.xref.header.location.2" title="Location">Section 8.5</a>).
+ <p id="rfc.section.8.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 an entity which describes the status of the request and refers to the new resource, and a Location
+ header (see <a href="#header.location" id="rfc.xref.header.location.2" title="Location">Section 10.4</a>).
</p>
- <p id="rfc.section.6.5.p.5">Responses to this method are not cacheable, unless the response includes appropriate Cache-Control or Expires header fields.
+ <p id="rfc.section.8.5.p.5">Responses to this method are not cacheable, unless the response includes appropriate Cache-Control or Expires header fields.
However, the 303 (See Other) response can be used to direct the user agent to retrieve a cacheable resource.
</p>
- <p id="rfc.section.6.5.p.6">POST requests <em class="bcp14">MUST</em> obey the message transmission requirements set out in [message.transmission.requirements].
+ <p id="rfc.section.8.5.p.6">POST requests <em class="bcp14">MUST</em> obey the message transmission requirements set out in [message.transmission.requirements].
</p>
- <p id="rfc.section.6.5.p.7">See <a href="#encoding.sensitive.information.in.uris" title="Encoding Sensitive Information in URI's">Section 9.2</a> for security considerations.
+ <p id="rfc.section.8.5.p.7">See <a href="#encoding.sensitive.information.in.uris" title="Encoding Sensitive Information in URI's">Section 11.2</a> for security considerations.
</p>
<div id="rfc.iref.p.2"></div>
<div id="rfc.iref.m.5"></div>
- <h2 id="rfc.section.6.6"><a href="#rfc.section.6.6">6.6</a> <a id="PUT" href="#PUT">PUT</a></h2>
- <p id="rfc.section.6.6.p.1">The PUT method requests that the enclosed entity be stored under the supplied Request-URI. If the Request-URI refers to an
+ <h2 id="rfc.section.8.6"><a href="#rfc.section.8.6">8.6</a> <a id="PUT" href="#PUT">PUT</a></h2>
+ <p id="rfc.section.8.6.p.1">The PUT method requests that the enclosed entity be stored under the supplied Request-URI. If the Request-URI refers to an
already existing resource, the enclosed entity <em class="bcp14">SHOULD</em> be considered as a modified version of the one residing on the origin server. If the Request-URI does not point to an existing
resource, and that URI is capable of being defined as a new resource by the requesting user agent, the origin server can create
the resource with that URI. If a new resource is created, the origin server <em class="bcp14">MUST</em> inform the user agent via the 201 (Created) response. If an existing resource is modified, either the 200 (OK) or 204 (No
Content) response codes <em class="bcp14">SHOULD</em> be sent to indicate successful completion of the request. If the resource could not be created or modified with the Request-URI,
an appropriate error response <em class="bcp14">SHOULD</em> be given that reflects the nature of the problem. The recipient of the entity <em class="bcp14">MUST NOT</em> ignore any Content-* (e.g. Content-Range) headers that it does not understand or implement and <em class="bcp14">MUST</em> return a 501 (Not Implemented) response in such cases.
</p>
- <p id="rfc.section.6.6.p.2">If the request passes through a cache and the Request-URI identifies one or more currently cached entities, those entries <em class="bcp14">SHOULD</em> be treated as stale. Responses to this method are not cacheable.
+ <p id="rfc.section.8.6.p.2">If the request passes through a cache and the Request-URI identifies one or more currently cached entities, those entries <em class="bcp14">SHOULD</em> be treated as stale. Responses to this method are not cacheable.
</p>
- <p id="rfc.section.6.6.p.3">The fundamental difference between the POST and PUT requests is reflected in the different meaning of the Request-URI. The
+ <p id="rfc.section.8.6.p.3">The fundamental difference between the POST and PUT requests is reflected in the different meaning of the Request-URI. The
URI in a POST request identifies the resource that will handle the enclosed entity. That resource might be a data-accepting
process, a gateway to some other protocol, or a separate entity that accepts annotations. In contrast, the URI in a PUT request
identifies the entity enclosed with the request -- the user agent knows what URI is intended and the server <em class="bcp14">MUST NOT</em> attempt to apply the request to some other resource. If the server desires that the request be applied to a different URI,
it <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.
</p>
- <p id="rfc.section.6.6.p.4">A single resource <em class="bcp14">MAY</em> be identified by many different URIs. For example, an article might have a URI for identifying "the current version" which
+ <p id="rfc.section.8.6.p.4">A single resource <em class="bcp14">MAY</em> be identified by many different URIs. For example, an article might have a URI for identifying "the current version" which
is separate from the URI identifying each particular version. In this case, a PUT request on a general URI might result in
several other URIs being defined by the origin server.
</p>
- <p id="rfc.section.6.6.p.5">HTTP/1.1 does not define how a PUT method affects the state of an origin server.</p>
- <p id="rfc.section.6.6.p.6">PUT requests <em class="bcp14">MUST</em> obey the message transmission requirements set out in [message.transmission.requirements].
+ <p id="rfc.section.8.6.p.5">HTTP/1.1 does not define how a PUT method affects the state of an origin server.</p>
+ <p id="rfc.section.8.6.p.6">PUT requests <em class="bcp14">MUST</em> obey the message transmission requirements set out in [message.transmission.requirements].
</p>
- <p id="rfc.section.6.6.p.7">Unless otherwise specified for a particular entity-header, the entity-headers in the PUT request <em class="bcp14">SHOULD</em> be applied to the resource created or modified by the PUT.
+ <p id="rfc.section.8.6.p.7">Unless otherwise specified for a particular entity-header, the entity-headers in the PUT request <em class="bcp14">SHOULD</em> be applied to the resource created or modified by the PUT.
</p>
<div id="rfc.iref.d.1"></div>
<div id="rfc.iref.m.6"></div>
- <h2 id="rfc.section.6.7"><a href="#rfc.section.6.7">6.7</a> <a id="DELETE" href="#DELETE">DELETE</a></h2>
- <p id="rfc.section.6.7.p.1">The DELETE method requests that the origin server delete the resource identified by the Request-URI. 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
+ <h2 id="rfc.section.8.7"><a href="#rfc.section.8.7">8.7</a> <a id="DELETE" href="#DELETE">DELETE</a></h2>
+ <p id="rfc.section.8.7.p.1">The DELETE method requests that the origin server delete the resource identified by the Request-URI. 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
has been carried out, even if the status code returned from the origin server indicates that the action has been completed
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
location.
</p>
- <p id="rfc.section.6.7.p.2">A successful response <em class="bcp14">SHOULD</em> be 200 (OK) if the response includes an entity describing the status, 202 (Accepted) if the action has not yet been enacted,
+ <p id="rfc.section.8.7.p.2">A successful response <em class="bcp14">SHOULD</em> be 200 (OK) if the response includes an entity describing the status, 202 (Accepted) if the action has not yet been enacted,
or 204 (No Content) if the action has been enacted but the response does not include an entity.
</p>
- <p id="rfc.section.6.7.p.3">If the request passes through a cache and the Request-URI identifies one or more currently cached entities, those entries <em class="bcp14">SHOULD</em> be treated as stale. Responses to this method are not cacheable.
+ <p id="rfc.section.8.7.p.3">If the request passes through a cache and the Request-URI identifies one or more currently cached entities, those entries <em class="bcp14">SHOULD</em> be treated as stale. Responses to this method are not cacheable.
</p>
<div id="rfc.iref.t.1"></div>
<div id="rfc.iref.m.7"></div>
- <h2 id="rfc.section.6.8"><a href="#rfc.section.6.8">6.8</a> <a id="TRACE" href="#TRACE">TRACE</a></h2>
- <p id="rfc.section.6.8.p.1">The TRACE method is used to invoke a remote, application-layer loop-back of the request message. The final recipient of the
+ <h2 id="rfc.section.8.8"><a href="#rfc.section.8.8">8.8</a> <a id="TRACE" href="#TRACE">TRACE</a></h2>
+ <p id="rfc.section.8.8.p.1">The TRACE method is used to invoke 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 entity-body of a 200 (OK) response. The final recipient is either the
- origin server or the first proxy or gateway to receive a Max-Forwards value of zero (0) in the request (see <a href="#header.max-forwards" id="rfc.xref.header.max-forwards.2" title="Max-Forwards">Section 8.6</a>). A TRACE request <em class="bcp14">MUST NOT</em> include an entity.
+ origin server or the first proxy or gateway to receive a Max-Forwards value of zero (0) in the request (see <a href="#header.max-forwards" id="rfc.xref.header.max-forwards.2" title="Max-Forwards">Section 10.5</a>). A TRACE request <em class="bcp14">MUST NOT</em> include an entity.
</p>
- <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
+ <p id="rfc.section.8.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
[... 1376 lines stripped ...]
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@labs.apache.org
For additional commands, e-mail: commits-help@labs.apache.org