Ignore:
Timestamp:
10/08/13 11:07:48 (10 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.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.