Changeset 341 for draft-ietf-httpbis


Ignore:
Timestamp:
Nov 10, 2008, 5:09:55 PM (11 years ago)
Author:
fielding@…
Message:

Rewrite intro. Update URIs to RFC3986

File:
1 edited

Legend:

Unmodified
Added
Removed

  • draft-ietf-httpbis/latest-roy/p1-messaging.xml

    r340 r341  
    229229<t>
    230230   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>
    290264
    291265<section title="Requirements" anchor="intro.requirements">
    … …  
    544518<section title="Uniform Resource Identifiers" anchor="uri">
    545519<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"/>
    556531  <x:anchor-alias value="authority"/>
    557532  <x:anchor-alias value="fragment"/>
     533  <x:anchor-alias value="path-abempty"/>
    558534  <x:anchor-alias value="path-absolute"/>
    559535  <x:anchor-alias value="port"/>
    560536  <x:anchor-alias value="query"/>
    561   <x:anchor-alias value="relativeURI"/>
    562537  <x:anchor-alias value="uri-host"/>
    563538<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>   = &lt;absoluteURI, defined in <xref target="RFC2396" x:fmt="," x:sec="3"/>>
    576   <x:ref>authority</x:ref>     = &lt;authority, defined in <xref target="RFC2396" x:fmt="," x:sec="3.2"/>>
    577   <x:ref>fragment</x:ref>      = &lt;fragment, defined in <xref target="RFC2396" x:fmt="," x:sec="4.1"/>>
    578   <x:ref>path-absolute</x:ref> = &lt;abs_path, defined in <xref target="RFC2396" x:fmt="," x:sec="3"/>>
    579   <x:ref>port</x:ref>          = &lt;port, defined in <xref target="RFC2396" x:fmt="," x:sec="3.2.2"/>>
    580   <x:ref>query</x:ref>         = &lt;query, defined in <xref target="RFC2396" x:fmt="," x:sec="3.4"/>>
    581   <x:ref>relativeURI</x:ref>   = &lt;relativeURI, defined in <xref target="RFC2396" x:fmt="," x:sec="5"/>>
    582   <x:ref>uri-host</x:ref>      = &lt;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>   = &lt;absolute-URI, defined in <xref target="RFC3986" x:fmt="," x:sec="4.3"/>>
     544  <x:ref>authority</x:ref>     = &lt;authority, defined in <xref target="RFC3986" x:fmt="," x:sec="3.2"/>>
     545  <x:ref>fragment</x:ref>      = &lt;fragment, defined in <xref target="RFC3986" x:fmt="," x:sec="3.5"/>>
     546  <x:ref>path-abempty</x:ref>  = &lt;path-abempty, defined in <xref target="RFC3986" x:fmt="," x:sec="3.3"/>>
     547  <x:ref>path-absolute</x:ref> = &lt;path-absolute, defined in <xref target="RFC3986" x:fmt="," x:sec="3.3"/>>
     548  <x:ref>port</x:ref>          = &lt;port, defined in <xref target="RFC3986" x:fmt="," x:sec="3.2.3"/>>
     549  <x:ref>query</x:ref>         = &lt;query, defined in <xref target="RFC3986" x:fmt="," x:sec="3.4"/>>
     550  <x:ref>uri-host</x:ref>      = &lt;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
    586554   a URI. Servers &MUST; be able to handle the URI of any resource they
    587555   serve, and &SHOULD; be able to handle URIs of unbounded length if they
    … …  
    599567  </list>
    600568</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"/>
    605572  <iref item="http URI scheme" primary="true"/>
    606573  <iref item="URI scheme" subitem="http" primary="true"/>
    607574<t>
    608575   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> ]
    615581</artwork></figure>
    616582<t>
    … …  
    649615<t>
    650616   Characters other than those in the "reserved" set (see
    651    <xref target="RFC2396" x:fmt="," x:sec="2.2"/>) are equivalent to their
     617   <xref target="RFC3986" x:fmt="," x:sec="2.2"/>) are equivalent to their
    652618   ""%" <x:ref>HEXDIG</x:ref> <x:ref>HEXDIG</x:ref>" encoding.
    653619</t>
    … …  
    672638   including the message's protocol version and a success or error code,
    673639   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.
    676641</t>
    677642<t>
    … …  
    14811446<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Request-URI"/>
    14821447  <x:ref>Request-URI</x:ref>    = "*"
    1483                  / <x:ref>absoluteURI</x:ref>
     1448                 / <x:ref>absolute-URI</x:ref>
    14841449                 / ( <x:ref>path-absolute</x:ref> [ "?" <x:ref>query</x:ref> ] )
    14851450                 / <x:ref>authority</x:ref>
    … …  
    14961461</artwork></figure>
    14971462<t>
    1498    The absoluteURI form is &REQUIRED; when the request is being made to a
     1463   The absolute-URI form is &REQUIRED; when the request is being made to a
    14991464   proxy. The proxy is requested to forward the request or service it
    15001465   from a valid cache, and return the response. Note that the proxy &MAY;
    15011466   forward the request on to another proxy or directly to the server
    1502    specified by the absoluteURI. In order to avoid request loops, a
     1467   specified by the absolute-URI. In order to avoid request loops, a
    15031468   proxy &MUST; be able to recognize all of its server names, including
    15041469   any aliases, local variations, and the numeric IP address. An example
    … …  
    15091474</artwork></figure>
    15101475<t>
    1511    To allow for transition to absoluteURIs in all requests in future
    1512    versions of HTTP, all HTTP/1.1 servers &MUST; accept the absoluteURI
     1476   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
    15131478   form in requests, even though HTTP/1.1 clients will only generate
    15141479   them in requests to proxies.
    … …  
    15201485   The most common form of Request-URI is that used to identify a
    15211486   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) as
     1487   path of the URI &MUST; be transmitted (see <xref target="http.uri"/>, path-absolute) as
    15231488   the Request-URI, and the network location of the URI (authority) &MUST;
    15241489   be transmitted in a Host header field. For example, a client wishing
    … …  
    15381503<t>
    15391504   The Request-URI is transmitted in the format specified in
    1540    <xref target="general.syntax"/>. If the Request-URI is encoded using the
     1505   <xref target="http.uri"/>. If the Request-URI is encoded using the
    15411506   "% <x:ref>HEXDIG</x:ref> <x:ref>HEXDIG</x:ref>" encoding
    1542    (<xref target="RFC2396" x:fmt="," x:sec="2.4.1"/>), the origin server
     1507   (<xref target="RFC3986" x:fmt="," x:sec="2.4"/>), the origin server
    15431508   &MUST; decode the Request-URI in order to
    15441509   properly interpret the request. Servers &SHOULD; respond to invalid
    … …  
    15801545   resource on an HTTP/1.1 request:
    15811546  <list style="numbers">
    1582     <t>If Request-URI is an absoluteURI, the host is part of the
     1547    <t>If Request-URI is an absolute-URI, the host is part of the
    15831548     Request-URI. Any Host header field value in the request &MUST; be
    15841549     ignored.</t>
    1585     <t>If the Request-URI is not an absoluteURI, and the request includes
     1550    <t>If the Request-URI is not an absolute-URI, and the request includes
    15861551     a Host header field, the host is determined by the Host header
    15871552     field value.</t>
    … …  
    22702235   The Host request-header field specifies the Internet host and port
    22712236   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.url"/>). The Host field value &MUST; represent
     2237   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
    22742239   the naming authority of the origin server or gateway given by the
    22752240   original URL. This allows the origin server or gateway to
    … …  
    22782243</t>
    22792244<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.url"/>
     2245  <x:ref>Host</x:ref> = "Host" ":" <x:ref>uri-host</x:ref> [ ":" <x:ref>port</x:ref> ] ; <xref target="http.uri"/>
    22812246</artwork></figure>
    22822247<t>
    … …  
    26912656   The entry for the "http" URI Scheme in the registry located at
    26922657   <eref target="http://www.iana.org/assignments/uri-schemes.html"/>
    2693    should be updated to point to <xref target="http.url"/> of this document
     2658   should be updated to point to <xref target="http.uri"/> of this document
    26942659   (see <xref target="RFC4395"/>).
    26952660</t>
    … …  
    29902955<section title="Acknowledgments" anchor="ack">
    29912956<t>
    2992    This specification makes heavy use of the augmented BNF and generic
    2993    constructs defined by David H. Crocker for <xref target="RFC5234"/>. Similarly, it
    2994    reuses many of the definitions provided by Nathaniel Borenstein and
    2995    Ned Freed for MIME <xref target="RFC2045"/>. We hope that their inclusion in this
    2996    specification will help reduce past confusion over the relationship
    2997    between HTTP and Internet mail message formats.
    2998 </t>
    2999 <t>
    30002957   HTTP has evolved considerably over the years. It has
    30012958   benefited from a large and active developer community--the many
    … …  
    30453002   discovery of many of the problems that this document attempts to
    30463003   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.
    30473012</t>
    30483013</section>
    … …  
    33193284</reference>
    33203285
    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"/>
    33393314</reference>
    33403315
    … …  
    34763451</reference>
    34773452
    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 
    35383453<reference anchor="RFC1900">
    35393454  <front>
    … …  
    36403555</reference>
    36413556
    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 
    36543557<reference anchor="RFC2616">
    36553558  <front>
    … …  
    36983601  </front>
    36993602  <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&amp;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"/>
    37123603</reference>
    37133604
    … …  
    39603851<section title="Compatibility with Previous Versions" anchor="compatibility">
    39613852<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>
    39623875   It is beyond the scope of a protocol specification to mandate
    39633876   compliance with previous versions. HTTP/1.1 was deliberately
    … …  
    41264039</t>
    41274040<t>
    4128   Fix BNF to add query, as the abs_path production in
    4129   <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.
    41304043  (<xref target="request-uri"/>)
    41314044</t>
    … …  
    42814194    <t>
    42824195      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").
    42894201    </t>
    42904202    <t>
Note: See TracChangeset for help on using the changeset viewer.