Changeset 1840


Ignore:
Timestamp:
27/08/12 06:21:21 (9 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:
2 edited

Legend:

Unmodified
Added
Removed

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

    r1839 r1840  
    449449  }
    450450  @bottom-center {
    451        content: "Expires February 26, 2013";
     451       content: "Expires February 27, 2013";
    452452  }
    453453  @bottom-right {
    … …  
    499499      <meta name="dct.creator" content="Reschke, J. F.">
    500500      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p2-semantics-latest">
    501       <meta name="dct.issued" scheme="ISO8601" content="2012-08-25">
     501      <meta name="dct.issued" scheme="ISO8601" content="2012-08-26">
    502502      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    503503      <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.">
    … …  
    530530            </tr>
    531531            <tr>
    532                <td class="left">Expires: February 26, 2013</td>
     532               <td class="left">Expires: February 27, 2013</td>
    533533               <td class="right">greenbytes</td>
    534534            </tr>
    535535            <tr>
    536536               <td class="left"></td>
    537                <td class="right">August 25, 2012</td>
     537               <td class="right">August 26, 2012</td>
    538538            </tr>
    539539         </tbody>
    … …  
    562562         in progress”.
    563563      </p>
    564       <p>This Internet-Draft will expire on February 26, 2013.</p>
     564      <p>This Internet-Draft will expire on February 27, 2013.</p>
    565565      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    566566      <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
    … …  
    590590                     <li><a href="#rfc.section.3.1.1">3.1.1</a>&nbsp;&nbsp;&nbsp;<a href="#safe.methods">Safe Methods</a></li>
    591591                     <li><a href="#rfc.section.3.1.2">3.1.2</a>&nbsp;&nbsp;&nbsp;<a href="#idempotent.methods">Idempotent Methods</a></li>
     592                     <li><a href="#rfc.section.3.1.3">3.1.3</a>&nbsp;&nbsp;&nbsp;<a href="#cacheable.methods">Cacheable Methods</a></li>
    592593                  </ul>
    593594               </li>
    594                <li><a href="#rfc.section.3.2">3.2</a>&nbsp;&nbsp;&nbsp;<a href="#method.registry">Method Registry</a><ul>
    595                      <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>
    596                   </ul>
    597                </li>
    598                <li><a href="#rfc.section.3.3">3.3</a>&nbsp;&nbsp;&nbsp;<a href="#method.definitions">Method Definitions</a><ul>
    599                      <li><a href="#rfc.section.3.3.1">3.3.1</a>&nbsp;&nbsp;&nbsp;<a href="#OPTIONS">OPTIONS</a></li>
    600                      <li><a href="#rfc.section.3.3.2">3.3.2</a>&nbsp;&nbsp;&nbsp;<a href="#GET">GET</a></li>
    601                      <li><a href="#rfc.section.3.3.3">3.3.3</a>&nbsp;&nbsp;&nbsp;<a href="#HEAD">HEAD</a></li>
    602                      <li><a href="#rfc.section.3.3.4">3.3.4</a>&nbsp;&nbsp;&nbsp;<a href="#POST">POST</a></li>
    603                      <li><a href="#rfc.section.3.3.5">3.3.5</a>&nbsp;&nbsp;&nbsp;<a href="#PUT">PUT</a></li>
    604                      <li><a href="#rfc.section.3.3.6">3.3.6</a>&nbsp;&nbsp;&nbsp;<a href="#DELETE">DELETE</a></li>
    605                      <li><a href="#rfc.section.3.3.7">3.3.7</a>&nbsp;&nbsp;&nbsp;<a href="#TRACE">TRACE</a></li>
    606                      <li><a href="#rfc.section.3.3.8">3.3.8</a>&nbsp;&nbsp;&nbsp;<a href="#CONNECT">CONNECT</a></li>
     595               <li><a href="#rfc.section.3.2">3.2</a>&nbsp;&nbsp;&nbsp;<a href="#method.definitions">Method Definitions</a><ul>
     596                     <li><a href="#rfc.section.3.2.1">3.2.1</a>&nbsp;&nbsp;&nbsp;<a href="#OPTIONS">OPTIONS</a></li>
     597                     <li><a href="#rfc.section.3.2.2">3.2.2</a>&nbsp;&nbsp;&nbsp;<a href="#GET">GET</a></li>
     598                     <li><a href="#rfc.section.3.2.3">3.2.3</a>&nbsp;&nbsp;&nbsp;<a href="#HEAD">HEAD</a></li>
     599                     <li><a href="#rfc.section.3.2.4">3.2.4</a>&nbsp;&nbsp;&nbsp;<a href="#POST">POST</a></li>
     600                     <li><a href="#rfc.section.3.2.5">3.2.5</a>&nbsp;&nbsp;&nbsp;<a href="#PUT">PUT</a></li>
     601                     <li><a href="#rfc.section.3.2.6">3.2.6</a>&nbsp;&nbsp;&nbsp;<a href="#DELETE">DELETE</a></li>
     602                     <li><a href="#rfc.section.3.2.7">3.2.7</a>&nbsp;&nbsp;&nbsp;<a href="#TRACE">TRACE</a></li>
     603                     <li><a href="#rfc.section.3.2.8">3.2.8</a>&nbsp;&nbsp;&nbsp;<a href="#CONNECT">CONNECT</a></li>
    607604                  </ul>
    608605               </li>
    … …  
    733730         </li>
    734731         <li><a href="#rfc.section.11">11.</a>&nbsp;&nbsp;&nbsp;<a href="#IANA.considerations">IANA Considerations</a><ul>
    735                <li><a href="#rfc.section.11.1">11.1</a>&nbsp;&nbsp;&nbsp;<a href="#method.registration">Method Registry</a></li>
     732               <li><a href="#rfc.section.11.1">11.1</a>&nbsp;&nbsp;&nbsp;<a href="#method.registry">Method Registry</a><ul>
     733                     <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>
     734                     <li><a href="#rfc.section.11.1.2">11.1.2</a>&nbsp;&nbsp;&nbsp;<a href="#method.registration">Registrations</a></li>
     735                  </ul>
     736               </li>
    736737               <li><a href="#rfc.section.11.2">11.2</a>&nbsp;&nbsp;&nbsp;<a href="#status.code.registration">Status Code Registry</a></li>
    737738               <li><a href="#rfc.section.11.3">11.3</a>&nbsp;&nbsp;&nbsp;<a href="#header.field.registration">Header Field Registration</a></li>
    … …  
    876877                  <td class="left">GET</td>
    877878                  <td class="left">Retrieve a current representation of the target resource.</td>
    878                   <td class="left"><a href="#GET" id="rfc.xref.GET.1" title="GET">3.3.2</a></td>
     879                  <td class="left"><a href="#GET" id="rfc.xref.GET.1" title="GET">3.2.2</a></td>
    879880               </tr>
    880881               <tr>
    881882                  <td class="left">HEAD</td>
    882883                  <td class="left">Same as GET, but do not include a message body in the response.</td>
    883                   <td class="left"><a href="#HEAD" id="rfc.xref.HEAD.1" title="HEAD">3.3.3</a></td>
     884                  <td class="left"><a href="#HEAD" id="rfc.xref.HEAD.1" title="HEAD">3.2.3</a></td>
    884885               </tr>
    885886               <tr>
    886887                  <td class="left">POST</td>
    887888                  <td class="left">Perform resource-specific processing on the request payload.</td>
    888                   <td class="left"><a href="#POST" id="rfc.xref.POST.1" title="POST">3.3.4</a></td>
     889                  <td class="left"><a href="#POST" id="rfc.xref.POST.1" title="POST">3.2.4</a></td>
    889890               </tr>
    890891               <tr>
    891892                  <td class="left">PUT</td>
    892893                  <td class="left">Replace all current representations of the target resource with the request payload.</td>
    893                   <td class="left"><a href="#PUT" id="rfc.xref.PUT.1" title="PUT">3.3.5</a></td>
     894                  <td class="left"><a href="#PUT" id="rfc.xref.PUT.1" title="PUT">3.2.5</a></td>
    894895               </tr>
    895896               <tr>
    896897                  <td class="left">DELETE</td>
    897898                  <td class="left">Remove all current representations of the target resource.</td>
    898                   <td class="left"><a href="#DELETE" id="rfc.xref.DELETE.1" title="DELETE">3.3.6</a></td>
     899                  <td class="left"><a href="#DELETE" id="rfc.xref.DELETE.1" title="DELETE">3.2.6</a></td>
    899900               </tr>
    900901               <tr>
    901902                  <td class="left">CONNECT</td>
    902903                  <td class="left">Establish a tunnel to the server identified by the target resource.</td>
    903                   <td class="left"><a href="#CONNECT" id="rfc.xref.CONNECT.1" title="CONNECT">3.3.8</a></td>
     904                  <td class="left"><a href="#CONNECT" id="rfc.xref.CONNECT.1" title="CONNECT">3.2.8</a></td>
    904905               </tr>
    905906               <tr>
    906907                  <td class="left">OPTIONS</td>
    907908                  <td class="left">Describe the communication options for the target resource.</td>
    908                   <td class="left"><a href="#OPTIONS" id="rfc.xref.OPTIONS.1" title="OPTIONS">3.3.1</a></td>
     909                  <td class="left"><a href="#OPTIONS" id="rfc.xref.OPTIONS.1" title="OPTIONS">3.2.1</a></td>
    909910               </tr>
    910911               <tr>
    911912                  <td class="left">TRACE</td>
    912913                  <td class="left">Perform a message loop-back test along the path to the target resource.</td>
    913                   <td class="left"><a href="#TRACE" id="rfc.xref.TRACE.1" title="TRACE">3.3.7</a></td>
     914                  <td class="left"><a href="#TRACE" id="rfc.xref.TRACE.1" title="TRACE">3.2.7</a></td>
    914915               </tr>
    915916            </tbody>
    916917         </table>
    917918      </div>
    918       <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>.
    919       </p>
    920       <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>.
     919      <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>.
     920      </p>
     921      <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
     922         Method Registry maintained by IANA, as defined in <a href="#method.registry" title="Method Registry">Section&nbsp;11.1</a>.
    921923      </p>
    922924      <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
    … …  
    927929      <div id="rfc.iref.s.1"></div>
    928930      <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>
    929       <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
    930          on the origin server as a result of applying a safe method to a target resource. Likewise, reasonable use of a safe method
    931          is not expected to cause any harm, loss of property, or unusual burden on the origin server.
     931      <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
     932         change on the origin server as a result of applying a safe method to a target resource. Likewise, reasonable use of a safe
     933         method is not expected to cause any harm, loss of property, or unusual burden on the origin server.
    932934      </p>
    933935      <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
    934          entirely read-only, or which causes side-effects while invoking a safe method. In fact, some dynamic resources might consider
    935          that a feature. What is important, however, is that the user did not request that additional behavior and cannot be held accountable
    936          for it. For example, most servers append request information to access log files at the completion of every response, regardless
    937          of the method, and that is considered safe even though the log storage might become full and crash the server.
     936         entirely read-only, or which causes side-effects while invoking a safe method. What is important, however, is that the client
     937         did not request that additional behavior and cannot be held accountable for it. For example, most servers append request information
     938         to access log files at the completion of every response, regardless of the method, and that is considered safe even though
     939         the log storage might become full and crash the server. Likewise, a safe request initiated by selecting an advertisement on
     940         the Web will often have the side-effect of charging an advertising account.
    938941      </p>
    939942      <p id="rfc.section.3.1.1.p.3">The GET, HEAD, OPTIONS, and TRACE request methods are defined to be safe.</p>
    940       <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
    941          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
    942          making the unsafe request came from the same origin server as the request target.
    943       </p>
    944       <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,
     943      <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
     944         performance optimization (pre-fetching) to work without fear of causing harm. In addition, it allows a user agent to apply
     945         appropriate constraints on the automated use of unsafe methods when processing potentially untrusted content.
     946      </p>
     947      <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
     948         of an unsafe action before it is requested.
     949      </p>
     950      <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,
    945951         it is the resource owner's responsibility to ensure that the action is consistent with the request method semantics. For example,
    946          it is common for HTML form-based content editing software to use actions within query parameters, such as "page?do=delete".
    947          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
    948          side-effects when automated processes perform a GET on every URI reference, which often occurs for the sake of link maintenance,
    949          pre-fetching, or building a search index.
     952         it is common for Web-based content editing software to use actions within query parameters, such as "page?do=delete". If the
     953         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
     954         side-effects when automated processes perform a GET on every URI reference for the sake of link maintenance, pre-fetching,
     955         building a search index, etc.
    950956      </p>
    951957      <div id="rfc.iref.i.1"></div>
    952958      <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>
    953       <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
    954          of multiple identical requests is the same as for a single request. PUT, DELETE, and all safe request methods are idempotent.
    955          It is important to note that idempotence refers only to changes requested by the client: a server is free to change its state
    956          due to multiple requests for the purpose of tracking those requests, versioning of results, etc.
    957       </p>
    958       <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>
    959       <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>
    960       <p id="rfc.section.3.2.p.2">Registrations <em class="bcp14">MUST</em> include the following fields:
    961       </p>
    962       <ul>
    963          <li>Method Name (see <a href="#methods" title="Request Methods">Section&nbsp;3</a>)
    964          </li>
    965          <li>Safe ("yes" or "no", see <a href="#safe.methods" title="Safe Methods">Section&nbsp;3.1.1</a>)
    966          </li>
    967          <li>Idempotent ("yes" or "no", see <a href="#safe.methods" title="Safe Methods">Section&nbsp;3.1.1</a>)
    968          </li>
    969          <li>Pointer to specification text</li>
    970       </ul>
    971       <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>).
    972       </p>
    973       <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;.
    974       </p>
    975       <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>
    976       <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,
    977          and currently defined methods are inadequate, it might be appropriate to register a new method.
    978       </p>
    979       <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"
    980          of resource, or application. As such, it is preferred that new HTTP methods be registered in a document that isn't specific
    981          to a single application, so that this is clear.
    982       </p>
    983       <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
    984          (with responses to HEAD requests being the single exception). Definitions of new methods cannot change this rule, but they
    985          can specify that only zero-length bodies (as opposed to absent bodies) are allowed.
    986       </p>
    987       <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
    988          be used to satisfy a subsequent request.
    989       </p>
    990       <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>
    991       <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>
     959      <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
     960         methods are idempotent.
     961      </p>
     962      <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
     963         to log each request separately, retain a revision control history, or implement other non-idempotent side-effects for each
     964         idempotent request.
     965      </p>
     966      <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
     967         the client is able to read the server's response. For example, if a client sends a PUT request and the underlying connection
     968         is closed before any response is received, then it can establish a new connection and retry the request because it knows that
     969         repeating the request will have the same effect even if the original request succeeded. Note, however, that repeated failures
     970         would indicate a problem within the server.
     971      </p>
     972      <div id="rfc.iref.c.2"></div>
     973      <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>
     974      <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
     975         are defined to be cacheable. In general, safe methods that do not depend on a current or authoritative response are also cacheable,
     976         though the overwhelming majority of caches only support GET and HEAD. HTTP requirements for cache behavior and cacheable responses
     977         are defined in <a href="#Part6" id="rfc.xref.Part6.1"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>.
     978      </p>
     979      <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>
     980      <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>
    992981      <div id="rfc.iref.o.1"></div>
    993982      <div id="rfc.iref.m.1"></div>
    994       <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
     983      <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
    995984         by the effective request URI. This method allows a client to determine the options and/or requirements associated with a resource,
    996985         or the capabilities of a server, without implying a resource action or initiating a resource retrieval.
    997986      </p>
    998       <p id="rfc.section.3.3.1.p.2">Responses to the OPTIONS method are not cacheable.</p>
    999       <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
     987      <p id="rfc.section.3.2.1.p.2">Responses to the OPTIONS method are not cacheable.</p>
     988      <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
    1000989         body to make more detailed queries on the server.
    1001990      </p>
    1002       <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.
     991      <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.
    1003992         Since a server's communication options typically depend on the resource, the "*" request is only useful as a "ping" or "no-op"
    1004993         type of method; it does nothing beyond allowing the client to test the capabilities of the server. For example, this can be
    1005994         used to test a proxy for HTTP/1.1 conformance (or lack thereof).
    1006995      </p>
    1007       <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
     996      <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
    1008997         with that resource.
    1009998      </p>
    1010       <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,
     999      <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,
    10111000         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".
    10121001      </p>
    1013       <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.
    1014       </p>
    1015       <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>
     1002      <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.
     1003      </p>
     1004      <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>
    10161005      <div id="rfc.iref.g.2"></div>
    10171006      <div id="rfc.iref.m.2"></div>
    1018       <p id="rfc.section.3.3.2.p.1">The GET method requests transfer of a current representation of the target resource.</p>
    1019       <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
     1007      <p id="rfc.section.3.2.2.p.1">The GET method requests transfer of a current representation of the target resource.</p>
     1008      <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
    10201009         in the response and not the source text of the process, unless that text happens to be the output of the process.
    10211010      </p>
    1022       <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
     1011      <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
    10231012         header field(s). The conditional GET request is intended to reduce unnecessary network usage by allowing cached representations
    10241013         to be refreshed without requiring multiple requests or transferring data already held by the client.
    10251014      </p>
    1026       <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
     1015      <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
    10271016         to be completed without transferring data already held by the client.
    10281017      </p>
    1029       <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
     1018      <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
    10301019         to reject the request.
    10311020      </p>
    1032       <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>).
    1033       </p>
    1034       <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.
    1035       </p>
    1036       <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>
     1021      <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>).
     1022      </p>
     1023      <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.
     1024      </p>
     1025      <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>
    10371026      <div id="rfc.iref.h.1"></div>
    10381027      <div id="rfc.iref.m.3"></div>
    1039       <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
     1028      <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
    10401029         representation implied by the request without transferring the representation body. This method is often used for testing
    10411030         hypertext links for validity, accessibility, and recent modification.
    10421031      </p>
    1043       <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>.
    1044       </p>
    1045       <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
     1032      <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>.
     1033      </p>
     1034      <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
    10461035         to reject the request.
    10471036      </p>
    10481037      <div id="rfc.iref.p.1"></div>
    10491038      <div id="rfc.iref.m.4"></div>
    1050       <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>
    1051       <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
     1039      <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>
     1040      <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
    10521041         by the target resource. POST is designed to allow a uniform method to cover the following functions:
    10531042      </p>
    … …  
    10581047         <li>Extending a database through an append operation.</li>
    10591048      </ul>
    1060       <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
     1049      <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
    10611050         URI.
    10621051      </p>
    1063       <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
     1052      <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
    10641053         the result.
    10651054      </p>
    1066       <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>).
    1067       </p>
    1068       <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.
    1069       </p>
    1070       <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.
    1071       </p>
    1072       <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>
     1055      <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>).
     1056      </p>
     1057      <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.
     1058      </p>
     1059      <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.
     1060      </p>
     1061      <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>
    10731062      <div id="rfc.iref.p.2"></div>
    10741063      <div id="rfc.iref.m.5"></div>
    1075       <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
     1064      <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
    10761065         enclosed in the request message payload. A successful PUT of a given representation would suggest that a subsequent GET on
    10771066         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
    … …  
    10801069         by the origin server.
    10811070      </p>
    1082       <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
     1071      <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
    10831072         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.
    10841073      </p>
    1085       <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).
    1086       </p>
    1087       <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
     1074      <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).
     1075      </p>
     1076      <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
    10881077         or will not be changed by the PUT. This is particularly important when the origin server uses internal configuration information
    10891078         related to the URI in order to set the values for representation metadata on GET responses. When a PUT representation is inconsistent
    … …  
    10911080         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.
    10921081      </p>
    1093       <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:
     1082      <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:
    10941083      </p>
    10951084      <ol class="la">
    … …  
    11021091         </li>
    11031092      </ol>
    1104       <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
     1093      <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
    11051094         of the user agent request and the semantics of the origin server response. It does not define what a resource might be, in
    11061095         any sense of that word, beyond the interface provided via HTTP. It does not define how resource state is "stored", nor how
    … …  
    11091098         the server.
    11101099      </p>
    1111       <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.
     1100      <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.
    11121101         The target resource in a POST request is intended to handle the enclosed representation as a data-accepting process, such
    11131102         as for a gateway to some other protocol or a document that accepts annotations. In contrast, the target resource in a PUT
    … …  
    11151104         and visible to intermediaries, even though the exact effect is only known by the origin server.
    11161105      </p>
    1117       <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
     1106      <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
    11181107         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
    11191108         the target resource and instead wishes to have it applied to a different resource, such as when the resource has been moved
    11201109         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.
    11211110      </p>
    1122       <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)
     1111      <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)
    11231112         which is separate from the URIs identifying each particular version (different resources that at one point shared the same
    11241113         state as the current version resource). A successful PUT request on "the current version" URI might therefore create a new
    … …  
    11261115         the related resources.
    11271116      </p>
    1128       <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
     1117      <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
    11291118         representation). Partial content updates are possible by targeting a separately identified resource with state that overlaps
    11301119         a portion of the larger resource, or by using a different method that has been specifically defined for partial updates (for
    11311120         example, the PATCH method defined in <a href="#RFC5789" id="rfc.xref.RFC5789.1"><cite title="PATCH Method for HTTP">[RFC5789]</cite></a>).
    11321121      </p>
    1133       <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
     1122      <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
    11341123         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>).
    11351124      </p>
    1136       <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>
     1125      <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>
    11371126      <div id="rfc.iref.d.1"></div>
    11381127      <div id="rfc.iref.m.6"></div>
    1139       <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
     1128      <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
    11401129         has been carried out, even if the status code returned from the origin server indicates that the action has been completed
    11411130         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
    11421131         location.
    11431132      </p>
    1144       <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.
    1145       </p>
    1146       <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
     1133      <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.
     1134      </p>
     1135      <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
    11471136         implementations to reject the request.
    11481137      </p>
    1149       <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
     1138      <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
    11501139         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>).
    11511140      </p>
    1152       <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>
     1141      <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>
    11531142      <div id="rfc.iref.t.1"></div>
    11541143      <div id="rfc.iref.m.7"></div>
    1155       <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.
    1156       </p>
    1157       <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
    1158          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
     1144      <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.
     1145      </p>
     1146      <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
     1147         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
    11591148         messages in an infinite loop.
    11601149      </p>
    1161       <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.
    1162       </p>
    1163       <div id="rfc.iref.c.2"></div>
     1150      <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.
     1151      </p>
     1152      <div id="rfc.iref.c.3"></div>
    11641153      <div id="rfc.iref.m.8"></div>
    1165       <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>
    1166       <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
     1154      <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>
     1155      <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
    11671156         its behavior to blind forwarding of packets until the connection is closed.
    11681157      </p>
    1169       <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.
     1158      <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.
    11701159         For example,
    11711160      </p>
    … …  
    11731162Host: server.example.com:80
    11741163
    1175 </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
     1164</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
    11761165         switched to tunneling the current connection to that server connection. The tunneled data from the server begins immediately
    11771166         after the blank line that concludes the successful response's header block.
    11781167      </p>
    1179       <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.
    1180       </p>
    1181       <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
     1168      <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.
     1169      </p>
     1170      <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
    11821171         governed by HTTP.
    11831172      </p>
    1184       <p id="rfc.section.3.3.8.p.7">Proxy authentication might be used to establish the authority to create a tunnel:</p>
     1173      <p id="rfc.section.3.2.8.p.7">Proxy authentication might be used to establish the authority to create a tunnel:</p>
    11851174      <div id="rfc.figure.u.3"></div><pre class="text2">CONNECT server.example.com:80 HTTP/1.1
    11861175Host: server.example.com:80
    11871176Proxy-Authorization: basic aGVsbG86d29ybGQ=
    11881177
    1189 </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
     1178</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
    11901179         to reject the request.
    11911180      </p>
    1192       <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
     1181      <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
    11931182         if the eventual response is negative, and the connection can be reset with no response if more than one TCP segment is outstanding.
    11941183      </p>
    1195       <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,
     1184      <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,
    11961185         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.
    11971186      </p>
    1198       <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
     1187      <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
    11991188         the other one, and after that also the other connection will be terminated by the proxy. If there is outstanding data to that
    12001189         peer undelivered, that data will be discarded.
    12011190      </p>
    1202       <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.
     1191      <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.
    12031192      </p>
    12041193      <h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a>&nbsp;<a id="header.fields" href="#header.fields">Header Fields</a></h1>
    12051194      <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,
    1206          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.
     1195         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.
    12071196      </p>
    12081197      <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>
    … …  
    12161205         with "X-" if they are to be registered (either immediately or in the future).
    12171206      </p>
    1218       <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
     1207      <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
    12191208         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>.
    12201209      </p>
    12211210      <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
    12221211         in the field-value's payload. Typically, components that might contain a comma are protected with double-quotes using the
    1223          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>).
     1212         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>).
    12241213      </p>
    12251214      <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
    … …  
    12391228      <ul>
    12401229         <li>
    1241             <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>).
     1230            <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>).
    12421231            </p>
    12431232            <p>If it does not use the list syntax, document how to treat messages where the header field occurs multiple times (a sensible
    … …  
    12551244         </li>
    12561245         <li>
    1257             <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>).
     1246            <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>).
    12581247            </p>
    12591248         </li>
    … …  
    12661255         </li>
    12671256         <li>
    1268             <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>).
     1257            <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>).
    12691258            </p>
    12701259         </li>
    … …  
    13171306               <tr>
    13181307                  <td class="left">Host</td>
    1319                   <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>
     1308                  <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>
    13201309               </tr>
    13211310               <tr>
    … …  
    13571346               <tr>
    13581347                  <td class="left">TE</td>
    1359                   <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>
     1348                  <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>
    13601349               </tr>
    13611350               <tr>
    … …  
    13681357      <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>
    13691358      <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
    1370          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>).
     1359         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>).
    13711360      </p>
    13721361      <div id="rfc.table.u.2">
    … …  
    16761665      <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>
    16771666      <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>
    1678       <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>).
     1667      <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>).
    16791668      </p>
    16801669      <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;.
    … …  
    16981687      </p>
    16991688      <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>
    1700       <div id="rfc.iref.20"></div>
     1689      <div id="rfc.iref.21"></div>
    17011690      <div id="rfc.iref.s.2"></div>
    17021691      <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,
    … …  
    17111700         a request, then it need not forward the corresponding <a href="#status.100" class="smpl">100 (Continue)</a> response(s).)
    17121701      </p>
    1713       <div id="rfc.iref.21"></div>
     1702      <div id="rfc.iref.22"></div>
    17141703      <div id="rfc.iref.s.3"></div>
    17151704      <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>
    17161705      <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
    17171706         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
    1718          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.
    1719       </p>
    1720       <div id="rfc.iref.22"></div>
     1707         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.
     1708      </p>
     1709      <div id="rfc.iref.23"></div>
    17211710      <div id="rfc.iref.s.4"></div>
    17221711      <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>
    1723       <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
     1712      <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
    17241713         by the response's Upgrade header field immediately after the empty line which terminates the 101 response.
    17251714      </p>
    … …  
    17291718      </p>
    17301719      <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>
    1731       <div id="rfc.iref.23"></div>
     1720      <div id="rfc.iref.24"></div>
    17321721      <div id="rfc.iref.s.5"></div>
    17331722      <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>
    1734       <div id="rfc.iref.24"></div>
     1723      <div id="rfc.iref.25"></div>
    17351724      <div id="rfc.iref.s.6"></div>
    17361725      <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>
    … …  
    17481737      <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.
    17491738      </p>
    1750       <div id="rfc.iref.25"></div>
     1739      <div id="rfc.iref.26"></div>
    17511740      <div id="rfc.iref.s.7"></div>
    17521741      <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>
    … …  
    17611750         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>).
    17621751      </p>
    1763       <div id="rfc.iref.26"></div>
     1752      <div id="rfc.iref.27"></div>
    17641753      <div id="rfc.iref.s.8"></div>
    17651754      <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>
    … …  
    17731762         user can expect the request to be fulfilled.
    17741763      </p>
    1775       <div id="rfc.iref.27"></div>
     1764      <div id="rfc.iref.28"></div>
    17761765      <div id="rfc.iref.s.9"></div>
    17771766      <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>
    1778       <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>).
     1767      <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>).
    17791768      </p>
    17801769      <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
    … …  
    17831772      <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.
    17841773      </p>
    1785       <div id="rfc.iref.28"></div>
     1774      <div id="rfc.iref.29"></div>
    17861775      <div id="rfc.iref.s.10"></div>
    17871776      <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>
    … …  
    18041793      <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.
    18051794      </p>
    1806       <div id="rfc.iref.29"></div>
     1795      <div id="rfc.iref.30"></div>
    18071796      <div id="rfc.iref.s.11"></div>
    18081797      <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>
    … …  
    18111800         another input action.
    18121801      </p>
    1813       <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>.
     1802      <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>.
    18141803      </p>
    18151804      <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>
    1816       <div id="rfc.iref.30"></div>
     1805      <div id="rfc.iref.31"></div>
    18171806      <div id="rfc.iref.s.12"></div>
    18181807      <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.
    … …  
    18601849         </p>
    18611850      </div>
    1862       <div id="rfc.iref.31"></div>
     1851      <div id="rfc.iref.32"></div>
    18631852      <div id="rfc.iref.s.13"></div>
    18641853      <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>
    … …  
    18751864      <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.
    18761865      </p>
    1877       <div id="rfc.iref.32"></div>
     1866      <div id="rfc.iref.33"></div>
    18781867      <div id="rfc.iref.s.14"></div>
    18791868      <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>
    … …  
    18891878         </p>
    18901879      </div>
    1891       <div id="rfc.iref.33"></div>
     1880      <div id="rfc.iref.34"></div>
    18921881      <div id="rfc.iref.s.15"></div>
    18931882      <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>
    … …  
    19001889         </p>
    19011890      </div>
    1902       <div id="rfc.iref.34"></div>
     1891      <div id="rfc.iref.35"></div>
    19031892      <div id="rfc.iref.s.16"></div>
    19041893      <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>
    … …  
    19211910      <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.
    19221911      </p>
    1923       <div id="rfc.iref.35"></div>
     1912      <div id="rfc.iref.36"></div>
    19241913      <div id="rfc.iref.s.17"></div>
    19251914      <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>
    19261915      <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.
    19271916      </p>
    1928       <div id="rfc.iref.36"></div>
     1917      <div id="rfc.iref.37"></div>
    19291918      <div id="rfc.iref.s.18"></div>
    19301919      <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>
    19311920      <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>
    1932       <div id="rfc.iref.37"></div>
     1921      <div id="rfc.iref.38"></div>
    19331922      <div id="rfc.iref.s.19"></div>
    19341923      <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>
    … …  
    19441933      </div>
    19451934      <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>
    1946       <div id="rfc.iref.38"></div>
     1935      <div id="rfc.iref.39"></div>
    19471936      <div id="rfc.iref.s.20"></div>
    19481937      <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
    … …  
    19501939         These status codes are applicable to any request method. User agents <em class="bcp14">SHOULD</em> display any included representation to the user.
    19511940      </p>
    1952       <div id="rfc.iref.39"></div>
     1941      <div id="rfc.iref.40"></div>
    19531942      <div id="rfc.iref.s.21"></div>
    19541943      <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>
    19551944      <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>
    1956       <div id="rfc.iref.40"></div>
     1945      <div id="rfc.iref.41"></div>
    19571946      <div id="rfc.iref.s.22"></div>
    19581947      <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>
    19591948      <p id="rfc.section.5.6.2.p.1">This code is reserved for future use.</p>
    1960       <div id="rfc.iref.41"></div>
     1949      <div id="rfc.iref.42"></div>
    19611950      <div id="rfc.iref.s.23"></div>
    19621951      <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>
    … …  
    19681957            (Not Found)</a>  <em class="bcp14">MAY</em> be used instead.
    19691958      </p>
    1970       <div id="rfc.iref.42"></div>
     1959      <div id="rfc.iref.43"></div>
    19711960      <div id="rfc.iref.s.24"></div>
    19721961      <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>
    … …  
    19761965         has been refused, or when no other response is applicable.
    19771966      </p>
    1978       <div id="rfc.iref.43"></div>
     1967      <div id="rfc.iref.44"></div>
    19791968      <div id="rfc.iref.s.25"></div>
    19801969      <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>
    19811970      <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.
    19821971      </p>
    1983       <div id="rfc.iref.44"></div>
     1972      <div id="rfc.iref.45"></div>
    19841973      <div id="rfc.iref.s.26"></div>
    19851974      <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>
    … …  
    19991988      <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.
    20001989      </p>
    2001       <div id="rfc.iref.45"></div>
     1990      <div id="rfc.iref.46"></div>
    20021991      <div id="rfc.iref.s.27"></div>
    20031992      <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>
    20041993      <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.
    20051994      </p>
    2006       <div id="rfc.iref.46"></div>
     1995      <div id="rfc.iref.47"></div>
    20071996      <div id="rfc.iref.s.28"></div>
    20081997      <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>
    … …  
    20172006         contain a list of the differences between the two versions.
    20182007      </p>
    2019       <div id="rfc.iref.47"></div>
     2008      <div id="rfc.iref.48"></div>
    20202009      <div id="rfc.iref.s.29"></div>
    20212010      <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>
    … …  
    20322021      <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.
    20332022      </p>
    2034       <div id="rfc.iref.48"></div>
     2023      <div id="rfc.iref.49"></div>
    20352024      <div id="rfc.iref.s.30"></div>
    20362025      <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>
    … …  
    20382027         message.
    20392028      </p>
    2040       <div id="rfc.iref.49"></div>
     2029      <div id="rfc.iref.50"></div>
    20412030      <div id="rfc.iref.s.31"></div>
    20422031      <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>
    … …  
    20462035      <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.
    20472036      </p>
    2048       <div id="rfc.iref.50"></div>
     2037      <div id="rfc.iref.51"></div>
    20492038      <div id="rfc.iref.s.32"></div>
    20502039      <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>
    … …  
    20552044         in some servers using fixed-length buffers for reading or manipulating the request-target.
    20562045      </p>
    2057       <div id="rfc.iref.51"></div>
     2046      <div id="rfc.iref.52"></div>
    20582047      <div id="rfc.iref.s.33"></div>
    20592048      <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>
    … …  
    20612050         on the target resource.
    20622051      </p>
    2063       <div id="rfc.iref.52"></div>
     2052      <div id="rfc.iref.53"></div>
    20642053      <div id="rfc.iref.s.34"></div>
    20652054      <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>
    … …  
    20672056         not be met by the next-hop server.
    20682057      </p>
    2069       <div id="rfc.iref.53"></div>
     2058      <div id="rfc.iref.54"></div>
    20702059      <div id="rfc.iref.s.35"></div>
    20712060      <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>
    2072       <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.
     2061      <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.
    20732062      </p>
    20742063      <div id="rfc.figure.u.5"></div>
    … …  
    20842073      </p>
    20852074      <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>
    2086       <div id="rfc.iref.54"></div>
     2075      <div id="rfc.iref.55"></div>
    20872076      <div id="rfc.iref.s.36"></div>
    20882077      <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
    … …  
    20902079         User agents <em class="bcp14">SHOULD</em> display any included representation to the user. These response codes are applicable to any request method.
    20912080      </p>
    2092       <div id="rfc.iref.55"></div>
     2081      <div id="rfc.iref.56"></div>
    20932082      <div id="rfc.iref.s.37"></div>
    20942083      <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>
    20952084      <p id="rfc.section.5.7.1.p.1">The server encountered an unexpected condition which prevented it from fulfilling the request.</p>
    2096       <div id="rfc.iref.56"></div>
     2085      <div id="rfc.iref.57"></div>
    20972086      <div id="rfc.iref.s.38"></div>
    20982087      <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>
    … …  
    21002089         does not recognize the request method and is not capable of supporting it for any resource.
    21012090      </p>
    2102       <div id="rfc.iref.57"></div>
     2091      <div id="rfc.iref.58"></div>
    21032092      <div id="rfc.iref.s.39"></div>
    21042093      <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>
    … …  
    21062095         to fulfill the request.
    21072096      </p>
    2108       <div id="rfc.iref.58"></div>
     2097      <div id="rfc.iref.59"></div>
    21092098      <div id="rfc.iref.s.40"></div>
    21102099      <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>
    … …  
    21192108         </p>
    21202109      </div>
    2121       <div id="rfc.iref.59"></div>
     2110      <div id="rfc.iref.60"></div>
    21222111      <div id="rfc.iref.s.41"></div>
    21232112      <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>
    … …  
    21302119         </p>
    21312120      </div>
    2132       <div id="rfc.iref.60"></div>
     2121      <div id="rfc.iref.61"></div>
    21332122      <div id="rfc.iref.s.42"></div>
    21342123      <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>
    21352124      <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
    21362125         is indicating that it is unable or unwilling to complete the request using the same major version as the client, as described
    2137          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.
     2126         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.
    21382127      </p>
    21392128      <h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a>&nbsp;<a id="protocol.parameters" href="#protocol.parameters">Protocol Parameters</a></h1>
    … …  
    22612250         mechanism will be required to remove the encoding.
    22622251      </p>
    2263       <p id="rfc.section.6.4.p.4">compress<span id="rfc.iref.c.3"></span><span id="rfc.iref.c.4"></span> 
     2252      <p id="rfc.section.6.4.p.4">compress<span id="rfc.iref.c.4"></span><span id="rfc.iref.c.5"></span> 
    22642253      </p>
    22652254      <ul class="empty">
    2266          <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>.
    2267          </li>
    2268       </ul>
    2269       <p id="rfc.section.6.4.p.5">deflate<span id="rfc.iref.d.2"></span><span id="rfc.iref.c.5"></span> 
     2255         <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>.
     2256         </li>
     2257      </ul>
     2258      <p id="rfc.section.6.4.p.5">deflate<span id="rfc.iref.d.2"></span><span id="rfc.iref.c.6"></span> 
    22702259      </p>
    22712260      <ul class="empty">
    2272          <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>.
    2273          </li>
    2274       </ul>
    2275       <p id="rfc.section.6.4.p.6">gzip<span id="rfc.iref.g.23"></span><span id="rfc.iref.c.6"></span> 
     2261         <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>.
     2262         </li>
     2263      </ul>
     2264      <p id="rfc.section.6.4.p.6">gzip<span id="rfc.iref.g.23"></span><span id="rfc.iref.c.7"></span> 
    22762265      </p>
    22772266      <ul class="empty">
    2278          <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>.
     2267         <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>.
    22792268         </li>
    22802269      </ul>
    … …  
    22882277         <li>Pointer to specification text</li>
    22892278      </ul>
    2290       <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>).
    2291       </p>
    2292       <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.
     2279      <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>).
     2280      </p>
     2281      <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.
    22932282      </p>
    22942283      <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;.
    … …  
    23872376               <tr>
    23882377                  <td class="left">Content-Length</td>
    2389                   <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>
     2378                  <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>
    23902379               </tr>
    23912380               <tr>
    … …  
    23972386      </div>
    23982387      <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>
    2399       <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.
     2388      <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.
    24002389      </p>
    24012390      <div id="rfc.iref.r.1"></div>
    … …  
    24162405         in an HTTP message, it is referred to as the payload of the message.
    24172406      </p>
    2418       <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.
     2407      <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.
    24192408      </p>
    24202409      <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>
    24212410      <p id="rfc.section.8.1.p.1">It is sometimes necessary to determine an identifier for the resource associated with a representation.</p>
    24222411      <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>
    2423       <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
     2412      <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
    24242413         rules are used (with the first applicable one being selected):
    24252414      </p>
    … …  
    28352824         to the generic message handling rules.
    28362825      </p>
    2837       <div id="rfc.iref.c.7"></div>
     2826      <div id="rfc.iref.c.8"></div>
    28382827      <div id="rfc.iref.h.7"></div>
    28392828      <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>
    … …  
    28632852      <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).
    28642853      </p>
    2865       <div id="rfc.iref.c.8"></div>
     2854      <div id="rfc.iref.c.9"></div>
    28662855      <div id="rfc.iref.h.8"></div>
    28672856      <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>
    … …  
    28892878      <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.
    28902879      </p>
    2891       <div id="rfc.iref.c.9"></div>
     2880      <div id="rfc.iref.c.10"></div>
    28922881      <div id="rfc.iref.h.9"></div>
    28932882      <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>
    … …  
    28962885      </p>
    28972886      <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>
    2898 </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
     2887</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
    28992888         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.
    29002889      </p>
    … …  
    29292918      </p>
    29302919      <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>
    2931       <div id="rfc.iref.c.10"></div>
     2920      <div id="rfc.iref.c.11"></div>
    29322921      <div id="rfc.iref.h.10"></div>
    29332922      <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>
    … …  
    29872976      </p>
    29882977      <p id="rfc.section.10.11.p.4">The only expectation defined by this specification is:</p>
    2989       <p id="rfc.section.10.11.p.5"><span id="rfc.iref.141"></span><span id="rfc.iref.e.2"></span> 100-continue
     2978      <p id="rfc.section.10.11.p.5"><span id="rfc.iref.142"></span><span id="rfc.iref.e.2"></span> 100-continue
    29902979      </p>
    29912980      <ul class="empty">
    2992          <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.
     2981         <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.
    29932982         </li>
    29942983      </ul>
    … …  
    30533042      <div id="rfc.iref.h.15"></div>
    30543043      <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>
    3055       <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
     3044      <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
    30563045         to trace a request which appears to be failing or looping mid-chain.
    30573046      </p>
    … …  
    31013090      <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>
    31023091      <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>
    3103       <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
     3092      <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
    31043093         identifying the application.
    31053094      </p>
    … …  
    31073096</pre><p id="rfc.section.10.17.p.4">Example:</p>
    31083097      <div id="rfc.figure.u.59"></div><pre class="text">  Server: CERN/3.0 libwww/2.17
    3109 </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>).
     3098</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>).
    31103099      </p>
    31113100      <div class="note" id="rfc.section.10.17.p.7">
    … …  
    31233112         user agent limitations.
    31243113      </p>
    3125       <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
     3114      <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
    31263115         for identifying the application.
    31273116      </p>
    … …  
    31383127      <div id="rfc.figure.u.61"></div><pre class="text">  User-Agent: CERN-LineMode/2.15 libwww/2.17b3
    31393128</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>
    3140       <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>
    3141       <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.
    3142       </p>
    3143       <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:
     3129      <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>
     3130      <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>
     3131      <p id="rfc.section.11.1.p.2">Registrations <em class="bcp14">MUST</em> include the following fields:
     3132      </p>
     3133      <ul>
     3134         <li>Method Name (see <a href="#methods" title="Request Methods">Section&nbsp;3</a>)
     3135         </li>
     3136         <li>Safe ("yes" or "no", see <a href="#safe.methods" title="Safe Methods">Section&nbsp;3.1.1</a>)
     3137         </li>
     3138         <li>Idempotent ("yes" or "no", see <a href="#safe.methods" title="Safe Methods">Section&nbsp;3.1.1</a>)
     3139         </li>
     3140         <li>Pointer to specification text</li>
     3141      </ul>
     3142      <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>).
     3143      </p>
     3144      <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;.
     3145      </p>
     3146      <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>
     3147      <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
     3148         type, kind of resource, or application. As such, it is preferred that new HTTP methods be registered in a document that isn't
     3149         specific to a single application or data format, since orthogonal technologies deserve orthogonal specification.
     3150      </p>
     3151      <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
     3152         algorithm or prohibit the presence of a message body on either the request or the response message. Definitions of new methods
     3153         can specify that only zero-length bodies are allowed, which would imply that each such messages would be required to contain
     3154         a Content-Length header field with a value of "0".
     3155      </p>
     3156      <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,
     3157         the method definition ought to describe how, and under what conditions, a cache can store a response and use it to satisfy
     3158         a subsequent request.
     3159      </p>
     3160      <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>
     3161      <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:
    31443162      </p>
    31453163      <div id="rfc.table.2">
    … …  
    31593177                  <td class="left">no</td>
    31603178                  <td class="left">no</td>
    3161                   <td class="left"> <a href="#CONNECT" id="rfc.xref.CONNECT.2" title="CONNECT">Section&nbsp;3.3.8</a>
     3179                  <td class="left"> <a href="#CONNECT" id="rfc.xref.CONNECT.2" title="CONNECT">Section&nbsp;3.2.8</a>
    31623180                  </td>
    31633181               </tr>
    … …  
    31663184                  <td class="left">no</td>
    31673185                  <td class="left">yes</td>
    3168                   <td class="left"> <a href="#DELETE" id="rfc.xref.DELETE.2" title="DELETE">Section&nbsp;3.3.6</a>
     3186                  <td class="left"> <a href="#DELETE" id="rfc.xref.DELETE.2" title="DELETE">Section&nbsp;3.2.6</a>
    31693187                  </td>
    31703188               </tr>
    … …  
    31733191                  <td class="left">yes</td>
    31743192                  <td class="left">yes</td>
    3175                   <td class="left"> <a href="#GET" id="rfc.xref.GET.2" title="GET">Section&nbsp;3.3.2</a>
     3193                  <td class="left"> <a href="#GET" id="rfc.xref.GET.2" title="GET">Section&nbsp;3.2.2</a>
    31763194                  </td>
    31773195               </tr>
    … …  
    31803198                  <td class="left">yes</td>
    31813199                  <td class="left">yes</td>
    3182                   <td class="left"> <a href="#HEAD" id="rfc.xref.HEAD.2" title="HEAD">Section&nbsp;3.3.3</a>
     3200                  <td class="left"> <a href="#HEAD" id="rfc.xref.HEAD.2" title="HEAD">Section&nbsp;3.2.3</a>
    31833201                  </td>
    31843202               </tr>
    … …  
    31873205                  <td class="left">yes</td>
    31883206                  <td class="left">yes</td>
    3189                   <td class="left"> <a href="#OPTIONS" id="rfc.xref.OPTIONS.3" title="OPTIONS">Section&nbsp;3.3.1</a>
     3207                  <td class="left"> <a href="#OPTIONS" id="rfc.xref.OPTIONS.3" title="OPTIONS">Section&nbsp;3.2.1</a>
    31903208                  </td>
    31913209               </tr>
    … …  
    31943212                  <td class="left">no</td>
    31953213                  <td class="left">no</td>
    3196                   <td class="left"> <a href="#POST" id="rfc.xref.POST.2" title="POST">Section&nbsp;3.3.4</a>
     3214                  <td class="left"> <a href="#POST" id="rfc.xref.POST.2" title="POST">Section&nbsp;3.2.4</a>
    31973215                  </td>
    31983216               </tr>
    … …  
    32013219                  <td class="left">no</td>
    32023220                  <td class="left">yes</td>
    3203                   <td class="left"> <a href="#PUT" id="rfc.xref.PUT.2" title="PUT">Section&nbsp;3.3.5</a>
     3221                  <td class="left"> <a href="#PUT" id="rfc.xref.PUT.2" title="PUT">Section&nbsp;3.2.5</a>
    32043222                  </td>
    32053223               </tr>
    … …  
    32083226                  <td class="left">yes</td>
    32093227                  <td class="left">yes</td>
    3210                   <td class="left"> <a href="#TRACE" id="rfc.xref.TRACE.3" title="TRACE">Section&nbsp;3.3.7</a>
     3228                  <td class="left"> <a href="#TRACE" id="rfc.xref.TRACE.3" title="TRACE">Section&nbsp;3.2.7</a>
    32113229                  </td>
    32123230               </tr>
    … …  
    36793697         user.
    36803698      </p>
    3681       <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
     3699      <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
    36823700         to collect data from the client.
    36833701      </p>
    … …  
    39753993         However, this parameter is not part of the MIME standards).
    39763994      </p>
    3977       <div id="rfc.iref.c.11"></div>
     3995      <div id="rfc.iref.c.12"></div>
    39783996      <div id="rfc.iref.h.21"></div>
    39793997      <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>
    … …  
    39994017      </p>
    40004018      <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>
    4001       <p id="rfc.section.C.p.1">Introduce Method Registry. (<a href="#method.registry" title="Method Registry">Section&nbsp;3.2</a>)
    4002       </p>
    4003       <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>)
    4004       </p>
    4005       <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>)
    4006       </p>
    4007       <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>)
     4019      <p id="rfc.section.C.p.1">Introduce Method Registry. (<a href="#method.registry" title="Method Registry">Section&nbsp;11.1</a>)
     4020      </p>
     4021      <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>)
     4022      </p>
     4023      <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>)
     4024      </p>
     4025      <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>)
    40084026      </p>
    40094027      <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>)
    … …  
    47844802         <ul class="ind">
    47854803            <li><a id="rfc.index.1" href="#rfc.index.1"><b>1</b></a><ul>
    4786                   <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>
    4787                   <li>100-continue (expect value)&nbsp;&nbsp;<a href="#rfc.iref.141"><b>10.11</b></a></li>
    4788                   <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>
    4789                   <li>1xx Informational (status code class)&nbsp;&nbsp;<a href="#rfc.iref.20"><b>5.3</b></a></li>
     4804                  <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>
     4805                  <li>100-continue (expect value)&nbsp;&nbsp;<a href="#rfc.iref.142"><b>10.11</b></a></li>
     4806                  <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>
     4807                  <li>1xx Informational (status code class)&nbsp;&nbsp;<a href="#rfc.iref.21"><b>5.3</b></a></li>
    47904808               </ul>
    47914809            </li>
    47924810            <li><a id="rfc.index.2" href="#rfc.index.2"><b>2</b></a><ul>
    4793                   <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>
    4794                   <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>
    4795                   <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>
    4796                   <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>
    4797                   <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>
    4798                   <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>
    4799                   <li>2xx Successful (status code class)&nbsp;&nbsp;<a href="#rfc.iref.23"><b>5.4</b></a></li>
     4811                  <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>
     4812                  <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>
     4813                  <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>
     4814                  <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>
     4815                  <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>
     4816                  <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>
     4817                  <li>2xx Successful (status code class)&nbsp;&nbsp;<a href="#rfc.iref.24"><b>5.4</b></a></li>
    48004818               </ul>
    48014819            </li>
    48024820            <li><a id="rfc.index.3" href="#rfc.index.3"><b>3</b></a><ul>
    4803                   <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>
    4804                   <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>
    4805                   <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>
    4806                   <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>
    4807                   <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>
    4808                   <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>
    4809                   <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>
    4810                   <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>
     4821                  <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>
     4822                  <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>
     4823                  <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>
     4824                  <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>
     4825                  <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>
     4826                  <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>
     4827                  <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>
     4828                  <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>
    48114829               </ul>
    48124830            </li>
    48134831            <li><a id="rfc.index.4" href="#rfc.index.4"><b>4</b></a><ul>
    4814                   <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>
    4815                   <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>
    4816                   <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>
    4817                   <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>
    4818                   <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>
    4819                   <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>
    4820                   <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>
    4821                   <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>
    4822                   <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>
    4823                   <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>
    4824                   <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>
    4825                   <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>
    4826                   <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>
    4827                   <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>
    4828                   <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>
    4829                   <li>4xx Client Error (status code class)&nbsp;&nbsp;<a href="#rfc.iref.38"><b>5.6</b></a></li>
     4832                  <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>
     4833                  <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>
     4834                  <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>
     4835                  <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>
     4836                  <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>
     4837                  <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>
     4838                  <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>
     4839                  <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>
     4840                  <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>
     4841                  <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>
     4842                  <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>
     4843                  <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>
     4844                  <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>
     4845                  <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>
     4846                  <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>
     4847                  <li>4xx Client Error (status code class)&nbsp;&nbsp;<a href="#rfc.iref.39"><b>5.6</b></a></li>
    48304848               </ul>
    48314849            </li>
    48324850            <li><a id="rfc.index.5" href="#rfc.index.5"><b>5</b></a><ul>
    4833                   <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>
    4834                   <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>
    4835                   <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>
    4836                   <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>
    4837                   <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>
    4838                   <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>
    4839                   <li>5xx Server Error (status code class)&nbsp;&nbsp;<a href="#rfc.iref.54"><b>5.7</b></a></li>
     4851                  <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>
     4852                  <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>
     4853                  <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>
     4854                  <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>
     4855                  <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>
     4856                  <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>
     4857                  <li>5xx Server Error (status code class)&nbsp;&nbsp;<a href="#rfc.iref.55"><b>5.7</b></a></li>
    48404858               </ul>
    48414859            </li>
    … …  
    48494867            </li>
    48504868            <li><a id="rfc.index.C" href="#rfc.index.C"><b>C</b></a><ul>
     4869                  <li>cacheable&nbsp;&nbsp;<a href="#rfc.iref.c.2"><b>3.1.3</b></a></li>
    48514870                  <li>Coding Format&nbsp;&nbsp;
    48524871                     <ul>
    4853                         <li>compress&nbsp;&nbsp;<a href="#rfc.iref.c.4">6.4</a></li>
    4854                         <li>deflate&nbsp;&nbsp;<a href="#rfc.iref.c.5">6.4</a></li>
    4855                         <li>gzip&nbsp;&nbsp;<a href="#rfc.iref.c.6">6.4</a></li>
     4872                        <li>compress&nbsp;&nbsp;<a href="#rfc.iref.c.5">6.4</a></li>
     4873                        <li>deflate&nbsp;&nbsp;<a href="#rfc.iref.c.6">6.4</a></li>
     4874                        <li>gzip&nbsp;&nbsp;<a href="#rfc.iref.c.7">6.4</a></li>
    48564875                     </ul>
    48574876                  </li>
    4858                   <li>compress (Coding Format)&nbsp;&nbsp;<a href="#rfc.iref.c.3">6.4</a></li>
    4859                   <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>
     4877                  <li>compress (Coding Format)&nbsp;&nbsp;<a href="#rfc.iref.c.4">6.4</a></li>
     4878                  <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>
    48604879                  <li>content negotiation&nbsp;&nbsp;<a href="#rfc.iref.c.1">1</a></li>
    4861                   <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>
    4862                   <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>
    4863                   <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>
    4864                   <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>
    4865                   <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>
     4880                  <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>
     4881                  <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>
     4882                  <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>
     4883                  <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>
     4884                  <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>
    48664885               </ul>
    48674886            </li>
    … …  
    48694888                  <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>
    48704889                  <li>deflate (Coding Format)&nbsp;&nbsp;<a href="#rfc.iref.d.2">6.4</a></li>
    4871                   <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>
     4890                  <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>
    48724891                  <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>
    48734892               </ul>
    … …  
    48874906            </li>
    48884907            <li><a id="rfc.index.G" href="#rfc.index.G"><b>G</b></a><ul>
    4889                   <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>
     4908                  <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>
    48904909                  <li><tt>Grammar</tt>&nbsp;&nbsp;
    48914910                     <ul>
    … …  
    49554974            </li>
    49564975            <li><a id="rfc.index.H" href="#rfc.index.H"><b>H</b></a><ul>
    4957                   <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>
     4976                  <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>
    49584977                  <li>Header Fields&nbsp;&nbsp;
    49594978                     <ul>
    … …  
    49654984                        <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>
    49664985                        <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>
    4967                         <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>
     4986                        <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>
    49684987                        <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>
    49694988                        <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>
    … …  
    49714990                        <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>
    49724991                        <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>
    4973                         <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>
    4974                         <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>
     4992                        <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>
     4993                        <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>
    49754994                        <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>
    49764995                        <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>
    … …  
    49835002            </li>
    49845003            <li><a id="rfc.index.I" href="#rfc.index.I"><b>I</b></a><ul>
    4985                   <li>Idempotent Methods&nbsp;&nbsp;<a href="#rfc.iref.i.1"><b>3.1.2</b></a></li>
     5004                  <li>idempotent&nbsp;&nbsp;<a href="#rfc.iref.i.1"><b>3.1.2</b></a></li>
    49865005               </ul>
    49875006            </li>
    49885007            <li><a id="rfc.index.L" href="#rfc.index.L"><b>L</b></a><ul>
    4989                   <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>
     5008                  <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>
    49905009               </ul>
    49915010            </li>
    49925011            <li><a id="rfc.index.M" href="#rfc.index.M"><b>M</b></a><ul>
    4993                   <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>
     5012                  <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>
    49945013                  <li>Methods&nbsp;&nbsp;
    49955014                     <ul>
    4996                         <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>
    4997                         <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>
    4998                         <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>
    4999                         <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>
    5000                         <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>
    5001                         <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>
    5002                         <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>
    5003                         <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>
     5015                        <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>
     5016                        <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>
     5017                        <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>
     5018                        <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>
     5019                        <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>
     5020                        <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>
     5021                        <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>
     5022                        <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>
    50045023                     </ul>
    50055024                  </li>
    … …  
    50085027            </li>
    50095028            <li><a id="rfc.index.O" href="#rfc.index.O"><b>O</b></a><ul>
    5010                   <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>
     5029                  <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>
    50115030               </ul>
    50125031            </li>
    50135032            <li><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul>
    5014                   <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>
     5033                  <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>
    50155034                        <li><em>Section 1.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.3">1.2</a></li>
    5016                         <li><em>Section 2.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.23">5.4.4</a></li>
     5035                        <li><em>Section 2.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.22">5.4.4</a></li>
    50175036                        <li><em>Section 2.5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.2">1.1</a></li>
    5018                         <li><em>Section 2.6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.26">5.7.6</a></li>
     5037                        <li><em>Section 2.6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.25">5.7.6</a></li>
    50195038                        <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>
    5020                         <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>
     5039                        <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>
    50215040                        <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>
    5022                         <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>
    5023                         <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>
    5024                         <li><em>Section 3.3.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.32">7.1</a></li>
    5025                         <li><em>Section 4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.30">6.4.1</a></li>
    5026                         <li><em>Section 4.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.17">4.5</a></li>
    5027                         <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>
    5028                         <li><em>Section 4.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.31">6.4.1</a></li>
    5029                         <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>
    5030                         <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>
    5031                         <li><em>Section 4.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.19">4.6</a></li>
    5032                         <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>
    5033                         <li><em>Section 5.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.18">4.6</a></li>
    5034                         <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>
    5035                         <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>
    5036                         <li><em>Section 6.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.16">4.5</a></li>
    5037                         <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>
    5038                         <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>
    5039                         <li><em>Section 7.3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.10">3.3.7</a></li>
     5041                        <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>
     5042                        <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>
     5043                        <li><em>Section 3.3.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.31">7.1</a></li>
     5044                        <li><em>Section 4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.29">6.4.1</a></li>
     5045                        <li><em>Section 4.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.16">4.5</a></li>
     5046                        <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>
     5047                        <li><em>Section 4.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.30">6.4.1</a></li>
     5048                        <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>
     5049                        <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>
     5050                        <li><em>Section 4.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.18">4.6</a></li>
     5051                        <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>
     5052                        <li><em>Section 5.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.17">4.6</a></li>
     5053                        <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>
     5054                        <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>
     5055                        <li><em>Section 6.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.15">4.5</a></li>
     5056                        <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>
     5057                        <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>
     5058                        <li><em>Section 7.3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.9">3.2.7</a></li>
    50405059                        <li><em>Section 9</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.44">13</a></li>
    5041                         <li><em>Appendix B</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.13">4.5</a></li>
     5060                        <li><em>Appendix B</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.12">4.5</a></li>
    50425061                     </ul>
    50435062                  </li>
    5044                   <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>
     5063                  <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>
    50455064                        <li><em>Section 2.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.13">8.2</a></li>
    50465065                        <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>
    … …  
    50545073                     </ul>
    50555074                  </li>
    5056                   <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>
     5075                  <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>
    50575076                        <li><em>Section 3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part5.7">5.1</a></li>
    50585077                        <li><em>Section 3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part5.8">5.1</a></li>
    50595078                        <li><em>Section 3.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part5.9">5.1</a></li>
    50605079                        <li><em>Section 5.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part5.6">4.7</a></li>
    5061                         <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>
     5080                        <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>
    50625081                        <li><em>Section 5.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part5.4">4.6</a></li>
    5063                         <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>
     5082                        <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>
    50645083                     </ul>
    50655084                  </li>
    5066                   <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>
    5067                         <li><em>Section 4.1.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.4">3.3.4</a></li>
     5085                  <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>
     5086                        <li><em>Section 4.1.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.4">3.2.4</a></li>
    50685087                        <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>
    5069                         <li><em>Section 5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.3">3.3.3</a></li>
    5070                         <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>
     5088                        <li><em>Section 5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.3">3.2.3</a></li>
     5089                        <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>
    50715090                        <li><em>Section 7.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.8">4.7</a></li>
    50725091                        <li><em>Section 7.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.12">5.4.4</a></li>
    … …  
    50875106                  </li>
    50885107                  <li>payload&nbsp;&nbsp;<a href="#rfc.iref.p.3">7</a></li>
    5089                   <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>
    5090                   <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>
     5108                  <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>
     5109                  <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>
    50915110               </ul>
    50925111            </li>
    … …  
    51585177                     </ul>
    51595178                  </li>
    5160                   <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>
    5161                         <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>
     5179                  <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>
     5180                        <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>
    51625181                     </ul>
    51635182                  </li>
    … …  
    51765195                     </ul>
    51775196                  </li>
    5178                   <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>
     5197                  <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>
    51795198                  <li><em>RFC5987</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5987.1">4.5</a>, <a href="#RFC5987"><b>14.2</b></a></li>
    51805199                  <li><em>RFC6151</em>&nbsp;&nbsp;<a href="#RFC6151"><b>14.2</b></a>, <a href="#rfc.xref.RFC6151.1">C</a></li>
    … …  
    51835202            </li>
    51845203            <li><a id="rfc.index.S" href="#rfc.index.S"><b>S</b></a><ul>
    5185                   <li>Safe Methods&nbsp;&nbsp;<a href="#rfc.iref.s.1"><b>3.1.1</b></a></li>
     5204                  <li>safe&nbsp;&nbsp;<a href="#rfc.iref.s.1"><b>3.1.1</b></a></li>
    51865205                  <li>selected representation&nbsp;&nbsp;<a href="#rfc.iref.s.43"><b>8.2</b></a></li>
    51875206                  <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>
    … …  
    52385257            </li>
    52395258            <li><a id="rfc.index.T" href="#rfc.index.T"><b>T</b></a><ul>
    5240                   <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>
     5259                  <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>
    52415260               </ul>
    52425261            </li>

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

    r1839 r1840  
    327327   <ttcol>Sec.</ttcol>
    328328   <c>GET</c>
    329    <c>Retrieve a current representation of the target resource.</c>
     329   <c>Transfer a current representation of the target resource.</c>
    330330   <c><xref target="GET" format="counter"/></c>
    331331   <c>HEAD</c>
    … …  
    354354<t>
    355355   The methods GET and HEAD &MUST; be supported by all general-purpose
    356    servers. All other methods are &OPTIONAL;. If one of the above methods is
    357    implemented by a server, the server &MUST; implement that method according
    358    to the semantics defined for it in <xref target="method.definitions"/>.
    359 </t>
    360 <t>
    361    Additional methods &MAY; be used in HTTP.  New methods &SHOULD; be
    362    registered within the IANA registry, as defined in
     356   servers. All other methods are &OPTIONAL;.
     357   When implemented, a server &MUST; implement the above methods according
     358   to the semantics defined for them in <xref target="method.definitions"/>.
     359</t>
     360<t>
     361   Additional methods &MAY; be used in HTTP; many have already been
     362   standardized outside the scope of this specification and registered
     363   within the HTTP Method Registry maintained by IANA, as defined in
    363364   <xref target="method.registry"/>.
    364365</t>
    … …  
    377378
    378379<section title="Safe Methods" anchor="safe.methods">
    379 <iref item="Safe Methods" primary="true"/>
     380<iref item="safe" primary="true"/>
    380381<t>
    381382   Request methods are considered "<x:dfn anchor="safe">safe</x:dfn>" if
    382    their defined semantics are essentially read-only; i.e., the user does
     383   their defined semantics are essentially read-only; i.e., the client does
    383384   not request, and does not expect, any state change on the origin server
    384385   as a result of applying a safe method to a target resource.  Likewise,
    … …  
    389390   This definition of safe methods does not prevent an implementation from
    390391   including behavior that is potentially harmful, not entirely read-only,
    391    or which causes side-effects while invoking a safe method.  In fact,
    392    some dynamic resources might consider that a feature.  What is
    393    important, however, is that the user did not request that additional
     392   or which causes side-effects while invoking a safe method.  What is
     393   important, however, is that the client did not request that additional
    394394   behavior and cannot be held accountable for it.  For example,
    395395   most servers append request information to access log files at the
    396396   completion of every response, regardless of the method, and that is
    397397   considered safe even though the log storage might become full and crash
    398    the server.
     398   the server.  Likewise, a safe request initiated by selecting an
     399   advertisement on the Web will often have the side-effect of charging an
     400   advertising account.
    399401</t>
    400402<t>
    401403   The GET, HEAD, OPTIONS, and TRACE request methods are defined to be safe.
     404</t>
     405<t>
     406   The purpose of distinguishing between safe and unsafe methods is to
     407   allow automated retrieval processes (spiders) and cache performance
     408   optimization (pre-fetching) to work without fear of causing harm.
     409   In addition, it allows a user agent to apply appropriate constraints
     410   on the automated use of unsafe methods when processing potentially
     411   untrusted content.
    402412</t>
    403413<t>
    … …  
    405415   presenting potential actions to a user, such that the user can be made
    406416   aware of an unsafe action before it is requested.
    407    A user agent &SHOULD-NOT; make requests using unsafe methods as an
    408    automated result of the user selecting a safe action, unless the
    409    instruction for making the unsafe request came from the same origin server
    410    as the request target.
    411417</t>
    412418<t>
    … …  
    415421   owner's responsibility to ensure that the action is consistent with the
    416422   request method semantics.
    417    For example, it is common for HTML form-based content editing software
     423   For example, it is common for Web-based content editing software
    418424   to use actions within query parameters, such as "page?do=delete".
    419425   If the purpose of such a resource is to perform an unsafe action, then
    … …  
    421427   using a safe request method.  Failure to do so will result in
    422428   unfortunate side-effects when automated processes perform a GET on
    423    every URI reference, which often occurs for the sake of link maintenance,
    424    pre-fetching, or building a search index.
     429   every URI reference for the sake of link maintenance, pre-fetching,
     430   building a search index, etc.
    425431</t>
    426432</section>
    427433
    428434<section title="Idempotent Methods" anchor="idempotent.methods">
    429 <iref item="Idempotent Methods" primary="true"/>
    430 <t>
    431    Request methods can also have the property of "idempotence" in that,
    432    aside from error or expiration issues, the intended effect of multiple
    433    identical requests is the same as for a single request.
     435<iref item="idempotent" primary="true"/>
     436<t>
     437   Request methods are considered
     438   "<x:dfn anchor="idempotent">idempotent</x:dfn>" if the intended effect
     439   of multiple identical requests is the same as for a single request.
    434440   PUT, DELETE, and all safe request methods are idempotent.
    435    It is important to note that idempotence refers only to changes
    436    requested by the client: a server is free to change its state due
    437    to multiple requests for the purpose of tracking those requests,
    438    versioning of results, etc.
    439 </t>
    440 </section>
    441 </section>
    442 
    443 <section title="Method Registry" anchor="method.registry">
    444 <t>
    445   The HTTP Method Registry defines the name space for the method token in the
    446   Request line of an HTTP request.
    447 </t>
    448 <t>
    449   Registrations &MUST; include the following fields:
    450   <list style="symbols">
    451     <t>Method Name (see <xref target="methods"/>)</t>
    452     <t>Safe ("yes" or "no", see <xref target="safe.methods"/>)</t>
    453     <t>Idempotent ("yes" or "no", see <xref target="safe.methods"/>)</t>
    454     <t>Pointer to specification text</t>
    455   </list>
    456 </t>
    457 <t>
    458   Values to be added to this name space require IETF Review
    459   (see <xref target="RFC5226" x:fmt="," x:sec="4.1"/>).
    460 </t>
    461 <t>
    462   The registry itself is maintained at <eref target="http://www.iana.org/assignments/http-methods"/>.
    463 </t>
    464 
    465 <section title="Considerations for New Methods" anchor="considerations.for.new.methods">
    466 <t>
    467    When it is necessary to express new semantics for a HTTP request that
    468    aren't specific to a single application or media type, and currently defined
    469    methods are inadequate, it might be appropriate to register a new method.
    470 </t>
    471 <t>
    472    HTTP methods are generic; that is, they are potentially applicable to any
    473    resource, not just one particular media type, "type" of resource, or
    474    application. As such, it is preferred that new HTTP methods be registered
    475    in a document that isn't specific to a single application, so that this is
    476    clear.
    477 </t>
    478 <t>
    479    Due to the parsing rules defined in &message-body;, definitions of HTTP
    480    methods cannot prohibit the presence of a message body on either the request
    481    or the response message (with responses to HEAD requests being the single
    482    exception). Definitions of new methods cannot change this rule, but they can
    483    specify that only zero-length bodies (as opposed to absent bodies) are allowed.
    484 </t>
    485 <t>
    486    New method definitions need to indicate whether they are safe (<xref
    487    target="safe.methods"/>), what semantics (if any) the request body has,
    488    and whether they are idempotent (<xref target="idempotent.methods"/>).
    489    They also need to state whether they can be cached (&caching;); in
    490    particular under what conditions a cache can store the response, and under
    491    what conditions such a stored response can be used to satisfy a subsequent
    492    request.
     441</t>
     442<t>
     443   Like the definition of safe, the idempotent property only applies to
     444   what has been requested by the user; a server is free to log each request
     445   separately, retain a revision control history, or implement other
     446   non-idempotent side-effects for each idempotent request.
     447</t>
     448<t>
     449   Idempotent methods are distinguished because the request can be repeated
     450   automatically if a communication failure occurs before the client is
     451   able to read the server's response.  For example, if a client sends a PUT
     452   request and the underlying connection is closed before any response is
     453   received, then it can establish a new connection and retry the request
     454   because it knows that repeating the request will have the same effect
     455   even if the original request succeeded.  Note, however, that repeated
     456   failures would indicate a problem within the server.
     457</t>
     458</section>
     459
     460<section title="Cacheable Methods" anchor="cacheable.methods">
     461<iref item="cacheable" primary="true"/>
     462<t>
     463   Request methods are considered
     464   "<x:dfn anchor="cacheable">cacheable</x:dfn>" if it is possible and useful
     465   to answer a current client request with a stored response from a prior
     466   request.  GET and HEAD are defined to be cacheable.  In general, safe
     467   methods that do not depend on a current or authoritative response are
     468   also cacheable, though the overwhelming majority of caches only support
     469   GET and HEAD. HTTP requirements for cache behavior and cacheable responses
     470   are defined in &caching;.
    493471</t>
    494472</section>
    … …  
    40434021<section title="IANA Considerations" anchor="IANA.considerations">
    40444022
    4045 <section title="Method Registry" anchor="method.registration">
    4046 <t>
    4047   The registration procedure for HTTP request methods is defined by
    4048   <xref target="method.registry"/> of this document.
    4049 </t>
     4023<section title="Method Registry" anchor="method.registry">
     4024<t>
     4025  The HTTP Method Registry defines the name space for the method token in the
     4026  Request line of an HTTP request.
     4027</t>
     4028<t>
     4029  Registrations &MUST; include the following fields:
     4030  <list style="symbols">
     4031    <t>Method Name (see <xref target="methods"/>)</t>
     4032    <t>Safe ("yes" or "no", see <xref target="safe.methods"/>)</t>
     4033    <t>Idempotent ("yes" or "no", see <xref target="safe.methods"/>)</t>
     4034    <t>Pointer to specification text</t>
     4035  </list>
     4036</t>
     4037<t>
     4038  Values to be added to this name space require IETF Review
     4039  (see <xref target="RFC5226" x:fmt="," x:sec="4.1"/>).
     4040</t>
     4041<t>
     4042  The registry itself is maintained at <eref target="http://www.iana.org/assignments/http-methods"/>.
     4043</t>
     4044
     4045<section title="Considerations for New Methods" anchor="considerations.for.new.methods">
     4046<t>
     4047   Standardized HTTP methods are generic; that is, they are potentially
     4048   applicable to any resource, not just one particular media type, kind of
     4049   resource, or application. As such, it is preferred that new HTTP methods
     4050   be registered in a document that isn't specific to a single application or
     4051   data format, since orthogonal technologies deserve orthogonal specification.
     4052</t>
     4053<t>
     4054   Since HTTP message parsing (&message-body;) is independent of method
     4055   semantics (aside from responses to HEAD), definitions of new HTTP methods
     4056   cannot change the parsing algorithm or prohibit the presence of a message
     4057   body on either the request or the response message.
     4058   Definitions of new methods can specify that only zero-length bodies are
     4059   allowed, which would imply that each such messages would be required to
     4060   contain a Content-Length header field with a value of "0".
     4061</t>
     4062<t>
     4063   New method definitions need to indicate whether they are safe (<xref
     4064   target="safe.methods"/>), idempotent (<xref target="idempotent.methods"/>),
     4065   or cacheable (<xref target="cacheable.methods"/>), and what
     4066   semantics are to be associated with the request body if any is present
     4067   in the request.  If a method is cacheable, the method definition ought
     4068   to describe how, and under what conditions, a cache can store a response
     4069   and use it to satisfy a subsequent request.
     4070</t>
     4071</section>
     4072
     4073<section title="Registrations" anchor="method.registration">
    40504074<t>
    40514075   The HTTP Method Registry shall be created at <eref target="http://www.iana.org/assignments/http-methods"/>
    … …  
    41104134<!--(END)-->
    41114135<?ENDINC p2-semantics.iana-methods ?>
     4136</section>
    41124137</section>
    41134138
Note: See TracChangeset for help on using the changeset viewer.