Changeset 2350 for draft-ietf-httpbis/latest/p2-semantics.html
- Timestamp:
- 10/08/13 11:07:48 (9 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p2-semantics.html
r2349 r2350 449 449 } 450 450 @bottom-center { 451 content: "Expires February 7, 2014";451 content: "Expires February 11, 2014"; 452 452 } 453 453 @bottom-right { … … 494 494 <meta name="dct.creator" content="Reschke, J. F."> 495 495 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p2-semantics-latest"> 496 <meta name="dct.issued" scheme="ISO8601" content="2013-08- 06">496 <meta name="dct.issued" scheme="ISO8601" content="2013-08-10"> 497 497 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 498 498 <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP/1.1 messages, as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation."> … … 522 522 <tr> 523 523 <td class="left">Intended status: Standards Track</td> 524 <td class="right">August 6, 2013</td>524 <td class="right">August 10, 2013</td> 525 525 </tr> 526 526 <tr> 527 <td class="left">Expires: February 7, 2014</td>527 <td class="left">Expires: February 11, 2014</td> 528 528 <td class="right"></td> 529 529 </tr> … … 553 553 in progress”. 554 554 </p> 555 <p>This Internet-Draft will expire on February 7, 2014.</p>555 <p>This Internet-Draft will expire on February 11, 2014.</p> 556 556 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 557 557 <p>Copyright © 2013 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 637 637 <li><a href="#rfc.section.5.1">5.1</a> <a href="#request.controls">Controls</a><ul> 638 638 <li><a href="#rfc.section.5.1.1">5.1.1</a> <a href="#header.expect">Expect</a><ul> 639 <li><a href="#rfc.section.5.1.1.1">5.1.1.1</a> <a href="# use.of.the.100.status">Use of the 100 (Continue) Status</a></li>639 <li><a href="#rfc.section.5.1.1.1">5.1.1.1</a> <a href="#expect-100-continue">100-continue Expectation</a></li> 640 640 </ul> 641 641 </li> … … 1670 1670 <div id="rfc.iref.e.1"></div> 1671 1671 <h3 id="rfc.section.5.1.1"><a href="#rfc.section.5.1.1">5.1.1</a> <a id="header.expect" href="#header.expect">Expect</a></h3> 1672 <p id="rfc.section.5.1.1.p.1">The "Expect" header field is used to indicate that particular server behaviors are required by the client.</p> 1672 <p id="rfc.section.5.1.1.p.1">The "Expect" header field in a request indicates that a certain set of behaviors (expectations) need to be supported by all 1673 inbound servers in order to properly handle this request. A server that does not understand, or cannot comply with, one or 1674 more of the received expectations <em class="bcp14">MUST</em> respond with an appropriate <a href="#status.4xx" class="smpl">4xx</a> status code, indicating either <a href="#status.417" class="smpl">417 (Expectation Failed)</a> or some other error status that was determined prior to evaluating Expect. 1675 </p> 1673 1676 <div id="rfc.figure.u.20"></div><pre class="inline"><span id="rfc.iref.g.17"></span><span id="rfc.iref.g.18"></span><span id="rfc.iref.g.19"></span><span id="rfc.iref.g.20"></span><span id="rfc.iref.g.21"></span> <a href="#header.expect" class="smpl">Expect</a> = 1#<a href="#header.expect" class="smpl">expectation</a> 1674 1677 … … 1679 1682 <a href="#header.expect" class="smpl">expect-name</a> = <a href="#imported.abnf" class="smpl">token</a> 1680 1683 <a href="#header.expect" class="smpl">expect-value</a> = <a href="#imported.abnf" class="smpl">token</a> / <a href="#imported.abnf" class="smpl">quoted-string</a> 1681 </pre><p id="rfc.section.5.1.1.p.3">If all received Expect header field(s) are syntactically valid but contain an expectation that the recipient does not understand 1682 or cannot comply with, the recipient <em class="bcp14">MUST</em> respond with a <a href="#status.417" class="smpl">417 (Expectation Failed)</a> status code. A recipient of a syntactically invalid Expectation header field <em class="bcp14">MUST</em> respond with a <a href="#status.4xx" class="smpl">4xx</a> status code other than 417. 1683 </p> 1684 <p id="rfc.section.5.1.1.p.4">Comparison is case-insensitive for names (expect-name), and case-sensitive for values (expect-value).</p> 1685 <p id="rfc.section.5.1.1.p.5">An intermediary <em class="bcp14">MUST</em> forward a received Expect header field if the request is forwarded. 1686 </p> 1687 <p id="rfc.section.5.1.1.p.6">Many older HTTP/1.0 and HTTP/1.1 servers do not understand the Expect header field.</p> 1684 </pre><p id="rfc.section.5.1.1.p.3">Comparison is case-insensitive for names (expect-name) and case-sensitive for values (expect-value).</p> 1685 <p id="rfc.section.5.1.1.p.4">An intermediary forwarding a request <em class="bcp14">MUST</em> forward a received Expect header field unless one of the expectations requires otherwise. 1686 </p> 1687 <p id="rfc.section.5.1.1.p.5">The Expect header field was added after the original publication of HTTP/1.1 <a href="#RFC2068" id="rfc.xref.RFC2068.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a> and was not implemented by many of the initial implementations. We are hoping that those implementations have long since been 1688 replaced. However, it remains unlikely that any implementation sending HTTP/1.0 messages will have implemented this field. 1689 A server that receives an Expect header field in an HTTP/1.0 request <em class="bcp14">MUST</em> respond with <a href="#status.417" class="smpl">417 (Expectation Failed)</a>, since this would indicate that the message has been forwarded through an HTTP/1.0 intermediary that does not support Expect 1690 and won't be able to support any expectation. 1691 </p> 1688 1692 <div id="rfc.iref.45"></div> 1689 1693 <div id="rfc.iref.e.2"></div> 1690 <h4 id="rfc.section.5.1.1.1"><a href="#rfc.section.5.1.1.1">5.1.1.1</a> <a id="use.of.the.100.status" href="#use.of.the.100.status">Use of the 100 (Continue) Status</a></h4> 1691 <p id="rfc.section.5.1.1.1.p.1">The only expectation defined by this specification is:</p> 1692 <p id="rfc.section.5.1.1.1.p.2"><dfn>100-continue</dfn> 1693 </p> 1694 <ul class="empty"> 1695 <li>The request includes a payload body and the client will wait for a <a href="#status.100" class="smpl">100 (Continue)</a> response after sending the request header section but before sending the payload body. The 100-continue expectation does not 1696 use any expect-params. 1694 <h4 id="rfc.section.5.1.1.1"><a href="#rfc.section.5.1.1.1">5.1.1.1</a> <a id="expect-100-continue" href="#expect-100-continue">100-continue Expectation</a></h4> 1695 <p id="rfc.section.5.1.1.1.p.1">The <dfn>100-continue</dfn> expectation informs recipients that the client is about to send a (presumably large) payload in this request and wishes to 1696 receive a <a href="#status.100" class="smpl">100 (Continue)</a> interim response if the request-line and header fields are not sufficient to cause an immediate success, redirect, or error 1697 response. This allows the client to wait for an indication that it is worthwhile to send the payload body before actually 1698 doing so, which can improve efficiency when the payload body is huge or when the client anticipates that an error is likely 1699 (e.g., when sending a state-changing method, for the first time, without previously verified authentication credentials). 1700 </p> 1701 <p id="rfc.section.5.1.1.1.p.2">Requirements for clients: </p> 1702 <ul> 1703 <li>A client <em class="bcp14">MUST NOT</em> generate a 100-continue expectation in a request that does not include a payload body. 1704 </li> 1705 <li>A client that will wait for a <a href="#status.100" class="smpl">100 (Continue)</a> response before sending the request payload body <em class="bcp14">MUST</em> send an <a href="#header.expect" class="smpl">Expect</a> header field containing a 100-continue expectation. 1706 </li> 1707 <li>A client that sends a 100-continue expectation is not required to wait for any specific length of time; such a client <em class="bcp14">MAY</em> proceed to send the payload body even if it has not yet received a response. Furthermore, since <a href="#status.100" class="smpl">100 (Continue)</a> responses cannot be sent to an HTTP/1.0 intermediary, and since some servers have failed to implement Expect, such a client <em class="bcp14">SHOULD NOT</em> wait for an indefinite period before sending the payload body. 1708 </li> 1709 <li>A client that sends a 100-continue expectation <em class="bcp14">MUST NOT</em> send an expect-value or expect-param within that expectation. 1697 1710 </li> 1698 1711 </ul> 1699 <p id="rfc.section.5.1.1.1.p.3">The primary purpose of the <a href="#status.100" class="smpl">100 (Continue)</a> status code (<a href="#status.100" id="rfc.xref.status.100.1" title="100 Continue">Section 6.2.1</a>) is to allow a client that is sending a request message with a payload to determine if the origin server is willing to accept 1700 the request (based on the request header fields) before the client sends the payload body. In some cases, it might either 1701 be inappropriate or highly inefficient for the client to send the payload body if the server will reject the message without 1702 looking at the body. 1703 </p> 1704 <p id="rfc.section.5.1.1.1.p.4">Requirements for clients: </p> 1712 <p id="rfc.section.5.1.1.1.p.3">Requirements for origin servers: </p> 1705 1713 <ul> 1706 <li>If a client will wait for a <a href="#status.100" class="smpl">100 (Continue)</a> response before sending the payload body, it <em class="bcp14">MUST</em> send an <a href="#header.expect" class="smpl">Expect</a> header field with the "100-continue" expectation. 1707 </li> 1708 <li>A client <em class="bcp14">MUST NOT</em> send a "100-continue" expectation if it does not intend to send a payload body. 1709 </li> 1710 <li>Because of the presence of older implementations, the protocol allows ambiguous situations in which a client might send "Expect: 1711 100-continue" without receiving either a <a href="#status.417" class="smpl">417 (Expectation Failed)</a> or a <a href="#status.100" class="smpl">100 (Continue)</a> status code. Therefore, when a client sends this header field to an origin server (possibly via a proxy) from which it has 1712 never seen a <a href="#status.100" class="smpl">100 (Continue)</a> status code, the client <em class="bcp14">SHOULD NOT</em> wait for an indefinite period before sending the payload body. 1714 <li>Upon receiving a request that includes a 100-continue expectation, an origin server <em class="bcp14">MUST</em> either respond with <a href="#status.100" class="smpl">100 (Continue)</a> status code and continue to read from the input stream, or respond with a final status code. The origin server <em class="bcp14">MUST NOT</em> wait for the payload body before sending the <a href="#status.100" class="smpl">100 (Continue)</a> response. 1715 </li> 1716 <li>An origin server <em class="bcp14">MUST NOT</em> send a <a href="#status.100" class="smpl">100 (Continue)</a> response if such a request comes from an HTTP/1.0 client. 1717 </li> 1718 <li>An origin server <em class="bcp14">MAY</em> omit a <a href="#status.100" class="smpl">100 (Continue)</a> response if it has already received some or all of the payload body for the corresponding request. 1719 </li> 1720 <li>An origin server that sends a <a href="#status.100" class="smpl">100 (Continue)</a> response <em class="bcp14">MUST</em> ultimately send a final status code, once the payload body is received and processed, unless the connection is closed prematurely. 1721 </li> 1722 <li>An origin server that responds with a final status code before reading the entire payload body <em class="bcp14">SHOULD</em> indicate in that response whether it intends to close the connection or continue reading and discarding the request payload 1723 body (see <a href="p1-messaging.html#persistent.tear-down" title="Tear-down">Section 6.6</a> of <a href="#Part1" id="rfc.xref.Part1.21"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>). 1713 1724 </li> 1714 1725 </ul> 1715 <p id="rfc.section.5.1.1.1.p. 5">Requirements for origin servers: </p>1726 <p id="rfc.section.5.1.1.1.p.4">Requirements for proxies: </p> 1716 1727 <ul> 1717 <li>Upon receiving a request that includes an <a href="#header.expect" class="smpl">Expect</a> header field with the "100-continue" expectation, an origin server <em class="bcp14">MUST</em> either respond with <a href="#status.100" class="smpl">100 (Continue)</a> status code and continue to read from the input stream, or respond with a final status code. The origin server <em class="bcp14">MUST NOT</em> wait for the payload body before sending the <a href="#status.100" class="smpl">100 (Continue)</a> response. If the origin server responds with a final status code, it <em class="bcp14">MUST NOT</em> have performed the request method and <em class="bcp14">MAY</em> either close the connection or continue to read and discard the remainder of the request. 1718 </li> 1719 <li>An origin server <em class="bcp14">SHOULD NOT</em> send a <a href="#status.100" class="smpl">100 (Continue)</a> response if the request message does not include an <a href="#header.expect" class="smpl">Expect</a> header field with the "100-continue" expectation, and <em class="bcp14">MUST NOT</em> send a <a href="#status.100" class="smpl">100 (Continue)</a> response if such a request comes from an HTTP/1.0 (or earlier) client. There is an exception to this rule: for compatibility 1720 with <a href="#RFC2068" id="rfc.xref.RFC2068.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>, a server <em class="bcp14">MAY</em> send a <a href="#status.100" class="smpl">100 (Continue)</a> status code in response to an HTTP/1.1 PUT or POST request that does not include an Expect header field with the "100-continue" 1721 expectation. This exception, the purpose of which is to minimize any client processing delays associated with an undeclared 1722 wait for <a href="#status.100" class="smpl">100 (Continue)</a> status code, applies only to HTTP/1.1 requests, and not to requests with any other HTTP-version value. 1723 </li> 1724 <li>An origin server <em class="bcp14">MAY</em> omit a <a href="#status.100" class="smpl">100 (Continue)</a> response if it has already received some or all of the payload body for the corresponding request. 1725 </li> 1726 <li>An origin server that sends a <a href="#status.100" class="smpl">100 (Continue)</a> response <em class="bcp14">MUST</em> ultimately send a final status code, once the payload body is received and processed, unless the connection is closed prematurely. 1727 </li> 1728 <li>If an origin server receives a request that does not include an <a href="#header.expect" class="smpl">Expect</a> header field with the "100-continue" expectation, the request includes a payload body, and the server responds with a final 1729 status code before reading the entire payload body from the connection, then the server <em class="bcp14">SHOULD</em> indicate in the final response whether it intends to close the connection or to continue reading and discarding the request 1730 payload body (see <a href="p1-messaging.html#persistent.tear-down" title="Tear-down">Section 6.6</a> of <a href="#Part1" id="rfc.xref.Part1.21"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>). 1731 </li> 1732 </ul> 1733 <p id="rfc.section.5.1.1.1.p.6">Requirements for proxies: </p> 1734 <ul> 1735 <li>If a proxy receives a request that includes an <a href="#header.expect" class="smpl">Expect</a> header field with the "100-continue" expectation, and the proxy either knows that the next-hop server complies with HTTP/1.1 1736 or higher, or does not know the HTTP version of the next-hop server, it <em class="bcp14">MUST</em> forward the request, including the Expect header field. 1737 </li> 1738 <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 <a href="#status.417" class="smpl">417 (Expectation Failed)</a> status code. 1728 <li>A proxy that forwards a request received with a 100-continue expectation <em class="bcp14">MUST</em> send a 100-continue expectation in the forwarded request. 1729 </li> 1730 <li>A proxy <em class="bcp14">MUST NOT</em> forward a request received with a 100-continue expectation if it knows the advertised HTTP version of the next-hop server 1731 is HTTP/1.0; instead, such a proxy <em class="bcp14">MUST</em> respond with a <a href="#status.417" class="smpl">417 (Expectation Failed)</a> status code. 1739 1732 </li> 1740 1733 <li>Proxies <em class="bcp14">SHOULD</em> maintain a record of the HTTP version numbers received from recently-referenced next-hop servers. 1741 </li>1742 <li>A proxy <em class="bcp14">MUST NOT</em> forward a <a href="#status.100" class="smpl">100 (Continue)</a> response if the request message was received from an HTTP/1.0 (or earlier) client and did not include an <a href="#header.expect" class="smpl">Expect</a> header field with the "100-continue" expectation. This requirement overrides the general rule for forwarding of <a href="#status.1xx" class="smpl">1xx</a> responses (see <a href="#status.100" id="rfc.xref.status.100.2" title="100 Continue">Section 6.2.1</a>).1743 1734 </li> 1744 1735 </ul> … … 2206 2197 <td class="left">100</td> 2207 2198 <td class="left">Continue</td> 2208 <td class="left"><a href="#status.100" id="rfc.xref.status.100. 3" title="100 Continue">Section 6.2.1</a></td>2199 <td class="left"><a href="#status.100" id="rfc.xref.status.100.1" title="100 Continue">Section 6.2.1</a></td> 2209 2200 </tr> 2210 2201 <tr> … … 2436 2427 server intends to send a final response after the request has been fully received and acted upon. 2437 2428 </p> 2438 <p id="rfc.section.6.2.1.p.2">When the request contains an <a href="#header.expect" class="smpl">Expect</a> header field that includes a <a href="# use.of.the.100.status" class="smpl">100-continue</a> expectation, the 100 response indicates that the server wishes to receive the request payload body, as described in <a href="#use.of.the.100.status" title="Use of the 100 (Continue) Status">Section 5.1.1.1</a>. The client ought to continue sending the request and discard the 100 response.2439 </p> 2440 <p id="rfc.section.6.2.1.p.3">If the request did not contain an <a href="#header.expect" class="smpl">Expect</a> header field containing the <a href="# use.of.the.100.status" class="smpl">100-continue</a> expectation, the client can simply discard this interim response.2429 <p id="rfc.section.6.2.1.p.2">When the request contains an <a href="#header.expect" class="smpl">Expect</a> header field that includes a <a href="#expect-100-continue" class="smpl">100-continue</a> expectation, the 100 response indicates that the server wishes to receive the request payload body, as described in <a href="#expect-100-continue" title="100-continue Expectation">Section 5.1.1.1</a>. The client ought to continue sending the request and discard the 100 response. 2430 </p> 2431 <p id="rfc.section.6.2.1.p.3">If the request did not contain an <a href="#header.expect" class="smpl">Expect</a> header field containing the <a href="#expect-100-continue" class="smpl">100-continue</a> expectation, the client can simply discard this interim response. 2441 2432 </p> 2442 2433 <div id="rfc.iref.73"></div> … … 3370 3361 <td class="left">100</td> 3371 3362 <td class="left">Continue</td> 3372 <td class="left"><a href="#status.100" id="rfc.xref.status.100. 4" title="100 Continue">Section 6.2.1</a>3363 <td class="left"><a href="#status.100" id="rfc.xref.status.100.2" title="100 Continue">Section 6.2.1</a> 3373 3364 </td> 3374 3365 </tr> … … 4266 4257 <p id="rfc.section.B.p.10">The <a href="#OPTIONS" class="smpl">OPTIONS</a> (<a href="#OPTIONS" id="rfc.xref.OPTIONS.4" title="OPTIONS">Section 4.3.7</a>) and <a href="#TRACE" class="smpl">TRACE</a> (<a href="#TRACE" id="rfc.xref.TRACE.4" title="TRACE">Section 4.3.8</a>) request methods have been defined as being safe. 4267 4258 </p> 4268 <p id="rfc.section.B.p.11">The definition of <a href="#header.expect" class="smpl">Expect</a> has been both fixed to allow parameters for value-less expectations and simplified to allow trailing semicolons after "100-continue" 4269 (<a href="#header.expect" id="rfc.xref.header.expect.4" title="Expect">Section 5.1.1</a>). 4259 <p id="rfc.section.B.p.11">The definition of <a href="#header.expect" class="smpl">Expect</a> has been fixed to allow parameters for value-less expectations and simplified to allow trailing semicolons (<a href="#header.expect" id="rfc.xref.header.expect.4" title="Expect">Section 5.1.1</a>). 4270 4260 </p> 4271 4261 <p id="rfc.section.B.p.12">The <a href="#header.max-forwards" class="smpl">Max-Forwards</a> header field (<a href="#header.max-forwards" id="rfc.xref.header.max-forwards.5" title="Max-Forwards">Section 5.1.2</a>) has been restricted to the <a href="#OPTIONS" class="smpl">OPTIONS</a> and <a href="#TRACE" class="smpl">TRACE</a> methods; previously, extension methods could have used it as well. … … 4541 4531 <ul class="ind"> 4542 4532 <li><a id="rfc.index.1" href="#rfc.index.1"><b>1</b></a><ul> 4543 <li>100 Continue (status code) <a href="#rfc.xref.status.100.1"> 5.1.1.1</a>, <a href="#rfc.xref.status.100.2">5.1.1.1</a>, <a href="#rfc.xref.status.100.3">6.1</a>, <a href="#rfc.iref.73"><b>6.2.1</b></a>, <a href="#rfc.xref.status.100.4">8.2.3</a></li>4533 <li>100 Continue (status code) <a href="#rfc.xref.status.100.1">6.1</a>, <a href="#rfc.iref.73"><b>6.2.1</b></a>, <a href="#rfc.xref.status.100.2">8.2.3</a></li> 4544 4534 <li>100-continue (expect value) <a href="#rfc.iref.45"><b>5.1.1.1</b></a></li> 4545 4535 <li>101 Switching Protocols (status code) <a href="#rfc.xref.status.101.1">6.1</a>, <a href="#rfc.iref.73"><b>6.2.2</b></a>, <a href="#rfc.xref.status.101.2">8.2.3</a></li> … … 4840 4830 </ul> 4841 4831 </li> 4842 <li><em>RFC2068</em> <a href="#rfc.xref.RFC2068.1">5.1.1 .1</a>, <a href="#rfc.xref.RFC2068.2">6.4</a>, <a href="#RFC2068"><b>11.2</b></a><ul>4832 <li><em>RFC2068</em> <a href="#rfc.xref.RFC2068.1">5.1.1</a>, <a href="#rfc.xref.RFC2068.2">6.4</a>, <a href="#RFC2068"><b>11.2</b></a><ul> 4843 4833 <li><em>Section 10.3</em> <a href="#rfc.xref.RFC2068.2">6.4</a></li> 4844 4834 </ul>
Note: See TracChangeset
for help on using the changeset viewer.