Changeset 1162

Timestamp:

Mar 10, 2011, 9:42:12 PM (8 years ago)

Author:

fielding@…

Message:

update generated HTML

Location:

draft-ietf-httpbis/latest

Files:

• p1-messaging.html (modified) (12 diffs)
• p2-semantics.html (modified) (16 diffs)
• p3-payload.html (modified) (7 diffs)
• p4-conditional.html (modified) (8 diffs)
• p5-range.html (modified) (5 diffs)
• p6-cache.html (modified) (5 diffs)
• p7-auth.html (modified) (5 diffs)

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

@@ -1291 +1291 @@
       <p id="rfc.section.3.3.p.8">For response messages, whether or not a message-body is included with a message is dependent on both the request method and
          the response status code (<a href="#status.code.and.reason.phrase" title="Status Code and Reason Phrase">Section&nbsp;5.1.1</a>). Responses to the HEAD request method never include a message-body because the associated response header fields (e.g.,
-         Transfer-Encoding, Content-Length, etc.) only indicate what their values would have been if the method had been GET. All 1xx
-         (Informational), 204 (No Content), and 304 (Not Modified) responses <em class="bcp14">MUST NOT</em> include a message-body. All other responses do include a message-body, although the body <em class="bcp14">MAY</em> be of zero length.
+         Transfer-Encoding, Content-Length, etc.) only indicate what their values would have been if the request method had been GET.
+         All 1xx (Informational), 204 (No Content), and 304 (Not Modified) responses <em class="bcp14">MUST NOT</em> include a message-body. All other responses do include a message-body, although the body <em class="bcp14">MAY</em> be of zero length.
       </p>
       <p id="rfc.section.3.3.p.9">The length of the message-body is determined by one of the following (in order of precedence):</p>
@@ -1432 +1432 @@
       <div id="rfc.figure.u.31"></div><pre class="inline"><span id="rfc.iref.g.46"></span>  <a href="#request-line" class="smpl">Request-Line</a>   = <a href="#method" class="smpl">Method</a> <a href="#core.rules" class="smpl">SP</a> <a href="#request-target" class="smpl">request-target</a> <a href="#core.rules" class="smpl">SP</a> <a href="#http.version" class="smpl">HTTP-Version</a> <a href="#core.rules" class="smpl">CRLF</a>
 </pre><h3 id="rfc.section.4.1.1"><a href="#rfc.section.4.1.1">4.1.1</a>&nbsp;<a id="method" href="#method">Method</a></h3>
-      <p id="rfc.section.4.1.1.p.1">The Method token indicates the method to be performed on the resource identified by the request-target. The method is case-sensitive.</p>
+      <p id="rfc.section.4.1.1.p.1">The Method token indicates the request method to be performed on the target resource. The request method is case-sensitive.</p>
       <div id="rfc.figure.u.32"></div><pre class="inline"><span id="rfc.iref.g.47"></span>  <a href="#method" class="smpl">Method</a>         = <a href="#rule.token.separators" class="smpl">token</a>
 </pre><h3 id="rfc.section.4.1.2"><a href="#rfc.section.4.1.2">4.1.2</a>&nbsp;<a id="request-target" href="#request-target">request-target</a></h3>
-      <p id="rfc.section.4.1.2.p.1">The request-target identifies the resource upon which to apply the request.</p>
+      <p id="rfc.section.4.1.2.p.1">The request-target identifies the target resource upon which to apply the request.</p>
       <div id="rfc.figure.u.33"></div><pre class="inline"><span id="rfc.iref.g.48"></span>  <a href="#request-target" class="smpl">request-target</a> = "*"
                  / <a href="#uri" class="smpl">absolute-URI</a>
@@ -1442 +1442 @@
 </pre><p id="rfc.section.4.1.2.p.3">The four options for request-target are dependent on the nature of the request.</p>
       <p id="rfc.section.4.1.2.p.4"><span id="rfc.iref.a.1"></span> The asterisk "*" ("asterisk form") means that the request does not apply to a particular resource, but to the server itself.
-         This is only allowed for the OPTIONS method. Thus, the only valid example is
+         This is only allowed for the OPTIONS request method. Thus, the only valid example is
       </p>
       <div id="rfc.figure.u.34"></div><pre class="text2">OPTIONS * HTTP/1.1
@@ -1453 +1453 @@
 </pre><p id="rfc.section.4.1.2.p.8">To allow for transition to absolute-URIs in all requests in future versions of HTTP, all HTTP/1.1 servers <em class="bcp14">MUST</em> accept the absolute-URI form in requests, even though HTTP/1.1 clients will only generate them in requests to proxies.
       </p>
