Changeset 1148
- Timestamp:
- 05/03/11 10:54:06 (12 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.xml
r1145 r1148 51 51 <?rfc-ext allow-markup-in-artwork="yes" ?> 52 52 <?rfc-ext include-references-in-index="yes" ?> 53 <rfc obsoletes="2 616" updates="2817" category="std" x:maturity-level="draft"53 <rfc obsoletes="2145,2616" updates="2817" category="std" x:maturity-level="draft" 54 54 ipr="pre5378Trust200902" docName="draft-ietf-httpbis-p1-messaging-&ID-VERSION;" 55 55 xmlns:x='http://purl.org/net/xml2rfc/ext'> … … 271 271 <t> 272 272 This document is Part 1 of the seven-part specification of HTTP, 273 defining the protocol referred to as "HTTP/1.1" andobsoleting274 <xref target="RFC2616"/> .273 defining the protocol referred to as "HTTP/1.1", obsoleting 274 <xref target="RFC2616"/> and <xref target="RFC2145"/>. 275 275 Part 1 describes the architectural elements that are used or 276 276 referred to in HTTP, defines the "http" and "https" URI schemes, … … 640 640 </section> 641 641 642 <section title="Connections and Transport Independence" anchor="transport-independence"> 643 <t> 644 HTTP messaging is independent of the underlying transport or 645 session-layer connection protocol(s). HTTP only presumes a reliable 646 transport with in-order delivery of requests and the corresponding 647 in-order delivery of responses. The mapping of HTTP request and 648 response structures onto the data units of the underlying transport 649 protocol is outside the scope of this specification. 650 </t> 651 <t> 652 The specific connection protocols to be used for an interaction 653 are determined by client configuration and the identifier (if any) 654 provided for the request target. For example, the "http" URI scheme 655 (<xref target="http.uri"/>) indicates a default connection of TCP 656 over IP, with a default TCP port of 80, but the client might be 657 configured to use a proxy via some other connection port or protocol 658 instead of using the defaults. 659 </t> 660 <t> 661 A connection might be used for multiple HTTP request/response exchanges, 662 as defined in <xref target="persistent.connections"/>. 663 </t> 664 </section> 665 642 666 <section title="Intermediaries" anchor="intermediaries"> 643 667 <iref primary="true" item="intermediary"/> 644 668 <t> 645 A more complicated situation occurs when one or more intermediaries646 a re present in the request/response chain. There are three common647 forms ofintermediary: proxy, gateway, and tunnel. In some cases,669 HTTP enables the use of intermediaries to satisfy requests through 670 a chain of connections. There are three common forms of HTTP 671 intermediary: proxy, gateway, and tunnel. In some cases, 648 672 a single intermediary might act as an origin server, proxy, gateway, 649 673 or tunnel, switching behavior based on the nature of each request. … … 790 814 </section> 791 815 792 <section title="Transport Independence" anchor="transport-independence"> 793 <t> 794 HTTP systems are used in a wide variety of environments, from 795 corporate intranets with high-bandwidth links to long-distance 796 communication over low-power radio links and intermittent connectivity. 797 </t> 798 <t> 799 HTTP communication usually takes place over TCP/IP connections. The 800 default port is TCP 80 (<eref target="http://www.iana.org/assignments/port-numbers"/>), but other ports can be used. This does 801 not preclude HTTP from being implemented on top of any other protocol 802 on the Internet, or on other networks. HTTP only presumes a reliable 803 transport; any protocol that provides such guarantees can be used; 804 the mapping of the HTTP/1.1 request and response structures onto the 805 transport data units of the protocol in question is outside the scope 806 of this specification. 807 </t> 808 <t> 809 In HTTP/1.0, most implementations used a new connection for each 810 request/response exchange. In HTTP/1.1, a connection might be used for 811 one or more request/response exchanges, although connections might be 812 closed for a variety of reasons (see <xref target="persistent.connections"/>). 813 </t> 814 </section> 815 816 <section title="HTTP Version" anchor="http.version"> 816 <section title="Protocol Versioning" anchor="http.version"> 817 817 <x:anchor-alias value="HTTP-Version"/> 818 818 <x:anchor-alias value="HTTP-Prot-Name"/> 819 819 <t> 820 HTTP uses a "<major>.<minor>" numbering scheme to indicate versions 821 of the protocol. The protocol versioning policy is intended to allow 822 the sender to indicate the format of a message and its capacity for 823 understanding further HTTP communication, rather than the features 824 obtained via that communication. No change is made to the version 825 number for the addition of message components which do not affect 826 communication behavior or which only add to extensible field values. 827 The <minor> number is incremented when the changes made to the 828 protocol add features which do not change the general message parsing 829 algorithm, but which might add to the message semantics and imply 830 additional capabilities of the sender. The <major> number is 831 incremented when the format of a message within the protocol is 832 changed. See <xref target="RFC2145"/> for a fuller explanation. 820 HTTP uses a "<major>.<minor>" numbering scheme to indicate 821 versions of the protocol. This specification defines version "1.1". 822 The protocol version as a whole indicates the sender's compliance 823 with the set of requirements laid out in that version's corresponding 824 specification of HTTP. 833 825 </t> 834 826 <t> … … 841 833 </artwork></figure> 842 834 <t> 843 Note that the major and minor numbers &MUST; be treated as separate 844 integers and that each &MAY; be incremented higher than a single digit. 845 Thus, HTTP/2.4 is a lower version than HTTP/2.13, which in turn is 846 lower than HTTP/12.3. Leading zeros &MUST; be ignored by recipients and 847 &MUST-NOT; be sent. 848 </t> 849 <t> 850 An application that sends a request or response message that includes 851 HTTP-Version of "HTTP/1.1" &MUST; be at least conditionally compliant 852 with this specification. Applications that are at least conditionally 853 compliant with this specification &SHOULD; use an HTTP-Version of 854 "HTTP/1.1" in their messages, and &MUST; do so for any message that is 855 not compatible with HTTP/1.0. For more details on when to send 856 specific HTTP-Version values, see <xref target="RFC2145"/>. 857 </t> 858 <t> 859 The HTTP version of an application is the highest HTTP version for 860 which the application is at least conditionally compliant. 861 </t> 862 <t> 863 Proxy and gateway applications need to be careful when forwarding 864 messages in protocol versions different from that of the application. 865 Since the protocol version indicates the protocol capability of the 866 sender, a proxy/gateway &MUST-NOT; send a message with a version 867 indicator which is greater than its actual version. If a higher 868 version request is received, the proxy/gateway &MUST; either downgrade 869 the request version, or respond with an error, or switch to tunnel 870 behavior. 871 </t> 872 <t> 873 Due to interoperability problems with HTTP/1.0 proxies discovered 874 since the publication of <xref target="RFC2068"/>, caching proxies &MUST;, gateways 875 &MAY;, and tunnels &MUST-NOT; upgrade the request to the highest version 876 they support. The proxy/gateway's response to that request &MUST; be in 877 the same major version as the request. 878 </t> 879 <x:note> 880 <t> 881 <x:h>Note:</x:h> Converting between versions of HTTP might involve modification 882 of header fields required or forbidden by the versions involved. 883 </t> 884 </x:note> 835 The HTTP version number consists of two non-negative decimal integers 836 separated by the "." (period or decimal point) character. The first 837 number ("major version") indicates the HTTP messaging syntax, whereas 838 the second number ("minor version") indicates the highest minor 839 version to which the sender is at least conditionally compliant and 840 able to understand for future communication. The minor version 841 advertises the sender's communication capabilities even when the 842 sender is only using a backwards-compatible subset of the protocol, 843 thereby letting the recipient know that more advanced features can 844 be used in response (by servers) or in future requests (by clients). 845 </t> 846 <t> 847 When comparing HTTP versions, the numbers &MUST; be compared 848 numerically rather than lexically. For example, HTTP/2.4 is a lower 849 version than HTTP/2.13, which in turn is lower than HTTP/12.3. 850 Leading zeros &MUST; be ignored by recipients and &MUST-NOT; be sent. 851 </t> 852 <t> 853 When an HTTP/1.1 message is sent to an HTTP/1.0 recipient 854 (or a recipient whose version is unknown), the HTTP/1.1 message is 855 constructed such that it will be interpreted as a valid HTTP/1.0 856 message even if all of the provided header fields not defined in 857 the HTTP/1.0 specification <xref target="RFC1945"/> are ignored. 858 This specification excludes incompatible message constructions by 859 imposing recipient-version requirements on new HTTP/1.1 features 860 that are not safely interpreted by earlier HTTP/1.0 recipients. 861 </t> 862 <t> 863 The interpretation of an HTTP message header field does not change 864 between minor versions of the same major version, though the default 865 behavior of a recipient in the absence of such a field can change. 866 Unless specified otherwise, header fields defined in HTTP/1.1 are 867 defined for all versions of HTTP/1.x. The most popular example of 868 this is the Host header field, which was introduced during the 869 standardization process of HTTP/1.1 and widely deployed for HTTP/1.0 870 requests out of necessity. 871 </t> 872 <t> 873 Likewise, new header fields can be defined such that, when they are 874 understood by a recipient, they might override or enhance the 875 interpretation of previously defined header fields. When an 876 implementation receives an unrecognized header field, the recipient 877 &MUST; ignore that header field for local processing regardless of 878 the message's HTTP version. An unrecognized header field received 879 by a proxy &MUST; be forwarded downstream unless the header field's 880 field-name is listed in the message's Connection header-field 881 (see <xref target="header.connection"/>). 882 These requirements allow HTTP's functionality to be enhanced without 883 requiring prior update of all compliant intermediaries. 884 </t> 885 <t> 886 Intermediaries that process HTTP messages (i.e., all intermediaries 887 other than those acting as a tunnel) &MUST; send their own HTTP-Version 888 in forwarded messages. In other words, they &MUST-NOT; blindly 889 forward the first line of an HTTP message without ensuring that the 890 protocol version matches what the intermediary understands, and 891 is at least conditionally compliant to, for both the receiving and 892 sending of messages. Forwarding an HTTP message without rewriting 893 the HTTP-Version might result in communication errors when downstream 894 recipients use the message sender's version to determine what features 895 are safe to use for later communication with that sender. 896 </t> 897 <t> 898 An HTTP client &SHOULD; send a request version equal to the highest 899 version for which the client is at least conditionally compliant and 900 whose major version is no higher than the highest version supported 901 by the server, if this is known. An HTTP client &MUST-NOT; send a 902 version for which it is not at least conditionally compliant. 903 </t> 904 <t> 905 An HTTP client &MAY; send a lower request version if it is known that 906 the server incorrectly implements the HTTP specification, but only 907 after the client has attempted at least one normal request and determined 908 from the response status or header fields (e.g., Server) that the 909 server improperly handles higher request versions. 910 </t> 911 <t> 912 An HTTP server &SHOULD; send a response version equal to the highest 913 version for which the server is at least conditionally compliant and 914 whose major version is less than or equal to the one received in the 915 request. An HTTP server &MUST-NOT; send a version for which it is not 916 at least conditionally compliant. A server &MAY; send a 505 (HTTP 917 Version Not Supported) response if it cannot send a response using the 918 major version used in the client's request. 919 </t> 920 <t> 921 An HTTP server &MAY; send an HTTP/1.0 response to an HTTP/1.0 request 922 if it is known or suspected that the client incorrectly implements the 923 HTTP specification and is incapable of correctly processing later 924 version responses, such as when a client fails to parse the version 925 number correctly or when an intermediary is known to blindly forward 926 the HTTP-Version even when it doesn't comply with the given minor 927 version of the protocol. Such protocol downgrades &SHOULD-NOT; be 928 performed unless triggered by specific client attributes, such as when 929 one or more of the request header fields (e.g., User-Agent) uniquely 930 match the values sent by a client known to be in error. 931 </t> 932 <t> 933 The intention of HTTP's versioning design is that the major number 934 will only be incremented if an incompatible message syntax is 935 introduced, and that the minor number will only be incremented when 936 changes made to the protocol have the effect of adding to the message 937 semantics or implying additional capabilities of the sender. However, 938 the minor version was not incremented for the changes introduced in 939 <xref target="RFC2616"/>, and this revision is specifically avoiding 940 any such changes to the protocol. 941 </t> 885 942 </section> 886 943
Note: See TracChangeset
for help on using the changeset viewer.