Changeset 2342


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

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

Location:
draft-ietf-httpbis/latest
Files:
2 edited

Legend:

Unmodified
Added
Removed

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

    r2334 r2342  
    449449  }
    450450  @bottom-center {
    451        content: "Expires February 2, 2014";
     451       content: "Expires February 4, 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-01">
     496      <meta name="dct.issued" scheme="ISO8601" content="2013-08-03">
    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 1, 2013</td>
     524               <td class="right">August 3, 2013</td>
    525525            </tr>
    526526            <tr>
    527                <td class="left">Expires: February 2, 2014</td>
     527               <td class="left">Expires: February 4, 2014</td>
    528528               <td class="right"></td>
    529529            </tr>
    … …  
    553553         in progress”.
    554554      </p>
    555       <p>This Internet-Draft will expire on February 2, 2014.</p>
     555      <p>This Internet-Draft will expire on February 4, 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>
    … …  
    10081008</pre><p id="rfc.section.3.1.2.2.p.3">An example of its use is</p>
    10091009      <div id="rfc.figure.u.9"></div><pre class="text">  Content-Encoding: gzip
    1010 </pre><p id="rfc.section.3.1.2.2.p.5">If multiple encodings have been applied to a representation, the content codings <em class="bcp14">MUST</em> be listed in the order in which they were applied. Additional information about the encoding parameters <em class="bcp14">MAY</em> be provided by other header fields not defined by this specification.
     1010</pre><p id="rfc.section.3.1.2.2.p.5">If one or more encodings have been applied to a representation, the sender that applied the encodings <em class="bcp14">MUST</em> generate a Content-Encoding header field that lists the content codings in the order in which they were applied. Additional
     1011         information about the encoding parameters <em class="bcp14">MAY</em> be provided by other header fields not defined by this specification.
    10111012      </p>
    10121013      <p id="rfc.section.3.1.2.2.p.6">Unlike Transfer-Encoding (<a href="p1-messaging.html#header.transfer-encoding" title="Transfer-Encoding">Section 3.3.1</a> of <a href="#Part1" id="rfc.xref.Part1.10"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>), the codings listed in Content-Encoding are a characteristic of the representation; the representation is defined in terms
    … …  
    13621363         it is the resource owner's responsibility to ensure that the action is consistent with the request method semantics. For example,
    13631364         it is common for Web-based content editing software to use actions within query parameters, such as "page?do=delete". If the
    1364          purpose of such a resource is to perform an unsafe action, then the resource <em class="bcp14">MUST</em> disable or disallow that action when it is accessed using a safe request method. Failure to do so will result in unfortunate
     1365         purpose of such a resource is to perform an unsafe action, then the resource owner <em class="bcp14">MUST</em> disable or disallow that action when it is accessed using a safe request method. Failure to do so will result in unfortunate
    13651366         side-effects when automated processes perform a GET on every URI reference for the sake of link maintenance, pre-fetching,
    13661367         building a search index, etc.
    … …  
    15441545      <h3 id="rfc.section.4.3.6"><a href="#rfc.section.4.3.6">4.3.6</a>&nbsp;<a id="CONNECT" href="#CONNECT">CONNECT</a></h3>
    15451546      <p id="rfc.section.4.3.6.p.1">The CONNECT method requests that the recipient establish a tunnel to the destination origin server identified by the request-target
    1546          and, if successful, thereafter restrict its behavior to blind forwarding of packets, in both directions, until the connection
     1547         and, if successful, thereafter restrict its behavior to blind forwarding of packets, in both directions, until the tunnel
    15471548         is closed.
    15481549      </p>
    … …  
    15611562         connection remains governed by HTTP.
    15621563      </p>
    1563       <p id="rfc.section.4.3.6.p.6">A server <em class="bcp14">SHOULD NOT</em> send any <a href="p1-messaging.html#header.transfer-encoding" class="smpl">Transfer-Encoding</a> or <a href="p1-messaging.html#header.content-length" class="smpl">Content-Length</a> header fields in a successful response. A client <em class="bcp14">MUST</em> ignore any Content-Length or Transfer-Encoding header fields received in a successful response.
    1564       </p>
    1565       <p id="rfc.section.4.3.6.p.7">There are significant risks in establishing a tunnel to arbitrary servers, particularly when the destination is a well-known
     1564      <p id="rfc.section.4.3.6.p.6">A tunnel is closed when a tunnel intermediary detects that either side has closed its connection: the intermediary <em class="bcp14">MUST</em> attempt to send any outstanding data that came from the closed side to the other side, close both connections, and then discard
     1565         any remaining data left undelivered.
     1566      </p>
     1567      <p id="rfc.section.4.3.6.p.7">Proxy authentication might be used to establish the authority to create a tunnel. For example,</p>
     1568      <div id="rfc.figure.u.19"></div><pre class="text2">CONNECT server.example.com:80 HTTP/1.1
     1569Host: server.example.com:80
     1570Proxy-Authorization: basic aGVsbG86d29ybGQ=
     1571
     1572</pre><p id="rfc.section.4.3.6.p.9">There are significant risks in establishing a tunnel to arbitrary servers, particularly when the destination is a well-known
    15661573         or reserved TCP port that is not intended for Web traffic. For example, a CONNECT to a request-target of "example.com:25"
    15671574         would suggest that the proxy connect to the reserved port for SMTP traffic; if allowed, that could trick the proxy into relaying
    15681575         spam email. Proxies that support CONNECT <em class="bcp14">SHOULD</em> restrict its use to a limited set of known ports or a configurable whitelist of safe request targets.
    15691576      </p>
    1570       <p id="rfc.section.4.3.6.p.8">Proxy authentication might be used to establish the authority to create a tunnel. For example,</p>
    1571       <div id="rfc.figure.u.19"></div><pre class="text2">CONNECT server.example.com:80 HTTP/1.1
    1572 Host: server.example.com:80
    1573 Proxy-Authorization: basic aGVsbG86d29ybGQ=
    1574 
    1575 </pre><p id="rfc.section.4.3.6.p.10">When a tunnel intermediary detects that either side has closed its connection, any outstanding data that came from that side
    1576          will first be sent to the other side and then the intermediary will close both connections. If there is outstanding data left
    1577          undelivered, that data will be discarded.
     1577      <p id="rfc.section.4.3.6.p.10">A server <em class="bcp14">SHOULD NOT</em> send any <a href="p1-messaging.html#header.transfer-encoding" class="smpl">Transfer-Encoding</a> or <a href="p1-messaging.html#header.content-length" class="smpl">Content-Length</a> header fields in a successful response to CONNECT. A client <em class="bcp14">MUST</em> ignore any Content-Length or Transfer-Encoding header fields received in a successful response to CONNECT.
    15781578      </p>
    15791579      <p id="rfc.section.4.3.6.p.11">A payload within a CONNECT request message has no defined semantics; sending a payload body on a CONNECT request might cause
    … …  
    16101610      <p id="rfc.section.4.3.8.p.1">The TRACE method requests a remote, application-level loop-back of the request message. The final recipient of the request <em class="bcp14">SHOULD</em> reflect the message received, excluding some fields described below, back to the client as the message body of a <a href="#status.200" class="smpl">200 (OK)</a> response with a <a href="#header.content-type" class="smpl">Content-Type</a> of "message/http" (<a href="p1-messaging.html#internet.media.type.message.http" title="Internet Media Type message/http">Section 7.3.1</a> of <a href="#Part1" id="rfc.xref.Part1.17"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>). The final recipient is either the origin server or the first server to receive a <a href="#header.max-forwards" class="smpl">Max-Forwards</a> value of zero (0) in the request (<a href="#header.max-forwards" id="rfc.xref.header.max-forwards.2" title="Max-Forwards">Section&nbsp;5.1.2</a>).
    16111611      </p>
    1612       <p id="rfc.section.4.3.8.p.2">A client <em class="bcp14">MUST NOT</em> send header fields in a TRACE request containing sensitive data that might be disclosed by the response. For example, it would
    1613          be foolish for a user agent to send stored user credentials <a href="#Part7" id="rfc.xref.Part7.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Authentication">[Part7]</cite></a> or cookies <a href="#RFC6265" id="rfc.xref.RFC6265.1"><cite title="HTTP State Management Mechanism">[RFC6265]</cite></a> in a TRACE request. The final recipient of the request <em class="bcp14">SHOULD</em> exclude any request header fields that are likely to contain sensitive data when that recipient generates the response body.
     1612      <p id="rfc.section.4.3.8.p.2">A client <em class="bcp14">MUST NOT</em> generate header fields in a TRACE request containing sensitive data that might be disclosed by the response. For example,
     1613         it would be foolish for a user agent to send stored user credentials <a href="#Part7" id="rfc.xref.Part7.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Authentication">[Part7]</cite></a> or cookies <a href="#RFC6265" id="rfc.xref.RFC6265.1"><cite title="HTTP State Management Mechanism">[RFC6265]</cite></a> in a TRACE request. The final recipient of the request <em class="bcp14">SHOULD</em> exclude any request header fields that are likely to contain sensitive data when that recipient generates the response body.
    16141614      </p>
    16151615      <p id="rfc.section.4.3.8.p.3">TRACE allows the client to see what is being received at the other end of the request chain and use that data for testing
    … …  
    16831683      </p>
    16841684      <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">The Expect header field <em class="bcp14">MUST</em> be forwarded if the request is forwarded.
     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.
    16861686      </p>
    16871687      <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>
    … …  
    17021702         looking at the body.
    17031703      </p>
    1704       <p id="rfc.section.5.1.1.1.p.4">Requirements for HTTP/1.1 clients: </p>
     1704      <p id="rfc.section.5.1.1.1.p.4">Requirements for clients: </p>
    17051705      <ul>
    17061706         <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.
    … …  
    17081708         <li>A client <em class="bcp14">MUST NOT</em> send an <a href="#header.expect" class="smpl">Expect</a> header field with the "100-continue" expectation if it does not intend to send a payload body.
    17091709         </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.
     1713         </li>
    17101714      </ul>
    1711       <p id="rfc.section.5.1.1.1.p.5">Because of the presence of older implementations, the protocol allows ambiguous situations in which a client might send "Expect:
    1712          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
    1713          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       </p>
    1715       <p id="rfc.section.5.1.1.1.p.6">Requirements for HTTP/1.1 origin servers: </p>
     1715      <p id="rfc.section.5.1.1.1.p.5">Requirements for origin servers: </p>
    17161716      <ul>
    17171717         <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 rest of the request.
    … …  
    17331733         </li>
    17341734      </ul>
    1735       <p id="rfc.section.5.1.1.1.p.7">Requirements for HTTP/1.1 proxies: </p>
     1735      <p id="rfc.section.5.1.1.1.p.6">Requirements for proxies: </p>
    17361736      <ul>
    17371737         <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
    … …  
    17521752      <div id="rfc.figure.u.21"></div><pre class="inline"><span id="rfc.iref.g.22"></span>  <a href="#header.max-forwards" class="smpl">Max-Forwards</a> = 1*<a href="#imported.abnf" class="smpl">DIGIT</a>
    17531753</pre><p id="rfc.section.5.1.2.p.3">The Max-Forwards value is a decimal integer indicating the remaining number of times this request message can be forwarded.</p>
    1754       <p id="rfc.section.5.1.2.p.4">Each recipient of a TRACE or OPTIONS request containing a Max-Forwards header field <em class="bcp14">MUST</em> check and update its value prior to forwarding the request. If the received value is zero (0), the recipient <em class="bcp14">MUST NOT</em> forward the request; instead, it <em class="bcp14">MUST</em> respond as the final recipient. If the received Max-Forwards value is greater than zero, then the forwarded message <em class="bcp14">MUST</em> contain an updated Max-Forwards field with a value decremented by one (1).
    1755       </p>
    1756       <p id="rfc.section.5.1.2.p.5">The Max-Forwards header field <em class="bcp14">MAY</em> be ignored for all other request methods.
     1754      <p id="rfc.section.5.1.2.p.4">Each intermediary that receives a TRACE or OPTIONS request containing a Max-Forwards header field <em class="bcp14">MUST</em> check and update its value prior to forwarding the request. If the received value is zero (0), the intermediary <em class="bcp14">MUST NOT</em> forward the request; instead, the intermediary <em class="bcp14">MUST</em> respond as the final recipient. If the received Max-Forwards value is greater than zero, the intermediary <em class="bcp14">MUST</em> generate an updated Max-Forwards field in the forwarded message with a field-value that is the lesser of: a) the received
     1755         value decremented by one (1), or b) the recipient's maximum supported value for Max-Forwards.
     1756      </p>
     1757      <p id="rfc.section.5.1.2.p.5">A recipient <em class="bcp14">MAY</em> ignore a Max-Forwards header field received with any other request methods.
    17571758      </p>
    17581759      <div id="rfc.iref.c.10"></div>
    … …  
    21692170      <p id="rfc.section.6.p.2">HTTP status codes are extensible. HTTP clients are not required to understand the meaning of all registered status codes,
    21702171         though such understanding is obviously desirable. However, clients <em class="bcp14">MUST</em> understand the class of any status code, as indicated by the first digit, and treat an unrecognized status code as being equivalent
    2171          to the x00 status code of that class, with the exception that a response with an unrecognized status code <em class="bcp14">MUST NOT</em> be cached.
     2172         to the x00 status code of that class, with the exception that a recipient <em class="bcp14">MUST NOT</em> cache a response with an unrecognized status code.
    21722173      </p>
    21732174      <p id="rfc.section.6.p.3">For example, if an unrecognized status code of 471 is received by a client, the client can assume that there was something
    … …  
    24292430         A user agent <em class="bcp14">MAY</em> ignore unexpected 1xx status responses.
    24302431      </p>
    2431       <p id="rfc.section.6.2.p.3">Proxies <em class="bcp14">MUST</em> forward 1xx responses, unless the connection between the proxy and its client has been closed, or unless the proxy itself
    2432          requested the generation of the 1xx response. For example, if a proxy adds an "Expect: 100-continue" field when it forwards
    2433          a request, then it need not forward the corresponding <a href="#status.100" class="smpl">100 (Continue)</a> response(s).
     2432      <p id="rfc.section.6.2.p.3">A proxy <em class="bcp14">MUST</em> forward 1xx responses unless the proxy itself requested the generation of the 1xx response. For example, if a proxy adds an
     2433         "Expect: 100-continue" field when it forwards a request, then it need not forward the corresponding <a href="#status.100" class="smpl">100 (Continue)</a> response(s).
    24342434      </p>
    24352435      <div id="rfc.iref.73"></div>
    … …  
    28992899      <p>Examples of the two obsolete formats are</p><pre class="text">Sunday, 06-Nov-94 08:49:37 GMT   ; obsolete RFC 850 format
    29002900Sun Nov  6 08:49:37 1994         ; ANSI C's asctime() format
    2901 </pre><p id="rfc.section.7.1.1.1.p.5">A recipient that parses a timestamp value in an HTTP header field <em class="bcp14">MUST</em> accept all three formats. A sender <em class="bcp14">MUST</em> generate the IMF-fixdate format when sending an HTTP-date value in a header field.
     2901</pre><p id="rfc.section.7.1.1.1.p.5">A recipient that parses a timestamp value in an HTTP header field <em class="bcp14">MUST</em> accept all three HTTP-date formats. When a sender generates a header field that contains one or more timestamps defined as
     2902         HTTP-date, the sender <em class="bcp14">MUST</em> generate those timestamps in the IMF-fixdate format.
    29022903      </p>
    29032904      <p id="rfc.section.7.1.1.1.p.6">An HTTP-date value represents time as an instance of Coordinated Universal Time (UTC). The first two formats indicate UTC

  • 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.