Changeset 630 for draft-ietf-httpbis/latest
- Timestamp:
- 27/07/09 16:05:58 (13 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.xml
r627 r630 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 510 <section title="Client/Server Operation" anchor="operation"> 511 <iref item="client"/> 512 <iref item="server"/> 513 <iref item="connection"/> 514 <t> 515 HTTP is a request/response protocol that operates by exchanging messages 516 across a reliable transport or session-layer connection. An HTTP client 517 is a program that establishes a connection to a server for the purpose 518 of sending one or more HTTP requests. An HTTP server is a program that 519 accepts connections in order to service HTTP requests by sending HTTP 520 responses. 521 </t> 522 <iref item="user agent"/> 523 <iref item="origin server"/> 524 <t> 525 Note that the terms "client" and "server" refer only to the roles that 526 these programs perform for a particular connection. The same program 527 may act as a client on some connections and a server on others. We use 528 the term "user agent" to refer to the program that initiates a request, 529 such as a WWW browser, editor, or spider (web-traversing robot), and 530 the term "origin server" to refer to the program that can originate 531 authoritative responses to a request. 532 </t> 533 <t> 534 Most HTTP communication consists of a retrieval request (GET) for 535 a representation of some resource identified by a URI. In the 525 536 simplest case, this may be accomplished via a single connection (v) 526 537 between the user agent (UA) and the origin server (O). … … 531 542 <----------------------- response chain 532 543 </artwork></figure> 544 <iref item="message"/> 545 <iref item="request"/> 546 <iref item="response"/> 547 <t> 548 A client sends an HTTP request to the server in the form of a request 549 message (<xref target="request"/>), beginning with a method, URI, and 550 protocol version, followed by MIME-like header fields containing 551 request modifiers, client information, and payload metadata, an empty 552 line, and finally the payload body (if any). 553 The server response (<xref target="response"/>) begins with a status line, 554 including the protocol version, a success or error code, and textual 555 reason phrase, followed by MIME-like header fields containing server 556 information, resource metadata, payload metadata, an empty line, and 557 finally the payload body (if any). 558 </t> 559 <figure><preamble> 560 The following example illustrates a typical message exchange for a 561 GET request on the URI "http://www.example.com/hello.txt": 562 </preamble><artwork type="drawing"> 563 client request: 564 565 GET /hello.txt HTTP/1.1 566 User-Agent: curl/7.16.3 libcurl/7.16.3 OpenSSL/0.9.7l zlib/1.2.3 567 Host: www.example.com 568 Accept: */* 569 570 server response: 571 572 HTTP/1.1 200 OK 573 Date: Mon, 27 Jul 2009 12:28:53 GMT 574 Server: Apache 575 Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT 576 ETag: "34aa387-d-1568eb00" 577 Accept-Ranges: bytes 578 Content-Length: 13 579 Vary: Accept-Encoding 580 Content-Type: text/plain 581 582 Hello World! 583 </artwork></figure> 584 </section> 585 586 <section title="Intermediaries" anchor="intermediaries"> 533 587 <t> 534 588 A more complicated situation occurs when one or more intermediaries 535 589 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. 590 forms of intermediary: proxy, gateway, and tunnel. In some cases, 591 a single intermediary may act as an origin server, proxy, gateway, 592 or tunnel, switching behavior based on the nature of each request. 547 593 </t> 548 594 <figure><artwork type="drawing"> … … 555 601 user agent and origin server. A request or response message that 556 602 travels the whole chain will pass through four separate connections. 557 This distinction is important because some HTTP communication options603 Some HTTP communication options 558 604 may apply only to the connection with the nearest, non-tunnel 559 605 neighbor, only to the end-points of the chain, or to all connections … … 565 611 </t> 566 612 <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. 613 <iref item="upstream"/><iref item="downstream"/> 614 <iref item="inbound"/><iref item="outbound"/> 615 We use the terms "upstream" and "downstream" to describe various 616 requirements in relation to the directional flow of a message: 617 all messages flow from upstream to downstream. 618 Likewise, we use the terms "inbound" and "outbound" to refer to 619 directions in relation to the request path: "inbound" means toward 620 the origin server and "outbound" means toward the user agent. 621 </t> 622 <t><iref item="proxy"/> 623 A proxy is a message forwarding agent that is selected by the 624 client, usually via local configuration rules, to receive requests 625 for some type(s) of absolute URI and attempt to satisfy those 626 requests via translation through the HTTP interface. Some translations 627 are minimal, such as for proxy requests for "http" URIs, whereas 628 other requests may require translation to and from entirely different 629 application-layer protocols. Proxies are often used to group an 630 organization's HTTP requests through a common intermediary for the 631 sake of security, annotation services, or shared caching. 632 </t> 633 <t><iref item="gateway"/><iref item="reverse proxy"/> 634 A gateway (a.k.a., reverse proxy) is a receiving agent that acts 635 as a layer above some other server(s) and translates the received 636 requests to the underlying server's protocol. Gateways are often 637 used for load balancing or partitioning HTTP services across 638 multiple machines. 639 Unlike a proxy, a gateway receives requests as if it were the 640 origin server for the requested resource; the requesting client 641 will not be aware that it is communicating with a gateway. 642 A gateway communicates with the client as if the gateway is the 643 origin server and thus is subject to all of the requirements on 644 origin servers for that connection. A gateway communicates 645 with inbound servers using any protocol it desires, including 646 private extensions to HTTP that are outside the scope of this 647 specification. 648 </t> 649 <t><iref item="tunnel"/> 650 A tunnel acts as a blind relay between two connections 651 without changing the messages. Once active, a tunnel is not 652 considered a party to the HTTP communication, though the tunnel may 653 have been initiated by an HTTP request. A tunnel ceases to exist when 654 both ends of the relayed connection are closed. Tunnels are used to 655 extend a virtual connection through an intermediary, such as when 656 transport-layer security is used to establish private communication 657 through a shared firewall proxy. 658 </t> 659 </section> 660 661 <section title="Caches" anchor="caches"> 662 <iref item="cache"/> 663 <t> 664 Any party to HTTP communication that is not acting as a tunnel may 665 employ an internal cache for handling requests. 666 A cache is a local store of previous response messages and the 667 subsystem that controls its message storage, retrieval, and deletion. 668 A cache stores cacheable responses in order to reduce the response 669 time and network bandwidth consumption on future, equivalent 670 requests. Any client or server may include a cache, though a cache 671 cannot be used by a server while it is acting as a tunnel. 672 </t> 673 <t> 674 The effect of a cache is that the request/response chain is shortened 675 if one of the participants along the chain has a cached response 676 applicable to that request. The following illustrates the resulting 677 chain if B has a cached copy of an earlier response from O (via C) 678 for a request which has not been cached by UA or A. 574 679 </t> 575 680 <figure><artwork type="drawing"> … … 578 683 <--------- response chain 579 684 </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 685 <t><iref item="cacheable"/> 686 A response is cacheable if a cache is allowed to store a copy of 687 the response message for use in answering subsequent requests. 688 Even when a response is cacheable, there may be additional 689 constraints placed by the client or by the origin server on when 690 that cached response can be used for a particular request. HTTP 691 requirements for cache behavior and cacheable responses are 692 defined in &caching;. 693 </t> 694 <t> 695 There are a wide variety of architectures and configurations 696 of caches and proxies deployed across the World Wide Web and 697 inside large organizations. These systems include national hierarchies 590 698 of proxy caches to save transoceanic bandwidth, systems that 591 699 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. 700 subsets of cached data via CD-ROM, and so on. 701 </t> 702 </section> 703 704 <section title="Transport Independence" anchor="transport-independence"> 705 <t> 706 HTTP systems are used in a wide variety of environments, from 707 corporate intranets with high-bandwidth links to long-distance 708 communication over low-power radio links and intermittent connectivity. 600 709 </t> 601 710 <t> … … 4203 4312 </t> 4204 4313 <t> 4205 <iref item="cache"/>4206 <x:dfn>cache</x:dfn>4207 <list>4208 <t>4209 A program's local store of response messages and the subsystem4210 that controls its message storage, retrieval, and deletion. A4211 cache stores cacheable responses in order to reduce the response4212 time and network bandwidth consumption on future, equivalent4213 requests. Any client or server may include a cache, though a cache4214 cannot be used by a server that is acting as a tunnel.4215 </t>4216 </list>4217 </t>4218 <t>4219 <iref item="cacheable"/>4220 <x:dfn>cacheable</x:dfn>4221 <list>4222 <t>4223 A response is cacheable if a cache is allowed to store a copy of4224 the response message for use in answering subsequent requests. The4225 rules for determining the cacheability of HTTP responses are4226 defined in &caching;. Even if a resource is cacheable, there may4227 be additional constraints on whether a cache can use the cached4228 copy for a particular request.4229 </t>4230 </list>4231 </t>4232 <t>4233 <iref item="client"/>4234 <x:dfn>client</x:dfn>4235 <list>4236 <t>4237 A program that establishes connections for the purpose of sending4238 requests.4239 </t>4240 </list>4241 </t>4242 <t>4243 <iref item="connection"/>4244 <x:dfn>connection</x:dfn>4245 <list>4246 <t>4247 A transport layer virtual circuit established between two programs4248 for the purpose of communication.4249 </t>4250 </list>4251 </t>4252 <t>4253 4314 <iref item="content negotiation"/> 4254 4315 <x:dfn>content negotiation</x:dfn> … … 4275 4336 </t> 4276 4337 <t> 4277 <iref item="gateway"/>4278 <x:dfn>gateway</x:dfn>4279 <list>4280 <t>4281 A server which acts as an intermediary for some other server.4282 Unlike a proxy, a gateway receives requests as if it were the4283 origin server for the requested resource; the requesting client4284 may not be aware that it is communicating with a gateway.4285 </t>4286 </list>4287 </t>4288 <t>4289 <iref item="inbound"/>4290 <iref item="outbound"/>4291 <x:dfn>inbound</x:dfn>/<x:dfn>outbound</x:dfn>4292 <list>4293 <t>4294 Inbound and outbound refer to the request and response paths for4295 messages: "inbound" means "traveling toward the origin server",4296 and "outbound" means "traveling toward the user agent"4297 </t>4298 </list>4299 </t>4300 <t>4301 <iref item="message"/>4302 <x:dfn>message</x:dfn>4303 <list>4304 <t>4305 The basic unit of HTTP communication, consisting of a structured4306 sequence of octets matching the syntax defined in <xref target="http.message"/> and4307 transmitted via the connection.4308 </t>4309 </list>4310 </t>4311 <t>4312 <iref item="origin server"/>4313 <x:dfn>origin server</x:dfn>4314 <list>4315 <t>4316 The server on which a given resource resides or is to be created.4317 </t>4318 </list>4319 </t>4320 <t>4321 <iref item="proxy"/>4322 <x:dfn>proxy</x:dfn>4323 <list>4324 <t>4325 An intermediary program which acts as both a server and a client4326 for the purpose of making requests on behalf of other clients.4327 Requests are serviced internally or by passing them on, with4328 possible translation, to other servers. A proxy &MUST; implement4329 both the client and server requirements of this specification. A4330 "transparent proxy" is a proxy that does not modify the request or4331 response beyond what is required for proxy authentication and4332 identification. A "non-transparent proxy" is a proxy that modifies4333 the request or response in order to provide some added service to4334 the user agent, such as group annotation services, media type4335 transformation, protocol reduction, or anonymity filtering. Except4336 where either transparent or non-transparent behavior is explicitly4337 stated, the HTTP proxy requirements apply to both types of4338 proxies.4339 </t>4340 </list>4341 </t>4342 <t>4343 <iref item="request"/>4344 <x:dfn>request</x:dfn>4345 <list>4346 <t>4347 An HTTP request message, as defined in <xref target="request"/>.4348 </t>4349 </list>4350 </t>4351 <t>4352 <iref item="response"/>4353 <x:dfn>response</x:dfn>4354 <list>4355 <t>4356 An HTTP response message, as defined in <xref target="response"/>.4357 </t>4358 </list>4359 </t>4360 <t>4361 4338 <iref item="representation"/> 4362 4339 <x:dfn>representation</x:dfn> … … 4366 4343 negotiation, as described in &content.negotiation;. There may exist multiple 4367 4344 representations associated with a particular response status. 4368 </t>4369 </list>4370 </t>4371 <t>4372 <iref item="server"/>4373 <x:dfn>server</x:dfn>4374 <list>4375 <t>4376 An application program that accepts connections in order to4377 service requests by sending back responses. Any given program may4378 be capable of being both a client and a server; our use of these4379 terms refers only to the role being performed by the program for a4380 particular connection, rather than to the program's capabilities4381 in general. Likewise, any server may act as an origin server,4382 proxy, gateway, or tunnel, switching behavior based on the nature4383 of each request.4384 </t>4385 </list>4386 </t>4387 <t>4388 <iref item="tunnel"/>4389 <x:dfn>tunnel</x:dfn>4390 <list>4391 <t>4392 An intermediary program which is acting as a blind relay between4393 two connections. Once active, a tunnel is not considered a party4394 to the HTTP communication, though the tunnel may have been4395 initiated by an HTTP request. The tunnel ceases to exist when both4396 ends of the relayed connections are closed.4397 </t>4398 </list>4399 </t>4400 <t>4401 <iref item="upstream"/>4402 <iref item="downstream"/>4403 <x:dfn>upstream</x:dfn>/<x:dfn>downstream</x:dfn>4404 <list>4405 <t>4406 Upstream and downstream describe the flow of a message: all4407 messages flow from upstream to downstream.4408 </t>4409 </list>4410 </t>4411 <t>4412 <iref item="user agent"/>4413 <x:dfn>user agent</x:dfn>4414 <list>4415 <t>4416 The client which initiates a request. These are often browsers,4417 editors, spiders (web-traversing robots), or other end user tools.4418 4345 </t> 4419 4346 </list>
Note: See TracChangeset
for help on using the changeset viewer.