Changeset 900

Timestamp:

Jul 23, 2010, 11:35:53 PM (9 years ago)

Author:

fielding@…

Message:

regenerate html

Location:

draft-ietf-httpbis/latest

Files:

• p1-messaging.html (modified) (8 diffs)
• p2-semantics.html (modified) (1 diff)
• p6-cache.html (modified) (1 diff)

draft-ietf-httpbis/latest/p1-messaging.html

@@ -376 +376 @@
       <link rel="Index" href="#rfc.index">
       <link rel="Chapter" title="1 Introduction" href="#rfc.section.1">
-      <link rel="Chapter" title="2 HTTP architecture" href="#rfc.section.2">
+      <link rel="Chapter" title="2 HTTP-related architecture" href="#rfc.section.2">
       <link rel="Chapter" title="3 HTTP Message" href="#rfc.section.3">
       <link rel="Chapter" title="4 Request" href="#rfc.section.4">
@@ -544 +544 @@
             </ul>
          </li>
-         <li class="tocline0">2.&nbsp;&nbsp;&nbsp;<a href="#architecture">HTTP architecture</a><ul class="toc">
-               <li class="tocline1">2.1&nbsp;&nbsp;&nbsp;<a href="#operation">Client/Server Operation</a></li>
+         <li class="tocline0">2.&nbsp;&nbsp;&nbsp;<a href="#architecture">HTTP-related architecture</a><ul class="toc">
+               <li class="tocline1">2.1&nbsp;&nbsp;&nbsp;<a href="#operation">Client/Server Messaging</a></li>
                <li class="tocline1">2.2&nbsp;&nbsp;&nbsp;<a href="#intermediaries">Intermediaries</a></li>
                <li class="tocline1">2.3&nbsp;&nbsp;&nbsp;<a href="#caches">Caches</a></li>
@@ -863 +863 @@
   <a href="#abnf.dependencies" class="smpl">Pragma</a>          = &lt;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>&gt;
   <a href="#abnf.dependencies" class="smpl">Warning</a>         = &lt;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>&gt;
-</pre><h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a>&nbsp;<a id="architecture" href="#architecture">HTTP architecture</a></h1>
+</pre><h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a>&nbsp;<a id="architecture" href="#architecture">HTTP-related architecture</a></h1>
       <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
          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>
       <div id="rfc.iref.c.2"></div>
-      <h2 id="rfc.section.2.1"><a href="#rfc.section.2.1">2.1</a>&nbsp;<a id="operation" href="#operation">Client/Server Operation</a></h2>
-      <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.
-         An HTTP client is a program that establishes a connection to a server for the purpose of sending one or more HTTP requests.
-         An HTTP server is a program that accepts connections in order to service HTTP requests by sending HTTP responses.
+      <h2 id="rfc.section.2.1"><a href="#rfc.section.2.1">2.1</a>&nbsp;<a id="operation" href="#operation">Client/Server Messaging</a></h2>
+      <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
+         connection. An HTTP "client" is a program that establishes a connection to a server for the purpose of sending one or more
+         HTTP requests. An HTTP "server" is a program that accepts connections in order to service HTTP requests by sending HTTP responses.
       </p>
       <div id="rfc.iref.u.1"></div>
       <div id="rfc.iref.o.1"></div>
-      <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 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 program that initiates a request, such as a WWW browser, editor, or spider (web-traversing robot), and the term "origin
-         server" to refer to the program that can originate authoritative responses to a request.
+      <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
+         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
+         program that initiates a request, such as a WWW browser, editor, or spider (web-traversing robot), and the term "origin server"
+         to refer to the program that can originate authoritative responses to a request.
       </p>
       <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
-         the simplest case, this may be accomplished via a single connection (v) between the user agent (UA) and the origin server
-         (O).
-      </p>
-      <div id="rfc.figure.u.15"></div><pre class="drawing">       request chain ------------------------&gt;
-    UA -------------------v------------------- O
-       &lt;----------------------- response chain
+         the simplest case, this may be accomplished via a single bidirectional connection (===) between the user agent (UA) and the
+         origin server (O).
+      </p>
+      <div id="rfc.figure.u.15"></div><pre class="drawing">         request   &gt;
+    UA ======================================= O
+                                &lt;   response
 </pre><div id="rfc.iref.m.1"></div>
       <div id="rfc.iref.r.1"></div>
