Changeset 374 for draft-ietf-httpbis/latest/p1-messaging.xml
- Timestamp:
- 13/11/08 22:27:55 (14 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.xml
r372 r374 229 229 <t> 230 230 The Hypertext Transfer Protocol (HTTP) is an application-level 231 protocol for distributed, collaborative, hypermedia information 232 systems. HTTP has been in use by the World-Wide Web global 233 information initiative since 1990. The first version of HTTP, commonly 234 referred to as HTTP/0.9, was a simple protocol for raw data transfer 235 across the Internet with only a single method and no metadata. 236 HTTP/1.0, as defined by <xref target="RFC1945"/>, improved 237 the protocol by allowing messages to be in the format of MIME-like 238 messages, containing metadata about the data transferred and 239 modifiers on the request/response semantics. However, HTTP/1.0 did 240 not sufficiently take into consideration the effects of hierarchical 241 proxies, caching, the need for persistent connections, or name-based 242 virtual hosts. In addition, the proliferation of incompletely-implemented 243 applications calling themselves "HTTP/1.0" necessitated a 244 protocol version change in order for two communicating applications 245 to determine each other's true capabilities. 246 </t> 247 <t> 248 This document is Part 1 of the seven-part specification that defines 249 the protocol referred to as "HTTP/1.1", obsoleting <xref target="RFC2616"/>. 250 HTTP/1.1 remains compatible with HTTP/1.0 by including more stringent 251 requirements that enable reliable implementations and adding only 252 those new features that will either be safely ignored by an HTTP/1.0 253 recipient or only sent when communicating with a party advertising 254 compliance with HTTP/1.1. 255 Part 1 defines those aspects of HTTP/1.1 related to overall network 256 operation, message framing, interaction with transport protocols, and 257 URI schemes. 258 </t> 259 <t> 260 This document is currently disorganized in order to minimize the changes 261 between drafts and enable reviewers to see the smaller errata changes. 262 The next draft will reorganize the sections to better reflect the content. 263 In particular, the sections will be organized according to the typical 264 process of deciding when to use HTTP (URI schemes), overall network operation, 265 connection management, message framing, and generic message parsing. 266 The current mess reflects how widely dispersed these topics and associated 267 requirements had become in <xref target="RFC2616"/>. 268 </t> 269 270 <section title="Purpose" anchor="intro.purpose"> 271 <t> 272 Practical information systems require more functionality than simple 273 retrieval, including search, front-end update, and annotation. HTTP 274 allows an open-ended set of methods and headers that indicate the 275 purpose of a request <xref target="RFC2324"/>. It builds on the discipline of reference 276 provided by the Uniform Resource Identifier (URI) <xref target="RFC1630"/>, as a location 277 (URL) <xref target="RFC1738"/> or name (URN) <xref target="RFC1737"/>, for indicating the resource to which a 278 method is to be applied. Messages are passed in a format similar to 279 that used by Internet mail <xref target="RFC5322"/> as defined by the Multipurpose 280 Internet Mail Extensions (MIME) <xref target="RFC2045"/>. 281 </t> 282 <t> 283 HTTP is also used as a generic protocol for communication between 284 user agents and proxies/gateways to other Internet systems, including 285 those supported by the SMTP <xref target="RFC2821"/>, NNTP <xref target="RFC3977"/>, FTP <xref target="RFC959"/>, Gopher <xref target="RFC1436"/>, 286 and WAIS <xref target="WAIS"/> protocols. In this way, HTTP allows basic hypermedia 287 access to resources available from diverse applications. 288 </t> 289 </section> 231 request/response protocol that uses extensible semantics and MIME-like 232 message payloads for flexible interaction with network-based hypermedia 233 information systems. HTTP relies upon the Uniform Resource Identifier (URI) 234 standard <xref target="RFC3986"/> to indicate resource targets for 235 interaction and to identify other resources. 236 Messages are passed in a format similar to that used by Internet mail 237 <xref target="RFC5322"/> and the Multipurpose Internet Mail Extensions 238 (MIME) <xref target="RFC2045"/> (see &diff2045entity; for the differences 239 between HTTP and MIME messages). 240 </t> 241 <t> 242 HTTP is also designed for use as a generic protocol for translating 243 communication to and from other Internet information systems, such as 244 USENET news services via NNTP <xref target="RFC3977"/>, 245 file services via FTP <xref target="RFC959"/>, 246 Gopher <xref target="RFC1436"/>, and WAIS <xref target="WAIS"/>. 247 HTTP proxies and gateways provide access to alternative information 248 services by translating their diverse protocols into a hypermedia 249 format that can be viewed and manipulated by clients in the same way 250 as HTTP services. 251 </t> 252 <t> 253 This document is Part 1 of the seven-part specification of HTTP, 254 defining the protocol referred to as "HTTP/1.1" and obsoleting 255 <xref target="RFC2616"/>. 256 Part 1 defines how clients determine when to use HTTP, the URI schemes 257 specific to HTTP-based resources, overall network operation with 258 transport protocol connection management, and HTTP message framing. 259 Our goal is to define all of the mechanisms necessary for HTTP message 260 handling that are independent of message semantics, thereby defining the 261 complete set of requirements for an HTTP message relay or generic 262 message parser. 263 </t> 290 264 291 265 <section title="Requirements" anchor="intro.requirements"> … … 697 671 <section title="Uniform Resource Identifiers" anchor="uri"> 698 672 <t> 699 URIs have been known by many names: WWW addresses, Universal Document 700 Identifiers, Universal Resource Identifiers <xref target="RFC1630"/>, and finally the 701 combination of Uniform Resource Locators (URL) <xref target="RFC1738"/> and Names (URN) 702 <xref target="RFC1737"/>. As far as HTTP is concerned, Uniform Resource Identifiers are 703 simply formatted strings which identify--via name, location, or any 704 other characteristic--a resource. 705 </t> 706 707 <section title="General Syntax" anchor="general.syntax"> 708 <x:anchor-alias value="absoluteURI"/> 673 Uniform Resource Identifiers (URIs) <xref target="RFC3986"/> are used in HTTP 674 to indicate the target of a request and to identify additional resources related 675 to that resource, the request, or the response. Each protocol element in HTTP 676 that allows a URI reference will indicate in its ABNF whether the element allows 677 only a URI in absolute form, any relative reference, or some limited subset of 678 the URI-reference grammar. Unless otherwise indicated, relative URI references 679 are to be parsed relative to the URI corresponding to the request target 680 (the base URI). 681 </t> 682 <x:anchor-alias value="URI-reference"/> 683 <x:anchor-alias value="absolute-URI"/> 709 684 <x:anchor-alias value="authority"/> 710 685 <x:anchor-alias value="fragment"/> 686 <x:anchor-alias value="path-abempty"/> 711 687 <x:anchor-alias value="path-absolute"/> 712 688 <x:anchor-alias value="port"/> 713 689 <x:anchor-alias value="query"/> 714 690 <x:anchor-alias value="relativeURI"/> 691 <x:anchor-alias value="relative-part"/> 715 692 <x:anchor-alias value="uri-host"/> 716 693 <t> 717 URIs in HTTP can be represented in absolute form or relative to some 718 known base URI <xref target="RFC1808"/>, depending upon the context of their use. The two 719 forms are differentiated by the fact that absolute URIs always begin 720 with a scheme name followed by a colon. For definitive information on 721 URL syntax and semantics, see "Uniform Resource Identifiers (URI): 722 Generic Syntax and Semantics," <xref target="RFC2396"/> (which replaces <xref target="RFC1738"/> 723 and <xref target="RFC1808"/>). This specification adopts the 724 definitions of "URI-reference", "absoluteURI", "fragment", "relativeURI", "port", 725 "host", "abs_path", "query", and "authority" from that specification: 726 </t> 727 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="absoluteURI"/><iref primary="true" item="Grammar" subitem="authority"/><iref primary="true" item="Grammar" subitem="path-absolute"/><iref primary="true" item="Grammar" subitem="port"/><iref primary="true" item="Grammar" subitem="query"/><iref primary="true" item="Grammar" subitem="relativeURI"/><iref primary="true" item="Grammar" subitem="uri-host"/> 728 <x:ref>absoluteURI</x:ref> = <absoluteURI, defined in <xref target="RFC2396" x:fmt="," x:sec="3"/>> 729 <x:ref>authority</x:ref> = <authority, defined in <xref target="RFC2396" x:fmt="," x:sec="3.2"/>> 730 <x:ref>fragment</x:ref> = <fragment, defined in <xref target="RFC2396" x:fmt="," x:sec="4.1"/>> 731 <x:ref>path-absolute</x:ref> = <abs_path, defined in <xref target="RFC2396" x:fmt="," x:sec="3"/>> 732 <x:ref>port</x:ref> = <port, defined in <xref target="RFC2396" x:fmt="," x:sec="3.2.2"/>> 733 <x:ref>query</x:ref> = <query, defined in <xref target="RFC2396" x:fmt="," x:sec="3.4"/>> 734 <x:ref>relativeURI</x:ref> = <relativeURI, defined in <xref target="RFC2396" x:fmt="," x:sec="5"/>> 735 <x:ref>uri-host</x:ref> = <host, defined in <xref target="RFC2396" x:fmt="," x:sec="3.2.2"/>> 736 </artwork></figure> 737 <t> 738 HTTP does not place any a priori limit on the length of 694 This specification adopts the definitions of "URI-reference", "absolute-URI", "fragment", "port", 695 "host", "path-abempty", "path-absolute", "query", and "authority" from <xref target="RFC3986"/>: 696 </t> 697 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="URI-reference"/><iref primary="true" item="Grammar" subitem="absolute-URI"/><iref primary="true" item="Grammar" subitem="authority"/><iref primary="true" item="Grammar" subitem="path-absolute"/><iref primary="true" item="Grammar" subitem="port"/><iref primary="true" item="Grammar" subitem="query"/><iref primary="true" item="Grammar" subitem="uri-host"/><iref primary="true" item="Grammar" subitem="relativeURI"/><iref primary="true" item="Grammar" subitem="relative-part"/> 698 <x:ref>absolute-URI</x:ref> = <absolute-URI, defined in <xref target="RFC3986" x:fmt="," x:sec="4.3"/>> 699 <x:ref>authority</x:ref> = <authority, defined in <xref target="RFC3986" x:fmt="," x:sec="3.2"/>> 700 <x:ref>fragment</x:ref> = <fragment, defined in <xref target="RFC3986" x:fmt="," x:sec="3.5"/>> 701 <x:ref>path-abempty</x:ref> = <path-abempty, defined in <xref target="RFC3986" x:fmt="," x:sec="3.3"/>> 702 <x:ref>path-absolute</x:ref> = <path-absolute, defined in <xref target="RFC3986" x:fmt="," x:sec="3.3"/>> 703 <x:ref>port</x:ref> = <port, defined in <xref target="RFC3986" x:fmt="," x:sec="3.2.3"/>> 704 <x:ref>query</x:ref> = <query, defined in <xref target="RFC3986" x:fmt="," x:sec="3.4"/>> 705 <x:ref>uri-host</x:ref> = <host, defined in <xref target="RFC3986" x:fmt="," x:sec="3.2.2"/>> 706 707 <x:ref>relative-part</x:ref> = <relative-part, defined in <xref target="RFC3986" x:fmt="," x:sec="4.2"/>> 708 <x:ref>relativeURI</x:ref> = <x:ref>relative-part</x:ref> [ "?" <x:ref>query</x:ref> ] 709 </artwork></figure> 710 <t> 711 HTTP does not place an a priori limit on the length of 739 712 a URI. Servers &MUST; be able to handle the URI of any resource they 740 713 serve, and &SHOULD; be able to handle URIs of unbounded length if they … … 752 725 </list> 753 726 </t> 754 </section> 755 756 <section title="http URL" anchor="http.url"> 757 <x:anchor-alias value="http-URL"/> 727 728 <section title="http URI scheme" anchor="http.uri"> 729 <x:anchor-alias value="http-URI"/> 758 730 <iref item="http URI scheme" primary="true"/> 759 731 <iref item="URI scheme" subitem="http" primary="true"/> 760 732 <t> 761 733 The "http" scheme is used to locate network resources via the HTTP 762 protocol. This section defines the scheme-specific syntax and 763 semantics for http URLs. 764 </t> 765 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="http-URL"/> 766 <x:ref>http-URL</x:ref> = "http:" "//" <x:ref>uri-host</x:ref> [ ":" <x:ref>port</x:ref> ] 767 [ <x:ref>path-absolute</x:ref> [ "?" <x:ref>query</x:ref> ]] 734 protocol. This section defines the syntax and semantics for identifiers 735 using the http or https URI schemes. 736 </t> 737 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="http-URI"/> 738 <x:ref>http-URI</x:ref> = "http:" "//" <x:ref>authority</x:ref> <x:ref>path-abempty</x:ref> [ "?" <x:ref>query</x:ref> ] 768 739 </artwork></figure> 769 740 <t> … … 802 773 <t> 803 774 Characters other than those in the "reserved" set (see 804 <xref target="RFC 2396" x:fmt="," x:sec="2.2"/>) are equivalent to their775 <xref target="RFC3986" x:fmt="," x:sec="2.2"/>) are equivalent to their 805 776 ""%" <x:ref>HEXDIG</x:ref> <x:ref>HEXDIG</x:ref>" encoding. 806 777 </t> … … 1449 1420 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Request-URI"/> 1450 1421 <x:ref>Request-URI</x:ref> = "*" 1451 / <x:ref>absolute URI</x:ref>1422 / <x:ref>absolute-URI</x:ref> 1452 1423 / ( <x:ref>path-absolute</x:ref> [ "?" <x:ref>query</x:ref> ] ) 1453 1424 / <x:ref>authority</x:ref> … … 1464 1435 </artwork></figure> 1465 1436 <t> 1466 The absolute URI form is &REQUIRED; when the request is being made to a1437 The absolute-URI form is &REQUIRED; when the request is being made to a 1467 1438 proxy. The proxy is requested to forward the request or service it 1468 1439 from a valid cache, and return the response. Note that the proxy &MAY; 1469 1440 forward the request on to another proxy or directly to the server 1470 specified by the absolute URI. In order to avoid request loops, a1441 specified by the absolute-URI. In order to avoid request loops, a 1471 1442 proxy &MUST; be able to recognize all of its server names, including 1472 1443 any aliases, local variations, and the numeric IP address. An example … … 1477 1448 </artwork></figure> 1478 1449 <t> 1479 To allow for transition to absolute URIs in all requests in future1480 versions of HTTP, all HTTP/1.1 servers &MUST; accept the absolute URI1450 To allow for transition to absolute-URIs in all requests in future 1451 versions of HTTP, all HTTP/1.1 servers &MUST; accept the absolute-URI 1481 1452 form in requests, even though HTTP/1.1 clients will only generate 1482 1453 them in requests to proxies. … … 1488 1459 The most common form of Request-URI is that used to identify a 1489 1460 resource on an origin server or gateway. In this case the absolute 1490 path of the URI &MUST; be transmitted (see <xref target=" general.syntax"/>, path-absolute) as1461 path of the URI &MUST; be transmitted (see <xref target="http.uri"/>, path-absolute) as 1491 1462 the Request-URI, and the network location of the URI (authority) &MUST; 1492 1463 be transmitted in a Host header field. For example, a client wishing … … 1506 1477 <t> 1507 1478 The Request-URI is transmitted in the format specified in 1508 <xref target=" general.syntax"/>. If the Request-URI is encoded using the1479 <xref target="http.uri"/>. If the Request-URI is encoded using the 1509 1480 "% <x:ref>HEXDIG</x:ref> <x:ref>HEXDIG</x:ref>" encoding 1510 (<xref target="RFC 2396" x:fmt="," x:sec="2.4.1"/>), the origin server1481 (<xref target="RFC3986" x:fmt="," x:sec="2.4"/>), the origin server 1511 1482 &MUST; decode the Request-URI in order to 1512 1483 properly interpret the request. Servers &SHOULD; respond to invalid … … 1548 1519 resource on an HTTP/1.1 request: 1549 1520 <list style="numbers"> 1550 <t>If Request-URI is an absolute URI, the host is part of the1521 <t>If Request-URI is an absolute-URI, the host is part of the 1551 1522 Request-URI. Any Host header field value in the request &MUST; be 1552 1523 ignored.</t> 1553 <t>If the Request-URI is not an absolute URI, and the request includes1524 <t>If the Request-URI is not an absolute-URI, and the request includes 1554 1525 a Host header field, the host is determined by the Host header 1555 1526 field value.</t> … … 2246 2217 number of the resource being requested, as obtained from the original 2247 2218 URI given by the user or referring resource (generally an HTTP URL, 2248 as described in <xref target="http.ur l"/>). The Host field value &MUST; represent2219 as described in <xref target="http.uri"/>). The Host field value &MUST; represent 2249 2220 the naming authority of the origin server or gateway given by the 2250 2221 original URL. This allows the origin server or gateway to … … 2254 2225 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Host"/><iref primary="true" item="Grammar" subitem="Host-v"/> 2255 2226 <x:ref>Host</x:ref> = "Host" ":" <x:ref>OWS</x:ref> <x:ref>Host-v</x:ref> 2256 <x:ref>Host-v</x:ref> = <x:ref>uri-host</x:ref> [ ":" <x:ref>port</x:ref> ] ; <xref target="http.ur l"/>2227 <x:ref>Host-v</x:ref> = <x:ref>uri-host</x:ref> [ ":" <x:ref>port</x:ref> ] ; <xref target="http.uri"/> 2257 2228 </artwork></figure> 2258 2229 <t> … … 2677 2648 The entry for the "http" URI Scheme in the registry located at 2678 2649 <eref target="http://www.iana.org/assignments/uri-schemes.html"/> 2679 should be updated to point to <xref target="http.ur l"/> of this document2650 should be updated to point to <xref target="http.uri"/> of this document 2680 2651 (see <xref target="RFC4395"/>). 2681 2652 </t> … … 2976 2947 <section title="Acknowledgments" anchor="ack"> 2977 2948 <t> 2978 This specification makes heavy use of the augmented BNF and generic2979 constructs defined by David H. Crocker for <xref target="RFC5234"/>. Similarly, it2980 reuses many of the definitions provided by Nathaniel Borenstein and2981 Ned Freed for MIME <xref target="RFC2045"/>. We hope that their inclusion in this2982 specification will help reduce past confusion over the relationship2983 between HTTP and Internet mail message formats.2984 </t>2985 <t>2986 2949 HTTP has evolved considerably over the years. It has 2987 2950 benefited from a large and active developer community--the many … … 3031 2994 discovery of many of the problems that this document attempts to 3032 2995 rectify. 2996 </t> 2997 <t> 2998 This specification makes heavy use of the augmented BNF and generic 2999 constructs defined by David H. Crocker for <xref target="RFC5234"/>. Similarly, it 3000 reuses many of the definitions provided by Nathaniel Borenstein and 3001 Ned Freed for MIME <xref target="RFC2045"/>. We hope that their inclusion in this 3002 specification will help reduce past confusion over the relationship 3003 between HTTP and Internet mail message formats. 3033 3004 </t> 3034 3005 </section> … … 3305 3276 </reference> 3306 3277 3307 <reference anchor="RFC2396"> 3308 <front> 3309 <title abbrev="URI Generic Syntax">Uniform Resource Identifiers (URI): Generic Syntax</title> 3310 <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee"> 3311 <organization abbrev="MIT/LCS">World Wide Web Consortium</organization> 3312 <address><email>timbl@w3.org</email></address> 3313 </author> 3314 <author initials="R.T." surname="Fielding" fullname="Roy T. Fielding"> 3315 <organization abbrev="U.C. Irvine">Department of Information and Computer Science</organization> 3316 <address><email>fielding@ics.uci.edu</email></address> 3317 </author> 3318 <author initials="L." surname="Masinter" fullname="Larry Masinter"> 3319 <organization abbrev="Xerox Corporation">Xerox PARC</organization> 3320 <address><email>masinter@parc.xerox.com</email></address> 3321 </author> 3322 <date month="August" year="1998"/> 3323 </front> 3324 <seriesInfo name="RFC" value="2396"/> 3278 <reference anchor="RFC3986"> 3279 <front> 3280 <title abbrev='URI Generic Syntax'>Uniform Resource Identifier (URI): Generic Syntax</title> 3281 <author initials='T.' surname='Berners-Lee' fullname='Tim Berners-Lee'> 3282 <organization abbrev="W3C/MIT">World Wide Web Consortium</organization> 3283 <address> 3284 <email>timbl@w3.org</email> 3285 <uri>http://www.w3.org/People/Berners-Lee/</uri> 3286 </address> 3287 </author> 3288 <author initials='R.' surname='Fielding' fullname='Roy T. Fielding'> 3289 <organization abbrev="Day Software">Day Software</organization> 3290 <address> 3291 <email>fielding@gbiv.com</email> 3292 <uri>http://roy.gbiv.com/</uri> 3293 </address> 3294 </author> 3295 <author initials='L.' surname='Masinter' fullname='Larry Masinter'> 3296 <organization abbrev="Adobe Systems">Adobe Systems Incorporated</organization> 3297 <address> 3298 <email>LMM@acm.org</email> 3299 <uri>http://larry.masinter.net/</uri> 3300 </address> 3301 </author> 3302 <date month='January' year='2005'></date> 3303 </front> 3304 <seriesInfo name="RFC" value="3986"/> 3305 <seriesInfo name="STD" value="66"/> 3325 3306 </reference> 3326 3307 … … 3462 3443 </reference> 3463 3444 3464 <reference anchor="RFC1630">3465 <front>3466 <title abbrev="URIs in WWW">Universal Resource Identifiers in WWW: A Unifying Syntax for the Expression of Names and Addresses of Objects on the Network as used in the World-Wide Web</title>3467 <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee">3468 <organization>CERN, World-Wide Web project</organization>3469 <address><email>timbl@info.cern.ch</email></address>3470 </author>3471 <date month="June" year="1994"/>3472 </front>3473 <seriesInfo name="RFC" value="1630"/>3474 </reference>3475 3476 <reference anchor="RFC1737">3477 <front>3478 <title abbrev="Requirements for Uniform Resource Names">Functional Requirements for Uniform Resource Names</title>3479 <author initials="L." surname="Masinter" fullname="Larry Masinter">3480 <organization>Xerox Palo Alto Research Center</organization>3481 <address><email>masinter@parc.xerox.com</email></address>3482 </author>3483 <author initials="K." surname="Sollins" fullname="Karen Sollins">3484 <organization>MIT Laboratory for Computer Science</organization>3485 <address><email>sollins@lcs.mit.edu</email></address>3486 </author>3487 <date month="December" year="1994"/>3488 </front>3489 <seriesInfo name="RFC" value="1737"/>3490 </reference>3491 3492 <reference anchor="RFC1738">3493 <front>3494 <title>Uniform Resource Locators (URL)</title>3495 <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee">3496 <organization>CERN, World-Wide Web project</organization>3497 <address><email>timbl@info.cern.ch</email></address>3498 </author>3499 <author initials="L." surname="Masinter" fullname="Larry Masinter">3500 <organization>Xerox PARC</organization>3501 <address><email>masinter@parc.xerox.com</email></address>3502 </author>3503 <author initials="M." surname="McCahill" fullname="Mark McCahill">3504 <organization>University of Minnesota, Computer and Information Services</organization>3505 <address><email>mpm@boombox.micro.umn.edu</email></address>3506 </author>3507 <date month="December" year="1994"/>3508 </front>3509 <seriesInfo name="RFC" value="1738"/>3510 </reference>3511 3512 <reference anchor="RFC1808">3513 <front>3514 <title>Relative Uniform Resource Locators</title>3515 <author initials="R." surname="Fielding" fullname="Roy T. Fielding">3516 <organization>University of California Irvine, Department of Information and Computer Science</organization>3517 <address><email>fielding@ics.uci.edu</email></address>3518 </author>3519 <date month="June" year="1995"/>3520 </front>3521 <seriesInfo name="RFC" value="1808"/>3522 </reference>3523 3524 3445 <reference anchor="RFC1900"> 3525 3446 <front> … … 3626 3547 </reference> 3627 3548 3628 <reference anchor="RFC2324">3629 <front>3630 <title abbrev="HTCPCP/1.0">Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0)</title>3631 <author initials="L." surname="Masinter" fullname="Larry Masinter">3632 <organization>Xerox Palo Alto Research Center</organization>3633 <address><email>masinter@parc.xerox.com</email></address>3634 </author>3635 <date month="April" day="1" year="1998"/>3636 </front>3637 <seriesInfo name="RFC" value="2324"/>3638 </reference>3639 3640 3549 <reference anchor="RFC2616"> 3641 3550 <front> … … 3684 3593 </front> 3685 3594 <seriesInfo name='RFC' value='2818' /> 3686 </reference>3687 3688 <reference anchor="RFC2821">3689 <front>3690 <title>Simple Mail Transfer Protocol</title>3691 <author initials="J." surname="Klensin" fullname="J. Klensin">3692 <organization>AT&T Laboratories</organization>3693 <address><email>klensin@research.att.com</email></address>3694 </author>3695 <date year="2001" month="April"/>3696 </front>3697 <seriesInfo name="RFC" value="2821"/>3698 3595 </reference> 3699 3596 … … 3946 3843 <section title="Compatibility with Previous Versions" anchor="compatibility"> 3947 3844 <t> 3845 HTTP has been in use by the World-Wide Web global information initiative 3846 since 1990. The first version of HTTP, later referred to as HTTP/0.9, 3847 was a simple protocol for hypertext data transfer across the Internet 3848 with only a single method and no metadata. 3849 HTTP/1.0, as defined by <xref target="RFC1945"/>, added a range of request 3850 methods and MIME-like messaging that could include metadata about the data 3851 transferred and modifiers on the request/response semantics. However, 3852 HTTP/1.0 did not sufficiently take into consideration the effects of 3853 hierarchical proxies, caching, the need for persistent connections, or 3854 name-based virtual hosts. The proliferation of incompletely-implemented 3855 applications calling themselves "HTTP/1.0" further necessitated a 3856 protocol version change in order for two communicating applications 3857 to determine each other's true capabilities. 3858 </t> 3859 <t> 3860 HTTP/1.1 remains compatible with HTTP/1.0 by including more stringent 3861 requirements that enable reliable implementations, adding only 3862 those new features that will either be safely ignored by an HTTP/1.0 3863 recipient or only sent when communicating with a party advertising 3864 compliance with HTTP/1.1. 3865 </t> 3866 <t> 3948 3867 It is beyond the scope of a protocol specification to mandate 3949 3868 compliance with previous versions. HTTP/1.1 was deliberately … … 4115 4034 </t> 4116 4035 <t> 4117 Fix BNF to add query, as the abs_path production in4118 <xref x:sec="3" x:fmt="of" target="RFC2396"/> doesn't define it.4036 Update use of abs_path production from RFC1808 to the path-absolute + query 4037 components of RFC3986. 4119 4038 (<xref target="request-uri"/>) 4120 4039 </t> … … 4524 4443 Add rules for terms imported from URI spec ("absoluteURI", "authority", 4525 4444 "path-absolute", "port", "query", "relativeURI", "host) -- these will 4526 have to be updated when switching over to RFC3986. 4445 have to be updated when switching over to RFC3986. 4527 4446 </t> 4528 4447 <t> … … 4631 4550 <list style="symbols"> 4632 4551 <t> 4552 <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/34"/>: 4553 "Out-of-date reference for URIs" 4554 </t> 4555 <t> 4633 4556 <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/132"/>: 4634 4557 "RFC 2822 is updated by RFC 5322"
Note: See TracChangeset
for help on using the changeset viewer.