Changeset 624 for draft-ietf-httpbis
- Timestamp:
- 26/07/09 11:56:53 (13 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.xml
r623 r624 508 508 </t> 509 509 510 <section title="Overall Operation" anchor="intro.overall.operation"> 511 <t> 512 HTTP is a request/response protocol. A client sends a 513 request to the server in the form of a request method, URI, and 514 protocol version, followed by a MIME-like message containing request 515 modifiers, client information, and possible body content over a 516 connection with a server. The server responds with a status line, 517 including the message's protocol version and a success or error code, 518 followed by a MIME-like message containing server information, entity 519 metadata, and possible entity-body content. 520 </t> 521 <t> 522 Most HTTP communication is initiated by a user agent and consists of 523 a request to be applied to a resource via the HTTP interface provided 524 by some origin server. In the 525 simplest case, this may be accomplished via a single connection (v) 526 between the user agent (UA) and the origin server (O). 527 </t> 528 <figure><artwork type="drawing"> 529 request chain ------------------------> 530 UA -------------------v------------------- O 531 <----------------------- response chain 532 </artwork></figure> 533 <t> 534 A more complicated situation occurs when one or more intermediaries 535 are present in the request/response chain. There are three common 536 forms of intermediary: proxy, gateway, and tunnel. A proxy is a 537 forwarding agent, receiving requests for a URI in its absolute form, 538 rewriting all or part of the message, and forwarding the reformatted 539 request toward the server identified by the URI. A gateway is a 540 receiving agent, acting as a layer above some other server(s) and, if 541 necessary, translating the requests to the underlying server's 542 protocol. A tunnel acts as a relay point between two connections 543 without changing the messages; tunnels are used when the 544 communication needs to pass through an intermediary (such as a 545 firewall) even when the intermediary cannot understand the contents 546 of the messages. 547 </t> 548 <figure><artwork type="drawing"> 549 request chain --------------------------------------> 550 UA -----v----- A -----v----- B -----v----- C -----v----- O 551 <------------------------------------- response chain 552 </artwork></figure> 553 <t> 554 The figure above shows three intermediaries (A, B, and C) between the 555 user agent and origin server. A request or response message that 556 travels the whole chain will pass through four separate connections. 557 This distinction is important because some HTTP communication options 558 may apply only to the connection with the nearest, non-tunnel 559 neighbor, only to the end-points of the chain, or to all connections 560 along the chain. Although the diagram is linear, each participant may 561 be engaged in multiple, simultaneous communications. For example, B 562 may be receiving requests from many clients other than A, and/or 563 forwarding requests to servers other than C, at the same time that it 564 is handling A's request. 565 </t> 566 <t> 567 Any party to the communication which is not acting as a tunnel may 568 employ an internal cache for handling requests. The effect of a cache 569 is that the request/response chain is shortened if one of the 570 participants along the chain has a cached response applicable to that 571 request. The following illustrates the resulting chain if B has a 572 cached copy of an earlier response from O (via C) for a request which 573 has not been cached by UA or A. 574 </t> 575 <figure><artwork type="drawing"> 576 request chain ----------> 577 UA -----v----- A -----v----- B - - - - - - C - - - - - - O 578 <--------- response chain 579 </artwork></figure> 580 <t> 581 Not all responses are usefully cacheable, and some requests may 582 contain modifiers which place special requirements on cache behavior. 583 HTTP requirements for cache behavior and cacheable responses are 584 defined in &caching;. 585 </t> 586 <t> 587 In fact, there are a wide variety of architectures and configurations 588 of caches and proxies currently being experimented with or deployed 589 across the World Wide Web. These systems include national hierarchies 590 of proxy caches to save transoceanic bandwidth, systems that 591 broadcast or multicast cache entries, organizations that distribute 592 subsets of cached data via CD-ROM, and so on. HTTP systems are used 593 in corporate intranets over high-bandwidth links, and for access via 594 PDAs with low-power radio links and intermittent connectivity. The 595 goal of HTTP/1.1 is to support the wide diversity of configurations 596 already deployed while introducing protocol constructs that meet the 597 needs of those who build web applications that require high 598 reliability and, failing that, at least reliable indications of 599 failure. 600 </t> 601 <t> 602 HTTP communication usually takes place over TCP/IP connections. The 603 default port is TCP 80 (<eref target="http://www.iana.org/assignments/port-numbers"/>), but other ports can be used. This does 604 not preclude HTTP from being implemented on top of any other protocol 605 on the Internet, or on other networks. HTTP only presumes a reliable 606 transport; any protocol that provides such guarantees can be used; 607 the mapping of the HTTP/1.1 request and response structures onto the 608 transport data units of the protocol in question is outside the scope 609 of this specification. 610 </t> 611 <t> 612 In HTTP/1.0, most implementations used a new connection for each 613 request/response exchange. In HTTP/1.1, a connection may be used for 614 one or more request/response exchanges, although connections may be 615 closed for a variety of reasons (see <xref target="persistent.connections"/>). 616 </t> 617 </section> 618 510 619 <section title="Uniform Resource Identifiers" anchor="uri"> 511 620 <iref primary="true" item="resource"/> … … 701 810 </t> 702 811 </section> 703 </section>704 705 <section title="Overall Operation" anchor="intro.overall.operation">706 <t>707 HTTP is a request/response protocol. A client sends a708 request to the server in the form of a request method, URI, and709 protocol version, followed by a MIME-like message containing request710 modifiers, client information, and possible body content over a711 connection with a server. The server responds with a status line,712 including the message's protocol version and a success or error code,713 followed by a MIME-like message containing server information, entity714 metadata, and possible entity-body content.715 </t>716 <t>717 Most HTTP communication is initiated by a user agent and consists of718 a request to be applied to a resource via the HTTP interface provided719 by some origin server. In the720 simplest case, this may be accomplished via a single connection (v)721 between the user agent (UA) and the origin server (O).722 </t>723 <figure><artwork type="drawing">724 request chain ------------------------>725 UA -------------------v------------------- O726 <----------------------- response chain727 </artwork></figure>728 <t>729 A more complicated situation occurs when one or more intermediaries730 are present in the request/response chain. There are three common731 forms of intermediary: proxy, gateway, and tunnel. A proxy is a732 forwarding agent, receiving requests for a URI in its absolute form,733 rewriting all or part of the message, and forwarding the reformatted734 request toward the server identified by the URI. A gateway is a735 receiving agent, acting as a layer above some other server(s) and, if736 necessary, translating the requests to the underlying server's737 protocol. A tunnel acts as a relay point between two connections738 without changing the messages; tunnels are used when the739 communication needs to pass through an intermediary (such as a740 firewall) even when the intermediary cannot understand the contents741 of the messages.742 </t>743 <figure><artwork type="drawing">744 request chain -------------------------------------->745 UA -----v----- A -----v----- B -----v----- C -----v----- O746 <------------------------------------- response chain747 </artwork></figure>748 <t>749 The figure above shows three intermediaries (A, B, and C) between the750 user agent and origin server. A request or response message that751 travels the whole chain will pass through four separate connections.752 This distinction is important because some HTTP communication options753 may apply only to the connection with the nearest, non-tunnel754 neighbor, only to the end-points of the chain, or to all connections755 along the chain. Although the diagram is linear, each participant may756 be engaged in multiple, simultaneous communications. For example, B757 may be receiving requests from many clients other than A, and/or758 forwarding requests to servers other than C, at the same time that it759 is handling A's request.760 </t>761 <t>762 Any party to the communication which is not acting as a tunnel may763 employ an internal cache for handling requests. The effect of a cache764 is that the request/response chain is shortened if one of the765 participants along the chain has a cached response applicable to that766 request. The following illustrates the resulting chain if B has a767 cached copy of an earlier response from O (via C) for a request which768 has not been cached by UA or A.769 </t>770 <figure><artwork type="drawing">771 request chain ---------->772 UA -----v----- A -----v----- B - - - - - - C - - - - - - O773 <--------- response chain774 </artwork></figure>775 <t>776 Not all responses are usefully cacheable, and some requests may777 contain modifiers which place special requirements on cache behavior.778 HTTP requirements for cache behavior and cacheable responses are779 defined in &caching;.780 </t>781 <t>782 In fact, there are a wide variety of architectures and configurations783 of caches and proxies currently being experimented with or deployed784 across the World Wide Web. These systems include national hierarchies785 of proxy caches to save transoceanic bandwidth, systems that786 broadcast or multicast cache entries, organizations that distribute787 subsets of cached data via CD-ROM, and so on. HTTP systems are used788 in corporate intranets over high-bandwidth links, and for access via789 PDAs with low-power radio links and intermittent connectivity. The790 goal of HTTP/1.1 is to support the wide diversity of configurations791 already deployed while introducing protocol constructs that meet the792 needs of those who build web applications that require high793 reliability and, failing that, at least reliable indications of794 failure.795 </t>796 <t>797 HTTP communication usually takes place over TCP/IP connections. The798 default port is TCP 80 (<eref target="http://www.iana.org/assignments/port-numbers"/>), but other ports can be used. This does799 not preclude HTTP from being implemented on top of any other protocol800 on the Internet, or on other networks. HTTP only presumes a reliable801 transport; any protocol that provides such guarantees can be used;802 the mapping of the HTTP/1.1 request and response structures onto the803 transport data units of the protocol in question is outside the scope804 of this specification.805 </t>806 <t>807 In HTTP/1.0, most implementations used a new connection for each808 request/response exchange. In HTTP/1.1, a connection may be used for809 one or more request/response exchanges, although connections may be810 closed for a variety of reasons (see <xref target="persistent.connections"/>).811 </t>812 812 </section> 813 813
Note: See TracChangeset
for help on using the changeset viewer.