03/09/12 22:12:40 (7 years ago)

(editorial) move Expect 100-continue discussion to p2

1 edited


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

    r1858 r1859  
    3737  <!ENTITY http-url                   "<xref target='Part1' x:rel='#http-url' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    3838  <!ENTITY http-version               "<xref target='Part1' x:rel='#http.version' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    39   <!ENTITY use100                     "<xref target='Part1' x:rel='#use.of.the.100.status' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    4039  <!ENTITY request-target             "<xref target='Part1' x:rel='#request-target' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    4140  <!ENTITY header-accept              "<xref target='header.accept' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    16541653   <list>
    16551654      <t>
    1656         The "100-continue" expectation is defined &use100;. It does not support
     1655        The "100-continue" expectation is defined below. It does not support
    16571656        any expect-params.
    16581657      </t>
    16721671   header field.
     1674<section title="Use of the 100 (Continue) Status" anchor="use.of.the.100.status">
     1676   The purpose of the <x:ref>100 (Continue)</x:ref> status code
     1677   (<xref target='status.100'/>)
     1678   is to allow a client that is sending a request message with a request body
     1679   to determine if the origin server is willing to accept the request
     1680   (based on the request header fields) before the client sends the request
     1681   body. In some cases, it might either be inappropriate or highly
     1682   inefficient for the client to send the body if the server will reject
     1683   the message without looking at the body.
     1686   Requirements for HTTP/1.1 clients:
     1687  <list style="symbols">
     1688    <t>
     1689        If a client will wait for a <x:ref>100 (Continue)</x:ref> response before
     1690        sending the request body, it &MUST; send an <x:ref>Expect</x:ref> header
     1691        field with the "100-continue" expectation.
     1692    </t>
     1693    <t>
     1694        A client &MUST-NOT; send an <x:ref>Expect</x:ref> header field with
     1695        the "100-continue" expectation if it does not intend to send a request
     1696        body.
     1697    </t>
     1698  </list>
     1701   Because of the presence of older implementations, the protocol allows
     1702   ambiguous situations in which a client might send "Expect: 100-continue"
     1703   without receiving either a <x:ref>417 (Expectation Failed)</x:ref>
     1704   or a <x:ref>100 (Continue)</x:ref> status code. Therefore, when a client sends this
     1705   header field to an origin server (possibly via a proxy) from which it
     1706   has never seen a <x:ref>100 (Continue)</x:ref> status code, the client &SHOULD-NOT; 
     1707   wait for an indefinite period before sending the request body.
     1710   Requirements for HTTP/1.1 origin servers:
     1711  <list style="symbols">
     1712    <t> Upon receiving a request which includes an <x:ref>Expect</x:ref> header
     1713        field with the "100-continue" expectation, an origin server &MUST;
     1714        either respond with <x:ref>100 (Continue)</x:ref> status code and continue to read
     1715        from the input stream, or respond with a final status code. The
     1716        origin server &MUST-NOT; wait for the request body before sending
     1717        the <x:ref>100 (Continue)</x:ref> response. If it responds with a final status
     1718        code, it &MAY; close the transport connection or it &MAY; continue
     1719        to read and discard the rest of the request.  It &MUST-NOT;
     1720        perform the request method if it returns a final status code.
     1721    </t>
     1722    <t> An origin server &SHOULD-NOT;  send a <x:ref>100 (Continue)</x:ref> response if
     1723        the request message does not include an <x:ref>Expect</x:ref> header
     1724        field with the "100-continue" expectation, and &MUST-NOT; send a
     1725        <x:ref>100 (Continue)</x:ref> response if such a request comes from an HTTP/1.0
     1726        (or earlier) client. There is an exception to this rule: for
     1727        compatibility with <xref target="RFC2068"/>, a server &MAY; send a <x:ref>100 (Continue)</x:ref>
     1728        status code in response to an HTTP/1.1 PUT or POST request that does
     1729        not include an Expect header field with the "100-continue"
     1730        expectation. This exception, the purpose of which is
     1731        to minimize any client processing delays associated with an
     1732        undeclared wait for <x:ref>100 (Continue)</x:ref> status code, applies only to
     1733        HTTP/1.1 requests, and not to requests with any other HTTP-version
     1734        value.
     1735    </t>
     1736    <t> An origin server &MAY; omit a <x:ref>100 (Continue)</x:ref> response if it has
     1737        already received some or all of the request body for the
     1738        corresponding request.
     1739    </t>
     1740    <t> An origin server that sends a <x:ref>100 (Continue)</x:ref> response &MUST;
     1741        ultimately send a final status code, once the request body is
     1742        received and processed, unless it terminates the transport
     1743        connection prematurely.
     1744    </t>
     1745    <t> If an origin server receives a request that does not include an
     1746        <x:ref>Expect</x:ref> header field with the "100-continue" expectation,
     1747        the request includes a request body, and the server responds
     1748        with a final status code before reading the entire request body
     1749        from the transport connection, then the server &SHOULD-NOT;  close
     1750        the transport connection until it has read the entire request,
     1751        or until the client closes the connection. Otherwise, the client
     1752        might not reliably receive the response message. However, this
     1753        requirement ought not be construed as preventing a server from
     1754        defending itself against denial-of-service attacks, or from
     1755        badly broken client implementations.
     1756      </t>
     1757    </list>
     1760   Requirements for HTTP/1.1 proxies:
     1761  <list style="symbols">
     1762    <t> If a proxy receives a request that includes an <x:ref>Expect</x:ref>
     1763        header field with the "100-continue" expectation, and the proxy
     1764        either knows that the next-hop server complies with HTTP/1.1 or
     1765        higher, or does not know the HTTP version of the next-hop
     1766        server, it &MUST; forward the request, including the Expect header
     1767        field.
     1768    </t>
     1769    <t> If the proxy knows that the version of the next-hop server is
     1770        HTTP/1.0 or lower, it &MUST-NOT; forward the request, and it &MUST;
     1771        respond with a <x:ref>417 (Expectation Failed)</x:ref> status code.
     1772    </t>
     1773    <t> Proxies &SHOULD; maintain a record of the HTTP version
     1774        numbers received from recently-referenced next-hop servers.
     1775    </t>
     1776    <t> A proxy &MUST-NOT; forward a <x:ref>100 (Continue)</x:ref> response if the
     1777        request message was received from an HTTP/1.0 (or earlier)
     1778        client and did not include an <x:ref>Expect</x:ref> header field with
     1779        the "100-continue" expectation. This requirement overrides the
     1780        general rule for forwarding of <x:ref>1xx</x:ref> responses
     1781        (see <xref target='status.100'/>).
     1782    </t>
     1783  </list>
    23592471   &SHOULD; continue by sending the remainder of the request or, if the
    23602472   request has already been completed, ignore this response. The server
    2361    &MUST; send a final response after the request has been completed. See
    2362    &use100; for detailed discussion of the use and handling of this
    2363    status code.
     2473   &MUST; send a final response after the request has been completed.
     2474   See <xref target="use.of.the.100.status"/> for detailed discussion of the
     2475   use and handling of this status code.
Note: See TracChangeset for help on using the changeset viewer.