Ignore:
Timestamp:
10/08/13 11:07:48 (7 years ago)
Author:
fielding@…
Message:

Rewrite the sections on Expect and 100-continue to simplify the requirements (remove redundant or impossible conditions) and fix contradictions; addresses #458 #466 #467

File:
1 edited

Legend:

Unmodified
Added
Removed

  • draft-ietf-httpbis/latest/p2-semantics.html

    r2349 r2350  
    449449  }
    450450  @bottom-center {
    451        content: "Expires February 7, 2014";
     451       content: "Expires February 11, 2014";
    452452  }
    453453  @bottom-right {
    … …  
    494494      <meta name="dct.creator" content="Reschke, J. F.">
    495495      <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">
    497497      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    498498      <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.">
    … …  
    522522            <tr>
    523523               <td class="left">Intended status: Standards Track</td>
    524                <td class="right">August 6, 2013</td>
     524               <td class="right">August 10, 2013</td>
    525525            </tr>
    526526            <tr>
    527                <td class="left">Expires: February 7, 2014</td>
     527               <td class="left">Expires: February 11, 2014</td>
    528528               <td class="right"></td>
    529529            </tr>
    … …  
    553553         in progress”.
    554554      </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>
    556556      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    557557      <p>Copyright © 2013 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
    … …  
    637637               <li><a href="#rfc.section.5.1">5.1</a>&nbsp;&nbsp;&nbsp;<a href="#request.controls">Controls</a><ul>
    638638                     <li><a href="#rfc.section.5.1.1">5.1.1</a>&nbsp;&nbsp;&nbsp;<a href="#header.expect">Expect</a><ul>
    639                            <li><a href="#rfc.section.5.1.1.1">5.1.1.1</a>&nbsp;&nbsp;&nbsp;<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>&nbsp;&nbsp;&nbsp;<a href="#expect-100-continue">100-continue Expectation</a></li>
    640640                        </ul>
    641641                     </li>
    … …  
    16701670      <div id="rfc.iref.e.1"></div>
    16711671      <h3 id="rfc.section.5.1.1"><a href="#rfc.section.5.1.1">5.1.1</a>&nbsp;<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>
    16731676      <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>
    16741677 
    … …  
    16791682  <a href="#header.expect" class="smpl">expect-name</a>  = <a href="#imported.abnf" class="smpl">token</a>
    16801683  <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>
    16881692      <div id="rfc.iref.45"></div>
    16891693      <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>&nbsp;<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>&nbsp;<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.
    16971710         </li>
    16981711      </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&nbsp;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>
    17051713      <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>).
    17131724         </li>
    17141725      </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>
    17161727      <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.
    17391732         </li>
    17401733         <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&nbsp;6.2.1</a>).
    17431734         </li>
    17441735      </ul>
    … …  
    22062197                  <td class="left">100</td>
    22072198                  <td class="left">Continue</td>
    2208                   <td class="left"><a href="#status.100" id="rfc.xref.status.100.3" title="100 Continue">Section&nbsp;6.2.1</a></td>
     2199                  <td class="left"><a href="#status.100" id="rfc.xref.status.100.1" title="100 Continue">Section&nbsp;6.2.1</a></td>
    22092200               </tr>
    22102201               <tr>
    … …  
    24362427         server intends to send a final response after the request has been fully received and acted upon.
    24372428      </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&nbsp;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&nbsp;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.
    24412432      </p>
    24422433      <div id="rfc.iref.73"></div>
    … …  
    33703361                  <td class="left">100</td>
    33713362                  <td class="left">Continue</td>
    3372                   <td class="left"><a href="#status.100" id="rfc.xref.status.100.4" title="100 Continue">Section&nbsp;6.2.1</a>
     3363                  <td class="left"><a href="#status.100" id="rfc.xref.status.100.2" title="100 Continue">Section&nbsp;6.2.1</a>
    33733364                  </td>
    33743365               </tr>
    … …  
    42664257      <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&nbsp;4.3.7</a>) and <a href="#TRACE" class="smpl">TRACE</a> (<a href="#TRACE" id="rfc.xref.TRACE.4" title="TRACE">Section&nbsp;4.3.8</a>) request methods have been defined as being safe.
    42674258      </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&nbsp;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&nbsp;5.1.1</a>).
    42704260      </p>
    42714261      <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&nbsp;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.
    … …  
    45414531         <ul class="ind">
    45424532            <li><a id="rfc.index.1" href="#rfc.index.1"><b>1</b></a><ul>
    4543                   <li>100 Continue (status code)&nbsp;&nbsp;<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)&nbsp;&nbsp;<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>
    45444534                  <li>100-continue (expect value)&nbsp;&nbsp;<a href="#rfc.iref.45"><b>5.1.1.1</b></a></li>
    45454535                  <li>101 Switching Protocols (status code)&nbsp;&nbsp;<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>
    … …  
    48404830                     </ul>
    48414831                  </li>
    4842                   <li><em>RFC2068</em>&nbsp;&nbsp;<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>&nbsp;&nbsp;<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>
    48434833                        <li><em>Section 10.3</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2068.2">6.4</a></li>
    48444834                     </ul>
Note: See TracChangeset for help on using the changeset viewer.