-      <p id="rfc.section.4.1.2.p.9"><span id="rfc.iref.a.3"></span> The "authority form" is only used by the CONNECT method (<a href="p2-semantics.html#CONNECT" title="CONNECT">Section 7.9</a> of <a href="#Part2" id="rfc.xref.Part2.3"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).
+      <p id="rfc.section.4.1.2.p.9"><span id="rfc.iref.a.3"></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.3"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).
       </p>
       <p id="rfc.section.4.1.2.p.10"><span id="rfc.iref.p.2"></span> The most common form of request-target is that used to identify a resource on an origin server or gateway ("path-absolute
@@ -1464 +1464 @@
          URI, it <em class="bcp14">MUST</em> be given as "/" (the server root).
       </p>
-      <p id="rfc.section.4.1.2.p.13">If a proxy receives a request without any path in the request-target and the method specified is capable of supporting the
-         asterisk form of request-target, then the last proxy on the request chain <em class="bcp14">MUST</em> forward the request with "*" as the final request-target.
+      <p id="rfc.section.4.1.2.p.13">If a proxy receives an OPTIONS request without any path in the request-target, then the last proxy on the request chain <em class="bcp14">MUST</em> forward the request with "*" as the final request-target.
       </p>
       <div id="rfc.figure.u.37"></div>
       <p>For example, the request</p><pre class="text2">OPTIONS http://www.example.org:8001 HTTP/1.1
 </pre><div id="rfc.figure.u.38"></div>
-      <p>would be forwarded by the proxy as</p><pre class="text2">OPTIONS * HTTP/1.1
+      <p>would be forwarded by the final proxy as</p><pre class="text2">OPTIONS * HTTP/1.1
 Host: www.example.org:8001
 </pre>  <p>after connecting to port 8001 of host "www.example.org".</p> 
@@ -1890 +1889 @@
       <p id="rfc.section.7.1.2.2.p.2">Clients which assume persistent connections and pipeline immediately after connection establishment <em class="bcp14">SHOULD</em> be prepared to retry their connection if the first pipelined attempt fails. If a client does such a retry, it <em class="bcp14">MUST NOT</em> pipeline before it knows the connection is persistent. Clients <em class="bcp14">MUST</em> also be prepared to resend their requests if the server closes the connection before sending all of the corresponding responses.
       </p>
-      <p id="rfc.section.7.1.2.2.p.3">Clients <em class="bcp14">SHOULD NOT</em> pipeline requests using non-idempotent methods or non-idempotent sequences of methods (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 7.1.2</a> of <a href="#Part2" id="rfc.xref.Part2.6"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). Otherwise, a premature termination of the transport connection could lead to indeterminate results. A client wishing to
+      <p id="rfc.section.7.1.2.2.p.3">Clients <em class="bcp14">SHOULD NOT</em> pipeline requests using non-idempotent request methods or non-idempotent sequences of request methods (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 7.1.2</a> of <a href="#Part2" id="rfc.xref.Part2.6"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). Otherwise, a premature termination of the transport connection could lead to indeterminate results. A client wishing to
          send a non-idempotent request <em class="bcp14">SHOULD</em> wait to send that request until it has received the response status line for the previous request.
       </p>
@@ -1974 +1973 @@
       </p>
       <p id="rfc.section.7.1.4.p.4">This means that clients, servers, and proxies <em class="bcp14">MUST</em> be able to recover from asynchronous close events. Client software <em class="bcp14">SHOULD</em> reopen the transport connection and retransmit the aborted sequence of requests without user interaction so long as the request
-         sequence is idempotent (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 7.1.2</a> of <a href="#Part2" id="rfc.xref.Part2.7"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). Non-idempotent methods or sequences <em class="bcp14">MUST NOT</em> be automatically retried, although user agents <em class="bcp14">MAY</em> offer a human operator the choice of retrying the request(s). Confirmation by user-agent software with semantic understanding
+         sequence is idempotent (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 7.1.2</a> of <a href="#Part2" id="rfc.xref.Part2.7"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). Non-idempotent request methods or sequences <em class="bcp14">MUST NOT</em> be automatically retried, although user agents <em class="bcp14">MAY</em> offer a human operator the choice of retrying the request(s). Confirmation by user-agent software with semantic understanding
          of the application <em class="bcp14">MAY</em> substitute for user confirmation. The automatic retry <em class="bcp14">SHOULD NOT</em> be repeated if the second sequence of requests fails.
       </p>
@@ -2021 +2020 @@
       <ul>
          <li>Upon receiving a request which includes an Expect request-header field with the "100-continue" expectation, an origin server <em class="bcp14">MUST</em> either respond with 100 (Continue) status code and continue to read from the input stream, or respond with a final status
-            code. The origin server <em class="bcp14">MUST NOT</em> wait for the request body before sending the 100 (Continue) response. If it responds with a final status code, it <em class="bcp14">MAY</em> close the transport connection or it <em class="bcp14">MAY</em> continue to read and discard the rest of the request. It <em class="bcp14">MUST NOT</em> perform the requested method if it returns a final status code.
+            code. The origin server <em class="bcp14">MUST NOT</em> wait for the request body before sending the 100 (Continue) response. If it responds with a final status code, it <em class="bcp14">MAY</em> close the transport connection or it <em class="bcp14">MAY</em> continue to read and discard the rest of the request. It <em class="bcp14">MUST NOT</em> perform the request method if it returns a final status code.
          </li>
          <li>An origin server <em class="bcp14">SHOULD NOT</em> send a 100 (Continue) response if the request message does not include an Expect request-header field with the "100-continue"
@@ -2134 +2133 @@
       <h2 id="rfc.section.9.2"><a href="#rfc.section.9.2">9.2</a>&nbsp;<a id="header.content-length" href="#header.content-length">Content-Length</a></h2>
       <p id="rfc.section.9.2.p.1">The "Content-Length" header field indicates the size of the message-body, in decimal number of octets, for any message other
-         than a response to the HEAD method or a response with a status code of 304. In the case of responses to the HEAD method, it
+         than a response to a HEAD request or a response with a status code of 304. In the case of a response to a HEAD request, Content-Length
          indicates the size of the payload body (not including any potential transfer-coding) that would have been sent had the request
-         been a GET. In the case of the 304 (Not Modified) response, it indicates the size of the payload body (not including any potential
-         transfer-coding) that would have been sent in a 200 (OK) response.
+         been a GET. In the case of a 304 (Not Modified) response to a GET request, Content-Length indicates the size of the payload
+         body (not including any potential transfer-coding) that would have been sent in a 200 (OK) response.
       </p>
       <div id="rfc.figure.u.60"></div><pre class="inline"><span id="rfc.iref.g.94"></span><span id="rfc.iref.g.95"></span>  <a href="#header.content-length" class="smpl">Content-Length</a>   = "Content-Length" ":" <a href="#rule.whitespace" class="smpl">OWS</a> 1*<a href="#header.content-length" class="smpl">Content-Length-v</a>
@@ -2310 +2309 @@
          transition between incompatible protocols by allowing the client to initiate a request in the more commonly supported protocol
          while indicating to the server that it would like to use a "better" protocol if available (where "better" is determined by
-         the server, possibly according to the nature of the method and/or resource being requested).
+         the server, possibly according to the nature of the request method or target resource).
       </p>
       <p id="rfc.section.9.8.p.6">The Upgrade header field only applies to switching application-layer protocols upon the existing transport-layer connection.
