Changeset 1227 for draft-ietf-httpbis/latest/p1-messaging.xml
- Timestamp:
- 28/03/11 15:34:32 (11 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.xml
r1214 r1227 532 532 <t> 533 533 HTTP is a stateless request/response protocol that operates by exchanging 534 messages across a reliable transport or session-layer connection. An HTTP 535 "client" is a program that establishes a connection to a server for the 536 purpose of sending one or more HTTP requests. An HTTP "server" is a 534 messages across a reliable transport or session-layer 535 "<x:dfn>connection</x:dfn>". An HTTP "<x:dfn>client</x:dfn>" is a 536 program that establishes a connection to a server for the purpose of 537 sending one or more HTTP requests. An HTTP "<x:dfn>server</x:dfn>" is a 537 538 program that accepts connections in order to service HTTP requests by 538 539 sending HTTP responses. … … 542 543 <iref primary="true" item="browser"/> 543 544 <iref primary="true" item="spider"/> 545 <iref primary="true" item="sender"/> 546 <iref primary="true" item="recipient"/> 544 547 <t> 545 548 Note that the terms client and server refer only to the roles that 546 549 these programs perform for a particular connection. The same program 547 550 might act as a client on some connections and a server on others. We use 548 the term " user agent" to refer to the program that initiates a request,551 the term "<x:dfn>user agent</x:dfn>" to refer to the program that initiates a request, 549 552 such as a WWW browser, editor, or spider (web-traversing robot), and 550 the term " origin server" to refer to the program that can originate553 the term "<x:dfn>origin server</x:dfn>" to refer to the program that can originate 551 554 authoritative responses to a request. For general requirements, we use 552 the term " sender" to refer to whichever component sent a given message553 and the term " recipient" to refer to any component that receives the555 the term "<x:dfn>sender</x:dfn>" to refer to whichever component sent a given message 556 and the term "<x:dfn>recipient</x:dfn>" to refer to any component that receives the 554 557 message. 555 558 </t> … … 569 572 <iref primary="true" item="response"/> 570 573 <t> 571 A client sends an HTTP request to the server in the form of a request572 message(<xref target="request"/>), beginning with a method, URI, and574 A client sends an HTTP request to the server in the form of a <x:dfn>request</x:dfn> 575 <x:dfn>message</x:dfn> (<xref target="request"/>), beginning with a method, URI, and 573 576 protocol version, followed by MIME-like header fields containing 574 577 request modifiers, client information, and payload metadata, an empty … … 577 580 </t> 578 581 <t> 579 A server responds to the client's request by sending an HTTP response580 message(<xref target="response"/>), beginning with a status line that582 A server responds to the client's request by sending an HTTP <x:dfn>response</x:dfn> 583 <x:dfn>message</x:dfn> (<xref target="response"/>), beginning with a status line that 581 584 includes the protocol version, a success or error code, and textual 582 585 reason phrase, followed by MIME-like header fields containing server … … 643 646 HTTP enables the use of intermediaries to satisfy requests through 644 647 a chain of connections. There are three common forms of HTTP 645 intermediary: proxy, gateway, and tunnel. In some cases,648 <x:dfn>intermediary</x:dfn>: proxy, gateway, and tunnel. In some cases, 646 649 a single intermediary might act as an origin server, proxy, gateway, 647 650 or tunnel, switching behavior based on the nature of each request. … … 668 671 <iref primary="true" item="upstream"/><iref primary="true" item="downstream"/> 669 672 <iref primary="true" item="inbound"/><iref primary="true" item="outbound"/> 670 We use the terms "upstream" and "downstream" to describe various 671 requirements in relation to the directional flow of a message: 672 all messages flow from upstream to downstream. 673 Likewise, we use the terms "inbound" and "outbound" to refer to 674 directions in relation to the request path: "inbound" means toward 675 the origin server and "outbound" means toward the user agent. 673 We use the terms "<x:dfn>upstream</x:dfn>" and "<x:dfn>downstream</x:dfn>" 674 to describe various requirements in relation to the directional flow of a 675 message: all messages flow from upstream to downstream. 676 Likewise, we use the terms inbound and outbound to refer to 677 directions in relation to the request path: 678 "<x:dfn>inbound</x:dfn>" means toward the origin server and 679 "<x:dfn>outbound</x:dfn>" means toward the user agent. 676 680 </t> 677 681 <t><iref primary="true" item="proxy"/> 678 A " proxy" is a message forwarding agent that is selected by the682 A "<x:dfn>proxy</x:dfn>" is a message forwarding agent that is selected by the 679 683 client, usually via local configuration rules, to receive requests 680 684 for some type(s) of absolute URI and attempt to satisfy those … … 689 693 <iref primary="true" item="transforming proxy"/> 690 694 <iref primary="true" item="non-transforming proxy"/> 691 An HTTP-to-HTTP proxy is called a " transforming proxy" if it is designed695 An HTTP-to-HTTP proxy is called a "<x:dfn>transforming proxy</x:dfn>" if it is designed 692 696 or configured to modify request or response messages in a semantically 693 697 meaningful way (i.e., modifications, beyond those required by normal … … 701 705 organization) that selected the proxy and are beyond the scope of 702 706 this specification. However, when a proxy is not intended to transform 703 a given message, we use the term " non-transforming proxy" to target707 a given message, we use the term "<x:dfn>non-transforming proxy</x:dfn>" to target 704 708 requirements that preserve HTTP message semantics. 705 709 </t> 706 710 <t><iref primary="true" item="gateway"/><iref primary="true" item="reverse proxy"/> 707 711 <iref primary="true" item="accelerator"/> 708 A "gateway" (a.k.a., "reverse proxy") is a receiving agent that acts 712 A "<x:dfn>gateway</x:dfn>" (a.k.a., "<x:dfn>reverse proxy</x:dfn>") 713 is a receiving agent that acts 709 714 as a layer above some other server(s) and translates the received 710 715 requests to the underlying server's protocol. Gateways are often 711 716 used to encapsulate legacy or untrusted information services, to 712 improve server performance through " accelerator" caching, and to717 improve server performance through "<x:dfn>accelerator</x:dfn>" caching, and to 713 718 enable partitioning or load-balancing of HTTP services across 714 719 multiple machines. … … 729 734 </t> 730 735 <t><iref primary="true" item="tunnel"/> 731 A " tunnel" acts as a blind relay between two connections736 A "<x:dfn>tunnel</x:dfn>" acts as a blind relay between two connections 732 737 without changing the messages. Once active, a tunnel is not 733 738 considered a party to the HTTP communication, though the tunnel might … … 744 749 filters or redirecting agents (usually violating HTTP semantics, 745 750 causing security problems, and otherwise making a mess of things). 746 Such a network intermediary, often referred to as an " interception proxy"747 <xref target="RFC3040"/>, " transparent proxy" <xref target="RFC1919"/>,748 or " captive portal",751 Such a network intermediary, often referred to as an "<x:dfn>interception proxy</x:dfn>" 752 <xref target="RFC3040"/>, "<x:dfn>transparent proxy</x:dfn>" <xref target="RFC1919"/>, 753 or "<x:dfn>captive portal</x:dfn>", 749 754 differs from an HTTP proxy because it has not been selected by the client. 750 755 Instead, the network intermediary redirects outgoing TCP port 80 packets … … 761 766 <iref primary="true" item="cache"/> 762 767 <t> 763 A " cache" is a local store of previous response messages and the768 A "<x:dfn>cache</x:dfn>" is a local store of previous response messages and the 764 769 subsystem that controls its message storage, retrieval, and deletion. 765 770 A cache stores cacheable responses in order to reduce the response … … 781 786 </artwork></figure> 782 787 <t><iref primary="true" item="cacheable"/> 783 A response is " cacheable" if a cache is allowed to store a copy of788 A response is "<x:dfn>cacheable</x:dfn>" if a cache is allowed to store a copy of 784 789 the response message for use in answering subsequent requests. 785 790 Even when a response is cacheable, there might be additional
Note: See TracChangeset
for help on using the changeset viewer.