![(please configure the [header_logo] section in trac.ini)](https://www.ietf.org/images/ietflogotrans.gif)
Changeset 1164 for draft-ietf-httpbis/latest/p2-semantics.html
- Timestamp:
- Mar 10, 2011, 10:45:43 PM (9 years ago)
- File:
-
- 1 edited
-
draft-ietf-httpbis/latest/p2-semantics.html (modified) (22 diffs)
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p2-semantics.html
r1162 r1164 411 411 <meta name="dct.issued" scheme="ISO8601" content="2011-03-10"> 412 412 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 413 <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 2 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 2 defines the semantics of HTTP messages as expressed by request methods, request -header fields, response status codes, and response-header fields.">414 <meta name="description" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 2 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 2 defines the semantics of HTTP messages as expressed by request methods, request -header fields, response status codes, and response-header fields.">413 <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 2 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 2 defines the semantics of HTTP messages as expressed by request methods, request header fields, response status codes, and response header fields."> 414 <meta name="description" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 2 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 2 defines the semantics of HTTP messages as expressed by request methods, request header fields, response status codes, and response header fields."> 415 415 </head> 416 416 <body> … … 502 502 systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 2 of the 503 503 seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 504 2 defines the semantics of HTTP messages as expressed by request methods, request -header fields, response status codes, and505 response -header fields.504 2 defines the semantics of HTTP messages as expressed by request methods, request header fields, response status codes, and 505 response header fields. 506 506 </p> 507 507 <h1 id="rfc.note.1"><a href="#rfc.note.1">Editorial Note (To be removed by RFC Editor)</a></h1> … … 709 709 <p id="rfc.section.1.p.2">This document is currently disorganized in order to minimize the changes between drafts and enable reviewers to see the smaller 710 710 errata changes. A future draft will reorganize the sections to better reflect the content. In particular, the sections will 711 be ordered according to the typical processing of an HTTP request message (after message parsing): resource mapping, general712 header fields, methods, request modifiers, response status, and resource metadata. The current mess reflects how widely dispersed713 these topics and associated requirements had become in <a href="#RFC2616" id="rfc.xref.RFC2616.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>.711 be ordered according to the typical processing of an HTTP request message (after message parsing): resource mapping, methods, 712 request modifying header fields, response status, status modifying header fields, and resource metadata. The current mess 713 reflects how widely dispersed these topics and associated requirements had become in <a href="#RFC2616" id="rfc.xref.RFC2616.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>. 714 714 </p> 715 715 <h2 id="rfc.section.1.1"><a href="#rfc.section.1.1">1.1</a> <a id="intro.requirements" href="#intro.requirements">Requirements</a></h2> … … 861 861 </p> 862 862 <h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a> <a id="request.header.fields" href="#request.header.fields">Request Header Fields</a></h1> 863 <p id="rfc.section.3.p.1">The request -header fields allow the client to pass additional information about the request, and about the client itself,863 <p id="rfc.section.3.p.1">The request header fields allow the client to pass additional information about the request, and about the client itself, 864 864 to the server. These fields act as request modifiers, with semantics equivalent to the parameters on a programming language 865 865 method invocation. … … 953 953 </table> 954 954 </div> 955 <p id="rfc.section.3.p.2">Request-header field names can be extended reliably only in combination with a change in the protocol version. However, new956 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.957 </p>958 955 <h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a> <a id="status.code.and.reason.phrase" href="#status.code.and.reason.phrase">Status Code and Reason Phrase</a></h1> 959 956 <p id="rfc.section.4.p.1">The Status-Code element is a 3-digit integer result code of the attempt to understand and satisfy the request.</p> … … 1216 1213 </p> 1217 1214 <h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a> <a id="response.header.fields" href="#response.header.fields">Response Header Fields</a></h1> 1218 <p id="rfc.section.5.p.1">The response -header fields allow the server to pass additional information about the response which cannot be placed in the1215 <p id="rfc.section.5.p.1">The response header fields allow the server to pass additional information about the response which cannot be placed in the 1219 1216 Status-Line. These header fields give information about the server and about further access to the target resource (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.21"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). 1220 1217 </p> … … 1223 1220 <thead> 1224 1221 <tr> 1225 <th> Method Name</th>1222 <th>Header Field Name</th> 1226 1223 <th>Defined in...</th> 1227 1224 </tr> … … 1271 1268 </table> 1272 1269 </div> 1273 <p id="rfc.section.5.p.2">Response-header field names can be extended reliably only in combination with a change in the protocol version. However, new1274 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-header1275 fields.1276 </p>1277 1270 <h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a> <a id="representation" href="#representation">Representation</a></h1> 1278 1271 <p id="rfc.section.6.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 … … 1356 1349 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". 1357 1350 </p> 1358 <p id="rfc.section.7.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 (see <a href="#header.max-forwards" id="rfc.xref.header.max-forwards.2" title="Max-Forwards">Section 9.5</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.1351 <p id="rfc.section.7.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.5</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. 1359 1352 </p> 1360 1353 <h2 id="rfc.section.7.3"><a href="#rfc.section.7.3">7.3</a> <a id="GET" href="#GET">GET</a></h2> … … 1869 1862 <div id="rfc.iref.s.31"></div> 1870 1863 <h3 id="rfc.section.8.4.13"><a href="#rfc.section.8.4.13">8.4.13</a> <a id="status.412" href="#status.412">412 Precondition Failed</a></h3> 1871 <p id="rfc.section.8.4.13.p.1">The precondition given in one or more of the request-header fields evaluated to false when it was tested on the server, as1872 definedin <a href="p4-conditional.html#status.412" title="412 Precondition Failed">Section 3.2</a> of <a href="#Part4" id="rfc.xref.Part4.16"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>.1864 <p id="rfc.section.8.4.13.p.1">The precondition given in one or more of the header fields evaluated to false when it was tested on the server, as defined 1865 in <a href="p4-conditional.html#status.412" title="412 Precondition Failed">Section 3.2</a> of <a href="#Part4" id="rfc.xref.Part4.16"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>. 1873 1866 </p> 1874 1867 <div id="rfc.iref.52"></div> … … 1898 1891 <div id="rfc.iref.s.35"></div> 1899 1892 <h3 id="rfc.section.8.4.17"><a href="#rfc.section.8.4.17">8.4.17</a> <a id="status.416" href="#status.416">416 Requested Range Not Satisfiable</a></h3> 1900 <p id="rfc.section.8.4.17.p.1">The request included a Range request-header field (<a href="p5-range.html#header.range" title="Range">Section 5.4</a> of <a href="#Part5" id="rfc.xref.Part5.12"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>) and none of the range-specifier values in this field overlap the current extent of the selected resource. See <a href="p5-range.html#status.416" title="416 Requested Range Not Satisfiable">Section 3.2</a> of <a href="#Part5" id="rfc.xref.Part5.13"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>.1893 <p id="rfc.section.8.4.17.p.1">The request included a Range header field (<a href="p5-range.html#header.range" title="Range">Section 5.4</a> of <a href="#Part5" id="rfc.xref.Part5.12"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>) and none of the range-specifier values in this field overlap the current extent of the selected resource. See <a href="p5-range.html#status.416" title="416 Requested Range Not Satisfiable">Section 3.2</a> of <a href="#Part5" id="rfc.xref.Part5.13"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>. 1901 1894 </p> 1902 1895 <div id="rfc.iref.56"></div> 1903 1896 <div id="rfc.iref.s.36"></div> 1904 1897 <h3 id="rfc.section.8.4.18"><a href="#rfc.section.8.4.18">8.4.18</a> <a id="status.417" href="#status.417">417 Expectation Failed</a></h3> 1905 <p id="rfc.section.8.4.18.p.1">The expectation given in an Expect request-header field (see <a href="#header.expect" id="rfc.xref.header.expect.2" title="Expect">Section 9.2</a>) could not be met by this server, or, if the server is a proxy, the server has unambiguous evidence that the request could1898 <p id="rfc.section.8.4.18.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.2</a>) could not be met by this server, or, if the server is a proxy, the server has unambiguous evidence that the request could 1906 1899 not be met by the next-hop server. 1907 1900 </p> … … 1973 1966 <div id="rfc.iref.h.2"></div> 1974 1967 <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> 1975 <p id="rfc.section.9.1.p.1">The "Allow" response-header field lists the set of methods advertised as supported by the target resource. The purpose of1976 this fieldis strictly to inform the recipient of valid request methods associated with the resource.1968 <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 field 1969 is strictly to inform the recipient of valid request methods associated with the resource. 1977 1970 </p> 1978 1971 <div id="rfc.figure.u.13"></div><pre class="inline"><span id="rfc.iref.g.6"></span><span id="rfc.iref.g.7"></span> <a href="#header.allow" class="smpl">Allow</a> = "Allow" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.allow" class="smpl">Allow-v</a> … … 1987 1980 <div id="rfc.iref.h.3"></div> 1988 1981 <h2 id="rfc.section.9.2"><a href="#rfc.section.9.2">9.2</a> <a id="header.expect" href="#header.expect">Expect</a></h2> 1989 <p id="rfc.section.9.2.p.1">The "Expect" request-header field is used to indicate that particular server behaviors are required by the client.</p>1982 <p id="rfc.section.9.2.p.1">The "Expect" header field is used to indicate that particular server behaviors are required by the client.</p> 1990 1983 <div id="rfc.figure.u.15"></div><pre class="inline"><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> <a href="#header.expect" class="smpl">Expect</a> = "Expect" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.expect" class="smpl">Expect-v</a> 1991 1984 <a href="#header.expect" class="smpl">Expect-v</a> = 1#<a href="#header.expect" class="smpl">expectation</a> … … 2005 1998 </p> 2006 1999 <p id="rfc.section.9.2.p.6">The Expect mechanism is hop-by-hop: that is, an HTTP/1.1 proxy <em class="bcp14">MUST</em> return a 417 (Expectation Failed) status code if it receives a request with an expectation that it cannot meet. However, the 2007 Expect request-header field itself is end-to-end; it <em class="bcp14">MUST</em> be forwarded if the request is forwarded.2000 Expect header field itself is end-to-end; it <em class="bcp14">MUST</em> be forwarded if the request is forwarded. 2008 2001 </p> 2009 2002 <p id="rfc.section.9.2.p.7">Many older HTTP/1.0 and HTTP/1.1 applications do not understand the Expect header field.</p> … … 2013 2006 <div id="rfc.iref.h.4"></div> 2014 2007 <h2 id="rfc.section.9.3"><a href="#rfc.section.9.3">9.3</a> <a id="header.from" href="#header.from">From</a></h2> 2015 <p id="rfc.section.9.3.p.1">The "From" request-header field, if given, <em class="bcp14">SHOULD</em> contain an Internet e-mail address for the human user who controls the requesting user agent. The address <em class="bcp14">SHOULD</em> be machine-usable, as defined by "mailbox" in <a href="http://tools.ietf.org/html/rfc5322#section-3.4">Section 3.4</a> of <a href="#RFC5322" id="rfc.xref.RFC5322.1"><cite title="Internet Message Format">[RFC5322]</cite></a>:2008 <p id="rfc.section.9.3.p.1">The "From" header field, if given, <em class="bcp14">SHOULD</em> contain an Internet e-mail address for the human user who controls the requesting user agent. The address <em class="bcp14">SHOULD</em> be machine-usable, as defined by "mailbox" in <a href="http://tools.ietf.org/html/rfc5322#section-3.4">Section 3.4</a> of <a href="#RFC5322" id="rfc.xref.RFC5322.1"><cite title="Internet Message Format">[RFC5322]</cite></a>: 2016 2009 </p> 2017 2010 <div id="rfc.figure.u.16"></div><pre class="inline"><span id="rfc.iref.g.13"></span><span id="rfc.iref.g.14"></span> <a href="#header.from" class="smpl">From</a> = "From" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.from" class="smpl">From-v</a> … … 2035 2028 <div id="rfc.iref.h.5"></div> 2036 2029 <h2 id="rfc.section.9.4"><a href="#rfc.section.9.4">9.4</a> <a id="header.location" href="#header.location">Location</a></h2> 2037 <p id="rfc.section.9.4.p.1">The "Location" response-header field is used to identify a newly created resource, or to redirect the recipient to a different2038 locationfor completion of the request.2030 <p id="rfc.section.9.4.p.1">The "Location" header field is used to identify a newly created resource, or to redirect the recipient to a different location 2031 for completion of the request. 2039 2032 </p> 2040 2033 <p id="rfc.section.9.4.p.2">For 201 (Created) responses, the Location is the URI of the new resource which was created by the request. For 3xx responses, … … 2067 2060 <div id="rfc.iref.h.6"></div> 2068 2061 <h2 id="rfc.section.9.5"><a href="#rfc.section.9.5">9.5</a> <a id="header.max-forwards" href="#header.max-forwards">Max-Forwards</a></h2> 2069 <p id="rfc.section.9.5.p.1">The "Max-Forwards" request-header field provides a mechanism with the TRACE (<a href="#TRACE" id="rfc.xref.TRACE.2" title="TRACE">Section 7.8</a>) and OPTIONS (<a href="#OPTIONS" id="rfc.xref.OPTIONS.2" title="OPTIONS">Section 7.2</a>) methods to limit the number of times that the request is forwarded by proxies or gateways. This can be useful when the client2062 <p id="rfc.section.9.5.p.1">The "Max-Forwards" header field provides a mechanism with the TRACE (<a href="#TRACE" id="rfc.xref.TRACE.2" title="TRACE">Section 7.8</a>) and OPTIONS (<a href="#OPTIONS" id="rfc.xref.OPTIONS.2" title="OPTIONS">Section 7.2</a>) methods to limit the number of times that the request is forwarded by proxies or gateways. This can be useful when the client 2070 2063 is attempting to trace a request which appears to be failing or looping in mid-chain. 2071 2064 </p> … … 2080 2073 <div id="rfc.iref.h.7"></div> 2081 2074 <h2 id="rfc.section.9.6"><a href="#rfc.section.9.6">9.6</a> <a id="header.referer" href="#header.referer">Referer</a></h2> 2082 <p id="rfc.section.9.6.p.1">The "Referer" [sic] request-header field allows the client to specify the URI of the resource from which the effective request2083 URIwas obtained (the "referrer", although the header field is misspelled.).2075 <p id="rfc.section.9.6.p.1">The "Referer" [sic] header field allows the client to specify the URI of the resource from which the effective request URI 2076 was obtained (the "referrer", although the header field is misspelled.). 2084 2077 </p> 2085 2078 <p id="rfc.section.9.6.p.2">The Referer header field allows servers to generate lists of back-links to resources for interest, logging, optimized caching, … … 2100 2093 <div id="rfc.iref.h.8"></div> 2101 2094 <h2 id="rfc.section.9.7"><a href="#rfc.section.9.7">9.7</a> <a id="header.retry-after" href="#header.retry-after">Retry-After</a></h2> 2102 <p id="rfc.section.9.7.p.1">The response-header "Retry-After" field can be used with a 503 (Service Unavailable) response to indicate how long the service2103 is expectedto 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 wait before issuing2095 <p id="rfc.section.9.7.p.1">The header "Retry-After" field can be used with a 503 (Service Unavailable) response to indicate how long the service is expected 2096 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 wait before issuing 2104 2097 the redirected request. 2105 2098 </p> … … 2118 2111 <div id="rfc.iref.h.9"></div> 2119 2112 <h2 id="rfc.section.9.8"><a href="#rfc.section.9.8">9.8</a> <a id="header.server" href="#header.server">Server</a></h2> 2120 <p id="rfc.section.9.8.p.1">The "Server" response-header field contains information about the software used by the origin server to handle the request.</p>2113 <p id="rfc.section.9.8.p.1">The "Server" header field contains information about the software used by the origin server to handle the request.</p> 2121 2114 <p id="rfc.section.9.8.p.2">The field can contain multiple product tokens (<a href="p1-messaging.html#product.tokens" title="Product Tokens">Section 6.3</a> of <a href="#Part1" id="rfc.xref.Part1.33"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) and comments (<a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.34"><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 2122 2115 identifying the application. … … 2127 2120 </pre><p id="rfc.section.9.8.p.4">Example:</p> 2128 2121 <div id="rfc.figure.u.28"></div><pre class="text"> Server: CERN/3.0 libwww/2.17 2129 </pre><p id="rfc.section.9.8.p.6">If the response is being forwarded through a proxy, the proxy application <em class="bcp14">MUST NOT</em> modify the Server response-header field. Instead, it <em class="bcp14">MUST</em> include a Via field (as described in <a href="p1-messaging.html#header.via" title="Via">Section 9.9</a> of <a href="#Part1" id="rfc.xref.Part1.35"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).2122 </pre><p id="rfc.section.9.8.p.6">If the response is being forwarded through a proxy, the proxy application <em class="bcp14">MUST NOT</em> modify the Server header field. Instead, it <em class="bcp14">MUST</em> include a Via field (as described in <a href="p1-messaging.html#header.via" title="Via">Section 9.9</a> of <a href="#Part1" id="rfc.xref.Part1.35"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). 2130 2123 </p> 2131 2124 <div class="note" id="rfc.section.9.8.p.7"> … … 2138 2131 <div id="rfc.iref.h.10"></div> 2139 2132 <h2 id="rfc.section.9.9"><a href="#rfc.section.9.9">9.9</a> <a id="header.user-agent" href="#header.user-agent">User-Agent</a></h2> 2140 <p id="rfc.section.9.9.p.1">The "User-Agent" request-header field contains information about the user agent originating the request. User agents <em class="bcp14">SHOULD</em> include this field with requests.2133 <p id="rfc.section.9.9.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. 2141 2134 </p> 2142 2135 <p id="rfc.section.9.9.p.2">Typically, it is used for statistical purposes, the tracing of protocol violations, and tailoring responses to avoid particular
Note: See TracChangeset
for help on using the changeset viewer.
