Changeset 373
- Timestamp:
- 13/11/08 21:26:18 (14 years ago)
- Location:
- draft-ietf-httpbis/latest-roy
- Files:
-
- 2 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest-roy/p1-messaging.html
r361 r373 365 365 <link rel="Index" href="#rfc.index"> 366 366 <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"> 368 368 <link rel="Chapter" title="3 Protocol Parameters" href="#rfc.section.3"> 369 369 <link rel="Chapter" title="4 HTTP Message" href="#rfc.section.4"> … … 477 477 <tr> 478 478 <td class="header left"></td> 479 <td class="header right">November 1 2, 2008</td>479 <td class="header right">November 13, 2008</td> 480 480 </tr> 481 481 </table> … … 529 529 </ul> 530 530 </li> 531 <li class="tocline0">2. <a href="# when">When to use HTTP</a><ul class="toc">531 <li class="tocline0">2. <a href="#architecture">HTTP architecture</a><ul class="toc"> 532 532 <li class="tocline1">2.1 <a href="#uri">Uniform Resource Identifiers</a><ul class="toc"> 533 533 <li class="tocline1">2.1.1 <a href="#http.uri">http URI scheme</a></li> … … 669 669 <h1 id="rfc.section.1" class="np"><a href="#rfc.section.1">1.</a> <a id="introduction" href="#introduction">Introduction</a></h1> 670 670 <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, 676 682 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 677 683 a hypermedia format that can be viewed and manipulated by clients in the same way as HTTP services. 678 684 </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. 683 695 </p> 684 696 <h2 id="rfc.section.1.1"><a href="#rfc.section.1.1">1.1</a> <a id="intro.requirements" href="#intro.requirements">Requirements</a></h2> … … 797 809 <a href="#abnf.dependencies" class="smpl">Pragma</a> = <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>> 798 810 <a href="#abnf.dependencies" class="smpl">Warning</a> = <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>> 799 </pre><h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a> <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> <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. 814 816 </p> 815 817 <h2 id="rfc.section.2.1"><a href="#rfc.section.2.1">2.1</a> <a id="uri" href="#uri">Uniform Resource Identifiers</a></h2> -
draft-ietf-httpbis/latest-roy/p1-messaging.xml
r361 r373 230 230 The Hypertext Transfer Protocol (HTTP) is an application-level 231 231 request/response protocol that uses extensible semantics and MIME-like 232 message payloads for flexible interaction with network-based hyper media232 message payloads for flexible interaction with network-based hypertext 233 233 information systems. HTTP relies upon the Uniform Resource Identifier (URI) 234 standard <xref target="RFC3986"/> to indicate resource targets for235 interaction and to identify otherresources.234 standard <xref target="RFC3986"/> to indicate resource targets and 235 relationships between resources. 236 236 Messages are passed in a format similar to that used by Internet mail 237 237 <xref target="RFC5322"/> and the Multipurpose Internet Mail Extensions 238 238 (MIME) <xref target="RFC2045"/> (see &diff2045entity; for the differences 239 239 between HTTP and MIME messages). 240 </t> 241 <t> 242 HTTP is a generic interface protocol for informations systems. It is 243 designed to hide the details of how a service is implemented by presenting 244 a uniform interface to clients that is independent of the types of 245 resources provided. Likewise, servers do not need to be aware of each 246 client's purpose: an HTTP request can be considered in isolation rather 247 than being associated with a specific type of client or a predetermined 248 sequence of application steps. The result is a protocol that can be used 249 effectively in many different contexts and for which implementations can 250 evolve independently over time. 240 251 </t> 241 252 <t> … … 251 262 </t> 252 263 <t> 264 One consequence of HTTP flexibility is that we cannot define the protocol 265 in terms of how to implement it behind the interface. Instead, we are 266 limited to restricting the syntax of communication, defining the intent 267 of received communication, and the expected behavior of recipients. If 268 the communication is considered in isolation, then successful actions 269 should be reflected in the observable interface provided by servers. 270 However, since many clients are potentially acting in parallel and 271 perhaps at cross-purposes, it would be meaningless to require that such 272 behavior be observable. 273 </t> 274 <t> 253 275 This document is Part 1 of the seven-part specification of HTTP, 254 276 defining the protocol referred to as "HTTP/1.1" and obsoleting 255 277 <xref target="RFC2616"/>. 256 Part 1 defines how clients determine when to use HTTP, the URI schemes257 specific to HTTP-based resources, overall network operation with258 transport protocol connection management, and HTTP message framing.278 Part 1 defines the URI schemes specific to HTTP-based resources, overall 279 network operation, transport protocol connection management, and HTTP 280 message framing and forwarding requirements. 259 281 Our goal is to define all of the mechanisms necessary for HTTP message 260 282 handling that are independent of message semantics, thereby defining the 261 complete set of requirements for a n HTTP message relay or generic262 message parser.283 complete set of requirements for a message parser and transparent 284 message-forwarding intermediaries. 263 285 </t> 264 286 … … 493 515 </section> 494 516 495 <section title="When to use HTTP" anchor="when"> 496 <t> 497 HTTP is a generic interface protocol for informations systems. It is 498 designed to hide the details of how a service is implemented by presenting 499 a uniform interface to clients that is independent of the types of 500 resources provided. Likewise, servers do not need to be aware of the 501 client's purpose: each HTTP request can be considered independently rather 502 than being associated with a specific type of client or a predetermined 503 sequence of application steps. The result is a protocol that can be used 504 effectively in many different contexts and for which implementations can 505 evolve independently over time. 506 </t> 507 <t> 508 One consequence of HTTP flexibility is that we cannot define the protocol 509 in terms of how to implement it behind the interface. Instead, we are 510 limited to restricting the syntax of communication, defining the intent 511 of received communication, and the expected behavior of recipients. If 512 the communication is considered in isolation, then successful actions 513 should be reflected in the observable interface provided by servers. 514 However, since many clients are potentially acting in parallel and 515 perhaps at cross-purposes, it would be meaningless to require that such 516 behavior be observable. 517 </t> 518 <t> 519 This section describes the most common contexts in which a user agent is 520 encouraged or instructed to use HTTP for communication and how such 521 contexts differ in terms of their resulting communication. 517 <section title="HTTP architecture" anchor="architecture"> 518 <t> 519 Nevertheless, HTTP was created with a specific architecture in mind, the 520 World Wide Web, and has evolved over time to support the scalability needs 521 of a worldwide hypertext system. Much of that architecture is reflected in 522 the terminology used to define HTTP. This section describes the larger 523 architecture surrounding expected usage of HTTP that is used by this 524 specification to define HTTP. 522 525 </t> 523 526
Note: See TracChangeset
for help on using the changeset viewer.