Changeset 2350


Ignore:
Timestamp:
Aug 10, 2013, 4:07:48 AM (6 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

Location:
draft-ietf-httpbis/latest
Files:
2 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>
  • draft-ietf-httpbis/latest/p2-semantics.xml

    r2349 r2350  
    18111811  <x:anchor-alias value="expect-value"/>
    18121812<t>
    1813    The "Expect" header field is used to indicate that particular
    1814    server behaviors are required by the client.
     1813   The "Expect" header field in a request indicates that a certain set of
     1814   behaviors (expectations) need to be supported by all inbound servers in
     1815   order to properly handle this request.
     1816   A server that does not understand, or cannot comply with, one or more of
     1817   the received expectations &MUST; respond with an appropriate
     1818   <x:ref>4xx</x:ref> status code, indicating either
     1819   <x:ref>417 (Expectation Failed)</x:ref> or some other error status that was
     1820   determined prior to evaluating Expect.
    18151821</t>
    18161822<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Expect"/><iref primary="true" item="Grammar" subitem="expectation"/><iref primary="true" item="Grammar" subitem="expect-param"/><iref primary="true" item="Grammar" subitem="expect-value"/><iref primary="true" item="Grammar" subitem="expect-name"/>
     
    18251831</artwork></figure>
    18261832<t>
    1827    If all received Expect header field(s) are syntactically valid but contain
    1828    an expectation that the recipient does not understand or cannot comply with,
    1829    the recipient &MUST; respond with a <x:ref>417 (Expectation Failed)</x:ref> status code. A
    1830    recipient of a syntactically invalid Expectation header field &MUST; respond
    1831    with a <x:ref>4xx</x:ref> status code other than 417.
    1832 </t>
    1833 <t>
    1834    Comparison is case-insensitive for names (expect-name), and case-sensitive
     1833   Comparison is case-insensitive for names (expect-name) and case-sensitive
    18351834   for values (expect-value).
    18361835</t>
    18371836<t>
    1838    An intermediary &MUST; forward a received Expect header field if the
    1839    request is forwarded.
    1840 </t>
    1841 <t>
    1842    Many older HTTP/1.0 and HTTP/1.1 servers do not understand the Expect
    1843    header field.
    1844 </t>
    1845 
    1846 <section title="Use of the 100 (Continue) Status" anchor="use.of.the.100.status">
     1837   An intermediary forwarding a request &MUST; forward a received Expect
     1838   header field unless one of the expectations requires otherwise.
     1839</t>
     1840<t>
     1841   The Expect header field was added after the original publication of
     1842   HTTP/1.1 <xref target="RFC2068"/> and was not implemented by many of the
     1843   initial implementations. We are hoping that those implementations have long
     1844   since been replaced. However, it remains unlikely that any implementation
     1845   sending HTTP/1.0 messages will have implemented this field.
     1846   A server that receives an Expect header field in an HTTP/1.0 request &MUST;
     1847   respond with <x:ref>417 (Expectation Failed)</x:ref>, since this would
     1848   indicate that the message has been forwarded through an HTTP/1.0
     1849   intermediary that does not support Expect and won't be able to support
     1850   any expectation.
     1851</t>
     1852
     1853<section title="100-continue Expectation" anchor="expect-100-continue">
    18471854  <iref primary="true" item="100-continue (expect value)"/>
    18481855  <iref primary="true" item="Expect Values" subitem="100-continue"/>
    18491856  <x:anchor-alias value="100-continue"/>
    18501857<t>
    1851    The only expectation defined by this specification is:
    1852 </t>
    1853 <t>
    1854   <x:dfn>100-continue</x:dfn>
    1855    <list>
    1856       <t>
    1857         The request includes a payload body and the client will wait for a
    1858         <x:ref>100 (Continue)</x:ref> response after sending the request
    1859         header section but before sending the payload body.
    1860         The 100-continue expectation does not use any expect-params.
    1861       </t>
    1862    </list>
    1863 </t>
    1864 <t>
    1865    The primary purpose of the <x:ref>100 (Continue)</x:ref> status code
    1866    (<xref target='status.100'/>)
    1867    is to allow a client that is sending a request message with a payload
    1868    to determine if the origin server is willing to accept the request
    1869    (based on the request header fields) before the client sends the payload
    1870    body. In some cases, it might either be inappropriate or highly
    1871    inefficient for the client to send the payload body if the server will
    1872    reject the message without looking at the body.
     1858   The <x:dfn>100-continue</x:dfn> expectation informs recipients that the
     1859   client is about to send a (presumably large) payload in this request and
     1860   wishes to receive a <x:ref>100 (Continue)</x:ref> interim response if the
     1861   request-line and header fields are not sufficient to cause an immediate
     1862   success, redirect, or error response. This allows the client to wait for an
     1863   indication that it is worthwhile to send the payload body before actually
     1864   doing so, which can improve efficiency when the payload body is huge or
     1865   when the client anticipates that an error is likely (e.g., when sending a
     1866   state-changing method, for the first time, without previously verified
     1867   authentication credentials).
    18731868</t>
    18741869<t>
     
    18761871  <list style="symbols">
    18771872    <t>
    1878      If a client will wait for a <x:ref>100 (Continue)</x:ref> response before
    1879      sending the payload body, it &MUST; send an <x:ref>Expect</x:ref> header
    1880      field with the "100-continue" expectation.
     1873     A client &MUST-NOT; generate a 100-continue expectation in a request that
     1874     does not include a payload body.
    18811875    </t>
    18821876    <t>
    1883      A client &MUST-NOT; send a "100-continue" expectation if it does not
    1884      intend to send a payload body.
     1877     A client that will wait for a <x:ref>100 (Continue)</x:ref> response
     1878     before sending the request payload body &MUST; send an
     1879     <x:ref>Expect</x:ref> header field containing a 100-continue expectation.
    18851880    </t>
    18861881    <t>
    1887      Because of the presence of older implementations, the protocol allows
    1888      ambiguous situations in which a client might send "Expect: 100-continue"
    1889      without receiving either a <x:ref>417 (Expectation Failed)</x:ref> or a
    1890      <x:ref>100 (Continue)</x:ref> status code. Therefore, when a client sends
    1891      this header field to an origin server (possibly via a proxy) from which
    1892      it has never seen a <x:ref>100 (Continue)</x:ref> status code, the
    1893      client &SHOULD-NOT; wait for an indefinite period before sending the
    1894      payload body.
     1882     A client that sends a 100-continue expectation is not required to wait
     1883     for any specific length of time; such a client &MAY; proceed to send the
     1884     payload body even if it has not yet received a response. Furthermore,
     1885     since <x:ref>100 (Continue)</x:ref> responses cannot be sent to an
     1886     HTTP/1.0 intermediary, and since some servers have failed to implement
     1887     Expect, such a client &SHOULD-NOT; wait for an indefinite period before
     1888     sending the payload body.
     1889    </t>
     1890    <t>
     1891     A client that sends a 100-continue expectation &MUST-NOT; send an
     1892     expect-value or expect-param within that expectation.
    18951893    </t>
    18961894  </list>
     
    18991897   Requirements for origin servers:
    19001898  <list style="symbols">
    1901     <t> Upon receiving a request that includes an <x:ref>Expect</x:ref> header
    1902         field with the "100-continue" expectation, an origin server &MUST;
    1903         either respond with <x:ref>100 (Continue)</x:ref> status code and
    1904         continue to read from the input stream, or respond with a final status
    1905         code. The origin server &MUST-NOT; wait for the payload body before
    1906         sending the <x:ref>100 (Continue)</x:ref> response. If the origin
    1907         server responds with a final status code, it &MUST-NOT; have performed
    1908         the request method and &MAY; either close the connection or continue
    1909         to read and discard the remainder of the request.
     1899    <t>
     1900     Upon receiving a request that includes a 100-continue expectation, an
     1901     origin server &MUST; either respond with <x:ref>100 (Continue)</x:ref>
     1902     status code and continue to read from the input stream, or respond with a
     1903     final status code. The origin server &MUST-NOT; wait for the payload body
     1904     before sending the <x:ref>100 (Continue)</x:ref> response.
    19101905    </t>
    1911     <t> An origin server &SHOULD-NOT; send a <x:ref>100 (Continue)</x:ref>
    1912         response if the request message does not include an
    1913         <x:ref>Expect</x:ref> header field with the "100-continue"
    1914         expectation, and &MUST-NOT; send a <x:ref>100 (Continue)</x:ref>
    1915         response if such a request comes from an HTTP/1.0 (or earlier) client.
    1916         There is an exception to this rule: for compatibility with
    1917         <xref target="RFC2068"/>, a server &MAY; send a
    1918         <x:ref>100 (Continue)</x:ref> status code in response to an HTTP/1.1
    1919         PUT or POST request that does not include an Expect header field with
    1920         the "100-continue" expectation. This exception, the purpose of which
    1921         is to minimize any client processing delays associated with an
    1922         undeclared wait for <x:ref>100 (Continue)</x:ref> status code, applies
    1923         only to HTTP/1.1 requests, and not to requests with any other
    1924         HTTP-version value.
     1906    <t>
     1907     An origin server &MUST-NOT; send a <x:ref>100 (Continue)</x:ref> response
     1908     if such a request comes from an HTTP/1.0 client.
    19251909    </t>
    1926     <t> An origin server &MAY; omit a <x:ref>100 (Continue)</x:ref> response
    1927         if it has already received some or all of the payload body for the
    1928         corresponding request.
     1910    <t>
     1911     An origin server &MAY; omit a <x:ref>100 (Continue)</x:ref> response if
     1912     it has already received some or all of the payload body for the
     1913     corresponding request.
    19291914    </t>
    1930     <t> An origin server that sends a <x:ref>100 (Continue)</x:ref> response
    1931         &MUST; ultimately send a final status code, once the payload body is
    1932         received and processed, unless the connection is closed prematurely.
     1915    <t>
     1916     An origin server that sends a <x:ref>100 (Continue)</x:ref> response
     1917     &MUST; ultimately send a final status code, once the payload body is
     1918     received and processed, unless the connection is closed prematurely.
    19331919    </t>
    1934     <t> If an origin server receives a request that does not include an
    1935         <x:ref>Expect</x:ref> header field with the "100-continue" expectation,
    1936         the request includes a payload body, and the server responds
    1937         with a final status code before reading the entire payload body
    1938         from the connection, then the server &SHOULD; indicate in the final
    1939         response whether it intends to close the connection or to continue
    1940         reading and discarding the request payload body
    1941         (see &persistent-tear-down;).
    1942       </t>
    1943     </list>
     1920    <t>
     1921     An origin server that responds with a final status code before reading
     1922     the entire payload body &SHOULD; indicate in that response whether it
     1923     intends to close the connection or continue reading and discarding the
     1924     request payload body (see &persistent-tear-down;).
     1925    </t>
     1926  </list>
    19441927</t>
    19451928<t>
    19461929   Requirements for proxies:
    19471930  <list style="symbols">
    1948     <t> If a proxy receives a request that includes an <x:ref>Expect</x:ref>
    1949         header field with the "100-continue" expectation, and the proxy
    1950         either knows that the next-hop server complies with HTTP/1.1 or
    1951         higher, or does not know the HTTP version of the next-hop
    1952         server, it &MUST; forward the request, including the Expect header
    1953         field.
     1931    <t>
     1932     A proxy that forwards a request received with a 100-continue expectation
     1933     &MUST; send a 100-continue expectation in the forwarded request.
    19541934    </t>
    1955     <t> If the proxy knows that the version of the next-hop server is
    1956         HTTP/1.0 or lower, it &MUST-NOT; forward the request, and it &MUST;
    1957         respond with a <x:ref>417 (Expectation Failed)</x:ref> status code.
     1935    <t>
     1936     A proxy &MUST-NOT; forward a request received with a 100-continue
     1937     expectation if it knows the advertised HTTP version of the next-hop
     1938     server is HTTP/1.0; instead, such a proxy &MUST; respond with a
     1939     <x:ref>417 (Expectation Failed)</x:ref> status code.
    19581940    </t>
    1959     <t> Proxies &SHOULD; maintain a record of the HTTP version
    1960         numbers received from recently-referenced next-hop servers.
    1961     </t>
    1962     <t> A proxy &MUST-NOT; forward a <x:ref>100 (Continue)</x:ref> response if
    1963         the request message was received from an HTTP/1.0 (or earlier)
    1964         client and did not include an <x:ref>Expect</x:ref> header field with
    1965         the "100-continue" expectation. This requirement overrides the
    1966         general rule for forwarding of <x:ref>1xx</x:ref> responses
    1967         (see <xref target='status.100'/>).
     1941    <t>
     1942     Proxies &SHOULD; maintain a record of the HTTP version numbers received
     1943     from recently-referenced next-hop servers.
    19681944    </t>
    19691945  </list>
     
    27642740   includes a <x:ref>100-continue</x:ref> expectation, the 100 response
    27652741   indicates that the server wishes to receive the request payload body,
    2766    as described in <xref target="use.of.the.100.status"/>.  The client
     2742   as described in <xref target="expect-100-continue"/>.  The client
    27672743   ought to continue sending the request and discard the 100 response.
    27682744</t>
     
    60035979</t>
    60045980<t>
    6005    The definition of <x:ref>Expect</x:ref> has been both fixed to allow
     5981   The definition of <x:ref>Expect</x:ref> has been fixed to allow
    60065982   parameters for value-less expectations and simplified to allow trailing
    6007    semicolons after "100-continue" (<xref target="header.expect"/>).
     5983   semicolons (<xref target="header.expect"/>).
    60085984</t>
    60095985<t>
Note: See TracChangeset for help on using the changeset viewer.