Changeset 1840

Timestamp:

27/08/12 06:21:21 (10 years ago)

Author:

fielding@…

Message:

Move method registry to IANA considerations.
Rewrite definitions of safe and idempotent; add cacheable.

Location:

draft-ietf-httpbis/latest

Files:

• p2-semantics.html (modified) (98 diffs)
• p2-semantics.xml (modified) (9 diffs)

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

@@ -449 +449 @@
   } 
   @bottom-center {
-       content: "Expires February 26, 2013"; 
+       content: "Expires February 27, 2013"; 
   } 
   @bottom-right {
@@ -499 +499 @@
       <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="2012-08-25">
+      <meta name="dct.issued" scheme="ISO8601" content="2012-08-26">
       <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, hypertext information systems. This document defines the semantics of HTTP/1.1 messages, as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation.">
@@ -530 +530 @@
             </tr>
             <tr>
-               <td class="left">Expires: February 26, 2013</td>
+               <td class="left">Expires: February 27, 2013</td>
                <td class="right">greenbytes</td>
             </tr>
             <tr>
                <td class="left"></td>
-               <td class="right">August 25, 2012</td>
+               <td class="right">August 26, 2012</td>
             </tr>
          </tbody>
@@ -562 +562 @@
          in progress”.
       </p>
-      <p>This Internet-Draft will expire on February 26, 2013.</p>
+      <p>This Internet-Draft will expire on February 27, 2013.</p>
       <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
       <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
@@ -590 +590 @@
                      <li><a href="#rfc.section.3.1.1">3.1.1</a>&nbsp;&nbsp;&nbsp;<a href="#safe.methods">Safe Methods</a></li>
                      <li><a href="#rfc.section.3.1.2">3.1.2</a>&nbsp;&nbsp;&nbsp;<a href="#idempotent.methods">Idempotent Methods</a></li>
+                     <li><a href="#rfc.section.3.1.3">3.1.3</a>&nbsp;&nbsp;&nbsp;<a href="#cacheable.methods">Cacheable Methods</a></li>
                   </ul>
                </li>
-               <li><a href="#rfc.section.3.2">3.2</a>&nbsp;&nbsp;&nbsp;<a href="#method.registry">Method Registry</a><ul>
-                     <li><a href="#rfc.section.3.2.1">3.2.1</a>&nbsp;&nbsp;&nbsp;<a href="#considerations.for.new.methods">Considerations for New Methods</a></li>
-                  </ul>
-               </li>
-               <li><a href="#rfc.section.3.3">3.3</a>&nbsp;&nbsp;&nbsp;<a href="#method.definitions">Method Definitions</a><ul>
-                     <li><a href="#rfc.section.3.3.1">3.3.1</a>&nbsp;&nbsp;&nbsp;<a href="#OPTIONS">OPTIONS</a></li>
-                     <li><a href="#rfc.section.3.3.2">3.3.2</a>&nbsp;&nbsp;&nbsp;<a href="#GET">GET</a></li>
-                     <li><a href="#rfc.section.3.3.3">3.3.3</a>&nbsp;&nbsp;&nbsp;<a href="#HEAD">HEAD</a></li>
-                     <li><a href="#rfc.section.3.3.4">3.3.4</a>&nbsp;&nbsp;&nbsp;<a href="#POST">POST</a></li>
-                     <li><a href="#rfc.section.3.3.5">3.3.5</a>&nbsp;&nbsp;&nbsp;<a href="#PUT">PUT</a></li>
-                     <li><a href="#rfc.section.3.3.6">3.3.6</a>&nbsp;&nbsp;&nbsp;<a href="#DELETE">DELETE</a></li>
-                     <li><a href="#rfc.section.3.3.7">3.3.7</a>&nbsp;&nbsp;&nbsp;<a href="#TRACE">TRACE</a></li>
-                     <li><a href="#rfc.section.3.3.8">3.3.8</a>&nbsp;&nbsp;&nbsp;<a href="#CONNECT">CONNECT</a></li>
+               <li><a href="#rfc.section.3.2">3.2</a>&nbsp;&nbsp;&nbsp;<a href="#method.definitions">Method Definitions</a><ul>
+                     <li><a href="#rfc.section.3.2.1">3.2.1</a>&nbsp;&nbsp;&nbsp;<a href="#OPTIONS">OPTIONS</a></li>
+                     <li><a href="#rfc.section.3.2.2">3.2.2</a>&nbsp;&nbsp;&nbsp;<a href="#GET">GET</a></li>
+                     <li><a href="#rfc.section.3.2.3">3.2.3</a>&nbsp;&nbsp;&nbsp;<a href="#HEAD">HEAD</a></li>
+                     <li><a href="#rfc.section.3.2.4">3.2.4</a>&nbsp;&nbsp;&nbsp;<a href="#POST">POST</a></li>
+                     <li><a href="#rfc.section.3.2.5">3.2.5</a>&nbsp;&nbsp;&nbsp;<a href="#PUT">PUT</a></li>
+                     <li><a href="#rfc.section.3.2.6">3.2.6</a>&nbsp;&nbsp;&nbsp;<a href="#DELETE">DELETE</a></li>
+                     <li><a href="#rfc.section.3.2.7">3.2.7</a>&nbsp;&nbsp;&nbsp;<a href="#TRACE">TRACE</a></li>
+                     <li><a href="#rfc.section.3.2.8">3.2.8</a>&nbsp;&nbsp;&nbsp;<a href="#CONNECT">CONNECT</a></li>
                   </ul>
                </li>
@@ -733 +730 @@
          </li>
          <li><a href="#rfc.section.11">11.</a>&nbsp;&nbsp;&nbsp;<a href="#IANA.considerations">IANA Considerations</a><ul>
-               <li><a href="#rfc.section.11.1">11.1</a>&nbsp;&nbsp;&nbsp;<a href="#method.registration">Method Registry</a></li>
+               <li><a href="#rfc.section.11.1">11.1</a>&nbsp;&nbsp;&nbsp;<a href="#method.registry">Method Registry</a><ul>
+                     <li><a href="#rfc.section.11.1.1">11.1.1</a>&nbsp;&nbsp;&nbsp;<a href="#considerations.for.new.methods">Considerations for New Methods</a></li>
+                     <li><a href="#rfc.section.11.1.2">11.1.2</a>&nbsp;&nbsp;&nbsp;<a href="#method.registration">Registrations</a></li>
+                  </ul>
+               </li>
                <li><a href="#rfc.section.11.2">11.2</a>&nbsp;&nbsp;&nbsp;<a href="#status.code.registration">Status Code Registry</a></li>
                <li><a href="#rfc.section.11.3">11.3</a>&nbsp;&nbsp;&nbsp;<a href="#header.field.registration">Header Field Registration</a></li>
@@ -876 +877 @@
                   <td class="left">GET</td>
                   <td class="left">Retrieve a current representation of the target resource.</td>
-                  <td class="left"><a href="#GET" id="rfc.xref.GET.1" title="GET">3.3.2</a></td>
+                  <td class="left"><a href="#GET" id="rfc.xref.GET.1" title="GET">3.2.2</a></td>
                </tr>
                <tr>
                   <td class="left">HEAD</td>
                   <td class="left">Same as GET, but do not include a message body in the response.</td>
-                  <td class="left"><a href="#HEAD" id="rfc.xref.HEAD.1" title="HEAD">3.3.3</a></td>
+                  <td class="left"><a href="#HEAD" id="rfc.xref.HEAD.1" title="HEAD">3.2.3</a></td>
                </tr>
                <tr>
                   <td class="left">POST</td>
                   <td class="left">Perform resource-specific processing on the request payload.</td>
-                  <td class="left"><a href="#POST" id="rfc.xref.POST.1" title="POST">3.3.4</a></td>
+                  <td class="left"><a href="#POST" id="rfc.xref.POST.1" title="POST">3.2.4</a></td>
                </tr>
                <tr>
                   <td class="left">PUT</td>
                   <td class="left">Replace all current representations of the target resource with the request payload.</td>
-                  <td class="left"><a href="#PUT" id="rfc.xref.PUT.1" title="PUT">3.3.5</a></td>
+                  <td class="left"><a href="#PUT" id="rfc.xref.PUT.1" title="PUT">3.2.5</a></td>
                </tr>
                <tr>
                   <td class="left">DELETE</td>
                   <td class="left">Remove all current representations of the target resource.</td>
-                  <td class="left"><a href="#DELETE" id="rfc.xref.DELETE.1" title="DELETE">3.3.6</a></td>
+                  <td class="left"><a href="#DELETE" id="rfc.xref.DELETE.1" title="DELETE">3.2.6</a></td>
                </tr>
                <tr>
                   <td class="left">CONNECT</td>
                   <td class="left">Establish a tunnel to the server identified by the target resource.</td>
-                  <td class="left"><a href="#CONNECT" id="rfc.xref.CONNECT.1" title="CONNECT">3.3.8</a></td>
+                  <td class="left"><a href="#CONNECT" id="rfc.xref.CONNECT.1" title="CONNECT">3.2.8</a></td>
                </tr>
                <tr>
                   <td class="left">OPTIONS</td>
                   <td class="left">Describe the communication options for the target resource.</td>
-                  <td class="left"><a href="#OPTIONS" id="rfc.xref.OPTIONS.1" title="OPTIONS">3.3.1</a></td>
+                  <td class="left"><a href="#OPTIONS" id="rfc.xref.OPTIONS.1" title="OPTIONS">3.2.1</a></td>
                </tr>
                <tr>
                   <td class="left">TRACE</td>
                   <td class="left">Perform a message loop-back test along the path to the target resource.</td>
-                  <td class="left"><a href="#TRACE" id="rfc.xref.TRACE.1" title="TRACE">3.3.7</a></td>
+                  <td class="left"><a href="#TRACE" id="rfc.xref.TRACE.1" title="TRACE">3.2.7</a></td>
                </tr>
             </tbody>
          </table>
       </div>
-      <p id="rfc.section.3.p.6">The methods GET and HEAD <em class="bcp14">MUST</em> be supported by all general-purpose servers. All other methods are <em class="bcp14">OPTIONAL</em>. If one of the above methods is implemented by a server, the server <em class="bcp14">MUST</em> implement that method according to the semantics defined for it in <a href="#method.definitions" title="Method Definitions">Section&nbsp;3.3</a>.
-      </p>
-      <p id="rfc.section.3.p.7">Additional methods <em class="bcp14">MAY</em> be used in HTTP. New methods <em class="bcp14">SHOULD</em> be registered within the IANA registry, as defined in <a href="#method.registry" title="Method Registry">Section&nbsp;3.2</a>.
+      <p id="rfc.section.3.p.6">The methods GET and HEAD <em class="bcp14">MUST</em> be supported by all general-purpose servers. All other methods are <em class="bcp14">OPTIONAL</em>. When implemented, a server <em class="bcp14">MUST</em> implement the above methods according to the semantics defined for them in <a href="#method.definitions" title="Method Definitions">Section&nbsp;3.2</a>.
+      </p>
+      <p id="rfc.section.3.p.7">Additional methods <em class="bcp14">MAY</em> be used in HTTP; many have already been standardized outside the scope of this specification and registered within the HTTP
+         Method Registry maintained by IANA, as defined in <a href="#method.registry" title="Method Registry">Section&nbsp;11.1</a>.
       </p>
       <p id="rfc.section.3.p.8">The set of methods allowed by a target resource can be listed in an <a href="#header.allow" class="smpl">Allow</a> header field (<a href="#header.allow" id="rfc.xref.header.allow.1" title="Allow">Section&nbsp;10.5</a>). However, the set of allowed methods can change dynamically. When a request message is received that is unrecognized or
@@ -927 +929 @@
       <div id="rfc.iref.s.1"></div>
       <h3 id="rfc.section.3.1.1"><a href="#rfc.section.3.1.1">3.1.1</a>&nbsp;<a id="safe.methods" href="#safe.methods">Safe Methods</a></h3>
-      <p id="rfc.section.3.1.1.p.1">Request methods are considered "<dfn id="safe">safe</dfn>" if their defined semantics are essentially read-only; i.e., the user does not request, and does not expect, any state change
-         on the origin server as a result of applying a safe method to a target resource. Likewise, reasonable use of a safe method
-         is not expected to cause any harm, loss of property, or unusual burden on the origin server.
+      <p id="rfc.section.3.1.1.p.1">Request methods are considered "<dfn id="safe">safe</dfn>" if their defined semantics are essentially read-only; i.e., the client does not request, and does not expect, any state
+         change on the origin server as a result of applying a safe method to a target resource. Likewise, reasonable use of a safe
+         method is not expected to cause any harm, loss of property, or unusual burden on the origin server.
       </p>
       <p id="rfc.section.3.1.1.p.2">This definition of safe methods does not prevent an implementation from including behavior that is potentially harmful, not
-         entirely read-only, or which causes side-effects while invoking a safe method. In fact, some dynamic resources might consider
-         that a feature. What is important, however, is that the user did not request that additional behavior and cannot be held accountable
-         for it. For example, most servers append request information to access log files at the completion of every response, regardless
-         of the method, and that is considered safe even though the log storage might become full and crash the server.
+         entirely read-only, or which causes side-effects while invoking a safe method. What is important, however, is that the client
+         did not request that additional behavior and cannot be held accountable for it. For example, most servers append request information
+         to access log files at the completion of every response, regardless of the method, and that is considered safe even though
+         the log storage might become full and crash the server. Likewise, a safe request initiated by selecting an advertisement on
+         the Web will often have the side-effect of charging an advertising account.
       </p>
       <p id="rfc.section.3.1.1.p.3">The GET, HEAD, OPTIONS, and TRACE request methods are defined to be safe.</p>
-      <p id="rfc.section.3.1.1.p.4">A user agent <em class="bcp14">SHOULD</em> distinguish between safe and unsafe methods when presenting potential actions to a user, such that the user can be made aware
-         of an unsafe action before it is requested. A user agent <em class="bcp14">SHOULD NOT</em> make requests using unsafe methods as an automated result of the user selecting a safe action, unless the instruction for
-         making the unsafe request came from the same origin server as the request target.
-      </p>
-      <p id="rfc.section.3.1.1.p.5">When a resource is constructed such that parameters within the effective request URI have the effect of selecting an action,
+      <p id="rfc.section.3.1.1.p.4">The purpose of distinguishing between safe and unsafe methods is to allow automated retrieval processes (spiders) and cache
+         performance optimization (pre-fetching) to work without fear of causing harm. In addition, it allows a user agent to apply
+         appropriate constraints on the automated use of unsafe methods when processing potentially untrusted content.
+      </p>
+      <p id="rfc.section.3.1.1.p.5">A user agent <em class="bcp14">SHOULD</em> distinguish between safe and unsafe methods when presenting potential actions to a user, such that the user can be made aware
+         of an unsafe action before it is requested.
+      </p>
+      <p id="rfc.section.3.1.1.p.6">When a resource is constructed such that parameters within the effective request URI have the effect of selecting an action,
          it is the resource owner's responsibility to ensure that the action is consistent with the request method semantics. For example,
-         it is common for HTML form-based content editing software to use actions within query parameters, such as "page?do=delete".
-         If the purpose of such a resource is to perform an unsafe action, then the resource <em class="bcp14">MUST</em> disable or disallow that action when it is accessed using a safe request method. Failure to do so will result in unfortunate
-         side-effects when automated processes perform a GET on every URI reference, which often occurs for the sake of link maintenance,
-         pre-fetching, or building a search index.
+         it is common for Web-based content editing software to use actions within query parameters, such as "page?do=delete". If the
+         purpose of such a resource is to perform an unsafe action, then the resource <em class="bcp14">MUST</em> disable or disallow that action when it is accessed using a safe request method. Failure to do so will result in unfortunate
+         side-effects when automated processes perform a GET on every URI reference for the sake of link maintenance, pre-fetching,
+         building a search index, etc.
       </p>
       <div id="rfc.iref.i.1"></div>
       <h3 id="rfc.section.3.1.2"><a href="#rfc.section.3.1.2">3.1.2</a>&nbsp;<a id="idempotent.methods" href="#idempotent.methods">Idempotent Methods</a></h3>
-      <p id="rfc.section.3.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.
-      </p>
-      <h2 id="rfc.section.3.2"><a href="#rfc.section.3.2">3.2</a>&nbsp;<a id="method.registry" href="#method.registry">Method Registry</a></h2>
-      <p id="rfc.section.3.2.p.1">The HTTP Method Registry defines the name space for the method token in the Request line of an HTTP request.</p>
-      <p id="rfc.section.3.2.p.2">Registrations <em class="bcp14">MUST</em> include the following fields: 
-      </p>
-      <ul>
-         <li>Method Name (see <a href="#methods" title="Request Methods">Section&nbsp;3</a>)
-         </li>
-         <li>Safe ("yes" or "no", see <a href="#safe.methods" title="Safe Methods">Section&nbsp;3.1.1</a>)
-         </li>
-         <li>Idempotent ("yes" or "no", see <a href="#safe.methods" title="Safe Methods">Section&nbsp;3.1.1</a>)
-         </li>
-         <li>Pointer to specification text</li>
-      </ul>
-      <p id="rfc.section.3.2.p.3">Values to be added to this name space require IETF Review (see <a href="#RFC5226" id="rfc.xref.RFC5226.1"><cite title="Guidelines for Writing an IANA Considerations Section in RFCs">[RFC5226]</cite></a>, <a href="http://tools.ietf.org/html/rfc5226#section-4.1">Section 4.1</a>).
-      </p>
-      <p id="rfc.section.3.2.p.4">The registry itself is maintained at &lt;<a href="http://www.iana.org/assignments/http-methods">http://www.iana.org/assignments/http-methods</a>&gt;.
-      </p>
-      <h3 id="rfc.section.3.2.1"><a href="#rfc.section.3.2.1">3.2.1</a>&nbsp;<a id="considerations.for.new.methods" href="#considerations.for.new.methods">Considerations for New Methods</a></h3>
-      <p id="rfc.section.3.2.1.p.1">When it is necessary to express new semantics for a HTTP request that aren't specific to a single application or media type,
-         and currently defined methods are inadequate, it might be appropriate to register a new method.
-      </p>
-      <p id="rfc.section.3.2.1.p.2">HTTP methods are generic; that is, they are potentially applicable to any resource, not just one particular media type, "type"
-         of resource, or application. As such, it is preferred that new HTTP methods be registered in a document that isn't specific
-         to a single application, so that this is clear.
-      </p>
-      <p id="rfc.section.3.2.1.p.3">Due to the parsing rules defined in <a href="p1-messaging.html#message.body" title="Message Body">Section 3.3</a> of <a href="#Part1" id="rfc.xref.Part1.7"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>, definitions of HTTP methods cannot prohibit the presence of a message body on either the request or the response message
-         (with responses to HEAD requests being the single exception). Definitions of new methods cannot change this rule, but they
-         can specify that only zero-length bodies (as opposed to absent bodies) are allowed.
-      </p>
-      <p id="rfc.section.3.2.1.p.4">New method definitions need to indicate whether they are safe (<a href="#safe.methods" title="Safe Methods">Section&nbsp;3.1.1</a>), what semantics (if any) the request body has, and whether they are idempotent (<a href="#idempotent.methods" title="Idempotent Methods">Section&nbsp;3.1.2</a>). They also need to state whether they can be cached (<a href="#Part6" id="rfc.xref.Part6.1"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>); in particular under what conditions a cache can store the response, and under what conditions such a stored response can
-         be used to satisfy a subsequent request.
-      </p>
-      <h2 id="rfc.section.3.3"><a href="#rfc.section.3.3">3.3</a>&nbsp;<a id="method.definitions" href="#method.definitions">Method Definitions</a></h2>
-      <h3 id="rfc.section.3.3.1"><a href="#rfc.section.3.3.1">3.3.1</a>&nbsp;<a id="OPTIONS" href="#OPTIONS">OPTIONS</a></h3>
+      <p id="rfc.section.3.1.2.p.1">Request methods are considered "<dfn id="idempotent">idempotent</dfn>" if the intended effect of multiple identical requests is the same as for a single request. PUT, DELETE, and all safe request
+         methods are idempotent.
+      </p>
+      <p id="rfc.section.3.1.2.p.2">Like the definition of safe, the idempotent property only applies to what has been requested by the user; a server is free
+         to log each request separately, retain a revision control history, or implement other non-idempotent side-effects for each
+         idempotent request.
+      </p>
+      <p id="rfc.section.3.1.2.p.3">Idempotent methods are distinguished because the request can be repeated automatically if a communication failure occurs before
+         the client is able to read the server's response. For example, if a client sends a PUT request and the underlying connection
+         is closed before any response is received, then it can establish a new connection and retry the request because it knows that
+         repeating the request will have the same effect even if the original request succeeded. Note, however, that repeated failures
+         would indicate a problem within the server.
+      </p>
+      <div id="rfc.iref.c.2"></div>
+      <h3 id="rfc.section.3.1.3"><a href="#rfc.section.3.1.3">3.1.3</a>&nbsp;<a id="cacheable.methods" href="#cacheable.methods">Cacheable Methods</a></h3>
+      <p id="rfc.section.3.1.3.p.1">Request methods are considered "<dfn id="cacheable">cacheable</dfn>" if it is possible and useful to answer a current client request with a stored response from a prior request. GET and HEAD
+         are defined to be cacheable. In general, safe methods that do not depend on a current or authoritative response are also cacheable,
+         though the overwhelming majority of caches only support GET and HEAD. HTTP requirements for cache behavior and cacheable responses
+         are defined in <a href="#Part6" id="rfc.xref.Part6.1"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>.
+      </p>
+      <h2 id="rfc.section.3.2"><a href="#rfc.section.3.2">3.2</a>&nbsp;<a id="method.definitions" href="#method.definitions">Method Definitions</a></h2>
+      <h3 id="rfc.section.3.2.1"><a href="#rfc.section.3.2.1">3.2.1</a>&nbsp;<a id="OPTIONS" href="#OPTIONS">OPTIONS</a></h3>
       <div id="rfc.iref.o.1"></div>
       <div id="rfc.iref.m.1"></div>
-      <p id="rfc.section.3.3.1.p.1">The OPTIONS method requests information about the communication options available on the request/response chain identified
+      <p id="rfc.section.3.2.1.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.3.3.1.p.2">Responses to the OPTIONS method are not cacheable.</p>
-      <p id="rfc.section.3.3.1.p.3">If the OPTIONS request includes a message body (as indicated by the presence of <a href="p1-messaging.html#header.content-length" class="smpl">Content-Length</a> or <a href="p1-messaging.html#header.transfer-encoding" class="smpl">Transfer-Encoding</a>), then the media type <em class="bcp14">MUST</em> be indicated by a <a href="#header.content-type" class="smpl">Content-Type</a> field. Although this specification does not define any use for such a body, future extensions to HTTP might use the OPTIONS
+      <p id="rfc.section.3.2.1.p.2">Responses to the OPTIONS method are not cacheable.</p>
+      <p id="rfc.section.3.2.1.p.3">If the OPTIONS request includes a message body (as indicated by the presence of <a href="p1-messaging.html#header.content-length" class="smpl">Content-Length</a> or <a href="p1-messaging.html#header.transfer-encoding" class="smpl">Transfer-Encoding</a>), then the media type <em class="bcp14">MUST</em> be indicated by a <a href="#header.content-type" class="smpl">Content-Type</a> field. Although this specification does not define any use for such a body, future extensions to HTTP might use the OPTIONS
          body to make more detailed queries on the server.
       </p>
-      <p id="rfc.section.3.3.1.p.4">If the request-target (<a href="p1-messaging.html#request-target" title="Request Target">Section 5.3</a> of <a href="#Part1" id="rfc.xref.Part1.8"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>) is an asterisk ("*"), the OPTIONS request is intended to apply to the server in general rather than to a specific resource.
+      <p id="rfc.section.3.2.1.p.4">If the request-target (<a href="p1-messaging.html#request-target" title="Request Target">Section 5.3</a> of <a href="#Part1" id="rfc.xref.Part1.7"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>) is an asterisk ("*"), the OPTIONS request is intended to apply to the server in general rather than to a specific resource.
          Since a server's communication options typically depend on the resource, the "*" request is only useful as a "ping" or "no-op"
          type of method; it does nothing beyond allowing the client to test the capabilities of the server. For example, this can be
          used to test a proxy for HTTP/1.1 conformance (or lack thereof).
       </p>
-      <p id="rfc.section.3.3.1.p.5">If the request-target is not an asterisk, the OPTIONS request applies only to the options that are available when communicating
+      <p id="rfc.section.3.2.1.p.5">If the request-target is not an asterisk, the OPTIONS request applies only to the options that are available when communicating
          with that resource.
       </p>
-      <p id="rfc.section.3.3.1.p.6">A <a href="#status.200" class="smpl">200 (OK)</a> response <em class="bcp14">SHOULD</em> include any header fields that indicate optional features implemented by the server and applicable to that resource (e.g., <a href="#header.allow" class="smpl">Allow</a>), possibly including extensions not defined by this specification. The response body, if any, <em class="bcp14">SHOULD</em> also include information about the communication options. The format for such a body is not defined by this specification,
+      <p id="rfc.section.3.2.1.p.6">A <a href="#status.200" class="smpl">200 (OK)</a> response <em class="bcp14">SHOULD</em> include any header fields that indicate optional features implemented by the server and applicable to that resource (e.g., <a href="#header.allow" class="smpl">Allow</a>), possibly including extensions not defined by this specification. The response body, if any, <em class="bcp14">SHOULD</em> also include information about the communication options. The format for such a body is not defined by this specification,
          but might be defined by future extensions to HTTP. Content negotiation <em class="bcp14">MAY</em> be used to select the appropriate response format. If no response body is included, the response <em class="bcp14">MUST</em> include a <a href="p1-messaging.html#header.content-length" class="smpl">Content-Length</a> field with a field-value of "0".
       </p>
-      <p id="rfc.section.3.3.1.p.7">The <a href="#header.max-forwards" class="smpl">Max-Forwards</a> header field <em class="bcp14">MAY</em> be used to target a specific proxy in the request chain (see <a href="#header.max-forwards" id="rfc.xref.header.max-forwards.1" title="Max-Forwards">Section&nbsp;10.14</a>). If no Max-Forwards field is present in the request, then the forwarded request <em class="bcp14">MUST NOT</em> include a Max-Forwards field.
-      </p>
-      <h3 id="rfc.section.3.3.2"><a href="#rfc.section.3.3.2">3.3.2</a>&nbsp;<a id="GET" href="#GET">GET</a></h3>
+      <p id="rfc.section.3.2.1.p.7">The <a href="#header.max-forwards" class="smpl">Max-Forwards</a> header field <em class="bcp14">MAY</em> be used to target a specific proxy in the request chain (see <a href="#header.max-forwards" id="rfc.xref.header.max-forwards.1" title="Max-Forwards">Section&nbsp;10.14</a>). If no Max-Forwards field is present in the request, then the forwarded request <em class="bcp14">MUST NOT</em> include a Max-Forwards field.
+      </p>
+      <h3 id="rfc.section.3.2.2"><a href="#rfc.section.3.2.2">3.2.2</a>&nbsp;<a id="GET" href="#GET">GET</a></h3>
       <div id="rfc.iref.g.2"></div>
       <div id="rfc.iref.m.2"></div>
-      <p id="rfc.section.3.3.2.p.1">The GET method requests transfer of a current representation of the target resource.</p>
-      <p id="rfc.section.3.3.2.p.2">If the target resource is a data-producing process, it is the produced data which shall be returned as the representation
+      <p id="rfc.section.3.2.2.p.1">The GET method requests transfer of a current representation of the target resource.</p>
+      <p id="rfc.section.3.2.2.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.3.3.2.p.3">The semantics of the GET method change to a "conditional GET" if the request message includes an <a href="p4-conditional.html#header.if-modified-since" class="smpl">If-Modified-Since</a>, <a href="p4-conditional.html#header.if-unmodified-since" class="smpl">If-Unmodified-Since</a>, <a href="p4-conditional.html#header.if-match" class="smpl">If-Match</a>, <a href="p4-conditional.html#header.if-none-match" class="smpl">If-None-Match</a>, or <a href="p5-range.html#header.if-range" class="smpl">If-Range</a> header field (<a href="#Part4" id="rfc.xref.Part4.1"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>). A conditional GET requests that the representation be transferred only under the circumstances described by the conditional
+      <p id="rfc.section.3.2.2.p.3">The semantics of the GET method change to a "conditional GET" if the request message includes an <a href="p4-conditional.html#header.if-modified-since" class="smpl">If-Modified-Since</a>, <a href="p4-conditional.html#header.if-unmodified-since" class="smpl">If-Unmodified-Since</a>, <a href="p4-conditional.html#header.if-match" class="smpl">If-Match</a>, <a href="p4-conditional.html#header.if-none-match" class="smpl">If-None-Match</a>, or <a href="p5-range.html#header.if-range" class="smpl">If-Range</a> header field (<a href="#Part4" id="rfc.xref.Part4.1"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>). 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.3.3.2.p.4">The semantics of the GET method change to a "partial GET" if the request message includes a <a href="p5-range.html#range.retrieval.requests" class="smpl">Range</a> header field (<a href="#Part5" id="rfc.xref.Part5.1"><cite title="HTTP/1.1, part 5: Range Requests">[Part5]</cite></a>). 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.2"><cite title="HTTP/1.1, part 5: Range Requests">[Part5]</cite></a>. The partial GET request is intended to reduce unnecessary network usage by allowing partially-retrieved representations
+      <p id="rfc.section.3.2.2.p.4">The semantics of the GET method change to a "partial GET" if the request message includes a <a href="p5-range.html#range.retrieval.requests" class="smpl">Range</a> header field (<a href="#Part5" id="rfc.xref.Part5.1"><cite title="HTTP/1.1, part 5: Range Requests">[Part5]</cite></a>). 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.2"><cite title="HTTP/1.1, part 5: Range Requests">[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.3.3.2.p.5">Bodies on GET requests have no defined semantics. Note that sending a body on a GET request might cause some existing implementations
+      <p id="rfc.section.3.2.2.p.5">Bodies on GET requests have no defined semantics. Note that sending a body on a GET request might cause some existing implementations
          to reject the request.
       </p>
-      <p id="rfc.section.3.3.2.p.6">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.2"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>).
-      </p>
-      <p id="rfc.section.3.3.2.p.7">See <a href="#encoding.sensitive.information.in.uris" title="Encoding Sensitive Information in URIs">Section&nbsp;12.2</a> for security considerations when used for forms.
-      </p>
-      <h3 id="rfc.section.3.3.3"><a href="#rfc.section.3.3.3">3.3.3</a>&nbsp;<a id="HEAD" href="#HEAD">HEAD</a></h3>
+      <p id="rfc.section.3.2.2.p.6">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.2"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>).
+      </p>
+      <p id="rfc.section.3.2.2.p.7">See <a href="#encoding.sensitive.information.in.uris" title="Encoding Sensitive Information in URIs">Section&nbsp;12.2</a> for security considerations when used for forms.
+      </p>
+      <h3 id="rfc.section.3.2.3"><a href="#rfc.section.3.2.3">3.2.3</a>&nbsp;<a id="HEAD" href="#HEAD">HEAD</a></h3>
       <div id="rfc.iref.h.1"></div>
       <div id="rfc.iref.m.3"></div>
-      <p id="rfc.section.3.3.3.p.1">The HEAD method is identical to GET except that the server <em class="bcp14">MUST NOT</em> return a message body in the response. The metadata contained in the HTTP header fields in response to a HEAD request <em class="bcp14">SHOULD</em> be identical to the information sent in response to a GET request. This method can be used for obtaining metadata about the
+      <p id="rfc.section.3.2.3.p.1">The HEAD method is identical to GET except that the server <em class="bcp14">MUST NOT</em> return a message body in the response. The metadata contained in the HTTP header fields in response to a HEAD request <em class="bcp14">SHOULD</em> be identical to the information sent in response to a GET request. This method can be used for obtaining metadata about the
          representation implied by the request without transferring the representation body. This method is often used for testing
          hypertext links for validity, accessibility, and recent modification.
       </p>
-      <p id="rfc.section.3.3.3.p.2">The response to a HEAD request is cacheable and <em class="bcp14">MAY</em> be used to satisfy a subsequent HEAD request. It also has potential side effects on previously stored responses to GET; see <a href="p6-cache.html#head.effects" title="Updating Caches with HEAD Responses">Section 5</a> of <a href="#Part6" id="rfc.xref.Part6.3"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>.
-      </p>
-      <p id="rfc.section.3.3.3.p.3">Bodies on HEAD requests have no defined semantics. Note that sending a body on a HEAD request might cause some existing implementations
+      <p id="rfc.section.3.2.3.p.2">The response to a HEAD request is cacheable and <em class="bcp14">MAY</em> be used to satisfy a subsequent HEAD request. It also has potential side effects on previously stored responses to GET; see <a href="p6-cache.html#head.effects" title="Updating Caches with HEAD Responses">Section 5</a> of <a href="#Part6" id="rfc.xref.Part6.3"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>.
+      </p>
+      <p id="rfc.section.3.2.3.p.3">Bodies on HEAD requests have no defined semantics. Note that sending a body on a HEAD request might cause some existing implementations
          to reject the request.
       </p>
       <div id="rfc.iref.p.1"></div>
       <div id="rfc.iref.m.4"></div>
-      <h3 id="rfc.section.3.3.4"><a href="#rfc.section.3.3.4">3.3.4</a>&nbsp;<a id="POST" href="#POST">POST</a></h3>
-      <p id="rfc.section.3.3.4.p.1">The POST method requests that the origin server accept the representation enclosed in the request as data to be processed
+      <h3 id="rfc.section.3.2.4"><a href="#rfc.section.3.2.4">3.2.4</a>&nbsp;<a id="POST" href="#POST">POST</a></h3>
+      <p id="rfc.section.3.2.4.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>
@@ -1058 +1047 @@
          <li>Extending a database through an append operation.</li>
       </ul>
-      <p id="rfc.section.3.3.4.p.2">The actual function performed by the POST method is determined by the server and is usually dependent on the effective request
+      <p id="rfc.section.3.2.4.p.2">The actual function performed by the POST method is determined by the server and is usually dependent on the effective request
          URI.
       </p>
-      <p id="rfc.section.3.3.4.p.3">The action performed by the POST method might not result in a resource that can be identified by a URI. In this case, either <a href="#status.200" class="smpl">200 (OK)</a> or <a href="#status.204" class="smpl">204 (No Content)</a> is the appropriate response status code, depending on whether or not the response includes a representation that describes
+      <p id="rfc.section.3.2.4.p.3">The action performed by the POST method might not result in a resource that can be identified by a URI. In this case, either <a href="#status.200" class="smpl">200 (OK)</a> or <a href="#status.204" class="smpl">204 (No Content)</a> is the appropriate response status code, depending on whether or not the response includes a representation that describes
          the result.
       </p>
-      <p id="rfc.section.3.3.4.p.4">If a resource has been created on the origin server, the response <em class="bcp14">SHOULD</em> be <a href="#status.201" class="smpl">201 (Created)</a> and contain a representation which describes the status of the request and refers to the new resource, and a <a href="#header.location" class="smpl">Location</a> header field (see <a href="#header.location" id="rfc.xref.header.location.1" title="Location">Section&nbsp;10.13</a>).
-      </p>
-      <p id="rfc.section.3.3.4.p.5">Responses to POST requests are only cacheable when they include explicit freshness information (see <a href="p6-cache.html#calculating.freshness.lifetime" title="Calculating Freshness Lifetime">Section 4.1.1</a> of <a href="#Part6" id="rfc.xref.Part6.4"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>). A cached POST response with a <a href="#header.content-location" class="smpl">Content-Location</a> header field (see <a href="#header.content-location" id="rfc.xref.header.content-location.1" title="Content-Location">Section&nbsp;10.8</a>) whose value is the effective Request URI <em class="bcp14">MAY</em> be used to satisfy subsequent GET and HEAD requests.
-      </p>
-      <p id="rfc.section.3.3.4.p.6">Note that POST caching is not widely implemented. However, the <a href="#status.303" class="smpl">303 (See Other)</a> response can be used to direct the user agent to retrieve a cacheable representation of the resource.
-      </p>
-      <h3 id="rfc.section.3.3.5"><a href="#rfc.section.3.3.5">3.3.5</a>&nbsp;<a id="PUT" href="#PUT">PUT</a></h3>
+      <p id="rfc.section.3.2.4.p.4">If a resource has been created on the origin server, the response <em class="bcp14">SHOULD</em> be <a href="#status.201" class="smpl">201 (Created)</a> and contain a representation which describes the status of the request and refers to the new resource, and a <a href="#header.location" class="smpl">Location</a> header field (see <a href="#header.location" id="rfc.xref.header.location.1" title="Location">Section&nbsp;10.13</a>).
+      </p>
+      <p id="rfc.section.3.2.4.p.5">Responses to POST requests are only cacheable when they include explicit freshness information (see <a href="p6-cache.html#calculating.freshness.lifetime" title="Calculating Freshness Lifetime">Section 4.1.1</a> of <a href="#Part6" id="rfc.xref.Part6.4"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>). A cached POST response with a <a href="#header.content-location" class="smpl">Content-Location</a> header field (see <a href="#header.content-location" id="rfc.xref.header.content-location.1" title="Content-Location">Section&nbsp;10.8</a>) whose value is the effective Request URI <em class="bcp14">MAY</em> be used to satisfy subsequent GET and HEAD requests.
+      </p>
+      <p id="rfc.section.3.2.4.p.6">Note that POST caching is not widely implemented. However, the <a href="#status.303" class="smpl">303 (See Other)</a> response can be used to direct the user agent to retrieve a cacheable representation of the resource.
+      </p>
+      <h3 id="rfc.section.3.2.5"><a href="#rfc.section.3.2.5">3.2.5</a>&nbsp;<a id="PUT" href="#PUT">PUT</a></h3>
       <div id="rfc.iref.p.2"></div>
       <div id="rfc.iref.m.5"></div>
-      <p id="rfc.section.3.3.5.p.1">The PUT method requests that the state of the target resource be created or replaced with the state defined by the representation
+      <p id="rfc.section.3.2.5.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 <a href="#status.200" class="smpl">200 (OK)</a> response. However, there is no guarantee that such a state change will be observable, since the target resource might be acted
@@ -1080 +1069 @@
          by the origin server.
       </p>
-      <p id="rfc.section.3.3.5.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 <a href="#status.201" class="smpl">201 (Created)</a> response. If the target resource does have a current representation and that representation is successfully modified in accordance
+      <p id="rfc.section.3.2.5.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 <a href="#status.201" class="smpl">201 (Created)</a> response. If the target resource does have a current representation and that representation is successfully modified in accordance
          with the state of the enclosed representation, then either a <a href="#status.200" class="smpl">200 (OK)</a> or <a href="#status.204" class="smpl">204 (No Content)</a> response <em class="bcp14">SHOULD</em> be sent to indicate successful completion of the request.
       </p>
-      <p id="rfc.section.3.3.5.p.3">Unrecognized header fields <em class="bcp14">SHOULD</em> be ignored (i.e., not saved as part of the resource state).
-      </p>
-      <p id="rfc.section.3.3.5.p.4">An origin server <em class="bcp14">SHOULD</em> verify that the PUT representation is consistent with any constraints which the server has for the target resource that cannot
+      <p id="rfc.section.3.2.5.p.3">Unrecognized header fields <em class="bcp14">SHOULD</em> be ignored (i.e., not saved as part of the resource state).
+      </p>
+      <p id="rfc.section.3.2.5.p.4">An origin server <em class="bcp14">SHOULD</em> verify that the PUT representation is consistent with any constraints which the server has for the target resource that cannot
          or will not be changed by the PUT. This is particularly important when the origin server uses internal configuration information
          related to the URI in order to set the values for representation metadata on GET responses. When a PUT representation is inconsistent
@@ -1091 +1080 @@
          appropriate error message containing sufficient information to explain why the representation is unsuitable. The <a href="#status.409" class="smpl">409 (Conflict)</a> or <a href="#status.415" class="smpl">415 (Unsupported Media Type)</a> status codes are suggested, with the latter being specific to constraints on <a href="#header.content-type" class="smpl">Content-Type</a> values.
       </p>
-      <p id="rfc.section.3.3.5.p.5">For example, if the target resource is configured to always have a <a href="#header.content-type" class="smpl">Content-Type</a> of "text/html" and the representation being PUT has a Content-Type of "image/jpeg", then the origin server <em class="bcp14">SHOULD</em> do one of: 
+      <p id="rfc.section.3.2.5.p.5">For example, if the target resource is configured to always have a <a href="#header.content-type" class="smpl">Content-Type</a> of "text/html" and the representation being PUT has a Content-Type of "image/jpeg", then the origin server <em class="bcp14">SHOULD</em> do one of: 
       </p>
       <ol class="la">
@@ -1102 +1091 @@
          </li>
       </ol>
-      <p id="rfc.section.3.3.5.p.6">HTTP does not define exactly how a PUT method affects the state of an origin server beyond what can be expressed by the intent
+      <p id="rfc.section.3.2.5.p.6">HTTP does not define exactly how a PUT method affects the state of an origin server beyond what can be expressed by the intent
          of the user agent request and the semantics of the origin server response. It does not define what a resource might be, in
          any sense of that word, beyond the interface provided via HTTP. It does not define how resource state is "stored", nor how
@@ -1109 +1098 @@
          the server.
       </p>
-      <p id="rfc.section.3.3.5.p.7">The fundamental difference between the POST and PUT methods is highlighted by the different intent for the target resource.
+      <p id="rfc.section.3.2.5.p.7">The fundamental difference between the POST and PUT methods is highlighted by the different intent for the target resource.
          The target resource in a POST request is intended to handle the enclosed representation as a data-accepting process, such
          as for a gateway to some other protocol or a document that accepts annotations. In contrast, the target resource in a PUT
@@ -1115 +1104 @@
          and visible to intermediaries, even though the exact effect is only known by the origin server.
       </p>
-      <p id="rfc.section.3.3.5.p.8">Proper interpretation of a PUT request presumes that the user agent knows what target resource is desired. A service that
+      <p id="rfc.section.3.2.5.p.8">Proper interpretation of a PUT request presumes that the user agent knows what target resource is desired. A service that
          is intended to select a proper URI on behalf of the client, after receiving a state-changing request, <em class="bcp14">SHOULD</em> be implemented using the POST method rather than PUT. If the origin server will not make the requested PUT state change to
          the target resource and instead wishes to have it applied to a different resource, such as when the resource has been moved
          to a different URI, then the origin server <em class="bcp14">MUST</em> send a <a href="#status.301" class="smpl">301 (Moved Permanently)</a> response; the user agent <em class="bcp14">MAY</em> then make its own decision regarding whether or not to redirect the request.
       </p>
-      <p id="rfc.section.3.3.5.p.9">A PUT request applied to the target resource <em class="bcp14">MAY</em> have side-effects on other resources. For example, an article might have a URI for identifying "the current version" (a resource)
+      <p id="rfc.section.3.2.5.p.9">A PUT request applied to the target resource <em class="bcp14">MAY</em> have side-effects on other resources. For example, an article might have a URI for identifying "the current version" (a resource)
          which is separate from the URIs identifying each particular version (different resources that at one point shared the same
          state as the current version resource). A successful PUT request on "the current version" URI might therefore create a new
@@ -1126 +1115 @@
          the related resources.
       </p>
-      <p id="rfc.section.3.3.5.p.10">An origin server <em class="bcp14">SHOULD</em> reject any PUT request that contains a <a href="p5-range.html#header.content-range" class="smpl">Content-Range</a> header field (<a href="p5-range.html#header.content-range" title="Content-Range">Section 5.2</a> of <a href="#Part5" id="rfc.xref.Part5.3"><cite title="HTTP/1.1, part 5: Range Requests">[Part5]</cite></a>), since it might be misinterpreted as partial content (or might be partial content that is being mistakenly PUT as a full
+      <p id="rfc.section.3.2.5.p.10">An origin server <em class="bcp14">SHOULD</em> reject any PUT request that contains a <a href="p5-range.html#header.content-range" class="smpl">Content-Range</a> header field (<a href="p5-range.html#header.content-range" title="Content-Range">Section 5.2</a> of <a href="#Part5" id="rfc.xref.Part5.3"><cite title="HTTP/1.1, part 5: Range Requests">[Part5]</cite></a>), since it might be misinterpreted as partial content (or might be partial content that is being mistakenly PUT as a full
          representation). Partial content updates are possible by targeting a separately identified resource with state that overlaps
          a portion of the larger resource, or by using a different method that has been specifically defined for partial updates (for
          example, the PATCH method defined in <a href="#RFC5789" id="rfc.xref.RFC5789.1"><cite title="PATCH Method for HTTP">[RFC5789]</cite></a>).
       </p>
-      <p id="rfc.section.3.3.5.p.11">Responses to the PUT method are not cacheable. If a PUT request passes through a cache that has one or more stored responses
+      <p id="rfc.section.3.2.5.p.11">Responses to the PUT method are not cacheable. If a PUT request passes through a cache that has one or more stored responses
          for the effective request URI, those stored responses will be invalidated (see <a href="p6-cache.html#invalidation.after.updates.or.deletions" title="Request Methods that Invalidate">Section 6</a> of <a href="#Part6" id="rfc.xref.Part6.5"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>).
       </p>
-      <h3 id="rfc.section.3.3.6"><a href="#rfc.section.3.3.6">3.3.6</a>&nbsp;<a id="DELETE" href="#DELETE">DELETE</a></h3>
+      <h3 id="rfc.section.3.2.6"><a href="#rfc.section.3.2.6">3.2.6</a>&nbsp;<a id="DELETE" href="#DELETE">DELETE</a></h3>
       <div id="rfc.iref.d.1"></div>
       <div id="rfc.iref.m.6"></div>
-      <p id="rfc.section.3.3.6.p.1">The DELETE method requests that the origin server delete the target resource. This method <em class="bcp14">MAY</em> be overridden by human intervention (or other means) on the origin server. The client cannot be guaranteed that the operation
+      <p id="rfc.section.3.2.6.p.1">The DELETE method requests that the origin server delete the target resource. This method <em class="bcp14">MAY</em> be overridden by human intervention (or other means) on the origin server. The client cannot be guaranteed that the operation
          has been carried out, even if the status code returned from the origin server indicates that the action has been completed
          successfully. However, the server <em class="bcp14">SHOULD NOT</em> indicate success unless, at the time the response is given, it intends to delete the resource or move it to an inaccessible
          location.
       </p>
-      <p id="rfc.section.3.3.6.p.2">A successful response <em class="bcp14">SHOULD</em> be <a href="#status.200" class="smpl">200 (OK)</a> if the response includes a representation describing the status, <a href="#status.202" class="smpl">202 (Accepted)</a> if the action has not yet been enacted, or <a href="#status.204" class="smpl">204 (No Content)</a> if the action has been enacted but the response does not include a representation.
-      </p>
-      <p id="rfc.section.3.3.6.p.3">Bodies on DELETE requests have no defined semantics. Note that sending a body on a DELETE request might cause some existing
+      <p id="rfc.section.3.2.6.p.2">A successful response <em class="bcp14">SHOULD</em> be <a href="#status.200" class="smpl">200 (OK)</a> if the response includes a representation describing the status, <a href="#status.202" class="smpl">202 (Accepted)</a> if the action has not yet been enacted, or <a href="#status.204" class="smpl">204 (No Content)</a> if the action has been enacted but the response does not include a representation.
+      </p>
+      <p id="rfc.section.3.2.6.p.3">Bodies on DELETE requests have no defined semantics. Note that sending a body on a DELETE request might cause some existing
          implementations to reject the request.
       </p>
-      <p id="rfc.section.3.3.6.p.4">Responses to the DELETE method are not cacheable. If a DELETE request passes through a cache that has one or more stored responses
+      <p id="rfc.section.3.2.6.p.4">Responses to the DELETE method are not cacheable. If a DELETE request passes through a cache that has one or more stored responses
          for the effective request URI, those stored responses will be invalidated (see <a href="p6-cache.html#invalidation.after.updates.or.deletions" title="Request Methods that Invalidate">Section 6</a> of <a href="#Part6" id="rfc.xref.Part6.6"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>).
       </p>
-      <h3 id="rfc.section.3.3.7"><a href="#rfc.section.3.3.7">3.3.7</a>&nbsp;<a id="TRACE" href="#TRACE">TRACE</a></h3>
+      <h3 id="rfc.section.3.2.7"><a href="#rfc.section.3.2.7">3.2.7</a>&nbsp;<a id="TRACE" href="#TRACE">TRACE</a></h3>
       <div id="rfc.iref.t.1"></div>
       <div id="rfc.iref.m.7"></div>
-      <p id="rfc.section.3.3.7.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 <a href="#status.200" class="smpl">200 (OK)</a> response. The final recipient is either the origin server or the first proxy to receive a <a href="#header.max-forwards" class="smpl">Max-Forwards</a> value of zero (0) in the request (see <a href="#header.max-forwards" id="rfc.xref.header.max-forwards.2" title="Max-Forwards">Section&nbsp;10.14</a>). A TRACE request <em class="bcp14">MUST NOT</em> include a message body.
-      </p>
-      <p id="rfc.section.3.3.7.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
-         or diagnostic information. The value of the <a href="p1-messaging.html#header.via" class="smpl">Via</a> header field (<a href="p1-messaging.html#header.via" title="Via">Section 5.7</a> of <a href="#Part1" id="rfc.xref.Part1.9"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>) is of particular interest, since it acts as a trace of the request chain. Use of the <a href="#header.max-forwards" class="smpl">Max-Forwards</a> header field allows the client to limit the length of the request chain, which is useful for testing a chain of proxies forwarding
+      <p id="rfc.section.3.2.7.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 <a href="#status.200" class="smpl">200 (OK)</a> response. The final recipient is either the origin server or the first proxy to receive a <a href="#header.max-forwards" class="smpl">Max-Forwards</a> value of zero (0) in the request (see <a href="#header.max-forwards" id="rfc.xref.header.max-forwards.2" title="Max-Forwards">Section&nbsp;10.14</a>). A TRACE request <em class="bcp14">MUST NOT</em> include a message body.
+      </p>
+      <p id="rfc.section.3.2.7.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
+         or diagnostic information. The value of the <a href="p1-messaging.html#header.via" class="smpl">Via</a> header field (<a href="p1-messaging.html#header.via" title="Via">Section 5.7</a> of <a href="#Part1" id="rfc.xref.Part1.8"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>) is of particular interest, since it acts as a trace of the request chain. Use of the <a href="#header.max-forwards" class="smpl">Max-Forwards</a> header field allows the client to limit the length of the request chain, which is useful for testing a chain of proxies forwarding
          messages in an infinite loop.
       </p>
-      <p id="rfc.section.3.3.7.p.3">If the request is valid, the response <em class="bcp14">SHOULD</em> have a <a href="#header.content-type" class="smpl">Content-Type</a> of "message/http" (see <a href="p1-messaging.html#internet.media.type.message.http" title="Internet Media Type message/http">Section 7.3.1</a> of <a href="#Part1" id="rfc.xref.Part1.10"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>) and contain a message body that encloses a copy of the entire request message. Responses to the TRACE method are not cacheable.
-      </p>
-      <div id="rfc.iref.c.2"></div>
+      <p id="rfc.section.3.2.7.p.3">If the request is valid, the response <em class="bcp14">SHOULD</em> have a <a href="#header.content-type" class="smpl">Content-Type</a> of "message/http" (see <a href="p1-messaging.html#internet.media.type.message.http" title="Internet Media Type message/http">Section 7.3.1</a> of <a href="#Part1" id="rfc.xref.Part1.9"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>) and contain a message body that encloses a copy of the entire request message. Responses to the TRACE method are not cacheable.
+      </p>
+      <div id="rfc.iref.c.3"></div>
       <div id="rfc.iref.m.8"></div>
-      <h3 id="rfc.section.3.3.8"><a href="#rfc.section.3.3.8">3.3.8</a>&nbsp;<a id="CONNECT" href="#CONNECT">CONNECT</a></h3>
-      <p id="rfc.section.3.3.8.p.1">The CONNECT method requests that the proxy establish a tunnel to the request-target and, if successful, thereafter restrict
+      <h3 id="rfc.section.3.2.8"><a href="#rfc.section.3.2.8">3.2.8</a>&nbsp;<a id="CONNECT" href="#CONNECT">CONNECT</a></h3>
+      <p id="rfc.section.3.2.8.p.1">The CONNECT method requests that the proxy establish a tunnel to the request-target and, if successful, thereafter restrict
          its behavior to blind forwarding of packets until the connection is closed.
       </p>
-      <p id="rfc.section.3.3.8.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 5.3</a> of <a href="#Part1" id="rfc.xref.Part1.11"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[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.
+      <p id="rfc.section.3.2.8.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 5.3</a> of <a href="#Part1" id="rfc.xref.Part1.10"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[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>
@@ -1173 +1162 @@
 Host: server.example.com:80
 
-</pre><p id="rfc.section.3.3.8.p.4">Any <a href="#status.2xx" class="smpl">2xx (Successful)</a> response to a CONNECT request indicates that the proxy has established a connection to the requested host and port, and has
+</pre><p id="rfc.section.3.2.8.p.4">Any <a href="#status.2xx" class="smpl">2xx (Successful)</a> response to a CONNECT request indicates that the proxy has established a connection to the requested host and port, and has
          switched to tunneling the current connection to that server connection. The tunneled data from the server begins immediately
          after the blank line that concludes the successful response's header block.
       </p>
-      <p id="rfc.section.3.3.8.p.5">A server <em class="bcp14">SHOULD NOT</em> send any <a href="p1-messaging.html#header.transfer-encoding" class="smpl">Transfer-Encoding</a> or <a href="p1-messaging.html#header.content-length" class="smpl">Content-Length</a> header fields in a successful response. A client <em class="bcp14">MUST</em> ignore any Content-Length or Transfer-Encoding header fields received in a successful response.
-      </p>
-      <p id="rfc.section.3.3.8.p.6">Any response other than a successful response indicates that the tunnel has not yet been formed and that the connection remains
+      <p id="rfc.section.3.2.8.p.5">A server <em class="bcp14">SHOULD NOT</em> send any <a href="p1-messaging.html#header.transfer-encoding" class="smpl">Transfer-Encoding</a> or <a href="p1-messaging.html#header.content-length" class="smpl">Content-Length</a> header fields in a successful response. A client <em class="bcp14">MUST</em> ignore any Content-Length or Transfer-Encoding header fields received in a successful response.
+      </p>
+      <p id="rfc.section.3.2.8.p.6">Any response other than a successful response indicates that the tunnel has not yet been formed and that the connection remains
          governed by HTTP.
       </p>
-      <p id="rfc.section.3.3.8.p.7">Proxy authentication might be used to establish the authority to create a tunnel:</p>
+      <p id="rfc.section.3.2.8.p.7">Proxy authentication might be used to establish the authority to create a tunnel:</p>
       <div id="rfc.figure.u.3"></div><pre class="text2">CONNECT server.example.com:80 HTTP/1.1
 Host: server.example.com:80
 Proxy-Authorization: basic aGVsbG86d29ybGQ=
 
-</pre><p id="rfc.section.3.3.8.p.9">A message body on a CONNECT request has no defined semantics. Sending a body on a CONNECT request might cause existing implementations
+</pre><p id="rfc.section.3.2.8.p.9">A message body on a CONNECT request has no defined semantics. Sending a body on a CONNECT request might cause existing implementations
          to reject the request.
       </p>
-      <p id="rfc.section.3.3.8.p.10">Similar to a pipelined HTTP/1.1 request, data to be tunneled from client to server <em class="bcp14">MAY</em> be sent immediately after the request (before a response is received). The usual caveats also apply: data can be discarded
+      <p id="rfc.section.3.2.8.p.10">Similar to a pipelined HTTP/1.1 request, data to be tunneled from client to server <em class="bcp14">MAY</em> be sent immediately after the request (before a response is received). The usual caveats also apply: data can be discarded
          if the eventual response is negative, and the connection can be reset with no response if more than one TCP segment is outstanding.
       </p>
-      <p id="rfc.section.3.3.8.p.11">It might be the case that the proxy itself can only reach the requested origin server through another proxy. In this case,
+      <p id="rfc.section.3.2.8.p.11">It might be the case that the proxy itself can only reach the requested origin server through another proxy. In this case,
          the first proxy <em class="bcp14">SHOULD</em> make a CONNECT request of that next proxy, requesting a tunnel to the authority. A proxy <em class="bcp14">MUST NOT</em> respond with any <a href="#status.2xx" class="smpl">2xx</a> status code unless it has either a direct or tunnel connection established to the authority.
       </p>
-      <p id="rfc.section.3.3.8.p.12">If at any point either one of the peers gets disconnected, any outstanding data that came from that peer will be passed to
+      <p id="rfc.section.3.2.8.p.12">If at any point either one of the peers gets disconnected, any outstanding data that came from that peer will be passed to
          the other one, and after that also the other connection will be terminated by the proxy. If there is outstanding data to that
          peer undelivered, that data will be discarded.
       </p>
-      <p id="rfc.section.3.3.8.p.13">An origin server which receives a CONNECT request for itself <em class="bcp14">MAY</em> respond with a <a href="#status.2xx" class="smpl">2xx</a> status code to indicate that a connection is established. However, most origin servers do not implement CONNECT.
+      <p id="rfc.section.3.2.8.p.13">An origin server which receives a CONNECT request for itself <em class="bcp14">MAY</em> respond with a <a href="#status.2xx" class="smpl">2xx</a> status code to indicate that a connection is established. However, most origin servers do not implement CONNECT.
       </p>
       <h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a>&nbsp;<a id="header.fields" href="#header.fields">Header Fields</a></h1>
       <p id="rfc.section.4.p.1">Header fields are key value pairs that can be used to communicate data about the message, its payload, the target resource,
-         or about the connection itself (i.e., control data). See <a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.12"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a> for a general definition of their syntax.
+         or about the connection itself (i.e., control data). See <a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.11"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a> for a general definition of their syntax.
       </p>
       <h2 id="rfc.section.4.1"><a href="#rfc.section.4.1">4.1</a>&nbsp;<a id="request.fields" href="#request.fields">Request-modifier Header Fields</a></h2>
@@ -1216 +1205 @@
          with "X-" if they are to be registered (either immediately or in the future).
       </p>
-      <p id="rfc.section.4.5.p.3">New header field values typically have their syntax defined using ABNF (<a href="#RFC5234" id="rfc.xref.RFC5234.2"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a>), using the extension defined in <a href="p1-messaging.html#abnf.extension" title="ABNF list extension: #rule">Appendix B</a> of <a href="#Part1" id="rfc.xref.Part1.13"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a> as necessary, and are usually constrained to the range of ASCII characters. Header fields needing a greater range of characters
+      <p id="rfc.section.4.5.p.3">New header field values typically have their syntax defined using ABNF (<a href="#RFC5234" id="rfc.xref.RFC5234.2"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a>), using the extension defined in <a href="p1-messaging.html#abnf.extension" title="ABNF list extension: #rule">Appendix B</a> of <a href="#Part1" id="rfc.xref.Part1.12"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a> as necessary, and are usually constrained to the range of ASCII characters. Header fields needing a greater range of characters
          can use an encoding such as the one defined in <a href="#RFC5987" id="rfc.xref.RFC5987.1"><cite title="Character Set and Language Encoding for Hypertext Transfer Protocol (HTTP) Header Field Parameters">[RFC5987]</cite></a>.
       </p>
       <p id="rfc.section.4.5.p.4">Because commas (",") are used as a generic delimiter between field-values, they need to be treated with care if they are allowed
          in the field-value's payload. Typically, components that might contain a comma are protected with double-quotes using the
-         quoted-string ABNF production (<a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.4</a> of <a href="#Part1" id="rfc.xref.Part1.14"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>).
+         quoted-string ABNF production (<a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.4</a> of <a href="#Part1" id="rfc.xref.Part1.13"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>).
       </p>
       <p id="rfc.section.4.5.p.5">For example, a textual date and a URI (either of which might contain a comma) could be safely carried in field-values like
@@ -1239 +1228 @@
       <ul>
          <li>
-            <p>Whether the field is a single value, or whether it can be a list (delimited by commas; see <a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.15"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>).
+            <p>Whether the field is a single value, or whether it can be a list (delimited by commas; see <a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.14"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>).
             </p>
             <p>If it does not use the list syntax, document how to treat messages where the header field occurs multiple times (a sensible
@@ -1255 +1244 @@
          </li>
          <li>
-            <p>Whether it is appropriate to list the field-name in the <a href="p1-messaging.html#header.connection" class="smpl">Connection</a> header field (i.e., if the header field is to be hop-by-hop, see <a href="p1-messaging.html#header.connection" title="Connection">Section 6.1</a> of <a href="#Part1" id="rfc.xref.Part1.16"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>).
+            <p>Whether it is appropriate to list the field-name in the <a href="p1-messaging.html#header.connection" class="smpl">Connection</a> header field (i.e., if the header field is to be hop-by-hop, see <a href="p1-messaging.html#header.connection" title="Connection">Section 6.1</a> of <a href="#Part1" id="rfc.xref.Part1.15"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>).
             </p>
          </li>
@@ -1266 +1255 @@
          </li>
          <li>
-            <p>Whether the header field is useful or allowable in trailers (see <a href="p1-messaging.html#chunked.encoding" title="Chunked Transfer Coding">Section 4.1</a> of <a href="#Part1" id="rfc.xref.Part1.17"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>).
+            <p>Whether the header field is useful or allowable in trailers (see <a href="p1-messaging.html#chunked.encoding" title="Chunked Transfer Coding">Section 4.1</a> of <a href="#Part1" id="rfc.xref.Part1.16"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>).
             </p>
          </li>
@@ -1317 +1306 @@
                <tr>
                   <td class="left">Host</td>
-                  <td class="left"><a href="p1-messaging.html#header.host" title="Host">Section 5.4</a> of <a href="#Part1" id="rfc.xref.Part1.18"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a></td>
+                  <td class="left"><a href="p1-messaging.html#header.host" title="Host">Section 5.4</a> of <a href="#Part1" id="rfc.xref.Part1.17"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a></td>
                </tr>
                <tr>
@@ -1357 +1346 @@
                <tr>
                   <td class="left">TE</td>
-                  <td class="left"><a href="p1-messaging.html#header.te" title="TE">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.19"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a></td>
+                  <td class="left"><a href="p1-messaging.html#header.te" title="TE">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.18"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a></td>
                </tr>
                <tr>
@@ -1368 +1357 @@
       <h2 id="rfc.section.4.7"><a href="#rfc.section.4.7">4.7</a>&nbsp;<a id="response.header.fields" href="#response.header.fields">Response Header Fields</a></h2>
       <p id="rfc.section.4.7.p.1">The response header fields allow the server to pass additional information about the response which cannot be placed in the
-         status-line. These header fields give information about the server and about further access to the target resource (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 5.5</a> of <a href="#Part1" id="rfc.xref.Part1.20"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>).
+         status-line. These header fields give information about the server and about further access to the target resource (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 5.5</a> of <a href="#Part1" id="rfc.xref.Part1.19"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>).
       </p>
       <div id="rfc.table.u.2">
@@ -1676 +1665 @@
       <h2 id="rfc.section.5.2"><a href="#rfc.section.5.2">5.2</a>&nbsp;<a id="status.code.registry" href="#status.code.registry">Status Code Registry</a></h2>
       <p id="rfc.section.5.2.p.1">The HTTP Status Code Registry defines the name space for the status-code token in the status-line of an HTTP response.</p>
-      <p id="rfc.section.5.2.p.2">Values to be added to this name space require IETF Review (see <a href="#RFC5226" id="rfc.xref.RFC5226.2"><cite title="Guidelines for Writing an IANA Considerations Section in RFCs">[RFC5226]</cite></a>, <a href="http://tools.ietf.org/html/rfc5226#section-4.1">Section 4.1</a>).
+      <p id="rfc.section.5.2.p.2">Values to be added to this name space require IETF Review (see <a href="#RFC5226" id="rfc.xref.RFC5226.1"><cite title="Guidelines for Writing an IANA Considerations Section in RFCs">[RFC5226]</cite></a>, <a href="http://tools.ietf.org/html/rfc5226#section-4.1">Section 4.1</a>).
       </p>
       <p id="rfc.section.5.2.p.3">The registry itself is maintained at &lt;<a href="http://www.iana.org/assignments/http-status-codes">http://www.iana.org/assignments/http-status-codes</a>&gt;.
@@ -1698 +1687 @@
       </p>
       <h2 id="rfc.section.5.3"><a href="#rfc.section.5.3">5.3</a>&nbsp;<a id="status.1xx" href="#status.1xx">Informational 1xx</a></h2>
-      <div id="rfc.iref.20"></div>
+      <div id="rfc.iref.21"></div>
       <div id="rfc.iref.s.2"></div>
       <p id="rfc.section.5.3.p.1">This class of status code indicates a provisional response, consisting only of the status-line and optional header fields,
@@ -1711 +1700 @@
          a request, then it need not forward the corresponding <a href="#status.100" class="smpl">100 (Continue)</a> response(s).)
       </p>
-      <div id="rfc.iref.21"></div>
+      <div id="rfc.iref.22"></div>
       <div id="rfc.iref.s.3"></div>
       <h3 id="rfc.section.5.3.1"><a href="#rfc.section.5.3.1">5.3.1</a>&nbsp;<a id="status.100" href="#status.100">100 Continue</a></h3>
       <p id="rfc.section.5.3.1.p.1">The client <em class="bcp14">SHOULD</em> continue with its request. This interim response is used to inform the client that the initial part of the request has been
          received and has not yet been rejected by the server. The client <em class="bcp14">SHOULD</em> continue by sending the remainder of the request or, if the request has already been completed, ignore this response. The
-         server <em class="bcp14">MUST</em> send a final response after the request has been completed. See <a href="p1-messaging.html#use.of.the.100.status" title="Use of the 100 (Continue) Status">Section 6.3</a> of <a href="#Part1" id="rfc.xref.Part1.21"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a> for detailed discussion of the use and handling of this status code.
-      </p>
-      <div id="rfc.iref.22"></div>
+         server <em class="bcp14">MUST</em> send a final response after the request has been completed. See <a href="p1-messaging.html#use.of.the.100.status" title="Use of the 100 (Continue) Status">Section 6.3</a> of <a href="#Part1" id="rfc.xref.Part1.20"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a> for detailed discussion of the use and handling of this status code.
+      </p>
+      <div id="rfc.iref.23"></div>
       <div id="rfc.iref.s.4"></div>
       <h3 id="rfc.section.5.3.2"><a href="#rfc.section.5.3.2">5.3.2</a>&nbsp;<a id="status.101" href="#status.101">101 Switching Protocols</a></h3>
-      <p id="rfc.section.5.3.2.p.1">The server understands and is willing to comply with the client's request, via the <a href="p1-messaging.html#header.upgrade" class="smpl">Upgrade</a> message header field (<a href="p1-messaging.html#header.upgrade" title="Upgrade">Section 6.4</a> of <a href="#Part1" id="rfc.xref.Part1.22"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>), for a change in the application protocol being used on this connection. The server will switch protocols to those defined
+      <p id="rfc.section.5.3.2.p.1">The server understands and is willing to comply with the client's request, via the <a href="p1-messaging.html#header.upgrade" class="smpl">Upgrade</a> message header field (<a href="p1-messaging.html#header.upgrade" title="Upgrade">Section 6.4</a> of <a href="#Part1" id="rfc.xref.Part1.21"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>), for a change in the application protocol being used on this connection. The server will switch protocols to those defined
          by the response's Upgrade header field immediately after the empty line which terminates the 101 response.
       </p>
@@ -1729 +1718 @@
       </p>
       <h2 id="rfc.section.5.4"><a href="#rfc.section.5.4">5.4</a>&nbsp;<a id="status.2xx" href="#status.2xx">Successful 2xx</a></h2>
-      <div id="rfc.iref.23"></div>
+      <div id="rfc.iref.24"></div>
       <div id="rfc.iref.s.5"></div>
       <p id="rfc.section.5.4.p.1">This class of status code indicates that the client's request was successfully received, understood, and accepted.</p>
-      <div id="rfc.iref.24"></div>
+      <div id="rfc.iref.25"></div>
       <div id="rfc.iref.s.6"></div>
       <h3 id="rfc.section.5.4.1"><a href="#rfc.section.5.4.1">5.4.1</a>&nbsp;<a id="status.200" href="#status.200">200 OK</a></h3>
@@ -1748 +1737 @@
       <p id="rfc.section.5.4.1.p.2">Caches <em class="bcp14">MAY</em> use a heuristic (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 4.1.2</a> of <a href="#Part6" id="rfc.xref.Part6.11"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) to determine freshness for 200 responses.
       </p>
-      <div id="rfc.iref.25"></div>
+      <div id="rfc.iref.26"></div>
       <div id="rfc.iref.s.7"></div>
       <h3 id="rfc.section.5.4.2"><a href="#rfc.section.5.4.2">5.4.2</a>&nbsp;<a id="status.201" href="#status.201">201 Created</a></h3>
@@ -1761 +1750 @@
          the <a href="#header.location" class="smpl">Location</a> header field or, in case the Location header field was omitted, by the Effective Request URI (see <a href="p4-conditional.html#header.etag" title="ETag">Section 2.3</a> of <a href="#Part4" id="rfc.xref.Part4.10"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>).
       </p>
-      <div id="rfc.iref.26"></div>
+      <div id="rfc.iref.27"></div>
       <div id="rfc.iref.s.8"></div>
       <h3 id="rfc.section.5.4.3"><a href="#rfc.section.5.4.3">5.4.3</a>&nbsp;<a id="status.202" href="#status.202">202 Accepted</a></h3>
@@ -1773 +1762 @@
          user can expect the request to be fulfilled.
       </p>
-      <div id="rfc.iref.27"></div>
+      <div id="rfc.iref.28"></div>
       <div id="rfc.iref.s.9"></div>
       <h3 id="rfc.section.5.4.4"><a href="#rfc.section.5.4.4">5.4.4</a>&nbsp;<a id="status.203" href="#status.203">203 Non-Authoritative Information</a></h3>
-      <p id="rfc.section.5.4.4.p.1">The representation in the response has been transformed or otherwise modified by a transforming proxy (<a href="p1-messaging.html#intermediaries" title="Intermediaries">Section 2.3</a> of <a href="#Part1" id="rfc.xref.Part1.23"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>). Note that the behavior of transforming intermediaries is controlled by the no-transform Cache-Control directive (<a href="p6-cache.html#header.cache-control" title="Cache-Control">Section 7.2</a> of <a href="#Part6" id="rfc.xref.Part6.12"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>).
+      <p id="rfc.section.5.4.4.p.1">The representation in the response has been transformed or otherwise modified by a transforming proxy (<a href="p1-messaging.html#intermediaries" title="Intermediaries">Section 2.3</a> of <a href="#Part1" id="rfc.xref.Part1.22"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>). Note that the behavior of transforming intermediaries is controlled by the no-transform Cache-Control directive (<a href="p6-cache.html#header.cache-control" title="Cache-Control">Section 7.2</a> of <a href="#Part6" id="rfc.xref.Part6.12"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>).
       </p>
       <p id="rfc.section.5.4.4.p.2">This status code is only appropriate when the response status code would have been <a href="#status.200" class="smpl">200 (OK)</a> otherwise. When the status code before transformation would have been different, the 214 Transformation Applied warn-code
@@ -1783 +1772 @@
       <p id="rfc.section.5.4.4.p.3">Caches <em class="bcp14">MAY</em> use a heuristic (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 4.1.2</a> of <a href="#Part6" id="rfc.xref.Part6.14"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) to determine freshness for 203 responses.
       </p>
-      <div id="rfc.iref.28"></div>
+      <div id="rfc.iref.29"></div>
       <div id="rfc.iref.s.10"></div>
       <h3 id="rfc.section.5.4.5"><a href="#rfc.section.5.4.5">5.4.5</a>&nbsp;<a id="status.204" href="#status.204">204 No Content</a></h3>
@@ -1804 +1793 @@
       <p id="rfc.section.5.4.5.p.5">The 204 response <em class="bcp14">MUST NOT</em> include a message body, and thus is always terminated by the first empty line after the header fields.
       </p>
-      <div id="rfc.iref.29"></div>
+      <div id="rfc.iref.30"></div>
       <div id="rfc.iref.s.11"></div>
       <h3 id="rfc.section.5.4.6"><a href="#rfc.section.5.4.6">5.4.6</a>&nbsp;<a id="status.205" href="#status.205">205 Reset Content</a></h3>
@@ -1811 +1800 @@
          another input action.
       </p>
-      <p id="rfc.section.5.4.6.p.2">The message body included with the response <em class="bcp14">MUST</em> be empty. Note that receivers still need to parse the response according to the algorithm defined in <a href="p1-messaging.html#message.body" title="Message Body">Section 3.3</a> of <a href="#Part1" id="rfc.xref.Part1.24"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>.
+      <p id="rfc.section.5.4.6.p.2">The message body included with the response <em class="bcp14">MUST</em> be empty. Note that receivers still need to parse the response according to the algorithm defined in <a href="p1-messaging.html#message.body" title="Message Body">Section 3.3</a> of <a href="#Part1" id="rfc.xref.Part1.23"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>.
       </p>
       <h2 id="rfc.section.5.5"><a href="#rfc.section.5.5">5.5</a>&nbsp;<a id="status.3xx" href="#status.3xx">Redirection 3xx</a></h2>
-      <div id="rfc.iref.30"></div>
+      <div id="rfc.iref.31"></div>
       <div id="rfc.iref.s.12"></div>
       <p id="rfc.section.5.5.p.1">This class of status code indicates that further action needs to be taken by the user agent in order to fulfill the request.
@@ -1860 +1849 @@
          </p> 
       </div>
-      <div id="rfc.iref.31"></div>
+      <div id="rfc.iref.32"></div>
       <div id="rfc.iref.s.13"></div>
       <h3 id="rfc.section.5.5.1"><a href="#rfc.section.5.5.1">5.5.1</a>&nbsp;<a id="status.300" href="#status.300">300 Multiple Choices</a></h3>
@@ -1875 +1864 @@
       <p id="rfc.section.5.5.1.p.4">Caches <em class="bcp14">MAY</em> use a heuristic (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 4.1.2</a> of <a href="#Part6" id="rfc.xref.Part6.15"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) to determine freshness for 300 responses.
       </p>
-      <div id="rfc.iref.32"></div>
+      <div id="rfc.iref.33"></div>
       <div id="rfc.iref.s.14"></div>
       <h3 id="rfc.section.5.5.2"><a href="#rfc.section.5.5.2">5.5.2</a>&nbsp;<a id="status.301" href="#status.301">301 Moved Permanently</a></h3>
@@ -1889 +1878 @@
          </p> 
       </div>
-      <div id="rfc.iref.33"></div>
+      <div id="rfc.iref.34"></div>
       <div id="rfc.iref.s.15"></div>
       <h3 id="rfc.section.5.5.3"><a href="#rfc.section.5.5.3">5.5.3</a>&nbsp;<a id="status.302" href="#status.302">302 Found</a></h3>
@@ -1900 +1889 @@
          </p> 
       </div>
-      <div id="rfc.iref.34"></div>
+      <div id="rfc.iref.35"></div>
       <div id="rfc.iref.s.16"></div>
       <h3 id="rfc.section.5.5.4"><a href="#rfc.section.5.5.4">5.5.4</a>&nbsp;<a id="status.303" href="#status.303">303 See Other</a></h3>
@@ -1921 +1910 @@
       <p id="rfc.section.5.5.4.p.4">Except for responses to a HEAD request, the representation of a 303 response <em class="bcp14">SHOULD</em> contain a short hypertext note with a hyperlink to the <a href="#header.location" class="smpl">Location</a> URI.
       </p>
-      <div id="rfc.iref.35"></div>
+      <div id="rfc.iref.36"></div>
       <div id="rfc.iref.s.17"></div>
       <h3 id="rfc.section.5.5.5"><a href="#rfc.section.5.5.5">5.5.5</a>&nbsp;<a id="status.305" href="#status.305">305 Use Proxy</a></h3>
       <p id="rfc.section.5.5.5.p.1">The 305 status code was defined in a previous version of this specification (see <a href="#changes.from.rfc.2616" title="Changes from RFC 2616">Appendix&nbsp;C</a>), and is now deprecated.
       </p>
-      <div id="rfc.iref.36"></div>
+      <div id="rfc.iref.37"></div>
       <div id="rfc.iref.s.18"></div>
       <h3 id="rfc.section.5.5.6"><a href="#rfc.section.5.5.6">5.5.6</a>&nbsp;<a id="status.306" href="#status.306">306 (Unused)</a></h3>
       <p id="rfc.section.5.5.6.p.1">The 306 status code was used in a previous version of the specification, is no longer used, and the code is reserved.</p>
-      <div id="rfc.iref.37"></div>
+      <div id="rfc.iref.38"></div>
       <div id="rfc.iref.s.19"></div>
       <h3 id="rfc.section.5.5.7"><a href="#rfc.section.5.5.7">5.5.7</a>&nbsp;<a id="status.307" href="#status.307">307 Temporary Redirect</a></h3>
@@ -1944 +1933 @@
       </div>
       <h2 id="rfc.section.5.6"><a href="#rfc.section.5.6">5.6</a>&nbsp;<a id="status.4xx" href="#status.4xx">Client Error 4xx</a></h2>
-      <div id="rfc.iref.38"></div>
+      <div id="rfc.iref.39"></div>
       <div id="rfc.iref.s.20"></div>
       <p id="rfc.section.5.6.p.1">The 4xx class of status code is intended for cases in which the client seems to have erred. Except when responding to a HEAD
@@ -1950 +1939 @@
          These status codes are applicable to any request method. User agents <em class="bcp14">SHOULD</em> display any included representation to the user.
       </p>
-      <div id="rfc.iref.39"></div>
+      <div id="rfc.iref.40"></div>
       <div id="rfc.iref.s.21"></div>
       <h3 id="rfc.section.5.6.1"><a href="#rfc.section.5.6.1">5.6.1</a>&nbsp;<a id="status.400" href="#status.400">400 Bad Request</a></h3>
       <p id="rfc.section.5.6.1.p.1">The server cannot or will not process the request, due to a client error (e.g., malformed syntax).</p>
-      <div id="rfc.iref.40"></div>
+      <div id="rfc.iref.41"></div>
       <div id="rfc.iref.s.22"></div>
       <h3 id="rfc.section.5.6.2"><a href="#rfc.section.5.6.2">5.6.2</a>&nbsp;<a id="status.402" href="#status.402">402 Payment Required</a></h3>
       <p id="rfc.section.5.6.2.p.1">This code is reserved for future use.</p>
-      <div id="rfc.iref.41"></div>
+      <div id="rfc.iref.42"></div>
       <div id="rfc.iref.s.23"></div>
       <h3 id="rfc.section.5.6.3"><a href="#rfc.section.5.6.3">5.6.3</a>&nbsp;<a id="status.403" href="#status.403">403 Forbidden</a></h3>
@@ -1968 +1957 @@
             (Not Found)</a>  <em class="bcp14">MAY</em> be used instead.
       </p>
-      <div id="rfc.iref.42"></div>
+      <div id="rfc.iref.43"></div>
       <div id="rfc.iref.s.24"></div>
       <h3 id="rfc.section.5.6.4"><a href="#rfc.section.5.6.4">5.6.4</a>&nbsp;<a id="status.404" href="#status.404">404 Not Found</a></h3>
@@ -1976 +1965 @@
          has been refused, or when no other response is applicable.
       </p>
-      <div id="rfc.iref.43"></div>
+      <div id="rfc.iref.44"></div>
       <div id="rfc.iref.s.25"></div>
       <h3 id="rfc.section.5.6.5"><a href="#rfc.section.5.6.5">5.6.5</a>&nbsp;<a id="status.405" href="#status.405">405 Method Not Allowed</a></h3>
       <p id="rfc.section.5.6.5.p.1">The method specified in the request-line is not allowed for the target resource. The response <em class="bcp14">MUST</em> include an <a href="#header.allow" class="smpl">Allow</a> header field containing a list of valid methods for the requested resource.
       </p>
-      <div id="rfc.iref.44"></div>
+      <div id="rfc.iref.45"></div>
       <div id="rfc.iref.s.26"></div>
       <h3 id="rfc.section.5.6.6"><a href="#rfc.section.5.6.6">5.6.6</a>&nbsp;<a id="status.406" href="#status.406">406 Not Acceptable</a></h3>
@@ -1999 +1988 @@
       <p id="rfc.section.5.6.6.p.4">If the response could be unacceptable, a user agent <em class="bcp14">SHOULD</em> temporarily stop receipt of more data and query the user for a decision on further actions.
       </p>
-      <div id="rfc.iref.45"></div>
+      <div id="rfc.iref.46"></div>
       <div id="rfc.iref.s.27"></div>
       <h3 id="rfc.section.5.6.7"><a href="#rfc.section.5.6.7">5.6.7</a>&nbsp;<a id="status.408" href="#status.408">408 Request Timeout</a></h3>
       <p id="rfc.section.5.6.7.p.1">The client did not produce a request within the time that the server was prepared to wait. The client <em class="bcp14">MAY</em> repeat the request without modifications at any later time.
       </p>
-      <div id="rfc.iref.46"></div>
+      <div id="rfc.iref.47"></div>
       <div id="rfc.iref.s.28"></div>
       <h3 id="rfc.section.5.6.8"><a href="#rfc.section.5.6.8">5.6.8</a>&nbsp;<a id="status.409" href="#status.409">409 Conflict</a></h3>
@@ -2017 +2006 @@
          contain a list of the differences between the two versions.
       </p>
-      <div id="rfc.iref.47"></div>
+      <div id="rfc.iref.48"></div>
       <div id="rfc.iref.s.29"></div>
       <h3 id="rfc.section.5.6.9"><a href="#rfc.section.5.6.9">5.6.9</a>&nbsp;<a id="status.410" href="#status.410">410 Gone</a></h3>
@@ -2032 +2021 @@
       <p id="rfc.section.5.6.9.p.3">Caches <em class="bcp14">MAY</em> use a heuristic (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 4.1.2</a> of <a href="#Part6" id="rfc.xref.Part6.17"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) to determine freshness for 410 responses.
       </p>
-      <div id="rfc.iref.48"></div>
+      <div id="rfc.iref.49"></div>
       <div id="rfc.iref.s.30"></div>
       <h3 id="rfc.section.5.6.10"><a href="#rfc.section.5.6.10">5.6.10</a>&nbsp;<a id="status.411" href="#status.411">411 Length Required</a></h3>
@@ -2038 +2027 @@
          message.
       </p>
-      <div id="rfc.iref.49"></div>
+      <div id="rfc.iref.50"></div>
       <div id="rfc.iref.s.31"></div>
       <h3 id="rfc.section.5.6.11"><a href="#rfc.section.5.6.11">5.6.11</a>&nbsp;<a id="status.413" href="#status.413">413 Request Representation Too Large</a></h3>
@@ -2046 +2035 @@
       <p id="rfc.section.5.6.11.p.2">If the condition is temporary, the server <em class="bcp14">SHOULD</em> include a <a href="#header.retry-after" class="smpl">Retry-After</a> header field to indicate that it is temporary and after what time the client <em class="bcp14">MAY</em> try again.
       </p>
-      <div id="rfc.iref.50"></div>
+      <div id="rfc.iref.51"></div>
       <div id="rfc.iref.s.32"></div>
       <h3 id="rfc.section.5.6.12"><a href="#rfc.section.5.6.12">5.6.12</a>&nbsp;<a id="status.414" href="#status.414">414 URI Too Long</a></h3>
@@ -2055 +2044 @@
          in some servers using fixed-length buffers for reading or manipulating the request-target.
       </p>
-      <div id="rfc.iref.51"></div>
+      <div id="rfc.iref.52"></div>
       <div id="rfc.iref.s.33"></div>
       <h3 id="rfc.section.5.6.13"><a href="#rfc.section.5.6.13">5.6.13</a>&nbsp;<a id="status.415" href="#status.415">415 Unsupported Media Type</a></h3>
@@ -2061 +2050 @@
          on the target resource.
       </p>
-      <div id="rfc.iref.52"></div>
+      <div id="rfc.iref.53"></div>
       <div id="rfc.iref.s.34"></div>
       <h3 id="rfc.section.5.6.14"><a href="#rfc.section.5.6.14">5.6.14</a>&nbsp;<a id="status.417" href="#status.417">417 Expectation Failed</a></h3>
@@ -2067 +2056 @@
          not be met by the next-hop server.
       </p>
-      <div id="rfc.iref.53"></div>
+      <div id="rfc.iref.54"></div>
       <div id="rfc.iref.s.35"></div>
       <h3 id="rfc.section.5.6.15"><a href="#rfc.section.5.6.15">5.6.15</a>&nbsp;<a id="status.426" href="#status.426">426 Upgrade Required</a></h3>
-      <p id="rfc.section.5.6.15.p.1">The request can not be completed without a prior protocol upgrade. This response <em class="bcp14">MUST</em> include an <a href="p1-messaging.html#header.upgrade" class="smpl">Upgrade</a> header field (<a href="p1-messaging.html#header.upgrade" title="Upgrade">Section 6.4</a> of <a href="#Part1" id="rfc.xref.Part1.25"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>) specifying the required protocols.
+      <p id="rfc.section.5.6.15.p.1">The request can not be completed without a prior protocol upgrade. This response <em class="bcp14">MUST</em> include an <a href="p1-messaging.html#header.upgrade" class="smpl">Upgrade</a> header field (<a href="p1-messaging.html#header.upgrade" title="Upgrade">Section 6.4</a> of <a href="#Part1" id="rfc.xref.Part1.24"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>) specifying the required protocols.
       </p>
       <div id="rfc.figure.u.5"></div> 
@@ -2084 +2073 @@
       </p>
       <h2 id="rfc.section.5.7"><a href="#rfc.section.5.7">5.7</a>&nbsp;<a id="status.5xx" href="#status.5xx">Server Error 5xx</a></h2>
-      <div id="rfc.iref.54"></div>
+      <div id="rfc.iref.55"></div>
       <div id="rfc.iref.s.36"></div>
       <p id="rfc.section.5.7.p.1">Response status codes beginning with the digit "5" indicate cases in which the server is aware that it has erred or is incapable
@@ -2090 +2079 @@
          User agents <em class="bcp14">SHOULD</em> display any included representation to the user. These response codes are applicable to any request method.
       </p>
-      <div id="rfc.iref.55"></div>
+      <div id="rfc.iref.56"></div>
       <div id="rfc.iref.s.37"></div>
       <h3 id="rfc.section.5.7.1"><a href="#rfc.section.5.7.1">5.7.1</a>&nbsp;<a id="status.500" href="#status.500">500 Internal Server Error</a></h3>
       <p id="rfc.section.5.7.1.p.1">The server encountered an unexpected condition which prevented it from fulfilling the request.</p>
-      <div id="rfc.iref.56"></div>
+      <div id="rfc.iref.57"></div>
       <div id="rfc.iref.s.38"></div>
       <h3 id="rfc.section.5.7.2"><a href="#rfc.section.5.7.2">5.7.2</a>&nbsp;<a id="status.501" href="#status.501">501 Not Implemented</a></h3>
@@ -2100 +2089 @@
          does not recognize the request method and is not capable of supporting it for any resource.
       </p>
-      <div id="rfc.iref.57"></div>
+      <div id="rfc.iref.58"></div>
       <div id="rfc.iref.s.39"></div>
       <h3 id="rfc.section.5.7.3"><a href="#rfc.section.5.7.3">5.7.3</a>&nbsp;<a id="status.502" href="#status.502">502 Bad Gateway</a></h3>
@@ -2106 +2095 @@
          to fulfill the request.
       </p>
-      <div id="rfc.iref.58"></div>
+      <div id="rfc.iref.59"></div>
       <div id="rfc.iref.s.40"></div>
       <h3 id="rfc.section.5.7.4"><a href="#rfc.section.5.7.4">5.7.4</a>&nbsp;<a id="status.503" href="#status.503">503 Service Unavailable</a></h3>
@@ -2119 +2108 @@
          </p> 
       </div>
-      <div id="rfc.iref.59"></div>
+      <div id="rfc.iref.60"></div>
       <div id="rfc.iref.s.41"></div>
       <h3 id="rfc.section.5.7.5"><a href="#rfc.section.5.7.5">5.7.5</a>&nbsp;<a id="status.504" href="#status.504">504 Gateway Timeout</a></h3>
@@ -2130 +2119 @@
          </p> 
       </div>
-      <div id="rfc.iref.60"></div>
+      <div id="rfc.iref.61"></div>
       <div id="rfc.iref.s.42"></div>
       <h3 id="rfc.section.5.7.6"><a href="#rfc.section.5.7.6">5.7.6</a>&nbsp;<a id="status.505" href="#status.505">505 HTTP Version Not Supported</a></h3>
       <p id="rfc.section.5.7.6.p.1">The server does not support, or refuses to support, the protocol version that was used in the request message. The server
          is indicating that it is unable or unwilling to complete the request using the same major version as the client, as described
-         in <a href="p1-messaging.html#http.version" title="Protocol Versioning">Section 2.6</a> of <a href="#Part1" id="rfc.xref.Part1.26"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>, other than with this error message. The response <em class="bcp14">SHOULD</em> contain a representation describing why that version is not supported and what other protocols are supported by that server.
+         in <a href="p1-messaging.html#http.version" title="Protocol Versioning">Section 2.6</a> of <a href="#Part1" id="rfc.xref.Part1.25"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>, other than with this error message. The response <em class="bcp14">SHOULD</em> contain a representation describing why that version is not supported and what other protocols are supported by that server.
       </p>
       <h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a>&nbsp;<a id="protocol.parameters" href="#protocol.parameters">Protocol Parameters</a></h1>
@@ -2261 +2250 @@
          mechanism will be required to remove the encoding.
       </p>
-      <p id="rfc.section.6.4.p.4">compress<span id="rfc.iref.c.3"></span><span id="rfc.iref.c.4"></span>  
+      <p id="rfc.section.6.4.p.4">compress<span id="rfc.iref.c.4"></span><span id="rfc.iref.c.5"></span>  
       </p>
       <ul class="empty">
-         <li>See <a href="p1-messaging.html#compress.coding" title="Compress Coding">Section 4.2.1</a> of <a href="#Part1" id="rfc.xref.Part1.27"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>.
-         </li>
-      </ul>
-      <p id="rfc.section.6.4.p.5">deflate<span id="rfc.iref.d.2"></span><span id="rfc.iref.c.5"></span>  
+         <li>See <a href="p1-messaging.html#compress.coding" title="Compress Coding">Section 4.2.1</a> of <a href="#Part1" id="rfc.xref.Part1.26"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>.
+         </li>
+      </ul>
+      <p id="rfc.section.6.4.p.5">deflate<span id="rfc.iref.d.2"></span><span id="rfc.iref.c.6"></span>  
       </p>
       <ul class="empty">
-         <li>See <a href="p1-messaging.html#deflate.coding" title="Deflate Coding">Section 4.2.2</a> of <a href="#Part1" id="rfc.xref.Part1.28"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>.
-         </li>
-      </ul>
-      <p id="rfc.section.6.4.p.6">gzip<span id="rfc.iref.g.23"></span><span id="rfc.iref.c.6"></span>  
+         <li>See <a href="p1-messaging.html#deflate.coding" title="Deflate Coding">Section 4.2.2</a> of <a href="#Part1" id="rfc.xref.Part1.27"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>.
+         </li>
+      </ul>
+      <p id="rfc.section.6.4.p.6">gzip<span id="rfc.iref.g.23"></span><span id="rfc.iref.c.7"></span>  
       </p>
       <ul class="empty">
-         <li>See <a href="p1-messaging.html#gzip.coding" title="Gzip Coding">Section 4.2.3</a> of <a href="#Part1" id="rfc.xref.Part1.29"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>.
+         <li>See <a href="p1-messaging.html#gzip.coding" title="Gzip Coding">Section 4.2.3</a> of <a href="#Part1" id="rfc.xref.Part1.28"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>.
          </li>
       </ul>
@@ -2288 +2277 @@
          <li>Pointer to specification text</li>
       </ul>
-      <p id="rfc.section.6.4.1.p.3">Names of content codings <em class="bcp14">MUST NOT</em> overlap with names of transfer codings (<a href="p1-messaging.html#transfer.codings" title="Transfer Codings">Section 4</a> of <a href="#Part1" id="rfc.xref.Part1.30"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>), unless the encoding transformation is identical (as is the case for the compression codings defined in <a href="p1-messaging.html#compression.codings" title="Compression Codings">Section 4.2</a> of <a href="#Part1" id="rfc.xref.Part1.31"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>).
-      </p>
-      <p id="rfc.section.6.4.1.p.4">Values to be added to this name space require IETF Review (see <a href="http://tools.ietf.org/html/rfc5226#section-4.1">Section 4.1</a> of <a href="#RFC5226" id="rfc.xref.RFC5226.3"><cite title="Guidelines for Writing an IANA Considerations Section in RFCs">[RFC5226]</cite></a>), and <em class="bcp14">MUST</em> conform to the purpose of content coding defined in this section.
+      <p id="rfc.section.6.4.1.p.3">Names of content codings <em class="bcp14">MUST NOT</em> overlap with names of transfer codings (<a href="p1-messaging.html#transfer.codings" title="Transfer Codings">Section 4</a> of <a href="#Part1" id="rfc.xref.Part1.29"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>), unless the encoding transformation is identical (as is the case for the compression codings defined in <a href="p1-messaging.html#compression.codings" title="Compression Codings">Section 4.2</a> of <a href="#Part1" id="rfc.xref.Part1.30"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>).
+      </p>
+      <p id="rfc.section.6.4.1.p.4">Values to be added to this name space require IETF Review (see <a href="http://tools.ietf.org/html/rfc5226#section-4.1">Section 4.1</a> of <a href="#RFC5226" id="rfc.xref.RFC5226.2"><cite title="Guidelines for Writing an IANA Considerations Section in RFCs">[RFC5226]</cite></a>), and <em class="bcp14">MUST</em> conform to the purpose of content coding defined in this section.
       </p>
       <p id="rfc.section.6.4.1.p.5">The registry itself is maintained at &lt;<a href="http://www.iana.org/assignments/http-parameters">http://www.iana.org/assignments/http-parameters</a>&gt;.
@@ -2387 +2376 @@
                <tr>
                   <td class="left">Content-Length</td>
-                  <td class="left"><a href="p1-messaging.html#header.content-length" title="Content-Length">Section 3.3.2</a> of <a href="#Part1" id="rfc.xref.Part1.32"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a></td>
+                  <td class="left"><a href="p1-messaging.html#header.content-length" title="Content-Length">Section 3.3.2</a> of <a href="#Part1" id="rfc.xref.Part1.31"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a></td>
                </tr>
                <tr>
@@ -2397 +2386 @@
       </div>
       <h2 id="rfc.section.7.2"><a href="#rfc.section.7.2">7.2</a>&nbsp;<a id="payload.body" href="#payload.body">Payload Body</a></h2>
-      <p id="rfc.section.7.2.p.1">A payload body is only present in a message when a message body is present, as described in <a href="p1-messaging.html#message.body" title="Message Body">Section 3.3</a> of <a href="#Part1" id="rfc.xref.Part1.33"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>. The payload body is obtained from the message body by decoding any <a href="p1-messaging.html#header.transfer-encoding" class="smpl">Transfer-Encoding</a> that might have been applied to ensure safe and proper transfer of the message.
+      <p id="rfc.section.7.2.p.1">A payload body is only present in a message when a message body is present, as described in <a href="p1-messaging.html#message.body" title="Message Body">Section 3.3</a> of <a href="#Part1" id="rfc.xref.Part1.32"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>. The payload body is obtained from the message body by decoding any <a href="p1-messaging.html#header.transfer-encoding" class="smpl">Transfer-Encoding</a> that might have been applied to ensure safe and proper transfer of the message.
       </p>
       <div id="rfc.iref.r.1"></div>
@@ -2416 +2405 @@
          in an HTTP message, it is referred to as the payload of the message.
       </p>
-      <p id="rfc.section.8.p.4">A representation body is only present in a message when a message body is present, as described in <a href="p1-messaging.html#message.body" title="Message Body">Section 3.3</a> of <a href="#Part1" id="rfc.xref.Part1.34"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>. The representation body is obtained from the message body by decoding any <a href="p1-messaging.html#header.transfer-encoding" class="smpl">Transfer-Encoding</a> that might have been applied to ensure safe and proper transfer of the message.
+      <p id="rfc.section.8.p.4">A representation body is only present in a message when a message body is present, as described in <a href="p1-messaging.html#message.body" title="Message Body">Section 3.3</a> of <a href="#Part1" id="rfc.xref.Part1.33"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>. The representation body is obtained from the message body by decoding any <a href="p1-messaging.html#header.transfer-encoding" class="smpl">Transfer-Encoding</a> that might have been applied to ensure safe and proper transfer of the message.
       </p>
       <h2 id="rfc.section.8.1"><a href="#rfc.section.8.1">8.1</a>&nbsp;<a id="identifying.response.associated.with.representation" href="#identifying.response.associated.with.representation">Identifying the Resource Associated with a Representation</a></h2>
       <p id="rfc.section.8.1.p.1">It is sometimes necessary to determine an identifier for the resource associated with a representation.</p>
       <p id="rfc.section.8.1.p.2">An HTTP request representation, when present, is always associated with an anonymous (i.e., unidentified) resource.</p>
-      <p id="rfc.section.8.1.p.3">In the common case, an HTTP response is a representation of the target resource (see <a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 5.5</a> of <a href="#Part1" id="rfc.xref.Part1.35"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>). However, this is not always the case. To determine the URI of the resource a response is associated with, the following
+      <p id="rfc.section.8.1.p.3">In the common case, an HTTP response is a representation of the target resource (see <a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 5.5</a> of <a href="#Part1" id="rfc.xref.Part1.34"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>). However, this is not always the case. To determine the URI of the resource a response is associated with, the following
          rules are used (with the first applicable one being selected):
       </p>
@@ -2835 +2824 @@
          to the generic message handling rules.
       </p>
-      <div id="rfc.iref.c.7"></div>
+      <div id="rfc.iref.c.8"></div>
       <div id="rfc.iref.h.7"></div>
       <h2 id="rfc.section.10.6"><a href="#rfc.section.10.6">10.6</a>&nbsp;<a id="header.content-encoding" href="#header.content-encoding">Content-Encoding</a></h2>
@@ -2863 +2852 @@
       <p id="rfc.section.10.6.p.9">If the content-coding of a representation in a request message is not acceptable to the origin server, the server <em class="bcp14">SHOULD</em> respond with a status code of 415 (Unsupported Media Type).
       </p>
-      <div id="rfc.iref.c.8"></div>
+      <div id="rfc.iref.c.9"></div>
       <div id="rfc.iref.h.8"></div>
       <h2 id="rfc.section.10.7"><a href="#rfc.section.10.7">10.7</a>&nbsp;<a id="header.content-language" href="#header.content-language">Content-Language</a></h2>
@@ -2889 +2878 @@
       <p id="rfc.section.10.7.p.9">Content-Language <em class="bcp14">MAY</em> be applied to any media type — it is not limited to textual documents.
       </p>
-      <div id="rfc.iref.c.9"></div>
+      <div id="rfc.iref.c.10"></div>
       <div id="rfc.iref.h.9"></div>
       <h2 id="rfc.section.10.8"><a href="#rfc.section.10.8">10.8</a>&nbsp;<a id="header.content-location" href="#header.content-location">Content-Location</a></h2>
@@ -2896 +2885 @@
       </p>
       <div id="rfc.figure.u.41"></div><pre class="inline"><span id="rfc.iref.g.45"></span>  <a href="#header.content-location" class="smpl">Content-Location</a> = <a href="#imported.abnf" class="smpl">absolute-URI</a> / <a href="#imported.abnf" class="smpl">partial-URI</a>
-</pre><p id="rfc.section.10.8.p.3">The Content-Location value is not a replacement for the effective Request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 5.5</a> of <a href="#Part1" id="rfc.xref.Part1.36"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>). It is representation metadata. It has the same syntax and semantics as the header field of the same name defined for MIME
+</pre><p id="rfc.section.10.8.p.3">The Content-Location value is not a replacement for the effective Request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 5.5</a> of <a href="#Part1" id="rfc.xref.Part1.35"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>). It is representation metadata. It has the same syntax and semantics as the header field of the same name defined for MIME
          body parts in <a href="http://tools.ietf.org/html/rfc2557#section-4">Section 4</a> of <a href="#RFC2557" id="rfc.xref.RFC2557.1"><cite title="MIME Encapsulation of Aggregate Documents, such as HTML (MHTML)">[RFC2557]</cite></a>. However, its appearance in an HTTP message has some special implications for HTTP recipients.
       </p>
@@ -2929 +2918 @@
       </p>
       <p id="rfc.section.10.8.p.9">If the Content-Location value is a partial URI, the partial URI is interpreted relative to the effective request URI.</p>
-      <div id="rfc.iref.c.10"></div>
+      <div id="rfc.iref.c.11"></div>
       <div id="rfc.iref.h.10"></div>
       <h2 id="rfc.section.10.9"><a href="#rfc.section.10.9">10.9</a>&nbsp;<a id="header.content-type" href="#header.content-type">Content-Type</a></h2>
@@ -2987 +2976 @@
       </p>
       <p id="rfc.section.10.11.p.4">The only expectation defined by this specification is:</p>
-      <p id="rfc.section.10.11.p.5"><span id="rfc.iref.141"></span><span id="rfc.iref.e.2"></span> 100-continue 
+      <p id="rfc.section.10.11.p.5"><span id="rfc.iref.142"></span><span id="rfc.iref.e.2"></span> 100-continue 
       </p>
       <ul class="empty">
-         <li>The "100-continue" expectation is defined <a href="p1-messaging.html#use.of.the.100.status" title="Use of the 100 (Continue) Status">Section 6.3</a> of <a href="#Part1" id="rfc.xref.Part1.37"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>. It does not support any expect-params.
+         <li>The "100-continue" expectation is defined <a href="p1-messaging.html#use.of.the.100.status" title="Use of the 100 (Continue) Status">Section 6.3</a> of <a href="#Part1" id="rfc.xref.Part1.36"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>. It does not support any expect-params.
          </li>
       </ul>
@@ -3053 +3042 @@
       <div id="rfc.iref.h.15"></div>
       <h2 id="rfc.section.10.14"><a href="#rfc.section.10.14">10.14</a>&nbsp;<a id="header.max-forwards" href="#header.max-forwards">Max-Forwards</a></h2>
-      <p id="rfc.section.10.14.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;3.3.7</a>) and OPTIONS (<a href="#OPTIONS" id="rfc.xref.OPTIONS.2" title="OPTIONS">Section&nbsp;3.3.1</a>) methods to limit the number of times that the request is forwarded by proxies. This can be useful when the client is attempting
+      <p id="rfc.section.10.14.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;3.2.7</a>) and OPTIONS (<a href="#OPTIONS" id="rfc.xref.OPTIONS.2" title="OPTIONS">Section&nbsp;3.2.1</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 mid-chain.
       </p>
@@ -3101 +3090 @@
       <h2 id="rfc.section.10.17"><a href="#rfc.section.10.17">10.17</a>&nbsp;<a id="header.server" href="#header.server">Server</a></h2>
       <p id="rfc.section.10.17.p.1">The "Server" header field contains information about the software used by the origin server to handle the request.</p>
-      <p id="rfc.section.10.17.p.2">The field can contain multiple product tokens (<a href="#product.tokens" title="Product Tokens">Section&nbsp;6.2</a>) and comments (<a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.38"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>) identifying the server and any significant subproducts. The product tokens are listed in order of their significance for
+      <p id="rfc.section.10.17.p.2">The field can contain multiple product tokens (<a href="#product.tokens" title="Product Tokens">Section&nbsp;6.2</a>) and comments (<a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.37"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>) identifying the server and any significant subproducts. The product tokens are listed in order of their significance for
          identifying the application.
       </p>
@@ -3107 +3096 @@
 </pre><p id="rfc.section.10.17.p.4">Example:</p>
       <div id="rfc.figure.u.59"></div><pre class="text">  Server: CERN/3.0 libwww/2.17
-</pre><p id="rfc.section.10.17.p.6">If the response is being forwarded through a proxy, the proxy application <em class="bcp14">MUST NOT</em> modify the <a href="#header.server" class="smpl">Server</a> header field. Instead, it <em class="bcp14">MUST</em> include a <a href="p1-messaging.html#header.via" class="smpl">Via</a> field (as described in <a href="p1-messaging.html#header.via" title="Via">Section 5.7</a> of <a href="#Part1" id="rfc.xref.Part1.39"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>).
+</pre><p id="rfc.section.10.17.p.6">If the response is being forwarded through a proxy, the proxy application <em class="bcp14">MUST NOT</em> modify the <a href="#header.server" class="smpl">Server</a> header field. Instead, it <em class="bcp14">MUST</em> include a <a href="p1-messaging.html#header.via" class="smpl">Via</a> field (as described in <a href="p1-messaging.html#header.via" title="Via">Section 5.7</a> of <a href="#Part1" id="rfc.xref.Part1.38"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>).
       </p>
       <div class="note" id="rfc.section.10.17.p.7"> 
@@ -3123 +3112 @@
          user agent limitations.
       </p>
-      <p id="rfc.section.10.18.p.3">The field can contain multiple product tokens (<a href="#product.tokens" title="Product Tokens">Section&nbsp;6.2</a>) and comments (<a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.40"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>) identifying the agent and its significant subproducts. By convention, the product tokens are listed in order of their significance
+      <p id="rfc.section.10.18.p.3">The field can contain multiple product tokens (<a href="#product.tokens" title="Product Tokens">Section&nbsp;6.2</a>) and comments (<a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.39"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>) identifying the agent and its significant subproducts. By convention, the product tokens are listed in order of their significance
          for identifying the application.
       </p>
@@ -3138 +3127 @@
       <div id="rfc.figure.u.61"></div><pre class="text">  User-Agent: CERN-LineMode/2.15 libwww/2.17b3
 </pre><h1 id="rfc.section.11"><a href="#rfc.section.11">11.</a>&nbsp;<a id="IANA.considerations" href="#IANA.considerations">IANA Considerations</a></h1>
-      <h2 id="rfc.section.11.1"><a href="#rfc.section.11.1">11.1</a>&nbsp;<a id="method.registration" href="#method.registration">Method Registry</a></h2>
-      <p id="rfc.section.11.1.p.1">The registration procedure for HTTP request methods is defined by <a href="#method.registry" title="Method Registry">Section&nbsp;3.2</a> of this document.
-      </p>
-      <p id="rfc.section.11.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:
+      <h2 id="rfc.section.11.1"><a href="#rfc.section.11.1">11.1</a>&nbsp;<a id="method.registry" href="#method.registry">Method Registry</a></h2>
+      <p id="rfc.section.11.1.p.1">The HTTP Method Registry defines the name space for the method token in the Request line of an HTTP request.</p>
+      <p id="rfc.section.11.1.p.2">Registrations <em class="bcp14">MUST</em> include the following fields: 
+      </p>
+      <ul>
+         <li>Method Name (see <a href="#methods" title="Request Methods">Section&nbsp;3</a>)
+         </li>
+         <li>Safe ("yes" or "no", see <a href="#safe.methods" title="Safe Methods">Section&nbsp;3.1.1</a>)
+         </li>
+         <li>Idempotent ("yes" or "no", see <a href="#safe.methods" title="Safe Methods">Section&nbsp;3.1.1</a>)
+         </li>
+         <li>Pointer to specification text</li>
+      </ul>
+      <p id="rfc.section.11.1.p.3">Values to be added to this name space require IETF Review (see <a href="#RFC5226" id="rfc.xref.RFC5226.3"><cite title="Guidelines for Writing an IANA Considerations Section in RFCs">[RFC5226]</cite></a>, <a href="http://tools.ietf.org/html/rfc5226#section-4.1">Section 4.1</a>).
+      </p>
+      <p id="rfc.section.11.1.p.4">The registry itself is maintained at &lt;<a href="http://www.iana.org/assignments/http-methods">http://www.iana.org/assignments/http-methods</a>&gt;.
+      </p>
+      <h3 id="rfc.section.11.1.1"><a href="#rfc.section.11.1.1">11.1.1</a>&nbsp;<a id="considerations.for.new.methods" href="#considerations.for.new.methods">Considerations for New Methods</a></h3>
+      <p id="rfc.section.11.1.1.p.1">Standardized HTTP methods are generic; that is, they are potentially applicable to any resource, not just one particular media
+         type, kind of resource, or application. As such, it is preferred that new HTTP methods be registered in a document that isn't
+         specific to a single application or data format, since orthogonal technologies deserve orthogonal specification.
+      </p>
+      <p id="rfc.section.11.1.1.p.2">Since HTTP message parsing (<a href="p1-messaging.html#message.body" title="Message Body">Section 3.3</a> of <a href="#Part1" id="rfc.xref.Part1.40"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>) is independent of method semantics (aside from responses to HEAD), definitions of new HTTP methods cannot change the parsing
+         algorithm or prohibit the presence of a message body on either the request or the response message. Definitions of new methods
+         can specify that only zero-length bodies are allowed, which would imply that each such messages would be required to contain
+         a Content-Length header field with a value of "0".
+      </p>
+      <p id="rfc.section.11.1.1.p.3">New method definitions need to indicate whether they are safe (<a href="#safe.methods" title="Safe Methods">Section&nbsp;3.1.1</a>), idempotent (<a href="#idempotent.methods" title="Idempotent Methods">Section&nbsp;3.1.2</a>), or cacheable (<a href="#cacheable.methods" title="Cacheable Methods">Section&nbsp;3.1.3</a>), and what semantics are to be associated with the request body if any is present in the request. If a method is cacheable,
+         the method definition ought to describe how, and under what conditions, a cache can store a response and use it to satisfy
+         a subsequent request.
+      </p>
+      <h3 id="rfc.section.11.1.2"><a href="#rfc.section.11.1.2">11.1.2</a>&nbsp;<a id="method.registration" href="#method.registration">Registrations</a></h3>
+      <p id="rfc.section.11.1.2.p.1">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:
       </p>
       <div id="rfc.table.2">
@@ -3159 +3177 @@
                   <td class="left">no</td>
                   <td class="left">no</td>
-                  <td class="left"> <a href="#CONNECT" id="rfc.xref.CONNECT.2" title="CONNECT">Section&nbsp;3.3.8</a> 
+                  <td class="left"> <a href="#CONNECT" id="rfc.xref.CONNECT.2" title="CONNECT">Section&nbsp;3.2.8</a> 
                   </td>
                </tr>
@@ -3166 +3184 @@
                   <td class="left">no</td>
                   <td class="left">yes</td>
-                  <td class="left"> <a href="#DELETE" id="rfc.xref.DELETE.2" title="DELETE">Section&nbsp;3.3.6</a> 
+                  <td class="left"> <a href="#DELETE" id="rfc.xref.DELETE.2" title="DELETE">Section&nbsp;3.2.6</a> 
                   </td>
                </tr>
@@ -3173 +3191 @@
                   <td class="left">yes</td>
                   <td class="left">yes</td>
-                  <td class="left"> <a href="#GET" id="rfc.xref.GET.2" title="GET">Section&nbsp;3.3.2</a> 
+                  <td class="left"> <a href="#GET" id="rfc.xref.GET.2" title="GET">Section&nbsp;3.2.2</a> 
                   </td>
                </tr>
@@ -3180 +3198 @@
                   <td class="left">yes</td>
                   <td class="left">yes</td>
-                  <td class="left"> <a href="#HEAD" id="rfc.xref.HEAD.2" title="HEAD">Section&nbsp;3.3.3</a> 
+                  <td class="left"> <a href="#HEAD" id="rfc.xref.HEAD.2" title="HEAD">Section&nbsp;3.2.3</a> 
                   </td>
                </tr>
@@ -3187 +3205 @@
                   <td class="left">yes</td>
                   <td class="left">yes</td>
-                  <td class="left"> <a href="#OPTIONS" id="rfc.xref.OPTIONS.3" title="OPTIONS">Section&nbsp;3.3.1</a> 
+                  <td class="left"> <a href="#OPTIONS" id="rfc.xref.OPTIONS.3" title="OPTIONS">Section&nbsp;3.2.1</a> 
                   </td>
                </tr>
@@ -3194 +3212 @@
                   <td class="left">no</td>
                   <td class="left">no</td>
-                  <td class="left"> <a href="#POST" id="rfc.xref.POST.2" title="POST">Section&nbsp;3.3.4</a> 
+                  <td class="left"> <a href="#POST" id="rfc.xref.POST.2" title="POST">Section&nbsp;3.2.4</a> 
                   </td>
                </tr>
@@ -3201 +3219 @@
                   <td class="left">no</td>
                   <td class="left">yes</td>
-                  <td class="left"> <a href="#PUT" id="rfc.xref.PUT.2" title="PUT">Section&nbsp;3.3.5</a> 
+                  <td class="left"> <a href="#PUT" id="rfc.xref.PUT.2" title="PUT">Section&nbsp;3.2.5</a> 
                   </td>
                </tr>
@@ -3208 +3226 @@
                   <td class="left">yes</td>
                   <td class="left">yes</td>
-                  <td class="left"> <a href="#TRACE" id="rfc.xref.TRACE.3" title="TRACE">Section&nbsp;3.3.7</a> 
+                  <td class="left"> <a href="#TRACE" id="rfc.xref.TRACE.3" title="TRACE">Section&nbsp;3.2.7</a> 
                   </td>
                </tr>
@@ -3679 +3697 @@
          user.
       </p>
-      <p id="rfc.section.12.1.p.9">Some request methods, like TRACE (<a href="#TRACE" id="rfc.xref.TRACE.4" title="TRACE">Section&nbsp;3.3.7</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.12.1.p.9">Some request methods, like TRACE (<a href="#TRACE" id="rfc.xref.TRACE.4" title="TRACE">Section&nbsp;3.2.7</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>
@@ -3975 +3993 @@
          However, this parameter is not part of the MIME standards).
       </p>
-      <div id="rfc.iref.c.11"></div>
+      <div id="rfc.iref.c.12"></div>
       <div id="rfc.iref.h.21"></div>
       <h2 id="rfc.section.A.5"><a href="#rfc.section.A.5">A.5</a>&nbsp;<a id="no.content-transfer-encoding" href="#no.content-transfer-encoding">No Content-Transfer-Encoding</a></h2>
@@ -3999 +4017 @@
       </p>
       <h1 id="rfc.section.C"><a href="#rfc.section.C">C.</a>&nbsp;<a id="changes.from.rfc.2616" href="#changes.from.rfc.2616">Changes from RFC 2616</a></h1>
-      <p id="rfc.section.C.p.1">Introduce Method Registry. (<a href="#method.registry" title="Method Registry">Section&nbsp;3.2</a>)
-      </p>
-      <p id="rfc.section.C.p.2">Clarify definition of POST. (<a href="#POST" id="rfc.xref.POST.3" title="POST">Section&nbsp;3.3.4</a>)
-      </p>
-      <p id="rfc.section.C.p.3">Remove requirement to handle all Content-* header fields; ban use of <a href="p5-range.html#header.content-range" class="smpl">Content-Range</a> with PUT. (<a href="#PUT" id="rfc.xref.PUT.3" title="PUT">Section&nbsp;3.3.5</a>)
-      </p>
-      <p id="rfc.section.C.p.4">Take over definition of CONNECT method from <a href="#RFC2817" id="rfc.xref.RFC2817.2"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a>. (<a href="#CONNECT" id="rfc.xref.CONNECT.3" title="CONNECT">Section&nbsp;3.3.8</a>)
+      <p id="rfc.section.C.p.1">Introduce Method Registry. (<a href="#method.registry" title="Method Registry">Section&nbsp;11.1</a>)
+      </p>
+      <p id="rfc.section.C.p.2">Clarify definition of POST. (<a href="#POST" id="rfc.xref.POST.3" title="POST">Section&nbsp;3.2.4</a>)
+      </p>
+      <p id="rfc.section.C.p.3">Remove requirement to handle all Content-* header fields; ban use of <a href="p5-range.html#header.content-range" class="smpl">Content-Range</a> with PUT. (<a href="#PUT" id="rfc.xref.PUT.3" title="PUT">Section&nbsp;3.2.5</a>)
+      </p>
+      <p id="rfc.section.C.p.4">Take over definition of CONNECT method from <a href="#RFC2817" id="rfc.xref.RFC2817.2"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a>. (<a href="#CONNECT" id="rfc.xref.CONNECT.3" title="CONNECT">Section&nbsp;3.2.8</a>)
       </p>
       <p id="rfc.section.C.p.5">Take over the Status Code Registry, previously defined in <a href="http://tools.ietf.org/html/rfc2817#section-7.1">Section 7.1</a> of <a href="#RFC2817" id="rfc.xref.RFC2817.3"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a>. (<a href="#status.code.registry" title="Status Code Registry">Section&nbsp;5.2</a>)
@@ -4784 +4802 @@
          <ul class="ind">
             <li><a id="rfc.index.1" href="#rfc.index.1"><b>1</b></a><ul>
-                  <li>100 Continue (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.100.1">5.1</a>, <a href="#rfc.iref.21"><b>5.3.1</b></a>, <a href="#rfc.xref.status.100.2">11.2</a></li>
-                  <li>100-continue (expect value)&nbsp;&nbsp;<a href="#rfc.iref.141"><b>10.11</b></a></li>
-                  <li>101 Switching Protocols (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.101.1">5.1</a>, <a href="#rfc.iref.22"><b>5.3.2</b></a>, <a href="#rfc.xref.status.101.2">11.2</a></li>
-                  <li>1xx Informational (status code class)&nbsp;&nbsp;<a href="#rfc.iref.20"><b>5.3</b></a></li>
+                  <li>100 Continue (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.100.1">5.1</a>, <a href="#rfc.iref.22"><b>5.3.1</b></a>, <a href="#rfc.xref.status.100.2">11.2</a></li>
+                  <li>100-continue (expect value)&nbsp;&nbsp;<a href="#rfc.iref.142"><b>10.11</b></a></li>
+                  <li>101 Switching Protocols (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.101.1">5.1</a>, <a href="#rfc.iref.23"><b>5.3.2</b></a>, <a href="#rfc.xref.status.101.2">11.2</a></li>
+                  <li>1xx Informational (status code class)&nbsp;&nbsp;<a href="#rfc.iref.21"><b>5.3</b></a></li>
                </ul>
             </li>
             <li><a id="rfc.index.2" href="#rfc.index.2"><b>2</b></a><ul>
-                  <li>200 OK (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.200.1">5.1</a>, <a href="#rfc.iref.24"><b>5.4.1</b></a>, <a href="#rfc.xref.status.200.2">11.2</a></li>
-                  <li>201 Created (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.201.1">5.1</a>, <a href="#rfc.iref.25"><b>5.4.2</b></a>, <a href="#rfc.xref.status.201.2">11.2</a></li>
-                  <li>202 Accepted (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.202.1">5.1</a>, <a href="#rfc.iref.26"><b>5.4.3</b></a>, <a href="#rfc.xref.status.202.2">11.2</a></li>
-                  <li>203 Non-Authoritative Information (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.203.1">5.1</a>, <a href="#rfc.iref.27"><b>5.4.4</b></a>, <a href="#rfc.xref.status.203.2">11.2</a>, <a href="#rfc.xref.status.203.3">C</a></li>
-                  <li>204 No Content (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.204.1">5.1</a>, <a href="#rfc.iref.28"><b>5.4.5</b></a>, <a href="#rfc.xref.status.204.2">11.2</a></li>
-                  <li>205 Reset Content (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.205.1">5.1</a>, <a href="#rfc.iref.29"><b>5.4.6</b></a>, <a href="#rfc.xref.status.205.2">11.2</a></li>
-                  <li>2xx Successful (status code class)&nbsp;&nbsp;<a href="#rfc.iref.23"><b>5.4</b></a></li>
+                  <li>200 OK (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.200.1">5.1</a>, <a href="#rfc.iref.25"><b>5.4.1</b></a>, <a href="#rfc.xref.status.200.2">11.2</a></li>
+                  <li>201 Created (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.201.1">5.1</a>, <a href="#rfc.iref.26"><b>5.4.2</b></a>, <a href="#rfc.xref.status.201.2">11.2</a></li>
+                  <li>202 Accepted (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.202.1">5.1</a>, <a href="#rfc.iref.27"><b>5.4.3</b></a>, <a href="#rfc.xref.status.202.2">11.2</a></li>
+                  <li>203 Non-Authoritative Information (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.203.1">5.1</a>, <a href="#rfc.iref.28"><b>5.4.4</b></a>, <a href="#rfc.xref.status.203.2">11.2</a>, <a href="#rfc.xref.status.203.3">C</a></li>
+                  <li>204 No Content (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.204.1">5.1</a>, <a href="#rfc.iref.29"><b>5.4.5</b></a>, <a href="#rfc.xref.status.204.2">11.2</a></li>
+                  <li>205 Reset Content (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.205.1">5.1</a>, <a href="#rfc.iref.30"><b>5.4.6</b></a>, <a href="#rfc.xref.status.205.2">11.2</a></li>
+                  <li>2xx Successful (status code class)&nbsp;&nbsp;<a href="#rfc.iref.24"><b>5.4</b></a></li>
                </ul>
             </li>
             <li><a id="rfc.index.3" href="#rfc.index.3"><b>3</b></a><ul>
-                  <li>300 Multiple Choices (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.300.1">5.1</a>, <a href="#rfc.iref.31"><b>5.5.1</b></a>, <a href="#rfc.xref.status.300.2">11.2</a></li>
-                  <li>301 Moved Permanently (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.301.1">5.1</a>, <a href="#rfc.iref.32"><b>5.5.2</b></a>, <a href="#rfc.xref.status.301.2">11.2</a>, <a href="#rfc.xref.status.301.3">C</a></li>
-                  <li>302 Found (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.302.1">5.1</a>, <a href="#rfc.iref.33"><b>5.5.3</b></a>, <a href="#rfc.xref.status.302.2">11.2</a>, <a href="#rfc.xref.status.302.3">C</a></li>
-                  <li>303 See Other (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.303.1">5.1</a>, <a href="#rfc.iref.34"><b>5.5.4</b></a>, <a href="#rfc.xref.status.303.2">11.2</a></li>
-                  <li>305 Use Proxy (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.305.1">5.1</a>, <a href="#rfc.iref.35"><b>5.5.5</b></a>, <a href="#rfc.xref.status.305.2">11.2</a>, <a href="#rfc.xref.status.305.3">C</a></li>
-                  <li>306 (Unused) (status code)&nbsp;&nbsp;<a href="#rfc.iref.36"><b>5.5.6</b></a>, <a href="#rfc.xref.status.306.1">11.2</a></li>
-                  <li>307 Temporary Redirect (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.307.1">5.1</a>, <a href="#rfc.iref.37"><b>5.5.7</b></a>, <a href="#rfc.xref.status.307.2">11.2</a>, <a href="#rfc.xref.status.307.3">C</a></li>
-                  <li>3xx Redirection (status code class)&nbsp;&nbsp;<a href="#rfc.iref.30"><b>5.5</b></a>, <a href="#rfc.xref.status.3xx.1">C</a></li>
+                  <li>300 Multiple Choices (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.300.1">5.1</a>, <a href="#rfc.iref.32"><b>5.5.1</b></a>, <a href="#rfc.xref.status.300.2">11.2</a></li>
+                  <li>301 Moved Permanently (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.301.1">5.1</a>, <a href="#rfc.iref.33"><b>5.5.2</b></a>, <a href="#rfc.xref.status.301.2">11.2</a>, <a href="#rfc.xref.status.301.3">C</a></li>
+                  <li>302 Found (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.302.1">5.1</a>, <a href="#rfc.iref.34"><b>5.5.3</b></a>, <a href="#rfc.xref.status.302.2">11.2</a>, <a href="#rfc.xref.status.302.3">C</a></li>
+                  <li>303 See Other (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.303.1">5.1</a>, <a href="#rfc.iref.35"><b>5.5.4</b></a>, <a href="#rfc.xref.status.303.2">11.2</a></li>
+                  <li>305 Use Proxy (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.305.1">5.1</a>, <a href="#rfc.iref.36"><b>5.5.5</b></a>, <a href="#rfc.xref.status.305.2">11.2</a>, <a href="#rfc.xref.status.305.3">C</a></li>
+                  <li>306 (Unused) (status code)&nbsp;&nbsp;<a href="#rfc.iref.37"><b>5.5.6</b></a>, <a href="#rfc.xref.status.306.1">11.2</a></li>
+                  <li>307 Temporary Redirect (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.307.1">5.1</a>, <a href="#rfc.iref.38"><b>5.5.7</b></a>, <a href="#rfc.xref.status.307.2">11.2</a>, <a href="#rfc.xref.status.307.3">C</a></li>
+                  <li>3xx Redirection (status code class)&nbsp;&nbsp;<a href="#rfc.iref.31"><b>5.5</b></a>, <a href="#rfc.xref.status.3xx.1">C</a></li>
                </ul>
             </li>
             <li><a id="rfc.index.4" href="#rfc.index.4"><b>4</b></a><ul>
-                  <li>400 Bad Request (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.400.1">5.1</a>, <a href="#rfc.iref.39"><b>5.6.1</b></a>, <a href="#rfc.xref.status.400.2">11.2</a></li>
-                  <li>402 Payment Required (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.402.1">5.1</a>, <a href="#rfc.iref.40"><b>5.6.2</b></a>, <a href="#rfc.xref.status.402.2">11.2</a></li>
-                  <li>403 Forbidden (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.403.1">5.1</a>, <a href="#rfc.iref.41"><b>5.6.3</b></a>, <a href="#rfc.xref.status.403.2">11.2</a></li>
-                  <li>404 Not Found (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.404.1">5.1</a>, <a href="#rfc.iref.42"><b>5.6.4</b></a>, <a href="#rfc.xref.status.404.2">11.2</a></li>
-                  <li>405 Method Not Allowed (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.405.1">5.1</a>, <a href="#rfc.iref.43"><b>5.6.5</b></a>, <a href="#rfc.xref.status.405.2">11.2</a></li>
-                  <li>406 Not Acceptable (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.406.1">5.1</a>, <a href="#rfc.iref.44"><b>5.6.6</b></a>, <a href="#rfc.xref.status.406.2">11.2</a></li>
-                  <li>408 Request Timeout (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.408.1">5.1</a>, <a href="#rfc.iref.45"><b>5.6.7</b></a>, <a href="#rfc.xref.status.408.2">11.2</a></li>
-                  <li>409 Conflict (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.409.1">5.1</a>, <a href="#rfc.iref.46"><b>5.6.8</b></a>, <a href="#rfc.xref.status.409.2">11.2</a></li>
-                  <li>410 Gone (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.410.1">5.1</a>, <a href="#rfc.iref.47"><b>5.6.9</b></a>, <a href="#rfc.xref.status.410.2">11.2</a></li>
-                  <li>411 Length Required (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.411.1">5.1</a>, <a href="#rfc.iref.48"><b>5.6.10</b></a>, <a href="#rfc.xref.status.411.2">11.2</a></li>
-                  <li>413 Request Representation Too Large (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.413.1">5.1</a>, <a href="#rfc.iref.49"><b>5.6.11</b></a>, <a href="#rfc.xref.status.413.2">11.2</a></li>
-                  <li>414 URI Too Long (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.414.1">5.1</a>, <a href="#rfc.iref.50"><b>5.6.12</b></a>, <a href="#rfc.xref.status.414.2">11.2</a></li>
-                  <li>415 Unsupported Media Type (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.415.1">5.1</a>, <a href="#rfc.iref.51"><b>5.6.13</b></a>, <a href="#rfc.xref.status.415.2">11.2</a></li>
-                  <li>417 Expectation Failed (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.417.1">5.1</a>, <a href="#rfc.iref.52"><b>5.6.14</b></a>, <a href="#rfc.xref.status.417.2">11.2</a></li>
-                  <li>426 Upgrade Required (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.426.1">5.1</a>, <a href="#rfc.iref.53"><b>5.6.15</b></a>, <a href="#rfc.xref.status.426.2">11.2</a>, <a href="#rfc.xref.status.426.3">C</a></li>
-                  <li>4xx Client Error (status code class)&nbsp;&nbsp;<a href="#rfc.iref.38"><b>5.6</b></a></li>
+                  <li>400 Bad Request (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.400.1">5.1</a>, <a href="#rfc.iref.40"><b>5.6.1</b></a>, <a href="#rfc.xref.status.400.2">11.2</a></li>
+                  <li>402 Payment Required (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.402.1">5.1</a>, <a href="#rfc.iref.41"><b>5.6.2</b></a>, <a href="#rfc.xref.status.402.2">11.2</a></li>
+                  <li>403 Forbidden (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.403.1">5.1</a>, <a href="#rfc.iref.42"><b>5.6.3</b></a>, <a href="#rfc.xref.status.403.2">11.2</a></li>
+                  <li>404 Not Found (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.404.1">5.1</a>, <a href="#rfc.iref.43"><b>5.6.4</b></a>, <a href="#rfc.xref.status.404.2">11.2</a></li>
+                  <li>405 Method Not Allowed (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.405.1">5.1</a>, <a href="#rfc.iref.44"><b>5.6.5</b></a>, <a href="#rfc.xref.status.405.2">11.2</a></li>
+                  <li>406 Not Acceptable (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.406.1">5.1</a>, <a href="#rfc.iref.45"><b>5.6.6</b></a>, <a href="#rfc.xref.status.406.2">11.2</a></li>
+                  <li>408 Request Timeout (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.408.1">5.1</a>, <a href="#rfc.iref.46"><b>5.6.7</b></a>, <a href="#rfc.xref.status.408.2">11.2</a></li>
+                  <li>409 Conflict (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.409.1">5.1</a>, <a href="#rfc.iref.47"><b>5.6.8</b></a>, <a href="#rfc.xref.status.409.2">11.2</a></li>
+                  <li>410 Gone (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.410.1">5.1</a>, <a href="#rfc.iref.48"><b>5.6.9</b></a>, <a href="#rfc.xref.status.410.2">11.2</a></li>
+                  <li>411 Length Required (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.411.1">5.1</a>, <a href="#rfc.iref.49"><b>5.6.10</b></a>, <a href="#rfc.xref.status.411.2">11.2</a></li>
+                  <li>413 Request Representation Too Large (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.413.1">5.1</a>, <a href="#rfc.iref.50"><b>5.6.11</b></a>, <a href="#rfc.xref.status.413.2">11.2</a></li>
+                  <li>414 URI Too Long (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.414.1">5.1</a>, <a href="#rfc.iref.51"><b>5.6.12</b></a>, <a href="#rfc.xref.status.414.2">11.2</a></li>
+                  <li>415 Unsupported Media Type (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.415.1">5.1</a>, <a href="#rfc.iref.52"><b>5.6.13</b></a>, <a href="#rfc.xref.status.415.2">11.2</a></li>
+                  <li>417 Expectation Failed (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.417.1">5.1</a>, <a href="#rfc.iref.53"><b>5.6.14</b></a>, <a href="#rfc.xref.status.417.2">11.2</a></li>
+                  <li>426 Upgrade Required (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.426.1">5.1</a>, <a href="#rfc.iref.54"><b>5.6.15</b></a>, <a href="#rfc.xref.status.426.2">11.2</a>, <a href="#rfc.xref.status.426.3">C</a></li>
+                  <li>4xx Client Error (status code class)&nbsp;&nbsp;<a href="#rfc.iref.39"><b>5.6</b></a></li>
                </ul>
             </li>
             <li><a id="rfc.index.5" href="#rfc.index.5"><b>5</b></a><ul>
-                  <li>500 Internal Server Error (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.500.1">5.1</a>, <a href="#rfc.iref.55"><b>5.7.1</b></a>, <a href="#rfc.xref.status.500.2">11.2</a></li>
-                  <li>501 Not Implemented (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.501.1">5.1</a>, <a href="#rfc.iref.56"><b>5.7.2</b></a>, <a href="#rfc.xref.status.501.2">11.2</a></li>
-                  <li>502 Bad Gateway (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.502.1">5.1</a>, <a href="#rfc.iref.57"><b>5.7.3</b></a>, <a href="#rfc.xref.status.502.2">11.2</a></li>
-                  <li>503 Service Unavailable (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.503.1">5.1</a>, <a href="#rfc.iref.58"><b>5.7.4</b></a>, <a href="#rfc.xref.status.503.2">11.2</a></li>
-                  <li>504 Gateway Timeout (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.504.1">5.1</a>, <a href="#rfc.iref.59"><b>5.7.5</b></a>, <a href="#rfc.xref.status.504.2">11.2</a></li>
-                  <li>505 HTTP Version Not Supported (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.505.1">5.1</a>, <a href="#rfc.iref.60"><b>5.7.6</b></a>, <a href="#rfc.xref.status.505.2">11.2</a></li>
-                  <li>5xx Server Error (status code class)&nbsp;&nbsp;<a href="#rfc.iref.54"><b>5.7</b></a></li>
+                  <li>500 Internal Server Error (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.500.1">5.1</a>, <a href="#rfc.iref.56"><b>5.7.1</b></a>, <a href="#rfc.xref.status.500.2">11.2</a></li>
+                  <li>501 Not Implemented (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.501.1">5.1</a>, <a href="#rfc.iref.57"><b>5.7.2</b></a>, <a href="#rfc.xref.status.501.2">11.2</a></li>
+                  <li>502 Bad Gateway (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.502.1">5.1</a>, <a href="#rfc.iref.58"><b>5.7.3</b></a>, <a href="#rfc.xref.status.502.2">11.2</a></li>
+                  <li>503 Service Unavailable (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.503.1">5.1</a>, <a href="#rfc.iref.59"><b>5.7.4</b></a>, <a href="#rfc.xref.status.503.2">11.2</a></li>
+                  <li>504 Gateway Timeout (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.504.1">5.1</a>, <a href="#rfc.iref.60"><b>5.7.5</b></a>, <a href="#rfc.xref.status.504.2">11.2</a></li>
+                  <li>505 HTTP Version Not Supported (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.505.1">5.1</a>, <a href="#rfc.iref.61"><b>5.7.6</b></a>, <a href="#rfc.xref.status.505.2">11.2</a></li>
+                  <li>5xx Server Error (status code class)&nbsp;&nbsp;<a href="#rfc.iref.55"><b>5.7</b></a></li>
                </ul>
             </li>
@@ -4849 +4867 @@
             </li>
             <li><a id="rfc.index.C" href="#rfc.index.C"><b>C</b></a><ul>
+                  <li>cacheable&nbsp;&nbsp;<a href="#rfc.iref.c.2"><b>3.1.3</b></a></li>
                   <li>Coding Format&nbsp;&nbsp;
                      <ul>
-                        <li>compress&nbsp;&nbsp;<a href="#rfc.iref.c.4">6.4</a></li>
-                        <li>deflate&nbsp;&nbsp;<a href="#rfc.iref.c.5">6.4</a></li>
-                        <li>gzip&nbsp;&nbsp;<a href="#rfc.iref.c.6">6.4</a></li>
+                        <li>compress&nbsp;&nbsp;<a href="#rfc.iref.c.5">6.4</a></li>
+                        <li>deflate&nbsp;&nbsp;<a href="#rfc.iref.c.6">6.4</a></li>
+                        <li>gzip&nbsp;&nbsp;<a href="#rfc.iref.c.7">6.4</a></li>
                      </ul>
                   </li>
-                  <li>compress (Coding Format)&nbsp;&nbsp;<a href="#rfc.iref.c.3">6.4</a></li>
-                  <li>CONNECT method&nbsp;&nbsp;<a href="#rfc.xref.CONNECT.1">3</a>, <a href="#rfc.iref.c.2"><b>3.3.8</b></a>, <a href="#rfc.xref.CONNECT.2">11.1</a>, <a href="#rfc.xref.CONNECT.3">C</a></li>
+                  <li>compress (Coding Format)&nbsp;&nbsp;<a href="#rfc.iref.c.4">6.4</a></li>
+                  <li>CONNECT method&nbsp;&nbsp;<a href="#rfc.xref.CONNECT.1">3</a>, <a href="#rfc.iref.c.3"><b>3.2.8</b></a>, <a href="#rfc.xref.CONNECT.2">11.1.2</a>, <a href="#rfc.xref.CONNECT.3">C</a></li>
                   <li>content negotiation&nbsp;&nbsp;<a href="#rfc.iref.c.1">1</a></li>
-                  <li>Content-Encoding header field&nbsp;&nbsp;<a href="#rfc.xref.header.content-encoding.1">6.4</a>, <a href="#rfc.xref.header.content-encoding.2">8.2</a>, <a href="#rfc.iref.c.7"><b>10.6</b></a>, <a href="#rfc.xref.header.content-encoding.3">11.3</a></li>
-                  <li>Content-Language header field&nbsp;&nbsp;<a href="#rfc.xref.header.content-language.1">8.2</a>, <a href="#rfc.iref.c.8"><b>10.7</b></a>, <a href="#rfc.xref.header.content-language.2">11.3</a></li>
-                  <li>Content-Location header field&nbsp;&nbsp;<a href="#rfc.xref.header.content-location.1">3.3.4</a>, <a href="#rfc.xref.header.content-location.2">8.2</a>, <a href="#rfc.iref.c.9"><b>10.8</b></a>, <a href="#rfc.xref.header.content-location.3">10.13</a>, <a href="#rfc.xref.header.content-location.4">11.3</a>, <a href="#rfc.xref.header.content-location.5">C</a></li>
-                  <li>Content-Transfer-Encoding header field&nbsp;&nbsp;<a href="#rfc.iref.c.11">A.5</a>, <a href="#rfc.xref.no.content-transfer-encoding.1">C</a></li>
-                  <li>Content-Type header field&nbsp;&nbsp;<a href="#rfc.xref.header.content-type.1">4.5</a>, <a href="#rfc.xref.header.content-type.2">5</a>, <a href="#rfc.xref.header.content-type.3">6.5</a>, <a href="#rfc.xref.header.content-type.4">8.2</a>, <a href="#rfc.iref.c.10"><b>10.9</b></a>, <a href="#rfc.xref.header.content-type.5">11.3</a></li>
+                  <li>Content-Encoding header field&nbsp;&nbsp;<a href="#rfc.xref.header.content-encoding.1">6.4</a>, <a href="#rfc.xref.header.content-encoding.2">8.2</a>, <a href="#rfc.iref.c.8"><b>10.6</b></a>, <a href="#rfc.xref.header.content-encoding.3">11.3</a></li>
+                  <li>Content-Language header field&nbsp;&nbsp;<a href="#rfc.xref.header.content-language.1">8.2</a>, <a href="#rfc.iref.c.9"><b>10.7</b></a>, <a href="#rfc.xref.header.content-language.2">11.3</a></li>
+                  <li>Content-Location header field&nbsp;&nbsp;<a href="#rfc.xref.header.content-location.1">3.2.4</a>, <a href="#rfc.xref.header.content-location.2">8.2</a>, <a href="#rfc.iref.c.10"><b>10.8</b></a>, <a href="#rfc.xref.header.content-location.3">10.13</a>, <a href="#rfc.xref.header.content-location.4">11.3</a>, <a href="#rfc.xref.header.content-location.5">C</a></li>
+                  <li>Content-Transfer-Encoding header field&nbsp;&nbsp;<a href="#rfc.iref.c.12">A.5</a>, <a href="#rfc.xref.no.content-transfer-encoding.1">C</a></li>
+                  <li>Content-Type header field&nbsp;&nbsp;<a href="#rfc.xref.header.content-type.1">4.5</a>, <a href="#rfc.xref.header.content-type.2">5</a>, <a href="#rfc.xref.header.content-type.3">6.5</a>, <a href="#rfc.xref.header.content-type.4">8.2</a>, <a href="#rfc.iref.c.11"><b>10.9</b></a>, <a href="#rfc.xref.header.content-type.5">11.3</a></li>
                </ul>
             </li>
@@ -4869 +4888 @@
                   <li>Date header field&nbsp;&nbsp;<a href="#rfc.xref.header.date.1">4.7</a>, <a href="#rfc.iref.d.3"><b>10.10</b></a>, <a href="#rfc.xref.header.date.2">11.3</a></li>
                   <li>deflate (Coding Format)&nbsp;&nbsp;<a href="#rfc.iref.d.2">6.4</a></li>
-                  <li>DELETE method&nbsp;&nbsp;<a href="#rfc.xref.DELETE.1">3</a>, <a href="#rfc.iref.d.1"><b>3.3.6</b></a>, <a href="#rfc.xref.DELETE.2">11.1</a></li>
+                  <li>DELETE method&nbsp;&nbsp;<a href="#rfc.xref.DELETE.1">3</a>, <a href="#rfc.iref.d.1"><b>3.2.6</b></a>, <a href="#rfc.xref.DELETE.2">11.1.2</a></li>
                   <li><em>draft-reschke-http-status-308</em>&nbsp;&nbsp;<a href="#rfc.xref.draft-reschke-http-status-308.1">5.5.7</a>, <a href="#draft-reschke-http-status-308"><b>14.2</b></a></li>
                </ul>
@@ -4887 +4906 @@
             </li>
             <li><a id="rfc.index.G" href="#rfc.index.G"><b>G</b></a><ul>
-                  <li>GET method&nbsp;&nbsp;<a href="#rfc.xref.GET.1">3</a>, <a href="#rfc.iref.g.2"><b>3.3.2</b></a>, <a href="#rfc.xref.GET.2">11.1</a></li>
+                  <li>GET method&nbsp;&nbsp;<a href="#rfc.xref.GET.1">3</a>, <a href="#rfc.iref.g.2"><b>3.2.2</b></a>, <a href="#rfc.xref.GET.2">11.1.2</a></li>
                   <li><tt>Grammar</tt>&nbsp;&nbsp;
                      <ul>
@@ -4955 +4974 @@
             </li>
             <li><a id="rfc.index.H" href="#rfc.index.H"><b>H</b></a><ul>
-                  <li>HEAD method&nbsp;&nbsp;<a href="#rfc.xref.HEAD.1">3</a>, <a href="#rfc.iref.h.1"><b>3.3.3</b></a>, <a href="#rfc.xref.HEAD.2">11.1</a></li>
+                  <li>HEAD method&nbsp;&nbsp;<a href="#rfc.xref.HEAD.1">3</a>, <a href="#rfc.iref.h.1"><b>3.2.3</b></a>, <a href="#rfc.xref.HEAD.2">11.1.2</a></li>
                   <li>Header Fields&nbsp;&nbsp;
                      <ul>
@@ -4965 +4984 @@
                         <li>Content-Encoding&nbsp;&nbsp;<a href="#rfc.xref.header.content-encoding.1">6.4</a>, <a href="#rfc.xref.header.content-encoding.2">8.2</a>, <a href="#rfc.iref.h.7"><b>10.6</b></a>, <a href="#rfc.xref.header.content-encoding.3">11.3</a></li>
                         <li>Content-Language&nbsp;&nbsp;<a href="#rfc.xref.header.content-language.1">8.2</a>, <a href="#rfc.iref.h.8"><b>10.7</b></a>, <a href="#rfc.xref.header.content-language.2">11.3</a></li>
-                        <li>Content-Location&nbsp;&nbsp;<a href="#rfc.xref.header.content-location.1">3.3.4</a>, <a href="#rfc.xref.header.content-location.2">8.2</a>, <a href="#rfc.iref.h.9"><b>10.8</b></a>, <a href="#rfc.xref.header.content-location.3">10.13</a>, <a href="#rfc.xref.header.content-location.4">11.3</a>, <a href="#rfc.xref.header.content-location.5">C</a></li>
+                        <li>Content-Location&nbsp;&nbsp;<a href="#rfc.xref.header.content-location.1">3.2.4</a>, <a href="#rfc.xref.header.content-location.2">8.2</a>, <a href="#rfc.iref.h.9"><b>10.8</b></a>, <a href="#rfc.xref.header.content-location.3">10.13</a>, <a href="#rfc.xref.header.content-location.4">11.3</a>, <a href="#rfc.xref.header.content-location.5">C</a></li>
                         <li>Content-Transfer-Encoding&nbsp;&nbsp;<a href="#rfc.iref.h.21">A.5</a>, <a href="#rfc.xref.no.content-transfer-encoding.1">C</a></li>
                         <li>Content-Type&nbsp;&nbsp;<a href="#rfc.xref.header.content-type.1">4.5</a>, <a href="#rfc.xref.header.content-type.2">5</a>, <a href="#rfc.xref.header.content-type.3">6.5</a>, <a href="#rfc.xref.header.content-type.4">8.2</a>, <a href="#rfc.iref.h.10"><b>10.9</b></a>, <a href="#rfc.xref.header.content-type.5">11.3</a></li>
@@ -4971 +4990 @@
                         <li>Expect&nbsp;&nbsp;<a href="#rfc.xref.header.expect.1">4.6</a>, <a href="#rfc.xref.header.expect.2">5.6.14</a>, <a href="#rfc.iref.h.12"><b>10.11</b></a>, <a href="#rfc.xref.header.expect.3">11.3</a>, <a href="#rfc.xref.header.expect.4">C</a></li>
                         <li>From&nbsp;&nbsp;<a href="#rfc.xref.header.from.1">4.6</a>, <a href="#rfc.iref.h.13"><b>10.12</b></a>, <a href="#rfc.xref.header.from.2">11.3</a></li>
-                        <li>Location&nbsp;&nbsp;<a href="#rfc.xref.header.location.1">3.3.4</a>, <a href="#rfc.xref.header.location.2">4.7</a>, <a href="#rfc.xref.header.location.3">5.5</a>, <a href="#rfc.iref.h.14"><b>10.13</b></a>, <a href="#rfc.xref.header.location.4">11.3</a>, <a href="#rfc.xref.header.location.5">C</a></li>
-                        <li>Max-Forwards&nbsp;&nbsp;<a href="#rfc.xref.header.max-forwards.1">3.3.1</a>, <a href="#rfc.xref.header.max-forwards.2">3.3.7</a>, <a href="#rfc.xref.header.max-forwards.3">4.6</a>, <a href="#rfc.iref.h.15"><b>10.14</b></a>, <a href="#rfc.xref.header.max-forwards.4">11.3</a>, <a href="#rfc.xref.header.max-forwards.5">C</a></li>
+                        <li>Location&nbsp;&nbsp;<a href="#rfc.xref.header.location.1">3.2.4</a>, <a href="#rfc.xref.header.location.2">4.7</a>, <a href="#rfc.xref.header.location.3">5.5</a>, <a href="#rfc.iref.h.14"><b>10.13</b></a>, <a href="#rfc.xref.header.location.4">11.3</a>, <a href="#rfc.xref.header.location.5">C</a></li>
+                        <li>Max-Forwards&nbsp;&nbsp;<a href="#rfc.xref.header.max-forwards.1">3.2.1</a>, <a href="#rfc.xref.header.max-forwards.2">3.2.7</a>, <a href="#rfc.xref.header.max-forwards.3">4.6</a>, <a href="#rfc.iref.h.15"><b>10.14</b></a>, <a href="#rfc.xref.header.max-forwards.4">11.3</a>, <a href="#rfc.xref.header.max-forwards.5">C</a></li>
                         <li>MIME-Version&nbsp;&nbsp;<a href="#rfc.xref.mime-version.1">11.3</a>, <a href="#rfc.iref.h.20"><b>A.1</b></a></li>
                         <li>Referer&nbsp;&nbsp;<a href="#rfc.xref.header.referer.1">4.6</a>, <a href="#rfc.iref.h.16"><b>10.15</b></a>, <a href="#rfc.xref.header.referer.2">11.3</a>, <a href="#rfc.xref.header.referer.3">C</a></li>
@@ -4983 +5002 @@
             </li>
             <li><a id="rfc.index.I" href="#rfc.index.I"><b>I</b></a><ul>
-                  <li>Idempotent Methods&nbsp;&nbsp;<a href="#rfc.iref.i.1"><b>3.1.2</b></a></li>
+                  <li>idempotent&nbsp;&nbsp;<a href="#rfc.iref.i.1"><b>3.1.2</b></a></li>
                </ul>
             </li>
             <li><a id="rfc.index.L" href="#rfc.index.L"><b>L</b></a><ul>
-                  <li>Location header field&nbsp;&nbsp;<a href="#rfc.xref.header.location.1">3.3.4</a>, <a href="#rfc.xref.header.location.2">4.7</a>, <a href="#rfc.xref.header.location.3">5.5</a>, <a href="#rfc.iref.l.1"><b>10.13</b></a>, <a href="#rfc.xref.header.location.4">11.3</a>, <a href="#rfc.xref.header.location.5">C</a></li>
+                  <li>Location header field&nbsp;&nbsp;<a href="#rfc.xref.header.location.1">3.2.4</a>, <a href="#rfc.xref.header.location.2">4.7</a>, <a href="#rfc.xref.header.location.3">5.5</a>, <a href="#rfc.iref.l.1"><b>10.13</b></a>, <a href="#rfc.xref.header.location.4">11.3</a>, <a href="#rfc.xref.header.location.5">C</a></li>
                </ul>
             </li>
             <li><a id="rfc.index.M" href="#rfc.index.M"><b>M</b></a><ul>
-                  <li>Max-Forwards header field&nbsp;&nbsp;<a href="#rfc.xref.header.max-forwards.1">3.3.1</a>, <a href="#rfc.xref.header.max-forwards.2">3.3.7</a>, <a href="#rfc.xref.header.max-forwards.3">4.6</a>, <a href="#rfc.iref.m.9"><b>10.14</b></a>, <a href="#rfc.xref.header.max-forwards.4">11.3</a>, <a href="#rfc.xref.header.max-forwards.5">C</a></li>
+                  <li>Max-Forwards header field&nbsp;&nbsp;<a href="#rfc.xref.header.max-forwards.1">3.2.1</a>, <a href="#rfc.xref.header.max-forwards.2">3.2.7</a>, <a href="#rfc.xref.header.max-forwards.3">4.6</a>, <a href="#rfc.iref.m.9"><b>10.14</b></a>, <a href="#rfc.xref.header.max-forwards.4">11.3</a>, <a href="#rfc.xref.header.max-forwards.5">C</a></li>
                   <li>Methods&nbsp;&nbsp;
                      <ul>
-                        <li>CONNECT&nbsp;&nbsp;<a href="#rfc.xref.CONNECT.1">3</a>, <a href="#rfc.iref.m.8"><b>3.3.8</b></a>, <a href="#rfc.xref.CONNECT.2">11.1</a>, <a href="#rfc.xref.CONNECT.3">C</a></li>
-                        <li>DELETE&nbsp;&nbsp;<a href="#rfc.xref.DELETE.1">3</a>, <a href="#rfc.iref.m.6"><b>3.3.6</b></a>, <a href="#rfc.xref.DELETE.2">11.1</a></li>
-                        <li>GET&nbsp;&nbsp;<a href="#rfc.xref.GET.1">3</a>, <a href="#rfc.iref.m.2"><b>3.3.2</b></a>, <a href="#rfc.xref.GET.2">11.1</a></li>
-                        <li>HEAD&nbsp;&nbsp;<a href="#rfc.xref.HEAD.1">3</a>, <a href="#rfc.iref.m.3"><b>3.3.3</b></a>, <a href="#rfc.xref.HEAD.2">11.1</a></li>
-                        <li>OPTIONS&nbsp;&nbsp;<a href="#rfc.xref.OPTIONS.1">3</a>, <a href="#rfc.iref.m.1"><b>3.3.1</b></a>, <a href="#rfc.xref.OPTIONS.2">10.14</a>, <a href="#rfc.xref.OPTIONS.3">11.1</a></li>
-                        <li>POST&nbsp;&nbsp;<a href="#rfc.xref.POST.1">3</a>, <a href="#rfc.iref.m.4"><b>3.3.4</b></a>, <a href="#rfc.xref.POST.2">11.1</a>, <a href="#rfc.xref.POST.3">C</a></li>
-                        <li>PUT&nbsp;&nbsp;<a href="#rfc.xref.PUT.1">3</a>, <a href="#rfc.iref.m.5"><b>3.3.5</b></a>, <a href="#rfc.xref.PUT.2">11.1</a>, <a href="#rfc.xref.PUT.3">C</a></li>
-                        <li>TRACE&nbsp;&nbsp;<a href="#rfc.xref.TRACE.1">3</a>, <a href="#rfc.iref.m.7"><b>3.3.7</b></a>, <a href="#rfc.xref.TRACE.2">10.14</a>, <a href="#rfc.xref.TRACE.3">11.1</a>, <a href="#rfc.xref.TRACE.4">12.1</a></li>
+                        <li>CONNECT&nbsp;&nbsp;<a href="#rfc.xref.CONNECT.1">3</a>, <a href="#rfc.iref.m.8"><b>3.2.8</b></a>, <a href="#rfc.xref.CONNECT.2">11.1.2</a>, <a href="#rfc.xref.CONNECT.3">C</a></li>
+                        <li>DELETE&nbsp;&nbsp;<a href="#rfc.xref.DELETE.1">3</a>, <a href="#rfc.iref.m.6"><b>3.2.6</b></a>, <a href="#rfc.xref.DELETE.2">11.1.2</a></li>
+                        <li>GET&nbsp;&nbsp;<a href="#rfc.xref.GET.1">3</a>, <a href="#rfc.iref.m.2"><b>3.2.2</b></a>, <a href="#rfc.xref.GET.2">11.1.2</a></li>
+                        <li>HEAD&nbsp;&nbsp;<a href="#rfc.xref.HEAD.1">3</a>, <a href="#rfc.iref.m.3"><b>3.2.3</b></a>, <a href="#rfc.xref.HEAD.2">11.1.2</a></li>
+                        <li>OPTIONS&nbsp;&nbsp;<a href="#rfc.xref.OPTIONS.1">3</a>, <a href="#rfc.iref.m.1"><b>3.2.1</b></a>, <a href="#rfc.xref.OPTIONS.2">10.14</a>, <a href="#rfc.xref.OPTIONS.3">11.1.2</a></li>
+                        <li>POST&nbsp;&nbsp;<a href="#rfc.xref.POST.1">3</a>, <a href="#rfc.iref.m.4"><b>3.2.4</b></a>, <a href="#rfc.xref.POST.2">11.1.2</a>, <a href="#rfc.xref.POST.3">C</a></li>
+                        <li>PUT&nbsp;&nbsp;<a href="#rfc.xref.PUT.1">3</a>, <a href="#rfc.iref.m.5"><b>3.2.5</b></a>, <a href="#rfc.xref.PUT.2">11.1.2</a>, <a href="#rfc.xref.PUT.3">C</a></li>
+                        <li>TRACE&nbsp;&nbsp;<a href="#rfc.xref.TRACE.1">3</a>, <a href="#rfc.iref.m.7"><b>3.2.7</b></a>, <a href="#rfc.xref.TRACE.2">10.14</a>, <a href="#rfc.xref.TRACE.3">11.1.2</a>, <a href="#rfc.xref.TRACE.4">12.1</a></li>
                      </ul>
                   </li>
@@ -5008 +5027 @@
             </li>
             <li><a id="rfc.index.O" href="#rfc.index.O"><b>O</b></a><ul>
-                  <li>OPTIONS method&nbsp;&nbsp;<a href="#rfc.xref.OPTIONS.1">3</a>, <a href="#rfc.iref.o.1"><b>3.3.1</b></a>, <a href="#rfc.xref.OPTIONS.2">10.14</a>, <a href="#rfc.xref.OPTIONS.3">11.1</a></li>
+                  <li>OPTIONS method&nbsp;&nbsp;<a href="#rfc.xref.OPTIONS.1">3</a>, <a href="#rfc.iref.o.1"><b>3.2.1</b></a>, <a href="#rfc.xref.OPTIONS.2">10.14</a>, <a href="#rfc.xref.OPTIONS.3">11.1.2</a></li>
                </ul>
             </li>
             <li><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul>
-                  <li><em>Part1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.1">1</a>, <a href="#rfc.xref.Part1.2">1.1</a>, <a href="#rfc.xref.Part1.3">1.2</a>, <a href="#rfc.xref.Part1.4">2</a>, <a href="#rfc.xref.Part1.5">2</a>, <a href="#rfc.xref.Part1.6">2</a>, <a href="#rfc.xref.Part1.7">3.2.1</a>, <a href="#rfc.xref.Part1.8">3.3.1</a>, <a href="#rfc.xref.Part1.9">3.3.7</a>, <a href="#rfc.xref.Part1.10">3.3.7</a>, <a href="#rfc.xref.Part1.11">3.3.8</a>, <a href="#rfc.xref.Part1.12">4</a>, <a href="#rfc.xref.Part1.13">4.5</a>, <a href="#rfc.xref.Part1.14">4.5</a>, <a href="#rfc.xref.Part1.15">4.5</a>, <a href="#rfc.xref.Part1.16">4.5</a>, <a href="#rfc.xref.Part1.17">4.5</a>, <a href="#rfc.xref.Part1.18">4.6</a>, <a href="#rfc.xref.Part1.19">4.6</a>, <a href="#rfc.xref.Part1.20">4.7</a>, <a href="#rfc.xref.Part1.21">5.3.1</a>, <a href="#rfc.xref.Part1.22">5.3.2</a>, <a href="#rfc.xref.Part1.23">5.4.4</a>, <a href="#rfc.xref.Part1.24">5.4.6</a>, <a href="#rfc.xref.Part1.25">5.6.15</a>, <a href="#rfc.xref.Part1.26">5.7.6</a>, <a href="#rfc.xref.Part1.27">6.4</a>, <a href="#rfc.xref.Part1.28">6.4</a>, <a href="#rfc.xref.Part1.29">6.4</a>, <a href="#rfc.xref.Part1.30">6.4.1</a>, <a href="#rfc.xref.Part1.31">6.4.1</a>, <a href="#rfc.xref.Part1.32">7.1</a>, <a href="#rfc.xref.Part1.33">7.2</a>, <a href="#rfc.xref.Part1.34">8</a>, <a href="#rfc.xref.Part1.35">8.1</a>, <a href="#rfc.xref.Part1.36">10.8</a>, <a href="#rfc.xref.Part1.37">10.11</a>, <a href="#rfc.xref.Part1.38">10.17</a>, <a href="#rfc.xref.Part1.39">10.17</a>, <a href="#rfc.xref.Part1.40">10.18</a>, <a href="#rfc.xref.Part1.41">11.4</a>, <a href="#rfc.xref.Part1.42">11.4</a>, <a href="#rfc.xref.Part1.43">11.4</a>, <a href="#rfc.xref.Part1.44">13</a>, <a href="#Part1"><b>14.1</b></a>, <a href="#rfc.xref.Part1.45">C</a>, <a href="#rfc.xref.Part1.46">D</a>, <a href="#rfc.xref.Part1.47">D</a>, <a href="#rfc.xref.Part1.48">D</a>, <a href="#rfc.xref.Part1.49">D</a>, <a href="#rfc.xref.Part1.50">D</a>, <a href="#rfc.xref.Part1.51">D</a>, <a href="#rfc.xref.Part1.52">D</a>, <a href="#rfc.xref.Part1.53">D</a>, <a href="#rfc.xref.Part1.54">D</a>, <a href="#rfc.xref.Part1.55">D</a>, <a href="#rfc.xref.Part1.56">D</a><ul>
+                  <li><em>Part1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.1">1</a>, <a href="#rfc.xref.Part1.2">1.1</a>, <a href="#rfc.xref.Part1.3">1.2</a>, <a href="#rfc.xref.Part1.4">2</a>, <a href="#rfc.xref.Part1.5">2</a>, <a href="#rfc.xref.Part1.6">2</a>, <a href="#rfc.xref.Part1.7">3.2.1</a>, <a href="#rfc.xref.Part1.8">3.2.7</a>, <a href="#rfc.xref.Part1.9">3.2.7</a>, <a href="#rfc.xref.Part1.10">3.2.8</a>, <a href="#rfc.xref.Part1.11">4</a>, <a href="#rfc.xref.Part1.12">4.5</a>, <a href="#rfc.xref.Part1.13">4.5</a>, <a href="#rfc.xref.Part1.14">4.5</a>, <a href="#rfc.xref.Part1.15">4.5</a>, <a href="#rfc.xref.Part1.16">4.5</a>, <a href="#rfc.xref.Part1.17">4.6</a>, <a href="#rfc.xref.Part1.18">4.6</a>, <a href="#rfc.xref.Part1.19">4.7</a>, <a href="#rfc.xref.Part1.20">5.3.1</a>, <a href="#rfc.xref.Part1.21">5.3.2</a>, <a href="#rfc.xref.Part1.22">5.4.4</a>, <a href="#rfc.xref.Part1.23">5.4.6</a>, <a href="#rfc.xref.Part1.24">5.6.15</a>, <a href="#rfc.xref.Part1.25">5.7.6</a>, <a href="#rfc.xref.Part1.26">6.4</a>, <a href="#rfc.xref.Part1.27">6.4</a>, <a href="#rfc.xref.Part1.28">6.4</a>, <a href="#rfc.xref.Part1.29">6.4.1</a>, <a href="#rfc.xref.Part1.30">6.4.1</a>, <a href="#rfc.xref.Part1.31">7.1</a>, <a href="#rfc.xref.Part1.32">7.2</a>, <a href="#rfc.xref.Part1.33">8</a>, <a href="#rfc.xref.Part1.34">8.1</a>, <a href="#rfc.xref.Part1.35">10.8</a>, <a href="#rfc.xref.Part1.36">10.11</a>, <a href="#rfc.xref.Part1.37">10.17</a>, <a href="#rfc.xref.Part1.38">10.17</a>, <a href="#rfc.xref.Part1.39">10.18</a>, <a href="#rfc.xref.Part1.40">11.1.1</a>, <a href="#rfc.xref.Part1.41">11.4</a>, <a href="#rfc.xref.Part1.42">11.4</a>, <a href="#rfc.xref.Part1.43">11.4</a>, <a href="#rfc.xref.Part1.44">13</a>, <a href="#Part1"><b>14.1</b></a>, <a href="#rfc.xref.Part1.45">C</a>, <a href="#rfc.xref.Part1.46">D</a>, <a href="#rfc.xref.Part1.47">D</a>, <a href="#rfc.xref.Part1.48">D</a>, <a href="#rfc.xref.Part1.49">D</a>, <a href="#rfc.xref.Part1.50">D</a>, <a href="#rfc.xref.Part1.51">D</a>, <a href="#rfc.xref.Part1.52">D</a>, <a href="#rfc.xref.Part1.53">D</a>, <a href="#rfc.xref.Part1.54">D</a>, <a href="#rfc.xref.Part1.55">D</a>, <a href="#rfc.xref.Part1.56">D</a><ul>
                         <li><em>Section 1.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.3">1.2</a></li>
-                        <li><em>Section 2.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.23">5.4.4</a></li>
+                        <li><em>Section 2.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.22">5.4.4</a></li>
                         <li><em>Section 2.5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.2">1.1</a></li>
-                        <li><em>Section 2.6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.26">5.7.6</a></li>
+                        <li><em>Section 2.6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.25">5.7.6</a></li>
                         <li><em>Section 2.7</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.4">2</a>, <a href="#rfc.xref.Part1.53">D</a>, <a href="#rfc.xref.Part1.55">D</a>, <a href="#rfc.xref.Part1.56">D</a></li>
-                        <li><em>Section 3.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.12">4</a>, <a href="#rfc.xref.Part1.15">4.5</a>, <a href="#rfc.xref.Part1.38">10.17</a>, <a href="#rfc.xref.Part1.40">10.18</a></li>
+                        <li><em>Section 3.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.11">4</a>, <a href="#rfc.xref.Part1.14">4.5</a>, <a href="#rfc.xref.Part1.37">10.17</a>, <a href="#rfc.xref.Part1.39">10.18</a></li>
                         <li><em>Section 3.2.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.47">D</a>, <a href="#rfc.xref.Part1.48">D</a>, <a href="#rfc.xref.Part1.49">D</a></li>
-                        <li><em>Section 3.2.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.14">4.5</a>, <a href="#rfc.xref.Part1.50">D</a>, <a href="#rfc.xref.Part1.51">D</a>, <a href="#rfc.xref.Part1.52">D</a>, <a href="#rfc.xref.Part1.54">D</a></li>
-                        <li><em>Section 3.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.7">3.2.1</a>, <a href="#rfc.xref.Part1.24">5.4.6</a>, <a href="#rfc.xref.Part1.33">7.2</a>, <a href="#rfc.xref.Part1.34">8</a></li>
-                        <li><em>Section 3.3.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.32">7.1</a></li>
-                        <li><em>Section 4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.30">6.4.1</a></li>
-                        <li><em>Section 4.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.17">4.5</a></li>
-                        <li><em>Section 4.2.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.27">6.4</a>, <a href="#rfc.xref.Part1.41">11.4</a></li>
-                        <li><em>Section 4.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.31">6.4.1</a></li>
-                        <li><em>Section 4.2.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.28">6.4</a>, <a href="#rfc.xref.Part1.42">11.4</a></li>
-                        <li><em>Section 4.2.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.29">6.4</a>, <a href="#rfc.xref.Part1.43">11.4</a></li>
-                        <li><em>Section 4.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.19">4.6</a></li>
-                        <li><em>Section 5.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.5">2</a>, <a href="#rfc.xref.Part1.8">3.3.1</a>, <a href="#rfc.xref.Part1.11">3.3.8</a></li>
-                        <li><em>Section 5.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.18">4.6</a></li>
-                        <li><em>Section 5.5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.6">2</a>, <a href="#rfc.xref.Part1.20">4.7</a>, <a href="#rfc.xref.Part1.35">8.1</a>, <a href="#rfc.xref.Part1.36">10.8</a></li>
-                        <li><em>Section 5.7</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.9">3.3.7</a>, <a href="#rfc.xref.Part1.39">10.17</a>, <a href="#rfc.xref.Part1.45">C</a></li>
-                        <li><em>Section 6.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.16">4.5</a></li>
-                        <li><em>Section 6.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.21">5.3.1</a>, <a href="#rfc.xref.Part1.37">10.11</a></li>
-                        <li><em>Section 6.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.22">5.3.2</a>, <a href="#rfc.xref.Part1.25">5.6.15</a></li>
-                        <li><em>Section 7.3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.10">3.3.7</a></li>
+                        <li><em>Section 3.2.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.13">4.5</a>, <a href="#rfc.xref.Part1.50">D</a>, <a href="#rfc.xref.Part1.51">D</a>, <a href="#rfc.xref.Part1.52">D</a>, <a href="#rfc.xref.Part1.54">D</a></li>
+                        <li><em>Section 3.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.23">5.4.6</a>, <a href="#rfc.xref.Part1.32">7.2</a>, <a href="#rfc.xref.Part1.33">8</a>, <a href="#rfc.xref.Part1.40">11.1.1</a></li>
+                        <li><em>Section 3.3.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.31">7.1</a></li>
+                        <li><em>Section 4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.29">6.4.1</a></li>
+                        <li><em>Section 4.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.16">4.5</a></li>
+                        <li><em>Section 4.2.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.26">6.4</a>, <a href="#rfc.xref.Part1.41">11.4</a></li>
+                        <li><em>Section 4.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.30">6.4.1</a></li>
+                        <li><em>Section 4.2.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.27">6.4</a>, <a href="#rfc.xref.Part1.42">11.4</a></li>
+                        <li><em>Section 4.2.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.28">6.4</a>, <a href="#rfc.xref.Part1.43">11.4</a></li>
+                        <li><em>Section 4.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.18">4.6</a></li>
+                        <li><em>Section 5.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.5">2</a>, <a href="#rfc.xref.Part1.7">3.2.1</a>, <a href="#rfc.xref.Part1.10">3.2.8</a></li>
+                        <li><em>Section 5.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.17">4.6</a></li>
+                        <li><em>Section 5.5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.6">2</a>, <a href="#rfc.xref.Part1.19">4.7</a>, <a href="#rfc.xref.Part1.34">8.1</a>, <a href="#rfc.xref.Part1.35">10.8</a></li>
+                        <li><em>Section 5.7</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.8">3.2.7</a>, <a href="#rfc.xref.Part1.38">10.17</a>, <a href="#rfc.xref.Part1.45">C</a></li>
+                        <li><em>Section 6.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.15">4.5</a></li>
+                        <li><em>Section 6.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.20">5.3.1</a>, <a href="#rfc.xref.Part1.36">10.11</a></li>
+                        <li><em>Section 6.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.21">5.3.2</a>, <a href="#rfc.xref.Part1.24">5.6.15</a></li>
+                        <li><em>Section 7.3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.9">3.2.7</a></li>
                         <li><em>Section 9</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.44">13</a></li>
-                        <li><em>Appendix B</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.13">4.5</a></li>
+                        <li><em>Appendix B</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.12">4.5</a></li>
                      </ul>
                   </li>
-                  <li><em>Part4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.1">3.3.2</a>, <a href="#rfc.xref.Part4.2">4.6</a>, <a href="#rfc.xref.Part4.3">4.6</a>, <a href="#rfc.xref.Part4.4">4.6</a>, <a href="#rfc.xref.Part4.5">4.6</a>, <a href="#rfc.xref.Part4.6">4.7</a>, <a href="#rfc.xref.Part4.7">5.1</a>, <a href="#rfc.xref.Part4.8">5.1</a>, <a href="#rfc.xref.Part4.9">5.1</a>, <a href="#rfc.xref.Part4.10">5.4.2</a>, <a href="#rfc.xref.Part4.11">5.5</a>, <a href="#rfc.xref.Part4.12">8.2</a>, <a href="#rfc.xref.Part4.13">8.2</a>, <a href="#Part4"><b>14.1</b></a>, <a href="#rfc.xref.Part4.14">F.2</a><ul>
+                  <li><em>Part4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.1">3.2.2</a>, <a href="#rfc.xref.Part4.2">4.6</a>, <a href="#rfc.xref.Part4.3">4.6</a>, <a href="#rfc.xref.Part4.4">4.6</a>, <a href="#rfc.xref.Part4.5">4.6</a>, <a href="#rfc.xref.Part4.6">4.7</a>, <a href="#rfc.xref.Part4.7">5.1</a>, <a href="#rfc.xref.Part4.8">5.1</a>, <a href="#rfc.xref.Part4.9">5.1</a>, <a href="#rfc.xref.Part4.10">5.4.2</a>, <a href="#rfc.xref.Part4.11">5.5</a>, <a href="#rfc.xref.Part4.12">8.2</a>, <a href="#rfc.xref.Part4.13">8.2</a>, <a href="#Part4"><b>14.1</b></a>, <a href="#rfc.xref.Part4.14">F.2</a><ul>
                         <li><em>Section 2.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.13">8.2</a></li>
                         <li><em>Section 2.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.6">4.7</a>, <a href="#rfc.xref.Part4.10">5.4.2</a>, <a href="#rfc.xref.Part4.12">8.2</a></li>
@@ -5054 +5073 @@
                      </ul>
                   </li>
-                  <li><em>Part5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part5.1">3.3.2</a>, <a href="#rfc.xref.Part5.2">3.3.2</a>, <a href="#rfc.xref.Part5.3">3.3.5</a>, <a href="#rfc.xref.Part5.4">4.6</a>, <a href="#rfc.xref.Part5.5">4.6</a>, <a href="#rfc.xref.Part5.6">4.7</a>, <a href="#rfc.xref.Part5.7">5.1</a>, <a href="#rfc.xref.Part5.8">5.1</a>, <a href="#rfc.xref.Part5.9">5.1</a>, <a href="#rfc.xref.Part5.10">7.1</a>, <a href="#Part5"><b>14.1</b></a><ul>
+                  <li><em>Part5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part5.1">3.2.2</a>, <a href="#rfc.xref.Part5.2">3.2.2</a>, <a href="#rfc.xref.Part5.3">3.2.5</a>, <a href="#rfc.xref.Part5.4">4.6</a>, <a href="#rfc.xref.Part5.5">4.6</a>, <a href="#rfc.xref.Part5.6">4.7</a>, <a href="#rfc.xref.Part5.7">5.1</a>, <a href="#rfc.xref.Part5.8">5.1</a>, <a href="#rfc.xref.Part5.9">5.1</a>, <a href="#rfc.xref.Part5.10">7.1</a>, <a href="#Part5"><b>14.1</b></a><ul>
                         <li><em>Section 3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part5.7">5.1</a></li>
                         <li><em>Section 3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part5.8">5.1</a></li>
                         <li><em>Section 3.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part5.9">5.1</a></li>
                         <li><em>Section 5.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part5.6">4.7</a></li>
-                        <li><em>Section 5.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part5.3">3.3.5</a>, <a href="#rfc.xref.Part5.10">7.1</a></li>
+                        <li><em>Section 5.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part5.3">3.2.5</a>, <a href="#rfc.xref.Part5.10">7.1</a></li>
                         <li><em>Section 5.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part5.4">4.6</a></li>
-                        <li><em>Section 5.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part5.2">3.3.2</a>, <a href="#rfc.xref.Part5.5">4.6</a></li>
+                        <li><em>Section 5.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part5.2">3.2.2</a>, <a href="#rfc.xref.Part5.5">4.6</a></li>
                      </ul>
                   </li>
-                  <li><em>Part6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.1">3.2.1</a>, <a href="#rfc.xref.Part6.2">3.3.2</a>, <a href="#rfc.xref.Part6.3">3.3.3</a>, <a href="#rfc.xref.Part6.4">3.3.4</a>, <a href="#rfc.xref.Part6.5">3.3.5</a>, <a href="#rfc.xref.Part6.6">3.3.6</a>, <a href="#rfc.xref.Part6.7">4.5</a>, <a href="#rfc.xref.Part6.8">4.7</a>, <a href="#rfc.xref.Part6.9">4.7</a>, <a href="#rfc.xref.Part6.10">5.2.1</a>, <a href="#rfc.xref.Part6.11">5.4.1</a>, <a href="#rfc.xref.Part6.12">5.4.4</a>, <a href="#rfc.xref.Part6.13">5.4.4</a>, <a href="#rfc.xref.Part6.14">5.4.4</a>, <a href="#rfc.xref.Part6.15">5.5.1</a>, <a href="#rfc.xref.Part6.16">5.5.2</a>, <a href="#rfc.xref.Part6.17">5.6.9</a>, <a href="#rfc.xref.Part6.18">8.2</a>, <a href="#rfc.xref.Part6.19">9.1</a>, <a href="#Part6"><b>14.1</b></a><ul>
-                        <li><em>Section 4.1.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.4">3.3.4</a></li>
+                  <li><em>Part6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.1">3.1.3</a>, <a href="#rfc.xref.Part6.2">3.2.2</a>, <a href="#rfc.xref.Part6.3">3.2.3</a>, <a href="#rfc.xref.Part6.4">3.2.4</a>, <a href="#rfc.xref.Part6.5">3.2.5</a>, <a href="#rfc.xref.Part6.6">3.2.6</a>, <a href="#rfc.xref.Part6.7">4.5</a>, <a href="#rfc.xref.Part6.8">4.7</a>, <a href="#rfc.xref.Part6.9">4.7</a>, <a href="#rfc.xref.Part6.10">5.2.1</a>, <a href="#rfc.xref.Part6.11">5.4.1</a>, <a href="#rfc.xref.Part6.12">5.4.4</a>, <a href="#rfc.xref.Part6.13">5.4.4</a>, <a href="#rfc.xref.Part6.14">5.4.4</a>, <a href="#rfc.xref.Part6.15">5.5.1</a>, <a href="#rfc.xref.Part6.16">5.5.2</a>, <a href="#rfc.xref.Part6.17">5.6.9</a>, <a href="#rfc.xref.Part6.18">8.2</a>, <a href="#rfc.xref.Part6.19">9.1</a>, <a href="#Part6"><b>14.1</b></a><ul>
+                        <li><em>Section 4.1.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.4">3.2.4</a></li>
                         <li><em>Section 4.1.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.11">5.4.1</a>, <a href="#rfc.xref.Part6.14">5.4.4</a>, <a href="#rfc.xref.Part6.15">5.5.1</a>, <a href="#rfc.xref.Part6.16">5.5.2</a>, <a href="#rfc.xref.Part6.17">5.6.9</a></li>
-                        <li><em>Section 5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.3">3.3.3</a></li>
-                        <li><em>Section 6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.5">3.3.5</a>, <a href="#rfc.xref.Part6.6">3.3.6</a></li>
+                        <li><em>Section 5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.3">3.2.3</a></li>
+                        <li><em>Section 6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.5">3.2.5</a>, <a href="#rfc.xref.Part6.6">3.2.6</a></li>
                         <li><em>Section 7.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.8">4.7</a></li>
                         <li><em>Section 7.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.12">5.4.4</a></li>
@@ -5087 +5106 @@
                   </li>
                   <li>payload&nbsp;&nbsp;<a href="#rfc.iref.p.3">7</a></li>
-                  <li>POST method&nbsp;&nbsp;<a href="#rfc.xref.POST.1">3</a>, <a href="#rfc.iref.p.1"><b>3.3.4</b></a>, <a href="#rfc.xref.POST.2">11.1</a>, <a href="#rfc.xref.POST.3">C</a></li>
-                  <li>PUT method&nbsp;&nbsp;<a href="#rfc.xref.PUT.1">3</a>, <a href="#rfc.iref.p.2"><b>3.3.5</b></a>, <a href="#rfc.xref.PUT.2">11.1</a>, <a href="#rfc.xref.PUT.3">C</a></li>
+                  <li>POST method&nbsp;&nbsp;<a href="#rfc.xref.POST.1">3</a>, <a href="#rfc.iref.p.1"><b>3.2.4</b></a>, <a href="#rfc.xref.POST.2">11.1.2</a>, <a href="#rfc.xref.POST.3">C</a></li>
+                  <li>PUT method&nbsp;&nbsp;<a href="#rfc.xref.PUT.1">3</a>, <a href="#rfc.iref.p.2"><b>3.2.5</b></a>, <a href="#rfc.xref.PUT.2">11.1.2</a>, <a href="#rfc.xref.PUT.3">C</a></li>
                </ul>
             </li>
@@ -5158 +5177 @@
                      </ul>
                   </li>
-                  <li><em>RFC5226</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5226.1">3.2</a>, <a href="#rfc.xref.RFC5226.2">5.2</a>, <a href="#rfc.xref.RFC5226.3">6.4.1</a>, <a href="#RFC5226"><b>14.2</b></a><ul>
-                        <li><em>Section 4.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5226.1">3.2</a>, <a href="#rfc.xref.RFC5226.2">5.2</a>, <a href="#rfc.xref.RFC5226.3">6.4.1</a></li>
+                  <li><em>RFC5226</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5226.1">5.2</a>, <a href="#rfc.xref.RFC5226.2">6.4.1</a>, <a href="#rfc.xref.RFC5226.3">11.1</a>, <a href="#RFC5226"><b>14.2</b></a><ul>
+                        <li><em>Section 4.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5226.1">5.2</a>, <a href="#rfc.xref.RFC5226.2">6.4.1</a>, <a href="#rfc.xref.RFC5226.3">11.1</a></li>
                      </ul>
                   </li>
@@ -5176 +5195 @@
                      </ul>
                   </li>
-                  <li><em>RFC5789</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5789.1">3.3.5</a>, <a href="#RFC5789"><b>14.2</b></a></li>
+                  <li><em>RFC5789</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5789.1">3.2.5</a>, <a href="#RFC5789"><b>14.2</b></a></li>
                   <li><em>RFC5987</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5987.1">4.5</a>, <a href="#RFC5987"><b>14.2</b></a></li>
                   <li><em>RFC6151</em>&nbsp;&nbsp;<a href="#RFC6151"><b>14.2</b></a>, <a href="#rfc.xref.RFC6151.1">C</a></li>
@@ -5183 +5202 @@
             </li>
             <li><a id="rfc.index.S" href="#rfc.index.S"><b>S</b></a><ul>
-                  <li>Safe Methods&nbsp;&nbsp;<a href="#rfc.iref.s.1"><b>3.1.1</b></a></li>
+                  <li>safe&nbsp;&nbsp;<a href="#rfc.iref.s.1"><b>3.1.1</b></a></li>
                   <li>selected representation&nbsp;&nbsp;<a href="#rfc.iref.s.43"><b>8.2</b></a></li>
                   <li>Server header field&nbsp;&nbsp;<a href="#rfc.xref.header.server.1">4.7</a>, <a href="#rfc.iref.s.44"><b>10.17</b></a>, <a href="#rfc.xref.header.server.2">11.3</a>, <a href="#rfc.xref.header.server.3">12.1</a>, <a href="#rfc.xref.header.server.4">C</a></li>
@@ -5238 +5257 @@
             </li>
             <li><a id="rfc.index.T" href="#rfc.index.T"><b>T</b></a><ul>
-                  <li>TRACE method&nbsp;&nbsp;<a href="#rfc.xref.TRACE.1">3</a>, <a href="#rfc.iref.t.1"><b>3.3.7</b></a>, <a href="#rfc.xref.TRACE.2">10.14</a>, <a href="#rfc.xref.TRACE.3">11.1</a>, <a href="#rfc.xref.TRACE.4">12.1</a></li>
+                  <li>TRACE method&nbsp;&nbsp;<a href="#rfc.xref.TRACE.1">3</a>, <a href="#rfc.iref.t.1"><b>3.2.7</b></a>, <a href="#rfc.xref.TRACE.2">10.14</a>, <a href="#rfc.xref.TRACE.3">11.1.2</a>, <a href="#rfc.xref.TRACE.4">12.1</a></li>
                </ul>
             </li>

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

@@ -327 +327 @@
    <ttcol>Sec.</ttcol>
    <c>GET</c>
-   <c>Retrieve a current representation of the target resource.</c>
+   <c>Transfer a current representation of the target resource.</c>
    <c><xref target="GET" format="counter"/></c>
    <c>HEAD</c>
@@ -354 +354 @@
 <t>
    The methods GET and HEAD &MUST; be supported by all general-purpose
-   servers. All other methods are &OPTIONAL;. If one of the above methods is
-   implemented by a server, the server &MUST; implement that method according
-   to the semantics defined for it in <xref target="method.definitions"/>.
-</t>
-<t>
-   Additional methods &MAY; be used in HTTP.  New methods &SHOULD; be
-   registered within the IANA registry, as defined in
+   servers. All other methods are &OPTIONAL;.
+   When implemented, a server &MUST; implement the above methods according
+   to the semantics defined for them in <xref target="method.definitions"/>.
+</t>
+<t>
+   Additional methods &MAY; be used in HTTP; many have already been
+   standardized outside the scope of this specification and registered
+   within the HTTP Method Registry maintained by IANA, as defined in
    <xref target="method.registry"/>.
 </t>
@@ -377 +378 @@
 
 <section title="Safe Methods" anchor="safe.methods">
-<iref item="Safe Methods" primary="true"/>
+<iref item="safe" primary="true"/>
 <t>
    Request methods are considered "<x:dfn anchor="safe">safe</x:dfn>" if
-   their defined semantics are essentially read-only; i.e., the user does
+   their defined semantics are essentially read-only; i.e., the client does
    not request, and does not expect, any state change on the origin server
    as a result of applying a safe method to a target resource.  Likewise,
@@ -389 +390 @@
    This definition of safe methods does not prevent an implementation from
    including behavior that is potentially harmful, not entirely read-only,
-   or which causes side-effects while invoking a safe method.  In fact,
-   some dynamic resources might consider that a feature.  What is
-   important, however, is that the user did not request that additional
+   or which causes side-effects while invoking a safe method.  What is
+   important, however, is that the client did not request that additional
    behavior and cannot be held accountable for it.  For example,
    most servers append request information to access log files at the
    completion of every response, regardless of the method, and that is
    considered safe even though the log storage might become full and crash
-   the server.
+   the server.  Likewise, a safe request initiated by selecting an
+   advertisement on the Web will often have the side-effect of charging an
+   advertising account.
 </t>
 <t>
    The GET, HEAD, OPTIONS, and TRACE request methods are defined to be safe.
+</t>
+<t>
+   The purpose of distinguishing between safe and unsafe methods is to
+   allow automated retrieval processes (spiders) and cache performance
+   optimization (pre-fetching) to work without fear of causing harm.
+   In addition, it allows a user agent to apply appropriate constraints
+   on the automated use of unsafe methods when processing potentially
+   untrusted content.
 </t>
 <t>
@@ -405 +415 @@
    presenting potential actions to a user, such that the user can be made
    aware of an unsafe action before it is requested.
-   A user agent &SHOULD-NOT; make requests using unsafe methods as an
-   automated result of the user selecting a safe action, unless the
-   instruction for making the unsafe request came from the same origin server
-   as the request target.
 </t>
 <t>
@@ -415 +421 @@
    owner's responsibility to ensure that the action is consistent with the
    request method semantics.
-   For example, it is common for HTML form-based content editing software
+   For example, it is common for Web-based content editing software
    to use actions within query parameters, such as "page?do=delete".
    If the purpose of such a resource is to perform an unsafe action, then
@@ -421 +427 @@
    using a safe request method.  Failure to do so will result in
    unfortunate side-effects when automated processes perform a GET on
-   every URI reference, which often occurs for the sake of link maintenance,
-   pre-fetching, or building a search index.
+   every URI reference for the sake of link maintenance, pre-fetching,
+   building a search index, etc.
 </t>
 </section>
 
 <section title="Idempotent Methods" anchor="idempotent.methods">
-<iref item="Idempotent Methods" primary="true"/>
-<t>
-   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.
+<iref item="idempotent" primary="true"/>
+<t>
+   Request methods are considered
+   "<x:dfn anchor="idempotent">idempotent</x:dfn>" if 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.
-</t>
-</section>
-</section>
-
-<section title="Method Registry" anchor="method.registry">
-<t>
-  The HTTP Method Registry defines the name space for the method token in the
-  Request line of an HTTP request.
-</t>
-<t>
-  Registrations &MUST; include the following fields:
-  <list style="symbols">
-    <t>Method Name (see <xref target="methods"/>)</t>
-    <t>Safe ("yes" or "no", see <xref target="safe.methods"/>)</t>
-    <t>Idempotent ("yes" or "no", see <xref target="safe.methods"/>)</t>
-    <t>Pointer to specification text</t>
-  </list>
-</t>
-<t>
-  Values to be added to this name space require IETF Review
-  (see <xref target="RFC5226" x:fmt="," x:sec="4.1"/>).
-</t>
-<t>
-  The registry itself is maintained at <eref target="http://www.iana.org/assignments/http-methods"/>.
-</t>
-
-<section title="Considerations for New Methods" anchor="considerations.for.new.methods">
-<t>
-   When it is necessary to express new semantics for a HTTP request that
-   aren't specific to a single application or media type, and currently defined
-   methods are inadequate, it might be appropriate to register a new method.
-</t>
-<t>
-   HTTP methods are generic; that is, they are potentially applicable to any
-   resource, not just one particular media type, "type" of resource, or
-   application. As such, it is preferred that new HTTP methods be registered
-   in a document that isn't specific to a single application, so that this is
-   clear.
-</t>
-<t>
-   Due to the parsing rules defined in &message-body;, definitions of HTTP
-   methods cannot prohibit the presence of a message body on either the request
-   or the response message (with responses to HEAD requests being the single
-   exception). Definitions of new methods cannot change this rule, but they can
-   specify that only zero-length bodies (as opposed to absent bodies) are allowed.
-</t>
-<t>
-   New method definitions need to indicate whether they are safe (<xref
-   target="safe.methods"/>), what semantics (if any) the request body has,
-   and whether they are idempotent (<xref target="idempotent.methods"/>). 
-   They also need to state whether they can be cached (&caching;); in 
-   particular under what conditions a cache can store the response, and under
-   what conditions such a stored response can be used to satisfy a subsequent 
-   request.
+</t>
+<t>
+   Like the definition of safe, the idempotent property only applies to
+   what has been requested by the user; a server is free to log each request
+   separately, retain a revision control history, or implement other
+   non-idempotent side-effects for each idempotent request.
+</t>
+<t>
+   Idempotent methods are distinguished because the request can be repeated
+   automatically if a communication failure occurs before the client is
+   able to read the server's response.  For example, if a client sends a PUT
+   request and the underlying connection is closed before any response is
+   received, then it can establish a new connection and retry the request
+   because it knows that repeating the request will have the same effect
+   even if the original request succeeded.  Note, however, that repeated
+   failures would indicate a problem within the server.
+</t>
+</section>
+
+<section title="Cacheable Methods" anchor="cacheable.methods">
+<iref item="cacheable" primary="true"/>
+<t>
+   Request methods are considered
+   "<x:dfn anchor="cacheable">cacheable</x:dfn>" if it is possible and useful
+   to answer a current client request with a stored response from a prior
+   request.  GET and HEAD are defined to be cacheable.  In general, safe
+   methods that do not depend on a current or authoritative response are
+   also cacheable, though the overwhelming majority of caches only support
+   GET and HEAD. HTTP requirements for cache behavior and cacheable responses
+   are defined in &caching;.
 </t>
 </section>
@@ -4043 +4021 @@
 <section title="IANA Considerations" anchor="IANA.considerations">
 
-<section title="Method Registry" anchor="method.registration">
-<t>
-  The registration procedure for HTTP request methods is defined by 
-  <xref target="method.registry"/> of this document.
-</t>
+<section title="Method Registry" anchor="method.registry">
+<t>
+  The HTTP Method Registry defines the name space for the method token in the
+  Request line of an HTTP request.
+</t>
+<t>
+  Registrations &MUST; include the following fields:
+  <list style="symbols">
+    <t>Method Name (see <xref target="methods"/>)</t>
+    <t>Safe ("yes" or "no", see <xref target="safe.methods"/>)</t>
+    <t>Idempotent ("yes" or "no", see <xref target="safe.methods"/>)</t>
+    <t>Pointer to specification text</t>
+  </list>
+</t>
+<t>
+  Values to be added to this name space require IETF Review
+  (see <xref target="RFC5226" x:fmt="," x:sec="4.1"/>).
+</t>
+<t>
+  The registry itself is maintained at <eref target="http://www.iana.org/assignments/http-methods"/>.
+</t>
+
+<section title="Considerations for New Methods" anchor="considerations.for.new.methods">
+<t>
+   Standardized HTTP methods are generic; that is, they are potentially
+   applicable to any resource, not just one particular media type, kind of
+   resource, or application. As such, it is preferred that new HTTP methods
+   be registered in a document that isn't specific to a single application or
+   data format, since orthogonal technologies deserve orthogonal specification.
+</t>
+<t>
+   Since HTTP message parsing (&message-body;) is independent of method
+   semantics (aside from responses to HEAD), definitions of new HTTP methods
+   cannot change the parsing algorithm or prohibit the presence of a message
+   body on either the request or the response message.
+   Definitions of new methods can specify that only zero-length bodies are
+   allowed, which would imply that each such messages would be required to
+   contain a Content-Length header field with a value of "0".
+</t>
+<t>
+   New method definitions need to indicate whether they are safe (<xref
+   target="safe.methods"/>), idempotent (<xref target="idempotent.methods"/>),
+   or cacheable (<xref target="cacheable.methods"/>), and what
+   semantics are to be associated with the request body if any is present
+   in the request.  If a method is cacheable, the method definition ought
+   to describe how, and under what conditions, a cache can store a response
+   and use it to satisfy a subsequent request.
+</t>
+</section>
+
+<section title="Registrations" anchor="method.registration">
 <t>
    The HTTP Method Registry shall be created at <eref target="http://www.iana.org/assignments/http-methods"/>
@@ -4110 +4134 @@
 <!--(END)-->
 <?ENDINC p2-semantics.iana-methods ?>
+</section>
 </section>