@@ -924 +924 @@
          proxy, gateway, or tunnel, switching behavior based on the nature of each request.
       </p>
-      <div id="rfc.figure.u.18"></div><pre class="drawing">       request chain --------------------------------------&gt;
-    UA -----v----- A -----v----- B -----v----- C -----v----- O
-       &lt;------------------------------------- response chain
+      <div id="rfc.figure.u.18"></div><pre class="drawing">         &gt;             &gt;             &gt;             &gt;
+    UA =========== A =========== B =========== C =========== O
+               &lt;             &lt;             &lt;             &lt;
 </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
          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.
       </p>
-      <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 requests
-         for some type(s) of absolute URI and attempt to satisfy those requests via translation through the HTTP interface. Some translations
-         are minimal, such as for proxy requests for "http" URIs, whereas other requests may require translation to and from entirely
-         different application-layer protocols. Proxies are often used to group an organization's HTTP requests through a common intermediary
-         for the sake of security, annotation services, or shared caching.
-      </p>
-      <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 the
-         received requests to the underlying server's protocol. Gateways are often used for load balancing or partitioning HTTP services
-         across multiple machines. Unlike a proxy, a gateway receives requests as if it were the origin server for the requested resource;
-         the requesting client will not be aware that it is communicating with a gateway. A gateway communicates with the client as
-         if the gateway is the origin server and thus is subject to all of the requirements on origin servers for that connection.
+      <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
+         requests for some type(s) of absolute URI and attempt to satisfy those requests via translation through the HTTP interface.
+         Some translations are minimal, such as for proxy requests for "http" URIs, whereas other requests may require translation
+         to and from entirely different application-layer protocols. Proxies are often used to group an organization's HTTP requests
+         through a common intermediary for the sake of security, annotation services, or shared caching.
+      </p>
+      <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
+         the received requests to the underlying server's protocol. Gateways are often used for load balancing or partitioning HTTP
+         services across multiple machines. Unlike a proxy, a gateway receives requests as if it were the origin server for the requested
+         resource; the requesting client will not be aware that it is communicating with a gateway. A gateway communicates with the
+         client as if the gateway is the origin server and thus is subject to all of the requirements on origin servers for that connection.
          A gateway communicates with inbound servers using any protocol it desires, including private extensions to HTTP that are outside
          the scope of this specification.
       </p>
-      <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
+      <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
          a party to the HTTP communication, though the tunnel may have been initiated by an HTTP request. A tunnel ceases to exist
          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>
       <h2 id="rfc.section.2.3"><a href="#rfc.section.2.3">2.3</a>&nbsp;<a id="caches" href="#caches">Caches</a></h2>
-      <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
+      <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"
          is a local store of previous response messages and the subsystem that controls its message storage, retrieval, and deletion.
          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.
       </p>
-      <div id="rfc.figure.u.19"></div><pre class="drawing">          request chain ----------&gt;
-       UA -----v----- A -----v----- B - - - - - - C - - - - - - O
-          &lt;--------- response chain
-</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.
+      <div id="rfc.figure.u.19"></div><pre class="drawing">            &gt;             &gt;
+       UA =========== A =========== B - - - - - - C - - - - - - O
+                  &lt;             &lt;
+</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.
          Even when a response is cacheable, there may be additional constraints placed by the client or by the origin server on when
          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

@@ -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&nbsp;8.5.5</a>).
       </p>
-      <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&nbsp;8.2.2</a>).
+      <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&nbsp;8.2.2</a>).
       </p>
       <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

@@ -1165 +1165 @@
       </p>
       <ul class="empty">
-         <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
-            prevent caching even by caches that have been configured to return stale responses.
+         <li>The no-cache response directive indicates that the response MUST NOT be used to satisfy a subsequent request without successful
+            validation on the origin server. This allows an origin server to prevent a cache from using it to satisfy a request without
+            contacting it, even by caches that have been configured to return stale responses.
          </li>
          <li>If the no-cache response directive specifies one or more field-names, this requirement is limited to the field-values associated