Changeset 1174

Timestamp:

13/03/11 11:39:51 (11 years ago)

Author:

fielding@…

Message:

generate HTML

Location:

draft-ietf-httpbis/latest

Files:

• p1-messaging.html (modified) (15 diffs)
• p2-semantics.html (modified) (7 diffs)
• p3-payload.html (modified) (6 diffs)
• p6-cache.html (modified) (7 diffs)

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

@@ -359 +359 @@
   } 
   @bottom-center {
-       content: "Expires September 13, 2011"; 
+       content: "Expires September 14, 2011"; 
   } 
   @bottom-right {
@@ -410 +410 @@
       <meta name="dct.creator" content="Reschke, J. F.">
       <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p1-messaging-latest">
-      <meta name="dct.issued" scheme="ISO8601" content="2011-03-12">
+      <meta name="dct.issued" scheme="ISO8601" content="2011-03-13">
       <meta name="dct.replaces" content="urn:ietf:rfc:2145">
       <meta name="dct.replaces" content="urn:ietf:rfc:2616">
@@ -442 +442 @@
             </tr>
             <tr>
-               <td class="left">Expires: September 13, 2011</td>
+               <td class="left">Expires: September 14, 2011</td>
                <td class="right">HP</td>
             </tr>
@@ -495 +495 @@
             <tr>
                <td class="left"></td>
-               <td class="right">March 12, 2011</td>
+               <td class="right">March 13, 2011</td>
             </tr>
          </tbody>
@@ -523 +523 @@
          in progress”.
       </p>
-      <p>This Internet-Draft will expire on September 13, 2011.</p>
+      <p>This Internet-Draft will expire on September 14, 2011.</p>
       <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
       <p>Copyright © 2011 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
@@ -970 +970 @@
       <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
          the received requests to the underlying server's protocol. Gateways are often used for load balancing, "accelerator" caching,
-         or partitioning HTTP services across multiple machines. Unlike a proxy, a gateway receives requests as if it were the origin
-         server for the target 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.
+         or partitioning HTTP services across multiple machines. Gateways behave as an origin server on the outbound connection and
+         as a proxy on the inbound connection. All HTTP requirements applicable to an origin server also apply to the outbound communication
+         of a gateway. A gateway communicates with inbound servers using any protocol it desires, including private extensions to HTTP
+         that are outside the scope of this specification. However, an HTTP-to-HTTP gateway that wishes to interoperate with third-party
+         HTTP servers <em class="bcp14">SHOULD</em> comply with HTTP proxy requirements on the gateway's inbound connection.
       </p>
       <p id="rfc.section.2.3.p.8"><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 considered
@@ -1308 +1308 @@
          <li>
             <p>If a message is received without Transfer-Encoding and with either multiple Content-Length header fields having differing
-               field-values or a single Content-Length header field having an invalid value, then the message framing is invalid and <em class="bcp14">MUST</em> be treated as an error to prevent request or response smuggling. If this is a request message, the server <em class="bcp14">MUST</em> respond with a 400 (Bad Request) status code and then close the connection. If this is a response message received by a proxy
-               or gateway, the proxy or gateway <em class="bcp14">MUST</em> discard the received response, send a 502 (Bad Gateway) status code as its downstream response, and then close the connection.
+               field-values or a single Content-Length header field having an invalid value, then the message framing is invalid and <em class="bcp14">MUST</em> be treated as an error to prevent request or response smuggling. If this is a request message, the server <em class="bcp14">MUST</em> respond with a 400 (Bad Request) status code and then close the connection. If this is a response message received by a proxy,
+               the proxy <em class="bcp14">MUST</em> discard the received response, send a 502 (Bad Gateway) status code as its downstream response, and then close the connection.
                If this is a response message received by a user-agent, it <em class="bcp14">MUST</em> be treated as an error by discarding the message and closing the connection.
             </p>
@@ -1433 +1433 @@
       <p id="rfc.section.4.1.2.p.10"><span id="rfc.iref.a.4"></span> The "authority form" is only used by the CONNECT request method (<a href="p2-semantics.html#CONNECT" title="CONNECT">Section 7.9</a> of <a href="#Part2" id="rfc.xref.Part2.1"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).
       </p>
-      <p id="rfc.section.4.1.2.p.11"><span id="rfc.iref.o.3"></span> The most common form of request-target is that used when making a request to an origin server or gateway ("origin form").
-         In this case, the absolute path and query components of the URI <em class="bcp14">MUST</em> be transmitted as the request-target, and the authority component <em class="bcp14">MUST</em> be transmitted in a Host header field. For example, a client wishing to retrieve a representation of the resource, as identified
+      <p id="rfc.section.4.1.2.p.11"><span id="rfc.iref.o.3"></span> The most common form of request-target is that used when making a request to an origin server ("origin form"). In this case,
+         the absolute path and query components of the URI <em class="bcp14">MUST</em> be transmitted as the request-target, and the authority component <em class="bcp14">MUST</em> be transmitted in a Host header field. For example, a client wishing to retrieve a representation of the resource, as identified
          above, directly from the origin server would open (or reuse) a TCP connection to port 80 of the host "www.example.org" and
          send the lines:
@@ -1818 +1818 @@
       <h2 id="rfc.section.7.1"><a href="#rfc.section.7.1">7.1</a>&nbsp;<a id="persistent.connections" href="#persistent.connections">Persistent Connections</a></h2>
       <h3 id="rfc.section.7.1.1"><a href="#rfc.section.7.1.1">7.1.1</a>&nbsp;<a id="persistent.purpose" href="#persistent.purpose">Purpose</a></h3>
-      <p id="rfc.section.7.1.1.p.1">Prior to persistent connections, a separate TCP connection was established to fetch each URL, increasing the load on HTTP
-         servers and causing congestion on the Internet. The use of inline images and other associated data often requires a client
-         to make multiple requests of the same server in a short amount of time. Analysis of these performance problems and results
-         from a prototype implementation are available <a href="#Pad1995" id="rfc.xref.Pad1995.1"><cite title="Improving HTTP Latency">[Pad1995]</cite></a>  <a href="#Spe" id="rfc.xref.Spe.1"><cite title="Analysis of HTTP Performance Problems">[Spe]</cite></a>. Implementation experience and measurements of actual HTTP/1.1 implementations show good results <a href="#Nie1997" id="rfc.xref.Nie1997.1"><cite title="Network Performance Effects of HTTP/1.1, CSS1, and PNG">[Nie1997]</cite></a>. Alternatives have also been explored, for example, T/TCP <a href="#Tou1998" id="rfc.xref.Tou1998.1"><cite title="Analysis of HTTP Performance">[Tou1998]</cite></a>.
+      <p id="rfc.section.7.1.1.p.1">Prior to persistent connections, a separate TCP connection was established for each request, increasing the load on HTTP servers
+         and causing congestion on the Internet. The use of inline images and other associated data often requires a client to make
+         multiple requests of the same server in a short amount of time. Analysis of these performance problems and results from a
+         prototype implementation are available <a href="#Pad1995" id="rfc.xref.Pad1995.1"><cite title="Improving HTTP Latency">[Pad1995]</cite></a>  <a href="#Spe" id="rfc.xref.Spe.1"><cite title="Analysis of HTTP Performance Problems">[Spe]</cite></a>. Implementation experience and measurements of actual HTTP/1.1 implementations show good results <a href="#Nie1997" id="rfc.xref.Nie1997.1"><cite title="Network Performance Effects of HTTP/1.1, CSS1, and PNG">[Nie1997]</cite></a>. Alternatives have also been explored, for example, T/TCP <a href="#Tou1998" id="rfc.xref.Tou1998.1"><cite title="Analysis of HTTP Performance">[Tou1998]</cite></a>.
       </p>
       <p id="rfc.section.7.1.1.p.2">Persistent HTTP connections have a number of advantages: </p>
@@ -2149 +2149 @@
          </li>
       </ol>
-      <p id="rfc.section.9.3.p.6">A received message that does not have a Date header field <em class="bcp14">MUST</em> be assigned one by the recipient if the message will be cached by that recipient or gatewayed via a protocol which requires
-         a Date.
+      <p id="rfc.section.9.3.p.6">A received message that does not have a Date header field <em class="bcp14">MUST</em> be assigned one by the recipient if the message will be cached by that recipient.
       </p>
       <p id="rfc.section.9.3.p.7">Clients can use the Date header field as well; in order to keep request messages small, they are advised not to include it
@@ -2168 +2167 @@
       <div id="rfc.iref.h.10"></div>
       <h2 id="rfc.section.9.4"><a href="#rfc.section.9.4">9.4</a>&nbsp;<a id="header.host" href="#header.host">Host</a></h2>
-      <p id="rfc.section.9.4.p.1">The "Host" header field specifies the Internet host and port number of the resource being requested, allowing the origin server
-         or gateway to differentiate between internally-ambiguous URLs, such as the root "/" URL of a server for multiple host names
-         on a single IP address.
-      </p>
-      <p id="rfc.section.9.4.p.2">The Host field value <em class="bcp14">MUST</em> represent the naming authority of the origin server or gateway given by the original URL obtained from the user or referring
-         resource (generally an http URI, as described in <a href="#http.uri" title="http URI scheme">Section&nbsp;2.6.1</a>).
+      <p id="rfc.section.9.4.p.1">The "Host" header field in a request provides the host and port information from the target resource's URI, enabling the origin
+         server to distinguish between resources while servicing requests for multiple host names on a single IP address. Since the
+         Host field-value is critical information for handling a request, it <em class="bcp14">SHOULD</em> be sent as the first header field following the Request-Line.
       </p>
       <div id="rfc.figure.u.61"></div><pre class="inline"><span id="rfc.iref.g.98"></span><span id="rfc.iref.g.99"></span>  <a href="#header.host" class="smpl">Host</a>   = "Host" ":" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#header.host" class="smpl">Host-v</a>
   <a href="#header.host" class="smpl">Host-v</a> = <a href="#uri" class="smpl">uri-host</a> [ ":" <a href="#uri" class="smpl">port</a> ] ; <a href="#http.uri" title="http URI scheme">Section&nbsp;2.6.1</a>
-</pre><p id="rfc.section.9.4.p.4">A "host" without any trailing port information implies the default port for the service requested (e.g., "80" for an HTTP
-         URL). For example, a request on the origin server for &lt;http://www.example.org/pub/WWW/&gt; would properly include:
-      </p>
+</pre><p id="rfc.section.9.4.p.3">A client <em class="bcp14">MUST</em> send a Host header field in all HTTP/1.1 request messages. If the target resource's URI includes an authority component, then
+         the Host field-value <em class="bcp14">MUST</em> be identical to that authority component after excluding any userinfo (<a href="#http.uri" title="http URI scheme">Section&nbsp;2.6.1</a>). If the authority component is missing or undefined for the target resource's URI, then the Host header field <em class="bcp14">MUST</em> be sent with an empty field-value.
+      </p>
+      <p id="rfc.section.9.4.p.4">For example, a GET request to the origin server for &lt;http://www.example.org/pub/WWW/&gt; would begin with:</p>
       <div id="rfc.figure.u.62"></div><pre class="text2">GET /pub/WWW/ HTTP/1.1
 Host: www.example.org
-</pre><p id="rfc.section.9.4.p.6">A client <em class="bcp14">MUST</em> include a Host header field in all HTTP/1.1 request messages. If the requested URI does not include an Internet host name
-         for the service being requested, then the Host header field <em class="bcp14">MUST</em> be given with an empty value. An HTTP/1.1 proxy <em class="bcp14">MUST</em> ensure that any request message it forwards does contain an appropriate Host header field that identifies the service being
-         requested by the proxy. All Internet-based HTTP/1.1 servers <em class="bcp14">MUST</em> respond with a 400 (Bad Request) status code to any HTTP/1.1 request message which lacks a Host header field.
-      </p>
-      <p id="rfc.section.9.4.p.7">See Sections <a href="#the.resource.identified.by.a.request" title="The Resource Identified by a Request">4.2</a> and <a href="#changes.to.simplify.multi-homed.web.servers.and.conserve.ip.addresses" title="Changes to Simplify Multi-homed Web Servers and Conserve IP Addresses">B.1.1</a> for other requirements relating to Host.
+</pre><p id="rfc.section.9.4.p.6">The Host header field <em class="bcp14">MUST</em> be sent in an HTTP/1.1 request even if the request-target is in the form of an absolute-URI, since this allows the Host information
+         to be forwarded through ancient HTTP/1.0 proxies that might not have implemented Host.
+      </p>
+      <p id="rfc.section.9.4.p.7">When an HTTP/1.1 proxy receives a request with a request-target in the form of an absolute-URI, the proxy <em class="bcp14">MUST</em> ignore the received Host header field (if any) and instead replace it with the host information of the request-target. When
+         a proxy forwards a request, it <em class="bcp14">MUST</em> generate the Host header field based on the received absolute-URI rather than the received Host.
+      </p>
+      <p id="rfc.section.9.4.p.8">Since the Host header field acts as an application-level routing mechanism, it is a frequent target for malware seeking to
+         poison a shared cache or redirect a request to an unintended server. An interception proxy is particularly vulnerable if it
+         relies on the Host header field value for redirecting requests to internal servers, or for use as a cache key in a shared
+         cache, without first verifying that the intercepted connection is targeting a valid IP address for that host.
+      </p>
+      <p id="rfc.section.9.4.p.9">A server <em class="bcp14">MUST</em> respond with a 400 (Bad Request) status code to any HTTP/1.1 request message that lacks a Host header field and to any request
+         message that contains more than one Host header field or a Host header field with an invalid field-value.
+      </p>
+      <p id="rfc.section.9.4.p.10">See Sections <a href="#the.resource.identified.by.a.request" title="The Resource Identified by a Request">4.2</a> and <a href="#changes.to.simplify.multi-homed.web.servers.and.conserve.ip.addresses" title="Changes to Simplify Multi-homed Web Servers and Conserve IP Addresses">B.1.1</a> for other requirements relating to Host.
       </p>
       <div id="rfc.iref.t.5"></div>
@@ -2332 +2339 @@
       <div id="rfc.iref.h.15"></div>
       <h2 id="rfc.section.9.9"><a href="#rfc.section.9.9">9.9</a>&nbsp;<a id="header.via" href="#header.via">Via</a></h2>
-      <p id="rfc.section.9.9.p.1">The "Via" header field <em class="bcp14">MUST</em> be used by gateways and proxies to indicate the intermediate protocols and recipients between the user agent and the server
-         on requests, and between the origin server and the client on responses. It is analogous to the "Received" field defined in <a href="http://tools.ietf.org/html/rfc5322#section-3.6.7">Section 3.6.7</a> of <a href="#RFC5322" id="rfc.xref.RFC5322.5"><cite title="Internet Message Format">[RFC5322]</cite></a> and is intended to be used for tracking message forwards, avoiding request loops, and identifying the protocol capabilities
+      <p id="rfc.section.9.9.p.1">The "Via" header field <em class="bcp14">MUST</em> be sent by proxies to indicate the intermediate protocols and recipients between the user agent and the server on requests,
+         and between the origin server and the client on responses. It is analogous to the "Received" field defined in <a href="http://tools.ietf.org/html/rfc5322#section-3.6.7">Section 3.6.7</a> of <a href="#RFC5322" id="rfc.xref.RFC5322.5"><cite title="Internet Message Format">[RFC5322]</cite></a> and is intended to be used for tracking message forwards, avoiding request loops, and identifying the protocol capabilities
          of all senders along the request/response chain.
       </p>
@@ -2352 +2359 @@
          be sensitive information, it <em class="bcp14">MAY</em> be replaced by a pseudonym. If the port is not given, it <em class="bcp14">MAY</em> be assumed to be the default port of the received-protocol.
       </p>
-      <p id="rfc.section.9.9.p.5">Multiple Via field values represent each proxy or gateway that has forwarded the message. Each recipient <em class="bcp14">MUST</em> append its information such that the end result is ordered according to the sequence of forwarding applications.
-      </p>
-      <p id="rfc.section.9.9.p.6">Comments <em class="bcp14">MAY</em> be used in the Via header field to identify the software of the recipient proxy or gateway, analogous to the User-Agent and
-         Server header fields. However, all comments in the Via field are optional and <em class="bcp14">MAY</em> be removed by any recipient prior to forwarding the message.
+      <p id="rfc.section.9.9.p.5">Multiple Via field values represent each proxy that has forwarded the message. Each recipient <em class="bcp14">MUST</em> append its information such that the end result is ordered according to the sequence of forwarding applications.
+      </p>
+      <p id="rfc.section.9.9.p.6">Comments <em class="bcp14">MAY</em> be used in the Via header field to identify the software of the recipient proxy, analogous to the User-Agent and Server header
+         fields. However, all comments in the Via field are optional and <em class="bcp14">MAY</em> be removed by any recipient prior to forwarding the message.
       </p>
       <p id="rfc.section.9.9.p.7">For example, a request message could be sent from an HTTP/1.0 user agent to an internal proxy code-named "fred", which uses
@@ -2362 +2369 @@
       </p>
       <div id="rfc.figure.u.71"></div><pre class="text">  Via: 1.0 fred, 1.1 p.example.net (Apache/1.1)
-</pre><p id="rfc.section.9.9.p.9">Proxies and gateways used as a portal through a network firewall <em class="bcp14">SHOULD NOT</em>, by default, forward the names and ports of hosts within the firewall region. This information <em class="bcp14">SHOULD</em> only be propagated if explicitly enabled. If not enabled, the received-by host of any host behind the firewall <em class="bcp14">SHOULD</em> be replaced by an appropriate pseudonym for that host.
+</pre><p id="rfc.section.9.9.p.9">Proxies used as a portal through a network firewall <em class="bcp14">SHOULD NOT</em>, by default, forward the names and ports of hosts within the firewall region. This information <em class="bcp14">SHOULD</em> only be propagated if explicitly enabled. If not enabled, the received-by host of any host behind the firewall <em class="bcp14">SHOULD</em> be replaced by an appropriate pseudonym for that host.
       </p>
       <p id="rfc.section.9.9.p.10">For organizations that have strong privacy requirements for hiding internal structures, a proxy <em class="bcp14">MAY</em> combine an ordered subsequence of Via header field entries with identical received-protocol values into a single such entry.
@@ -3014 +3021 @@
          address, greatly simplifying large operational Web servers, where allocation of many IP addresses to a single host has created
          serious problems. The Internet will also be able to recover the IP addresses that have been allocated for the sole purpose
-         of allowing special-purpose domain names to be used in root-level HTTP URLs. Given the rate of growth of the Web, and the
-         number of servers already deployed, it is extremely important that all implementations of HTTP (including updates to existing
-         HTTP/1.0 applications) correctly implement these requirements: 
+         of allowing special-purpose domain names to be used. Given the rate of growth of the Web, and the number of servers already
+         deployed, it is extremely important that all implementations of HTTP (including updates to existing HTTP/1.0 applications)
+         correctly implement these requirements: 
       </p>
       <ul>

draft-ietf-httpbis/latest/p2-semantics.html

@@ -359 +359 @@
   } 
   @bottom-center {
-       content: "Expires September 12, 2011"; 
+       content: "Expires September 14, 2011"; 
   } 
   @bottom-right {
@@ -409 +409 @@
       <meta name="dct.creator" content="Reschke, J. F.">
       <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p2-semantics-latest">
-      <meta name="dct.issued" scheme="ISO8601" content="2011-03-11">
+      <meta name="dct.issued" scheme="ISO8601" content="2011-03-13">
       <meta name="dct.replaces" content="urn:ietf:rfc:2616">
       <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 2 of the seven-part specification that defines the protocol referred to as &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 2 defines the semantics of HTTP messages as expressed by request methods, request header fields, response status codes, and response header fields.">
@@ -440 +440 @@
             </tr>
             <tr>
-               <td class="left">Expires: September 12, 2011</td>
+               <td class="left">Expires: September 14, 2011</td>
                <td class="right">HP</td>
             </tr>
@@ -493 +493 @@
             <tr>
                <td class="left"></td>
-               <td class="right">March 11, 2011</td>
+               <td class="right">March 13, 2011</td>
             </tr>
          </tbody>
@@ -520 +520 @@
          in progress”.
       </p>
-      <p>This Internet-Draft will expire on September 12, 2011.</p>
+      <p>This Internet-Draft will expire on September 14, 2011.</p>
       <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
       <p>Copyright © 2011 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
@@ -1462 +1462 @@
       <div id="rfc.iref.m.7"></div>
       <p id="rfc.section.7.8.p.1">The TRACE method requests a remote, application-layer loop-back of the request message. The final recipient of the request <em class="bcp14">SHOULD</em> reflect the message received back to the client as the message-body of a 200 (OK) response. The final recipient is either
-         the origin server or the first proxy or gateway to receive a Max-Forwards value of zero (0) in the request (see <a href="#header.max-forwards" id="rfc.xref.header.max-forwards.3" title="Max-Forwards">Section&nbsp;9.5</a>). A TRACE request <em class="bcp14">MUST NOT</em> include a message-body.
+         the origin server or the first proxy to receive a Max-Forwards value of zero (0) in the request (see <a href="#header.max-forwards" id="rfc.xref.header.max-forwards.3" title="Max-Forwards">Section&nbsp;9.5</a>). A TRACE request <em class="bcp14">MUST NOT</em> include a message-body.
       </p>
       <p id="rfc.section.7.8.p.2">TRACE allows the client to see what is being received at the other end of the request chain and use that data for testing
@@ -2034 +2034 @@
       <div id="rfc.iref.h.6"></div>
       <h2 id="rfc.section.9.5"><a href="#rfc.section.9.5">9.5</a>&nbsp;<a id="header.max-forwards" href="#header.max-forwards">Max-Forwards</a></h2>
-      <p id="rfc.section.9.5.p.1">The "Max-Forwards" header field provides a mechanism with the TRACE (<a href="#TRACE" id="rfc.xref.TRACE.2" title="TRACE">Section&nbsp;7.8</a>) and OPTIONS (<a href="#OPTIONS" id="rfc.xref.OPTIONS.2" title="OPTIONS">Section&nbsp;7.2</a>) methods to limit the number of times that the request is forwarded by proxies or gateways. This can be useful when the client
-         is attempting to trace a request which appears to be failing or looping in mid-chain.
+      <p id="rfc.section.9.5.p.1">The "Max-Forwards" header field provides a mechanism with the TRACE (<a href="#TRACE" id="rfc.xref.TRACE.2" title="TRACE">Section&nbsp;7.8</a>) and OPTIONS (<a href="#OPTIONS" id="rfc.xref.OPTIONS.2" title="OPTIONS">Section&nbsp;7.2</a>) methods to limit the number of times that the request is forwarded by proxies. This can be useful when the client is attempting
+         to trace a request which appears to be failing or looping in mid-chain.
       </p>
       <div id="rfc.figure.u.16"></div><pre class="inline"><span id="rfc.iref.g.17"></span><span id="rfc.iref.g.18"></span>  <a href="#header.max-forwards" class="smpl">Max-Forwards</a>   = "Max-Forwards" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.max-forwards" class="smpl">Max-Forwards-v</a>
   <a href="#header.max-forwards" class="smpl">Max-Forwards-v</a> = 1*<a href="#notation" class="smpl">DIGIT</a>
 </pre><p id="rfc.section.9.5.p.3">The Max-Forwards value is a decimal integer indicating the remaining number of times this request message can be forwarded.</p>
-      <p id="rfc.section.9.5.p.4">Each proxy or gateway recipient of a TRACE or OPTIONS request containing a Max-Forwards header field <em class="bcp14">MUST</em> check and update its value prior to forwarding the request. If the received value is zero (0), the recipient <em class="bcp14">MUST NOT</em> forward the request; instead, it <em class="bcp14">MUST</em> respond as the final recipient. If the received Max-Forwards value is greater than zero, then the forwarded message <em class="bcp14">MUST</em> contain an updated Max-Forwards field with a value decremented by one (1).
+      <p id="rfc.section.9.5.p.4">Each recipient of a TRACE or OPTIONS request containing a Max-Forwards header field <em class="bcp14">MUST</em> check and update its value prior to forwarding the request. If the received value is zero (0), the recipient <em class="bcp14">MUST NOT</em> forward the request; instead, it <em class="bcp14">MUST</em> respond as the final recipient. If the received Max-Forwards value is greater than zero, then the forwarded message <em class="bcp14">MUST</em> contain an updated Max-Forwards field with a value decremented by one (1).
       </p>
       <p id="rfc.section.9.5.p.5">The Max-Forwards header field <em class="bcp14">MAY</em> be ignored for all other request methods.

draft-ietf-httpbis/latest/p3-payload.html

@@ -359 +359 @@
   } 
   @bottom-center {
-       content: "Expires September 12, 2011"; 
+       content: "Expires September 14, 2011"; 
   } 
   @bottom-right {
@@ -408 +408 @@
       <meta name="dct.creator" content="Reschke, J. F.">
       <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p3-payload-latest">
-      <meta name="dct.issued" scheme="ISO8601" content="2011-03-11">
+      <meta name="dct.issued" scheme="ISO8601" content="2011-03-13">
       <meta name="dct.replaces" content="urn:ietf:rfc:2616">
       <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 3 of the seven-part specification that defines the protocol referred to as &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 3 defines HTTP message content, metadata, and content negotiation.">
@@ -434 +434 @@
             </tr>
             <tr>
-               <td class="left">Expires: September 12, 2011</td>
+               <td class="left">Expires: September 14, 2011</td>
                <td class="right">J. Mogul</td>
             </tr>
@@ -491 +491 @@
             <tr>
                <td class="left"></td>
-               <td class="right">March 11, 2011</td>
+               <td class="right">March 13, 2011</td>
             </tr>
          </tbody>
@@ -517 +517 @@
          in progress”.
       </p>
-      <p>This Internet-Draft will expire on September 12, 2011.</p>
+      <p>This Internet-Draft will expire on September 14, 2011.</p>
       <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
       <p>Copyright © 2011 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
@@ -1364 +1364 @@
   <a href="#header.content-md5" class="smpl">Content-MD5-v</a> = &lt;base64 of 128 bit MD5 digest as per <a href="#RFC1864" id="rfc.xref.RFC1864.2"><cite title="The Content-MD5 Header Field">[RFC1864]</cite></a>&gt;
 </pre><p id="rfc.section.6.8.p.3">The Content-MD5 header field <em class="bcp14">MAY</em> be generated by an origin server or client to function as an integrity check of the payload body. Only origin servers or user
-         agents <em class="bcp14">MAY</em> generate the Content-MD5 header field; proxies and gateways <em class="bcp14">MUST NOT</em> generate it, as this would defeat its value as an end-to-end integrity check. Any recipient <em class="bcp14">MAY</em> check that the digest value in this header field matches a corresponding digest calculated on payload body as received.
+         agents <em class="bcp14">MAY</em> generate the Content-MD5 header field; proxies <em class="bcp14">MUST NOT</em> generate it, as this would defeat its value as an end-to-end integrity check. Any recipient <em class="bcp14">MAY</em> check that the digest value in this header field matches a corresponding digest calculated on payload body as received.
       </p>
       <p id="rfc.section.6.8.p.4">The MD5 digest is computed based on the content of the payload body, including any content-coding, but not including any transfer-coding

draft-ietf-httpbis/latest/p6-cache.html

@@ -362 +362 @@
   } 
   @bottom-center {
-       content: "Expires September 12, 2011"; 
+       content: "Expires September 14, 2011"; 
   } 
   @bottom-right {
@@ -408 +408 @@
       <meta name="dct.creator" content="Reschke, J. F.">
       <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p6-cache-latest">
-      <meta name="dct.issued" scheme="ISO8601" content="2011-03-11">
+      <meta name="dct.issued" scheme="ISO8601" content="2011-03-13">
       <meta name="dct.replaces" content="urn:ietf:rfc:2616">
       <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. This document is Part 6 of the seven-part specification that defines the protocol referred to as &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 6 defines requirements on HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages.">
@@ -434 +434 @@
             </tr>
             <tr>
-               <td class="left">Expires: September 12, 2011</td>
+               <td class="left">Expires: September 14, 2011</td>
                <td class="right">J. Mogul</td>
             </tr>
@@ -495 +495 @@
             <tr>
                <td class="left"></td>
-               <td class="right">March 11, 2011</td>
+               <td class="right">March 13, 2011</td>
             </tr>
          </tbody>
@@ -521 +521 @@
          in progress”.
       </p>
-      <p>This Internet-Draft will expire on September 12, 2011.</p>
+      <p>This Internet-Draft will expire on September 14, 2011.</p>
       <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
       <p>Copyright © 2011 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
@@ -862 +862 @@
       </p>
       <div class="note" id="rfc.section.2.3.1.1.p.4"> 
-         <p> <b>Note:</b> RFC 2616 (<a href="#RFC2616" id="rfc.xref.RFC2616.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>, <a href="http://tools.ietf.org/html/rfc2616#section-13.9">Section 13.9</a>) required that caches do not calculate heuristic freshness for URLs with query components (i.e., those containing '?'). In
+         <p> <b>Note:</b> RFC 2616 (<a href="#RFC2616" id="rfc.xref.RFC2616.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>, <a href="http://tools.ietf.org/html/rfc2616#section-13.9">Section 13.9</a>) required that caches do not calculate heuristic freshness for URIs with query components (i.e., those containing '?'). In
             practice, this has not been widely implemented. Therefore, servers are encouraged to send explicit directives (e.g., Cache-Control:
             no-cache) if they wish to preclude caching.
@@ -1068 +1068 @@
          </p> 
       </div>
-      <p id="rfc.section.3.2.p.4">An intermediary (i.e., a proxy or gateway, whether or not it implements a cache) <em class="bcp14">MUST</em> pass cache directives through, regardless of their significance to that application, since the directives might be applicable
-         to all recipients along the request/response chain. It is not possible to target a directive to a specific cache.
+      <p id="rfc.section.3.2.p.4">A proxy, whether or not it implements a cache, <em class="bcp14">MUST</em> pass cache directives through in forwarded messages, regardless of their significance to that application, since the directives
+         might be applicable to all recipients along the request/response chain. It is not possible to target a directive to a specific
+         cache.
       </p>
       <div id="rfc.figure.u.9"></div><pre class="inline"><span id="rfc.iref.g.4"></span><span id="rfc.iref.g.5"></span><span id="rfc.iref.g.6"></span>  <a href="#header.cache-control" class="smpl">Cache-Control</a>   = "Cache-Control" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.cache-control" class="smpl">Cache-Control-v</a>