Changeset 341 for draft-ietf-httpbis
- Timestamp:
- 11/11/08 01:09:55 (14 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest-roy/p1-messaging.xml
r340 r341 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"> … … 544 518 <section title="Uniform Resource Identifiers" anchor="uri"> 545 519 <t> 546 URIs have been known by many names: WWW addresses, Universal Document 547 Identifiers, Universal Resource Identifiers <xref target="RFC1630"/>, and finally the 548 combination of Uniform Resource Locators (URL) <xref target="RFC1738"/> and Names (URN) 549 <xref target="RFC1737"/>. As far as HTTP is concerned, Uniform Resource Identifiers are 550 simply formatted strings which identify--via name, location, or any 551 other characteristic--a resource. 552 </t> 553 554 <section title="General Syntax" anchor="general.syntax"> 555 <x:anchor-alias value="absoluteURI"/> 520 Uniform Resource Identifiers (URIs) <xref target="RFC3986"/> are used in HTTP 521 to indicate the target of a request and to identify additional resources related 522 to that resource, the request, or the response. Each protocol element in HTTP 523 that allows a URI reference will indicate in its ABNF whether the element allows 524 only a URI in absolute form, any relative reference, or some limited subset of 525 the URI-reference grammar. Unless otherwise indicated, relative URI references 526 are to be parsed relative to the URI corresponding to the request target 527 (the base URI). 528 </t> 529 <x:anchor-alias value="URI-reference"/> 530 <x:anchor-alias value="absolute-URI"/> 556 531 <x:anchor-alias value="authority"/> 557 532 <x:anchor-alias value="fragment"/> 533 <x:anchor-alias value="path-abempty"/> 558 534 <x:anchor-alias value="path-absolute"/> 559 535 <x:anchor-alias value="port"/> 560 536 <x:anchor-alias value="query"/> 561 <x:anchor-alias value="relativeURI"/>562 537 <x:anchor-alias value="uri-host"/> 563 538 <t> 564 URIs in HTTP can be represented in absolute form or relative to some 565 known base URI <xref target="RFC1808"/>, depending upon the context of their use. The two 566 forms are differentiated by the fact that absolute URIs always begin 567 with a scheme name followed by a colon. For definitive information on 568 URL syntax and semantics, see "Uniform Resource Identifiers (URI): 569 Generic Syntax and Semantics," <xref target="RFC2396"/> (which replaces <xref target="RFC1738"/> 570 and <xref target="RFC1808"/>). This specification adopts the 571 definitions of "URI-reference", "absoluteURI", "fragment", "relativeURI", "port", 572 "host", "abs_path", "query", and "authority" from that specification: 573 </t> 574 <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"/> 575 <x:ref>absoluteURI</x:ref> = <absoluteURI, defined in <xref target="RFC2396" x:fmt="," x:sec="3"/>> 576 <x:ref>authority</x:ref> = <authority, defined in <xref target="RFC2396" x:fmt="," x:sec="3.2"/>> 577 <x:ref>fragment</x:ref> = <fragment, defined in <xref target="RFC2396" x:fmt="," x:sec="4.1"/>> 578 <x:ref>path-absolute</x:ref> = <abs_path, defined in <xref target="RFC2396" x:fmt="," x:sec="3"/>> 579 <x:ref>port</x:ref> = <port, defined in <xref target="RFC2396" x:fmt="," x:sec="3.2.2"/>> 580 <x:ref>query</x:ref> = <query, defined in <xref target="RFC2396" x:fmt="," x:sec="3.4"/>> 581 <x:ref>relativeURI</x:ref> = <relativeURI, defined in <xref target="RFC2396" x:fmt="," x:sec="5"/>> 582 <x:ref>uri-host</x:ref> = <host, defined in <xref target="RFC2396" x:fmt="," x:sec="3.2.2"/>> 583 </artwork></figure> 584 <t> 585 HTTP does not place any a priori limit on the length of 539 This specification adopts the definitions of "URI-reference", "absolute-URI", "fragment", "port", 540 "host", "path-abempty", "path-absolute", "query", and "authority" from <xref target="RFC3986"/>: 541 </t> 542 <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"/> 543 <x:ref>absolute-URI</x:ref> = <absolute-URI, defined in <xref target="RFC3986" x:fmt="," x:sec="4.3"/>> 544 <x:ref>authority</x:ref> = <authority, defined in <xref target="RFC3986" x:fmt="," x:sec="3.2"/>> 545 <x:ref>fragment</x:ref> = <fragment, defined in <xref target="RFC3986" x:fmt="," x:sec="3.5"/>> 546 <x:ref>path-abempty</x:ref> = <path-abempty, defined in <xref target="RFC3986" x:fmt="," x:sec="3.3"/>> 547 <x:ref>path-absolute</x:ref> = <path-absolute, defined in <xref target="RFC3986" x:fmt="," x:sec="3.3"/>> 548 <x:ref>port</x:ref> = <port, defined in <xref target="RFC3986" x:fmt="," x:sec="3.2.3"/>> 549 <x:ref>query</x:ref> = <query, defined in <xref target="RFC3986" x:fmt="," x:sec="3.4"/>> 550 <x:ref>uri-host</x:ref> = <host, defined in <xref target="RFC3986" x:fmt="," x:sec="3.2.2"/>> 551 </artwork></figure> 552 <t> 553 HTTP does not place an a priori limit on the length of 586 554 a URI. Servers &MUST; be able to handle the URI of any resource they 587 555 serve, and &SHOULD; be able to handle URIs of unbounded length if they … … 599 567 </list> 600 568 </t> 601 </section> 602 603 <section title="http URL" anchor="http.url"> 604 <x:anchor-alias value="http-URL"/> 569 570 <section title="http URI scheme" anchor="http.uri"> 571 <x:anchor-alias value="http-URI"/> 605 572 <iref item="http URI scheme" primary="true"/> 606 573 <iref item="URI scheme" subitem="http" primary="true"/> 607 574 <t> 608 575 The "http" scheme is used to locate network resources via the HTTP 609 protocol. This section defines the scheme-specific syntax and 610 semantics for http URLs. 611 </t> 612 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="http-URL"/> 613 <x:ref>http-URL</x:ref> = "http:" "//" <x:ref>uri-host</x:ref> [ ":" <x:ref>port</x:ref> ] 614 [ <x:ref>path-absolute</x:ref> [ "?" <x:ref>query</x:ref> ]] 576 protocol. This section defines the syntax and semantics for identifiers 577 using the http or https URI schemes. 578 </t> 579 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="http-URI"/> 580 <x:ref>http-URI</x:ref> = "http:" "//" <x:ref>authority</x:ref> <x:ref>path-abempty</x:ref> [ "?" <x:ref>query</x:ref> ] 615 581 </artwork></figure> 616 582 <t> … … 649 615 <t> 650 616 Characters other than those in the "reserved" set (see 651 <xref target="RFC 2396" x:fmt="," x:sec="2.2"/>) are equivalent to their617 <xref target="RFC3986" x:fmt="," x:sec="2.2"/>) are equivalent to their 652 618 ""%" <x:ref>HEXDIG</x:ref> <x:ref>HEXDIG</x:ref>" encoding. 653 619 </t> … … 672 638 including the message's protocol version and a success or error code, 673 639 followed by a MIME-like message containing server information, entity 674 metainformation, and possible entity-body content. The relationship 675 between HTTP and MIME is described in &diff2045entity;. 640 metainformation, and possible entity-body content. 676 641 </t> 677 642 <t> … … 1481 1446 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Request-URI"/> 1482 1447 <x:ref>Request-URI</x:ref> = "*" 1483 / <x:ref>absolute URI</x:ref>1448 / <x:ref>absolute-URI</x:ref> 1484 1449 / ( <x:ref>path-absolute</x:ref> [ "?" <x:ref>query</x:ref> ] ) 1485 1450 / <x:ref>authority</x:ref> … … 1496 1461 </artwork></figure> 1497 1462 <t> 1498 The absolute URI form is &REQUIRED; when the request is being made to a1463 The absolute-URI form is &REQUIRED; when the request is being made to a 1499 1464 proxy. The proxy is requested to forward the request or service it 1500 1465 from a valid cache, and return the response. Note that the proxy &MAY; 1501 1466 forward the request on to another proxy or directly to the server 1502 specified by the absolute URI. In order to avoid request loops, a1467 specified by the absolute-URI. In order to avoid request loops, a 1503 1468 proxy &MUST; be able to recognize all of its server names, including 1504 1469 any aliases, local variations, and the numeric IP address. An example … … 1509 1474 </artwork></figure> 1510 1475 <t> 1511 To allow for transition to absolute URIs in all requests in future1512 versions of HTTP, all HTTP/1.1 servers &MUST; accept the absolute URI1476 To allow for transition to absolute-URIs in all requests in future 1477 versions of HTTP, all HTTP/1.1 servers &MUST; accept the absolute-URI 1513 1478 form in requests, even though HTTP/1.1 clients will only generate 1514 1479 them in requests to proxies. … … 1520 1485 The most common form of Request-URI is that used to identify a 1521 1486 resource on an origin server or gateway. In this case the absolute 1522 path of the URI &MUST; be transmitted (see <xref target=" general.syntax"/>, path-absolute) as1487 path of the URI &MUST; be transmitted (see <xref target="http.uri"/>, path-absolute) as 1523 1488 the Request-URI, and the network location of the URI (authority) &MUST; 1524 1489 be transmitted in a Host header field. For example, a client wishing … … 1538 1503 <t> 1539 1504 The Request-URI is transmitted in the format specified in 1540 <xref target=" general.syntax"/>. If the Request-URI is encoded using the1505 <xref target="http.uri"/>. If the Request-URI is encoded using the 1541 1506 "% <x:ref>HEXDIG</x:ref> <x:ref>HEXDIG</x:ref>" encoding 1542 (<xref target="RFC 2396" x:fmt="," x:sec="2.4.1"/>), the origin server1507 (<xref target="RFC3986" x:fmt="," x:sec="2.4"/>), the origin server 1543 1508 &MUST; decode the Request-URI in order to 1544 1509 properly interpret the request. Servers &SHOULD; respond to invalid … … 1580 1545 resource on an HTTP/1.1 request: 1581 1546 <list style="numbers"> 1582 <t>If Request-URI is an absolute URI, the host is part of the1547 <t>If Request-URI is an absolute-URI, the host is part of the 1583 1548 Request-URI. Any Host header field value in the request &MUST; be 1584 1549 ignored.</t> 1585 <t>If the Request-URI is not an absolute URI, and the request includes1550 <t>If the Request-URI is not an absolute-URI, and the request includes 1586 1551 a Host header field, the host is determined by the Host header 1587 1552 field value.</t> … … 2270 2235 The Host request-header field specifies the Internet host and port 2271 2236 number of the resource being requested, as obtained from the original 2272 URI given by the user or referring resource (generally an HTTP URL,2273 as described in <xref target="http.ur l"/>). The Host field value &MUST; represent2237 URI given by the user or referring resource (generally an http URI, 2238 as described in <xref target="http.uri"/>). The Host field value &MUST; represent 2274 2239 the naming authority of the origin server or gateway given by the 2275 2240 original URL. This allows the origin server or gateway to … … 2278 2243 </t> 2279 2244 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Host"/> 2280 <x:ref>Host</x:ref> = "Host" ":" <x:ref>uri-host</x:ref> [ ":" <x:ref>port</x:ref> ] ; <xref target="http.ur l"/>2245 <x:ref>Host</x:ref> = "Host" ":" <x:ref>uri-host</x:ref> [ ":" <x:ref>port</x:ref> ] ; <xref target="http.uri"/> 2281 2246 </artwork></figure> 2282 2247 <t> … … 2691 2656 The entry for the "http" URI Scheme in the registry located at 2692 2657 <eref target="http://www.iana.org/assignments/uri-schemes.html"/> 2693 should be updated to point to <xref target="http.ur l"/> of this document2658 should be updated to point to <xref target="http.uri"/> of this document 2694 2659 (see <xref target="RFC4395"/>). 2695 2660 </t> … … 2990 2955 <section title="Acknowledgments" anchor="ack"> 2991 2956 <t> 2992 This specification makes heavy use of the augmented BNF and generic2993 constructs defined by David H. Crocker for <xref target="RFC5234"/>. Similarly, it2994 reuses many of the definitions provided by Nathaniel Borenstein and2995 Ned Freed for MIME <xref target="RFC2045"/>. We hope that their inclusion in this2996 specification will help reduce past confusion over the relationship2997 between HTTP and Internet mail message formats.2998 </t>2999 <t>3000 2957 HTTP has evolved considerably over the years. It has 3001 2958 benefited from a large and active developer community--the many … … 3045 3002 discovery of many of the problems that this document attempts to 3046 3003 rectify. 3004 </t> 3005 <t> 3006 This specification makes heavy use of the augmented BNF and generic 3007 constructs defined by David H. Crocker for <xref target="RFC5234"/>. Similarly, it 3008 reuses many of the definitions provided by Nathaniel Borenstein and 3009 Ned Freed for MIME <xref target="RFC2045"/>. We hope that their inclusion in this 3010 specification will help reduce past confusion over the relationship 3011 between HTTP and Internet mail message formats. 3047 3012 </t> 3048 3013 </section> … … 3319 3284 </reference> 3320 3285 3321 <reference anchor="RFC2396"> 3322 <front> 3323 <title abbrev="URI Generic Syntax">Uniform Resource Identifiers (URI): Generic Syntax</title> 3324 <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee"> 3325 <organization abbrev="MIT/LCS">World Wide Web Consortium</organization> 3326 <address><email>timbl@w3.org</email></address> 3327 </author> 3328 <author initials="R.T." surname="Fielding" fullname="Roy T. Fielding"> 3329 <organization abbrev="U.C. Irvine">Department of Information and Computer Science</organization> 3330 <address><email>fielding@ics.uci.edu</email></address> 3331 </author> 3332 <author initials="L." surname="Masinter" fullname="Larry Masinter"> 3333 <organization abbrev="Xerox Corporation">Xerox PARC</organization> 3334 <address><email>masinter@parc.xerox.com</email></address> 3335 </author> 3336 <date month="August" year="1998"/> 3337 </front> 3338 <seriesInfo name="RFC" value="2396"/> 3286 <reference anchor="RFC3986"> 3287 <front> 3288 <title abbrev='URI Generic Syntax'>Uniform Resource Identifier (URI): Generic Syntax</title> 3289 <author initials='T.' surname='Berners-Lee' fullname='Tim Berners-Lee'> 3290 <organization abbrev="W3C/MIT">World Wide Web Consortium</organization> 3291 <address> 3292 <email>timbl@w3.org</email> 3293 <uri>http://www.w3.org/People/Berners-Lee/</uri> 3294 </address> 3295 </author> 3296 <author initials='R.' surname='Fielding' fullname='Roy T. Fielding'> 3297 <organization abbrev="Day Software">Day Software</organization> 3298 <address> 3299 <email>fielding@gbiv.com</email> 3300 <uri>http://roy.gbiv.com/</uri> 3301 </address> 3302 </author> 3303 <author initials='L.' surname='Masinter' fullname='Larry Masinter'> 3304 <organization abbrev="Adobe Systems">Adobe Systems Incorporated</organization> 3305 <address> 3306 <email>LMM@acm.org</email> 3307 <uri>http://larry.masinter.net/</uri> 3308 </address> 3309 </author> 3310 <date month='January' year='2005'></date> 3311 </front> 3312 <seriesInfo name="RFC" value="3986"/> 3313 <seriesInfo name="STD" value="66"/> 3339 3314 </reference> 3340 3315 … … 3476 3451 </reference> 3477 3452 3478 <reference anchor="RFC1630">3479 <front>3480 <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>3481 <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee">3482 <organization>CERN, World-Wide Web project</organization>3483 <address><email>timbl@info.cern.ch</email></address>3484 </author>3485 <date month="June" year="1994"/>3486 </front>3487 <seriesInfo name="RFC" value="1630"/>3488 </reference>3489 3490 <reference anchor="RFC1737">3491 <front>3492 <title abbrev="Requirements for Uniform Resource Names">Functional Requirements for Uniform Resource Names</title>3493 <author initials="L." surname="Masinter" fullname="Larry Masinter">3494 <organization>Xerox Palo Alto Research Center</organization>3495 <address><email>masinter@parc.xerox.com</email></address>3496 </author>3497 <author initials="K." surname="Sollins" fullname="Karen Sollins">3498 <organization>MIT Laboratory for Computer Science</organization>3499 <address><email>sollins@lcs.mit.edu</email></address>3500 </author>3501 <date month="December" year="1994"/>3502 </front>3503 <seriesInfo name="RFC" value="1737"/>3504 </reference>3505 3506 <reference anchor="RFC1738">3507 <front>3508 <title>Uniform Resource Locators (URL)</title>3509 <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee">3510 <organization>CERN, World-Wide Web project</organization>3511 <address><email>timbl@info.cern.ch</email></address>3512 </author>3513 <author initials="L." surname="Masinter" fullname="Larry Masinter">3514 <organization>Xerox PARC</organization>3515 <address><email>masinter@parc.xerox.com</email></address>3516 </author>3517 <author initials="M." surname="McCahill" fullname="Mark McCahill">3518 <organization>University of Minnesota, Computer and Information Services</organization>3519 <address><email>mpm@boombox.micro.umn.edu</email></address>3520 </author>3521 <date month="December" year="1994"/>3522 </front>3523 <seriesInfo name="RFC" value="1738"/>3524 </reference>3525 3526 <reference anchor="RFC1808">3527 <front>3528 <title>Relative Uniform Resource Locators</title>3529 <author initials="R." surname="Fielding" fullname="Roy T. Fielding">3530 <organization>University of California Irvine, Department of Information and Computer Science</organization>3531 <address><email>fielding@ics.uci.edu</email></address>3532 </author>3533 <date month="June" year="1995"/>3534 </front>3535 <seriesInfo name="RFC" value="1808"/>3536 </reference>3537 3538 3453 <reference anchor="RFC1900"> 3539 3454 <front> … … 3640 3555 </reference> 3641 3556 3642 <reference anchor="RFC2324">3643 <front>3644 <title abbrev="HTCPCP/1.0">Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0)</title>3645 <author initials="L." surname="Masinter" fullname="Larry Masinter">3646 <organization>Xerox Palo Alto Research Center</organization>3647 <address><email>masinter@parc.xerox.com</email></address>3648 </author>3649 <date month="April" day="1" year="1998"/>3650 </front>3651 <seriesInfo name="RFC" value="2324"/>3652 </reference>3653 3654 3557 <reference anchor="RFC2616"> 3655 3558 <front> … … 3698 3601 </front> 3699 3602 <seriesInfo name='RFC' value='2818' /> 3700 </reference>3701 3702 <reference anchor="RFC2821">3703 <front>3704 <title>Simple Mail Transfer Protocol</title>3705 <author initials="J." surname="Klensin" fullname="J. Klensin">3706 <organization>AT&T Laboratories</organization>3707 <address><email>klensin@research.att.com</email></address>3708 </author>3709 <date year="2001" month="April"/>3710 </front>3711 <seriesInfo name="RFC" value="2821"/>3712 3603 </reference> 3713 3604 … … 3960 3851 <section title="Compatibility with Previous Versions" anchor="compatibility"> 3961 3852 <t> 3853 HTTP has been in use by the World-Wide Web global information initiative 3854 since 1990. The first version of HTTP, later referred to as HTTP/0.9, 3855 was a simple protocol for hypertext data transfer across the Internet 3856 with only a single method and no metadata. 3857 HTTP/1.0, as defined by <xref target="RFC1945"/>, added a range of request 3858 methods and MIME-like messaging that could include metadata about the data 3859 transferred and modifiers on the request/response semantics. However, 3860 HTTP/1.0 did not sufficiently take into consideration the effects of 3861 hierarchical proxies, caching, the need for persistent connections, or 3862 name-based virtual hosts. The proliferation of incompletely-implemented 3863 applications calling themselves "HTTP/1.0" further necessitated a 3864 protocol version change in order for two communicating applications 3865 to determine each other's true capabilities. 3866 </t> 3867 <t> 3868 HTTP/1.1 remains compatible with HTTP/1.0 by including more stringent 3869 requirements that enable reliable implementations, adding only 3870 those new features that will either be safely ignored by an HTTP/1.0 3871 recipient or only sent when communicating with a party advertising 3872 compliance with HTTP/1.1. 3873 </t> 3874 <t> 3962 3875 It is beyond the scope of a protocol specification to mandate 3963 3876 compliance with previous versions. HTTP/1.1 was deliberately … … 4126 4039 </t> 4127 4040 <t> 4128 Fix BNF to add query, as the abs_path production in4129 <xref x:sec="3" x:fmt="of" target="RFC2396"/> doesn't define it.4041 Update use of abs_path production from RFC1808 to the path-absolute + query 4042 components of RFC3986. 4130 4043 (<xref target="request-uri"/>) 4131 4044 </t> … … 4281 4194 <t> 4282 4195 Avoid underscore character in rule names ("http_URL" -> 4283 "http-URL", "abs_path" -> "path-absolute"). 4284 </t> 4285 <t> 4286 Add rules for terms imported from URI spec ("absoluteURI", "authority", 4287 "path-absolute", "port", "query", "relativeURI", "host) -- these will 4288 have to be updated when switching over to RFC3986. 4196 "http-URI", "abs_path" -> "path-absolute"). 4197 </t> 4198 <t> 4199 Add rules for terms imported from URI spec ("absolute-URI", "authority", 4200 "path-abempty", "path-absolute", "uri-host", "port", "query"). 4289 4201 </t> 4290 4202 <t>
Note: See TracChangeset
for help on using the changeset viewer.