Ignore:
Timestamp:
04/08/13 01:45:41 (8 years ago)
Author:
fielding@…
Message:

Many changes to properly target MUST requirements by role; addresses #478

File:
1 edited

Legend:

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

    r2334 r2342  
    587587</artwork></figure>
    588588<t>
    589    If multiple encodings have been applied to a representation, the content
    590    codings &MUST; be listed in the order in which they were applied.
     589   If one or more encodings have been applied to a representation, the sender
     590   that applied the encodings &MUST; generate a Content-Encoding header field
     591   that lists the content codings in the order in which they were applied.
    591592   Additional information about the encoding parameters &MAY; be provided
    592593   by other header fields not defined by this specification.
     
    12111212   to use actions within query parameters, such as "page?do=delete".
    12121213   If the purpose of such a resource is to perform an unsafe action, then
    1213    the resource &MUST; disable or disallow that action when it is accessed
    1214    using a safe request method. Failure to do so will result in
     1214   the resource owner &MUST; disable or disallow that action when it is
     1215   accessed using a safe request method. Failure to do so will result in
    12151216   unfortunate side-effects when automated processes perform a GET on
    12161217   every URI reference for the sake of link maintenance, pre-fetching,
     
    15941595   destination origin server identified by the request-target and, if
    15951596   successful, thereafter restrict its behavior to blind forwarding of
    1596    packets, in both directions, until the connection is closed.
     1597   packets, in both directions, until the tunnel is closed.
    15971598</t>
    15981599<t>
     
    16261627</t>
    16271628<t>
    1628    A server &SHOULD-NOT; send any <x:ref>Transfer-Encoding</x:ref> or
    1629    <x:ref>Content-Length</x:ref> header fields in a successful response.
    1630    A client &MUST; ignore any Content-Length or Transfer-Encoding header
    1631    fields received in a successful response.
    1632 </t>
     1629   A tunnel is closed when a tunnel intermediary detects that either side
     1630   has closed its connection: the intermediary &MUST; attempt to send any
     1631   outstanding data that came from the closed side to the other side, close
     1632   both connections, and then discard any remaining data left undelivered.
     1633</t>
     1634<t>
     1635   Proxy authentication might be used to establish the
     1636   authority to create a tunnel.  For example,
     1637</t>
     1638<figure><artwork type="message/http; msgtype=&#34;request&#34;" x:indent-with="  ">
     1639CONNECT server.example.com:80 HTTP/1.1
     1640Host: server.example.com:80
     1641Proxy-Authorization: basic aGVsbG86d29ybGQ=
     1642
     1643</artwork></figure>
    16331644<t>
    16341645   There are significant risks in establishing a tunnel to arbitrary servers,
     
    16421653</t>
    16431654<t>
    1644    Proxy authentication might be used to establish the
    1645    authority to create a tunnel.  For example,
    1646 </t>
    1647 <figure><artwork type="message/http; msgtype=&#34;request&#34;" x:indent-with="  ">
    1648 CONNECT server.example.com:80 HTTP/1.1
    1649 Host: server.example.com:80
    1650 Proxy-Authorization: basic aGVsbG86d29ybGQ=
    1651 
    1652 </artwork></figure>
    1653 <t>
    1654    When a tunnel intermediary detects that either side has closed its
    1655    connection, any outstanding data that came from that side will first be
    1656    sent to the other side and then the intermediary will close both
    1657    connections. If there is outstanding data left undelivered,
    1658    that data will be discarded.
     1655   A server &SHOULD-NOT; send any <x:ref>Transfer-Encoding</x:ref> or
     1656   <x:ref>Content-Length</x:ref> header fields in a successful response
     1657   to CONNECT.
     1658   A client &MUST; ignore any Content-Length or Transfer-Encoding header
     1659   fields received in a successful response to CONNECT.
    16591660</t>
    16601661<t>
     
    17431744</t>
    17441745<t>
    1745    A client &MUST-NOT; send header fields in a TRACE request containing
     1746   A client &MUST-NOT; generate header fields in a TRACE request containing
    17461747   sensitive data that might be disclosed by the response. For example, it
    17471748   would be foolish for a user agent to send stored user credentials
     
    18311832</t>
    18321833<t>
    1833    The Expect header field &MUST; be forwarded if the request is forwarded.
     1834   An intermediary &MUST; forward a received Expect header field if the
     1835   request is forwarded.
    18341836</t>
    18351837<t>
     
    18671869</t>
    18681870<t>
    1869    Requirements for HTTP/1.1 clients:
     1871   Requirements for clients:
    18701872  <list style="symbols">
    18711873    <t>
    1872         If a client will wait for a <x:ref>100 (Continue)</x:ref> response before
    1873         sending the payload body, it &MUST; send an <x:ref>Expect</x:ref> header
    1874         field with the "100-continue" expectation.
     1874     If a client will wait for a <x:ref>100 (Continue)</x:ref> response before
     1875     sending the payload body, it &MUST; send an <x:ref>Expect</x:ref> header
     1876     field with the "100-continue" expectation.
    18751877    </t>
    18761878    <t>
    1877         A client &MUST-NOT; send an <x:ref>Expect</x:ref> header field with
    1878         the "100-continue" expectation if it does not intend to send a payload
    1879         body.
     1879     A client &MUST-NOT; send an <x:ref>Expect</x:ref> header field with
     1880     the "100-continue" expectation if it does not intend to send a payload
     1881     body.
     1882    </t>
     1883    <t>
     1884     Because of the presence of older implementations, the protocol allows
     1885     ambiguous situations in which a client might send "Expect: 100-continue"
     1886     without receiving either a <x:ref>417 (Expectation Failed)</x:ref> or a
     1887     <x:ref>100 (Continue)</x:ref> status code. Therefore, when a client sends
     1888     this header field to an origin server (possibly via a proxy) from which
     1889     it has never seen a <x:ref>100 (Continue)</x:ref> status code, the
     1890     client &SHOULD-NOT; wait for an indefinite period before sending the
     1891     payload body.
    18801892    </t>
    18811893  </list>
    18821894</t>
    18831895<t>
    1884    Because of the presence of older implementations, the protocol allows
    1885    ambiguous situations in which a client might send "Expect: 100-continue"
    1886    without receiving either a <x:ref>417 (Expectation Failed)</x:ref>
    1887    or a <x:ref>100 (Continue)</x:ref> status code. Therefore, when a client sends this
    1888    header field to an origin server (possibly via a proxy) from which it
    1889    has never seen a <x:ref>100 (Continue)</x:ref> status code, the client &SHOULD-NOT; 
    1890    wait for an indefinite period before sending the payload body.
    1891 </t>
    1892 <t>
    1893    Requirements for HTTP/1.1 origin servers:
     1896   Requirements for origin servers:
    18941897  <list style="symbols">
    18951898    <t> Upon receiving a request that includes an <x:ref>Expect</x:ref> header
     
    19421945</t>
    19431946<t>
    1944    Requirements for HTTP/1.1 proxies:
     1947   Requirements for proxies:
    19451948  <list style="symbols">
    19461949    <t> If a proxy receives a request that includes an <x:ref>Expect</x:ref>
     
    19581961        numbers received from recently-referenced next-hop servers.
    19591962    </t>
    1960     <t> A proxy &MUST-NOT; forward a <x:ref>100 (Continue)</x:ref> response if the
    1961         request message was received from an HTTP/1.0 (or earlier)
     1963    <t> A proxy &MUST-NOT; forward a <x:ref>100 (Continue)</x:ref> response if
     1964        the request message was received from an HTTP/1.0 (or earlier)
    19621965        client and did not include an <x:ref>Expect</x:ref> header field with
    19631966        the "100-continue" expectation. This requirement overrides the
     
    19881991</t>
    19891992<t>
    1990    Each recipient of a TRACE or OPTIONS request
    1991    containing a Max-Forwards header field &MUST; check and update its
    1992    value prior to forwarding the request. If the received value is zero
    1993    (0), the recipient &MUST-NOT; forward the request; instead, it &MUST;
    1994    respond as the final recipient. If the received Max-Forwards value is
    1995    greater than zero, then the forwarded message &MUST; contain an updated
    1996    Max-Forwards field with a value decremented by one (1).
    1997 </t>
    1998 <t>
    1999    The Max-Forwards header field &MAY; be ignored for all other request
    2000    methods.
     1993   Each intermediary that receives a TRACE or OPTIONS request containing a
     1994   Max-Forwards header field &MUST; check and update its value prior to
     1995   forwarding the request. If the received value is zero (0), the intermediary
     1996   &MUST-NOT; forward the request; instead, the intermediary &MUST; respond as
     1997   the final recipient. If the received Max-Forwards value is greater than
     1998   zero, the intermediary &MUST; generate an updated Max-Forwards field in the
     1999   forwarded message with a field-value that is the lesser of: a) the received
     2000   value decremented by one (1), or b) the recipient's maximum supported value
     2001   for Max-Forwards.
     2002</t>
     2003<t>
     2004   A recipient &MAY; ignore a Max-Forwards header field received with any
     2005   other request methods.
    20012006</t>
    20022007</section>
     
    26092614   understand the class of any status code, as indicated by the first
    26102615   digit, and treat an unrecognized status code as being equivalent to the
    2611    x00 status code of that class, with the exception that a response with an
    2612    unrecognized status code &MUST-NOT; be cached.
     2616   x00 status code of that class, with the exception that
     2617   a recipient &MUST-NOT; cache a response with an unrecognized status code.
    26132618</t>
    26142619<t>
     
    27402745</t>
    27412746<t>
    2742    Proxies &MUST; forward 1xx responses, unless the connection between the
    2743    proxy and its client has been closed, or unless the proxy itself
     2747   A proxy &MUST; forward 1xx responses unless the proxy itself
    27442748   requested the generation of the 1xx response. For example, if a
    27452749   proxy adds an "Expect: 100-continue" field when it forwards a request,
     
    36933697<t>
    36943698   A recipient that parses a timestamp value in an HTTP header field &MUST;
    3695    accept all three formats. A sender &MUST; generate the IMF-fixdate
    3696    format when sending an HTTP-date value in a header field.
     3699   accept all three HTTP-date formats. When a sender generates a header field
     3700   that contains one or more timestamps defined as HTTP-date,
     3701   the sender &MUST; generate those timestamps in the IMF-fixdate format.
    36973702</t>
    36983703<t>
Note: See TracChangeset for help on using the changeset viewer.