@@ -2999 +2998 @@
       <h1 id="rfc.section.B"><a href="#rfc.section.B">B.</a>&nbsp;<a id="compatibility" href="#compatibility">Compatibility with Previous Versions</a></h1>
       <p id="rfc.section.B.p.1">HTTP has been in use by the World-Wide Web global information initiative since 1990. The first version of HTTP, later referred
-         to as HTTP/0.9, was a simple protocol for hypertext data transfer across the Internet with only a single method and no metadata.
-         HTTP/1.0, as defined by <a href="#RFC1945" id="rfc.xref.RFC1945.2"><cite title="Hypertext Transfer Protocol -- HTTP/1.0">[RFC1945]</cite></a>, added a range of request methods and MIME-like messaging that could include metadata about the data transferred and modifiers
+         to as HTTP/0.9, was a simple protocol for hypertext data transfer across the Internet with only a single request method (GET)
+         and no metadata. HTTP/1.0, as defined by <a href="#RFC1945" id="rfc.xref.RFC1945.2"><cite title="Hypertext Transfer Protocol -- HTTP/1.0">[RFC1945]</cite></a>, added a range of request methods and MIME-like messaging that could include metadata about the data transferred and modifiers
          on the request/response semantics. However, HTTP/1.0 did not sufficiently take into consideration the effects of hierarchical
          proxies, caching, the need for persistent connections, or name-based virtual hosts. The proliferation of incompletely-implemented
@@ -3084 +3083 @@
       </p>
       <p id="rfc.section.B.3.p.7">Update use of abs_path production from RFC 1808 to the path-absolute + query components of RFC 3986. State that the asterisk
-         form is allowed for the OPTIONS method only. (<a href="#request-target" title="request-target">Section&nbsp;4.1.2</a>)
+         form is allowed for the OPTIONS request method only. (<a href="#request-target" title="request-target">Section&nbsp;4.1.2</a>)
       </p>
       <p id="rfc.section.B.3.p.8">Clarification that the chunk length does not include the count of the octets in the chunk header and trailer. Furthermore

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

@@ -774 +774 @@
              &lt;WWW-Authenticate, defined in <a href="#Part7" id="rfc.xref.Part7.4"><cite title="HTTP/1.1, part 7: Authentication">[Part7]</cite></a>, <a href="p7-auth.html#header.www-authenticate" title="WWW-Authenticate">Section 4.4</a>&gt;
 </pre><h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a>&nbsp;<a id="method" href="#method">Method</a></h1>
