Ignore:
Timestamp:
13/11/08 21:26:18 (13 years ago)
Author:
fielding@…
Message:

change tactics -- define HTTP architecture instead of when to use HTTP

File:
1 edited

Legend:

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

    r361 r373  
    365365      <link rel="Index" href="#rfc.index">
    366366      <link rel="Chapter" title="1 Introduction" href="#rfc.section.1">
    367       <link rel="Chapter" title="2 When to use HTTP" href="#rfc.section.2">
     367      <link rel="Chapter" title="2 HTTP architecture" href="#rfc.section.2">
    368368      <link rel="Chapter" title="3 Protocol Parameters" href="#rfc.section.3">
    369369      <link rel="Chapter" title="4 HTTP Message" href="#rfc.section.4">
     
    477477         <tr>
    478478            <td class="header left"></td>
    479             <td class="header right">November 12, 2008</td>
     479            <td class="header right">November 13, 2008</td>
    480480         </tr>
    481481      </table>
     
    529529            </ul>
    530530         </li>
    531          <li class="tocline0">2.&nbsp;&nbsp;&nbsp;<a href="#when">When to use HTTP</a><ul class="toc">
     531         <li class="tocline0">2.&nbsp;&nbsp;&nbsp;<a href="#architecture">HTTP architecture</a><ul class="toc">
    532532               <li class="tocline1">2.1&nbsp;&nbsp;&nbsp;<a href="#uri">Uniform Resource Identifiers</a><ul class="toc">
    533533                     <li class="tocline1">2.1.1&nbsp;&nbsp;&nbsp;<a href="#http.uri">http URI scheme</a></li>
     
    669669      <h1 id="rfc.section.1" class="np"><a href="#rfc.section.1">1.</a>&nbsp;<a id="introduction" href="#introduction">Introduction</a></h1>
    670670      <p id="rfc.section.1.p.1">The Hypertext Transfer Protocol (HTTP) is an application-level request/response protocol that uses extensible semantics and
    671          MIME-like message payloads for flexible interaction with network-based hypermedia information systems. HTTP relies upon the
    672          Uniform Resource Identifier (URI) standard <a href="#RFC3986" id="rfc.xref.RFC3986.1"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a> to indicate resource targets for interaction and to identify other resources. Messages are passed in a format similar to that
    673          used by Internet mail <a href="#RFC5322" id="rfc.xref.RFC5322.1"><cite title="Internet Message Format">[RFC5322]</cite></a> and the Multipurpose Internet Mail Extensions (MIME) <a href="#RFC2045" id="rfc.xref.RFC2045.1"><cite title="Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies">[RFC2045]</cite></a> (see <a href="p3-payload.html#differences.between.http.entities.and.rfc.2045.entities" title="Differences Between HTTP Entities and RFC 2045 Entities">Appendix A</a> of <a href="#Part3" id="rfc.xref.Part3.1"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a> for the differences between HTTP and MIME messages).
    674       </p>
    675       <p id="rfc.section.1.p.2">HTTP is also designed for use as a generic protocol for translating communication to and from other Internet information systems,
     671         MIME-like message payloads for flexible interaction with network-based hypertext information systems. HTTP relies upon the
     672         Uniform Resource Identifier (URI) standard <a href="#RFC3986" id="rfc.xref.RFC3986.1"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a> to indicate resource targets and relationships between resources. Messages are passed in a format similar to that used by
     673         Internet mail <a href="#RFC5322" id="rfc.xref.RFC5322.1"><cite title="Internet Message Format">[RFC5322]</cite></a> and the Multipurpose Internet Mail Extensions (MIME) <a href="#RFC2045" id="rfc.xref.RFC2045.1"><cite title="Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies">[RFC2045]</cite></a> (see <a href="p3-payload.html#differences.between.http.entities.and.rfc.2045.entities" title="Differences Between HTTP Entities and RFC 2045 Entities">Appendix A</a> of <a href="#Part3" id="rfc.xref.Part3.1"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a> for the differences between HTTP and MIME messages).
     674      </p>
     675      <p id="rfc.section.1.p.2">HTTP is a generic interface protocol for informations systems. It is designed to hide the details of how a service is implemented
     676         by presenting a uniform interface to clients that is independent of the types of resources provided. Likewise, servers do
     677         not need to be aware of each client's purpose: an HTTP request can be considered in isolation rather than being associated
     678         with a specific type of client or a predetermined sequence of application steps. The result is a protocol that can be used
     679         effectively in many different contexts and for which implementations can evolve independently over time.
     680      </p>
     681      <p id="rfc.section.1.p.3">HTTP is also designed for use as a generic protocol for translating communication to and from other Internet information systems,
    676682         such as USENET news services via NNTP <a href="#RFC3977" id="rfc.xref.RFC3977.1"><cite title="Network News Transfer Protocol (NNTP)">[RFC3977]</cite></a>, file services via FTP <a href="#RFC959" id="rfc.xref.RFC959.1"><cite title="File Transfer Protocol">[RFC959]</cite></a>, Gopher <a href="#RFC1436" id="rfc.xref.RFC1436.1"><cite title="The Internet Gopher Protocol (a distributed document search and retrieval protocol)">[RFC1436]</cite></a>, and WAIS <a href="#WAIS" id="rfc.xref.WAIS.1"><cite title="WAIS Interface Protocol Prototype Functional Specification (v1.5)">[WAIS]</cite></a>. HTTP proxies and gateways provide access to alternative information services by translating their diverse protocols into
    677683         a hypermedia format that can be viewed and manipulated by clients in the same way as HTTP services.
    678684      </p>
    679       <p id="rfc.section.1.p.3">This document is Part 1 of the seven-part specification of HTTP, defining the protocol referred to as "HTTP/1.1" and obsoleting <a href="#RFC2616" id="rfc.xref.RFC2616.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>. Part 1 defines how clients determine when to use HTTP, the URI schemes specific to HTTP-based resources, overall network
    680          operation with transport protocol connection management, and HTTP message framing. Our goal is to define all of the mechanisms
    681          necessary for HTTP message handling that are independent of message semantics, thereby defining the complete set of requirements
    682          for an HTTP message relay or generic message parser.
     685      <p id="rfc.section.1.p.4">One consequence of HTTP flexibility is that we cannot define the protocol in terms of how to implement it behind the interface.
     686         Instead, we are limited to restricting the syntax of communication, defining the intent of received communication, and the
     687         expected behavior of recipients. If the communication is considered in isolation, then successful actions should be reflected
     688         in the observable interface provided by servers. However, since many clients are potentially acting in parallel and perhaps
     689         at cross-purposes, it would be meaningless to require that such behavior be observable.
     690      </p>
     691      <p id="rfc.section.1.p.5">This document is Part 1 of the seven-part specification of HTTP, defining the protocol referred to as "HTTP/1.1" and obsoleting <a href="#RFC2616" id="rfc.xref.RFC2616.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>. Part 1 defines the URI schemes specific to HTTP-based resources, overall network operation, transport protocol connection
     692         management, and HTTP message framing and forwarding requirements. Our goal is to define all of the mechanisms necessary for
     693         HTTP message handling that are independent of message semantics, thereby defining the complete set of requirements for a message
     694         parser and transparent message-forwarding intermediaries.
    683695      </p>
    684696      <h2 id="rfc.section.1.1"><a href="#rfc.section.1.1">1.1</a>&nbsp;<a id="intro.requirements" href="#intro.requirements">Requirements</a></h2>
     
    797809  <a href="#abnf.dependencies" class="smpl">Pragma</a>          = &lt;Pragma, defined in <a href="#Part6" id="rfc.xref.Part6.2"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>, <a href="p6-cache.html#header.pragma" title="Pragma">Section 16.4</a>&gt;
    798810  <a href="#abnf.dependencies" class="smpl">Warning</a>         = &lt;Warning, defined in <a href="#Part6" id="rfc.xref.Part6.3"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>, <a href="p6-cache.html#header.warning" title="Warning">Section 16.6</a>&gt;
    799 </pre><h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a>&nbsp;<a id="when" href="#when">When to use HTTP</a></h1>
    800       <p id="rfc.section.2.p.1">HTTP is a generic interface protocol for informations systems. It is designed to hide the details of how a service is implemented
    801          by presenting a uniform interface to clients that is independent of the types of resources provided. Likewise, servers do
    802          not need to be aware of the client's purpose: each HTTP request can be considered independently rather than being associated
    803          with a specific type of client or a predetermined sequence of application steps. The result is a protocol that can be used
    804          effectively in many different contexts and for which implementations can evolve independently over time.
    805       </p>
    806       <p id="rfc.section.2.p.2">One consequence of HTTP flexibility is that we cannot define the protocol in terms of how to implement it behind the interface.
    807          Instead, we are limited to restricting the syntax of communication, defining the intent of received communication, and the
    808          expected behavior of recipients. If the communication is considered in isolation, then successful actions should be reflected
    809          in the observable interface provided by servers. However, since many clients are potentially acting in parallel and perhaps
    810          at cross-purposes, it would be meaningless to require that such behavior be observable.
    811       </p>
    812       <p id="rfc.section.2.p.3">This section describes the most common contexts in which a user agent is encouraged or instructed to use HTTP for communication
    813          and how such contexts differ in terms of their resulting communication.
     811</pre><h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a>&nbsp;<a id="architecture" href="#architecture">HTTP architecture</a></h1>
     812      <p id="rfc.section.2.p.1">Nevertheless, HTTP was created with a specific architecture in mind, the World Wide Web, and has evolved over time to support
     813         the scalability needs of a worldwide hypertext system. Much of that architecture is reflected in the terminology used to define
     814         HTTP. This section describes the larger architecture surrounding expected usage of HTTP that is used by this specification
     815         to define HTTP.
    814816      </p>
    815817      <h2 id="rfc.section.2.1"><a href="#rfc.section.2.1">2.1</a>&nbsp;<a id="uri" href="#uri">Uniform Resource Identifiers</a></h2>
Note: See TracChangeset for help on using the changeset viewer.