Changeset 389 for draft-ietf-httpbis/latest/p1-messaging.xml
- Timestamp:
- 15/11/08 00:20:37 (12 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.xml
r385 r389 280 280 </section> 281 281 282 <section title="Overall Operation" anchor="intro.overall.operation">283 <t>284 HTTP is a request/response protocol. A client sends a285 request to the server in the form of a request method, URI, and286 protocol version, followed by a MIME-like message containing request287 modifiers, client information, and possible body content over a288 connection with a server. The server responds with a status line,289 including the message's protocol version and a success or error code,290 followed by a MIME-like message containing server information, entity291 metainformation, and possible entity-body content. The relationship292 between HTTP and MIME is described in &diff2045entity;.293 </t>294 <t>295 Most HTTP communication is initiated by a user agent and consists of296 a request to be applied to a resource on some origin server. In the297 simplest case, this may be accomplished via a single connection (v)298 between the user agent (UA) and the origin server (O).299 </t>300 <figure><artwork type="drawing">301 request chain ------------------------>302 UA -------------------v------------------- O303 <----------------------- response chain304 </artwork></figure>305 <t>306 A more complicated situation occurs when one or more intermediaries307 are present in the request/response chain. There are three common308 forms of intermediary: proxy, gateway, and tunnel. A proxy is a309 forwarding agent, receiving requests for a URI in its absolute form,310 rewriting all or part of the message, and forwarding the reformatted311 request toward the server identified by the URI. A gateway is a312 receiving agent, acting as a layer above some other server(s) and, if313 necessary, translating the requests to the underlying server's314 protocol. A tunnel acts as a relay point between two connections315 without changing the messages; tunnels are used when the316 communication needs to pass through an intermediary (such as a317 firewall) even when the intermediary cannot understand the contents318 of the messages.319 </t>320 <figure><artwork type="drawing">321 request chain -------------------------------------->322 UA -----v----- A -----v----- B -----v----- C -----v----- O323 <------------------------------------- response chain324 </artwork></figure>325 <t>326 The figure above shows three intermediaries (A, B, and C) between the327 user agent and origin server. A request or response message that328 travels the whole chain will pass through four separate connections.329 This distinction is important because some HTTP communication options330 may apply only to the connection with the nearest, non-tunnel331 neighbor, only to the end-points of the chain, or to all connections332 along the chain. Although the diagram is linear, each participant may333 be engaged in multiple, simultaneous communications. For example, B334 may be receiving requests from many clients other than A, and/or335 forwarding requests to servers other than C, at the same time that it336 is handling A's request.337 </t>338 <t>339 Any party to the communication which is not acting as a tunnel may340 employ an internal cache for handling requests. The effect of a cache341 is that the request/response chain is shortened if one of the342 participants along the chain has a cached response applicable to that343 request. The following illustrates the resulting chain if B has a344 cached copy of an earlier response from O (via C) for a request which345 has not been cached by UA or A.346 </t>347 <figure><artwork type="drawing">348 request chain ---------->349 UA -----v----- A -----v----- B - - - - - - C - - - - - - O350 <--------- response chain351 </artwork></figure>352 <t>353 Not all responses are usefully cacheable, and some requests may354 contain modifiers which place special requirements on cache behavior.355 HTTP requirements for cache behavior and cacheable responses are356 defined in &caching;.357 </t>358 <t>359 In fact, there are a wide variety of architectures and configurations360 of caches and proxies currently being experimented with or deployed361 across the World Wide Web. These systems include national hierarchies362 of proxy caches to save transoceanic bandwidth, systems that363 broadcast or multicast cache entries, organizations that distribute364 subsets of cached data via CD-ROM, and so on. HTTP systems are used365 in corporate intranets over high-bandwidth links, and for access via366 PDAs with low-power radio links and intermittent connectivity. The367 goal of HTTP/1.1 is to support the wide diversity of configurations368 already deployed while introducing protocol constructs that meet the369 needs of those who build web applications that require high370 reliability and, failing that, at least reliable indications of371 failure.372 </t>373 <t>374 HTTP communication usually takes place over TCP/IP connections. The375 default port is TCP 80 (<eref target="http://www.iana.org/assignments/port-numbers"/>), but other ports can be used. This does376 not preclude HTTP from being implemented on top of any other protocol377 on the Internet, or on other networks. HTTP only presumes a reliable378 transport; any protocol that provides such guarantees can be used;379 the mapping of the HTTP/1.1 request and response structures onto the380 transport data units of the protocol in question is outside the scope381 of this specification.382 </t>383 <t>384 In HTTP/1.0, most implementations used a new connection for each385 request/response exchange. In HTTP/1.1, a connection may be used for386 one or more request/response exchanges, although connections may be387 closed for a variety of reasons (see <xref target="persistent.connections"/>).388 </t>389 </section>390 </section>391 392 282 <section title="Notational Conventions and Generic Grammar" anchor="notation"> 393 283 … … 600 490 601 491 </section> 492 493 <section title="Overall Operation" anchor="intro.overall.operation"> 494 <t> 495 HTTP is a request/response protocol. A client sends a 496 request to the server in the form of a request method, URI, and 497 protocol version, followed by a MIME-like message containing request 498 modifiers, client information, and possible body content over a 499 connection with a server. The server responds with a status line, 500 including the message's protocol version and a success or error code, 501 followed by a MIME-like message containing server information, entity 502 metainformation, and possible entity-body content. The relationship 503 between HTTP and MIME is described in &diff2045entity;. 504 </t> 505 <t> 506 Most HTTP communication is initiated by a user agent and consists of 507 a request to be applied to a resource on some origin server. In the 508 simplest case, this may be accomplished via a single connection (v) 509 between the user agent (UA) and the origin server (O). 510 </t> 511 <figure><artwork type="drawing"> 512 request chain ------------------------> 513 UA -------------------v------------------- O 514 <----------------------- response chain 515 </artwork></figure> 516 <t> 517 A more complicated situation occurs when one or more intermediaries 518 are present in the request/response chain. There are three common 519 forms of intermediary: proxy, gateway, and tunnel. A proxy is a 520 forwarding agent, receiving requests for a URI in its absolute form, 521 rewriting all or part of the message, and forwarding the reformatted 522 request toward the server identified by the URI. A gateway is a 523 receiving agent, acting as a layer above some other server(s) and, if 524 necessary, translating the requests to the underlying server's 525 protocol. A tunnel acts as a relay point between two connections 526 without changing the messages; tunnels are used when the 527 communication needs to pass through an intermediary (such as a 528 firewall) even when the intermediary cannot understand the contents 529 of the messages. 530 </t> 531 <figure><artwork type="drawing"> 532 request chain --------------------------------------> 533 UA -----v----- A -----v----- B -----v----- C -----v----- O 534 <------------------------------------- response chain 535 </artwork></figure> 536 <t> 537 The figure above shows three intermediaries (A, B, and C) between the 538 user agent and origin server. A request or response message that 539 travels the whole chain will pass through four separate connections. 540 This distinction is important because some HTTP communication options 541 may apply only to the connection with the nearest, non-tunnel 542 neighbor, only to the end-points of the chain, or to all connections 543 along the chain. Although the diagram is linear, each participant may 544 be engaged in multiple, simultaneous communications. For example, B 545 may be receiving requests from many clients other than A, and/or 546 forwarding requests to servers other than C, at the same time that it 547 is handling A's request. 548 </t> 549 <t> 550 Any party to the communication which is not acting as a tunnel may 551 employ an internal cache for handling requests. The effect of a cache 552 is that the request/response chain is shortened if one of the 553 participants along the chain has a cached response applicable to that 554 request. The following illustrates the resulting chain if B has a 555 cached copy of an earlier response from O (via C) for a request which 556 has not been cached by UA or A. 557 </t> 558 <figure><artwork type="drawing"> 559 request chain ----------> 560 UA -----v----- A -----v----- B - - - - - - C - - - - - - O 561 <--------- response chain 562 </artwork></figure> 563 <t> 564 Not all responses are usefully cacheable, and some requests may 565 contain modifiers which place special requirements on cache behavior. 566 HTTP requirements for cache behavior and cacheable responses are 567 defined in &caching;. 568 </t> 569 <t> 570 In fact, there are a wide variety of architectures and configurations 571 of caches and proxies currently being experimented with or deployed 572 across the World Wide Web. These systems include national hierarchies 573 of proxy caches to save transoceanic bandwidth, systems that 574 broadcast or multicast cache entries, organizations that distribute 575 subsets of cached data via CD-ROM, and so on. HTTP systems are used 576 in corporate intranets over high-bandwidth links, and for access via 577 PDAs with low-power radio links and intermittent connectivity. The 578 goal of HTTP/1.1 is to support the wide diversity of configurations 579 already deployed while introducing protocol constructs that meet the 580 needs of those who build web applications that require high 581 reliability and, failing that, at least reliable indications of 582 failure. 583 </t> 584 <t> 585 HTTP communication usually takes place over TCP/IP connections. The 586 default port is TCP 80 (<eref target="http://www.iana.org/assignments/port-numbers"/>), but other ports can be used. This does 587 not preclude HTTP from being implemented on top of any other protocol 588 on the Internet, or on other networks. HTTP only presumes a reliable 589 transport; any protocol that provides such guarantees can be used; 590 the mapping of the HTTP/1.1 request and response structures onto the 591 transport data units of the protocol in question is outside the scope 592 of this specification. 593 </t> 594 <t> 595 In HTTP/1.0, most implementations used a new connection for each 596 request/response exchange. In HTTP/1.1, a connection may be used for 597 one or more request/response exchanges, although connections may be 598 closed for a variety of reasons (see <xref target="persistent.connections"/>). 599 </t> 600 </section> 601 </section> 602 602 603 603 604 <section title="Protocol Parameters" anchor="protocol.parameters">
Note: See TracChangeset
for help on using the changeset viewer.