Changeset 1164 for draft-ietf-httpbis
- Timestamp:
- 11/03/11 06:45:43 (11 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 7 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.html
r1162 r1164 546 546 <li>1.2.1 <a href="#notation.abnf">ABNF Extension: #rule</a></li> 547 547 <li>1.2.2 <a href="#basic.rules">Basic Rules</a></li> 548 <li>1.2.3 <a href="#abnf.dependencies">ABNF Rules defined in other Parts of the Specification</a></li>549 548 </ul> 550 549 </li> … … 863 862 </pre><p id="rfc.section.1.2.2.p.14">Producers <em class="bcp14">SHOULD NOT</em> escape characters that do not require escaping (i.e., other than DQUOTE and the backslash character). 864 863 </p> 865 <h3 id="rfc.section.1.2.3"><a href="#rfc.section.1.2.3">1.2.3</a> <a id="abnf.dependencies" href="#abnf.dependencies">ABNF Rules defined in other Parts of the Specification</a></h3> 866 <p id="rfc.section.1.2.3.p.1">The ABNF rules below are defined in other parts:</p> 867 <div id="rfc.figure.u.12"></div><pre class="inline"> <a href="#abnf.dependencies" class="smpl">request-header</a> = <request-header, defined in <a href="#Part2" id="rfc.xref.Part2.1"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>, <a href="p2-semantics.html#request.header.fields" title="Request Header Fields">Section 3</a>> 868 <a href="#abnf.dependencies" class="smpl">response-header</a> = <response-header, defined in <a href="#Part2" id="rfc.xref.Part2.2"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>, <a href="p2-semantics.html#response.header.fields" title="Response Header Fields">Section 5</a>> 869 </pre><div id="rfc.figure.u.13"></div><pre class="inline"> <a href="#abnf.dependencies" class="smpl">MIME-Version</a> = <MIME-Version, defined in <a href="#Part3" id="rfc.xref.Part3.2"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#mime-version" title="MIME-Version">Appendix A.1</a>> 870 </pre><div id="rfc.figure.u.14"></div><pre class="inline"> <a href="#abnf.dependencies" class="smpl">Cache-Control</a> = <Cache-Control, defined in <a href="#Part6" id="rfc.xref.Part6.1"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>, <a href="p6-cache.html#header.pragma" title="Pragma">Section 3.4</a>> 871 <a href="#abnf.dependencies" class="smpl">Pragma</a> = <Pragma, defined in <a href="#Part6" id="rfc.xref.Part6.2"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>, <a href="p6-cache.html#header.pragma" title="Pragma">Section 3.4</a>> 872 <a href="#abnf.dependencies" class="smpl">Warning</a> = <Warning, defined in <a href="#Part6" id="rfc.xref.Part6.3"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>, <a href="p6-cache.html#header.warning" title="Warning">Section 3.6</a>> 873 </pre><h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a> <a id="architecture" href="#architecture">HTTP-related architecture</a></h1> 864 <h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a> <a id="architecture" href="#architecture">HTTP-related architecture</a></h1> 874 865 <p id="rfc.section.2.p.1">HTTP was created for the World Wide Web architecture and has evolved over time to support the scalability needs of a worldwide 875 866 hypertext system. Much of that architecture is reflected in the terminology and syntax productions used to define HTTP. … … 898 889 the origin server (O). 899 890 </p> 900 <div id="rfc.figure.u.1 5"></div><pre class="drawing"> request >891 <div id="rfc.figure.u.12"></div><pre class="drawing"> request > 901 892 UA ======================================= O 902 893 < response … … 913 904 </p> 914 905 <p id="rfc.section.2.1.p.7">The following example illustrates a typical message exchange for a GET request on the URI "http://www.example.com/hello.txt":</p> 915 <div id="rfc.figure.u.1 6"></div>906 <div id="rfc.figure.u.13"></div> 916 907 <p>client request:</p><pre class="text2">GET /hello.txt HTTP/1.1 917 908 User-Agent: curl/7.16.3 libcurl/7.16.3 OpenSSL/0.9.7l zlib/1.2.3 … … 919 910 Accept: */* 920 911 921 </pre><div id="rfc.figure.u.1 7"></div>912 </pre><div id="rfc.figure.u.14"></div> 922 913 <p>server response:</p><pre class="text">HTTP/1.1 200 OK 923 914 Date: Mon, 27 Jul 2009 12:28:53 GMT … … 948 939 gateway, or tunnel, switching behavior based on the nature of each request. 949 940 </p> 950 <div id="rfc.figure.u.1 8"></div><pre class="drawing"> > > > >941 <div id="rfc.figure.u.15"></div><pre class="drawing"> > > > > 951 942 UA =========== A =========== B =========== C =========== O 952 943 < < < < … … 1007 998 from O (via C) for a request which has not been cached by UA or A. 1008 999 </p> 1009 <div id="rfc.figure.u.1 9"></div><pre class="drawing"> > >1000 <div id="rfc.figure.u.16"></div><pre class="drawing"> > > 1010 1001 UA =========== A =========== B - - - - - - C - - - - - - O 1011 1002 < < … … 1013 1004 Even when a response is cacheable, there might be additional constraints placed by the client or by the origin server on when 1014 1005 that cached response can be used for a particular request. HTTP requirements for cache behavior and cacheable responses are 1015 defined in <a href="p6-cache.html#caching.overview" title="Cache Operation">Section 2</a> of <a href="#Part6" id="rfc.xref.Part6. 4"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>.1006 defined in <a href="p6-cache.html#caching.overview" title="Cache Operation">Section 2</a> of <a href="#Part6" id="rfc.xref.Part6.1"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>. 1016 1007 </p> 1017 1008 <p id="rfc.section.2.4.p.5">There are a wide variety of architectures and configurations of caches and proxies deployed across the World Wide Web and … … 1026 1017 </p> 1027 1018 <p id="rfc.section.2.5.p.2">The version of an HTTP message is indicated by an HTTP-Version field in the first line of the message. HTTP-Version is case-sensitive.</p> 1028 <div id="rfc.figure.u. 20"></div><pre class="inline"><span id="rfc.iref.g.25"></span><span id="rfc.iref.g.26"></span> <a href="#http.version" class="smpl">HTTP-Version</a> = <a href="#http.version" class="smpl">HTTP-Prot-Name</a> "/" 1*<a href="#core.rules" class="smpl">DIGIT</a> "." 1*<a href="#core.rules" class="smpl">DIGIT</a>1019 <div id="rfc.figure.u.17"></div><pre class="inline"><span id="rfc.iref.g.25"></span><span id="rfc.iref.g.26"></span> <a href="#http.version" class="smpl">HTTP-Version</a> = <a href="#http.version" class="smpl">HTTP-Prot-Name</a> "/" 1*<a href="#core.rules" class="smpl">DIGIT</a> "." 1*<a href="#core.rules" class="smpl">DIGIT</a> 1029 1020 <a href="#http.version" class="smpl">HTTP-Prot-Name</a> = %x48.54.54.50 ; "HTTP", case-sensitive 1030 1021 </pre><p id="rfc.section.2.5.p.4">The HTTP version number consists of two non-negative decimal integers separated by the "." (period or decimal point) character. … … 1089 1080 "path-absolute", "query", and "authority" from <a href="#RFC3986" id="rfc.xref.RFC3986.4"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>. In addition, we define a partial-URI rule for protocol elements that allow a relative URI without a fragment. 1090 1081 </p> 1091 <div id="rfc.figure.u. 21"></div><pre class="inline"><span id="rfc.iref.g.27"></span><span id="rfc.iref.g.28"></span><span id="rfc.iref.g.29"></span><span id="rfc.iref.g.30"></span><span id="rfc.iref.g.31"></span><span id="rfc.iref.g.32"></span><span id="rfc.iref.g.33"></span> <a href="#uri" class="smpl">URI-reference</a> = <URI-reference, defined in <a href="#RFC3986" id="rfc.xref.RFC3986.5"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-4.1">Section 4.1</a>>1082 <div id="rfc.figure.u.18"></div><pre class="inline"><span id="rfc.iref.g.27"></span><span id="rfc.iref.g.28"></span><span id="rfc.iref.g.29"></span><span id="rfc.iref.g.30"></span><span id="rfc.iref.g.31"></span><span id="rfc.iref.g.32"></span><span id="rfc.iref.g.33"></span> <a href="#uri" class="smpl">URI-reference</a> = <URI-reference, defined in <a href="#RFC3986" id="rfc.xref.RFC3986.5"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-4.1">Section 4.1</a>> 1092 1083 <a href="#uri" class="smpl">absolute-URI</a> = <absolute-URI, defined in <a href="#RFC3986" id="rfc.xref.RFC3986.6"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-4.3">Section 4.3</a>> 1093 1084 <a href="#uri" class="smpl">relative-part</a> = <relative-part, defined in <a href="#RFC3986" id="rfc.xref.RFC3986.7"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-4.2">Section 4.2</a>> … … 1113 1104 data corresponding to a resource for which that server might provide an HTTP interface. 1114 1105 </p> 1115 <div id="rfc.figure.u. 22"></div><pre class="inline"><span id="rfc.iref.g.34"></span> <a href="#http.uri" class="smpl">http-URI</a> = "http:" "//" <a href="#uri" class="smpl">authority</a> <a href="#uri" class="smpl">path-abempty</a> [ "?" <a href="#uri" class="smpl">query</a> ]1106 <div id="rfc.figure.u.19"></div><pre class="inline"><span id="rfc.iref.g.34"></span> <a href="#http.uri" class="smpl">http-URI</a> = "http:" "//" <a href="#uri" class="smpl">authority</a> <a href="#uri" class="smpl">path-abempty</a> [ "?" <a href="#uri" class="smpl">query</a> ] 1116 1107 </pre><p id="rfc.section.2.6.1.p.3">The host identifier within an <a href="#uri" class="smpl">authority</a> component is defined in <a href="#RFC3986" id="rfc.xref.RFC3986.14"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-3.2.2">Section 3.2.2</a>. If host is provided as an IP literal or IPv4 address, then the HTTP server is any listener on the indicated TCP port at 1117 1108 that IP address. If host is a registered name, then that name is considered an indirect identifier and the recipient might … … 1149 1140 TCP port of 443 is assumed if the port subcomponent is empty or not given, and the TCP connection <em class="bcp14">MUST</em> be secured for privacy through the use of strong encryption prior to sending the first HTTP request. 1150 1141 </p> 1151 <div id="rfc.figure.u.2 3"></div><pre class="inline"><span id="rfc.iref.g.35"></span> <a href="#https.uri" class="smpl">https-URI</a> = "https:" "//" <a href="#uri" class="smpl">authority</a> <a href="#uri" class="smpl">path-abempty</a> [ "?" <a href="#uri" class="smpl">query</a> ]1142 <div id="rfc.figure.u.20"></div><pre class="inline"><span id="rfc.iref.g.35"></span> <a href="#https.uri" class="smpl">https-URI</a> = "https:" "//" <a href="#uri" class="smpl">authority</a> <a href="#uri" class="smpl">path-abempty</a> [ "?" <a href="#uri" class="smpl">query</a> ] 1152 1143 </pre><p id="rfc.section.2.6.2.p.4">Unlike the "http" scheme, responses to "https" identified requests are never "public" and thus are ineligible for shared caching. 1153 Their default is "private" and might be further constrained via use of the Cache-Control header field .1144 Their default is "private" and might be further constrained via use of the Cache-Control header field (<a href="p6-cache.html#header.cache-control" title="Cache-Control">Section 3.2</a> of <a href="#Part6" id="rfc.xref.Part6.2"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>). 1154 1145 </p> 1155 1146 <p id="rfc.section.2.6.2.p.5">Resources made available via the "https" scheme have no shared identity with the "http" scheme even if their resource identifiers … … 1170 1161 </p> 1171 1162 <p id="rfc.section.2.6.3.p.3">For example, the following three URIs are equivalent:</p> 1172 <div id="rfc.figure.u.2 4"></div><pre class="text"> http://example.com:80/~smith/home.html1163 <div id="rfc.figure.u.21"></div><pre class="text"> http://example.com:80/~smith/home.html 1173 1164 http://EXAMPLE.com/%7Esmith/home.html 1174 1165 http://EXAMPLE.com:/%7esmith/home.html … … 1190 1181 or invalid request method) and clients are implemented to only expect a response. 1191 1182 </p> 1192 <div id="rfc.figure.u.2 5"></div><pre class="inline"><span id="rfc.iref.g.36"></span> <a href="#http.message" class="smpl">HTTP-message</a> = <a href="#http.message" class="smpl">start-line</a>1183 <div id="rfc.figure.u.22"></div><pre class="inline"><span id="rfc.iref.g.36"></span> <a href="#http.message" class="smpl">HTTP-message</a> = <a href="#http.message" class="smpl">start-line</a> 1193 1184 *( <a href="#header.fields" class="smpl">header-field</a> <a href="#core.rules" class="smpl">CRLF</a> ) 1194 1185 <a href="#core.rules" class="smpl">CRLF</a> … … 1221 1212 value. 1222 1213 </p> 1223 <div id="rfc.figure.u.2 6"></div><pre class="inline"><span id="rfc.iref.g.37"></span><span id="rfc.iref.g.38"></span><span id="rfc.iref.g.39"></span><span id="rfc.iref.g.40"></span> <a href="#header.fields" class="smpl">header-field</a> = <a href="#header.fields" class="smpl">field-name</a> ":" <a href="#rule.whitespace" class="smpl">OWS</a> [ <a href="#header.fields" class="smpl">field-value</a> ] <a href="#rule.whitespace" class="smpl">OWS</a>1214 <div id="rfc.figure.u.23"></div><pre class="inline"><span id="rfc.iref.g.37"></span><span id="rfc.iref.g.38"></span><span id="rfc.iref.g.39"></span><span id="rfc.iref.g.40"></span> <a href="#header.fields" class="smpl">header-field</a> = <a href="#header.fields" class="smpl">field-name</a> ":" <a href="#rule.whitespace" class="smpl">OWS</a> [ <a href="#header.fields" class="smpl">field-value</a> ] <a href="#rule.whitespace" class="smpl">OWS</a> 1224 1215 <a href="#header.fields" class="smpl">field-name</a> = <a href="#rule.token.separators" class="smpl">token</a> 1225 1216 <a href="#header.fields" class="smpl">field-value</a> = *( <a href="#header.fields" class="smpl">field-content</a> / <a href="#rule.whitespace" class="smpl">OWS</a> ) … … 1261 1252 </p> 1262 1253 </div> 1263 <div id="rfc.figure.u.2 7"></div><pre class="inline"><span id="rfc.iref.g.41"></span><span id="rfc.iref.g.42"></span> <a href="#rule.comment" class="smpl">comment</a> = "(" *( <a href="#rule.comment" class="smpl">ctext</a> / <a href="#rule.quoted-cpair" class="smpl">quoted-cpair</a> / <a href="#rule.comment" class="smpl">comment</a> ) ")"1254 <div id="rfc.figure.u.24"></div><pre class="inline"><span id="rfc.iref.g.41"></span><span id="rfc.iref.g.42"></span> <a href="#rule.comment" class="smpl">comment</a> = "(" *( <a href="#rule.comment" class="smpl">ctext</a> / <a href="#rule.quoted-cpair" class="smpl">quoted-cpair</a> / <a href="#rule.comment" class="smpl">comment</a> ) ")" 1264 1255 <a href="#rule.comment" class="smpl">ctext</a> = <a href="#rule.whitespace" class="smpl">OWS</a> / %x21-27 / %x2A-5B / %x5D-7E / <a href="#rule.quoted-string" class="smpl">obs-text</a> 1265 1256 ; <a href="#rule.whitespace" class="smpl">OWS</a> / <<a href="#core.rules" class="smpl">VCHAR</a> except "(", ")", and "\"> / <a href="#rule.quoted-string" class="smpl">obs-text</a> … … 1267 1258 <p id="rfc.section.3.2.p.12"> The backslash character ("\") can be used as a single-character quoting mechanism within comment constructs:</p> 1268 1259 </div> 1269 <div id="rfc.figure.u.2 8"></div><pre class="inline"><span id="rfc.iref.g.43"></span> <a href="#rule.quoted-cpair" class="smpl">quoted-cpair</a> = "\" ( <a href="#core.rules" class="smpl">WSP</a> / <a href="#core.rules" class="smpl">VCHAR</a> / <a href="#rule.quoted-string" class="smpl">obs-text</a> )1260 <div id="rfc.figure.u.25"></div><pre class="inline"><span id="rfc.iref.g.43"></span> <a href="#rule.quoted-cpair" class="smpl">quoted-cpair</a> = "\" ( <a href="#core.rules" class="smpl">WSP</a> / <a href="#core.rules" class="smpl">VCHAR</a> / <a href="#rule.quoted-string" class="smpl">obs-text</a> ) 1270 1261 </pre><p id="rfc.section.3.2.p.14">Producers <em class="bcp14">SHOULD NOT</em> escape characters that do not require escaping (i.e., other than the backslash character "\" and the parentheses "(" and ")"). 1271 1262 </p> 1272 1263 <h2 id="rfc.section.3.3"><a href="#rfc.section.3.3">3.3</a> <a id="message.body" href="#message.body">Message Body</a></h2> 1273 1264 <p id="rfc.section.3.3.p.1">The message-body (if any) of an HTTP message is used to carry the payload body associated with the request or response.</p> 1274 <div id="rfc.figure.u.2 9"></div><pre class="inline"><span id="rfc.iref.g.44"></span> <a href="#message.body" class="smpl">message-body</a> = *OCTET1265 <div id="rfc.figure.u.26"></div><pre class="inline"><span id="rfc.iref.g.44"></span> <a href="#message.body" class="smpl">message-body</a> = *OCTET 1275 1266 </pre><p id="rfc.section.3.3.p.3">The message-body differs from the payload body only when a transfer-coding has been applied, as indicated by the Transfer-Encoding 1276 1267 header field (<a href="#header.transfer-encoding" id="rfc.xref.header.transfer-encoding.1" title="Transfer-Encoding">Section 9.7</a>). If more than one Transfer-Encoding header field is present in a message, the multiple field-values <em class="bcp14">MUST</em> be combined into one field-value, according to the algorithm defined in <a href="#header.fields" title="Header Fields">Section 3.2</a>, before determining the message-body length. … … 1356 1347 <p id="rfc.section.3.3.p.15">Request messages that are prematurely terminated, possibly due to a cancelled connection or a server-imposed time-out exception, <em class="bcp14">MUST</em> result in closure of the connection; sending an HTTP/1.1 error response prior to closing the connection is <em class="bcp14">OPTIONAL</em>. Response messages that are prematurely terminated, usually by closure of the connection prior to receiving the expected 1357 1348 number of octets or by failure to decode a transfer-encoded message-body, <em class="bcp14">MUST</em> be recorded as incomplete. A user agent <em class="bcp14">MUST NOT</em> render an incomplete response message-body as if it were complete (i.e., some indication must be given to the user that an 1358 error occurred). Cache requirements for incomplete responses are defined in <a href="p6-cache.html#errors.or.incomplete.response.cache.behavior" title="Storing Partial and Incomplete Responses">Section 2.1.1</a> of <a href="#Part6" id="rfc.xref.Part6. 5"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>.1349 error occurred). Cache requirements for incomplete responses are defined in <a href="p6-cache.html#errors.or.incomplete.response.cache.behavior" title="Storing Partial and Incomplete Responses">Section 2.1.1</a> of <a href="#Part6" id="rfc.xref.Part6.3"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>. 1359 1350 </p> 1360 1351 <p id="rfc.section.3.3.p.16">A server <em class="bcp14">MUST</em> read the entire request message-body or close the connection after sending its response, since otherwise the remaining data … … 1384 1375 </tr> 1385 1376 <tr> 1386 <td class="left">Pragma</td>1387 <td class="left"><a href="p6-cache.html#header.pragma" title="Pragma">Section 3.4</a> of <a href="#Part6" id="rfc.xref.Part6.6"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a></td>1388 </tr>1389 <tr>1390 1377 <td class="left">Trailer</td> 1391 1378 <td class="left"><a href="#header.trailer" id="rfc.xref.header.trailer.1" title="Trailer">Section 9.6</a></td> … … 1403 1390 <td class="left"><a href="#header.via" id="rfc.xref.header.via.1" title="Via">Section 9.9</a></td> 1404 1391 </tr> 1405 <tr>1406 <td class="left">Warning</td>1407 <td class="left"><a href="p6-cache.html#header.warning" title="Warning">Section 3.6</a> of <a href="#Part6" id="rfc.xref.Part6.7"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a></td>1408 </tr>1409 <tr>1410 <td class="left">MIME-Version</td>1411 <td class="left"><a href="p3-payload.html#mime-version" title="MIME-Version">Appendix A.1</a> of <a href="#Part3" id="rfc.xref.Part3.3"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a></td>1412 </tr>1413 1392 </tbody> 1414 1393 </table> 1415 1394 </div> 1416 <p id="rfc.section.3.4.p.2">General-header field names can be extended reliably only in combination with a change in the protocol version. However, new1417 or experimental header fields might be given the semantics of general header fields if all parties in the communication recognize1418 them to be general-header fields.1419 </p>1420 1395 <h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a> <a id="request" href="#request">Request</a></h1> 1421 1396 <p id="rfc.section.4.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 1422 1397 resource, the identifier of the resource, and the protocol version in use. 1423 1398 </p> 1424 <div id="rfc.figure.u. 30"></div><pre class="inline"><span id="rfc.iref.g.45"></span> <a href="#request" class="smpl">Request</a> = <a href="#request-line" class="smpl">Request-Line</a> ; <a href="#request-line" title="Request-Line">Section 4.1</a>1399 <div id="rfc.figure.u.27"></div><pre class="inline"><span id="rfc.iref.g.45"></span> <a href="#request" class="smpl">Request</a> = <a href="#request-line" class="smpl">Request-Line</a> ; <a href="#request-line" title="Request-Line">Section 4.1</a> 1425 1400 *( <a href="#header.fields" class="smpl">header-field</a> <a href="#core.rules" class="smpl">CRLF</a> ) ; <a href="#header.fields" title="Header Fields">Section 3.2</a> 1426 1401 <a href="#core.rules" class="smpl">CRLF</a> … … 1430 1405 The elements are separated by SP characters. No CR or LF is allowed except in the final CRLF sequence. 1431 1406 </p> 1432 <div id="rfc.figure.u. 31"></div><pre class="inline"><span id="rfc.iref.g.46"></span> <a href="#request-line" class="smpl">Request-Line</a> = <a href="#method" class="smpl">Method</a> <a href="#core.rules" class="smpl">SP</a> <a href="#request-target" class="smpl">request-target</a> <a href="#core.rules" class="smpl">SP</a> <a href="#http.version" class="smpl">HTTP-Version</a> <a href="#core.rules" class="smpl">CRLF</a>1407 <div id="rfc.figure.u.28"></div><pre class="inline"><span id="rfc.iref.g.46"></span> <a href="#request-line" class="smpl">Request-Line</a> = <a href="#method" class="smpl">Method</a> <a href="#core.rules" class="smpl">SP</a> <a href="#request-target" class="smpl">request-target</a> <a href="#core.rules" class="smpl">SP</a> <a href="#http.version" class="smpl">HTTP-Version</a> <a href="#core.rules" class="smpl">CRLF</a> 1433 1408 </pre><h3 id="rfc.section.4.1.1"><a href="#rfc.section.4.1.1">4.1.1</a> <a id="method" href="#method">Method</a></h3> 1434 1409 <p id="rfc.section.4.1.1.p.1">The Method token indicates the request method to be performed on the target resource. The request method is case-sensitive.</p> 1435 <div id="rfc.figure.u. 32"></div><pre class="inline"><span id="rfc.iref.g.47"></span> <a href="#method" class="smpl">Method</a> = <a href="#rule.token.separators" class="smpl">token</a>1410 <div id="rfc.figure.u.29"></div><pre class="inline"><span id="rfc.iref.g.47"></span> <a href="#method" class="smpl">Method</a> = <a href="#rule.token.separators" class="smpl">token</a> 1436 1411 </pre><h3 id="rfc.section.4.1.2"><a href="#rfc.section.4.1.2">4.1.2</a> <a id="request-target" href="#request-target">request-target</a></h3> 1437 1412 <p id="rfc.section.4.1.2.p.1">The request-target identifies the target resource upon which to apply the request.</p> 1438 <div id="rfc.figure.u.3 3"></div><pre class="inline"><span id="rfc.iref.g.48"></span> <a href="#request-target" class="smpl">request-target</a> = "*"1413 <div id="rfc.figure.u.30"></div><pre class="inline"><span id="rfc.iref.g.48"></span> <a href="#request-target" class="smpl">request-target</a> = "*" 1439 1414 / <a href="#uri" class="smpl">absolute-URI</a> 1440 1415 / ( <a href="#uri" class="smpl">path-absolute</a> [ "?" <a href="#uri" class="smpl">query</a> ] ) … … 1444 1419 This is only allowed for the OPTIONS request method. Thus, the only valid example is 1445 1420 </p> 1446 <div id="rfc.figure.u.3 4"></div><pre class="text2">OPTIONS * HTTP/1.11421 <div id="rfc.figure.u.31"></div><pre class="text2">OPTIONS * HTTP/1.1 1447 1422 </pre><p id="rfc.section.4.1.2.p.6"><span id="rfc.iref.a.2"></span> The "absolute-URI" 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, 1448 1423 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 absolute-URI. In order to avoid request … … 1450 1425 Request-Line would be: 1451 1426 </p> 1452 <div id="rfc.figure.u.3 5"></div><pre class="text2">GET http://www.example.org/pub/WWW/TheProject.html HTTP/1.11427 <div id="rfc.figure.u.32"></div><pre class="text2">GET http://www.example.org/pub/WWW/TheProject.html HTTP/1.1 1453 1428 </pre><p id="rfc.section.4.1.2.p.8">To allow for transition to absolute-URIs in all requests in future versions of HTTP, all HTTP/1.1 servers <em class="bcp14">MUST</em> accept the absolute-URI form in requests, even though HTTP/1.1 clients will only generate them in requests to proxies. 1454 1429 </p> 1455 <p id="rfc.section.4.1.2.p.9"><span id="rfc.iref.a.3"></span> The "authority form" is only used by the CONNECT request method (<a href="p2-semantics.html#CONNECT" title="CONNECT">Section 7.9</a> of <a href="#Part2" id="rfc.xref.Part2. 3"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).1430 <p id="rfc.section.4.1.2.p.9"><span id="rfc.iref.a.3"></span> The "authority form" is only used by the CONNECT request method (<a href="p2-semantics.html#CONNECT" title="CONNECT">Section 7.9</a> of <a href="#Part2" id="rfc.xref.Part2.1"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). 1456 1431 </p> 1457 1432 <p id="rfc.section.4.1.2.p.10"><span id="rfc.iref.p.2"></span> The most common form of request-target is that used to identify a resource on an origin server or gateway ("path-absolute … … 1459 1434 server would create a TCP connection to port 80 of the host "www.example.org" and send the lines: 1460 1435 </p> 1461 <div id="rfc.figure.u.3 6"></div><pre class="text2">GET /pub/WWW/TheProject.html HTTP/1.11436 <div id="rfc.figure.u.33"></div><pre class="text2">GET /pub/WWW/TheProject.html HTTP/1.1 1462 1437 Host: www.example.org 1463 1438 </pre><p id="rfc.section.4.1.2.p.12">followed by the remainder of the Request. Note that the absolute path cannot be empty; if none is present in the original … … 1466 1441 <p id="rfc.section.4.1.2.p.13">If a proxy receives an OPTIONS request without any path in the request-target, then the last proxy on the request chain <em class="bcp14">MUST</em> forward the request with "*" as the final request-target. 1467 1442 </p> 1468 <div id="rfc.figure.u.3 7"></div>1443 <div id="rfc.figure.u.34"></div> 1469 1444 <p>For example, the request</p><pre class="text2">OPTIONS http://www.example.org:8001 HTTP/1.1 1470 </pre><div id="rfc.figure.u.3 8"></div>1445 </pre><div id="rfc.figure.u.35"></div> 1471 1446 <p>would be forwarded by the final proxy as</p><pre class="text2">OPTIONS * HTTP/1.1 1472 1447 Host: www.example.org:8001 … … 1484 1459 </div> 1485 1460 <p id="rfc.section.4.1.2.p.19">HTTP does not place a pre-defined limit on the length of a request-target. A server <em class="bcp14">MUST</em> be prepared to receive URIs of unbounded length and respond with the 414 (URI Too Long) status code if the received request-target 1486 would be longer than the server wishes to handle (see <a href="p2-semantics.html#status.414" title="414 URI Too Long">Section 8.4.15</a> of <a href="#Part2" id="rfc.xref.Part2. 4"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).1461 would be longer than the server wishes to handle (see <a href="p2-semantics.html#status.414" title="414 URI Too Long">Section 8.4.15</a> of <a href="#Part2" id="rfc.xref.Part2.2"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). 1487 1462 </p> 1488 1463 <p id="rfc.section.4.1.2.p.20">Various ad-hoc limitations on request-target length are found in practice. It is <em class="bcp14">RECOMMENDED</em> that all HTTP senders and recipients support request-target lengths of 8000 or more octets. … … 1538 1513 </p> 1539 1514 <p id="rfc.section.4.3.p.6">Otherwise, when request-target uses the authority form, the effective request URI is undefined.</p> 1540 <div id="rfc.figure.u.3 9"></div>1515 <div id="rfc.figure.u.36"></div> 1541 1516 <p>Example 1: the effective request URI for the message</p> <pre class="text">GET /pub/WWW/TheProject.html HTTP/1.1 1542 1517 Host: www.example.org:8080 … … 1544 1519 the request-target "/pub/WWW/TheProject.html", thus "http://www.example.org:8080/pub/WWW/TheProject.html". 1545 1520 </p> 1546 <div id="rfc.figure.u. 40"></div>1521 <div id="rfc.figure.u.37"></div> 1547 1522 <p>Example 2: the effective request URI for the message</p> <pre class="text">GET * HTTP/1.1 1548 1523 Host: www.example.org … … 1554 1529 <h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a> <a id="response" href="#response">Response</a></h1> 1555 1530 <p id="rfc.section.5.p.1">After receiving and interpreting a request message, a server responds with an HTTP response message.</p> 1556 <div id="rfc.figure.u. 41"></div><pre class="inline"><span id="rfc.iref.g.49"></span> <a href="#response" class="smpl">Response</a> = <a href="#status-line" class="smpl">Status-Line</a> ; <a href="#status-line" title="Status-Line">Section 5.1</a>1531 <div id="rfc.figure.u.38"></div><pre class="inline"><span id="rfc.iref.g.49"></span> <a href="#response" class="smpl">Response</a> = <a href="#status-line" class="smpl">Status-Line</a> ; <a href="#status-line" title="Status-Line">Section 5.1</a> 1557 1532 *( <a href="#header.fields" class="smpl">header-field</a> <a href="#core.rules" class="smpl">CRLF</a> ) ; <a href="#header.fields" title="Header Fields">Section 3.2</a> 1558 1533 <a href="#core.rules" class="smpl">CRLF</a> … … 1563 1538 CRLF sequence. 1564 1539 </p> 1565 <div id="rfc.figure.u. 42"></div><pre class="inline"><span id="rfc.iref.g.50"></span> <a href="#status-line" class="smpl">Status-Line</a> = <a href="#http.version" class="smpl">HTTP-Version</a> <a href="#core.rules" class="smpl">SP</a> <a href="#status.code.and.reason.phrase" class="smpl">Status-Code</a> <a href="#core.rules" class="smpl">SP</a> <a href="#status.code.and.reason.phrase" class="smpl">Reason-Phrase</a> <a href="#core.rules" class="smpl">CRLF</a>1540 <div id="rfc.figure.u.39"></div><pre class="inline"><span id="rfc.iref.g.50"></span> <a href="#status-line" class="smpl">Status-Line</a> = <a href="#http.version" class="smpl">HTTP-Version</a> <a href="#core.rules" class="smpl">SP</a> <a href="#status.code.and.reason.phrase" class="smpl">Status-Code</a> <a href="#core.rules" class="smpl">SP</a> <a href="#status.code.and.reason.phrase" class="smpl">Reason-Phrase</a> <a href="#core.rules" class="smpl">CRLF</a> 1566 1541 </pre><h3 id="rfc.section.5.1.1"><a href="#rfc.section.5.1.1">5.1.1</a> <a id="status.code.and.reason.phrase" href="#status.code.and.reason.phrase">Status Code and Reason Phrase</a></h3> 1567 1542 <p id="rfc.section.5.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 1568 are fully defined in <a href="p2-semantics.html#status.codes" title="Status Code Definitions">Section 8</a> of <a href="#Part2" id="rfc.xref.Part2. 5"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>. The Reason Phrase exists for the sole purpose of providing a textual description associated with the numeric status code,1543 are fully defined in <a href="p2-semantics.html#status.codes" title="Status Code Definitions">Section 8</a> of <a href="#Part2" id="rfc.xref.Part2.3"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>. The Reason Phrase exists for the sole purpose of providing a textual description associated with the numeric status code, 1569 1544 out of deference to earlier Internet application protocols that were more frequently used with interactive text clients. A 1570 1545 client <em class="bcp14">SHOULD</em> ignore the content of the Reason Phrase. … … 1580 1555 <li>5xx: Server Error - The server failed to fulfill an apparently valid request</li> 1581 1556 </ul> 1582 <div id="rfc.figure.u.4 3"></div><pre class="inline"><span id="rfc.iref.g.51"></span><span id="rfc.iref.g.52"></span> <a href="#status.code.and.reason.phrase" class="smpl">Status-Code</a> = 3<a href="#core.rules" class="smpl">DIGIT</a>1557 <div id="rfc.figure.u.40"></div><pre class="inline"><span id="rfc.iref.g.51"></span><span id="rfc.iref.g.52"></span> <a href="#status.code.and.reason.phrase" class="smpl">Status-Code</a> = 3<a href="#core.rules" class="smpl">DIGIT</a> 1583 1558 <a href="#status.code.and.reason.phrase" class="smpl">Reason-Phrase</a> = *( <a href="#core.rules" class="smpl">WSP</a> / <a href="#core.rules" class="smpl">VCHAR</a> / <a href="#rule.quoted-string" class="smpl">obs-text</a> ) 1584 1559 </pre><h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a> <a id="protocol.parameters" href="#protocol.parameters">Protocol Parameters</a></h1> … … 1587 1562 a fixed-length subset of that defined by <a href="#RFC1123" id="rfc.xref.RFC1123.1"><cite title="Requirements for Internet Hosts - Application and Support">[RFC1123]</cite></a>: 1588 1563 </p> 1589 <div id="rfc.figure.u.4 4"></div><pre class="text">Sun, 06 Nov 1994 08:49:37 GMT ; RFC 11231564 <div id="rfc.figure.u.41"></div><pre class="text">Sun, 06 Nov 1994 08:49:37 GMT ; RFC 1123 1590 1565 </pre><p id="rfc.section.6.1.p.3">The other formats are described here only for compatibility with obsolete implementations.</p> 1591 <div id="rfc.figure.u.4 5"></div><pre class="text">Sunday, 06-Nov-94 08:49:37 GMT ; obsolete RFC 850 format1566 <div id="rfc.figure.u.42"></div><pre class="text">Sunday, 06-Nov-94 08:49:37 GMT ; obsolete RFC 850 format 1592 1567 Sun Nov 6 08:49:37 1994 ; ANSI C's asctime() format 1593 1568 </pre><p id="rfc.section.6.1.p.5">HTTP/1.1 clients and servers that parse a date value <em class="bcp14">MUST</em> accept all three formats (for compatibility with HTTP/1.0), though they <em class="bcp14">MUST</em> only generate the RFC 1123 format for representing HTTP-date values in header fields. See <a href="#tolerant.applications" title="Tolerant Applications">Appendix A</a> for further information. … … 1597 1572 time zone, and <em class="bcp14">MUST</em> be assumed when reading the asctime format. HTTP-date is case sensitive and <em class="bcp14">MUST NOT</em> include additional whitespace beyond that specifically included as SP in the grammar. 1598 1573 </p> 1599 <div id="rfc.figure.u.4 6"></div><pre class="inline"><span id="rfc.iref.g.53"></span> <a href="#date.time.formats.full.date" class="smpl">HTTP-date</a> = <a href="#preferred.date.format" class="smpl">rfc1123-date</a> / <a href="#obsolete.date.formats" class="smpl">obs-date</a>1574 <div id="rfc.figure.u.43"></div><pre class="inline"><span id="rfc.iref.g.53"></span> <a href="#date.time.formats.full.date" class="smpl">HTTP-date</a> = <a href="#preferred.date.format" class="smpl">rfc1123-date</a> / <a href="#obsolete.date.formats" class="smpl">obs-date</a> 1600 1575 </pre><div id="preferred.date.format"> 1601 1576 <p id="rfc.section.6.1.p.8"> Preferred format:</p> 1602 1577 </div> 1603 <div id="rfc.figure.u.4 7"></div><pre class="inline"><span id="rfc.iref.g.54"></span><span id="rfc.iref.g.55"></span><span id="rfc.iref.g.56"></span><span id="rfc.iref.g.57"></span><span id="rfc.iref.g.58"></span><span id="rfc.iref.g.59"></span><span id="rfc.iref.g.60"></span><span id="rfc.iref.g.61"></span><span id="rfc.iref.g.62"></span><span id="rfc.iref.g.63"></span><span id="rfc.iref.g.64"></span><span id="rfc.iref.g.65"></span> <a href="#preferred.date.format" class="smpl">rfc1123-date</a> = <a href="#preferred.date.format" class="smpl">day-name</a> "," <a href="#core.rules" class="smpl">SP</a> date1 <a href="#core.rules" class="smpl">SP</a> <a href="#preferred.date.format" class="smpl">time-of-day</a> <a href="#core.rules" class="smpl">SP</a> <a href="#preferred.date.format" class="smpl">GMT</a>1578 <div id="rfc.figure.u.44"></div><pre class="inline"><span id="rfc.iref.g.54"></span><span id="rfc.iref.g.55"></span><span id="rfc.iref.g.56"></span><span id="rfc.iref.g.57"></span><span id="rfc.iref.g.58"></span><span id="rfc.iref.g.59"></span><span id="rfc.iref.g.60"></span><span id="rfc.iref.g.61"></span><span id="rfc.iref.g.62"></span><span id="rfc.iref.g.63"></span><span id="rfc.iref.g.64"></span><span id="rfc.iref.g.65"></span> <a href="#preferred.date.format" class="smpl">rfc1123-date</a> = <a href="#preferred.date.format" class="smpl">day-name</a> "," <a href="#core.rules" class="smpl">SP</a> date1 <a href="#core.rules" class="smpl">SP</a> <a href="#preferred.date.format" class="smpl">time-of-day</a> <a href="#core.rules" class="smpl">SP</a> <a href="#preferred.date.format" class="smpl">GMT</a> 1604 1579 ; fixed length subset of the format defined in 1605 1580 ; <a href="http://tools.ietf.org/html/rfc1123#section-5.2.14">Section 5.2.14</a> of <a href="#RFC1123" id="rfc.xref.RFC1123.2"><cite title="Requirements for Internet Hosts - Application and Support">[RFC1123]</cite></a> … … 1644 1619 <p id="rfc.section.6.1.p.11"> Obsolete formats:</p> 1645 1620 </div> 1646 <div id="rfc.figure.u.4 8"></div><pre class="inline"><span id="rfc.iref.g.66"></span> <a href="#obsolete.date.formats" class="smpl">obs-date</a> = <a href="#obsolete.date.formats" class="smpl">rfc850-date</a> / <a href="#obsolete.date.formats" class="smpl">asctime-date</a>1647 </pre><div id="rfc.figure.u.4 9"></div><pre class="inline"><span id="rfc.iref.g.67"></span> <a href="#obsolete.date.formats" class="smpl">rfc850-date</a> = <a href="#obsolete.date.formats" class="smpl">day-name-l</a> "," <a href="#core.rules" class="smpl">SP</a> <a href="#obsolete.date.formats" class="smpl">date2</a> <a href="#core.rules" class="smpl">SP</a> <a href="#preferred.date.format" class="smpl">time-of-day</a> <a href="#core.rules" class="smpl">SP</a> <a href="#preferred.date.format" class="smpl">GMT</a>1621 <div id="rfc.figure.u.45"></div><pre class="inline"><span id="rfc.iref.g.66"></span> <a href="#obsolete.date.formats" class="smpl">obs-date</a> = <a href="#obsolete.date.formats" class="smpl">rfc850-date</a> / <a href="#obsolete.date.formats" class="smpl">asctime-date</a> 1622 </pre><div id="rfc.figure.u.46"></div><pre class="inline"><span id="rfc.iref.g.67"></span> <a href="#obsolete.date.formats" class="smpl">rfc850-date</a> = <a href="#obsolete.date.formats" class="smpl">day-name-l</a> "," <a href="#core.rules" class="smpl">SP</a> <a href="#obsolete.date.formats" class="smpl">date2</a> <a href="#core.rules" class="smpl">SP</a> <a href="#preferred.date.format" class="smpl">time-of-day</a> <a href="#core.rules" class="smpl">SP</a> <a href="#preferred.date.format" class="smpl">GMT</a> 1648 1623 <a href="#obsolete.date.formats" class="smpl">date2</a> = <a href="#preferred.date.format" class="smpl">day</a> "-" <a href="#preferred.date.format" class="smpl">month</a> "-" 2<a href="#core.rules" class="smpl">DIGIT</a> 1649 1624 ; day-month-year (e.g., 02-Jun-82) … … 1656 1631 / %x53.61.74.75.72.64.61.79 ; "Saturday", case-sensitive 1657 1632 / %x53.75.6E.64.61.79 ; "Sunday", case-sensitive 1658 </pre><div id="rfc.figure.u. 50"></div><pre class="inline"><span id="rfc.iref.g.68"></span> <a href="#obsolete.date.formats" class="smpl">asctime-date</a> = <a href="#preferred.date.format" class="smpl">day-name</a> <a href="#core.rules" class="smpl">SP</a> <a href="#obsolete.date.formats" class="smpl">date3</a> <a href="#core.rules" class="smpl">SP</a> <a href="#preferred.date.format" class="smpl">time-of-day</a> <a href="#core.rules" class="smpl">SP</a> <a href="#preferred.date.format" class="smpl">year</a>1633 </pre><div id="rfc.figure.u.47"></div><pre class="inline"><span id="rfc.iref.g.68"></span> <a href="#obsolete.date.formats" class="smpl">asctime-date</a> = <a href="#preferred.date.format" class="smpl">day-name</a> <a href="#core.rules" class="smpl">SP</a> <a href="#obsolete.date.formats" class="smpl">date3</a> <a href="#core.rules" class="smpl">SP</a> <a href="#preferred.date.format" class="smpl">time-of-day</a> <a href="#core.rules" class="smpl">SP</a> <a href="#preferred.date.format" class="smpl">year</a> 1659 1634 <a href="#obsolete.date.formats" class="smpl">date3</a> = <a href="#preferred.date.format" class="smpl">month</a> <a href="#core.rules" class="smpl">SP</a> ( 2<a href="#core.rules" class="smpl">DIGIT</a> / ( <a href="#core.rules" class="smpl">SP</a> 1<a href="#core.rules" class="smpl">DIGIT</a> )) 1660 1635 ; month day (e.g., Jun 2) … … 1674 1649 transfer-coding is a property of the message rather than a property of the representation that is being transferred. 1675 1650 </p> 1676 <div id="rfc.figure.u. 51"></div><pre class="inline"><span id="rfc.iref.g.69"></span><span id="rfc.iref.g.70"></span> <a href="#transfer.codings" class="smpl">transfer-coding</a> = "chunked" ; <a href="#chunked.encoding" title="Chunked Transfer Coding">Section 6.2.1</a>1651 <div id="rfc.figure.u.48"></div><pre class="inline"><span id="rfc.iref.g.69"></span><span id="rfc.iref.g.70"></span> <a href="#transfer.codings" class="smpl">transfer-coding</a> = "chunked" ; <a href="#chunked.encoding" title="Chunked Transfer Coding">Section 6.2.1</a> 1677 1652 / "compress" ; <a href="#compress.coding" title="Compress Coding">Section 6.2.2.1</a> 1678 1653 / "deflate" ; <a href="#deflate.coding" title="Deflate Coding">Section 6.2.2.2</a> … … 1683 1658 <p id="rfc.section.6.2.p.3"> Parameters are in the form of attribute/value pairs.</p> 1684 1659 </div> 1685 <div id="rfc.figure.u. 52"></div><pre class="inline"><span id="rfc.iref.g.71"></span><span id="rfc.iref.g.72"></span><span id="rfc.iref.g.73"></span><span id="rfc.iref.g.74"></span><span id="rfc.iref.g.75"></span> <a href="#rule.parameter" class="smpl">transfer-parameter</a> = <a href="#rule.parameter" class="smpl">attribute</a> <a href="#rule.whitespace" class="smpl">BWS</a> "=" <a href="#rule.whitespace" class="smpl">BWS</a> <a href="#rule.parameter" class="smpl">value</a>1660 <div id="rfc.figure.u.49"></div><pre class="inline"><span id="rfc.iref.g.71"></span><span id="rfc.iref.g.72"></span><span id="rfc.iref.g.73"></span><span id="rfc.iref.g.74"></span><span id="rfc.iref.g.75"></span> <a href="#rule.parameter" class="smpl">transfer-parameter</a> = <a href="#rule.parameter" class="smpl">attribute</a> <a href="#rule.whitespace" class="smpl">BWS</a> "=" <a href="#rule.whitespace" class="smpl">BWS</a> <a href="#rule.parameter" class="smpl">value</a> 1686 1661 <a href="#rule.parameter" class="smpl">attribute</a> = <a href="#rule.token.separators" class="smpl">token</a> 1687 1662 <a href="#rule.parameter" class="smpl">value</a> = <a href="#rule.token.separators" class="smpl">word</a> … … 1701 1676 for the recipient to verify that it has received the full message. 1702 1677 </p> 1703 <div id="rfc.figure.u.5 3"></div><pre class="inline"><span id="rfc.iref.g.76"></span><span id="rfc.iref.g.77"></span><span id="rfc.iref.g.78"></span><span id="rfc.iref.g.79"></span><span id="rfc.iref.g.80"></span><span id="rfc.iref.g.81"></span><span id="rfc.iref.g.82"></span><span id="rfc.iref.g.83"></span><span id="rfc.iref.g.84"></span><span id="rfc.iref.g.85"></span><span id="rfc.iref.g.86"></span> <a href="#chunked.encoding" class="smpl">Chunked-Body</a> = *<a href="#chunked.encoding" class="smpl">chunk</a>1678 <div id="rfc.figure.u.50"></div><pre class="inline"><span id="rfc.iref.g.76"></span><span id="rfc.iref.g.77"></span><span id="rfc.iref.g.78"></span><span id="rfc.iref.g.79"></span><span id="rfc.iref.g.80"></span><span id="rfc.iref.g.81"></span><span id="rfc.iref.g.82"></span><span id="rfc.iref.g.83"></span><span id="rfc.iref.g.84"></span><span id="rfc.iref.g.85"></span><span id="rfc.iref.g.86"></span> <a href="#chunked.encoding" class="smpl">Chunked-Body</a> = *<a href="#chunked.encoding" class="smpl">chunk</a> 1704 1679 <a href="#chunked.encoding" class="smpl">last-chunk</a> 1705 1680 <a href="#chunked.encoding" class="smpl">trailer-part</a> … … 1745 1720 </p> 1746 1721 <p id="rfc.section.6.2.1.p.7">A process for decoding the "chunked" transfer-coding can be represented in pseudo-code as:</p> 1747 <div id="rfc.figure.u.5 4"></div><pre class="text"> length := 01722 <div id="rfc.figure.u.51"></div><pre class="text"> length := 0 1748 1723 read chunk-size, chunk-ext (if any) and CRLF 1749 1724 while (chunk-size > 0) { … … 1806 1781 <li>Pointer to specification text</li> 1807 1782 </ul> 1808 <p id="rfc.section.6.2.3.p.3">Names of transfer codings <em class="bcp14">MUST NOT</em> overlap with names of content codings (<a href="p3-payload.html#content.codings" title="Content Codings">Section 2.2</a> of <a href="#Part3" id="rfc.xref.Part3. 4"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>), unless the encoding transformation is identical (as it is the case for the compression codings defined in <a href="#compression.codings" title="Compression Codings">Section 6.2.2</a>).1783 <p id="rfc.section.6.2.3.p.3">Names of transfer codings <em class="bcp14">MUST NOT</em> overlap with names of content codings (<a href="p3-payload.html#content.codings" title="Content Codings">Section 2.2</a> of <a href="#Part3" id="rfc.xref.Part3.2"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>), unless the encoding transformation is identical (as it is the case for the compression codings defined in <a href="#compression.codings" title="Compression Codings">Section 6.2.2</a>). 1809 1784 </p> 1810 1785 <p id="rfc.section.6.2.3.p.4">Values to be added to this name space require a specification (see "Specification Required" in <a href="http://tools.ietf.org/html/rfc5226#section-4.1">Section 4.1</a> of <a href="#RFC5226" id="rfc.xref.RFC5226.1"><cite title="Guidelines for Writing an IANA Considerations Section in RFCs">[RFC5226]</cite></a>), and <em class="bcp14">MUST</em> conform to the purpose of transfer coding defined in this section. … … 1817 1792 By convention, the products are listed in order of their significance for identifying the application. 1818 1793 </p> 1819 <div id="rfc.figure.u.5 5"></div><pre class="inline"><span id="rfc.iref.g.88"></span><span id="rfc.iref.g.89"></span> <a href="#product.tokens" class="smpl">product</a> = <a href="#rule.token.separators" class="smpl">token</a> ["/" <a href="#product.tokens" class="smpl">product-version</a>]1794 <div id="rfc.figure.u.52"></div><pre class="inline"><span id="rfc.iref.g.88"></span><span id="rfc.iref.g.89"></span> <a href="#product.tokens" class="smpl">product</a> = <a href="#rule.token.separators" class="smpl">token</a> ["/" <a href="#product.tokens" class="smpl">product-version</a>] 1820 1795 <a href="#product.tokens" class="smpl">product-version</a> = <a href="#rule.token.separators" class="smpl">token</a> 1821 1796 </pre><p id="rfc.section.6.3.p.3">Examples:</p> 1822 <div id="rfc.figure.u.5 6"></div><pre class="text"> User-Agent: CERN-LineMode/2.15 libwww/2.17b31797 <div id="rfc.figure.u.53"></div><pre class="text"> User-Agent: CERN-LineMode/2.15 libwww/2.17b3 1823 1798 Server: Apache/0.8.4 1824 1799 </pre><p id="rfc.section.6.3.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). 1825 1800 </p> 1826 1801 <h2 id="rfc.section.6.4"><a href="#rfc.section.6.4">6.4</a> <a id="quality.values" href="#quality.values">Quality Values</a></h2> 1827 <p id="rfc.section.6.4.p.1">Both transfer codings (TE request header field, <a href="#header.te" id="rfc.xref.header.te.3" title="TE">Section 9.5</a>) and content negotiation (<a href="p3-payload.html#content.negotiation" title="Content Negotiation">Section 5</a> of <a href="#Part3" id="rfc.xref.Part3. 5"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>) use short "floating point" numbers to indicate the relative importance ("weight") of various negotiable parameters. A weight1802 <p id="rfc.section.6.4.p.1">Both transfer codings (TE request header field, <a href="#header.te" id="rfc.xref.header.te.3" title="TE">Section 9.5</a>) and content negotiation (<a href="p3-payload.html#content.negotiation" title="Content Negotiation">Section 5</a> of <a href="#Part3" id="rfc.xref.Part3.3"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>) use short "floating point" numbers to indicate the relative importance ("weight") of various negotiable parameters. A weight 1828 1803 is normalized to a real number in the range 0 through 1, where 0 is the minimum and 1 the maximum value. If a parameter has 1829 1804 a quality value of 0, then content with this parameter is "not acceptable" for the client. HTTP/1.1 applications <em class="bcp14">MUST NOT</em> generate more than three digits after the decimal point. User configuration of these values <em class="bcp14">SHOULD</em> also be limited in this fashion. 1830 1805 </p> 1831 <div id="rfc.figure.u.5 7"></div><pre class="inline"><span id="rfc.iref.g.90"></span> <a href="#quality.values" class="smpl">qvalue</a> = ( "0" [ "." 0*3<a href="#core.rules" class="smpl">DIGIT</a> ] )1806 <div id="rfc.figure.u.54"></div><pre class="inline"><span id="rfc.iref.g.90"></span> <a href="#quality.values" class="smpl">qvalue</a> = ( "0" [ "." 0*3<a href="#core.rules" class="smpl">DIGIT</a> ] ) 1832 1807 / ( "1" [ "." 0*3("0") ] ) 1833 1808 </pre><div class="note" id="rfc.section.6.4.p.3"> … … 1889 1864 <p id="rfc.section.7.1.2.2.p.2">Clients which assume persistent connections and pipeline immediately after connection establishment <em class="bcp14">SHOULD</em> be prepared to retry their connection if the first pipelined attempt fails. If a client does such a retry, it <em class="bcp14">MUST NOT</em> pipeline before it knows the connection is persistent. Clients <em class="bcp14">MUST</em> also be prepared to resend their requests if the server closes the connection before sending all of the corresponding responses. 1890 1865 </p> 1891 <p id="rfc.section.7.1.2.2.p.3">Clients <em class="bcp14">SHOULD NOT</em> pipeline requests using non-idempotent request methods or non-idempotent sequences of request methods (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 7.1.2</a> of <a href="#Part2" id="rfc.xref.Part2. 6"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). Otherwise, a premature termination of the transport connection could lead to indeterminate results. A client wishing to1866 <p id="rfc.section.7.1.2.2.p.3">Clients <em class="bcp14">SHOULD NOT</em> pipeline requests using non-idempotent request methods or non-idempotent sequences of request methods (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 7.1.2</a> of <a href="#Part2" id="rfc.xref.Part2.4"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). Otherwise, a premature termination of the transport connection could lead to indeterminate results. A client wishing to 1892 1867 send a non-idempotent request <em class="bcp14">SHOULD</em> wait to send that request until it has received the response status line for the previous request. 1893 1868 </p> … … 1950 1925 <li>Content-Type</li> 1951 1926 </ul> 1952 <p id="rfc.section.7.1.3.2.p.6">A transforming proxy <em class="bcp14">MAY</em> modify or add these fields to a message that does not include no-transform, but if it does so, it <em class="bcp14">MUST</em> add a Warning 214 (Transformation applied) if one does not already appear in the message (see <a href="p6-cache.html#header.warning" title="Warning">Section 3.6</a> of <a href="#Part6" id="rfc.xref.Part6. 8"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>).1927 <p id="rfc.section.7.1.3.2.p.6">A transforming proxy <em class="bcp14">MAY</em> modify or add these fields to a message that does not include no-transform, but if it does so, it <em class="bcp14">MUST</em> add a Warning 214 (Transformation applied) if one does not already appear in the message (see <a href="p6-cache.html#header.warning" title="Warning">Section 3.6</a> of <a href="#Part6" id="rfc.xref.Part6.4"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>). 1953 1928 </p> 1954 1929 <div class="note" id="rfc.section.7.1.3.2.p.7"> … … 1957 1932 </p> 1958 1933 </div> 1959 <p id="rfc.section.7.1.3.2.p.8">A non-transforming proxy <em class="bcp14">MUST</em> preserve the message payload (<a href="#Part3" id="rfc.xref.Part3. 6"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>), though it <em class="bcp14">MAY</em> change the message-body through application or removal of a transfer-coding (<a href="#transfer.codings" title="Transfer Codings">Section 6.2</a>).1934 <p id="rfc.section.7.1.3.2.p.8">A non-transforming proxy <em class="bcp14">MUST</em> preserve the message payload (<a href="#Part3" id="rfc.xref.Part3.4"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>), though it <em class="bcp14">MAY</em> change the message-body through application or removal of a transfer-coding (<a href="#transfer.codings" title="Transfer Codings">Section 6.2</a>). 1960 1935 </p> 1961 1936 <h3 id="rfc.section.7.1.4"><a href="#rfc.section.7.1.4">7.1.4</a> <a id="persistent.practical" href="#persistent.practical">Practical Considerations</a></h3> … … 1973 1948 </p> 1974 1949 <p id="rfc.section.7.1.4.p.4">This means that clients, servers, and proxies <em class="bcp14">MUST</em> be able to recover from asynchronous close events. Client software <em class="bcp14">SHOULD</em> reopen the transport connection and retransmit the aborted sequence of requests without user interaction so long as the request 1975 sequence is idempotent (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 7.1.2</a> of <a href="#Part2" id="rfc.xref.Part2. 7"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). Non-idempotent request methods or sequences <em class="bcp14">MUST NOT</em> be automatically retried, although user agents <em class="bcp14">MAY</em> offer a human operator the choice of retrying the request(s). Confirmation by user-agent software with semantic understanding1950 sequence is idempotent (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 7.1.2</a> of <a href="#Part2" id="rfc.xref.Part2.5"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). Non-idempotent request methods or sequences <em class="bcp14">MUST NOT</em> be automatically retried, although user agents <em class="bcp14">MAY</em> offer a human operator the choice of retrying the request(s). Confirmation by user-agent software with semantic understanding 1976 1951 of the application <em class="bcp14">MAY</em> substitute for user confirmation. The automatic retry <em class="bcp14">SHOULD NOT</em> be repeated if the second sequence of requests fails. 1977 1952 </p> … … 2000 1975 </p> 2001 1976 <h3 id="rfc.section.7.2.3"><a href="#rfc.section.7.2.3">7.2.3</a> <a id="use.of.the.100.status" href="#use.of.the.100.status">Use of the 100 (Continue) Status</a></h3> 2002 <p id="rfc.section.7.2.3.p.1">The purpose of the 100 (Continue) status code (see <a href="p2-semantics.html#status.100" title="100 Continue">Section 8.1.1</a> of <a href="#Part2" id="rfc.xref.Part2. 8"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) is to allow a client that is sending a request message with a request body to determine if the origin server is willing1977 <p id="rfc.section.7.2.3.p.1">The purpose of the 100 (Continue) status code (see <a href="p2-semantics.html#status.100" title="100 Continue">Section 8.1.1</a> of <a href="#Part2" id="rfc.xref.Part2.6"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) is to allow a client that is sending a request message with a request body to determine if the origin server is willing 2003 1978 to accept the request (based on the request header fields) before the client sends the request body. In some cases, it might 2004 1979 either be inappropriate or highly inefficient for the client to send the body if the server will reject the message without … … 2007 1982 <p id="rfc.section.7.2.3.p.2">Requirements for HTTP/1.1 clients: </p> 2008 1983 <ul> 2009 <li>If a client will wait for a 100 (Continue) response before sending the request body, it <em class="bcp14">MUST</em> send an Expect request-header field (<a href="p2-semantics.html#header.expect" title="Expect">Section 9.2</a> of <a href="#Part2" id="rfc.xref.Part2.9"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) with the "100-continue" expectation.2010 </li> 2011 <li>A client <em class="bcp14">MUST NOT</em> send an Expect request-header field (<a href="p2-semantics.html#header.expect" title="Expect">Section 9.2</a> of <a href="#Part2" id="rfc.xref.Part2.10"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) with the "100-continue" expectation if it does not intend to send a request body.1984 <li>If a client will wait for a 100 (Continue) response before sending the request body, it <em class="bcp14">MUST</em> send an Expect header field (<a href="p2-semantics.html#header.expect" title="Expect">Section 9.2</a> of <a href="#Part2" id="rfc.xref.Part2.7"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) with the "100-continue" expectation. 1985 </li> 1986 <li>A client <em class="bcp14">MUST NOT</em> send an Expect header field (<a href="p2-semantics.html#header.expect" title="Expect">Section 9.2</a> of <a href="#Part2" id="rfc.xref.Part2.8"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) with the "100-continue" expectation if it does not intend to send a request body. 2012 1987 </li> 2013 1988 </ul> … … 2019 1994 <p id="rfc.section.7.2.3.p.4">Requirements for HTTP/1.1 origin servers: </p> 2020 1995 <ul> 2021 <li>Upon receiving a request which includes an Expect request-header field with the "100-continue" expectation, an origin server <em class="bcp14">MUST</em> either respond with 100 (Continue) status code and continue to read from the input stream, or respond with a final status1996 <li>Upon receiving a request which includes an Expect header field with the "100-continue" expectation, an origin server <em class="bcp14">MUST</em> either respond with 100 (Continue) status code and continue to read from the input stream, or respond with a final status 2022 1997 code. The origin server <em class="bcp14">MUST NOT</em> wait for the request body before sending the 100 (Continue) response. If it responds with a final status code, it <em class="bcp14">MAY</em> close the transport connection or it <em class="bcp14">MAY</em> continue to read and discard the rest of the request. It <em class="bcp14">MUST NOT</em> perform the request method if it returns a final status code. 2023 1998 </li> 2024 <li>An origin server <em class="bcp14">SHOULD NOT</em> send a 100 (Continue) response if the request message does not include an Expect request-header field with the "100-continue"2025 expectation,and <em class="bcp14">MUST NOT</em> send a 100 (Continue) response if such a request comes from an HTTP/1.0 (or earlier) client. There is an exception to this2026 rule: for compatibility with <a href="#RFC2068" id="rfc.xref.RFC2068.2"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>, a server <em class="bcp14">MAY</em> send a 100 (Continue) status code in response to an HTTP/1.1 PUT or POST request that does not include an Expect request-header2027 field with the "100-continue" expectation. This exception, the purpose of which is to minimize any client processing delays2028 associated with an undeclared wait for 100 (Continue) status code, applies only to HTTP/1.1 requests, and not to requests2029 with any otherHTTP-version value.1999 <li>An origin server <em class="bcp14">SHOULD NOT</em> send a 100 (Continue) response if the request message does not include an Expect header field with the "100-continue" expectation, 2000 and <em class="bcp14">MUST NOT</em> send a 100 (Continue) response if such a request comes from an HTTP/1.0 (or earlier) client. There is an exception to this 2001 rule: for compatibility with <a href="#RFC2068" id="rfc.xref.RFC2068.2"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>, a server <em class="bcp14">MAY</em> send a 100 (Continue) status code in response to an HTTP/1.1 PUT or POST request that does not include an Expect header field 2002 with the "100-continue" expectation. This exception, the purpose of which is to minimize any client processing delays associated 2003 with an undeclared wait for 100 (Continue) status code, applies only to HTTP/1.1 requests, and not to requests with any other 2004 HTTP-version value. 2030 2005 </li> 2031 2006 <li>An origin server <em class="bcp14">MAY</em> omit a 100 (Continue) response if it has already received some or all of the request body for the corresponding request. … … 2034 2009 prematurely. 2035 2010 </li> 2036 <li>If an origin server receives a request that does not include an Expect request-header field with the "100-continue" expectation,2037 the request includes a request body, and the server responds with a final status code before reading the entire request body2038 fromthe transport connection, then the server <em class="bcp14">SHOULD NOT</em> close the transport connection until it has read the entire request, or until the client closes the connection. Otherwise,2011 <li>If an origin server receives a request that does not include an Expect header field with the "100-continue" expectation, the 2012 request includes a request body, and the server responds with a final status code before reading the entire request body from 2013 the transport connection, then the server <em class="bcp14">SHOULD NOT</em> close the transport connection until it has read the entire request, or until the client closes the connection. Otherwise, 2039 2014 the client might not reliably receive the response message. However, this requirement is not be construed as preventing a 2040 2015 server from defending itself against denial-of-service attacks, or from badly broken client implementations. … … 2043 2018 <p id="rfc.section.7.2.3.p.5">Requirements for HTTP/1.1 proxies: </p> 2044 2019 <ul> 2045 <li>If a proxy receives a request that includes an Expect request-header field with the "100-continue" expectation, and the proxy2046 either knows that the next-hop server complies with HTTP/1.1 or higher, or does not know the HTTP version of the next-hop2047 server,it <em class="bcp14">MUST</em> forward the request, including the Expect header field.2020 <li>If a proxy receives a request that includes an Expect header field with the "100-continue" expectation, and the proxy either 2021 knows that the next-hop server complies with HTTP/1.1 or higher, or does not know the HTTP version of the next-hop server, 2022 it <em class="bcp14">MUST</em> forward the request, including the Expect header field. 2048 2023 </li> 2049 2024 <li>If the proxy knows that the version of the next-hop server is HTTP/1.0 or lower, it <em class="bcp14">MUST NOT</em> forward the request, and it <em class="bcp14">MUST</em> respond with a 417 (Expectation Failed) status code. … … 2052 2027 </li> 2053 2028 <li>A proxy <em class="bcp14">MUST NOT</em> forward a 100 (Continue) response if the request message was received from an HTTP/1.0 (or earlier) client and did not include 2054 an Expect request-header field with the "100-continue" expectation. This requirement overrides the general rule for forwarding2055 of 1xx responses (see <a href="p2-semantics.html#status.1xx" title="Informational 1xx">Section 8.1</a> of <a href="#Part2" id="rfc.xref.Part2.11"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).2029 an Expect header field with the "100-continue" expectation. This requirement overrides the general rule for forwarding of 2030 1xx responses (see <a href="p2-semantics.html#status.1xx" title="Informational 1xx">Section 8.1</a> of <a href="#Part2" id="rfc.xref.Part2.9"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). 2056 2031 </li> 2057 2032 </ul> 2058 2033 <h3 id="rfc.section.7.2.4"><a href="#rfc.section.7.2.4">7.2.4</a> <a id="connection.premature" href="#connection.premature">Client Behavior if Server Prematurely Closes Connection</a></h3> 2059 <p id="rfc.section.7.2.4.p.1">If an HTTP/1.1 client sends a request which includes a request body, but which does not include an Expect request-header field2060 with the "100-continue" expectation, and if the client is not directly connected to an HTTP/1.1 origin server, and if the2061 clientsees the connection close before receiving a status line from the server, the client <em class="bcp14">SHOULD</em> retry the request. If the client does retry this request, it <em class="bcp14">MAY</em> use the following "binary exponential backoff" algorithm to be assured of obtaining a reliable response:2034 <p id="rfc.section.7.2.4.p.1">If an HTTP/1.1 client sends a request which includes a request body, but which does not include an Expect header field with 2035 the "100-continue" expectation, and if the client is not directly connected to an HTTP/1.1 origin server, and if the client 2036 sees the connection close before receiving a status line from the server, the client <em class="bcp14">SHOULD</em> retry the request. If the client does retry this request, it <em class="bcp14">MAY</em> use the following "binary exponential backoff" algorithm to be assured of obtaining a reliable response: 2062 2037 </p> 2063 2038 <ol> 2064 2039 <li>Initiate a new connection to the server</li> 2065 <li>Transmit the request- header fields</li>2040 <li>Transmit the request-line, header fields, and the CRLF that indicates the end of header fields.</li> 2066 2041 <li>Initialize a variable R to the estimated round-trip time to the server (e.g., based on the time it took to establish the connection), 2067 2042 or to a constant value of 5 seconds if the round-trip time is not available. … … 2102 2077 <div id="rfc.iref.h.6"></div> 2103 2078 <h2 id="rfc.section.9.1"><a href="#rfc.section.9.1">9.1</a> <a id="header.connection" href="#header.connection">Connection</a></h2> 2104 <p id="rfc.section.9.1.p.1">The "Connection" general-header field allows the sender to specify options that are desired for that particular connection 2105 and <em class="bcp14">MUST NOT</em> be communicated by proxies over further connections. 2079 <p id="rfc.section.9.1.p.1">The "Connection" header field allows the sender to specify options that are desired for that particular connection and <em class="bcp14">MUST NOT</em> be communicated by proxies over further connections. 2106 2080 </p> 2107 2081 <p id="rfc.section.9.1.p.2">The Connection header field's value has the following grammar:</p> 2108 <div id="rfc.figure.u.5 8"></div><pre class="inline"><span id="rfc.iref.g.91"></span><span id="rfc.iref.g.92"></span><span id="rfc.iref.g.93"></span> <a href="#header.connection" class="smpl">Connection</a> = "Connection" ":" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#header.connection" class="smpl">Connection-v</a>2082 <div id="rfc.figure.u.55"></div><pre class="inline"><span id="rfc.iref.g.91"></span><span id="rfc.iref.g.92"></span><span id="rfc.iref.g.93"></span> <a href="#header.connection" class="smpl">Connection</a> = "Connection" ":" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#header.connection" class="smpl">Connection-v</a> 2109 2083 <a href="#header.connection" class="smpl">Connection-v</a> = 1#<a href="#header.connection" class="smpl">connection-token</a> 2110 2084 <a href="#header.connection" class="smpl">connection-token</a> = <a href="#rule.token.separators" class="smpl">token</a> … … 2114 2088 header field might not be sent if there are no parameters associated with that connection option. 2115 2089 </p> 2116 <p id="rfc.section.9.1.p.5">Message header fields listed in the Connection header field <em class="bcp14">MUST NOT</em> include end-to-end header fields, such as Cache-Control .2090 <p id="rfc.section.9.1.p.5">Message header fields listed in the Connection header field <em class="bcp14">MUST NOT</em> include end-to-end header fields, such as Cache-Control (<a href="p6-cache.html#header.cache-control" title="Cache-Control">Section 3.2</a> of <a href="#Part6" id="rfc.xref.Part6.5"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>). 2117 2091 </p> 2118 2092 <p id="rfc.section.9.1.p.6">HTTP/1.1 defines the "close" connection option for the sender to signal that the connection will be closed after completion 2119 2093 of the response. For example, 2120 2094 </p> 2121 <div id="rfc.figure.u.5 9"></div><pre class="text"> Connection: close2095 <div id="rfc.figure.u.56"></div><pre class="text"> Connection: close 2122 2096 </pre><p id="rfc.section.9.1.p.8">in either the request or the response header fields indicates that the connection <em class="bcp14">SHOULD NOT</em> be considered "persistent" (<a href="#persistent.connections" title="Persistent Connections">Section 7.1</a>) after the current request/response is complete. 2123 2097 </p> … … 2138 2112 body (not including any potential transfer-coding) that would have been sent in a 200 (OK) response. 2139 2113 </p> 2140 <div id="rfc.figure.u. 60"></div><pre class="inline"><span id="rfc.iref.g.94"></span><span id="rfc.iref.g.95"></span> <a href="#header.content-length" class="smpl">Content-Length</a> = "Content-Length" ":" <a href="#rule.whitespace" class="smpl">OWS</a> 1*<a href="#header.content-length" class="smpl">Content-Length-v</a>2114 <div id="rfc.figure.u.57"></div><pre class="inline"><span id="rfc.iref.g.94"></span><span id="rfc.iref.g.95"></span> <a href="#header.content-length" class="smpl">Content-Length</a> = "Content-Length" ":" <a href="#rule.whitespace" class="smpl">OWS</a> 1*<a href="#header.content-length" class="smpl">Content-Length-v</a> 2141 2115 <a href="#header.content-length" class="smpl">Content-Length-v</a> = 1*<a href="#core.rules" class="smpl">DIGIT</a> 2142 2116 </pre><p id="rfc.section.9.2.p.3">An example is</p> 2143 <div id="rfc.figure.u. 61"></div><pre class="text"> Content-Length: 34952117 <div id="rfc.figure.u.58"></div><pre class="text"> Content-Length: 3495 2144 2118 </pre><p id="rfc.section.9.2.p.5">Implementations <em class="bcp14">SHOULD</em> use this field to indicate the message-body length when no transfer-coding is being applied and the payload's body length 2145 2119 can be determined prior to being transferred. <a href="#message.body" title="Message Body">Section 3.3</a> describes how recipients determine the length of a message-body. … … 2152 2126 <div id="rfc.iref.h.8"></div> 2153 2127 <h2 id="rfc.section.9.3"><a href="#rfc.section.9.3">9.3</a> <a id="header.date" href="#header.date">Date</a></h2> 2154 <p id="rfc.section.9.3.p.1">The "Date" general-header field represents the date and time at which the message was originated, having the same semantics2155 as theOrigination Date Field (orig-date) defined in <a href="http://tools.ietf.org/html/rfc5322#section-3.6.1">Section 3.6.1</a> of <a href="#RFC5322" id="rfc.xref.RFC5322.4"><cite title="Internet Message Format">[RFC5322]</cite></a>. The field value is an HTTP-date, as described in <a href="#date.time.formats.full.date" title="Date/Time Formats: Full Date">Section 6.1</a>; it <em class="bcp14">MUST</em> be sent in rfc1123-date format.2156 </p> 2157 <div id="rfc.figure.u. 62"></div><pre class="inline"><span id="rfc.iref.g.96"></span><span id="rfc.iref.g.97"></span> <a href="#header.date" class="smpl">Date</a> = "Date" ":" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#header.date" class="smpl">Date-v</a>2128 <p id="rfc.section.9.3.p.1">The "Date" header field represents the date and time at which the message was originated, having the same semantics as the 2129 Origination Date Field (orig-date) defined in <a href="http://tools.ietf.org/html/rfc5322#section-3.6.1">Section 3.6.1</a> of <a href="#RFC5322" id="rfc.xref.RFC5322.4"><cite title="Internet Message Format">[RFC5322]</cite></a>. The field value is an HTTP-date, as described in <a href="#date.time.formats.full.date" title="Date/Time Formats: Full Date">Section 6.1</a>; it <em class="bcp14">MUST</em> be sent in rfc1123-date format. 2130 </p> 2131 <div id="rfc.figure.u.59"></div><pre class="inline"><span id="rfc.iref.g.96"></span><span id="rfc.iref.g.97"></span> <a href="#header.date" class="smpl">Date</a> = "Date" ":" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#header.date" class="smpl">Date-v</a> 2158 2132 <a href="#header.date" class="smpl">Date-v</a> = <a href="#date.time.formats.full.date" class="smpl">HTTP-date</a> 2159 2133 </pre><p id="rfc.section.9.3.p.3">An example is</p> 2160 <div id="rfc.figure.u.6 3"></div><pre class="text"> Date: Tue, 15 Nov 1994 08:12:31 GMT2134 <div id="rfc.figure.u.60"></div><pre class="text"> Date: Tue, 15 Nov 1994 08:12:31 GMT 2161 2135 </pre><p id="rfc.section.9.3.p.5">Origin servers <em class="bcp14">MUST</em> include a Date header field in all responses, except in these cases: 2162 2136 </p> … … 2189 2163 <div id="rfc.iref.h.10"></div> 2190 2164 <h2 id="rfc.section.9.4"><a href="#rfc.section.9.4">9.4</a> <a id="header.host" href="#header.host">Host</a></h2> 2191 <p id="rfc.section.9.4.p.1">The "Host" request-header field specifies the Internet host and port number of the resource being requested, allowing the2192 or igin server or gateway to differentiate between internally-ambiguous URLs, such as the root "/" URL of a server for multiple2193 host nameson a single IP address.2165 <p id="rfc.section.9.4.p.1">The "Host" header field specifies the Internet host and port number of the resource being requested, allowing the origin server 2166 or gateway to differentiate between internally-ambiguous URLs, such as the root "/" URL of a server for multiple host names 2167 on a single IP address. 2194 2168 </p> 2195 2169 <p id="rfc.section.9.4.p.2">The Host field value <em class="bcp14">MUST</em> represent the naming authority of the origin server or gateway given by the original URL obtained from the user or referring 2196 2170 resource (generally an http URI, as described in <a href="#http.uri" title="http URI scheme">Section 2.6.1</a>). 2197 2171 </p> 2198 <div id="rfc.figure.u.6 4"></div><pre class="inline"><span id="rfc.iref.g.98"></span><span id="rfc.iref.g.99"></span> <a href="#header.host" class="smpl">Host</a> = "Host" ":" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#header.host" class="smpl">Host-v</a>2172 <div id="rfc.figure.u.61"></div><pre class="inline"><span id="rfc.iref.g.98"></span><span id="rfc.iref.g.99"></span> <a href="#header.host" class="smpl">Host</a> = "Host" ":" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#header.host" class="smpl">Host-v</a> 2199 2173 <a href="#header.host" class="smpl">Host-v</a> = <a href="#uri" class="smpl">uri-host</a> [ ":" <a href="#uri" class="smpl">port</a> ] ; <a href="#http.uri" title="http URI scheme">Section 2.6.1</a> 2200 2174 </pre><p id="rfc.section.9.4.p.4">A "host" without any trailing port information implies the default port for the service requested (e.g., "80" for an HTTP 2201 2175 URL). For example, a request on the origin server for <http://www.example.org/pub/WWW/> would properly include: 2202 2176 </p> 2203 <div id="rfc.figure.u.6 5"></div><pre class="text2">GET /pub/WWW/ HTTP/1.12177 <div id="rfc.figure.u.62"></div><pre class="text2">GET /pub/WWW/ HTTP/1.1 2204 2178 Host: www.example.org 2205 2179 </pre><p id="rfc.section.9.4.p.6">A client <em class="bcp14">MUST</em> include a Host header field in all HTTP/1.1 request messages. If the requested URI does not include an Internet host name … … 2212 2186 <div id="rfc.iref.h.11"></div> 2213 2187 <h2 id="rfc.section.9.5"><a href="#rfc.section.9.5">9.5</a> <a id="header.te" href="#header.te">TE</a></h2> 2214 <p id="rfc.section.9.5.p.1">The "TE" request-header field indicates what extension transfer-codings it is willing to accept in the response, and whether2215 or notit is willing to accept trailer fields in a chunked transfer-coding.2188 <p id="rfc.section.9.5.p.1">The "TE" header field indicates what extension transfer-codings it is willing to accept in the response, and whether or not 2189 it is willing to accept trailer fields in a chunked transfer-coding. 2216 2190 </p> 2217 2191 <p id="rfc.section.9.5.p.2">Its value consists of the keyword "trailers" and/or a comma-separated list of extension transfer-coding names with optional 2218 2192 accept parameters (as described in <a href="#transfer.codings" title="Transfer Codings">Section 6.2</a>). 2219 2193 </p> 2220 <div id="rfc.figure.u.6 6"></div><pre class="inline"><span id="rfc.iref.g.100"></span><span id="rfc.iref.g.101"></span><span id="rfc.iref.g.102"></span><span id="rfc.iref.g.103"></span><span id="rfc.iref.g.104"></span> <a href="#header.te" class="smpl">TE</a> = "TE" ":" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#header.te" class="smpl">TE-v</a>2194 <div id="rfc.figure.u.63"></div><pre class="inline"><span id="rfc.iref.g.100"></span><span id="rfc.iref.g.101"></span><span id="rfc.iref.g.102"></span><span id="rfc.iref.g.103"></span><span id="rfc.iref.g.104"></span> <a href="#header.te" class="smpl">TE</a> = "TE" ":" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#header.te" class="smpl">TE-v</a> 2221 2195 <a href="#header.te" class="smpl">TE-v</a> = #<a href="#header.te" class="smpl">t-codings</a> 2222 2196 <a href="#header.te" class="smpl">t-codings</a> = "trailers" / ( <a href="#transfer.codings" class="smpl">transfer-extension</a> [ <a href="#header.te" class="smpl">te-params</a> ] ) … … 2227 2201 </p> 2228 2202 <p id="rfc.section.9.5.p.5">Examples of its use are:</p> 2229 <div id="rfc.figure.u.6 7"></div><pre class="text"> TE: deflate2203 <div id="rfc.figure.u.64"></div><pre class="text"> TE: deflate 2230 2204 TE: 2231 2205 TE: trailers, deflate;q=0.5 … … 2261 2235 <div id="rfc.iref.h.12"></div> 2262 2236 <h2 id="rfc.section.9.6"><a href="#rfc.section.9.6">9.6</a> <a id="header.trailer" href="#header.trailer">Trailer</a></h2> 2263 <p id="rfc.section.9.6.p.1">The "Trailer" general-header field indicates that the given set of header fields is present in the trailer of a message encoded2264 withchunked transfer-coding.2265 </p> 2266 <div id="rfc.figure.u.6 8"></div><pre class="inline"><span id="rfc.iref.g.105"></span><span id="rfc.iref.g.106"></span> <a href="#header.trailer" class="smpl">Trailer</a> = "Trailer" ":" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#header.trailer" class="smpl">Trailer-v</a>2237 <p id="rfc.section.9.6.p.1">The "Trailer" header field indicates that the given set of header fields is present in the trailer of a message encoded with 2238 chunked transfer-coding. 2239 </p> 2240 <div id="rfc.figure.u.65"></div><pre class="inline"><span id="rfc.iref.g.105"></span><span id="rfc.iref.g.106"></span> <a href="#header.trailer" class="smpl">Trailer</a> = "Trailer" ":" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#header.trailer" class="smpl">Trailer-v</a> 2267 2241 <a href="#header.trailer" class="smpl">Trailer-v</a> = 1#<a href="#header.fields" class="smpl">field-name</a> 2268 2242 </pre><p id="rfc.section.9.6.p.3">An HTTP/1.1 message <em class="bcp14">SHOULD</em> include a Trailer header field in a message using chunked transfer-coding with a non-empty trailer. Doing so allows the recipient … … 2281 2255 <div id="rfc.iref.h.13"></div> 2282 2256 <h2 id="rfc.section.9.7"><a href="#rfc.section.9.7">9.7</a> <a id="header.transfer-encoding" href="#header.transfer-encoding">Transfer-Encoding</a></h2> 2283 <p id="rfc.section.9.7.p.1">The "Transfer-Encoding" general-header field indicates what transfer-codings (if any) have been applied to the message body.2284 It differs from Content-Encoding (<a href="p3-payload.html#content.codings" title="Content Codings">Section 2.2</a> of <a href="#Part3" id="rfc.xref.Part3.7"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>) in that transfer-codings are a property of the message (and therefore are removed by intermediaries), whereas content-codings2257 <p id="rfc.section.9.7.p.1">The "Transfer-Encoding" header field indicates what transfer-codings (if any) have been applied to the message body. It differs 2258 from Content-Encoding (<a href="p3-payload.html#content.codings" title="Content Codings">Section 2.2</a> of <a href="#Part3" id="rfc.xref.Part3.5"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>) in that transfer-codings are a property of the message (and therefore are removed by intermediaries), whereas content-codings 2285 2259 are not. 2286 2260 </p> 2287 <div id="rfc.figure.u.6 9"></div><pre class="inline"><span id="rfc.iref.g.107"></span><span id="rfc.iref.g.108"></span> <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a> = "Transfer-Encoding" ":" <a href="#rule.whitespace" class="smpl">OWS</a>2261 <div id="rfc.figure.u.66"></div><pre class="inline"><span id="rfc.iref.g.107"></span><span id="rfc.iref.g.108"></span> <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a> = "Transfer-Encoding" ":" <a href="#rule.whitespace" class="smpl">OWS</a> 2288 2262 <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding-v</a> 2289 2263 <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding-v</a> = 1#<a href="#transfer.codings" class="smpl">transfer-coding</a> 2290 2264 </pre><p id="rfc.section.9.7.p.3">Transfer-codings are defined in <a href="#transfer.codings" title="Transfer Codings">Section 6.2</a>. An example is: 2291 2265 </p> 2292 <div id="rfc.figure.u. 70"></div><pre class="text"> Transfer-Encoding: chunked2266 <div id="rfc.figure.u.67"></div><pre class="text"> Transfer-Encoding: chunked 2293 2267 </pre><p id="rfc.section.9.7.p.5">If multiple encodings have been applied to a representation, the transfer-codings <em class="bcp14">MUST</em> be listed in the order in which they were applied. Additional information about the encoding parameters <em class="bcp14">MAY</em> be provided by other header fields not defined by this specification. 2294 2268 </p> … … 2297 2271 <div id="rfc.iref.h.14"></div> 2298 2272 <h2 id="rfc.section.9.8"><a href="#rfc.section.9.8">9.8</a> <a id="header.upgrade" href="#header.upgrade">Upgrade</a></h2> 2299 <p id="rfc.section.9.8.p.1">The "Upgrade" general-header field allows the client to specify what additional communication protocols it would like to use,2300 if theserver chooses to switch protocols. Servers can use it to indicate what protocols they are willing to switch to.2301 </p> 2302 <div id="rfc.figure.u. 71"></div><pre class="inline"><span id="rfc.iref.g.109"></span><span id="rfc.iref.g.110"></span> <a href="#header.upgrade" class="smpl">Upgrade</a> = "Upgrade" ":" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#header.upgrade" class="smpl">Upgrade-v</a>2273 <p id="rfc.section.9.8.p.1">The "Upgrade" header field allows the client to specify what additional communication protocols it would like to use, if the 2274 server chooses to switch protocols. Servers can use it to indicate what protocols they are willing to switch to. 2275 </p> 2276 <div id="rfc.figure.u.68"></div><pre class="inline"><span id="rfc.iref.g.109"></span><span id="rfc.iref.g.110"></span> <a href="#header.upgrade" class="smpl">Upgrade</a> = "Upgrade" ":" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#header.upgrade" class="smpl">Upgrade-v</a> 2303 2277 <a href="#header.upgrade" class="smpl">Upgrade-v</a> = 1#<a href="#product.tokens" class="smpl">product</a> 2304 2278 </pre><p id="rfc.section.9.8.p.3">For example,</p> 2305 <div id="rfc.figure.u. 72"></div><pre class="text"> Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x112279 <div id="rfc.figure.u.69"></div><pre class="text"> Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11 2306 2280 </pre><p id="rfc.section.9.8.p.5">The Upgrade header field is intended to provide a simple mechanism for transition from HTTP/1.1 to some other, incompatible 2307 2281 protocol. It does so by allowing the client to advertise its desire to use another protocol, such as a later version of HTTP … … 2319 2293 </p> 2320 2294 <p id="rfc.section.9.8.p.8">The Upgrade header field cannot be used to indicate a switch to a protocol on a different connection. For that purpose, it 2321 is more appropriate to use a 3xx redirection response (<a href="p2-semantics.html#status.3xx" title="Redirection 3xx">Section 8.3</a> of <a href="#Part2" id="rfc.xref.Part2.1 2"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).2295 is more appropriate to use a 3xx redirection response (<a href="p2-semantics.html#status.3xx" title="Redirection 3xx">Section 8.3</a> of <a href="#Part2" id="rfc.xref.Part2.10"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). 2322 2296 </p> 2323 2297 <p id="rfc.section.9.8.p.9">Servers <em class="bcp14">MUST</em> include the "Upgrade" header field in 101 (Switching Protocols) responses to indicate which protocol(s) are being switched … … 2353 2327 <div id="rfc.iref.h.15"></div> 2354 2328 <h2 id="rfc.section.9.9"><a href="#rfc.section.9.9">9.9</a> <a id="header.via" href="#header.via">Via</a></h2> 2355 <p id="rfc.section.9.9.p.1">The "Via" general-header field <em class="bcp14">MUST</em> be used by gateways and proxies to indicate the intermediate protocols and recipients between the user agent and the server2329 <p id="rfc.section.9.9.p.1">The "Via" header field <em class="bcp14">MUST</em> be used by gateways and proxies to indicate the intermediate protocols and recipients between the user agent and the server 2356 2330 on requests, and between the origin server and the client on responses. It is analogous to the "Received" field defined in <a href="http://tools.ietf.org/html/rfc5322#section-3.6.7">Section 3.6.7</a> of <a href="#RFC5322" id="rfc.xref.RFC5322.5"><cite title="Internet Message Format">[RFC5322]</cite></a> and is intended to be used for tracking message forwards, avoiding request loops, and identifying the protocol capabilities 2357 2331 of all senders along the request/response chain. 2358 2332 </p> 2359 <div id="rfc.figure.u.7 3"></div><pre class="inline"><span id="rfc.iref.g.111"></span><span id="rfc.iref.g.112"></span><span id="rfc.iref.g.113"></span><span id="rfc.iref.g.114"></span><span id="rfc.iref.g.115"></span><span id="rfc.iref.g.116"></span><span id="rfc.iref.g.117"></span> <a href="#header.via" class="smpl">Via</a> = "Via" ":" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#header.via" class="smpl">Via-v</a>2333 <div id="rfc.figure.u.70"></div><pre class="inline"><span id="rfc.iref.g.111"></span><span id="rfc.iref.g.112"></span><span id="rfc.iref.g.113"></span><span id="rfc.iref.g.114"></span><span id="rfc.iref.g.115"></span><span id="rfc.iref.g.116"></span><span id="rfc.iref.g.117"></span> <a href="#header.via" class="smpl">Via</a> = "Via" ":" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#header.via" class="smpl">Via-v</a> 2360 2334 <a href="#header.via" class="smpl">Via-v</a> = 1#( <a href="#header.via" class="smpl">received-protocol</a> <a href="#rule.whitespace" class="smpl">RWS</a> <a href="#header.via" class="smpl">received-by</a> 2361 2335 [ <a href="#rule.whitespace" class="smpl">RWS</a> <a href="#rule.comment" class="smpl">comment</a> ] ) … … 2382 2356 server at www.example.com. The request received by www.example.com would then have the following Via header field: 2383 2357 </p> 2384 <div id="rfc.figure.u.7 4"></div><pre class="text"> Via: 1.0 fred, 1.1 p.example.net (Apache/1.1)2358 <div id="rfc.figure.u.71"></div><pre class="text"> Via: 1.0 fred, 1.1 p.example.net (Apache/1.1) 2385 2359 </pre><p id="rfc.section.9.9.p.9">Proxies and gateways used as a portal through a network firewall <em class="bcp14">SHOULD NOT</em>, by default, forward the names and ports of hosts within the firewall region. This information <em class="bcp14">SHOULD</em> only be propagated if explicitly enabled. If not enabled, the received-by host of any host behind the firewall <em class="bcp14">SHOULD</em> be replaced by an appropriate pseudonym for that host. 2386 2360 </p> … … 2388 2362 For example, 2389 2363 </p> 2390 <div id="rfc.figure.u.7 5"></div><pre class="text"> Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy2364 <div id="rfc.figure.u.72"></div><pre class="text"> Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy 2391 2365 </pre><p id="rfc.section.9.9.p.12">could be collapsed to</p> 2392 <div id="rfc.figure.u.7 6"></div><pre class="text"> Via: 1.0 ricky, 1.1 mertz, 1.0 lucy2366 <div id="rfc.figure.u.73"></div><pre class="text"> Via: 1.0 ricky, 1.1 mertz, 1.0 lucy 2393 2367 </pre><p id="rfc.section.9.9.p.14">Applications <em class="bcp14">SHOULD NOT</em> combine multiple entries unless they are all under the same organizational control and the hosts have already been replaced 2394 2368 by pseudonyms. Applications <em class="bcp14">MUST NOT</em> combine entries which have different received-protocol values. … … 2979 2953 </p> 2980 2954 <p id="rfc.section.A.p.4">The character set of a representation <em class="bcp14">SHOULD</em> be labeled as the lowest common denominator of the character codes used within that representation, with the exception that 2981 not labeling the representation is preferred over labeling the representation with the labels US-ASCII or ISO-8859-1. See <a href="#Part3" id="rfc.xref.Part3. 8"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>.2955 not labeling the representation is preferred over labeling the representation with the labels US-ASCII or ISO-8859-1. See <a href="#Part3" id="rfc.xref.Part3.6"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>. 2982 2956 </p> 2983 2957 <p id="rfc.section.A.p.5">Additional rules for requirements on parsing and encoding of dates and other potential problems with date encodings include:</p> … … 3028 3002 <p id="rfc.section.B.1.p.1">This section summarizes major differences between versions HTTP/1.0 and HTTP/1.1.</p> 3029 3003 <h3 id="rfc.section.B.1.1"><a href="#rfc.section.B.1.1">B.1.1</a> <a id="changes.to.simplify.multi-homed.web.servers.and.conserve.ip.addresses" href="#changes.to.simplify.multi-homed.web.servers.and.conserve.ip.addresses">Changes to Simplify Multi-homed Web Servers and Conserve IP Addresses</a></h3> 3030 <p id="rfc.section.B.1.1.p.1">The requirements that clients and servers support the Host request-header field (<a href="#header.host" id="rfc.xref.header.host.3" title="Host">Section 9.4</a>), report an error if it is missing from an HTTP/1.1 request, and accept absolute URIs (<a href="#request-target" title="request-target">Section 4.1.2</a>) are among the most important changes defined by this specification.3004 <p id="rfc.section.B.1.1.p.1">The requirements that clients and servers support the Host header field (<a href="#header.host" id="rfc.xref.header.host.3" title="Host">Section 9.4</a>), report an error if it is missing from an HTTP/1.1 request, and accept absolute URIs (<a href="#request-target" title="request-target">Section 4.1.2</a>) are among the most important changes defined by this specification. 3031 3005 </p> 3032 3006 <p id="rfc.section.B.1.1.p.2">Older HTTP/1.0 clients assumed a one-to-one relationship of IP addresses and servers; there was no other established mechanism … … 3040 3014 </p> 3041 3015 <ul> 3042 <li>Both clients and servers <em class="bcp14">MUST</em> support the Host request-header field.3016 <li>Both clients and servers <em class="bcp14">MUST</em> support the Host header field. 3043 3017 </li> 3044 3018 <li>A client that sends an HTTP/1.1 request <em class="bcp14">MUST</em> send a Host header field. 3045 3019 </li> 3046 <li>Servers <em class="bcp14">MUST</em> report a 400 (Bad Request) error if an HTTP/1.1 request does not include a Host request-header field.3020 <li>Servers <em class="bcp14">MUST</em> report a 400 (Bad Request) error if an HTTP/1.1 request does not include a Host header field. 3047 3021 </li> 3048 3022 <li>Servers <em class="bcp14">MUST</em> accept absolute URIs. … … 3095 3069 </p> 3096 3070 <h1 id="rfc.section.C"><a href="#rfc.section.C">C.</a> <a id="collected.abnf" href="#collected.abnf">Collected ABNF</a></h1> 3097 <div id="rfc.figure.u.77"></div> <pre class="inline"><a href="#rule.whitespace" class="smpl">BWS</a> = OWS 3098 3099 <a href="#abnf.dependencies" class="smpl">Cache-Control</a> = <Cache-Control, defined in [Part6], Section 3.4> 3071 <div id="rfc.figure.u.74"></div> <pre class="inline"><a href="#rule.whitespace" class="smpl">BWS</a> = OWS 3072 3100 3073 <a href="#chunked.encoding" class="smpl">Chunked-Body</a> = *chunk last-chunk trailer-part CRLF 3101 3074 <a href="#header.connection" class="smpl">Connection</a> = "Connection:" OWS Connection-v … … 3118 3091 <a href="#header.host" class="smpl">Host-v</a> = uri-host [ ":" port ] 3119 3092 3120 <a href="#abnf.dependencies" class="smpl">MIME-Version</a> = <MIME-Version, defined in [Part3], Appendix A.1>3121 3093 <a href="#method" class="smpl">Method</a> = token 3122 3094 3123 3095 <a href="#rule.whitespace" class="smpl">OWS</a> = *( [ obs-fold ] WSP ) 3124 3125 <a href="#abnf.dependencies" class="smpl">Pragma</a> = <Pragma, defined in [Part6], Section 3.4>3126 3096 3127 3097 <a href="#rule.whitespace" class="smpl">RWS</a> = 1*( [ obs-fold ] WSP ) … … 3150 3120 ] *( OWS "," [ OWS received-protocol RWS received-by [ RWS comment ] 3151 3121 ] ) 3152 3153 <a href="#abnf.dependencies" class="smpl">Warning</a> = <Warning, defined in [Part6], Section 3.6>3154 3122 3155 3123 <a href="#uri" class="smpl">absolute-URI</a> = <absolute-URI, defined in [RFC3986], Section 4.3> … … 3246 3214 <a href="#header.via" class="smpl">received-protocol</a> = [ protocol-name "/" ] protocol-version 3247 3215 <a href="#uri" class="smpl">relative-part</a> = <relative-part, defined in [RFC3986], Section 4.2> 3248 <a href="#abnf.dependencies" class="smpl">request-header</a> = <request-header, defined in [Part2], Section 3>3249 3216 <a href="#request-target" class="smpl">request-target</a> = "*" / absolute-URI / ( path-absolute [ "?" query ] ) 3250 3217 / authority 3251 <a href="#abnf.dependencies" class="smpl">response-header</a> = <response-header, defined in [Part2], Section 5>3252 3218 <a href="#preferred.date.format" class="smpl">rfc1123-date</a> = day-name "," SP date1 SP time-of-day SP GMT 3253 3219 <a href="#obsolete.date.formats" class="smpl">rfc850-date</a> = day-name-l "," SP date2 SP time-of-day SP GMT … … 3278 3244 3279 3245 <a href="#preferred.date.format" class="smpl">year</a> = 4DIGIT 3280 </pre> <div id="rfc.figure.u.78"></div> 3281 <p>ABNF diagnostics:</p><pre class="inline">; Cache-Control defined but not used 3282 ; Chunked-Body defined but not used 3246 </pre> <div id="rfc.figure.u.75"></div> 3247 <p>ABNF diagnostics:</p><pre class="inline">; Chunked-Body defined but not used 3283 3248 ; Connection defined but not used 3284 3249 ; Content-Length defined but not used … … 3286 3251 ; HTTP-message defined but not used 3287 3252 ; Host defined but not used 3288 ; MIME-Version defined but not used3289 ; Pragma defined but not used3290 3253 ; Request defined but not used 3291 3254 ; Response defined but not used … … 3296 3259 ; Upgrade defined but not used 3297 3260 ; Via defined but not used 3298 ; Warning defined but not used3299 3261 ; http-URI defined but not used 3300 3262 ; https-URI defined but not used 3301 3263 ; partial-URI defined but not used 3302 ; request-header defined but not used3303 ; response-header defined but not used3304 3264 ; special defined but not used 3305 3265 </pre><h1 id="rfc.section.D"><a href="#rfc.section.D">D.</a> <a id="change.log" href="#change.log">Change Log (to be removed by RFC Editor before publication)</a></h1> … … 3836 3796 <li><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul> 3837 3797 <li><em>Pad1995</em> <a href="#rfc.xref.Pad1995.1">7.1.1</a>, <a href="#Pad1995"><b>13.2</b></a></li> 3838 <li><em>Part2</em> <a href="#rfc.xref.Part2.1">1.2.3</a>, <a href="#rfc.xref.Part2.2">1.2.3</a>, <a href="#rfc.xref.Part2.3">4.1.2</a>, <a href="#rfc.xref.Part2.4">4.1.2</a>, <a href="#rfc.xref.Part2.5">5.1.1</a>, <a href="#rfc.xref.Part2.6">7.1.2.2</a>, <a href="#rfc.xref.Part2.7">7.1.4</a>, <a href="#rfc.xref.Part2.8">7.2.3</a>, <a href="#rfc.xref.Part2.9">7.2.3</a>, <a href="#rfc.xref.Part2.10">7.2.3</a>, <a href="#rfc.xref.Part2.11">7.2.3</a>, <a href="#rfc.xref.Part2.12">9.8</a>, <a href="#Part2"><b>13.1</b></a><ul> 3839 <li><em>Section 3</em> <a href="#rfc.xref.Part2.1">1.2.3</a></li> 3840 <li><em>Section 5</em> <a href="#rfc.xref.Part2.2">1.2.3</a></li> 3841 <li><em>Section 7.1.2</em> <a href="#rfc.xref.Part2.6">7.1.2.2</a>, <a href="#rfc.xref.Part2.7">7.1.4</a></li> 3842 <li><em>Section 7.9</em> <a href="#rfc.xref.Part2.3">4.1.2</a></li> 3843 <li><em>Section 8</em> <a href="#rfc.xref.Part2.5">5.1.1</a></li> 3844 <li><em>Section 8.1.1</em> <a href="#rfc.xref.Part2.8">7.2.3</a></li> 3845 <li><em>Section 8.1</em> <a href="#rfc.xref.Part2.11">7.2.3</a></li> 3846 <li><em>Section 8.3</em> <a href="#rfc.xref.Part2.12">9.8</a></li> 3847 <li><em>Section 8.4.15</em> <a href="#rfc.xref.Part2.4">4.1.2</a></li> 3848 <li><em>Section 9.2</em> <a href="#rfc.xref.Part2.9">7.2.3</a>, <a href="#rfc.xref.Part2.10">7.2.3</a></li> 3798 <li><em>Part2</em> <a href="#rfc.xref.Part2.1">4.1.2</a>, <a href="#rfc.xref.Part2.2">4.1.2</a>, <a href="#rfc.xref.Part2.3">5.1.1</a>, <a href="#rfc.xref.Part2.4">7.1.2.2</a>, <a href="#rfc.xref.Part2.5">7.1.4</a>, <a href="#rfc.xref.Part2.6">7.2.3</a>, <a href="#rfc.xref.Part2.7">7.2.3</a>, <a href="#rfc.xref.Part2.8">7.2.3</a>, <a href="#rfc.xref.Part2.9">7.2.3</a>, <a href="#rfc.xref.Part2.10">9.8</a>, <a href="#Part2"><b>13.1</b></a><ul> 3799 <li><em>Section 7.1.2</em> <a href="#rfc.xref.Part2.4">7.1.2.2</a>, <a href="#rfc.xref.Part2.5">7.1.4</a></li> 3800 <li><em>Section 7.9</em> <a href="#rfc.xref.Part2.1">4.1.2</a></li> 3801 <li><em>Section 8</em> <a href="#rfc.xref.Part2.3">5.1.1</a></li> 3802 <li><em>Section 8.1.1</em> <a href="#rfc.xref.Part2.6">7.2.3</a></li> 3803 <li><em>Section 8.1</em> <a href="#rfc.xref.Part2.9">7.2.3</a></li> 3804 <li><em>Section 8.3</em> <a href="#rfc.xref.Part2.10">9.8</a></li> 3805 <li><em>Section 8.4.15</em> <a href="#rfc.xref.Part2.2">4.1.2</a></li> 3806 <li><em>Section 9.2</em> <a href="#rfc.xref.Part2.7">7.2.3</a>, <a href="#rfc.xref.Part2.8">7.2.3</a></li> 3849 3807 </ul> 3850 3808 </li> 3851 <li><em>Part3</em> <a href="#rfc.xref.Part3.1">1</a>, <a href="#rfc.xref.Part3.2"> 1.2.3</a>, <a href="#rfc.xref.Part3.3">3.4</a>, <a href="#rfc.xref.Part3.4">6.2.3</a>, <a href="#rfc.xref.Part3.5">6.4</a>, <a href="#rfc.xref.Part3.6">7.1.3.2</a>, <a href="#rfc.xref.Part3.7">9.7</a>, <a href="#Part3"><b>13.1</b></a>, <a href="#rfc.xref.Part3.8">A</a><ul>3852 <li><em>Section 2.2</em> <a href="#rfc.xref.Part3. 4">6.2.3</a>, <a href="#rfc.xref.Part3.7">9.7</a></li>3853 <li><em>Section 5</em> <a href="#rfc.xref.Part3. 5">6.4</a></li>3809 <li><em>Part3</em> <a href="#rfc.xref.Part3.1">1</a>, <a href="#rfc.xref.Part3.2">6.2.3</a>, <a href="#rfc.xref.Part3.3">6.4</a>, <a href="#rfc.xref.Part3.4">7.1.3.2</a>, <a href="#rfc.xref.Part3.5">9.7</a>, <a href="#Part3"><b>13.1</b></a>, <a href="#rfc.xref.Part3.6">A</a><ul> 3810 <li><em>Section 2.2</em> <a href="#rfc.xref.Part3.2">6.2.3</a>, <a href="#rfc.xref.Part3.5">9.7</a></li> 3811 <li><em>Section 5</em> <a href="#rfc.xref.Part3.3">6.4</a></li> 3854 3812 <li><em>Appendix A</em> <a href="#rfc.xref.Part3.1">1</a></li> 3855 <li><em>Appendix A.1</em> <a href="#rfc.xref.Part3.2">1.2.3</a>, <a href="#rfc.xref.Part3.3">3.4</a></li>3856 3813 </ul> 3857 3814 </li> 3858 <li><em>Part6</em> <a href="#rfc.xref.Part6.1"> 1.2.3</a>, <a href="#rfc.xref.Part6.2">1.2.3</a>, <a href="#rfc.xref.Part6.3">1.2.3</a>, <a href="#rfc.xref.Part6.4">2.4</a>, <a href="#rfc.xref.Part6.5">3.3</a>, <a href="#rfc.xref.Part6.6">3.4</a>, <a href="#rfc.xref.Part6.7">3.4</a>, <a href="#rfc.xref.Part6.8">7.1.3.2</a>, <a href="#Part6"><b>13.1</b></a><ul>3859 <li><em>Section 2</em> <a href="#rfc.xref.Part6. 4">2.4</a></li>3860 <li><em>Section 2.1.1</em> <a href="#rfc.xref.Part6. 5">3.3</a></li>3861 <li><em>Section 3. 4</em> <a href="#rfc.xref.Part6.1">1.2.3</a>, <a href="#rfc.xref.Part6.2">1.2.3</a>, <a href="#rfc.xref.Part6.6">3.4</a></li>3862 <li><em>Section 3.6</em> <a href="#rfc.xref.Part6. 3">1.2.3</a>, <a href="#rfc.xref.Part6.7">3.4</a>, <a href="#rfc.xref.Part6.8">7.1.3.2</a></li>3815 <li><em>Part6</em> <a href="#rfc.xref.Part6.1">2.4</a>, <a href="#rfc.xref.Part6.2">2.6.2</a>, <a href="#rfc.xref.Part6.3">3.3</a>, <a href="#rfc.xref.Part6.4">7.1.3.2</a>, <a href="#rfc.xref.Part6.5">9.1</a>, <a href="#Part6"><b>13.1</b></a><ul> 3816 <li><em>Section 2</em> <a href="#rfc.xref.Part6.1">2.4</a></li> 3817 <li><em>Section 2.1.1</em> <a href="#rfc.xref.Part6.3">3.3</a></li> 3818 <li><em>Section 3.2</em> <a href="#rfc.xref.Part6.2">2.6.2</a>, <a href="#rfc.xref.Part6.5">9.1</a></li> 3819 <li><em>Section 3.6</em> <a href="#rfc.xref.Part6.4">7.1.3.2</a></li> 3863 3820 </ul> 3864 3821 </li> -
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 -
draft-ietf-httpbis/latest/p3-payload.html
r1162 r1164 1020 1020 <li>It might limit a public cache's ability to use the same response for multiple user's requests.</li> 1021 1021 </ol> 1022 <p id="rfc.section.5.1.p.4">HTTP/1.1 includes the following request-header fields for enabling server-driven negotiation through description of user agent1023 capabilities and user preferences: Accept (<a href="#header.accept" id="rfc.xref.header.accept.2" title="Accept">Section 6.1</a>), Accept-Charset (<a href="#header.accept-charset" id="rfc.xref.header.accept-charset.1" title="Accept-Charset">Section 6.2</a>), Accept-Encoding (<a href="#header.accept-encoding" id="rfc.xref.header.accept-encoding.2" title="Accept-Encoding">Section 6.3</a>), Accept-Language (<a href="#header.accept-language" id="rfc.xref.header.accept-language.1" title="Accept-Language">Section 6.4</a>), and User-Agent (<a href="p2-semantics.html#header.user-agent" title="User-Agent">Section 9.9</a> of <a href="#Part2" id="rfc.xref.Part2.1"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). However, an origin server is not limited to these dimensions and <em class="bcp14">MAY</em> vary the response based on any aspect of the request, including information outside the request-header fields or within extension1024 header fields not defined by this specification.1022 <p id="rfc.section.5.1.p.4">HTTP/1.1 includes the following header fields for enabling server-driven negotiation through description of user agent capabilities 1023 and user preferences: Accept (<a href="#header.accept" id="rfc.xref.header.accept.2" title="Accept">Section 6.1</a>), Accept-Charset (<a href="#header.accept-charset" id="rfc.xref.header.accept-charset.1" title="Accept-Charset">Section 6.2</a>), Accept-Encoding (<a href="#header.accept-encoding" id="rfc.xref.header.accept-encoding.2" title="Accept-Encoding">Section 6.3</a>), Accept-Language (<a href="#header.accept-language" id="rfc.xref.header.accept-language.1" title="Accept-Language">Section 6.4</a>), and User-Agent (<a href="p2-semantics.html#header.user-agent" title="User-Agent">Section 9.9</a> of <a href="#Part2" id="rfc.xref.Part2.1"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). However, an origin server is not limited to these dimensions and <em class="bcp14">MAY</em> vary the response based on any aspect of the request, including aspects of the connection (e.g., IP address) or information 1024 within extension header fields not defined by this specification. 1025 1025 </p> 1026 1026 <div class="note" id="rfc.section.5.1.p.5"> … … 1054 1054 <div id="rfc.iref.h.1"></div> 1055 1055 <h2 id="rfc.section.6.1"><a href="#rfc.section.6.1">6.1</a> <a id="header.accept" href="#header.accept">Accept</a></h2> 1056 <p id="rfc.section.6.1.p.1">The "Accept" request-header field can be used by user agents to specify response media types that are acceptable. Accept header1057 fields can be used to indicate that the request is specifically limited to a small set of desired types, as in the case of1058 a requestfor an in-line image.1056 <p id="rfc.section.6.1.p.1">The "Accept" header field can be used by user agents to specify response media types that are acceptable. Accept header fields 1057 can be used to indicate that the request is specifically limited to a small set of desired types, as in the case of a request 1058 for an in-line image. 1059 1059 </p> 1060 1060 <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><span id="rfc.iref.g.14"></span><span id="rfc.iref.g.15"></span> <a href="#header.accept" class="smpl">Accept</a> = "Accept" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.accept" class="smpl">Accept-v</a> … … 1155 1155 <div id="rfc.iref.h.2"></div> 1156 1156 <h2 id="rfc.section.6.2"><a href="#rfc.section.6.2">6.2</a> <a id="header.accept-charset" href="#header.accept-charset">Accept-Charset</a></h2> 1157 <p id="rfc.section.6.2.p.1">The "Accept-Charset" request-header field can be used by user agents to indicate what response character sets are acceptable.1158 Thisfield allows clients capable of understanding more comprehensive or special-purpose character sets to signal that capability1157 <p id="rfc.section.6.2.p.1">The "Accept-Charset" header field can be used by user agents to indicate what response character sets are acceptable. This 1158 field allows clients capable of understanding more comprehensive or special-purpose character sets to signal that capability 1159 1159 to a server which is capable of representing documents in those character sets. 1160 1160 </p> … … 1179 1179 <div id="rfc.iref.h.3"></div> 1180 1180 <h2 id="rfc.section.6.3"><a href="#rfc.section.6.3">6.3</a> <a id="header.accept-encoding" href="#header.accept-encoding">Accept-Encoding</a></h2> 1181 <p id="rfc.section.6.3.p.1">The "Accept-Encoding" request-header field can be used by user agents to indicate what response content-codings (<a href="#content.codings" title="Content Codings">Section 2.2</a>) are acceptable in the response.1181 <p id="rfc.section.6.3.p.1">The "Accept-Encoding" header field can be used by user agents to indicate what response content-codings (<a href="#content.codings" title="Content Codings">Section 2.2</a>) are acceptable in the response. 1182 1182 </p> 1183 1183 <div id="rfc.figure.u.20"></div><pre class="inline"><span id="rfc.iref.g.18"></span><span id="rfc.iref.g.19"></span><span id="rfc.iref.g.20"></span> <a href="#header.accept-encoding" class="smpl">Accept-Encoding</a> = "Accept-Encoding" ":" <a href="#core.rules" class="smpl">OWS</a> … … 1230 1230 <div id="rfc.iref.h.4"></div> 1231 1231 <h2 id="rfc.section.6.4"><a href="#rfc.section.6.4">6.4</a> <a id="header.accept-language" href="#header.accept-language">Accept-Language</a></h2> 1232 <p id="rfc.section.6.4.p.1">The "Accept-Language" request-header field can be used by user agents to indicate the set of natural languages that are preferred1232 <p id="rfc.section.6.4.p.1">The "Accept-Language" header field can be used by user agents to indicate the set of natural languages that are preferred 1233 1233 in the response. Language tags are defined in <a href="#language.tags" title="Language Tags">Section 2.4</a>. 1234 1234 </p> … … 1546 1546 </p> 1547 1547 <h2 id="rfc.section.8.1"><a href="#rfc.section.8.1">8.1</a> <a id="privacy.issues.connected.to.accept.header.fields" href="#privacy.issues.connected.to.accept.header.fields">Privacy Issues Connected to Accept Header Fields</a></h2> 1548 <p id="rfc.section.8.1.p.1">Accept request-headers fields can reveal information about the user to all servers which are accessed. The Accept-Language1549 header field in particular can reveal information the user would consider to be of a private nature, because the understanding1550 ofparticular languages is often strongly correlated to the membership of a particular ethnic group. User agents which offer1548 <p id="rfc.section.8.1.p.1">Accept headers fields can reveal information about the user to all servers which are accessed. The Accept-Language header 1549 field in particular can reveal information the user would consider to be of a private nature, because the understanding of 1550 particular languages is often strongly correlated to the membership of a particular ethnic group. User agents which offer 1551 1551 the option to configure the contents of an Accept-Language header field to be sent in every request are strongly encouraged 1552 1552 to let the configuration process include a message which makes the user aware of the loss of privacy involved. … … 1554 1554 <p id="rfc.section.8.1.p.2">An approach that limits the loss of privacy would be for a user agent to omit the sending of Accept-Language header fields 1555 1555 by default, and to ask the user whether or not to start sending Accept-Language header fields to a server if it detects, by 1556 looking for any Vary response-header fields generated by the server, that such sending could improve the quality of service.1556 looking for any Vary header fields generated by the server, that such sending could improve the quality of service. 1557 1557 </p> 1558 1558 <p id="rfc.section.8.1.p.3">Elaborate user-customized accept header fields sent in every request, in particular if these include quality values, can be … … 1762 1762 <div id="rfc.iref.h.10"></div> 1763 1763 <h2 id="rfc.section.A.1"><a href="#rfc.section.A.1">A.1</a> <a id="mime-version" href="#mime-version">MIME-Version</a></h2> 1764 <p id="rfc.section.A.1.p.1">HTTP is not a MIME-compliant protocol. However, HTTP/1.1 messages <em class="bcp14">MAY</em> include a single MIME-Version general-header field to indicate what version of the MIME protocol was used to construct the 1765 message. Use of the MIME-Version header field indicates that the message is in full compliance with the MIME protocol (as 1766 defined in <a href="#RFC2045" id="rfc.xref.RFC2045.2"><cite title="Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies">[RFC2045]</cite></a>). Proxies/gateways are responsible for ensuring full compliance (where possible) when exporting HTTP messages to strict MIME 1764 <p id="rfc.section.A.1.p.1">HTTP is not a MIME-compliant protocol. However, HTTP/1.1 messages <em class="bcp14">MAY</em> include a single MIME-Version header field to indicate what version of the MIME protocol was used to construct the message. 1765 Use of the MIME-Version header field indicates that the message is in full compliance with the MIME protocol (as defined in <a href="#RFC2045" id="rfc.xref.RFC2045.2"><cite title="Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies">[RFC2045]</cite></a>). Proxies/gateways are responsible for ensuring full compliance (where possible) when exporting HTTP messages to strict MIME 1767 1766 environments. 1768 1767 </p> -
draft-ietf-httpbis/latest/p4-conditional.html
r1162 r1164 605 605 <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 606 606 errata changes. A future draft will reorganize the sections to better reflect the content. In particular, the sections on 607 resource metadata will be discussed first and then followed by each conditional request -header field, concluding with a definition607 resource metadata will be discussed first and then followed by each conditional request header field, concluding with a definition 608 608 of precedence and the expectation of ordering strong validator checks before weak validator checks. It is likely that more 609 609 content from <a href="#Part6" id="rfc.xref.Part6.1"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a> will migrate to this part, where appropriate. The current mess reflects how widely dispersed these topics and associated requirements … … 708 708 <div id="rfc.iref.s.2"></div> 709 709 <h2 id="rfc.section.3.2"><a href="#rfc.section.3.2">3.2</a> <a id="status.412" href="#status.412">412 Precondition Failed</a></h2> 710 <p id="rfc.section.3.2.p.1">The precondition given in one or more of the request-header fields evaluated to false when it was tested on the server. This711 response code allows the client to place preconditions on the current resource metadata (header field data) and thus prevent712 the requestedmethod from being applied to a resource other than the one intended.710 <p id="rfc.section.3.2.p.1">The precondition given in one or more of the header fields evaluated to false when it was tested on the server. This response 711 code allows the client to place preconditions on the current resource metadata (header field data) and thus prevent the requested 712 method from being applied to a resource other than the one intended. 713 713 </p> 714 714 <h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a> <a id="weak.and.strong.validators" href="#weak.and.strong.validators">Weak and Strong Validators</a></h1> … … 904 904 <div id="rfc.iref.h.1"></div> 905 905 <h2 id="rfc.section.6.1"><a href="#rfc.section.6.1">6.1</a> <a id="header.etag" href="#header.etag">ETag</a></h2> 906 <p id="rfc.section.6.1.p.1">The "ETag" response-header field provides the current value of the entity-tag (see <a href="#entity.tags" title="Entity-Tags">Section 2</a>) for one representation of the target resource. An entity-tag is intended for use as a resource-local identifier for differentiating906 <p id="rfc.section.6.1.p.1">The "ETag" header field provides the current value of the entity-tag (see <a href="#entity.tags" title="Entity-Tags">Section 2</a>) for one representation of the target resource. An entity-tag is intended for use as a resource-local identifier for differentiating 907 907 between representations of the same resource that vary over time or via content negotiation (see <a href="#weak.and.strong.validators" title="Weak and Strong Validators">Section 4</a>). 908 908 </p> … … 925 925 <div id="rfc.iref.h.2"></div> 926 926 <h2 id="rfc.section.6.2"><a href="#rfc.section.6.2">6.2</a> <a id="header.if-match" href="#header.if-match">If-Match</a></h2> 927 <p id="rfc.section.6.2.p.1">The "If-Match" request-header field is used to make a request method conditional. A client that has one or more representations928 previously obtained from the resource can verify that one of those representations is current by including a list of their929 associatedentity-tags in the If-Match header field.927 <p id="rfc.section.6.2.p.1">The "If-Match" header field is used to make a request method conditional. A client that has one or more representations previously 928 obtained from the resource can verify that one of those representations is current by including a list of their associated 929 entity-tags in the If-Match header field. 930 930 </p> 931 931 <p id="rfc.section.6.2.p.2">This allows efficient updates of cached information with a minimum amount of transaction overhead. It is also used when updating … … 960 960 <div id="rfc.iref.h.3"></div> 961 961 <h2 id="rfc.section.6.3"><a href="#rfc.section.6.3">6.3</a> <a id="header.if-modified-since" href="#header.if-modified-since">If-Modified-Since</a></h2> 962 <p id="rfc.section.6.3.p.1">The "If-Modified-Since" request-header field is used to make a request method conditional by date: if the representation that963 would have been transferred in a 200 response to a GET request has not been modified since the time specified in this field,964 thendo not perform the method; instead, respond as detailed below.962 <p id="rfc.section.6.3.p.1">The "If-Modified-Since" header field is used to make a request method conditional by date: if the representation that would 963 have been transferred in a 200 response to a GET request has not been modified since the time specified in this field, then 964 do not perform the method; instead, respond as detailed below. 965 965 </p> 966 966 <div id="rfc.figure.u.11"></div><pre class="inline"><span id="rfc.iref.g.8"></span><span id="rfc.iref.g.9"></span> <a href="#header.if-modified-since" class="smpl">If-Modified-Since</a> = "If-Modified-Since" ":" <a href="#core.rules" class="smpl">OWS</a> … … 986 986 <p id="rfc.section.6.3.p.6">The purpose of this feature is to allow efficient updates of cached information with a minimum amount of transaction overhead. </p> 987 987 <ul class="empty"> 988 <li> <b>Note:</b> The Range request-header field modifies the meaning of If-Modified-Since; see <a href="p5-range.html#header.range" title="Range">Section 5.4</a> of <a href="#Part5" id="rfc.xref.Part5.4"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a> for full details.988 <li> <b>Note:</b> The Range header field modifies the meaning of If-Modified-Since; see <a href="p5-range.html#header.range" title="Range">Section 5.4</a> of <a href="#Part5" id="rfc.xref.Part5.4"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a> for full details. 989 989 </li> 990 990 <li> <b>Note:</b> If-Modified-Since times are interpreted by the server, whose clock might not be synchronized with the client. … … 1010 1010 <div id="rfc.iref.h.4"></div> 1011 1011 <h2 id="rfc.section.6.4"><a href="#rfc.section.6.4">6.4</a> <a id="header.if-none-match" href="#header.if-none-match">If-None-Match</a></h2> 1012 <p id="rfc.section.6.4.p.1">The "If-None-Match" request-header field is used to make a request method conditional. A client that has one or more representations1012 <p id="rfc.section.6.4.p.1">The "If-None-Match" header field is used to make a request method conditional. A client that has one or more representations 1013 1013 previously obtained from the resource can verify that none of those representations is current by including a list of their 1014 1014 associated entity-tags in the If-None-Match header field. … … 1046 1046 <div id="rfc.iref.h.5"></div> 1047 1047 <h2 id="rfc.section.6.5"><a href="#rfc.section.6.5">6.5</a> <a id="header.if-unmodified-since" href="#header.if-unmodified-since">If-Unmodified-Since</a></h2> 1048 <p id="rfc.section.6.5.p.1">The "If-Unmodified-Since" request-header field is used to make a request method conditional. If the representation that would1049 have been transferred in a 200 response to a GET request on the same resource has not been modified since the time specified1050 inthis field, the server <em class="bcp14">SHOULD</em> perform the requested operation as if the If-Unmodified-Since header field were not present.1048 <p id="rfc.section.6.5.p.1">The "If-Unmodified-Since" header field is used to make a request method conditional. If the representation that would have 1049 been transferred in a 200 response to a GET request on the same resource has not been modified since the time specified in 1050 this field, the server <em class="bcp14">SHOULD</em> perform the requested operation as if the If-Unmodified-Since header field were not present. 1051 1051 </p> 1052 1052 <p id="rfc.section.6.5.p.2">If the representation has been modified since the specified time, the server <em class="bcp14">MUST NOT</em> perform the requested operation, and <em class="bcp14">MUST</em> return a 412 (Precondition Failed). -
draft-ietf-httpbis/latest/p5-range.html
r1162 r1164 695 695 <div id="rfc.iref.s.2"></div> 696 696 <h2 id="rfc.section.3.2"><a href="#rfc.section.3.2">3.2</a> <a id="status.416" href="#status.416">416 Requested Range Not Satisfiable</a></h2> 697 <p id="rfc.section.3.2.p.1">A server <em class="bcp14">SHOULD</em> return a response with this status code if a request included a Range request-header field (<a href="#header.range" id="rfc.xref.header.range.4" title="Range">Section 5.4</a>), and none of the ranges-specifier values in this field overlap the current extent of the selected resource, and the request698 did not include an If-Range request-header field (<a href="#header.if-range" id="rfc.xref.header.if-range.2" title="If-Range">Section 5.3</a>). (For byte-ranges, this means that the first-byte-pos of all of the byte-range-spec values were greater than the current697 <p id="rfc.section.3.2.p.1">A server <em class="bcp14">SHOULD</em> return a response with this status code if a request included a Range header field (<a href="#header.range" id="rfc.xref.header.range.4" title="Range">Section 5.4</a>), and none of the ranges-specifier values in this field overlap the current extent of the selected resource, and the request 698 did not include an If-Range header field (<a href="#header.if-range" id="rfc.xref.header.if-range.2" title="If-Range">Section 5.3</a>). (For byte-ranges, this means that the first-byte-pos of all of the byte-range-spec values were greater than the current 699 699 length of the selected resource.) 700 700 </p> … … 722 722 <div id="rfc.iref.h.1"></div> 723 723 <h2 id="rfc.section.5.1"><a href="#rfc.section.5.1">5.1</a> <a id="header.accept-ranges" href="#header.accept-ranges">Accept-Ranges</a></h2> 724 <p id="rfc.section.5.1.p.1">The "Accept-Ranges" response-header field allows a resource to indicate its acceptance of range requests.</p>724 <p id="rfc.section.5.1.p.1">The "Accept-Ranges" header field allows a resource to indicate its acceptance of range requests.</p> 725 725 <div id="rfc.figure.u.5"></div><pre class="inline"><span id="rfc.iref.g.4"></span><span id="rfc.iref.g.5"></span><span id="rfc.iref.g.6"></span> <a href="#header.accept-ranges" class="smpl">Accept-Ranges</a> = "Accept-Ranges" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.accept-ranges" class="smpl">Accept-Ranges-v</a> 726 726 <a href="#header.accept-ranges" class="smpl">Accept-Ranges-v</a> = <a href="#header.accept-ranges" class="smpl">acceptable-ranges</a> … … 807 807 the full representation). 808 808 </p> 809 <p id="rfc.section.5.2.p.15">If the server receives a request (other than one including an If-Range request-header field) with an unsatisfiable Range request-header810 field(that is, all of whose byte-range-spec values have a first-byte-pos value greater than the current length of the selected809 <p id="rfc.section.5.2.p.15">If the server receives a request (other than one including an If-Range header field) with an unsatisfiable Range header field 810 (that is, all of whose byte-range-spec values have a first-byte-pos value greater than the current length of the selected 811 811 resource), it <em class="bcp14">SHOULD</em> return a response code of 416 (Requested range not satisfiable) (<a href="#status.416" id="rfc.xref.status.416.1" title="416 Requested Range Not Satisfiable">Section 3.2</a>). 812 812 </p> 813 813 <div class="note" id="rfc.section.5.2.p.16"> 814 814 <p> <b>Note:</b> Clients cannot depend on servers to send a 416 (Requested range not satisfiable) response instead of a 200 (OK) response for 815 an unsatisfiable Range request-header field, since not all servers implement this request-header field.815 an unsatisfiable Range header field, since not all servers implement this header field. 816 816 </p> 817 817 </div> … … 820 820 <h2 id="rfc.section.5.3"><a href="#rfc.section.5.3">5.3</a> <a id="header.if-range" href="#header.if-range">If-Range</a></h2> 821 821 <p id="rfc.section.5.3.p.1">If a client has a partial copy of a representation in its cache, and wishes to have an up-to-date copy of the entire representation 822 in its cache, it could use the Range request-header field with a conditional GET (using either or both of If-Unmodified-Since823 and If-Match.) However, if the condition fails because the representation has been modified, the client would then have to824 makea second request to obtain the entire current representation.825 </p> 826 <p id="rfc.section.5.3.p.2">The "If-Range" request-header field allows a client to "short-circuit" the second request. Informally, its meaning is "if827 the representationis unchanged, send me the part(s) that I am missing; otherwise, send me the entire new representation".822 in its cache, it could use the Range header field with a conditional GET (using either or both of If-Unmodified-Since and 823 If-Match.) However, if the condition fails because the representation has been modified, the client would then have to make 824 a second request to obtain the entire current representation. 825 </p> 826 <p id="rfc.section.5.3.p.2">The "If-Range" header field allows a client to "short-circuit" the second request. Informally, its meaning is "if the representation 827 is unchanged, send me the part(s) that I am missing; otherwise, send me the entire new representation". 828 828 </p> 829 829 <div id="rfc.figure.u.14"></div><pre class="inline"><span id="rfc.iref.g.13"></span><span id="rfc.iref.g.14"></span> <a href="#header.if-range" class="smpl">If-Range</a> = "If-Range" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.if-range" class="smpl">If-Range-v</a> … … 897 897 </ul> 898 898 <h3 id="rfc.section.5.4.2"><a href="#rfc.section.5.4.2">5.4.2</a> <a id="range.retrieval.requests" href="#range.retrieval.requests">Range Retrieval Requests</a></h3> 899 <p id="rfc.section.5.4.2.p.1">The "Range" request-header field defines the GET method (conditional or not) to request one or more sub-ranges of the response900 representationbody, instead of the entire representation body.899 <p id="rfc.section.5.4.2.p.1">The "Range" header field defines the GET method (conditional or not) to request one or more sub-ranges of the response representation 900 body, instead of the entire representation body. 901 901 </p> 902 902 <div id="rfc.figure.u.23"></div><pre class="inline"><span id="rfc.iref.g.23"></span> <a href="#range.retrieval.requests" class="smpl">Range</a> = "Range" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#range.retrieval.requests" class="smpl">Range-v</a> -
draft-ietf-httpbis/latest/p6-cache.html
r1162 r1164 783 783 </li> 784 784 <li>the request method associated with the stored response allows it to be used for the presented request, and</li> 785 <li>selecting request-header fields nominated by the stored response (if any) match those presented (see <a href="#caching.negotiated.responses" title="Caching Negotiated Responses">Section 2.7</a>), and785 <li>selecting header fields nominated by the stored response (if any) match those presented (see <a href="#caching.negotiated.responses" title="Caching Negotiated Responses">Section 2.7</a>), and 786 786 </li> 787 787 <li>the presented request and stored response are free from directives that would prevent its use (see <a href="#header.cache-control" id="rfc.xref.header.cache-control.2" title="Cache-Control">Section 3.2</a> and <a href="#header.pragma" id="rfc.xref.header.pragma.1" title="Pragma">Section 3.4</a>), and … … 868 868 </div> 869 869 <h3 id="rfc.section.2.3.2"><a href="#rfc.section.2.3.2">2.3.2</a> <a id="age.calculations" href="#age.calculations">Calculating Age</a></h3> 870 <p id="rfc.section.2.3.2.p.1">HTTP/1.1 uses the Age response-header field to convey the estimated age of the response message when obtained from a cache.871 The Age field value is the cache's estimate of the amount of time since the response was generated or validated by the origin872 server. In essence, the Age value is the sum of the time that the response has been resident in each of the caches along the873 pathfrom the origin server, plus the amount of time it has been in transit along network paths.870 <p id="rfc.section.2.3.2.p.1">HTTP/1.1 uses the Age header field to convey the estimated age of the response message when obtained from a cache. The Age 871 field value is the cache's estimate of the amount of time since the response was generated or validated by the origin server. 872 In essence, the Age value is the sum of the time that the response has been resident in each of the caches along the path 873 from the origin server, plus the amount of time it has been in transit along network paths. 874 874 </p> 875 875 <p id="rfc.section.2.3.2.p.2">The following data is used for the age calculation:</p> … … 990 990 </p> 991 991 <h2 id="rfc.section.2.7"><a href="#rfc.section.2.7">2.7</a> <a id="caching.negotiated.responses" href="#caching.negotiated.responses">Caching Negotiated Responses</a></h2> 992 <p id="rfc.section.2.7.p.1">When a cache receives a request that can be satisfied by a stored response that has a Vary header field (<a href="#header.vary" id="rfc.xref.header.vary.1" title="Vary">Section 3.5</a>), it <em class="bcp14">MUST NOT</em> use that response unless all of the selecting request-header fields nominated by the Vary header field match in both the original992 <p id="rfc.section.2.7.p.1">When a cache receives a request that can be satisfied by a stored response that has a Vary header field (<a href="#header.vary" id="rfc.xref.header.vary.1" title="Vary">Section 3.5</a>), it <em class="bcp14">MUST NOT</em> use that response unless all of the selecting header fields nominated by the Vary header field match in both the original 993 993 request (i.e., that associated with the stored response), and the presented request. 994 994 </p> 995 <p id="rfc.section.2.7.p.2">The selecting request-header fields from two requests are defined to match if and only if those in the first request can be996 t ransformed to those in the second request by applying any of the following:995 <p id="rfc.section.2.7.p.2">The selecting header fields from two requests are defined to match if and only if those in the first request can be transformed 996 to those in the second request by applying any of the following: 997 997 </p> 998 998 <ul> 999 999 <li>adding or removing whitespace, where allowed in the header field's syntax</li> 1000 <li>combining multiple message-header fields with the same field name (see <a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.16"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>)1000 <li>combining multiple header fields with the same field name (see <a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.16"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) 1001 1001 </li> 1002 1002 <li>normalizing both header field values in a way that is known to have identical semantics, according to the header field's specification … … 1010 1010 by the origin server. 1011 1011 </p> 1012 <p id="rfc.section.2.7.p.5">The stored response with matching selecting request-header fields is known as the selected response.</p>1012 <p id="rfc.section.2.7.p.5">The stored response with matching selecting header fields is known as the selected response.</p> 1013 1013 <p id="rfc.section.2.7.p.6">If no selected response is available, the cache <em class="bcp14">MAY</em> forward the presented request to the origin server in a conditional request; see <a href="#validation.model" title="Validation Model">Section 2.4</a>. 1014 1014 </p> … … 1040 1040 <div id="rfc.iref.h.2"></div> 1041 1041 <h2 id="rfc.section.3.1"><a href="#rfc.section.3.1">3.1</a> <a id="header.age" href="#header.age">Age</a></h2> 1042 <p id="rfc.section.3.1.p.1">The "Age" response-header field conveys the sender's estimate of the amount of time since the response was generated or successfully1042 <p id="rfc.section.3.1.p.1">The "Age" header field conveys the sender's estimate of the amount of time since the response was generated or successfully 1043 1043 validated at the origin server. Age values are calculated as specified in <a href="#age.calculations" title="Calculating Age">Section 2.3.2</a>. 1044 1044 </p> … … 1058 1058 <div id="rfc.iref.h.3"></div> 1059 1059 <h2 id="rfc.section.3.2"><a href="#rfc.section.3.2">3.2</a> <a id="header.cache-control" href="#header.cache-control">Cache-Control</a></h2> 1060 <p id="rfc.section.3.2.p.1">The "Cache-Control" general-header field is used to specify directives for caches along the request/response chain. Such cache1061 directives are unidirectional in that the presence of a directive in a request does not imply that the same directive is to1062 be givenin the response.1060 <p id="rfc.section.3.2.p.1">The "Cache-Control" header field is used to specify directives for caches along the request/response chain. Such cache directives 1061 are unidirectional in that the presence of a directive in a request does not imply that the same directive is to be given 1062 in the response. 1063 1063 </p> 1064 1064 <p id="rfc.section.3.2.p.2">A cache <em class="bcp14">MUST</em> obey the requirements of the Cache-Control directives defined in this section. See <a href="#cache.control.extensions" title="Cache Control Extensions">Section 3.2.3</a> for information about how Cache-Control directives defined elsewhere are handled. … … 1303 1303 <div id="rfc.iref.h.5"></div> 1304 1304 <h2 id="rfc.section.3.4"><a href="#rfc.section.3.4">3.4</a> <a id="header.pragma" href="#header.pragma">Pragma</a></h2> 1305 <p id="rfc.section.3.4.p.1">The "Pragma" general-header field is used to include implementation-specific directives that might apply to any recipient1306 along the request/response chain. All pragma directives specify optional behavior from the viewpoint of the protocol; however,1307 s ome systems <em class="bcp14">MAY</em> require that behavior be consistent with the directives.1305 <p id="rfc.section.3.4.p.1">The "Pragma" header field is used to include implementation-specific directives that might apply to any recipient along the 1306 request/response chain. All pragma directives specify optional behavior from the viewpoint of the protocol; however, some 1307 systems <em class="bcp14">MAY</em> require that behavior be consistent with the directives. 1308 1308 </p> 1309 1309 <div id="rfc.figure.u.15"></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><span id="rfc.iref.g.14"></span> <a href="#header.pragma" class="smpl">Pragma</a> = "Pragma" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.pragma" class="smpl">Pragma-v</a> … … 1315 1315 </p> 1316 1316 <div class="note" id="rfc.section.3.4.p.4"> 1317 <p> <b>Note:</b> Because the meaning of "Pragma: no-cache" as a response-header field is not actually specified, it does not provide a reliable1318 replacementfor "Cache-Control: no-cache" in a response.1317 <p> <b>Note:</b> Because the meaning of "Pragma: no-cache" as a header field is not actually specified, it does not provide a reliable replacement 1318 for "Cache-Control: no-cache" in a response. 1319 1319 </p> 1320 1320 </div> … … 1323 1323 <div id="rfc.iref.h.6"></div> 1324 1324 <h2 id="rfc.section.3.5"><a href="#rfc.section.3.5">3.5</a> <a id="header.vary" href="#header.vary">Vary</a></h2> 1325 <p id="rfc.section.3.5.p.1">The "Vary" response-header field conveys the set of request-header fields that were used to select the representation.</p>1325 <p id="rfc.section.3.5.p.1">The "Vary" header field conveys the set of header fields that were used to select the representation.</p> 1326 1326 <p id="rfc.section.3.5.p.2">Caches use this information, in part, to determine whether a stored response can be used to satisfy a given request; see <a href="#caching.negotiated.responses" title="Caching Negotiated Responses">Section 2.7</a>. determines, while the response is fresh, whether a cache is permitted to use the response to reply to a subsequent request 1327 1327 without validation; see <a href="#caching.negotiated.responses" title="Caching Negotiated Responses">Section 2.7</a>. … … 1332 1332 <div id="rfc.figure.u.16"></div><pre class="inline"><span id="rfc.iref.g.15"></span><span id="rfc.iref.g.16"></span> <a href="#header.vary" class="smpl">Vary</a> = "Vary" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.vary" class="smpl">Vary-v</a> 1333 1333 <a href="#header.vary" class="smpl">Vary-v</a> = "*" / 1#<a href="#abnf.dependencies" class="smpl">field-name</a> 1334 </pre><p id="rfc.section.3.5.p.5">The set of header fields named by the Vary field value is known as the selecting request-header fields.</p>1334 </pre><p id="rfc.section.3.5.p.5">The set of header fields named by the Vary field value is known as the selecting header fields.</p> 1335 1335 <p id="rfc.section.3.5.p.6">A server <em class="bcp14">SHOULD</em> include a Vary header field with any cacheable response that is subject to server-driven negotiation. Doing so allows a cache 1336 1336 to properly interpret future requests on that resource and informs the user agent about the presence of negotiation on that … … 1338 1338 the user agent with useful information about the dimensions over which the response varies at the time of the response. 1339 1339 </p> 1340 <p id="rfc.section.3.5.p.7">A Vary field value of "*" signals that unspecified parameters not limited to the request-header fields (e.g., the network1341 address of the client), play a role in the selection of the response representation; therefore, a cache cannot determine whether1342 thisresponse is appropriate. A proxy <em class="bcp14">MUST NOT</em> generate the "*" value.1343 </p> 1344 <p id="rfc.section.3.5.p.8">The field-names given are not limited to the set of standard request-header fields defined by this specification. Field names1345 arecase-insensitive.1340 <p id="rfc.section.3.5.p.7">A Vary field value of "*" signals that unspecified parameters not limited to the header fields (e.g., the network address 1341 of the client), play a role in the selection of the response representation; therefore, a cache cannot determine whether this 1342 response is appropriate. A proxy <em class="bcp14">MUST NOT</em> generate the "*" value. 1343 </p> 1344 <p id="rfc.section.3.5.p.8">The field-names given are not limited to the set of standard header fields defined by this specification. Field names are 1345 case-insensitive. 1346 1346 </p> 1347 1347 <div id="rfc.iref.w.1"></div> 1348 1348 <div id="rfc.iref.h.7"></div> 1349 1349 <h2 id="rfc.section.3.6"><a href="#rfc.section.3.6">3.6</a> <a id="header.warning" href="#header.warning">Warning</a></h2> 1350 <p id="rfc.section.3.6.p.1">The "Warning" general-header field is used to carry additional information about the status or transformation of a message1351 that might not be reflected in the message. This information is typically used to warn about possible incorrectness introduced1352 by cachingoperations or transformations applied to the payload of the message.1350 <p id="rfc.section.3.6.p.1">The "Warning" header field is used to carry additional information about the status or transformation of a message that might 1351 not be reflected in the message. This information is typically used to warn about possible incorrectness introduced by caching 1352 operations or transformations applied to the payload of the message. 1353 1353 </p> 1354 1354 <p id="rfc.section.3.6.p.2">Warnings can be used for other purposes, both cache-related and otherwise. The use of a warning, rather than an error status -
draft-ietf-httpbis/latest/p7-auth.html
r1162 r1164 711 711 <div id="rfc.iref.h.1"></div> 712 712 <h2 id="rfc.section.4.1"><a href="#rfc.section.4.1">4.1</a> <a id="header.authorization" href="#header.authorization">Authorization</a></h2> 713 <p id="rfc.section.4.1.p.1">The "Authorization" request-header field allows a user agent to authenticate itself with a server — usually, but not necessarily,713 <p id="rfc.section.4.1.p.1">The "Authorization" header field allows a user agent to authenticate itself with a server — usually, but not necessarily, 714 714 after receiving a 401 (Unauthorized) response. Its value consists of credentials containing information of the user agent 715 715 for the realm of the resource being requested. … … 724 724 <p id="rfc.section.4.1.p.5"> </p> 725 725 <ol> 726 <li>If the response includes the "s-maxage" cache-control directive, the cache <em class="bcp14">MAY</em> use that response in replying to a subsequent request. But (if the specified maximum age has passed) a proxy cache <em class="bcp14">MUST</em> first revalidate it with the origin server, using the request-header fields from the new request to allow the origin server727 t o authenticate the new request. (This is the defined behavior for s-maxage.) If the response includes "s-maxage=0", the proxy <em class="bcp14">MUST</em> always revalidate it before re-using it.728 </li> 729 <li>If the response includes the "must-revalidate" cache-control directive, the cache <em class="bcp14">MAY</em> use that response in replying to a subsequent request. But if the response is stale, all caches <em class="bcp14">MUST</em> first revalidate it with the origin server, using the request-header fields from the new request to allow the origin server730 t o authenticate the new request.726 <li>If the response includes the "s-maxage" cache-control directive, the cache <em class="bcp14">MAY</em> use that response in replying to a subsequent request. But (if the specified maximum age has passed) a proxy cache <em class="bcp14">MUST</em> first revalidate it with the origin server, using the header fields from the new request to allow the origin server to authenticate 727 the new request. (This is the defined behavior for s-maxage.) If the response includes "s-maxage=0", the proxy <em class="bcp14">MUST</em> always revalidate it before re-using it. 728 </li> 729 <li>If the response includes the "must-revalidate" cache-control directive, the cache <em class="bcp14">MAY</em> use that response in replying to a subsequent request. But if the response is stale, all caches <em class="bcp14">MUST</em> first revalidate it with the origin server, using the header fields from the new request to allow the origin server to authenticate 730 the new request. 731 731 </li> 732 732 <li>If the response includes the "public" cache-control directive, it <em class="bcp14">MAY</em> be returned in reply to any subsequent request. … … 736 736 <div id="rfc.iref.h.2"></div> 737 737 <h2 id="rfc.section.4.2"><a href="#rfc.section.4.2">4.2</a> <a id="header.proxy-authenticate" href="#header.proxy-authenticate">Proxy-Authenticate</a></h2> 738 <p id="rfc.section.4.2.p.1">The "Proxy-Authenticate" response-header field consists of a challenge that indicates the authentication scheme and parameters739 applicableto the proxy for this effective request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.7"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). It <em class="bcp14">MUST</em> be included as part of a 407 (Proxy Authentication Required) response.738 <p id="rfc.section.4.2.p.1">The "Proxy-Authenticate" header field consists of a challenge that indicates the authentication scheme and parameters applicable 739 to the proxy for this effective request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.7"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). It <em class="bcp14">MUST</em> be included as part of a 407 (Proxy Authentication Required) response. 740 740 </p> 741 741 <div id="rfc.figure.u.7"></div><pre class="inline"><span id="rfc.iref.g.3"></span><span id="rfc.iref.g.4"></span> <a href="#header.proxy-authenticate" class="smpl">Proxy-Authenticate</a> = "Proxy-Authenticate" ":" <a href="#core.rules" class="smpl">OWS</a> … … 749 749 <div id="rfc.iref.h.3"></div> 750 750 <h2 id="rfc.section.4.3"><a href="#rfc.section.4.3">4.3</a> <a id="header.proxy-authorization" href="#header.proxy-authorization">Proxy-Authorization</a></h2> 751 <p id="rfc.section.4.3.p.1">The "Proxy-Authorization" request-header field allows the client to identify itself (or its user) to a proxy which requires752 authentication. Its value consists of credentials containing the authentication information of the user agent for the proxy753 and/or realm ofthe resource being requested.751 <p id="rfc.section.4.3.p.1">The "Proxy-Authorization" header field allows the client to identify itself (or its user) to a proxy which requires authentication. 752 Its value consists of credentials containing the authentication information of the user agent for the proxy and/or realm of 753 the resource being requested. 754 754 </p> 755 755 <div id="rfc.figure.u.8"></div><pre class="inline"><span id="rfc.iref.g.5"></span><span id="rfc.iref.g.6"></span> <a href="#header.proxy-authorization" class="smpl">Proxy-Authorization</a> = "Proxy-Authorization" ":" <a href="#core.rules" class="smpl">OWS</a> … … 764 764 <div id="rfc.iref.h.4"></div> 765 765 <h2 id="rfc.section.4.4"><a href="#rfc.section.4.4">4.4</a> <a id="header.www-authenticate" href="#header.www-authenticate">WWW-Authenticate</a></h2> 766 <p id="rfc.section.4.4.p.1">The "WWW-Authenticate" response-header field consists of at least one challenge that indicates the authentication scheme(s)767 a nd parameters applicable to the effective request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.8"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). It <em class="bcp14">MUST</em> be included in 401 (Unauthorized) response messages.766 <p id="rfc.section.4.4.p.1">The "WWW-Authenticate" header field consists of at least one challenge that indicates the authentication scheme(s) and parameters 767 applicable to the effective request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.8"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). It <em class="bcp14">MUST</em> be included in 401 (Unauthorized) response messages. 768 768 </p> 769 769 <div id="rfc.figure.u.9"></div><pre class="inline"><span id="rfc.iref.g.7"></span><span id="rfc.iref.g.8"></span> <a href="#header.www-authenticate" class="smpl">WWW-Authenticate</a> = "WWW-Authenticate" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.www-authenticate" class="smpl">WWW-Authenticate-v</a>
Note: See TracChangeset
for help on using the changeset viewer.