-      <p id="rfc.section.2.p.1">The Method token indicates the method to be performed on the target resource (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.17"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). The method is case-sensitive.
+      <p id="rfc.section.2.p.1">The Method token indicates the request method to be performed on the target resource (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.17"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). The method is case-sensitive.
       </p>
       <div id="rfc.figure.u.8"></div><pre class="inline"><span id="rfc.iref.g.1"></span>  <a href="#method" class="smpl">Method</a>         = <a href="#core.rules" class="smpl">token</a>
@@ -829 +829 @@
          </table>
       </div>
-      <p id="rfc.section.2.1.p.2">Note that this list is not exhaustive — it does not include methods defined in other specifications.</p>
+      <p id="rfc.section.2.1.p.2">Note that this list is not exhaustive — it does not include request methods defined in other specifications.</p>
       <h2 id="rfc.section.2.2"><a href="#rfc.section.2.2">2.2</a>&nbsp;<a id="method.registry" href="#method.registry">Method Registry</a></h2>
       <p id="rfc.section.2.2.p.1">The HTTP Method Registry defines the name space for the Method token in the Request line of an HTTP request.</p>
@@ -1309 +1309 @@
       </p>
       <h1 id="rfc.section.7"><a href="#rfc.section.7">7.</a>&nbsp;<a id="method.definitions" href="#method.definitions">Method Definitions</a></h1>
-      <p id="rfc.section.7.p.1">The set of common methods for HTTP/1.1 is defined below. Although this set can be expanded, additional methods cannot be assumed
-         to share the same semantics for separately extended clients and servers.
+      <p id="rfc.section.7.p.1">The set of common request methods for HTTP/1.1 is defined below. Although this set can be expanded, additional methods cannot
+         be assumed to share the same semantics for separately extended clients and servers.
       </p>
       <h2 id="rfc.section.7.1"><a href="#rfc.section.7.1">7.1</a>&nbsp;<a id="safe.and.idempotent" href="#safe.and.idempotent">Safe and Idempotent Methods</a></h2>
@@ -1318 +1318 @@
          the user to be aware of any actions they take which might have an unexpected significance to themselves or others.
       </p>
-      <p id="rfc.section.7.1.1.p.2">In particular, the convention has been established that the GET, HEAD, OPTIONS, and TRACE methods <em class="bcp14">SHOULD NOT</em> have the significance of taking an action other than retrieval. These methods ought to be considered "<dfn id="safe">safe</dfn>". This allows user agents to represent other methods, such as POST, PUT and DELETE, in a special way, so that the user is
+      <p id="rfc.section.7.1.1.p.2">In particular, the convention has been established that the GET, HEAD, OPTIONS, and TRACE request methods <em class="bcp14">SHOULD NOT</em> have the significance of taking an action other than retrieval. These request methods ought to be considered "<dfn id="safe">safe</dfn>". This allows user agents to represent other methods, such as POST, PUT and DELETE, in a special way, so that the user is
          made aware of the fact that a possibly unsafe action is being requested.
       </p>
@@ -1327 +1327 @@
       <div id="rfc.iref.i.1"></div>
       <h3 id="rfc.section.7.1.2"><a href="#rfc.section.7.1.2">7.1.2</a>&nbsp;<a id="idempotent.methods" href="#idempotent.methods">Idempotent Methods</a></h3>
-      <p id="rfc.section.7.1.2.p.1">Methods can also have the property of "idempotence" in that, aside from error or expiration issues, the intended effect of
-         multiple identical requests is the same as for a single request. The methods PUT, DELETE, and all safe methods are idempotent.
+      <p id="rfc.section.7.1.2.p.1">Request methods can also have the property of "idempotence" in that, aside from error or expiration issues, the intended effect
+         of multiple identical requests is the same as for a single request. PUT, DELETE, and all safe request methods are idempotent.
          It is important to note that idempotence refers only to changes requested by the client: a server is free to change its state
          due to multiple requests for the purpose of tracking those requests, versioning of results, etc.
@@ -1335 +1335 @@
       <div id="rfc.iref.o.1"></div>
       <div id="rfc.iref.m.1"></div>
-      <p id="rfc.section.7.2.p.1">The OPTIONS method represents a request for information about the communication options available on the request/response
-         chain identified by the effective request URI. This method allows the client to determine the options and/or requirements
-         associated with a resource, or the capabilities of a server, without implying a resource action or initiating a resource retrieval.
-      </p>
-      <p id="rfc.section.7.2.p.2">Responses to this method are not cacheable.</p>
+      <p id="rfc.section.7.2.p.1">The OPTIONS method requests information about the communication options available on the request/response chain identified
+         by the effective request URI. This method allows a client to determine the options and/or requirements associated with a resource,
+         or the capabilities of a server, without implying a resource action or initiating a resource retrieval.
+      </p>
+      <p id="rfc.section.7.2.p.2">Responses to the OPTIONS method are not cacheable.</p>
       <p id="rfc.section.7.2.p.3">If the OPTIONS request includes a message-body (as indicated by the presence of Content-Length or Transfer-Encoding), then
          the media type <em class="bcp14">MUST</em> be indicated by a Content-Type field. Although this specification does not define any use for such a body, future extensions
@@ -1361 +1361 @@
       <div id="rfc.iref.g.5"></div>
       <div id="rfc.iref.m.2"></div>
-      <p id="rfc.section.7.3.p.1">The GET method means retrieve whatever information (in the form of a representation) currently corresponds to the target resource.</p>
+      <p id="rfc.section.7.3.p.1">The GET method requests transfer of a current representation of the target resource.</p>
       <p id="rfc.section.7.3.p.2">If the target resource is a data-producing process, it is the produced data which shall be returned as the representation
          in the response and not the source text of the process, unless that text happens to be the output of the process.
       </p>
       <p id="rfc.section.7.3.p.3">The semantics of the GET method change to a "conditional GET" if the request message includes an If-Modified-Since, If-Unmodified-Since,
-         If-Match, If-None-Match, or If-Range header field. A conditional GET method requests that the representation be transferred
-         only under the circumstances described by the conditional header field(s). The conditional GET method is intended to reduce
-         unnecessary network usage by allowing cached representations to be refreshed without requiring multiple requests or transferring
-         data already held by the client.
+         If-Match, If-None-Match, or If-Range header field. A conditional GET requests that the representation be transferred only
+         under the circumstances described by the conditional header field(s). The conditional GET request is intended to reduce unnecessary
+         network usage by allowing cached representations to be refreshed without requiring multiple requests or transferring data
+         already held by the client.
       </p>
       <p id="rfc.section.7.3.p.4">The semantics of the GET method change to a "partial GET" if the request message includes a Range header field. A partial
-         GET requests that only part of the representation be transferred, as described in <a href="p5-range.html#header.range" title="Range">Section 5.4</a> of <a href="#Part5" id="rfc.xref.Part5.10"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>. The partial GET method is intended to reduce unnecessary network usage by allowing partially-retrieved representations to
-         be completed without transferring data already held by the client.
+         GET requests that only part of the representation be transferred, as described in <a href="p5-range.html#header.range" title="Range">Section 5.4</a> of <a href="#Part5" id="rfc.xref.Part5.10"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>. The partial GET request is intended to reduce unnecessary network usage by allowing partially-retrieved representations
+         to be completed without transferring data already held by the client.
       </p>
       <p id="rfc.section.7.3.p.5">The response to a GET request is cacheable and <em class="bcp14">MAY</em> be used to satisfy subsequent GET and HEAD requests (see <a href="#Part6" id="rfc.xref.Part6.8"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>).
@@ -1393 +1393 @@
       <div id="rfc.iref.m.4"></div>
       <h2 id="rfc.section.7.5"><a href="#rfc.section.7.5">7.5</a>&nbsp;<a id="POST" href="#POST">POST</a></h2>
-      <p id="rfc.section.7.5.p.1">The POST method is used to request that the origin server accept the representation enclosed in the request as data to be
-         processed by the target resource. POST is designed to allow a uniform method to cover the following functions: 
+      <p id="rfc.section.7.5.p.1">The POST method requests that the origin server accept the representation enclosed in the request as data to be processed
+         by the target resource. POST is designed to allow a uniform method to cover the following functions: 
       </p>
       <ul>
@@ -1420 +1420 @@
       <div id="rfc.iref.m.5"></div>
       <h2 id="rfc.section.7.6"><a href="#rfc.section.7.6">7.6</a>&nbsp;<a id="PUT" href="#PUT">PUT</a></h2>
-      <p id="rfc.section.7.6.p.1">The PUT method is used to request that the state of the target resource be created or replaced with the state defined by the
-         representation enclosed in the request message payload. A successful PUT of a given representation would suggest that a subsequent
-         GET on that same target resource will result in an equivalent representation being returned in a 200 (OK) response. However,
-         there is no guarantee that such a state change will be observable, since the target resource might be acted upon by other
-         user agents in parallel, or might be subject to dynamic processing by the origin server, before any subsequent GET is received.
-         A successful response only implies that the user agent's intent was achieved at the time of its processing by the origin server.
+      <p id="rfc.section.7.6.p.1">The PUT method requests that the state of the target resource be created or replaced with the state defined by the representation
+         enclosed in the request message payload. A successful PUT of a given representation would suggest that a subsequent GET on
+         that same target resource will result in an equivalent representation being returned in a 200 (OK) response. However, there
+         is no guarantee that such a state change will be observable, since the target resource might be acted upon by other user agents
+         in parallel, or might be subject to dynamic processing by the origin server, before any subsequent GET is received. A successful
+         response only implies that the user agent's intent was achieved at the time of its processing by the origin server.
       </p>
       <p id="rfc.section.7.6.p.2">If the target resource does not have a current representation and the PUT successfully creates one, then the origin server <em class="bcp14">MUST</em> inform the user agent by sending a 201 (Created) response. If the target resource does have a current representation and that
@@ -1494 +1494 @@
       <div id="rfc.iref.t.1"></div>
       <div id="rfc.iref.m.7"></div>
-      <p id="rfc.section.7.8.p.1">The TRACE method is used to invoke 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
+      <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.
       </p>
@@ -1508 +1507 @@
       <div id="rfc.iref.m.8"></div>
       <h2 id="rfc.section.7.9"><a href="#rfc.section.7.9">7.9</a>&nbsp;<a id="CONNECT" href="#CONNECT">CONNECT</a></h2>
-      <p id="rfc.section.7.9.p.1">The CONNECT method is used with a proxy to dynamically switch the connection to a tunnel.</p>
-      <p id="rfc.section.7.9.p.2">When using CONNECT, the request-target <em class="bcp14">MUST</em> be use the authority form (<a href="p1-messaging.html#request-target" title="request-target">Section 4.1.2</a> of <a href="#Part1" id="rfc.xref.Part1.26"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>); i.e., the host name and port number destination of the requested connection separated by a colon:
+      <p id="rfc.section.7.9.p.1">The CONNECT method requests that the proxy establish a tunnel to the request-target and then restrict its behavior to blind
+         forwarding of packets until the connection is closed.
+      </p>
+      <p id="rfc.section.7.9.p.2">When using CONNECT, the request-target <em class="bcp14">MUST</em> use the authority form (<a href="p1-messaging.html#request-target" title="request-target">Section 4.1.2</a> of <a href="#Part1" id="rfc.xref.Part1.26"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>); i.e., the request-target consists of only the host name and port number of the tunnel destination, separated by a colon.
+         For example,
       </p>
       <div id="rfc.figure.u.10"></div><pre class="text2">CONNECT server.example.com:80 HTTP/1.1
@@ -1890 +1892 @@
       <div id="rfc.iref.s.34"></div>
       <h3 id="rfc.section.8.4.16"><a href="#rfc.section.8.4.16">8.4.16</a>&nbsp;<a id="status.415" href="#status.415">415 Unsupported Media Type</a></h3>
-      <p id="rfc.section.8.4.16.p.1">The server is refusing to service the request because the representation of the request is in a format not supported by the
-         target resource for the requested method.
+      <p id="rfc.section.8.4.16.p.1">The server is refusing to service the request because the request payload is in a format not supported by this request method
+         on the target resource.
       </p>
       <div id="rfc.iref.55"></div>
@@ -1972 +1974 @@
       <h2 id="rfc.section.9.1"><a href="#rfc.section.9.1">9.1</a>&nbsp;<a id="header.allow" href="#header.allow">Allow</a></h2>
       <p id="rfc.section.9.1.p.1">The "Allow" response-header field lists the set of methods advertised as supported by the target resource. The purpose of
-         this field is strictly to inform the recipient of valid methods associated with the resource.
+         this field is strictly to inform the recipient of valid request methods associated with the resource.
       </p>
       <div id="rfc.figure.u.13"></div><pre class="inline"><span id="rfc.iref.g.6"></span><span id="rfc.iref.g.7"></span>  <a href="#header.allow" class="smpl">Allow</a>   = "Allow" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.allow" class="smpl">Allow-v</a>
@@ -2073 +2075 @@
       <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>
-      <p id="rfc.section.9.5.p.5">The Max-Forwards header field <em class="bcp14">MAY</em> be ignored for all other methods.
+      <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.
       </p>
       <div id="rfc.iref.r.1"></div>
@@ -2158 +2160 @@
 </pre><h1 id="rfc.section.10"><a href="#rfc.section.10">10.</a>&nbsp;<a id="IANA.considerations" href="#IANA.considerations">IANA Considerations</a></h1>
       <h2 id="rfc.section.10.1"><a href="#rfc.section.10.1">10.1</a>&nbsp;<a id="method.registration" href="#method.registration">Method Registry</a></h2>
-      <p id="rfc.section.10.1.p.1">The registration procedure for HTTP Methods is defined by <a href="#method.registry" title="Method Registry">Section&nbsp;2.2</a> of this document.
+      <p id="rfc.section.10.1.p.1">The registration procedure for HTTP request methods is defined by <a href="#method.registry" title="Method Registry">Section&nbsp;2.2</a> of this document.
       </p>
       <p id="rfc.section.10.1.p.2">The HTTP Method Registry shall be created at &lt;<a href="http://www.iana.org/assignments/http-methods">http://www.iana.org/assignments/http-methods</a>&gt; and be populated with the registrations below:
@@ -2582 +2584 @@
          to uniquely identify the user.
       </p>
-      <p id="rfc.section.11.1.p.9">Some methods, like TRACE (<a href="#TRACE" id="rfc.xref.TRACE.4" title="TRACE">Section&nbsp;7.8</a>), expose information that was sent in request header fields within the body of their response. Clients <em class="bcp14">SHOULD</em> be careful with sensitive information, like Cookies, Authorization credentials and other header fields that might be used
+      <p id="rfc.section.11.1.p.9">Some request methods, like TRACE (<a href="#TRACE" id="rfc.xref.TRACE.4" title="TRACE">Section&nbsp;7.8</a>), expose information that was sent in request header fields within the body of their response. Clients <em class="bcp14">SHOULD</em> be careful with sensitive information, like Cookies, Authorization credentials, and other header fields that might be used
          to collect data from the client.
       </p>

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

@@ -359 +359 @@
   } 
   @bottom-center {
-       content: "Expires September 10, 2011"; 
+       content: "Expires September 11, 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-09">
+      <meta name="dct.issued" scheme="ISO8601" content="2011-03-10">
       <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 10, 2011</td>
+               <td class="left">Expires: September 11, 2011</td>
                <td class="right">J. Mogul</td>
             </tr>
@@ -491 +491 @@
             <tr>
                <td class="left"></td>
-               <td class="right">March 9, 2011</td>
+               <td class="right">March 10, 2011</td>
             </tr>
          </tbody>
@@ -517 +517 @@
          in progress”.
       </p>
-      <p>This Internet-Draft will expire on September 10, 2011.</p>
+      <p>This Internet-Draft will expire on September 11, 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>
@@ -1329 +1329 @@
       <p id="rfc.section.6.7.p.4">If Content-Location is included in a response message and its value is the same as the effective request URI, then the response
          payload <em class="bcp14">SHOULD</em> be considered the current representation of that resource. For a GET or HEAD request, this is the same as the default semantics
-         when no Content-Location is provided by the server. For a state-changing method like PUT or POST, it implies that the server's
+         when no Content-Location is provided by the server. For a state-changing request like PUT or POST, it implies that the server's
          response contains the new representation of that resource, thereby distinguishing it from representations that might only
          report about the action (e.g., "It worked!"). This allows authoring applications to update their local copies without the
@@ -1339 +1339 @@
          and the representation selected for this response can also be found at the identified URI. For other methods, such a Content-Location
          indicates that this representation contains a report on the action's status and the same report is available (for future access
-         with GET) at the given URI. For example, a purchase transaction made via the POST method might include a receipt document
-         as the payload of the 200 response; the Content-Location value provides an identifier for retrieving a copy of that same receipt
+         with GET) at the given URI. For example, a purchase transaction made via a POST request might include a receipt document as
+         the payload of the 200 response; the Content-Location value provides an identifier for retrieving a copy of that same receipt
          in the future.
       </p>

