Changeset 1227 for draft-ietf-httpbis/latest
- Timestamp:
- 28/03/11 15:34:32 (11 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 2 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.html
r1215 r1227 359 359 } 360 360 @bottom-center { 361 content: "Expires September 2 8, 2011";361 content: "Expires September 29, 2011"; 362 362 } 363 363 @bottom-right { … … 410 410 <meta name="dct.creator" content="Reschke, J. F."> 411 411 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p1-messaging-latest"> 412 <meta name="dct.issued" scheme="ISO8601" content="2011-03-2 7">412 <meta name="dct.issued" scheme="ISO8601" content="2011-03-28"> 413 413 <meta name="dct.replaces" content="urn:ietf:rfc:2145"> 414 414 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> … … 442 442 </tr> 443 443 <tr> 444 <td class="left">Expires: September 2 8, 2011</td>444 <td class="left">Expires: September 29, 2011</td> 445 445 <td class="right">HP</td> 446 446 </tr> … … 495 495 <tr> 496 496 <td class="left"></td> 497 <td class="right">March 2 7, 2011</td>497 <td class="right">March 28, 2011</td> 498 498 </tr> 499 499 </tbody> … … 523 523 in progress”. 524 524 </p> 525 <p>This Internet-Draft will expire on September 2 8, 2011.</p>525 <p>This Internet-Draft will expire on September 29, 2011.</p> 526 526 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 527 527 <p>Copyright © 2011 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 872 872 <h2 id="rfc.section.2.1"><a href="#rfc.section.2.1">2.1</a> <a id="operation" href="#operation">Client/Server Messaging</a></h2> 873 873 <p id="rfc.section.2.1.p.1">HTTP is a stateless request/response protocol that operates by exchanging messages across a reliable transport or session-layer 874 connection. An HTTP "client" is a program that establishes a connection to a server for the purpose of sending one or more 875 HTTP requests. An HTTP "server" is a program that accepts connections in order to service HTTP requests by sending HTTP responses. 874 "<dfn>connection</dfn>". An HTTP "<dfn>client</dfn>" is a program that establishes a connection to a server for the purpose of sending one or more HTTP requests. An HTTP "<dfn>server</dfn>" is a program that accepts connections in order to service HTTP requests by sending HTTP responses. 876 875 </p> 877 876 <div id="rfc.iref.u.1"></div> … … 879 878 <div id="rfc.iref.b.1"></div> 880 879 <div id="rfc.iref.s.2"></div> 880 <div id="rfc.iref.s.3"></div> 881 <div id="rfc.iref.r.1"></div> 881 882 <p id="rfc.section.2.1.p.2">Note that the terms client and server refer only to the roles that these programs perform for a particular connection. The 882 same program might act as a client on some connections and a server on others. We use the term "user agent" to refer to the 883 program that initiates a request, such as a WWW browser, editor, or spider (web-traversing robot), and the term "origin server" 884 to refer to the program that can originate authoritative responses to a request. For general requirements, we use the term 885 "sender" to refer to whichever component sent a given message and the term "recipient" to refer to any component that receives 886 the message. 883 same program might act as a client on some connections and a server on others. We use the term "<dfn>user agent</dfn>" to refer to the program that initiates a request, such as a WWW browser, editor, or spider (web-traversing robot), and the 884 term "<dfn>origin server</dfn>" to refer to the program that can originate authoritative responses to a request. For general requirements, we use the term 885 "<dfn>sender</dfn>" to refer to whichever component sent a given message and the term "<dfn>recipient</dfn>" to refer to any component that receives the message. 887 886 </p> 888 887 <p id="rfc.section.2.1.p.3">Most HTTP communication consists of a retrieval request (GET) for a representation of some resource identified by a URI. In … … 894 893 < response 895 894 </pre><div id="rfc.iref.m.1"></div> 896 <div id="rfc.iref.r.1"></div>897 895 <div id="rfc.iref.r.2"></div> 898 <p id="rfc.section.2.1.p.5">A client sends an HTTP request to the server in the form of a request message (<a href="#request" title="Request">Section 4</a>), beginning with a method, URI, and protocol version, followed by MIME-like header fields containing request modifiers, client 896 <div id="rfc.iref.r.3"></div> 897 <p id="rfc.section.2.1.p.5">A client sends an HTTP request to the server in the form of a <dfn>request</dfn> <dfn>message</dfn> (<a href="#request" title="Request">Section 4</a>), beginning with a method, URI, and protocol version, followed by MIME-like header fields containing request modifiers, client 899 898 information, and payload metadata, an empty line to indicate the end of the header section, and finally the payload body (if 900 899 any). 901 900 </p> 902 <p id="rfc.section.2.1.p.6">A server responds to the client's request by sending an HTTP response message(<a href="#response" title="Response">Section 5</a>), beginning with a status line that includes the protocol version, a success or error code, and textual reason phrase, followed901 <p id="rfc.section.2.1.p.6">A server responds to the client's request by sending an HTTP <dfn>response</dfn> <dfn>message</dfn> (<a href="#response" title="Response">Section 5</a>), beginning with a status line that includes the protocol version, a success or error code, and textual reason phrase, followed 903 902 by MIME-like header fields containing server information, resource metadata, and payload metadata, an empty line to indicate 904 903 the end of the header section, and finally the payload body (if any). … … 937 936 <h2 id="rfc.section.2.3"><a href="#rfc.section.2.3">2.3</a> <a id="intermediaries" href="#intermediaries">Intermediaries</a></h2> 938 937 <p id="rfc.section.2.3.p.1">HTTP enables the use of intermediaries to satisfy requests through a chain of connections. There are three common forms of 939 HTTP intermediary: proxy, gateway, and tunnel. In some cases, a single intermediary might act as an origin server, proxy,940 gateway, or tunnel,switching behavior based on the nature of each request.938 HTTP <dfn>intermediary</dfn>: proxy, gateway, and tunnel. In some cases, a single intermediary might act as an origin server, proxy, gateway, or tunnel, 939 switching behavior based on the nature of each request. 941 940 </p> 942 941 <div id="rfc.figure.u.15"></div><pre class="drawing"> > > > > … … 950 949 at the same time that it is handling A's request. 951 950 </p> 952 <p id="rfc.section.2.3.p.4"> <span id="rfc.iref.u.2"></span><span id="rfc.iref.d.1"></span> <span id="rfc.iref.i.2"></span><span id="rfc.iref.o.2"></span> We use the terms "upstream" and "downstream" to describe various requirements in relation to the directional flow of a message: 953 all messages flow from upstream to downstream. Likewise, we use the terms "inbound" and "outbound" to refer to directions 954 in relation to the request path: "inbound" means toward the origin server and "outbound" means toward the user agent. 955 </p> 956 <p id="rfc.section.2.3.p.5"><span id="rfc.iref.p.1"></span> A "proxy" is a message forwarding agent that is selected by the client, usually via local configuration rules, to receive 957 requests for some type(s) of absolute URI and attempt to satisfy those requests via translation through the HTTP interface. 958 Some translations are minimal, such as for proxy requests for "http" URIs, whereas other requests might require translation 959 to and from entirely different application-layer protocols. Proxies are often used to group an organization's HTTP requests 960 through a common intermediary for the sake of security, annotation services, or shared caching. 961 </p> 962 <p id="rfc.section.2.3.p.6"> <span id="rfc.iref.t.1"></span> <span id="rfc.iref.n.1"></span> An HTTP-to-HTTP proxy is called a "transforming proxy" if it is designed or configured to modify request or response messages 963 in a semantically meaningful way (i.e., modifications, beyond those required by normal HTTP processing, that change the message 964 in a way that would be significant to the original sender or potentially significant to downstream recipients). For example, 965 a transforming proxy might be acting as a shared annotation server (modifying responses to include references to a local annotation 966 database), a malware filter, a format transcoder, or an intranet-to-Internet privacy filter. Such transformations are presumed 967 to be desired by the client (or client organization) that selected the proxy and are beyond the scope of this specification. 968 However, when a proxy is not intended to transform a given message, we use the term "non-transforming proxy" to target requirements 969 that preserve HTTP message semantics. 970 </p> 971 <p id="rfc.section.2.3.p.7"><span id="rfc.iref.g.24"></span><span id="rfc.iref.r.3"></span> <span id="rfc.iref.a.1"></span> A "gateway" (a.k.a., "reverse proxy") is a receiving agent that acts as a layer above some other server(s) and translates 972 the received requests to the underlying server's protocol. Gateways are often used to encapsulate legacy or untrusted information 973 services, to improve server performance through "accelerator" caching, and to enable partitioning or load-balancing of HTTP 974 services across multiple machines. 951 <p id="rfc.section.2.3.p.4"> <span id="rfc.iref.u.2"></span><span id="rfc.iref.d.1"></span> <span id="rfc.iref.i.2"></span><span id="rfc.iref.o.2"></span> We use the terms "<dfn>upstream</dfn>" and "<dfn>downstream</dfn>" to describe various requirements in relation to the directional flow of a message: all messages flow from upstream to downstream. 952 Likewise, we use the terms inbound and outbound to refer to directions in relation to the request path: "<dfn>inbound</dfn>" means toward the origin server and "<dfn>outbound</dfn>" means toward the user agent. 953 </p> 954 <p id="rfc.section.2.3.p.5"><span id="rfc.iref.p.1"></span> A "<dfn>proxy</dfn>" is a message forwarding agent that is selected by the client, usually via local configuration rules, to receive requests 955 for some type(s) of absolute URI and attempt to satisfy those requests via translation through the HTTP interface. Some translations 956 are minimal, such as for proxy requests for "http" URIs, whereas other requests might require translation to and from entirely 957 different application-layer protocols. Proxies are often used to group an organization's HTTP requests through a common intermediary 958 for the sake of security, annotation services, or shared caching. 959 </p> 960 <p id="rfc.section.2.3.p.6"> <span id="rfc.iref.t.1"></span> <span id="rfc.iref.n.1"></span> An HTTP-to-HTTP proxy is called a "<dfn>transforming proxy</dfn>" if it is designed or configured to modify request or response messages in a semantically meaningful way (i.e., modifications, 961 beyond those required by normal HTTP processing, that change the message in a way that would be significant to the original 962 sender or potentially significant to downstream recipients). For example, a transforming proxy might be acting as a shared 963 annotation server (modifying responses to include references to a local annotation database), a malware filter, a format transcoder, 964 or an intranet-to-Internet privacy filter. Such transformations are presumed to be desired by the client (or client organization) 965 that selected the proxy and are beyond the scope of this specification. However, when a proxy is not intended to transform 966 a given message, we use the term "<dfn>non-transforming proxy</dfn>" to target requirements that preserve HTTP message semantics. 967 </p> 968 <p id="rfc.section.2.3.p.7"><span id="rfc.iref.g.24"></span><span id="rfc.iref.r.4"></span> <span id="rfc.iref.a.1"></span> A "<dfn>gateway</dfn>" (a.k.a., "<dfn>reverse proxy</dfn>") is a receiving agent that acts as a layer above some other server(s) and translates the received requests to the underlying 969 server's protocol. Gateways are often used to encapsulate legacy or untrusted information services, to improve server performance 970 through "<dfn>accelerator</dfn>" caching, and to enable partitioning or load-balancing of HTTP services across multiple machines. 975 971 </p> 976 972 <p id="rfc.section.2.3.p.8">A gateway behaves as an origin server on its outbound connection and as a user agent on its inbound connection. All HTTP requirements … … 979 975 However, an HTTP-to-HTTP gateway that wishes to interoperate with third-party HTTP servers <em class="bcp14">MUST</em> comply with HTTP user agent requirements on the gateway's inbound connection and <em class="bcp14">MUST</em> implement the Connection (<a href="#header.connection" id="rfc.xref.header.connection.1" title="Connection">Section 9.1</a>) and Via (<a href="#header.via" id="rfc.xref.header.via.1" title="Via">Section 9.9</a>) header fields for both connections. 980 976 </p> 981 <p id="rfc.section.2.3.p.9"><span id="rfc.iref.t.2"></span> A " tunnel" acts as a blind relay between two connections without changing the messages. Once active, a tunnel is not considered982 a party to the HTTP communication, though the tunnel might have been initiated by an HTTP request. A tunnel ceases to exist983 when both ends of the relayed connection are closed. Tunnels are used to extend a virtual connection through an intermediary,984 such aswhen transport-layer security is used to establish private communication through a shared firewall proxy.977 <p id="rfc.section.2.3.p.9"><span id="rfc.iref.t.2"></span> A "<dfn>tunnel</dfn>" acts as a blind relay between two connections without changing the messages. Once active, a tunnel is not considered a party 978 to the HTTP communication, though the tunnel might have been initiated by an HTTP request. A tunnel ceases to exist when both 979 ends of the relayed connection are closed. Tunnels are used to extend a virtual connection through an intermediary, such as 980 when transport-layer security is used to establish private communication through a shared firewall proxy. 985 981 </p> 986 982 <p id="rfc.section.2.3.p.10"><span id="rfc.iref.i.3"></span><span id="rfc.iref.t.3"></span> <span id="rfc.iref.c.3"></span> In addition, there may exist network intermediaries that are not considered part of the HTTP communication but nevertheless 987 983 act as filters or redirecting agents (usually violating HTTP semantics, causing security problems, and otherwise making a 988 mess of things). Such a network intermediary, often referred to as an " interception proxy" <a href="#RFC3040" id="rfc.xref.RFC3040.1"><cite title="Internet Web Replication and Caching Taxonomy">[RFC3040]</cite></a>, "transparent proxy" <a href="#RFC1919" id="rfc.xref.RFC1919.1"><cite title="Classical versus Transparent IP Proxies">[RFC1919]</cite></a>, or "captive portal", differs from an HTTP proxy because it has not been selected by the client. Instead, the network intermediary989 redirects outgoing TCP port 80 packets (and occasionally other common port traffic) to an internal HTTP server. Interception990 proxies are commonly found on public network access points, as a means of enforcing account subscription prior to allowing991 use ofnon-local Internet services, and within corporate firewalls to enforce network usage policies. They are indistinguishable984 mess of things). Such a network intermediary, often referred to as an "<dfn>interception proxy</dfn>" <a href="#RFC3040" id="rfc.xref.RFC3040.1"><cite title="Internet Web Replication and Caching Taxonomy">[RFC3040]</cite></a>, "<dfn>transparent proxy</dfn>" <a href="#RFC1919" id="rfc.xref.RFC1919.1"><cite title="Classical versus Transparent IP Proxies">[RFC1919]</cite></a>, or "<dfn>captive portal</dfn>", differs from an HTTP proxy because it has not been selected by the client. Instead, the network intermediary redirects 985 outgoing TCP port 80 packets (and occasionally other common port traffic) to an internal HTTP server. Interception proxies 986 are commonly found on public network access points, as a means of enforcing account subscription prior to allowing use of 987 non-local Internet services, and within corporate firewalls to enforce network usage policies. They are indistinguishable 992 988 from a man-in-the-middle attack. 993 989 </p> 994 990 <div id="rfc.iref.c.4"></div> 995 991 <h2 id="rfc.section.2.4"><a href="#rfc.section.2.4">2.4</a> <a id="caches" href="#caches">Caches</a></h2> 996 <p id="rfc.section.2.4.p.1">A " cache" is a local store of previous response messages and the subsystem that controls its message storage, retrieval, and997 deletion. A cache stores cacheable responses in order to reduce the response time and network bandwidth consumption on future,998 equivalentrequests. Any client or server <em class="bcp14">MAY</em> employ a cache, though a cache cannot be used by a server while it is acting as a tunnel.992 <p id="rfc.section.2.4.p.1">A "<dfn>cache</dfn>" is a local store of previous response messages and the subsystem that controls its message storage, retrieval, and deletion. 993 A cache stores cacheable responses in order to reduce the response time and network bandwidth consumption on future, equivalent 994 requests. Any client or server <em class="bcp14">MAY</em> employ a cache, though a cache cannot be used by a server while it is acting as a tunnel. 999 995 </p> 1000 996 <p id="rfc.section.2.4.p.2">The effect of a cache is that the request/response chain is shortened if one of the participants along the chain has a cached … … 1005 1001 UA =========== A =========== B - - - - - - C - - - - - - O 1006 1002 < < 1007 </pre><p id="rfc.section.2.4.p.4"><span id="rfc.iref.c.5"></span> A response is "cacheable" if a cache is allowed to store a copy of the response message for use in answering subsequent requests. 1008 Even when a response is cacheable, there might be additional constraints placed by the client or by the origin server on when 1009 that cached response can be used for a particular request. HTTP requirements for cache behavior and cacheable responses are 1010 defined in <a href="p6-cache.html#caching.overview" title="Cache Operation">Section 2</a> of <a href="#Part6" id="rfc.xref.Part6.1"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>. 1003 </pre><p id="rfc.section.2.4.p.4"><span id="rfc.iref.c.5"></span> A response is "<dfn>cacheable</dfn>" if a cache is allowed to store a copy of the response message for use in answering subsequent requests. Even when a response 1004 is cacheable, there might be additional constraints placed by the client or by the origin server on when that cached response 1005 can be used for a particular request. HTTP requirements for cache behavior and cacheable responses are defined in <a href="p6-cache.html#caching.overview" title="Cache Operation">Section 2</a> of <a href="#Part6" id="rfc.xref.Part6.1"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>. 1011 1006 </p> 1012 1007 <p id="rfc.section.2.4.p.5">There are a wide variety of architectures and configurations of caches and proxies deployed across the World Wide Web and … … 1074 1069 for the changes introduced between <a href="#RFC2068" id="rfc.xref.RFC2068.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a> and <a href="#RFC2616" id="rfc.xref.RFC2616.2"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>, and this revision is specifically avoiding any such changes to the protocol. 1075 1070 </p> 1076 <div id="rfc.iref.r. 4"></div>1071 <div id="rfc.iref.r.5"></div> 1077 1072 <h2 id="rfc.section.2.6"><a href="#rfc.section.2.6">2.6</a> <a id="uri" href="#uri">Uniform Resource Identifiers</a></h2> 1078 1073 <p id="rfc.section.2.6.p.1">Uniform Resource Identifiers (URIs) <a href="#RFC3986" id="rfc.xref.RFC3986.2"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a> are used throughout HTTP as the means for identifying resources. URI references are used to target requests, indicate redirects, … … 3845 3840 </li> 3846 3841 <li><a id="rfc.index.R" href="#rfc.index.R"><b>R</b></a><ul> 3847 <li>request <a href="#rfc.iref.r.1"><b>2.1</b></a></li> 3848 <li>resource <a href="#rfc.iref.r.4"><b>2.6</b></a></li> 3849 <li>response <a href="#rfc.iref.r.2"><b>2.1</b></a></li> 3850 <li>reverse proxy <a href="#rfc.iref.r.3"><b>2.3</b></a></li> 3842 <li>recipient <a href="#rfc.iref.r.1"><b>2.1</b></a></li> 3843 <li>request <a href="#rfc.iref.r.2"><b>2.1</b></a></li> 3844 <li>resource <a href="#rfc.iref.r.5"><b>2.6</b></a></li> 3845 <li>response <a href="#rfc.iref.r.3"><b>2.1</b></a></li> 3846 <li>reverse proxy <a href="#rfc.iref.r.4"><b>2.3</b></a></li> 3851 3847 <li><em>RFC1123</em> <a href="#rfc.xref.RFC1123.1">6.1</a>, <a href="#rfc.xref.RFC1123.2">6.1</a>, <a href="#RFC1123"><b>13.2</b></a><ul> 3852 3848 <li><em>Section 5.2.14</em> <a href="#rfc.xref.RFC1123.2">6.1</a></li> … … 3913 3909 </li> 3914 3910 <li><a id="rfc.index.S" href="#rfc.index.S"><b>S</b></a><ul> 3911 <li>sender <a href="#rfc.iref.s.3"><b>2.1</b></a></li> 3915 3912 <li>server <a href="#rfc.iref.s.1"><b>2.1</b></a></li> 3916 3913 <li><em>Spe</em> <a href="#rfc.xref.Spe.1">7.1.1</a>, <a href="#Spe"><b>13.2</b></a></li> -
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.