Changeset 1520 for draft-ietf-httpbis/latest/p1-messaging.xml
- Timestamp:
- 30/01/12 03:09:15 (9 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
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
Note: See TracChangeset
for help on using the changeset viewer.