draft-ietf-httpbis/latest/p4-conditional.html

@@ -359 +359 @@
   } 
   @bottom-center {
-       content: "Expires September 10, 2011"; 
+       content: "Expires September 11, 2011"; 
   } 
   @bottom-right {
@@ -406 +406 @@
       <meta name="dct.creator" content="Reschke, J. F.">
       <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p4-conditional-latest">
-      <meta name="dct.issued" scheme="ISO8601" content="2011-03-09">
+      <meta name="dct.issued" scheme="ISO8601" content="2011-03-10">
       <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 4 of the seven-part specification that defines the protocol referred to as &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 4 defines request header fields for indicating conditional requests and the rules for constructing responses to those requests.">
@@ -432 +432 @@
             </tr>
             <tr>
-               <td class="left">Expires: September 10, 2011</td>
+               <td class="left">Expires: September 11, 2011</td>
                <td class="right">J. Mogul</td>
             </tr>
@@ -489 +489 @@
             <tr>
                <td class="left"></td>
-               <td class="right">March 9, 2011</td>
+               <td class="right">March 10, 2011</td>
             </tr>
          </tbody>
@@ -515 +515 @@
          in progress”.
       </p>
-      <p>This Internet-Draft will expire on September 10, 2011.</p>
+      <p>This Internet-Draft will expire on September 11, 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>
@@ -939 +939 @@
          for that resource, then the server <em class="bcp14">MAY</em> perform the requested method as if the If-Match header field did not exist.
       </p>
-      <p id="rfc.section.6.2.p.5">If none of the entity-tags match, or if "*" is given and no current representation exists, the server <em class="bcp14">MUST NOT</em> perform the requested method, and <em class="bcp14">MUST</em> return a 412 (Precondition Failed) response. This behavior is most useful when the client wants to prevent an updating method,
-         such as PUT, from modifying a resource that has changed since the client last retrieved it.
+      <p id="rfc.section.6.2.p.5">If none of the entity-tags match, or if "*" is given and no current representation exists, the server <em class="bcp14">MUST NOT</em> perform the requested method, and <em class="bcp14">MUST</em> return a 412 (Precondition Failed) response. This behavior is most useful when the client wants to prevent an updating request
+         method, such as PUT, from modifying a resource that has changed since the client last retrieved it.
       </p>
       <p id="rfc.section.6.2.p.6">If the request would, without the If-Match header field, result in anything other than a 2xx or 412 status code, then the
          If-Match header field <em class="bcp14">MUST</em> be ignored.
       </p>
-      <p id="rfc.section.6.2.p.7">The meaning of "If-Match: *" is that the method <em class="bcp14">SHOULD</em> be performed if the representation selected by the origin server (or by a cache, possibly using the Vary mechanism, see <a href="p6-cache.html#header.vary" title="Vary">Section 3.5</a> of <a href="#Part6" id="rfc.xref.Part6.2"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) exists, and <em class="bcp14">MUST NOT</em> be performed if the representation does not exist.
+      <p id="rfc.section.6.2.p.7">The meaning of "If-Match: *" is that the request method <em class="bcp14">SHOULD</em> be performed if the representation selected by the origin server (or by a cache, possibly using the Vary mechanism, see <a href="p6-cache.html#header.vary" title="Vary">Section 3.5</a> of <a href="#Part6" id="rfc.xref.Part6.2"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) exists, and <em class="bcp14">MUST NOT</em> be performed if the representation does not exist.
       </p>
       <p id="rfc.section.6.2.p.8">A request intended to update a resource (e.g., a PUT) <em class="bcp14">MAY</em> include an If-Match header field to signal that the request method <em class="bcp14">MUST NOT</em> be applied if the representation corresponding to the If-Match value (a single entity-tag) is no longer a representation of
@@ -1015 +1015 @@
       </p>
       <p id="rfc.section.6.4.p.2">This allows efficient updates of cached information with a minimum amount of transaction overhead. It is also used to prevent
-         a method (e.g., PUT) from inadvertently modifying an existing resource when the client believes that the resource does not
-         exist.
+         a request method (e.g., PUT) from inadvertently modifying an existing resource when the client believes that the resource
+         does not exist.
       </p>
       <p id="rfc.section.6.4.p.3">As a special case, the value "*" matches any current representation of the resource.</p>
@@ -1032 +1032 @@
          the If-None-Match header field <em class="bcp14">MUST</em> be ignored. (See <a href="#rules.for.when.to.use.entity.tags.and.last-modified.dates" title="Rules for When to Use Entity-tags and Last-Modified Dates">Section&nbsp;5</a> for a discussion of server behavior when both If-Modified-Since and If-None-Match appear in the same request.)
       </p>
-      <p id="rfc.section.6.4.p.8">The meaning of "If-None-Match: *" is that the method <em class="bcp14">MUST NOT</em> be performed if the representation selected by the origin server (or by a cache, possibly using the Vary mechanism, see <a href="p6-cache.html#header.vary" title="Vary">Section 3.5</a> of <a href="#Part6" id="rfc.xref.Part6.3"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) exists, and <em class="bcp14">SHOULD</em> be performed if the representation does not exist. This feature is intended to be useful in preventing races between PUT operations.
+      <p id="rfc.section.6.4.p.8">The meaning of "If-None-Match: *" is that the request method <em class="bcp14">MUST NOT</em> be performed if the representation selected by the origin server (or by a cache, possibly using the Vary mechanism, see <a href="p6-cache.html#header.vary" title="Vary">Section 3.5</a> of <a href="#Part6" id="rfc.xref.Part6.3"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) exists, and <em class="bcp14">SHOULD</em> be performed if the representation does not exist. This feature is intended to be useful in preventing races between PUT operations.
       </p>
       <p id="rfc.section.6.4.p.9">Examples:</p>

draft-ietf-httpbis/latest/p5-range.html

@@ -359 +359 @@
   } 
   @bottom-center {
-       content: "Expires September 10, 2011"; 
+       content: "Expires September 11, 2011"; 
   } 
   @bottom-right {
@@ -406 +406 @@
       <meta name="dct.creator" content="Reschke, J. F.">
       <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p5-range-latest">
-      <meta name="dct.issued" scheme="ISO8601" content="2011-03-09">
+      <meta name="dct.issued" scheme="ISO8601" content="2011-03-10">
       <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 5 of the seven-part specification that defines the protocol referred to as &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 5 defines range-specific requests and the rules for constructing and combining responses to those requests.">
@@ -432 +432 @@
             </tr>
             <tr>
-               <td class="left">Expires: September 10, 2011</td>
+               <td class="left">Expires: September 11, 2011</td>
                <td class="right">J. Mogul</td>
             </tr>
@@ -489 +489 @@
             <tr>
                <td class="left"></td>
-               <td class="right">March 9, 2011</td>
+               <td class="right">March 10, 2011</td>
             </tr>
          </tbody>
@@ -515 +515 @@
          in progress”.
       </p>
-      <p>This Internet-Draft will expire on September 10, 2011.</p>
+      <p>This Internet-Draft will expire on September 11, 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>

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

@@ -362 +362 @@
   } 
   @bottom-center {
-       content: "Expires September 10, 2011"; 
+       content: "Expires September 11, 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-09">
+      <meta name="dct.issued" scheme="ISO8601" content="2011-03-10">
       <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 10, 2011</td>
+               <td class="left">Expires: September 11, 2011</td>
                <td class="right">J. Mogul</td>
             </tr>
@@ -495 +495 @@
             <tr>
                <td class="left"></td>
-               <td class="right">March 9, 2011</td>
+               <td class="right">March 10, 2011</td>
             </tr>
          </tbody>
@@ -521 +521 @@
          in progress”.
       </p>
-      <p>This Internet-Draft will expire on September 10, 2011.</p>
+      <p>This Internet-Draft will expire on September 11, 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>

draft-ietf-httpbis/latest/p7-auth.html

@@ -359 +359 @@
   } 
   @bottom-center {
-       content: "Expires September 10, 2011"; 
+       content: "Expires September 11, 2011"; 
   } 
   @bottom-right {
@@ -403 +403 @@
       <meta name="dct.creator" content="Reschke, J. F.">
       <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p7-auth-latest">
-      <meta name="dct.issued" scheme="ISO8601" content="2011-03-09">
+      <meta name="dct.issued" scheme="ISO8601" content="2011-03-10">
       <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 7 of the seven-part specification that defines the protocol referred to as &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 7 defines HTTP Authentication.">
@@ -434 +434 @@
             </tr>
             <tr>
-               <td class="left">Expires: September 10, 2011</td>
+               <td class="left">Expires: September 11, 2011</td>
                <td class="right">HP</td>
             </tr>
@@ -487 +487 @@
             <tr>
                <td class="left"></td>
-               <td class="right">March 9, 2011</td>
+               <td class="right">March 10, 2011</td>
             </tr>
          </tbody>
@@ -513 +513 @@
          in progress”.
       </p>
-      <p>This Internet-Draft will expire on September 10, 2011.</p>
+      <p>This Internet-Draft will expire on September 11, 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>