Changeset 900
- Timestamp:
- 24/07/10 06:35:53 (12 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 3 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.html
r881 r900 376 376 <link rel="Index" href="#rfc.index"> 377 377 <link rel="Chapter" title="1 Introduction" href="#rfc.section.1"> 378 <link rel="Chapter" title="2 HTTP architecture" href="#rfc.section.2">378 <link rel="Chapter" title="2 HTTP-related architecture" href="#rfc.section.2"> 379 379 <link rel="Chapter" title="3 HTTP Message" href="#rfc.section.3"> 380 380 <link rel="Chapter" title="4 Request" href="#rfc.section.4"> … … 544 544 </ul> 545 545 </li> 546 <li class="tocline0">2. <a href="#architecture">HTTP architecture</a><ul class="toc">547 <li class="tocline1">2.1 <a href="#operation">Client/Server Operation</a></li>546 <li class="tocline0">2. <a href="#architecture">HTTP-related architecture</a><ul class="toc"> 547 <li class="tocline1">2.1 <a href="#operation">Client/Server Messaging</a></li> 548 548 <li class="tocline1">2.2 <a href="#intermediaries">Intermediaries</a></li> 549 549 <li class="tocline1">2.3 <a href="#caches">Caches</a></li> … … 863 863 <a href="#abnf.dependencies" class="smpl">Pragma</a> = <Pragma, defined in <a href="#Part6" id="rfc.xref.Part6.2"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>, <a href="p6-cache.html#header.pragma" title="Pragma">Section 3.4</a>> 864 864 <a href="#abnf.dependencies" class="smpl">Warning</a> = <Warning, defined in <a href="#Part6" id="rfc.xref.Part6.3"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>, <a href="p6-cache.html#header.warning" title="Warning">Section 3.6</a>> 865 </pre><h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a> <a id="architecture" href="#architecture">HTTP architecture</a></h1>865 </pre><h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a> <a id="architecture" href="#architecture">HTTP-related architecture</a></h1> 866 866 <p id="rfc.section.2.p.1">HTTP was created for the World Wide Web architecture and has evolved over time to support the scalability needs of a worldwide 867 867 hypertext system. Much of that architecture is reflected in the terminology and syntax productions used to define HTTP. … … 870 870 <div id="rfc.iref.s.1"></div> 871 871 <div id="rfc.iref.c.2"></div> 872 <h2 id="rfc.section.2.1"><a href="#rfc.section.2.1">2.1</a> <a id="operation" href="#operation">Client/Server Operation</a></h2>873 <p id="rfc.section.2.1.p.1">HTTP is a request/response protocol that operates by exchanging messages across a reliable transport or session-layer connection.874 An HTTP client is a program that establishes a connection to a server for the purpose of sending one or more HTTP requests.875 An HTTP serveris a program that accepts connections in order to service HTTP requests by sending HTTP responses.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 <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. 876 876 </p> 877 877 <div id="rfc.iref.u.1"></div> 878 878 <div id="rfc.iref.o.1"></div> 879 <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.880 The same program may act as a client on some connections and a server on others. We use the term "user agent" to refer to881 the program that initiates a request, such as a WWW browser, editor, or spider (web-traversing robot), and the term "origin882 server"to refer to the program that can originate authoritative responses to a request.879 <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 880 same program may act as a client on some connections and a server on others. We use the term "user agent" to refer to the 881 program that initiates a request, such as a WWW browser, editor, or spider (web-traversing robot), and the term "origin server" 882 to refer to the program that can originate authoritative responses to a request. 883 883 </p> 884 884 <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 885 the simplest case, this may be accomplished via a single connection (v) between the user agent (UA) and the origin server886 (O).887 </p> 888 <div id="rfc.figure.u.15"></div><pre class="drawing"> request chain ------------------------>889 UA -------------------v-------------------O890 <----------------------- response chain885 the simplest case, this may be accomplished via a single bidirectional connection (===) between the user agent (UA) and the 886 origin server (O). 887 </p> 888 <div id="rfc.figure.u.15"></div><pre class="drawing"> request > 889 UA ======================================= O 890 < response 891 891 </pre><div id="rfc.iref.m.1"></div> 892 892 <div id="rfc.iref.r.1"></div> … … 924 924 proxy, gateway, or tunnel, switching behavior based on the nature of each request. 925 925 </p> 926 <div id="rfc.figure.u.18"></div><pre class="drawing"> request chain -------------------------------------->927 UA -----v----- A -----v----- B -----v----- C -----v-----O928 <------------------------------------- response chain926 <div id="rfc.figure.u.18"></div><pre class="drawing"> > > > > 927 UA =========== A =========== B =========== C =========== O 928 < < < < 929 929 </pre><p id="rfc.section.2.2.p.3">The figure above shows three intermediaries (A, B, and C) between the user agent and origin server. A request or response 930 930 message that travels the whole chain will pass through four separate connections. Some HTTP communication options may apply … … 938 938 in relation to the request path: "inbound" means toward the origin server and "outbound" means toward the user agent. 939 939 </p> 940 <p id="rfc.section.2.2.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 requests941 for some type(s) of absolute URI and attempt to satisfy those requests via translation through the HTTP interface. Some translations942 are minimal, such as for proxy requests for "http" URIs, whereas other requests may require translation to and from entirely943 different application-layer protocols. Proxies are often used to group an organization's HTTP requests through a common intermediary944 for the sake of security, annotation services, or shared caching.945 </p> 946 <p id="rfc.section.2.2.p.6"><span id="rfc.iref.g.24"></span><span id="rfc.iref.r.3"></span> A gateway (a.k.a., reverse proxy) is a receiving agent that acts as a layer above some other server(s) and translates the947 received requests to the underlying server's protocol. Gateways are often used for load balancing or partitioning HTTP services948 across multiple machines. Unlike a proxy, a gateway receives requests as if it were the origin server for the requested resource;949 the requesting client will not be aware that it is communicating with a gateway. A gateway communicates with the client as950 if the gateway is the origin server and thus is subject to all of the requirements on origin servers for that connection.940 <p id="rfc.section.2.2.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 941 requests for some type(s) of absolute URI and attempt to satisfy those requests via translation through the HTTP interface. 942 Some translations are minimal, such as for proxy requests for "http" URIs, whereas other requests may require translation 943 to and from entirely different application-layer protocols. Proxies are often used to group an organization's HTTP requests 944 through a common intermediary for the sake of security, annotation services, or shared caching. 945 </p> 946 <p id="rfc.section.2.2.p.6"><span id="rfc.iref.g.24"></span><span id="rfc.iref.r.3"></span> A "gateway" (a.k.a., "reverse proxy") is a receiving agent that acts as a layer above some other server(s) and translates 947 the received requests to the underlying server's protocol. Gateways are often used for load balancing or partitioning HTTP 948 services across multiple machines. Unlike a proxy, a gateway receives requests as if it were the origin server for the requested 949 resource; the requesting client will not be aware that it is communicating with a gateway. A gateway communicates with the 950 client as if the gateway is the origin server and thus is subject to all of the requirements on origin servers for that connection. 951 951 A gateway communicates with inbound servers using any protocol it desires, including private extensions to HTTP that are outside 952 952 the scope of this specification. 953 953 </p> 954 <p id="rfc.section.2.2.p.7"><span id="rfc.iref.t.1"></span> A tunnelacts as a blind relay between two connections without changing the messages. Once active, a tunnel is not considered954 <p id="rfc.section.2.2.p.7"><span id="rfc.iref.t.1"></span> A "tunnel" acts as a blind relay between two connections without changing the messages. Once active, a tunnel is not considered 955 955 a party to the HTTP communication, though the tunnel may have been initiated by an HTTP request. A tunnel ceases to exist 956 956 when both ends of the relayed connection are closed. Tunnels are used to extend a virtual connection through an intermediary, … … 959 959 <div id="rfc.iref.c.3"></div> 960 960 <h2 id="rfc.section.2.3"><a href="#rfc.section.2.3">2.3</a> <a id="caches" href="#caches">Caches</a></h2> 961 <p id="rfc.section.2.3.p.1">Any party to HTTP communication that is not acting as a tunnel may employ an internal cache for handling requests. A cache961 <p id="rfc.section.2.3.p.1">Any party to HTTP communication that is not acting as a tunnel may employ an internal cache for handling requests. A "cache" 962 962 is a local store of previous response messages and the subsystem that controls its message storage, retrieval, and deletion. 963 963 A cache stores cacheable responses in order to reduce the response time and network bandwidth consumption on future, equivalent … … 968 968 from O (via C) for a request which has not been cached by UA or A. 969 969 </p> 970 <div id="rfc.figure.u.19"></div><pre class="drawing"> request chain ---------->971 UA -----v----- A -----v-----B - - - - - - C - - - - - - O972 <--------- response chain973 </pre><p id="rfc.section.2.3.p.4"><span id="rfc.iref.c.4"></span> A response is cacheableif a cache is allowed to store a copy of the response message for use in answering subsequent requests.970 <div id="rfc.figure.u.19"></div><pre class="drawing"> > > 971 UA =========== A =========== B - - - - - - C - - - - - - O 972 < < 973 </pre><p id="rfc.section.2.3.p.4"><span id="rfc.iref.c.4"></span> A response is "cacheable" if a cache is allowed to store a copy of the response message for use in answering subsequent requests. 974 974 Even when a response is cacheable, there may be additional constraints placed by the client or by the origin server on when 975 975 that cached response can be used for a particular request. HTTP requirements for cache behavior and cacheable responses are -
draft-ietf-httpbis/latest/p2-semantics.html
r895 r900 2257 2257 <p id="rfc.section.A.1.p.1">Clarified which error code should be used for inbound server failures (e.g., DNS failures). (<a href="#status.504" id="rfc.xref.status.504.3" title="504 Gateway Timeout">Section 8.5.5</a>). 2258 2258 </p> 2259 <p id="rfc.section.A.1.p.2">201 (Created) had a race that required an E tag be sent when a resource is first created. (<a href="#status.201" id="rfc.xref.status.201.3" title="201 Created">Section 8.2.2</a>).2259 <p id="rfc.section.A.1.p.2">201 (Created) had a race that required an ETag be sent when a resource is first created. (<a href="#status.201" id="rfc.xref.status.201.3" title="201 Created">Section 8.2.2</a>). 2260 2260 </p> 2261 2261 <p id="rfc.section.A.1.p.3">303 (See Also) and 307 (Temporary Redirect) added to address user agent failure to implement status code 302 properly. (Section <a href="#status.303" id="rfc.xref.status.303.4" title="303 See Other">8.3.4</a> and <a href="#status.307" id="rfc.xref.status.307.4" title="307 Temporary Redirect">8.3.8</a>) -
draft-ietf-httpbis/latest/p6-cache.html
r892 r900 1165 1165 </p> 1166 1166 <ul class="empty"> 1167 <li>The no-cache response directive indicates that the response <em class="bcp14">MUST NOT</em> be used to satisfy a subsequent request without successful validation on the origin server. This allows an origin server to 1168 prevent caching even by caches that have been configured to return stale responses. 1167 <li>The no-cache response directive indicates that the response MUST NOT be used to satisfy a subsequent request without successful 1168 validation on the origin server. This allows an origin server to prevent a cache from using it to satisfy a request without 1169 contacting it, even by caches that have been configured to return stale responses. 1169 1170 </li> 1170 1171 <li>If the no-cache response directive specifies one or more field-names, this requirement is limited to the field-values associated
Note: See TracChangeset
for help on using the changeset viewer.