Changeset 2052 for draft-ietf-httpbis/latest/p1-messaging.html
- Timestamp:
- 16/12/12 03:46:23 (10 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.html
r2049 r2052 449 449 } 450 450 @bottom-center { 451 content: "Expires June 1 4, 2013";451 content: "Expires June 18, 2013"; 452 452 } 453 453 @bottom-right { … … 491 491 <meta name="dct.creator" content="Reschke, J. F."> 492 492 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p1-messaging-latest"> 493 <meta name="dct.issued" scheme="ISO8601" content="2012-12-1 1">493 <meta name="dct.issued" scheme="ISO8601" content="2012-12-15"> 494 494 <meta name="dct.replaces" content="urn:ietf:rfc:2145"> 495 495 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> … … 520 520 <tr> 521 521 <td class="left">Intended status: Standards Track</td> 522 <td class="right">December 1 1, 2012</td>522 <td class="right">December 15, 2012</td> 523 523 </tr> 524 524 <tr> 525 <td class="left">Expires: June 1 4, 2013</td>525 <td class="left">Expires: June 18, 2013</td> 526 526 <td class="right"></td> 527 527 </tr> … … 551 551 in progress”. 552 552 </p> 553 <p>This Internet-Draft will expire on June 1 4, 2013.</p>553 <p>This Internet-Draft will expire on June 18, 2013.</p> 554 554 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 555 555 <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 884 884 or an intranet-to-Internet privacy filter. Such transformations are presumed to be desired by the client (or client organization) 885 885 that selected the proxy and are beyond the scope of this specification. However, when a proxy is not intended to transform 886 a given message, we use the term "<dfn>non-transforming proxy</dfn>" to target requirements that preserve HTTP message semantics. See <a href="p2-semantics.html#status.203" title="203 Non-Authoritative Information">Section 7.3.4</a> of <a href="#Part2" id="rfc.xref.Part2.3"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a> and <a href="p6-cache.html#header.warning" title="Warning">Section 7.5</a> of <a href="#Part6" id="rfc.xref.Part6.2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a> for status and warning codes related to transformations.886 a given message, we use the term "<dfn>non-transforming proxy</dfn>" to target requirements that preserve HTTP message semantics. See <a href="p2-semantics.html#status.203" title="203 Non-Authoritative Information">Section 6.3.4</a> of <a href="#Part2" id="rfc.xref.Part2.3"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a> and <a href="p6-cache.html#header.warning" title="Warning">Section 7.5</a> of <a href="#Part6" id="rfc.xref.Part6.2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a> for status and warning codes related to transformations. 887 887 </p> 888 888 <p id="rfc.section.2.3.p.7"><span id="rfc.iref.g.13"></span><span id="rfc.iref.r.4"></span> <span id="rfc.iref.a.1"></span> A "<dfn>gateway</dfn>" (a.k.a., "<dfn>reverse proxy</dfn>") is a receiving agent that acts as a layer above some other server(s) and translates the received requests to the underlying … … 1054 1054 </p> 1055 1055 <p id="rfc.section.2.7.1.p.6">When an "http" URI is used within a context that calls for access to the indicated resource, a client <em class="bcp14">MAY</em> attempt access by resolving the host to an IP address, establishing a TCP connection to that address on the indicated port, 1056 and sending an HTTP request message (<a href="#http.message" title="Message Format">Section 3</a>) containing the URI's identifying data (<a href="#message.routing" title="Message Routing">Section 5</a>) to the server. If the server responds to that request with a non-interim HTTP response message, as described in <a href="p2-semantics.html#status.codes" title="Response Status Codes">Section 7</a> of <a href="#Part2" id="rfc.xref.Part2.5"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>, then that response is considered an authoritative answer to the client's request.1056 and sending an HTTP request message (<a href="#http.message" title="Message Format">Section 3</a>) containing the URI's identifying data (<a href="#message.routing" title="Message Routing">Section 5</a>) to the server. If the server responds to that request with a non-interim HTTP response message, as described in <a href="p2-semantics.html#status.codes" title="Response Status Codes">Section 6</a> of <a href="#Part2" id="rfc.xref.Part2.5"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>, then that response is considered an authoritative answer to the client's request. 1057 1057 </p> 1058 1058 <p id="rfc.section.2.7.1.p.7">Although HTTP is independent of the transport protocol, the "http" scheme is specific to TCP-based services because the name … … 1154 1154 </div> 1155 1155 <div id="rfc.figure.u.14"></div><pre class="inline"><span id="rfc.iref.g.29"></span> <a href="#method" class="smpl">method</a> = <a href="#rule.token.separators" class="smpl">token</a> 1156 </pre><p id="rfc.section.3.1.1.p.5">The methods defined by this specification can be found in <a href="p2-semantics.html#methods" title="Request Methods">Section 5</a> of <a href="#Part2" id="rfc.xref.Part2.6"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>, along with information regarding the HTTP method registry and considerations for defining new methods.1156 </pre><p id="rfc.section.3.1.1.p.5">The methods defined by this specification can be found in <a href="p2-semantics.html#methods" title="Request Methods">Section 4</a> of <a href="#Part2" id="rfc.xref.Part2.6"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>, along with information regarding the HTTP method registry and considerations for defining new methods. 1157 1157 </p> 1158 1158 <div id="rfc.iref.r.6"></div> … … 1167 1167 </p> 1168 1168 <p id="rfc.section.3.1.1.p.9">HTTP does not place a pre-defined limit on the length of a request-line. A server that receives a method longer than any that 1169 it implements <em class="bcp14">SHOULD</em> respond with either a <a href="p2-semantics.html#status.405" class="smpl">405 (Method Not Allowed)</a>, if it is an origin server, or a <a href="p2-semantics.html#status.501" class="smpl">501 (Not Implemented)</a> status code. A server <em class="bcp14">MUST</em> be prepared to receive URIs of unbounded length and respond with the <a href="p2-semantics.html#status.414" class="smpl">414 (URI Too Long)</a> status code if the received request-target would be longer than the server wishes to handle (see <a href="p2-semantics.html#status.414" title="414 URI Too Long">Section 7.5.12</a> of <a href="#Part2" id="rfc.xref.Part2.7"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>).1169 it implements <em class="bcp14">SHOULD</em> respond with either a <a href="p2-semantics.html#status.405" class="smpl">405 (Method Not Allowed)</a>, if it is an origin server, or a <a href="p2-semantics.html#status.501" class="smpl">501 (Not Implemented)</a> status code. A server <em class="bcp14">MUST</em> be prepared to receive URIs of unbounded length and respond with the <a href="p2-semantics.html#status.414" class="smpl">414 (URI Too Long)</a> status code if the received request-target would be longer than the server wishes to handle (see <a href="p2-semantics.html#status.414" title="414 URI Too Long">Section 6.5.12</a> of <a href="#Part2" id="rfc.xref.Part2.7"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). 1170 1170 </p> 1171 1171 <p id="rfc.section.3.1.1.p.10">Various ad-hoc limitations on request-line length are found in practice. It is <em class="bcp14">RECOMMENDED</em> that all HTTP senders and recipients support, at a minimum, request-line lengths of 8000 octets. … … 1178 1178 </pre><p id="rfc.section.3.1.2.p.3">The status-code element is a 3-digit integer code describing the result of the server's attempt to understand and satisfy 1179 1179 the client's corresponding request. The rest of the response message is to be interpreted in light of the semantics defined 1180 for that status code. See <a href="p2-semantics.html#status.codes" title="Response Status Codes">Section 7</a> of <a href="#Part2" id="rfc.xref.Part2.8"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a> for information about the semantics of status codes, including the classes of status code (indicated by the first digit),1180 for that status code. See <a href="p2-semantics.html#status.codes" title="Response Status Codes">Section 6</a> of <a href="#Part2" id="rfc.xref.Part2.8"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a> for information about the semantics of status codes, including the classes of status code (indicated by the first digit), 1181 1181 the status codes defined by this specification, considerations for the definition of new status codes, and the IANA registry. 1182 1182 </p> … … 1199 1199 ; see <a href="#field.parsing" title="Field Parsing">Section 3.2.4</a> 1200 1200 </pre><p id="rfc.section.3.2.p.3">The field-name token labels the corresponding field-value as having the semantics defined by that header field. For example, 1201 the <a href="p2-semantics.html#header.date" class="smpl">Date</a> header field is defined in <a href="p2-semantics.html#header.date" title="Date">Section 8.1.1.2</a> of <a href="#Part2" id="rfc.xref.Part2.9"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a> as containing the origination timestamp for the message in which it appears.1201 the <a href="p2-semantics.html#header.date" class="smpl">Date</a> header field is defined in <a href="p2-semantics.html#header.date" title="Date">Section 7.1.1.2</a> of <a href="#Part2" id="rfc.xref.Part2.9"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a> as containing the origination timestamp for the message in which it appears. 1202 1202 </p> 1203 1203 <h3 id="rfc.section.3.2.1"><a href="#rfc.section.3.2.1">3.2.1</a> <a id="field.extensibility" href="#field.extensibility">Field Extensibility</a></h3> … … 1207 1207 the protocol version if their defined semantics allow them to be safely ignored by recipients that do not recognize them. 1208 1208 </p> 1209 <p id="rfc.section.3.2.1.p.2">New HTTP header fields ought to be be registered with IANA in the Message Header Field Registry, as described in <a href="p2-semantics.html#header.field.registry" title="Header Field Registry">Section 9.3</a> of <a href="#Part2" id="rfc.xref.Part2.10"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>. A proxy <em class="bcp14">MUST</em> forward unrecognized header fields unless the field-name is listed in the <a href="#header.connection" class="smpl">Connection</a> header field (<a href="#header.connection" id="rfc.xref.header.connection.3" title="Connection">Section 6.1</a>) or the proxy is specifically configured to block, or otherwise transform, such fields. Other recipients <em class="bcp14">SHOULD</em> ignore unrecognized header fields.1209 <p id="rfc.section.3.2.1.p.2">New HTTP header fields ought to be be registered with IANA in the Message Header Field Registry, as described in <a href="p2-semantics.html#header.field.registry" title="Header Field Registry">Section 8.3</a> of <a href="#Part2" id="rfc.xref.Part2.10"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>. A proxy <em class="bcp14">MUST</em> forward unrecognized header fields unless the field-name is listed in the <a href="#header.connection" class="smpl">Connection</a> header field (<a href="#header.connection" id="rfc.xref.header.connection.3" title="Connection">Section 6.1</a>) or the proxy is specifically configured to block, or otherwise transform, such fields. Other recipients <em class="bcp14">SHOULD</em> ignore unrecognized header fields. 1210 1210 </p> 1211 1211 <h3 id="rfc.section.3.2.2"><a href="#rfc.section.3.2.2">3.2.2</a> <a id="field.order" href="#field.order">Field Order</a></h3> … … 1340 1340 </p> 1341 1341 <p id="rfc.section.3.3.p.5">The presence of a message body in a response depends on both the request method to which it is responding and the response 1342 status code (<a href="#status.line" title="Status Line">Section 3.1.2</a>). Responses to the HEAD request method never include a message body because the associated response header fields (e.g., <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a>, <a href="#header.content-length" class="smpl">Content-Length</a>, etc.), if present, indicate only what their values would have been if the request method had been GET (<a href="p2-semantics.html#HEAD" title="HEAD">Section 5.3.2</a> of <a href="#Part2" id="rfc.xref.Part2.11"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). <a href="p2-semantics.html#status.2xx" class="smpl">2xx (Successful)</a> responses to CONNECT switch to tunnel mode instead of having a message body (<a href="p2-semantics.html#CONNECT" title="CONNECT">Section 5.3.6</a> of <a href="#Part2" id="rfc.xref.Part2.12"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). All <a href="p2-semantics.html#status.1xx" class="smpl">1xx (Informational)</a>, <a href="p2-semantics.html#status.204" class="smpl">204 (No Content)</a>, and <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a> responses <em class="bcp14">MUST NOT</em> include a message body. All other responses do include a message body, although the body <em class="bcp14">MAY</em> be of zero length.1342 status code (<a href="#status.line" title="Status Line">Section 3.1.2</a>). Responses to the HEAD request method never include a message body because the associated response header fields (e.g., <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a>, <a href="#header.content-length" class="smpl">Content-Length</a>, etc.), if present, indicate only what their values would have been if the request method had been GET (<a href="p2-semantics.html#HEAD" title="HEAD">Section 4.3.2</a> of <a href="#Part2" id="rfc.xref.Part2.11"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). <a href="p2-semantics.html#status.2xx" class="smpl">2xx (Successful)</a> responses to CONNECT switch to tunnel mode instead of having a message body (<a href="p2-semantics.html#CONNECT" title="CONNECT">Section 4.3.6</a> of <a href="#Part2" id="rfc.xref.Part2.12"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). All <a href="p2-semantics.html#status.1xx" class="smpl">1xx (Informational)</a>, <a href="p2-semantics.html#status.204" class="smpl">204 (No Content)</a>, and <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a> responses <em class="bcp14">MUST NOT</em> include a message body. All other responses do include a message body, although the body <em class="bcp14">MAY</em> be of zero length. 1343 1343 </p> 1344 1344 <div id="rfc.iref.t.4"></div> … … 1382 1382 payload body. For messages that do include a payload body, the Content-Length field-value provides the framing information 1383 1383 necessary for determining where the body (and message) ends. For messages that do not include a payload body, the Content-Length 1384 indicates the size of the selected representation (<a href="p2-semantics.html#selected.representation" title="Selected Representation Header Fields">Section 8.2</a> of <a href="#Part2" id="rfc.xref.Part2.14"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>).1384 indicates the size of the selected representation (<a href="p2-semantics.html#selected.representation" title="Selected Representation Header Fields">Section 7.2</a> of <a href="#Part2" id="rfc.xref.Part2.14"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). 1385 1385 </p> 1386 1386 <div id="rfc.figure.u.28"></div><pre class="inline"><span id="rfc.iref.g.54"></span> <a href="#header.content-length" class="smpl">Content-Length</a> = 1*<a href="#core.rules" class="smpl">DIGIT</a> … … 1393 1393 anticipate such a body. 1394 1394 </p> 1395 <p id="rfc.section.3.3.2.p.7">A server <em class="bcp14">MAY</em> send a Content-Length header field in a response to a HEAD request (<a href="p2-semantics.html#HEAD" title="HEAD">Section 5.3.2</a> of <a href="#Part2" id="rfc.xref.Part2.15"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>); a server <em class="bcp14">MUST NOT</em> send Content-Length in such a response unless its field-value equals the decimal number of octets that would have been sent1395 <p id="rfc.section.3.3.2.p.7">A server <em class="bcp14">MAY</em> send a Content-Length header field in a response to a HEAD request (<a href="p2-semantics.html#HEAD" title="HEAD">Section 4.3.2</a> of <a href="#Part2" id="rfc.xref.Part2.15"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>); a server <em class="bcp14">MUST NOT</em> send Content-Length in such a response unless its field-value equals the decimal number of octets that would have been sent 1396 1396 in the payload body of a response if the same request had used the GET method. 1397 1397 </p> … … 1399 1399 in the payload body of a <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> response to the same request. 1400 1400 </p> 1401 <p id="rfc.section.3.3.2.p.9">A server <em class="bcp14">MUST NOT</em> send a Content-Length header field in any response with a status code of <a href="p2-semantics.html#status.1xx" class="smpl">1xx (Informational)</a> or <a href="p2-semantics.html#status.204" class="smpl">204 (No Content)</a>. A server <em class="bcp14">SHOULD NOT</em> send a Content-Length header field in any <a href="p2-semantics.html#status.2xx" class="smpl">2xx (Successful)</a> response to a CONNECT request (<a href="p2-semantics.html#CONNECT" title="CONNECT">Section 5.3.6</a> of <a href="#Part2" id="rfc.xref.Part2.16"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>).1401 <p id="rfc.section.3.3.2.p.9">A server <em class="bcp14">MUST NOT</em> send a Content-Length header field in any response with a status code of <a href="p2-semantics.html#status.1xx" class="smpl">1xx (Informational)</a> or <a href="p2-semantics.html#status.204" class="smpl">204 (No Content)</a>. A server <em class="bcp14">SHOULD NOT</em> send a Content-Length header field in any <a href="p2-semantics.html#status.2xx" class="smpl">2xx (Successful)</a> response to a CONNECT request (<a href="p2-semantics.html#CONNECT" title="CONNECT">Section 4.3.6</a> of <a href="#Part2" id="rfc.xref.Part2.16"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). 1402 1402 </p> 1403 1403 <p id="rfc.section.3.3.2.p.10">Aside from the cases defined above, in the absence of Transfer-Encoding, an origin server <em class="bcp14">SHOULD</em> send a Content-Length header field when the payload body size is known prior to sending the complete header block. This will … … 1660 1660 </p> 1661 1661 <p id="rfc.section.4.3.p.7">When multiple transfer codings are acceptable, the client <em class="bcp14">MAY</em> rank the codings by preference using a case-insensitive "q" parameter (similar to the qvalues used in content negotiation 1662 fields, <a href="p2-semantics.html#quality.values" title="Quality Values">Section 6.3.1</a> of <a href="#Part2" id="rfc.xref.Part2.17"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). The rank value is a real number in the range 0 through 1, where 0.001 is the least preferred and 1 is the most preferred;1662 fields, <a href="p2-semantics.html#quality.values" title="Quality Values">Section 5.3.1</a> of <a href="#Part2" id="rfc.xref.Part2.17"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). The rank value is a real number in the range 0 through 1, where 0.001 is the least preferred and 1 is the most preferred; 1663 1663 a value of 0 means "not acceptable". 1664 1664 </p> … … 1740 1740 </p> 1741 1741 <div id="authority-form"> 1742 <p id="rfc.section.5.3.p.13"><span id="rfc.iref.a.3"></span> The authority-form of request-target is only used for CONNECT requests (<a href="p2-semantics.html#CONNECT" title="CONNECT">Section 5.3.6</a> of <a href="#Part2" id="rfc.xref.Part2.19"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). When making a CONNECT request to establish a tunnel through one or more proxies, a client <em class="bcp14">MUST</em> send only the target URI's authority component (excluding any userinfo) as the request-target. For example,1742 <p id="rfc.section.5.3.p.13"><span id="rfc.iref.a.3"></span> The authority-form of request-target is only used for CONNECT requests (<a href="p2-semantics.html#CONNECT" title="CONNECT">Section 4.3.6</a> of <a href="#Part2" id="rfc.xref.Part2.19"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). When making a CONNECT request to establish a tunnel through one or more proxies, a client <em class="bcp14">MUST</em> send only the target URI's authority component (excluding any userinfo) as the request-target. For example, 1743 1743 </p> 1744 1744 </div> 1745 1745 <div id="rfc.figure.u.41"></div><pre class="text2">CONNECT www.example.com:80 HTTP/1.1 1746 1746 </pre><div id="asterisk-form"> 1747 <p id="rfc.section.5.3.p.15"><span id="rfc.iref.a.4"></span> The asterisk-form of request-target is only used for a server-wide OPTIONS request (<a href="p2-semantics.html#OPTIONS" title="OPTIONS">Section 5.3.7</a> of <a href="#Part2" id="rfc.xref.Part2.20"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). When a client wishes to request OPTIONS for the server as a whole, as opposed to a specific named resource of that server,1747 <p id="rfc.section.5.3.p.15"><span id="rfc.iref.a.4"></span> The asterisk-form of request-target is only used for a server-wide OPTIONS request (<a href="p2-semantics.html#OPTIONS" title="OPTIONS">Section 4.3.7</a> of <a href="#Part2" id="rfc.xref.Part2.20"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). When a client wishes to request OPTIONS for the server as a whole, as opposed to a specific named resource of that server, 1748 1748 the client <em class="bcp14">MUST</em> send only "*" (%x2A) as the request-target. For example, 1749 1749 </p> … … 1827 1827 <p id="rfc.section.5.6.p.1">HTTP does not include a request identifier for associating a given request message with its corresponding one or more response 1828 1828 messages. Hence, it relies on the order of response arrival to correspond exactly to the order in which requests are made 1829 on the same connection. More than one response message per request only occurs when one or more informational responses (<a href="p2-semantics.html#status.1xx" class="smpl">1xx</a>, see <a href="p2-semantics.html#status.1xx" title="Informational 1xx">Section 7.2</a> of <a href="#Part2" id="rfc.xref.Part2.21"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>) precede a final response to the same request.1829 on the same connection. More than one response message per request only occurs when one or more informational responses (<a href="p2-semantics.html#status.1xx" class="smpl">1xx</a>, see <a href="p2-semantics.html#status.1xx" title="Informational 1xx">Section 6.2</a> of <a href="#Part2" id="rfc.xref.Part2.21"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>) precede a final response to the same request. 1830 1830 </p> 1831 1831 <p id="rfc.section.5.6.p.2">A client that has more than one outstanding request on a connection <em class="bcp14">MUST</em> maintain a list of outstanding requests in the order sent and <em class="bcp14">MUST</em> associate each received response message on that connection to the highest ordered request that has not yet received a final … … 1997 1997 <p id="rfc.section.6.3.1.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. 1998 1998 </p> 1999 <p id="rfc.section.6.3.1.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 5.2.2</a> of <a href="#Part2" id="rfc.xref.Part2.23"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). Otherwise, a premature termination of the transport connection could lead to indeterminate results. A client wishing to1999 <p id="rfc.section.6.3.1.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 4.2.2</a> of <a href="#Part2" id="rfc.xref.Part2.23"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). Otherwise, a premature termination of the transport connection could lead to indeterminate results. A client wishing to 2000 2000 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. 2001 2001 </p> … … 2003 2003 <p id="rfc.section.6.3.2.p.1">Connections can be closed at any time, with or without intention. Implementations ought to anticipate the need to recover 2004 2004 from asynchronous close events. A client <em class="bcp14">MAY</em> open a new connection and retransmit an aborted sequence of requests without user interaction so long as the request sequence 2005 is idempotent (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 5.2.2</a> of <a href="#Part2" id="rfc.xref.Part2.24"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). A client <em class="bcp14">MUST NOT</em> automatically retry non-idempotent request sequences, 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 understanding2005 is idempotent (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 4.2.2</a> of <a href="#Part2" id="rfc.xref.Part2.24"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). A client <em class="bcp14">MUST NOT</em> automatically retry non-idempotent request sequences, 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 2006 2006 of the application <em class="bcp14">MAY</em> substitute for user confirmation. An automatic retry <em class="bcp14">SHOULD NOT</em> be repeated if a second sequence of requests fails. 2007 2007 </p> … … 2096 2096 </p> 2097 2097 <p id="rfc.section.6.7.p.9">The Upgrade header field only applies to switching application-level protocols on the existing connection; it cannot be used 2098 to switch to a protocol on a different connection. For that purpose, it is more appropriate to use a <a href="p2-semantics.html#status.3xx" class="smpl">3xx (Redirection)</a> response (<a href="p2-semantics.html#status.3xx" title="Redirection 3xx">Section 7.4</a> of <a href="#Part2" id="rfc.xref.Part2.25"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>).2098 to switch to a protocol on a different connection. For that purpose, it is more appropriate to use a <a href="p2-semantics.html#status.3xx" class="smpl">3xx (Redirection)</a> response (<a href="p2-semantics.html#status.3xx" title="Redirection 3xx">Section 6.4</a> of <a href="#Part2" id="rfc.xref.Part2.25"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). 2099 2099 </p> 2100 2100 <p id="rfc.section.6.7.p.10">This specification only defines the protocol name "HTTP" for use by the family of Hypertext Transfer Protocols, as defined … … 2479 2479 </p> 2480 2480 <h2 id="rfc.section.8.3"><a href="#rfc.section.8.3">8.3</a> <a id="attack.pathname" href="#attack.pathname">Attacks Based On File and Path Names</a></h2> 2481 <p id="rfc.section.8.3.p.1">Origin servers <em class="bcp14">SHOULD</em> be careful to restrict the documents returnedby HTTP requests to be only those that were intended by the server administrators.2481 <p id="rfc.section.8.3.p.1">Origin servers <em class="bcp14">SHOULD</em> be careful to restrict the documents sent by HTTP requests to be only those that were intended by the server administrators. 2482 2482 If an HTTP server translates HTTP URIs directly into file system calls, the server <em class="bcp14">MUST</em> take special care not to serve files that were not intended to be delivered to HTTP clients. For example, UNIX, Microsoft 2483 2483 Windows, and other operating systems use ".." as a path component to indicate a directory level above the current one. On … … 2512 2512 that most implementations will choose substantially higher limits. 2513 2513 </p> 2514 <p id="rfc.section.8.6.p.3">This specification also provides a way for servers to reject messages that have request-targets that are too long (<a href="p2-semantics.html#status.414" title="414 URI Too Long">Section 7.5.12</a> of <a href="#Part2" id="rfc.xref.Part2.27"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>) or request entities that are too large (<a href="p2-semantics.html#status.4xx" title="Client Error 4xx">Section 7.5</a> of <a href="#Part2" id="rfc.xref.Part2.28"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>).2514 <p id="rfc.section.8.6.p.3">This specification also provides a way for servers to reject messages that have request-targets that are too long (<a href="p2-semantics.html#status.414" title="414 URI Too Long">Section 6.5.12</a> of <a href="#Part2" id="rfc.xref.Part2.27"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>) or request entities that are too large (<a href="p2-semantics.html#status.4xx" title="Client Error 4xx">Section 6.5</a> of <a href="#Part2" id="rfc.xref.Part2.28"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). 2515 2515 </p> 2516 2516 <p id="rfc.section.8.6.p.4">Recipients <em class="bcp14">SHOULD</em> carefully limit the extent to which they read other fields, including (but not limited to) request methods, response status … … 3277 3277 <li><em>Section 3.1.2.1</em> <a href="#rfc.xref.Part2.13">3.3.1</a>, <a href="#rfc.xref.Part2.26">7.4</a></li> 3278 3278 <li><em>Section 3.3</em> <a href="#rfc.xref.Part2.22">5.7.2</a></li> 3279 <li><em>Section 5</em> <a href="#rfc.xref.Part2.6">3.1.1</a></li>3280 <li><em>Section 5.2.2</em> <a href="#rfc.xref.Part2.23">6.3.1</a>, <a href="#rfc.xref.Part2.24">6.3.2</a></li>3281 <li><em>Section 5.3.2</em> <a href="#rfc.xref.Part2.11">3.3</a>, <a href="#rfc.xref.Part2.15">3.3.2</a></li>3282 <li><em>Section 5.3.6</em> <a href="#rfc.xref.Part2.12">3.3</a>, <a href="#rfc.xref.Part2.16">3.3.2</a>, <a href="#rfc.xref.Part2.19">5.3</a></li>3283 <li><em>Section 5.3.7</em> <a href="#rfc.xref.Part2.20">5.3</a></li>3284 <li><em>Section 6.3.1</em> <a href="#rfc.xref.Part2.17">4.3</a></li>3285 <li><em>Section 7</em> <a href="#rfc.xref.Part2.5">2.7.1</a>, <a href="#rfc.xref.Part2.8">3.1.2</a></li>3286 <li><em>Section 7.2</em> <a href="#rfc.xref.Part2.21">5.6</a></li>3287 <li><em>Section 7.3.4</em> <a href="#rfc.xref.Part2.3">2.3</a></li>3288 <li><em>Section 7.4</em> <a href="#rfc.xref.Part2.25">6.7</a></li>3289 <li><em>Section 7.5</em> <a href="#rfc.xref.Part2.28">8.6</a></li>3290 <li><em>Section 7.5.12</em> <a href="#rfc.xref.Part2.7">3.1.1</a>, <a href="#rfc.xref.Part2.27">8.6</a></li>3291 <li><em>Section 8.1.1.2</em> <a href="#rfc.xref.Part2.9">3.2</a></li>3292 <li><em>Section 8.2</em> <a href="#rfc.xref.Part2.14">3.3.2</a></li>3293 <li><em>Section 9.3</em> <a href="#rfc.xref.Part2.10">3.2.1</a></li>3279 <li><em>Section 4</em> <a href="#rfc.xref.Part2.6">3.1.1</a></li> 3280 <li><em>Section 4.2.2</em> <a href="#rfc.xref.Part2.23">6.3.1</a>, <a href="#rfc.xref.Part2.24">6.3.2</a></li> 3281 <li><em>Section 4.3.2</em> <a href="#rfc.xref.Part2.11">3.3</a>, <a href="#rfc.xref.Part2.15">3.3.2</a></li> 3282 <li><em>Section 4.3.6</em> <a href="#rfc.xref.Part2.12">3.3</a>, <a href="#rfc.xref.Part2.16">3.3.2</a>, <a href="#rfc.xref.Part2.19">5.3</a></li> 3283 <li><em>Section 4.3.7</em> <a href="#rfc.xref.Part2.20">5.3</a></li> 3284 <li><em>Section 5.3.1</em> <a href="#rfc.xref.Part2.17">4.3</a></li> 3285 <li><em>Section 6</em> <a href="#rfc.xref.Part2.5">2.7.1</a>, <a href="#rfc.xref.Part2.8">3.1.2</a></li> 3286 <li><em>Section 6.2</em> <a href="#rfc.xref.Part2.21">5.6</a></li> 3287 <li><em>Section 6.3.4</em> <a href="#rfc.xref.Part2.3">2.3</a></li> 3288 <li><em>Section 6.4</em> <a href="#rfc.xref.Part2.25">6.7</a></li> 3289 <li><em>Section 6.5</em> <a href="#rfc.xref.Part2.28">8.6</a></li> 3290 <li><em>Section 6.5.12</em> <a href="#rfc.xref.Part2.7">3.1.1</a>, <a href="#rfc.xref.Part2.27">8.6</a></li> 3291 <li><em>Section 7.1.1.2</em> <a href="#rfc.xref.Part2.9">3.2</a></li> 3292 <li><em>Section 7.2</em> <a href="#rfc.xref.Part2.14">3.3.2</a></li> 3293 <li><em>Section 8.3</em> <a href="#rfc.xref.Part2.10">3.2.1</a></li> 3294 3294 <li><em>Appendix A</em> <a href="#rfc.xref.Part2.2">2.1</a></li> 3295 3295 </ul>
Note: See TracChangeset
for help on using the changeset viewer.