Changeset 2557 for draft-ietf-httpbis


Ignore:
Timestamp:
18/01/14 05:06:05 (6 years ago)
Author:
fielding@…
Message:

(editorial) define WWW where World Wide Web first appears and remove redundant bits from the abstract and history; see #531 and [2555]

Location:
draft-ietf-httpbis/latest
Files:
2 edited

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpbis/latest/p1-messaging.html

    r2555 r2557  
    493493      <meta name="dct.replaces" content="urn:ietf:rfc:2145">
    494494      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    495       <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document provides an overview of HTTP architecture and its associated terminology, defines the &#34;http&#34; and &#34;https&#34; Uniform Resource Identifier (URI) schemes, defines the HTTP/1.1 message syntax and parsing requirements, and describes general security concerns for implementations.">
    496       <meta name="description" content="The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document provides an overview of HTTP architecture and its associated terminology, defines the &#34;http&#34; and &#34;https&#34; Uniform Resource Identifier (URI) schemes, defines the HTTP/1.1 message syntax and parsing requirements, and describes general security concerns for implementations.">
     495      <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document provides an overview of HTTP architecture and its associated terminology, defines the &#34;http&#34; and &#34;https&#34; Uniform Resource Identifier (URI) schemes, defines the HTTP/1.1 message syntax and parsing requirements, and describes related security concerns for implementations.">
     496      <meta name="description" content="The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document provides an overview of HTTP architecture and its associated terminology, defines the &#34;http&#34; and &#34;https&#34; Uniform Resource Identifier (URI) schemes, defines the HTTP/1.1 message syntax and parsing requirements, and describes related security concerns for implementations.">
    497497   </head>
    498498   <body onload="init();">
     
    530530      <h1 id="rfc.abstract"><a href="#rfc.abstract">Abstract</a></h1>
    531531      <p>The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext
    532          information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document provides
    533          an overview of HTTP architecture and its associated terminology, defines the "http" and "https" Uniform Resource Identifier
    534          (URI) schemes, defines the HTTP/1.1 message syntax and parsing requirements, and describes general security concerns for implementations.
     532         information systems. This document provides an overview of HTTP architecture and its associated terminology, defines the "http"
     533         and "https" Uniform Resource Identifier (URI) schemes, defines the HTTP/1.1 message syntax and parsing requirements, and describes
     534         related security concerns for implementations.
    535535      </p>
    536536      <h1 id="rfc.note.1"><a href="#rfc.note.1">Editorial Note (To be removed by RFC Editor)</a></h1>
     
    796796      <div id="architecture">
    797797         <h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a>&nbsp;<a href="#architecture">Architecture</a></h1>
    798          <p id="rfc.section.2.p.1">HTTP was created for the World Wide Web architecture and has evolved over time to support the scalability needs of a worldwide
    799             hypertext system. Much of that architecture is reflected in the terminology and syntax productions used to define HTTP.
     798         <p id="rfc.section.2.p.1">HTTP was created for the World Wide Web (WWW) architecture and has evolved over time to support the scalability needs of a
     799            worldwide hypertext system. Much of that architecture is reflected in the terminology and syntax productions used to define
     800            HTTP.
    800801         </p>
    801802         <div id="operation">
     
    31703171      <div id="compatibility">
    31713172         <h1 id="rfc.section.A" class="np"><a href="#rfc.section.A">A.</a>&nbsp;<a href="#compatibility">HTTP Version History</a></h1>
    3172          <p id="rfc.section.A.p.1">HTTP has been in use by the World-Wide Web (WWW) global information initiative since 1990. The first version of HTTP, later
    3173             referred to as HTTP/0.9, was a simple protocol for hypertext data transfer across the Internet with only a single request
    3174             method (GET) and no metadata. HTTP/1.0, as defined by <a href="#RFC1945" id="rfc.xref.RFC1945.3"><cite title="Hypertext Transfer Protocol -- HTTP/1.0">[RFC1945]</cite></a>, added a range of request methods and MIME-like messaging that could include metadata about the data transferred and modifiers
    3175             on the request/response semantics. However, HTTP/1.0 did not sufficiently take into consideration the effects of hierarchical
     3173         <p id="rfc.section.A.p.1">HTTP has been in use since 1990. The first version, later referred to as HTTP/0.9, was a simple protocol for hypertext data
     3174            transfer across the Internet, using only a single request method (GET) and no metadata. HTTP/1.0, as defined by <a href="#RFC1945" id="rfc.xref.RFC1945.3"><cite title="Hypertext Transfer Protocol -- HTTP/1.0">[RFC1945]</cite></a>, added a range of request methods and MIME-like messaging, allowing for metadata to be transferred and modifiers placed on
     3175            the request/response semantics. However, HTTP/1.0 did not sufficiently take into consideration the effects of hierarchical
    31763176            proxies, caching, the need for persistent connections, or name-based virtual hosts. The proliferation of incompletely-implemented
    31773177            applications calling themselves "HTTP/1.0" further necessitated a protocol version change in order for two communicating applications
     
    31793179         </p>
    31803180         <p id="rfc.section.A.p.2">HTTP/1.1 remains compatible with HTTP/1.0 by including more stringent requirements that enable reliable implementations, adding
    3181             only those new features that will either be safely ignored by an HTTP/1.0 recipient or only sent when communicating with a
    3182             party advertising conformance with HTTP/1.1.
     3181            only those features that can either be safely ignored by an HTTP/1.0 recipient or only sent when communicating with a party
     3182            advertising conformance with HTTP/1.1.
    31833183         </p>
    3184          <p id="rfc.section.A.p.3">It is beyond the scope of a protocol specification to mandate conformance with previous versions. HTTP/1.1 was deliberately
    3185             designed, however, to make supporting previous versions easy. We would expect a general-purpose HTTP/1.1 server to understand
    3186             any valid request in the format of HTTP/1.0 and respond appropriately with an HTTP/1.1 message that only uses features understood
    3187             (or safely ignored) by HTTP/1.0 clients. Likewise, we would expect an HTTP/1.1 client to understand any valid HTTP/1.0 response.
     3184         <p id="rfc.section.A.p.3">HTTP/1.1 has been designed to make supporting previous versions easy. A general-purpose HTTP/1.1 server ought to be able to
     3185            understand any valid request in the format of HTTP/1.0, responding appropriately with an HTTP/1.1 message that only uses features
     3186            understood (or safely ignored) by HTTP/1.0 clients. Likewise, an HTTP/1.1 client can be expected to understand any valid HTTP/1.0
     3187            response.
    31883188         </p>
    31893189         <p id="rfc.section.A.p.4">Since HTTP/0.9 did not support header fields in a request, there is no mechanism for it to support name-based virtual hosts
    31903190            (selection of resource by inspection of the <a href="#header.host" class="smpl">Host</a> header field). Any server that implements name-based virtual hosts ought to disable support for HTTP/0.9. Most requests that
    3191             appear to be HTTP/0.9 are, in fact, badly constructed HTTP/1.x requests wherein a buggy client failed to properly encode linear
    3192             whitespace found in a URI reference and placed in the request-target.
     3191            appear to be HTTP/0.9 are, in fact, badly constructed HTTP/1.x requests caused by a client failing to properly encode the
     3192            request-target.
    31933193         </p>
    31943194         <div id="changes.from.1.0">
  • draft-ietf-httpbis/latest/p1-messaging.xml

    r2555 r2557  
    113113<abstract>
    114114<t>
    115    The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for
    116    distributed, collaborative, hypertext information systems. HTTP has been in
    117    use by the World Wide Web global information initiative since 1990.
     115   The Hypertext Transfer Protocol (HTTP) is a stateless application-level
     116   protocol for distributed, collaborative, hypertext information systems.
    118117   This document provides an overview of HTTP architecture and its associated
    119118   terminology, defines the "http" and "https" Uniform Resource Identifier
    120    (URI) schemes, defines the HTTP/1.1 message syntax and parsing requirements,
    121    and describes general security concerns for implementations.
     119   (URI) schemes, defines the HTTP/1.1 message syntax and parsing
     120   requirements, and describes related security concerns for implementations.
    122121</t>   
    123122</abstract>
     
    144143<t>
    145144   The Hypertext Transfer Protocol (HTTP) is a stateless application-level
    146    request/response protocol that uses extensible semantics and self-descriptive
    147    message payloads for flexible interaction with network-based hypertext
    148    information systems. This document is the first in a series of documents
    149    that collectively form the HTTP/1.1 specification:
     145   request/response protocol that uses extensible semantics and
     146   self-descriptive message payloads for flexible interaction with
     147   network-based hypertext information systems. This document is the first in
     148   a series of documents that collectively form the HTTP/1.1 specification:
    150149   <list style="empty">
    151150    <t>RFC xxx1: Message Syntax and Routing</t>
     
    273272<section title="Architecture" anchor="architecture">
    274273<t>
    275    HTTP was created for the World Wide Web architecture
     274   HTTP was created for the World Wide Web (WWW) architecture
    276275   and has evolved over time to support the scalability needs of a worldwide
    277276   hypertext system. Much of that architecture is reflected in the terminology
     
    50305029<section title="HTTP Version History" anchor="compatibility">
    50315030<t>
    5032    HTTP has been in use by the World-Wide Web (WWW) global information initiative
    5033    since 1990. The first version of HTTP, later referred to as HTTP/0.9,
    5034    was a simple protocol for hypertext data transfer across the Internet
    5035    with only a single request method (GET) and no metadata.
     5031   HTTP has been in use since 1990. The first version, later referred to as
     5032   HTTP/0.9, was a simple protocol for hypertext data transfer across the
     5033   Internet, using only a single request method (GET) and no metadata.
    50365034   HTTP/1.0, as defined by <xref target="RFC1945"/>, added a range of request
    5037    methods and MIME-like messaging that could include metadata about the data
    5038    transferred and modifiers on the request/response semantics. However,
     5035   methods and MIME-like messaging, allowing for metadata to be transferred
     5036   and modifiers placed on the request/response semantics. However,
    50395037   HTTP/1.0 did not sufficiently take into consideration the effects of
    50405038   hierarchical proxies, caching, the need for persistent connections, or
     
    50475045   HTTP/1.1 remains compatible with HTTP/1.0 by including more stringent
    50485046   requirements that enable reliable implementations, adding only
    5049    those new features that will either be safely ignored by an HTTP/1.0
     5047   those features that can either be safely ignored by an HTTP/1.0
    50505048   recipient or only sent when communicating with a party advertising
    50515049   conformance with HTTP/1.1.
    50525050</t>
    50535051<t>
    5054    It is beyond the scope of a protocol specification to mandate
    5055    conformance with previous versions. HTTP/1.1 was deliberately
    5056    designed, however, to make supporting previous versions easy.
    5057    We would expect a general-purpose HTTP/1.1 server to understand
    5058    any valid request in the format of HTTP/1.0 and respond appropriately
    5059    with an HTTP/1.1 message that only uses features understood (or
    5060    safely ignored) by HTTP/1.0 clients.  Likewise, we would expect
    5061    an HTTP/1.1 client to understand any valid HTTP/1.0 response.
    5062 </t>
    5063 <t>
    5064    Since HTTP/0.9 did not support header fields in a request,
    5065    there is no mechanism for it to support name-based virtual
    5066    hosts (selection of resource by inspection of the <x:ref>Host</x:ref> header
    5067    field).  Any server that implements name-based virtual hosts
    5068    ought to disable support for HTTP/0.9.  Most requests that
    5069    appear to be HTTP/0.9 are, in fact, badly constructed HTTP/1.x
    5070    requests wherein a buggy client failed to properly encode
    5071    linear whitespace found in a URI reference and placed in
    5072    the request-target.
     5052   HTTP/1.1 has been designed to make supporting previous versions easy.
     5053   A general-purpose HTTP/1.1 server ought to be able to understand any valid
     5054   request in the format of HTTP/1.0, responding appropriately with an
     5055   HTTP/1.1 message that only uses features understood (or safely ignored) by
     5056   HTTP/1.0 clients. Likewise, an HTTP/1.1 client can be expected to
     5057   understand any valid HTTP/1.0 response.
     5058</t>
     5059<t>
     5060   Since HTTP/0.9 did not support header fields in a request, there is no
     5061   mechanism for it to support name-based virtual hosts (selection of resource
     5062   by inspection of the <x:ref>Host</x:ref> header field).
     5063   Any server that implements name-based virtual hosts ought to disable
     5064   support for HTTP/0.9. Most requests that appear to be HTTP/0.9 are, in
     5065   fact, badly constructed HTTP/1.x requests caused by a client failing to
     5066   properly encode the request-target.
    50735067</t>
    50745068
Note: See TracChangeset for help on using the changeset viewer.