Changeset 1178 for draft-ietf-httpbis/latest/p1-messaging.xml
- Timestamp:
- 14/03/11 05:07:18 (11 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.xml
r1176 r1178 1186 1186 </t> 1187 1187 <t> 1188 Some old HTTP/1.0 client implementations generatean extra CRLF1188 Some old HTTP/1.0 client implementations send an extra CRLF 1189 1189 after a POST request as a lame workaround for some early server 1190 1190 applications that failed to read message-body content that was … … 4895 4895 </section> 4896 4896 4897 <section title=" Compatibility with Previous Versions" anchor="compatibility">4897 <section title="HTTP Version History" anchor="compatibility"> 4898 4898 <t> 4899 4899 HTTP has been in use by the World-Wide Web global information initiative … … 4921 4921 It is beyond the scope of a protocol specification to mandate 4922 4922 compliance with previous versions. HTTP/1.1 was deliberately 4923 designed, however, to make supporting previous versions easy. It is 4924 worth noting that, at the time of composing this specification, we would 4925 expect general-purpose HTTP/1.1 servers to: 4926 <list style="symbols"> 4927 <t>understand any valid request in the format of HTTP/1.0 and 4928 1.1;</t> 4929 4930 <t>respond appropriately with a message in the same major version 4931 used by the client.</t> 4932 </list> 4933 </t> 4934 <t> 4935 And we would expect HTTP/1.1 clients to: 4936 <list style="symbols"> 4937 <t>understand any valid response in the format of HTTP/1.0 or 4938 1.1.</t> 4939 </list> 4940 </t> 4941 <t> 4942 For most implementations of HTTP/1.0, each connection is established 4943 by the client prior to the request and closed by the server after 4944 sending the response. Some implementations implement the Keep-Alive 4945 version of persistent connections described in <xref x:sec="19.7.1" x:fmt="of" target="RFC2068"/>. 4923 designed, however, to make supporting previous versions easy. 4924 We would expect a general-purpose HTTP/1.1 server to understand 4925 any valid request in the format of HTTP/1.0 and respond appropriately 4926 with an HTTP/1.1 message that only uses features understood (or 4927 safely ignored) by HTTP/1.0 clients. Likewise, would expect 4928 an HTTP/1.1 client to understand any valid HTTP/1.0 response. 4929 </t> 4930 <t> 4931 Since HTTP/0.9 did not support header fields in a request, 4932 there is no mechanism for it to support name-based virtual 4933 hosts (selection of resource by inspection of the Host header 4934 field). Any server that implements name-based virtual hosts 4935 ought to disable support for HTTP/0.9. Most requests that 4936 appear to be HTTP/0.9 are, in fact, badly constructed HTTP/1.x 4937 requests wherein a buggy client failed to properly encode 4938 linear whitespace found in a URI reference and placed in 4939 the request-target. 4946 4940 </t> 4947 4941 … … 4952 4946 </t> 4953 4947 4954 <section title=" Changes to Simplify Multi-homed Web Servers and Conserve IP Addresses" anchor="changes.to.simplify.multi-homed.web.servers.and.conserve.ip.addresses">4948 <section title="Multi-homed Web Servers" anchor="changes.to.simplify.multi-homed.web.servers.and.conserve.ip.addresses"> 4955 4949 <t> 4956 4950 The requirements that clients and servers support the Host header 4957 4951 field (<xref target="header.host"/>), report an error if it is 4958 4952 missing from an HTTP/1.1 request, and accept absolute URIs (<xref target="request-target"/>) 4959 are among the most important changes defined by this 4960 specification. 4953 are among the most important changes defined by HTTP/1.1. 4961 4954 </t> 4962 4955 <t> … … 4964 4957 addresses and servers; there was no other established mechanism for 4965 4958 distinguishing the intended server of a request than the IP address 4966 to which that request was directed. The changes outlined above will 4967 allow the Internet, once older HTTP clients are no longer common, to 4968 support multiple Web sites from a single IP address, greatly 4969 simplifying large operational Web servers, where allocation of many 4970 IP addresses to a single host has created serious problems. The 4971 Internet will also be able to recover the IP addresses that have been 4972 allocated for the sole purpose of allowing special-purpose domain 4973 names to be used. Given the rate of growth of 4974 the Web, and the number of servers already deployed, it is extremely 4975 important that all implementations of HTTP (including updates to 4976 existing HTTP/1.0 applications) correctly implement these 4977 requirements: 4978 <list style="symbols"> 4979 <t>Both clients and servers &MUST; support the Host header field.</t> 4980 4981 <t>A client that sends an HTTP/1.1 request &MUST; send a Host header field.</t> 4982 4983 <t>Servers &MUST; report a 400 (Bad Request) error if an HTTP/1.1 4984 request does not include a Host header field.</t> 4985 4986 <t>Servers &MUST; accept absolute URIs.</t> 4987 </list> 4988 </t> 4989 </section> 4990 </section> 4991 4992 <section title="Compatibility with HTTP/1.0 Persistent Connections" anchor="compatibility.with.http.1.0.persistent.connections"> 4959 to which that request was directed. The Host header field was 4960 introduced during the development of HTTP/1.1 and, though it was 4961 quickly implemented by most HTTP/1.0 browsers, additional requirements 4962 were placed on all HTTP/1.1 requests in order to ensure complete 4963 adoption. At the time of this writing, most HTTP-based services 4964 are dependent upon the Host header field for targeting requests. 4965 </t> 4966 </section> 4967 4968 <section title="Keep-Alive Connections" anchor="compatibility.with.http.1.0.persistent.connections"> 4969 <t> 4970 For most implementations of HTTP/1.0, each connection is established 4971 by the client prior to the request and closed by the server after 4972 sending the response. However, some implementations implement the 4973 Keep-Alive version of persistent connections described in 4974 <xref x:sec="19.7.1" x:fmt="of" target="RFC2068"/>. 4975 </t> 4993 4976 <t> 4994 4977 Some clients and servers might wish to be compatible with some … … 5015 4998 declaring non-persistence. See <xref target="header.connection"/>. 5016 4999 </t> 5017 <t> 5018 The original HTTP/1.0 form of persistent connections (the Connection: 5019 Keep-Alive and Keep-Alive header field) is documented in <xref x:sec="19.7.1" x:fmt="of" target="RFC2068"/>. 5020 </t> 5000 </section> 5021 5001 </section> 5022 5002
Note: See TracChangeset
for help on using the changeset viewer.