Changeset 2342
- Timestamp:
- 04/08/13 01:45:41 (9 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 2 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p2-semantics.html
r2334 r2342 449 449 } 450 450 @bottom-center { 451 content: "Expires February 2, 2014";451 content: "Expires February 4, 2014"; 452 452 } 453 453 @bottom-right { … … 494 494 <meta name="dct.creator" content="Reschke, J. F."> 495 495 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p2-semantics-latest"> 496 <meta name="dct.issued" scheme="ISO8601" content="2013-08-0 1">496 <meta name="dct.issued" scheme="ISO8601" content="2013-08-03"> 497 497 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 498 498 <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."> … … 522 522 <tr> 523 523 <td class="left">Intended status: Standards Track</td> 524 <td class="right">August 1, 2013</td>524 <td class="right">August 3, 2013</td> 525 525 </tr> 526 526 <tr> 527 <td class="left">Expires: February 2, 2014</td>527 <td class="left">Expires: February 4, 2014</td> 528 528 <td class="right"></td> 529 529 </tr> … … 553 553 in progress”. 554 554 </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> 556 556 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 557 557 <p>Copyright © 2013 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 1008 1008 </pre><p id="rfc.section.3.1.2.2.p.3">An example of its use is</p> 1009 1009 <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. 1011 1012 </p> 1012 1013 <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 … … 1362 1363 it is the resource owner's responsibility to ensure that the action is consistent with the request method semantics. For example, 1363 1364 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 unfortunate1365 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 1365 1366 side-effects when automated processes perform a GET on every URI reference for the sake of link maintenance, pre-fetching, 1366 1367 building a search index, etc. … … 1544 1545 <h3 id="rfc.section.4.3.6"><a href="#rfc.section.4.3.6">4.3.6</a> <a id="CONNECT" href="#CONNECT">CONNECT</a></h3> 1545 1546 <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 connection1547 and, if successful, thereafter restrict its behavior to blind forwarding of packets, in both directions, until the tunnel 1547 1548 is closed. 1548 1549 </p> … … 1561 1562 connection remains governed by HTTP. 1562 1563 </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 1569 Host: server.example.com:80 1570 Proxy-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 1566 1573 or reserved TCP port that is not intended for Web traffic. For example, a CONNECT to a request-target of "example.com:25" 1567 1574 would suggest that the proxy connect to the reserved port for SMTP traffic; if allowed, that could trick the proxy into relaying 1568 1575 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. 1569 1576 </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. 1578 1578 </p> 1579 1579 <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 … … 1610 1610 <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 5.1.2</a>). 1611 1611 </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 would1613 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. 1614 1614 </p> 1615 1615 <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 … … 1683 1683 </p> 1684 1684 <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. 1686 1686 </p> 1687 1687 <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> … … 1702 1702 looking at the body. 1703 1703 </p> 1704 <p id="rfc.section.5.1.1.1.p.4">Requirements for HTTP/1.1clients: </p>1704 <p id="rfc.section.5.1.1.1.p.4">Requirements for clients: </p> 1705 1705 <ul> 1706 1706 <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. … … 1708 1708 <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. 1709 1709 </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> 1710 1714 </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> 1716 1716 <ul> 1717 1717 <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. … … 1733 1733 </li> 1734 1734 </ul> 1735 <p id="rfc.section.5.1.1.1.p. 7">Requirements for HTTP/1.1proxies: </p>1735 <p id="rfc.section.5.1.1.1.p.6">Requirements for proxies: </p> 1736 1736 <ul> 1737 1737 <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 … … 1752 1752 <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> 1753 1753 </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. 1757 1758 </p> 1758 1759 <div id="rfc.iref.c.10"></div> … … 2169 2170 <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, 2170 2171 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 re sponse 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. 2172 2173 </p> 2173 2174 <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 … … 2429 2430 A user agent <em class="bcp14">MAY</em> ignore unexpected 1xx status responses. 2430 2431 </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). 2434 2434 </p> 2435 2435 <div id="rfc.iref.73"></div> … … 2899 2899 <p>Examples of the two obsolete formats are</p><pre class="text">Sunday, 06-Nov-94 08:49:37 GMT ; obsolete RFC 850 format 2900 2900 Sun 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. 2902 2903 </p> 2903 2904 <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 587 587 </artwork></figure> 588 588 <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. 591 592 Additional information about the encoding parameters &MAY; be provided 592 593 by other header fields not defined by this specification. … … 1211 1212 to use actions within query parameters, such as "page?do=delete". 1212 1213 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 accessed1214 using a safe request method.Failure to do so will result in1214 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 1215 1216 unfortunate side-effects when automated processes perform a GET on 1216 1217 every URI reference for the sake of link maintenance, pre-fetching, … … 1594 1595 destination origin server identified by the request-target and, if 1595 1596 successful, thereafter restrict its behavior to blind forwarding of 1596 packets, in both directions, until the connectionis closed.1597 packets, in both directions, until the tunnel is closed. 1597 1598 </t> 1598 1599 <t> … … 1626 1627 </t> 1627 1628 <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="request"" x:indent-with=" "> 1639 CONNECT server.example.com:80 HTTP/1.1 1640 Host: server.example.com:80 1641 Proxy-Authorization: basic aGVsbG86d29ybGQ= 1642 1643 </artwork></figure> 1633 1644 <t> 1634 1645 There are significant risks in establishing a tunnel to arbitrary servers, … … 1642 1653 </t> 1643 1654 <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="request"" 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. 1659 1660 </t> 1660 1661 <t> … … 1743 1744 </t> 1744 1745 <t> 1745 A client &MUST-NOT; sendheader fields in a TRACE request containing1746 A client &MUST-NOT; generate header fields in a TRACE request containing 1746 1747 sensitive data that might be disclosed by the response. For example, it 1747 1748 would be foolish for a user agent to send stored user credentials … … 1831 1832 </t> 1832 1833 <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. 1834 1836 </t> 1835 1837 <t> … … 1867 1869 </t> 1868 1870 <t> 1869 Requirements for HTTP/1.1clients:1871 Requirements for clients: 1870 1872 <list style="symbols"> 1871 1873 <t> 1872 1873 1874 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. 1875 1877 </t> 1876 1878 <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. 1880 1892 </t> 1881 1893 </list> 1882 1894 </t> 1883 1895 <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: 1894 1897 <list style="symbols"> 1895 1898 <t> Upon receiving a request that includes an <x:ref>Expect</x:ref> header … … 1942 1945 </t> 1943 1946 <t> 1944 Requirements for HTTP/1.1proxies:1947 Requirements for proxies: 1945 1948 <list style="symbols"> 1946 1949 <t> If a proxy receives a request that includes an <x:ref>Expect</x:ref> … … 1958 1961 numbers received from recently-referenced next-hop servers. 1959 1962 </t> 1960 <t> A proxy &MUST-NOT; forward a <x:ref>100 (Continue)</x:ref> response if the1961 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) 1962 1965 client and did not include an <x:ref>Expect</x:ref> header field with 1963 1966 the "100-continue" expectation. This requirement overrides the … … 1988 1991 </t> 1989 1992 <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. 2001 2006 </t> 2002 2007 </section> … … 2609 2614 understand the class of any status code, as indicated by the first 2610 2615 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 an2612 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. 2613 2618 </t> 2614 2619 <t> … … 2740 2745 </t> 2741 2746 <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 2744 2748 requested the generation of the 1xx response. For example, if a 2745 2749 proxy adds an "Expect: 100-continue" field when it forwards a request, … … 3693 3697 <t> 3694 3698 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. 3697 3702 </t> 3698 3703 <t>
Note: See TracChangeset
for help on using the changeset viewer.