Ignore:
Timestamp:
13/09/13 09:05:47 (7 years ago)
Author:
fielding@…
Message:

Remove the Expect extension mechanism to focus on the definition of 100-continue; allow proxies to generate 100 on behalf of inbound HTTP/1.0 servers; addresses #458 and #468

File:
1 edited

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpbis/latest/p2-semantics.xml

    r2376 r2380  
    18171817<section title="Expect" anchor="header.expect">
    18181818  <iref primary="true" item="Expect header field" x:for-anchor=""/>
     1819  <iref primary="true" item="100-continue (expect value)"/>
    18191820  <x:anchor-alias value="Expect"/>
    18201821  <x:anchor-alias value="expectation"/>
    1821   <x:anchor-alias value="expect-param"/>
    1822   <x:anchor-alias value="expect-name"/>
    1823   <x:anchor-alias value="expect-value"/>
    1824 <t>
    1825    The "Expect" header field in a request indicates that a certain set of
    1826    behaviors (expectations) need to be supported by all inbound servers in
    1827    order to properly handle this request.
    1828    A server that does not understand, or cannot comply with, one or more of
    1829    the received expectations &MUST; respond with an appropriate
    1830    <x:ref>4xx</x:ref> status code, indicating either
    1831    <x:ref>417 (Expectation Failed)</x:ref> or some other error status that was
    1832    determined prior to evaluating Expect.
    1833 </t>
    1834 <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"/>
    1835   <x:ref>Expect</x:ref>       = 1#<x:ref>expectation</x:ref>
    1836  
    1837   <x:ref>expectation</x:ref>  = <x:ref>expect-name</x:ref> [ <x:ref>BWS</x:ref> "=" <x:ref>BWS</x:ref> <x:ref>expect-value</x:ref> ]
    1838                              *( <x:ref>OWS</x:ref> ";" [ <x:ref>OWS</x:ref> <x:ref>expect-param</x:ref> ] )
    1839   <x:ref>expect-param</x:ref> = <x:ref>expect-name</x:ref> [ <x:ref>BWS</x:ref> "=" <x:ref>BWS</x:ref> <x:ref>expect-value</x:ref> ]
    1840  
    1841   <x:ref>expect-name</x:ref>  = <x:ref>token</x:ref>
    1842   <x:ref>expect-value</x:ref> = <x:ref>token</x:ref> / <x:ref>quoted-string</x:ref>
     1822  <x:anchor-alias value="100-continue"/>
     1823<t>
     1824   The "Expect" header field in a request indicates a certain set of
     1825   behaviors (expectations) that need to be supported by the server in
     1826   order to properly handle this request. The only such expectation defined
     1827   by this specification is <x:ref>100-continue</x:ref>.
     1828</t>
     1829<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Expect"/>
     1830  <x:ref>Expect</x:ref>  = "100-continue"
    18431831</artwork></figure>
    18441832<t>
    1845    Comparison is case-insensitive for names (expect-name) and case-sensitive
    1846    for values (expect-value).
    1847 </t>
    1848 <t>
    1849    An intermediary forwarding a request &MUST; forward a received Expect
    1850    header field unless one of the expectations requires otherwise.
    1851 </t>
    1852 <t>
    1853    The Expect header field was added after the original publication of
    1854    HTTP/1.1 <xref target="RFC2068"/> and was not implemented by many of the
    1855    initial implementations. We are hoping that those implementations have long
    1856    since been replaced. However, it remains unlikely that any implementation
    1857    sending HTTP/1.0 messages will have implemented this field.
    1858    A server that receives an Expect header field in an HTTP/1.0 request &MUST;
    1859    respond with <x:ref>417 (Expectation Failed)</x:ref>, since this would
    1860    indicate that the message has been forwarded through an HTTP/1.0
    1861    intermediary that does not support Expect and won't be able to support
    1862    any expectation.
    1863 </t>
    1864 
    1865 <section title="100-continue Expectation" anchor="expect-100-continue">
    1866   <iref primary="true" item="100-continue (expect value)"/>
    1867   <iref primary="true" item="Expect Values" subitem="100-continue"/>
    1868   <x:anchor-alias value="100-continue"/>
    1869 <t>
    1870    The <x:dfn>100-continue</x:dfn> expectation informs recipients that the
    1871    client is about to send a (presumably large) payload in this request and
    1872    wishes to receive a <x:ref>100 (Continue)</x:ref> interim response if the
    1873    request-line and header fields are not sufficient to cause an immediate
     1833   The Expect field-value is case-insensitive.
     1834</t>
     1835<t>
     1836   A server that receives an Expect field-value other than
     1837   <x:ref>100-continue</x:ref> &MAY; respond with a
     1838   <x:ref>417 (Expectation Failed)</x:ref> status code to indicate that the
     1839   unexpected expectation cannot be met.
     1840</t>
     1841<t>
     1842   A <x:dfn>100-continue</x:dfn> expectation informs recipients that the
     1843   client is about to send a (presumably large) message body in this request
     1844   and wishes to receive a <x:ref>100 (Continue)</x:ref> interim response if
     1845   the request-line and header fields are not sufficient to cause an immediate
    18741846   success, redirect, or error response. This allows the client to wait for an
    1875    indication that it is worthwhile to send the payload body before actually
    1876    doing so, which can improve efficiency when the payload body is huge or
     1847   indication that it is worthwhile to send the message body before actually
     1848   doing so, which can improve efficiency when the message body is huge or
    18771849   when the client anticipates that an error is likely (e.g., when sending a
    18781850   state-changing method, for the first time, without previously verified
    18791851   authentication credentials).
     1852</t>
     1853<t>
     1854   For example, a request that begins with
     1855</t>
     1856<figure><artwork type="message/http; msgtype=&#34;request&#34;" x:indent-with="  ">
     1857PUT /somewhere/fun HTTP/1.1
     1858Host: origin.example.com
     1859Content-Type: video/h264
     1860Content-Length: 1234567890987
     1861Expect: 100-continue
     1862
     1863</artwork></figure>
     1864<t>
     1865   allows the origin server to immediately respond with an error message, such
     1866   as <x:ref>401 (Unauthorized)</x:ref> or <x:ref>405 (Method Not Allowed)</x:ref>,
     1867   before the client starts filling the pipes with an unnecessary data
     1868   transfer.
    18801869</t>
    18811870<t>
     
    18841873    <t>
    18851874     A client &MUST-NOT; generate a 100-continue expectation in a request that
    1886      does not include a payload body.
     1875     does not include a message body.
    18871876    </t>
    18881877    <t>
    18891878     A client that will wait for a <x:ref>100 (Continue)</x:ref> response
    1890      before sending the request payload body &MUST; send an
     1879     before sending the request message body &MUST; send an
    18911880     <x:ref>Expect</x:ref> header field containing a 100-continue expectation.
    18921881    </t>
     
    18941883     A client that sends a 100-continue expectation is not required to wait
    18951884     for any specific length of time; such a client &MAY; proceed to send the
    1896      payload body even if it has not yet received a response. Furthermore,
    1897      since <x:ref>100 (Continue)</x:ref> responses cannot be sent to an
    1898      HTTP/1.0 intermediary, and since some servers have failed to implement
    1899      Expect, such a client &SHOULD-NOT; wait for an indefinite period before
    1900      sending the payload body.
    1901     </t>
    1902     <t>
    1903      A client that sends a 100-continue expectation &MUST-NOT; send an
    1904      expect-value or expect-param within that expectation.
     1885     message body even if it has not yet received a response. Furthermore,
     1886     since <x:ref>100 (Continue)</x:ref> responses cannot be sent through an
     1887     HTTP/1.0 intermediary, such a client &SHOULD-NOT; wait for an indefinite
     1888     period before sending the message body.
    19051889    </t>
    19061890    <t>
     
    19141898</t>
    19151899<t>
    1916    Requirements for origin servers:
     1900   Requirements for servers:
    19171901  <list style="symbols">
    19181902    <t>
    1919      Upon receiving a request that includes a 100-continue expectation, an
    1920      origin server &MUST; either respond with <x:ref>100 (Continue)</x:ref>
    1921      status code and continue to read from the input stream, or respond with a
    1922      final status code. The origin server &MUST-NOT; wait for the payload body
    1923      before sending the <x:ref>100 (Continue)</x:ref> response.
     1903     A server that receives a 100-continue expectation in an HTTP/1.0 request
     1904     &MUST; ignore that expectation.
    19241905    </t>
    19251906    <t>
    1926      An origin server &MUST-NOT; send a <x:ref>100 (Continue)</x:ref> response
    1927      if such a request comes from an HTTP/1.0 client.
     1907     A server &MAY; omit sending a <x:ref>100 (Continue)</x:ref> response if
     1908     it has already received some or all of the message body for the
     1909     corresponding request, or if the framing indicates that there is no
     1910     message body.
    19281911    </t>
    19291912    <t>
    1930      An origin server &MAY; omit a <x:ref>100 (Continue)</x:ref> response if
    1931      it has already received some or all of the payload body for the
    1932      corresponding request.
     1913     A server that sends a <x:ref>100 (Continue)</x:ref> response &MUST;
     1914     ultimately send a final status code, once the message body is received
     1915     and processed, unless the connection is closed prematurely.
    19331916    </t>
    19341917    <t>
    1935      An origin server that sends a <x:ref>100 (Continue)</x:ref> response
    1936      &MUST; ultimately send a final status code, once the payload body is
    1937      received and processed, unless the connection is closed prematurely.
    1938     </t>
    1939     <t>
    1940      An origin server that responds with a final status code before reading
    1941      the entire payload body &SHOULD; indicate in that response whether it
     1918     A server that responds with a final status code before reading
     1919     the entire message body &SHOULD; indicate in that response whether it
    19421920     intends to close the connection or continue reading and discarding the
    1943      request payload body (see &persistent-tear-down;).
     1921     request message (see &persistent-tear-down;).
    19441922    </t>
    19451923  </list>
    19461924</t>
    19471925<t>
    1948    Requirements for proxies:
    1949   <list style="symbols">
    1950     <t>
    1951      A proxy that forwards a request received with a 100-continue expectation
    1952      &MUST; send a 100-continue expectation in the forwarded request.
    1953     </t>
    1954     <t>
    1955      A proxy &MUST-NOT; forward a request received with a 100-continue
    1956      expectation if it knows the advertised HTTP version of the next-hop
    1957      server is HTTP/1.0; instead, such a proxy &MUST; respond with a
    1958      <x:ref>417 (Expectation Failed)</x:ref> status code.
    1959     </t>
    1960     <t>
    1961      Proxies &SHOULD; maintain a record of the HTTP version numbers received
    1962      from recently-referenced next-hop servers.
    1963     </t>
    1964   </list>
    1965 </t>
    1966 </section>
     1926   An origin server &MUST;, upon receiving an HTTP/1.1 (or later) request-line
     1927   and a complete header section that contains a 100-continue expectation and
     1928   indicates a request message body will follow, either send an immediate
     1929   response with a final status code, if that status can be determined by
     1930   examining just the request-line and header fields, or send an immediate
     1931   <x:ref>100 (Continue)</x:ref> response to encourage the client to send the
     1932   request's message body. The origin server &MUST-NOT; wait for the message
     1933   body before sending the <x:ref>100 (Continue)</x:ref> response.
     1934</t>
     1935<t>
     1936   A proxy &MUST;, upon receiving an HTTP/1.1 (or later) request-line
     1937   and a complete header section that contains a 100-continue expectation and
     1938   indicates a request message body will follow, either send an immediate
     1939   response with a final status code, if that status can be determined by
     1940   examining just the request-line and header fields, or begin forwarding the
     1941   request toward the origin server by sending a corresponding request-line
     1942   and header section to the next inbound server. If the proxy believes (from
     1943   configuration or past interaction) that the next inbound server only
     1944   supports HTTP/1.0, the proxy &MAY; generate an immediate
     1945   <x:ref>100 (Continue)</x:ref> response to encourage the client to begin
     1946   sending the message body.
     1947</t>
     1948<x:note>
     1949  <t>
     1950    &Note; The Expect header field was added after the original publication of
     1951    HTTP/1.1 <xref target="RFC2068"/> as both the means to request an interim
     1952    100 response and the general mechanism for indicating must-understand
     1953    extensions. However, the extension mechanism has not been used by clients
     1954    and the must-understand requirements have not been implemented by many
     1955    servers, rendering the extension mechanism useless. This specification has
     1956    removed the extension mechanism in order to simplify the definition and
     1957    processing of 100-continue.
     1958  </t>
     1959</x:note>
    19671960</section>
    19681961
     
    27592752   includes a <x:ref>100-continue</x:ref> expectation, the 100 response
    27602753   indicates that the server wishes to receive the request payload body,
    2761    as described in <xref target="expect-100-continue"/>.  The client
     2754   as described in <xref target="header.expect"/>.  The client
    27622755   ought to continue sending the request and discard the 100 response.
    27632756</t>
     
    52075200  </front>
    52085201  <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p7-auth-&ID-VERSION;"/>
    5209   <x:source href="p7-auth.xml" basename="p7-auth"/>
     5202  <x:source href="p7-auth.xml" basename="p7-auth">
     5203     <x:defines>401 (Unauthorized)</x:defines>
     5204  </x:source>
    52105205</reference>
    52115206
     
    61866181<x:ref>Date</x:ref> = HTTP-date
    61876182
    6188 <x:ref>Expect</x:ref> = *( "," OWS ) expectation *( OWS "," [ OWS expectation ] )
     6183<x:ref>Expect</x:ref> = "100-continue"
    61896184
    61906185<x:ref>From</x:ref> = mailbox
     
    62446239 / %x53.75.6E.64.61.79 ; Sunday
    62456240<x:ref>delta-seconds</x:ref> = 1*DIGIT
    6246 
    6247 <x:ref>expect-name</x:ref> = token
    6248 <x:ref>expect-param</x:ref> = expect-name [ BWS "=" BWS expect-value ]
    6249 <x:ref>expect-value</x:ref> = token / quoted-string
    6250 <x:ref>expectation</x:ref> = expect-name [ BWS "=" BWS expect-value ] *( OWS ";" [
    6251  OWS expect-param ] )
    62526241
    62536242<x:ref>field-name</x:ref> = &lt;comment, defined in [Part1], Section 3.2&gt;
Note: See TracChangeset for help on using the changeset viewer.