Changeset 1520 for draft-ietf-httpbis/latest
- Timestamp:
- 30/01/12 03:09:15 (11 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 6 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.html
r1519 r1520 892 892 applicable to an origin server also apply to the outbound communication of a gateway. A gateway communicates with inbound 893 893 servers using any protocol that it desires, including private extensions to HTTP that are outside the scope of this specification. 894 However, an HTTP-to-HTTP gateway that wishes to interoperate with third-party HTTP servers <em class="bcp14">MUST</em> co mply withHTTP user agent requirements on the gateway's inbound connection and <em class="bcp14">MUST</em> implement the Connection (<a href="#header.connection" id="rfc.xref.header.connection.1" title="Connection">Section 8.1</a>) and Via (<a href="#header.via" id="rfc.xref.header.via.1" title="Via">Section 8.8</a>) header fields for both connections.894 However, an HTTP-to-HTTP gateway that wishes to interoperate with third-party HTTP servers <em class="bcp14">MUST</em> conform to HTTP user agent requirements on the gateway's inbound connection and <em class="bcp14">MUST</em> implement the Connection (<a href="#header.connection" id="rfc.xref.header.connection.1" title="Connection">Section 8.1</a>) and Via (<a href="#header.via" id="rfc.xref.header.via.1" title="Via">Section 8.8</a>) header fields for both connections. 895 895 </p> 896 896 <p id="rfc.section.2.3.p.9"><span id="rfc.iref.t.2"></span> A "<dfn>tunnel</dfn>" acts as a blind relay between two connections without changing the messages. Once active, a tunnel is not considered a party … … 951 951 <h2 id="rfc.section.2.6"><a href="#rfc.section.2.6">2.6</a> <a id="http.version" href="#http.version">Protocol Versioning</a></h2> 952 952 <p id="rfc.section.2.6.p.1">HTTP uses a "<major>.<minor>" numbering scheme to indicate versions of the protocol. This specification defines version "1.1". 953 The protocol version as a whole indicates the sender's co mpliance with the set of requirements laid out in that version's953 The protocol version as a whole indicates the sender's conformance with the set of requirements laid out in that version's 954 954 corresponding specification of HTTP. 955 955 </p> … … 959 959 </pre><p id="rfc.section.2.6.p.4">The HTTP version number consists of two decimal digits separated by a "." (period or decimal point). The first digit ("major 960 960 version") indicates the HTTP messaging syntax, whereas the second digit ("minor version") indicates the highest minor version 961 to which the sender is at least conditionally compliant and able to understand for future communication. The minor version 962 advertises the sender's communication capabilities even when the sender is only using a backwards-compatible subset of the 963 protocol, thereby letting the recipient know that more advanced features can be used in response (by servers) or in future 964 requests (by clients). 961 to which the sender is conformant and able to understand for future communication. The minor version advertises the sender's 962 communication capabilities even when the sender is only using a backwards-compatible subset of the protocol, thereby letting 963 the recipient know that more advanced features can be used in response (by servers) or in future requests (by clients). 965 964 </p> 966 965 <p id="rfc.section.2.6.p.5">When an HTTP/1.1 message is sent to an HTTP/1.0 recipient <a href="#RFC1945" id="rfc.xref.RFC1945.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.0">[RFC1945]</cite></a> or a recipient whose version is unknown, the HTTP/1.1 message is constructed such that it can be interpreted as a valid HTTP/1.0 967 966 message if all of the newer features are ignored. This specification places recipient-version requirements on some new features 968 so that a co mpliant sender will only use compatible features until it has determined, through configuration or the receipt967 so that a conformant sender will only use compatible features until it has determined, through configuration or the receipt 969 968 of a message, that the recipient supports HTTP/1.1. 970 969 </p> … … 972 971 behavior of a recipient in the absence of such a field can change. Unless specified otherwise, header fields defined in HTTP/1.1 973 972 are defined for all versions of HTTP/1.x. In particular, the Host and Connection header fields ought to be implemented by 974 all HTTP/1.x implementations whether or not they advertise co mpliance with HTTP/1.1.973 all HTTP/1.x implementations whether or not they advertise conformance with HTTP/1.1. 975 974 </p> 976 975 <p id="rfc.section.2.6.p.7">New header fields can be defined such that, when they are understood by a recipient, they might override or enhance the interpretation 977 976 of previously defined header fields. When an implementation receives an unrecognized header field, the recipient <em class="bcp14">MUST</em> ignore that header field for local processing regardless of the message's HTTP version. An unrecognized header field received 978 by a proxy <em class="bcp14">MUST</em> be forwarded downstream unless the header field's field-name is listed in the message's Connection header-field (see <a href="#header.connection" id="rfc.xref.header.connection.2" title="Connection">Section 8.1</a>). These requirements allow HTTP's functionality to be enhanced without requiring prior update of all compliantintermediaries.979 </p> 980 <p id="rfc.section.2.6.p.8">Intermediaries that process HTTP messages (i.e., all intermediaries other than those acting as tunnels) <em class="bcp14">MUST</em> send their own HTTP-Version in forwarded messages. In other words, they <em class="bcp14">MUST NOT</em> blindly forward the first line of an HTTP message without ensuring that the protocol version matches what the intermediary981 understands, and is at least conditionally compliant to, for both the receiving and sending of messages. Forwarding an HTTP982 message without rewriting the HTTP-Version might result in communication errors when downstream recipients use the message983 sender's versionto determine what features are safe to use for later communication with that sender.984 </p> 985 <p id="rfc.section.2.6.p.9">An HTTP client <em class="bcp14">SHOULD</em> send a request version equal to the highest version for which the client is at least conditionally compliant and whose major986 version is no higher than the highest version supported by the server, if this is known. An HTTP client <em class="bcp14">MUST NOT</em> send a version for which it is not at least conditionally compliant.977 by a proxy <em class="bcp14">MUST</em> be forwarded downstream unless the header field's field-name is listed in the message's Connection header-field (see <a href="#header.connection" id="rfc.xref.header.connection.2" title="Connection">Section 8.1</a>). These requirements allow HTTP's functionality to be enhanced without requiring prior update of deployed intermediaries. 978 </p> 979 <p id="rfc.section.2.6.p.8">Intermediaries that process HTTP messages (i.e., all intermediaries other than those acting as tunnels) <em class="bcp14">MUST</em> send their own HTTP-Version in forwarded messages. In other words, they <em class="bcp14">MUST NOT</em> blindly forward the first line of an HTTP message without ensuring that the protocol version in that message matches a version 980 to which that intermediary is conformant for both the receiving and sending of messages. Forwarding an HTTP message without 981 rewriting the HTTP-Version might result in communication errors when downstream recipients use the message sender's version 982 to determine what features are safe to use for later communication with that sender. 983 </p> 984 <p id="rfc.section.2.6.p.9">An HTTP client <em class="bcp14">SHOULD</em> send a request version equal to the highest version to which the client is conformant and whose major version is no higher 985 than the highest version supported by the server, if this is known. An HTTP client <em class="bcp14">MUST NOT</em> send a version to which it is not conformant. 987 986 </p> 988 987 <p id="rfc.section.2.6.p.10">An HTTP client <em class="bcp14">MAY</em> send a lower request version if it is known that the server incorrectly implements the HTTP specification, but only after … … 990 989 that the server improperly handles higher request versions. 991 990 </p> 992 <p id="rfc.section.2.6.p.11">An HTTP server <em class="bcp14">SHOULD</em> send a response version equal to the highest version for which the server is at least conditionally compliant and whose major993 version is less than or equal to the one received in the request. An HTTP server <em class="bcp14">MUST NOT</em> send a version for which it is not at least conditionally compliant. A server <em class="bcp14">MAY</em> send a 505 (HTTP Version Not Supported) response if it cannot send a response using the major version used in the client's991 <p id="rfc.section.2.6.p.11">An HTTP server <em class="bcp14">SHOULD</em> send a response version equal to the highest version to which the server is conformant and whose major version is less than 992 or equal to the one received in the request. An HTTP server <em class="bcp14">MUST NOT</em> send a version to which it is not conformant. A server <em class="bcp14">MAY</em> send a 505 (HTTP Version Not Supported) response if it cannot send a response using the major version used in the client's 994 993 request. 995 994 </p> 996 995 <p id="rfc.section.2.6.p.12">An HTTP server <em class="bcp14">MAY</em> send an HTTP/1.0 response to an HTTP/1.0 request if it is known or suspected that the client incorrectly implements the HTTP 997 996 specification and is incapable of correctly processing later version responses, such as when a client fails to parse the version 998 number correctly or when an intermediary is known to blindly forward the HTTP-Version even when it doesn't co mply withthe997 number correctly or when an intermediary is known to blindly forward the HTTP-Version even when it doesn't conform to the 999 998 given minor version of the protocol. Such protocol downgrades <em class="bcp14">SHOULD NOT</em> be performed unless triggered by specific client attributes, such as when one or more of the request header fields (e.g., 1000 999 User-Agent) uniquely match the values sent by a client known to be in error. … … 1659 1658 </ol> 1660 1659 <p id="rfc.section.5.1.1.p.6">This requirement prevents an interoperability failure when the message is being received by an HTTP/1.1 (or later) proxy and 1661 forwarded to an HTTP/1.0 recipient. It avoids a situation where co mpliance with the protocol would have necessitated a possibly1660 forwarded to an HTTP/1.0 recipient. It avoids a situation where conformance with the protocol would have necessitated a possibly 1662 1661 infinite buffer on the proxy. 1663 1662 </p> … … 2061 2060 connection behavior based on the presence of connection options <em class="bcp14">MUST</em> do so based on the presence of the connection-token rather than only the presence of the optional header field. In other words, 2062 2061 if the connection option is received as a header field but not indicated within the Connection field-value, then the recipient <em class="bcp14">MUST</em> ignore the connection-specific header field because it has likely been forwarded by an intermediary that is only partially 2063 co mpliant.2062 conformant. 2064 2063 </p> 2065 2064 <p id="rfc.section.8.1.p.7">When defining new connection options, specifications ought to carefully consider existing deployed header fields and ensure … … 2905 2904 <p id="rfc.section.A.p.2">HTTP/1.1 remains compatible with HTTP/1.0 by including more stringent requirements that enable reliable implementations, adding 2906 2905 only those new features that will either be safely ignored by an HTTP/1.0 recipient or only sent when communicating with a 2907 party advertising co mpliance with HTTP/1.1.2908 </p> 2909 <p id="rfc.section.A.p.3">It is beyond the scope of a protocol specification to mandate co mpliance with previous versions. HTTP/1.1 was deliberately2906 party advertising conformance with HTTP/1.1. 2907 </p> 2908 <p id="rfc.section.A.p.3">It is beyond the scope of a protocol specification to mandate conformance with previous versions. HTTP/1.1 was deliberately 2910 2909 designed, however, to make supporting previous versions easy. We would expect a general-purpose HTTP/1.1 server to understand 2911 2910 any valid request in the format of HTTP/1.0 and respond appropriately with an HTTP/1.1 message that only uses features understood -
draft-ietf-httpbis/latest/p1-messaging.xml
r1518 r1520 589 589 the scope of this specification. However, an HTTP-to-HTTP gateway 590 590 that wishes to interoperate with third-party HTTP servers &MUST; 591 co mply withHTTP user agent requirements on the gateway's inbound591 conform to HTTP user agent requirements on the gateway's inbound 592 592 connection and &MUST; implement the Connection 593 593 (<xref target="header.connection"/>) and Via (<xref target="header.via"/>) … … 710 710 HTTP uses a "<major>.<minor>" numbering scheme to indicate 711 711 versions of the protocol. This specification defines version "1.1". 712 The protocol version as a whole indicates the sender's co mpliance712 The protocol version as a whole indicates the sender's conformance 713 713 with the set of requirements laid out in that version's corresponding 714 714 specification of HTTP. … … 726 726 (period or decimal point). The first digit ("major version") indicates the 727 727 HTTP messaging syntax, whereas the second digit ("minor version") indicates 728 the highest minor version to which the sender is at least conditionally729 co mpliant and able to understand for future communication. The minor728 the highest minor version to which the sender is 729 conformant and able to understand for future communication. The minor 730 730 version advertises the sender's communication capabilities even when the 731 731 sender is only using a backwards-compatible subset of the protocol, … … 739 739 as a valid HTTP/1.0 message if all of the newer features are ignored. 740 740 This specification places recipient-version requirements on some 741 new features so that a co mpliant sender will only use compatible741 new features so that a conformant sender will only use compatible 742 742 features until it has determined, through configuration or the 743 743 receipt of a message, that the recipient supports HTTP/1.1. … … 750 750 defined for all versions of HTTP/1.x. In particular, the Host and 751 751 Connection header fields ought to be implemented by all HTTP/1.x 752 implementations whether or not they advertise co mpliance with HTTP/1.1.752 implementations whether or not they advertise conformance with HTTP/1.1. 753 753 </t> 754 754 <t> … … 763 763 (see <xref target="header.connection"/>). 764 764 These requirements allow HTTP's functionality to be enhanced without 765 requiring prior update of all compliantintermediaries.765 requiring prior update of deployed intermediaries. 766 766 </t> 767 767 <t> … … 770 770 in forwarded messages. In other words, they &MUST-NOT; blindly 771 771 forward the first line of an HTTP message without ensuring that the 772 protocol version matches what the intermediary understands, and773 i s at least conditionally compliant to,for both the receiving and772 protocol version in that message matches a version to which that 773 intermediary is conformant for both the receiving and 774 774 sending of messages. Forwarding an HTTP message without rewriting 775 775 the HTTP-Version might result in communication errors when downstream … … 779 779 <t> 780 780 An HTTP client &SHOULD; send a request version equal to the highest 781 version for which the client is at least conditionally compliant and781 version to which the client is conformant and 782 782 whose major version is no higher than the highest version supported 783 783 by the server, if this is known. An HTTP client &MUST-NOT; send a 784 version for which it is not at least conditionally compliant.784 version to which it is not conformant. 785 785 </t> 786 786 <t> … … 793 793 <t> 794 794 An HTTP server &SHOULD; send a response version equal to the highest 795 version for which the server is at least conditionally compliant and795 version to which the server is conformant and 796 796 whose major version is less than or equal to the one received in the 797 request. An HTTP server &MUST-NOT; send a version forwhich it is not798 at least conditionally compliant. A server &MAY; send a 505 (HTTP797 request. An HTTP server &MUST-NOT; send a version to which it is not 798 conformant. A server &MAY; send a 505 (HTTP 799 799 Version Not Supported) response if it cannot send a response using the 800 800 major version used in the client's request. … … 806 806 version responses, such as when a client fails to parse the version 807 807 number correctly or when an intermediary is known to blindly forward 808 the HTTP-Version even when it doesn't co mply withthe given minor808 the HTTP-Version even when it doesn't conform to the given minor 809 809 version of the protocol. Such protocol downgrades &SHOULD-NOT; be 810 810 performed unless triggered by specific client attributes, such as when … … 2166 2166 message is being received by an HTTP/1.1 (or later) proxy and 2167 2167 forwarded to an HTTP/1.0 recipient. It avoids a situation where 2168 co mpliance with the protocol would have necessitated a possibly2168 conformance with the protocol would have necessitated a possibly 2169 2169 infinite buffer on the proxy. 2170 2170 </t> … … 2930 2930 within the Connection field-value, then the recipient &MUST; ignore 2931 2931 the connection-specific header field because it has likely been 2932 forwarded by an intermediary that is only partially co mpliant.2932 forwarded by an intermediary that is only partially conformant. 2933 2933 </t> 2934 2934 <t> … … 4847 4847 those new features that will either be safely ignored by an HTTP/1.0 4848 4848 recipient or only sent when communicating with a party advertising 4849 co mpliance with HTTP/1.1.4849 conformance with HTTP/1.1. 4850 4850 </t> 4851 4851 <t> 4852 4852 It is beyond the scope of a protocol specification to mandate 4853 co mpliance with previous versions. HTTP/1.1 was deliberately4853 conformance with previous versions. HTTP/1.1 was deliberately 4854 4854 designed, however, to make supporting previous versions easy. 4855 4855 We would expect a general-purpose HTTP/1.1 server to understand -
draft-ietf-httpbis/latest/p2-semantics.html
r1519 r1520 1408 1408 to a specific resource. Since a server's communication options typically depend on the resource, the "*" request is only useful 1409 1409 as a "ping" or "no-op" type of method; it does nothing beyond allowing the client to test the capabilities of the server. 1410 For example, this can be used to test a proxy for HTTP/1.1 co mpliance (or lack thereof).1410 For example, this can be used to test a proxy for HTTP/1.1 conformance (or lack thereof). 1411 1411 </p> 1412 1412 <p id="rfc.section.6.2.p.5">If the request-target is not an asterisk, the OPTIONS request applies only to the options that are available when communicating … … 1784 1784 (<a href="#RFC2068" id="rfc.xref.RFC2068.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>, <a href="http://tools.ietf.org/html/rfc2068#section-10.3.4">Section 10.3.4</a>). As user agents did not change their behavior to maintain backwards compatibility, the first revision of HTTP/1.1 added 1785 1785 yet another status code, 307 (Temporary Redirect), for which the backwards compatibility problems did not apply (<a href="#RFC2616" id="rfc.xref.RFC2616.2"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>, <a href="http://tools.ietf.org/html/rfc2616#section-10.3.8">Section 10.3.8</a>). Over 10 years later, most user agents still do method rewriting for status codes 301 and 302, therefore this specification 1786 makes that behavior co mpliant in case the original request was POST.1786 makes that behavior conformant in case the original request was POST. 1787 1787 </p> 1788 1788 </div> -
draft-ietf-httpbis/latest/p2-semantics.xml
r1518 r1520 945 945 type of method; it does nothing beyond allowing the client to test 946 946 the capabilities of the server. For example, this can be used to test 947 a proxy for HTTP/1.1 co mpliance (or lack thereof).947 a proxy for HTTP/1.1 conformance (or lack thereof). 948 948 </t> 949 949 <t> … … 1702 1702 Over 10 years later, most user agents still do method rewriting for 1703 1703 status codes 301 and 302, therefore this specification makes that behavior 1704 co mpliant in case the original request was POST.1704 conformant in case the original request was POST. 1705 1705 </t> 1706 1706 </x:note> -
draft-ietf-httpbis/latest/p3-payload.html
r1519 r1520 1687 1687 <h2 id="rfc.section.A.1"><a href="#rfc.section.A.1">A.1</a> <a id="mime-version" href="#mime-version">MIME-Version</a></h2> 1688 1688 <p id="rfc.section.A.1.p.1">HTTP is not a MIME-compliant protocol. However, HTTP/1.1 messages <em class="bcp14">MAY</em> include a single MIME-Version header field to indicate what version of the MIME protocol was used to construct the message. 1689 Use of the MIME-Version header field indicates that the message is in full compliance with the MIME protocol (as defined in <a href="#RFC2045" id="rfc.xref.RFC2045.2"><cite title="Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies">[RFC2045]</cite></a>). Proxies/gateways are responsible for ensuring full compliance (where possible) when exporting HTTP messages to strict MIME 1690 environments. 1689 Use of the MIME-Version header field indicates that the message is in full conformance with the MIME protocol (as defined 1690 in <a href="#RFC2045" id="rfc.xref.RFC2045.2"><cite title="Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies">[RFC2045]</cite></a>). Proxies/gateways are responsible for ensuring full conformance (where possible) when exporting HTTP messages to strict 1691 MIME environments. 1691 1692 </p> 1692 1693 <div id="rfc.figure.u.29"></div><pre class="inline"><span id="rfc.iref.g.24"></span> <a href="#mime-version" class="smpl">MIME-Version</a> = 1*<a href="#notation" class="smpl">DIGIT</a> "." 1*<a href="#notation" class="smpl">DIGIT</a> -
draft-ietf-httpbis/latest/p3-payload.xml
r1518 r1520 2389 2389 version of the MIME protocol was used to construct the message. Use 2390 2390 of the MIME-Version header field indicates that the message is in 2391 full co mpliance with the MIME protocol (as defined in <xref target="RFC2045"/>).2392 Proxies/gateways are responsible for ensuring full co mpliance (where2391 full conformance with the MIME protocol (as defined in <xref target="RFC2045"/>). 2392 Proxies/gateways are responsible for ensuring full conformance (where 2393 2393 possible) when exporting HTTP messages to strict MIME environments. 2394 2394 </t>
Note: See TracChangeset
for help on using the changeset viewer.