Changeset 1619


Ignore:
Timestamp:
Mar 26, 2012, 7:44:27 AM (7 years ago)
Author:
julian.reschke@…
Message:

re-org sections

Location:
draft-ietf-httpbis/latest
Files:
2 edited

Legend:

Unmodified
Added
Removed

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

    r1618 r1619  
    483483      <link rel="Index" href="#rfc.index">
    484484      <link rel="Chapter" title="1 Introduction" href="#rfc.section.1">
    485       <link rel="Chapter" title="2 Method" href="#rfc.section.2">
     485      <link rel="Chapter" title="2 Methods" href="#rfc.section.2">
    486486      <link rel="Chapter" title="3 Header Fields" href="#rfc.section.3">
    487487      <link rel="Chapter" title="4 Status Code and Reason Phrase" href="#rfc.section.4">
    488488      <link rel="Chapter" title="5 Representation" href="#rfc.section.5">
    489       <link rel="Chapter" title="6 Method Definitions" href="#rfc.section.6">
    490       <link rel="Chapter" title="7 Common Protocol Parameters" href="#rfc.section.7">
    491       <link rel="Chapter" title="8 Header Field Definitions" href="#rfc.section.8">
    492       <link rel="Chapter" title="9 IANA Considerations" href="#rfc.section.9">
    493       <link rel="Chapter" title="10 Security Considerations" href="#rfc.section.10">
    494       <link rel="Chapter" title="11 Acknowledgments" href="#rfc.section.11">
    495       <link rel="Chapter" href="#rfc.section.12" title="12 References">
     489      <link rel="Chapter" title="6 Common Protocol Parameters" href="#rfc.section.6">
     490      <link rel="Chapter" title="7 Header Field Definitions" href="#rfc.section.7">
     491      <link rel="Chapter" title="8 IANA Considerations" href="#rfc.section.8">
     492      <link rel="Chapter" title="9 Security Considerations" href="#rfc.section.9">
     493      <link rel="Chapter" title="10 Acknowledgments" href="#rfc.section.10">
     494      <link rel="Chapter" href="#rfc.section.11" title="11 References">
    496495      <link rel="Appendix" title="A Changes from RFC 2616" href="#rfc.section.A">
    497496      <link rel="Appendix" title="B Collected ABNF" href="#rfc.section.B">
    … …  
    598597            </ul>
    599598         </li>
    600          <li>2.&nbsp;&nbsp;&nbsp;<a href="#method">Method</a><ul>
    601                <li>2.1&nbsp;&nbsp;&nbsp;<a href="#overview.of.methods">Overview of Methods</a></li>
     599         <li>2.&nbsp;&nbsp;&nbsp;<a href="#methods">Methods</a><ul>
     600               <li>2.1&nbsp;&nbsp;&nbsp;<a href="#safe.and.idempotent">Safe and Idempotent Methods</a><ul>
     601                     <li>2.1.1&nbsp;&nbsp;&nbsp;<a href="#safe.methods">Safe Methods</a></li>
     602                     <li>2.1.2&nbsp;&nbsp;&nbsp;<a href="#idempotent.methods">Idempotent Methods</a></li>
     603                  </ul>
     604               </li>
    602605               <li>2.2&nbsp;&nbsp;&nbsp;<a href="#method.registry">Method Registry</a><ul>
    603606                     <li>2.2.1&nbsp;&nbsp;&nbsp;<a href="#considerations.for.new.methods">Considerations for New Methods</a></li>
     607                  </ul>
     608               </li>
     609               <li>2.3&nbsp;&nbsp;&nbsp;<a href="#method.definitions">Method Definitions</a><ul>
     610                     <li>2.3.1&nbsp;&nbsp;&nbsp;<a href="#OPTIONS">OPTIONS</a></li>
     611                     <li>2.3.2&nbsp;&nbsp;&nbsp;<a href="#GET">GET</a></li>
     612                     <li>2.3.3&nbsp;&nbsp;&nbsp;<a href="#HEAD">HEAD</a></li>
     613                     <li>2.3.4&nbsp;&nbsp;&nbsp;<a href="#POST">POST</a></li>
     614                     <li>2.3.5&nbsp;&nbsp;&nbsp;<a href="#PUT">PUT</a></li>
     615                     <li>2.3.6&nbsp;&nbsp;&nbsp;<a href="#DELETE">DELETE</a></li>
     616                     <li>2.3.7&nbsp;&nbsp;&nbsp;<a href="#TRACE">TRACE</a></li>
     617                     <li>2.3.8&nbsp;&nbsp;&nbsp;<a href="#CONNECT">CONNECT</a></li>
    604618                  </ul>
    605619               </li>
    … …  
    678692            </ul>
    679693         </li>
    680          <li>6.&nbsp;&nbsp;&nbsp;<a href="#method.definitions">Method Definitions</a><ul>
    681                <li>6.1&nbsp;&nbsp;&nbsp;<a href="#safe.and.idempotent">Safe and Idempotent Methods</a><ul>
    682                      <li>6.1.1&nbsp;&nbsp;&nbsp;<a href="#safe.methods">Safe Methods</a></li>
    683                      <li>6.1.2&nbsp;&nbsp;&nbsp;<a href="#idempotent.methods">Idempotent Methods</a></li>
    684                   </ul>
    685                </li>
    686                <li>6.2&nbsp;&nbsp;&nbsp;<a href="#OPTIONS">OPTIONS</a></li>
    687                <li>6.3&nbsp;&nbsp;&nbsp;<a href="#GET">GET</a></li>
    688                <li>6.4&nbsp;&nbsp;&nbsp;<a href="#HEAD">HEAD</a></li>
    689                <li>6.5&nbsp;&nbsp;&nbsp;<a href="#POST">POST</a></li>
    690                <li>6.6&nbsp;&nbsp;&nbsp;<a href="#PUT">PUT</a></li>
    691                <li>6.7&nbsp;&nbsp;&nbsp;<a href="#DELETE">DELETE</a></li>
    692                <li>6.8&nbsp;&nbsp;&nbsp;<a href="#TRACE">TRACE</a></li>
    693                <li>6.9&nbsp;&nbsp;&nbsp;<a href="#CONNECT">CONNECT</a></li>
     694         <li>6.&nbsp;&nbsp;&nbsp;<a href="#common.protocol.parameters">Common Protocol Parameters</a><ul>
     695               <li>6.1&nbsp;&nbsp;&nbsp;<a href="#http.date">Date/Time Formats</a></li>
     696               <li>6.2&nbsp;&nbsp;&nbsp;<a href="#product.tokens">Product Tokens</a></li>
    694697            </ul>
    695698         </li>
    696          <li>7.&nbsp;&nbsp;&nbsp;<a href="#common.protocol.parameters">Common Protocol Parameters</a><ul>
    697                <li>7.1&nbsp;&nbsp;&nbsp;<a href="#http.date">Date/Time Formats</a></li>
    698                <li>7.2&nbsp;&nbsp;&nbsp;<a href="#product.tokens">Product Tokens</a></li>
     699         <li>7.&nbsp;&nbsp;&nbsp;<a href="#header.field.definitions">Header Field Definitions</a><ul>
     700               <li>7.1&nbsp;&nbsp;&nbsp;<a href="#header.allow">Allow</a></li>
     701               <li>7.2&nbsp;&nbsp;&nbsp;<a href="#header.date">Date</a></li>
     702               <li>7.3&nbsp;&nbsp;&nbsp;<a href="#header.expect">Expect</a></li>
     703               <li>7.4&nbsp;&nbsp;&nbsp;<a href="#header.from">From</a></li>
     704               <li>7.5&nbsp;&nbsp;&nbsp;<a href="#header.location">Location</a></li>
     705               <li>7.6&nbsp;&nbsp;&nbsp;<a href="#header.max-forwards">Max-Forwards</a></li>
     706               <li>7.7&nbsp;&nbsp;&nbsp;<a href="#header.referer">Referer</a></li>
     707               <li>7.8&nbsp;&nbsp;&nbsp;<a href="#header.retry-after">Retry-After</a></li>
     708               <li>7.9&nbsp;&nbsp;&nbsp;<a href="#header.server">Server</a></li>
     709               <li>7.10&nbsp;&nbsp;&nbsp;<a href="#header.user-agent">User-Agent</a></li>
    699710            </ul>
    700711         </li>
    701          <li>8.&nbsp;&nbsp;&nbsp;<a href="#header.field.definitions">Header Field Definitions</a><ul>
    702                <li>8.1&nbsp;&nbsp;&nbsp;<a href="#header.allow">Allow</a></li>
    703                <li>8.2&nbsp;&nbsp;&nbsp;<a href="#header.date">Date</a></li>
    704                <li>8.3&nbsp;&nbsp;&nbsp;<a href="#header.expect">Expect</a></li>
    705                <li>8.4&nbsp;&nbsp;&nbsp;<a href="#header.from">From</a></li>
    706                <li>8.5&nbsp;&nbsp;&nbsp;<a href="#header.location">Location</a></li>
    707                <li>8.6&nbsp;&nbsp;&nbsp;<a href="#header.max-forwards">Max-Forwards</a></li>
    708                <li>8.7&nbsp;&nbsp;&nbsp;<a href="#header.referer">Referer</a></li>
    709                <li>8.8&nbsp;&nbsp;&nbsp;<a href="#header.retry-after">Retry-After</a></li>
    710                <li>8.9&nbsp;&nbsp;&nbsp;<a href="#header.server">Server</a></li>
    711                <li>8.10&nbsp;&nbsp;&nbsp;<a href="#header.user-agent">User-Agent</a></li>
     712         <li>8.&nbsp;&nbsp;&nbsp;<a href="#IANA.considerations">IANA Considerations</a><ul>
     713               <li>8.1&nbsp;&nbsp;&nbsp;<a href="#method.registration">Method Registry</a></li>
     714               <li>8.2&nbsp;&nbsp;&nbsp;<a href="#status.code.registration">Status Code Registry</a></li>
     715               <li>8.3&nbsp;&nbsp;&nbsp;<a href="#header.field.registration">Header Field Registration</a></li>
    712716            </ul>
    713717         </li>
    714          <li>9.&nbsp;&nbsp;&nbsp;<a href="#IANA.considerations">IANA Considerations</a><ul>
    715                <li>9.1&nbsp;&nbsp;&nbsp;<a href="#method.registration">Method Registry</a></li>
    716                <li>9.2&nbsp;&nbsp;&nbsp;<a href="#status.code.registration">Status Code Registry</a></li>
    717                <li>9.3&nbsp;&nbsp;&nbsp;<a href="#header.field.registration">Header Field Registration</a></li>
     718         <li>9.&nbsp;&nbsp;&nbsp;<a href="#security.considerations">Security Considerations</a><ul>
     719               <li>9.1&nbsp;&nbsp;&nbsp;<a href="#security.sensitive">Transfer of Sensitive Information</a></li>
     720               <li>9.2&nbsp;&nbsp;&nbsp;<a href="#encoding.sensitive.information.in.uris">Encoding Sensitive Information in URIs</a></li>
     721               <li>9.3&nbsp;&nbsp;&nbsp;<a href="#location.spoofing-leakage">Location Header Fields: Spoofing and Information Leakage</a></li>
     722               <li>9.4&nbsp;&nbsp;&nbsp;<a href="#rfc.section.9.4">Security Considerations for CONNECT</a></li>
    718723            </ul>
    719724         </li>
    720          <li>10.&nbsp;&nbsp;&nbsp;<a href="#security.considerations">Security Considerations</a><ul>
    721                <li>10.1&nbsp;&nbsp;&nbsp;<a href="#security.sensitive">Transfer of Sensitive Information</a></li>
    722                <li>10.2&nbsp;&nbsp;&nbsp;<a href="#encoding.sensitive.information.in.uris">Encoding Sensitive Information in URIs</a></li>
    723                <li>10.3&nbsp;&nbsp;&nbsp;<a href="#location.spoofing-leakage">Location Header Fields: Spoofing and Information Leakage</a></li>
    724                <li>10.4&nbsp;&nbsp;&nbsp;<a href="#rfc.section.10.4">Security Considerations for CONNECT</a></li>
    725             </ul>
    726          </li>
    727          <li>11.&nbsp;&nbsp;&nbsp;<a href="#acks">Acknowledgments</a></li>
    728          <li>12.&nbsp;&nbsp;&nbsp;<a href="#rfc.references">References</a><ul>
    729                <li>12.1&nbsp;&nbsp;&nbsp;<a href="#rfc.references.1">Normative References</a></li>
    730                <li>12.2&nbsp;&nbsp;&nbsp;<a href="#rfc.references.2">Informative References</a></li>
     725         <li>10.&nbsp;&nbsp;&nbsp;<a href="#acks">Acknowledgments</a></li>
     726         <li>11.&nbsp;&nbsp;&nbsp;<a href="#rfc.references">References</a><ul>
     727               <li>11.1&nbsp;&nbsp;&nbsp;<a href="#rfc.references.1">Normative References</a></li>
     728               <li>11.2&nbsp;&nbsp;&nbsp;<a href="#rfc.references.2">Informative References</a></li>
    731729            </ul>
    732730         </li>
    … …  
    812810  <a href="#abnf.dependencies" class="smpl">partial-URI</a>   = &lt;partial-URI, defined in <a href="#Part1" id="rfc.xref.Part1.13"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.7</a>&gt;
    813811  <a href="#abnf.dependencies" class="smpl">URI-reference</a> = &lt;URI-reference, defined in <a href="#Part1" id="rfc.xref.Part1.14"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.7</a>&gt;
    814 </pre><h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a>&nbsp;<a id="method" href="#method">Method</a></h1>
     812</pre><h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a>&nbsp;<a id="methods" href="#methods">Methods</a></h1>
    815813      <p id="rfc.section.2.p.1">The method token indicates the request method to be performed on the target resource (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 5.5</a> of <a href="#Part1" id="rfc.xref.Part1.15"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). The method is case-sensitive.
    816814      </p>
    817       <div id="rfc.figure.u.3"></div><pre class="inline"><span id="rfc.iref.g.1"></span>  <a href="#method" class="smpl">method</a>         = <a href="#core.rules" class="smpl">token</a>
    818 </pre><p id="rfc.section.2.p.3">The list of methods allowed by a resource can be specified in an Allow header field (<a href="#header.allow" id="rfc.xref.header.allow.1" title="Allow">Section&nbsp;8.1</a>). The status code of the response always notifies the client whether a method is currently allowed on a resource, since the
     815      <div id="rfc.figure.u.3"></div><pre class="inline"><span id="rfc.iref.g.1"></span>  <a href="#methods" class="smpl">method</a>         = <a href="#core.rules" class="smpl">token</a>
     816</pre><p id="rfc.section.2.p.3">The list of methods allowed by a resource can be specified in an Allow header field (<a href="#header.allow" id="rfc.xref.header.allow.1" title="Allow">Section&nbsp;7.1</a>). The status code of the response always notifies the client whether a method is currently allowed on a resource, since the
    819817         set of allowed methods can change dynamically. An origin server <em class="bcp14">SHOULD</em> respond with the status code 405 (Method Not Allowed) if the method is known by the origin server but not allowed for the
    820818         resource, and 501 (Not Implemented) if the method is unrecognized or not implemented by the origin server. The methods GET
    821          and HEAD <em class="bcp14">MUST</em> be supported by all general-purpose servers. All other methods are <em class="bcp14">OPTIONAL</em>; however, if the above methods are implemented, they <em class="bcp14">MUST</em> be implemented with the same semantics as those specified in <a href="#method.definitions" title="Method Definitions">Section&nbsp;6</a>.
    822       </p>
    823       <h2 id="rfc.section.2.1"><a href="#rfc.section.2.1">2.1</a>&nbsp;<a id="overview.of.methods" href="#overview.of.methods">Overview of Methods</a></h2>
    824       <p id="rfc.section.2.1.p.1">The methods listed below are defined in <a href="#method.definitions" title="Method Definitions">Section&nbsp;6</a>.
    825       </p>
    826       <div id="rfc.table.u.1">
    827          <table class="tt full left" cellpadding="3" cellspacing="0">
    828             <thead>
    829                <tr>
    830                   <th>Method Name</th>
    831                   <th>Defined in...</th>
    832                </tr>
    833             </thead>
    834             <tbody>
    835                <tr>
    836                   <td class="left">OPTIONS</td>
    837                   <td class="left"><a href="#OPTIONS" id="rfc.xref.OPTIONS.1" title="OPTIONS">Section&nbsp;6.2</a></td>
    838                </tr>
    839                <tr>
    840                   <td class="left">GET</td>
    841                   <td class="left"><a href="#GET" id="rfc.xref.GET.1" title="GET">Section&nbsp;6.3</a></td>
    842                </tr>
    843                <tr>
    844                   <td class="left">HEAD</td>
    845                   <td class="left"><a href="#HEAD" id="rfc.xref.HEAD.1" title="HEAD">Section&nbsp;6.4</a></td>
    846                </tr>
    847                <tr>
    848                   <td class="left">POST</td>
    849                   <td class="left"><a href="#POST" id="rfc.xref.POST.1" title="POST">Section&nbsp;6.5</a></td>
    850                </tr>
    851                <tr>
    852                   <td class="left">PUT</td>
    853                   <td class="left"><a href="#PUT" id="rfc.xref.PUT.1" title="PUT">Section&nbsp;6.6</a></td>
    854                </tr>
    855                <tr>
    856                   <td class="left">DELETE</td>
    857                   <td class="left"><a href="#DELETE" id="rfc.xref.DELETE.1" title="DELETE">Section&nbsp;6.7</a></td>
    858                </tr>
    859                <tr>
    860                   <td class="left">TRACE</td>
    861                   <td class="left"><a href="#TRACE" id="rfc.xref.TRACE.1" title="TRACE">Section&nbsp;6.8</a></td>
    862                </tr>
    863                <tr>
    864                   <td class="left">CONNECT</td>
    865                   <td class="left"><a href="#CONNECT" id="rfc.xref.CONNECT.1" title="CONNECT">Section&nbsp;6.9</a></td>
    866                </tr>
    867             </tbody>
    868          </table>
    869       </div>
    870       <p id="rfc.section.2.1.p.2">Note that this list is not exhaustive — it does not include request methods defined in other specifications.</p>
     819         and HEAD <em class="bcp14">MUST</em> be supported by all general-purpose servers. All other methods are <em class="bcp14">OPTIONAL</em>; however, if the above methods are implemented, they <em class="bcp14">MUST</em> be implemented with the same semantics as those specified in <a href="#method.definitions" title="Method Definitions">Section&nbsp;2.3</a>.
     820      </p>
     821      <h2 id="rfc.section.2.1"><a href="#rfc.section.2.1">2.1</a>&nbsp;<a id="safe.and.idempotent" href="#safe.and.idempotent">Safe and Idempotent Methods</a></h2>
     822      <div id="rfc.iref.s.1"></div>
     823      <h3 id="rfc.section.2.1.1"><a href="#rfc.section.2.1.1">2.1.1</a>&nbsp;<a id="safe.methods" href="#safe.methods">Safe Methods</a></h3>
     824      <p id="rfc.section.2.1.1.p.1">Implementors need to be aware that the software represents the user in their interactions over the Internet, and need to allow
     825         the user to be aware of any actions they take which might have an unexpected significance to themselves or others.
     826      </p>
     827      <p id="rfc.section.2.1.1.p.2">In particular, the convention has been established that the GET, HEAD, OPTIONS, and TRACE request methods <em class="bcp14">SHOULD NOT</em> have the significance of taking an action other than retrieval. These request methods ought to be considered "<dfn id="safe">safe</dfn>". This allows user agents to represent other methods, such as POST, PUT and DELETE, in a special way, so that the user is
     828         made aware of the fact that a possibly unsafe action is being requested.
     829      </p>
     830      <p id="rfc.section.2.1.1.p.3">Naturally, it is not possible to ensure that the server does not generate side-effects as a result of performing a GET request;
     831         in fact, some dynamic resources consider that a feature. The important distinction here is that the user did not request the
     832         side-effects, so therefore cannot be held accountable for them.
     833      </p>
     834      <div id="rfc.iref.i.1"></div>
     835      <h3 id="rfc.section.2.1.2"><a href="#rfc.section.2.1.2">2.1.2</a>&nbsp;<a id="idempotent.methods" href="#idempotent.methods">Idempotent Methods</a></h3>
     836      <p id="rfc.section.2.1.2.p.1">Request methods can also have the property of "idempotence" in that, aside from error or expiration issues, the intended effect
     837         of multiple identical requests is the same as for a single request. PUT, DELETE, and all safe request methods are idempotent.
     838         It is important to note that idempotence refers only to changes requested by the client: a server is free to change its state
     839         due to multiple requests for the purpose of tracking those requests, versioning of results, etc.
     840      </p>
    871841      <h2 id="rfc.section.2.2"><a href="#rfc.section.2.2">2.2</a>&nbsp;<a id="method.registry" href="#method.registry">Method Registry</a></h2>
    872842      <p id="rfc.section.2.2.p.1">The HTTP Method Registry defines the name space for the method token in the Request line of an HTTP request.</p>
    … …  
    874844      </p>
    875845      <ul>
    876          <li>Method Name (see <a href="#method" title="Method">Section&nbsp;2</a>)
    877          </li>
    878          <li>Safe ("yes" or "no", see <a href="#safe.methods" title="Safe Methods">Section&nbsp;6.1.1</a>)
     846         <li>Method Name (see <a href="#methods" title="Methods">Section&nbsp;2</a>)
     847         </li>
     848         <li>Safe ("yes" or "no", see <a href="#safe.methods" title="Safe Methods">Section&nbsp;2.1.1</a>)
    879849         </li>
    880850         <li>Pointer to specification text</li>
    … …  
    896866         can specify that only zero-length bodies (as opposed to absent bodies) are allowed.
    897867      </p>
    898       <p id="rfc.section.2.2.1.p.4">New method definitions need to indicate whether they are safe (<a href="#safe.methods" title="Safe Methods">Section&nbsp;6.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;6.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 what conditions a cache may store the response, and under what conditions such a stored response may be used
     868      <p id="rfc.section.2.2.1.p.4">New method definitions need to indicate whether they are safe (<a href="#safe.methods" title="Safe Methods">Section&nbsp;2.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;2.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 what conditions a cache may store the response, and under what conditions such a stored response may be used
    899869         to satisfy a subsequent request.
     870      </p>
     871      <h2 id="rfc.section.2.3"><a href="#rfc.section.2.3">2.3</a>&nbsp;<a id="method.definitions" href="#method.definitions">Method Definitions</a></h2>
     872      <h3 id="rfc.section.2.3.1"><a href="#rfc.section.2.3.1">2.3.1</a>&nbsp;<a id="OPTIONS" href="#OPTIONS">OPTIONS</a></h3>
     873      <div id="rfc.iref.o.1"></div>
     874      <div id="rfc.iref.m.1"></div>
     875      <p id="rfc.section.2.3.1.p.1">The OPTIONS method requests information about the communication options available on the request/response chain identified
     876         by the effective request URI. This method allows a client to determine the options and/or requirements associated with a resource,
     877         or the capabilities of a server, without implying a resource action or initiating a resource retrieval.
     878      </p>
     879      <p id="rfc.section.2.3.1.p.2">Responses to the OPTIONS method are not cacheable.</p>
     880      <p id="rfc.section.2.3.1.p.3">If the OPTIONS request includes a message body (as indicated by the presence of Content-Length or Transfer-Encoding), then
     881         the media type <em class="bcp14">MUST</em> be indicated by a Content-Type field. Although this specification does not define any use for such a body, future extensions
     882         to HTTP might use the OPTIONS body to make more detailed queries on the server.
     883      </p>
     884      <p id="rfc.section.2.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.17"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) is an asterisk ("*"), the OPTIONS request is intended to apply to the server in general rather than to a specific resource.
     885         Since a server's communication options typically depend on the resource, the "*" request is only useful as a "ping" or "no-op"
     886         type of method; it does nothing beyond allowing the client to test the capabilities of the server. For example, this can be
     887         used to test a proxy for HTTP/1.1 conformance (or lack thereof).
     888      </p>
     889      <p id="rfc.section.2.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
     890         with that resource.
     891      </p>
     892      <p id="rfc.section.2.3.1.p.6">A 200 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.,
     893         Allow), 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,
     894         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 Content-Length field with a field-value of "0".
     895      </p>
     896      <p id="rfc.section.2.3.1.p.7">The Max-Forwards 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;7.6</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.
     897      </p>
     898      <h3 id="rfc.section.2.3.2"><a href="#rfc.section.2.3.2">2.3.2</a>&nbsp;<a id="GET" href="#GET">GET</a></h3>
     899      <div id="rfc.iref.g.2"></div>
     900      <div id="rfc.iref.m.2"></div>
     901      <p id="rfc.section.2.3.2.p.1">The GET method requests transfer of a current representation of the target resource.</p>
     902      <p id="rfc.section.2.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
     903         in the response and not the source text of the process, unless that text happens to be the output of the process.
     904      </p>
     905      <p id="rfc.section.2.3.2.p.3">The semantics of the GET method change to a "conditional GET" if the request message includes an If-Modified-Since, If-Unmodified-Since,
     906         If-Match, If-None-Match, or If-Range header field. A conditional GET requests that the representation be transferred only
     907         under the circumstances described by the conditional header field(s). The conditional GET request is intended to reduce unnecessary
     908         network usage by allowing cached representations to be refreshed without requiring multiple requests or transferring data
     909         already held by the client.
     910      </p>
     911      <p id="rfc.section.2.3.2.p.4">The semantics of the GET method change to a "partial GET" if the request message includes a Range header field. A partial
     912         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.1"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>. The partial GET request is intended to reduce unnecessary network usage by allowing partially-retrieved representations
     913         to be completed without transferring data already held by the client.
     914      </p>
     915      <p id="rfc.section.2.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
     916         to reject the request.
     917      </p>
     918      <p id="rfc.section.2.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>).
     919      </p>
     920      <p id="rfc.section.2.3.2.p.7">See <a href="#encoding.sensitive.information.in.uris" title="Encoding Sensitive Information in URIs">Section&nbsp;9.2</a> for security considerations when used for forms.
     921      </p>
     922      <h3 id="rfc.section.2.3.3"><a href="#rfc.section.2.3.3">2.3.3</a>&nbsp;<a id="HEAD" href="#HEAD">HEAD</a></h3>
     923      <div id="rfc.iref.h.1"></div>
     924      <div id="rfc.iref.m.3"></div>
     925      <p id="rfc.section.2.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
     926         representation implied by the request without transferring the representation body. This method is often used for testing
     927         hypertext links for validity, accessibility, and recent modification.
     928      </p>
     929      <p id="rfc.section.2.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 2.5</a> of <a href="#Part6" id="rfc.xref.Part6.3"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>.
     930      </p>
     931      <p id="rfc.section.2.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
     932         to reject the request.
     933      </p>
     934      <div id="rfc.iref.p.1"></div>
     935      <div id="rfc.iref.m.4"></div>
     936      <h3 id="rfc.section.2.3.4"><a href="#rfc.section.2.3.4">2.3.4</a>&nbsp;<a id="POST" href="#POST">POST</a></h3>
     937      <p id="rfc.section.2.3.4.p.1">The POST method requests that the origin server accept the representation enclosed in the request as data to be processed
     938         by the target resource. POST is designed to allow a uniform method to cover the following functions:
     939      </p>
     940      <ul>
     941         <li>Annotation of existing resources;</li>
     942         <li>Posting a message to a bulletin board, newsgroup, mailing list, or similar group of articles;</li>
     943         <li>Providing a block of data, such as the result of submitting a form, to a data-handling process;</li>
     944         <li>Extending a database through an append operation.</li>
     945      </ul>
     946      <p id="rfc.section.2.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
     947         URI.
     948      </p>
     949      <p id="rfc.section.2.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
     950         200 (OK) or 204 (No Content) is the appropriate response status code, depending on whether or not the response includes a
     951         representation that describes the result.
     952      </p>
     953      <p id="rfc.section.2.3.4.p.4">If a resource has been created on the origin server, the response <em class="bcp14">SHOULD</em> be 201 (Created) and contain a representation which describes the status of the request and refers to the new resource, and
     954         a Location header field (see <a href="#header.location" id="rfc.xref.header.location.1" title="Location">Section&nbsp;7.5</a>).
     955      </p>
     956      <p id="rfc.section.2.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 2.3.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 Content-Location header field (see <a href="p3-payload.html#header.content-location" title="Content-Location">Section 6.7</a> of <a href="#Part3" id="rfc.xref.Part3.1"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>) whose value is the effective Request URI <em class="bcp14">MAY</em> be used to satisfy subsequent GET and HEAD requests.
     957      </p>
     958      <p id="rfc.section.2.3.4.p.6">Note that POST caching is not widely implemented. However, the 303 (See Other) response can be used to direct the user agent
     959         to retrieve a cacheable representation of the resource.
     960      </p>
     961      <div id="rfc.iref.p.2"></div>
     962      <div id="rfc.iref.m.5"></div>
     963      <h3 id="rfc.section.2.3.5"><a href="#rfc.section.2.3.5">2.3.5</a>&nbsp;<a id="PUT" href="#PUT">PUT</a></h3>
     964      <p id="rfc.section.2.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
     965         enclosed in the request message payload. A successful PUT of a given representation would suggest that a subsequent GET on
     966         that same target resource will result in an equivalent representation being returned in a 200 (OK) response. However, there
     967         is no guarantee that such a state change will be observable, since the target resource might be acted upon by other user agents
     968         in parallel, or might be subject to dynamic processing by the origin server, before any subsequent GET is received. A successful
     969         response only implies that the user agent's intent was achieved at the time of its processing by the origin server.
     970      </p>
     971      <p id="rfc.section.2.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 201 (Created) response. If the target resource does have a current representation and that
     972         representation is successfully modified in accordance with the state of the enclosed representation, then either a 200 (OK)
     973         or 204 (No Content) response <em class="bcp14">SHOULD</em> be sent to indicate successful completion of the request.
     974      </p>
     975      <p id="rfc.section.2.3.5.p.3">Unrecognized header fields <em class="bcp14">SHOULD</em> be ignored (i.e., not saved as part of the resource state).
     976      </p>
     977      <p id="rfc.section.2.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
     978         or will not be changed by the PUT. This is particularly important when the origin server uses internal configuration information
     979         related to the URI in order to set the values for representation metadata on GET responses. When a PUT representation is inconsistent
     980         with the target resource, the origin server <em class="bcp14">SHOULD</em> either make them consistent, by transforming the representation or changing the resource configuration, or respond with an
     981         appropriate error message containing sufficient information to explain why the representation is unsuitable. The 409 (Conflict)
     982         or 415 (Unsupported Media Type) status codes are suggested, with the latter being specific to constraints on Content-Type
     983         values.
     984      </p>
     985      <p id="rfc.section.2.3.5.p.5">For example, if the target resource is configured to always have a Content-Type of "text/html" and the representation being
     986         PUT has a Content-Type of "image/jpeg", then the origin server <em class="bcp14">SHOULD</em> do one of: (a) reconfigure the target resource to reflect the new media type; (b) transform the PUT representation to a format
     987         consistent with that of the resource before saving it as the new resource state; or, (c) reject the request with a 415 response
     988         indicating that the target resource is limited to "text/html", perhaps including a link to a different resource that would
     989         be a suitable target for the new representation.
     990      </p>
     991      <p id="rfc.section.2.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
     992         of the user agent request and the semantics of the origin server response. It does not define what a resource might be, in
     993         any sense of that word, beyond the interface provided via HTTP. It does not define how resource state is "stored", nor how
     994         such storage might change as a result of a change in resource state, nor how the origin server translates resource state into
     995         representations. Generally speaking, all implementation details behind the resource interface are intentionally hidden by
     996         the server.
     997      </p>
     998      <p id="rfc.section.2.3.5.p.7">The fundamental difference between the POST and PUT methods is highlighted by the different intent for the target resource.
     999         The target resource in a POST request is intended to handle the enclosed representation as a data-accepting process, such
     1000         as for a gateway to some other protocol or a document that accepts annotations. In contrast, the target resource in a PUT
     1001         request is intended to take the enclosed representation as a new or replacement value. Hence, the intent of PUT is idempotent
     1002         and visible to intermediaries, even though the exact effect is only known by the origin server.
     1003      </p>
     1004      <p id="rfc.section.2.3.5.p.8">Proper interpretation of a PUT request presumes that the user agent knows what target resource is desired. A service that
     1005         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
     1006         the target resource and instead wishes to have it applied to a different resource, such as when the resource has been moved
     1007         to a different URI, then the origin server <em class="bcp14">MUST</em> send a 301 (Moved Permanently) response; the user agent <em class="bcp14">MAY</em> then make its own decision regarding whether or not to redirect the request.
     1008      </p>
     1009      <p id="rfc.section.2.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)
     1010         which is separate from the URIs identifying each particular version (different resources that at one point shared the same
     1011         state as the current version resource). A successful PUT request on "the current version" URI might therefore create a new
     1012         version resource in addition to changing the state of the target resource, and might also cause links to be added between
     1013         the related resources.
     1014      </p>
     1015      <p id="rfc.section.2.3.5.p.10">An origin server <em class="bcp14">SHOULD</em> reject any PUT request that contains a Content-Range header field, since it might be misinterpreted as partial content (or
     1016         might be partial content that is being mistakenly PUT as a full representation). Partial content updates are possible by targeting
     1017         a separately identified resource with state that overlaps a portion of the larger resource, or by using a different method
     1018         that has been specifically defined for partial updates (for example, the PATCH method defined in <a href="#RFC5789" id="rfc.xref.RFC5789.1"><cite title="PATCH Method for HTTP">[RFC5789]</cite></a>).
     1019      </p>
     1020      <p id="rfc.section.2.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
     1021         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 2.6</a> of <a href="#Part6" id="rfc.xref.Part6.5"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>).
     1022      </p>
     1023      <div id="rfc.iref.d.1"></div>
     1024      <div id="rfc.iref.m.6"></div>
     1025      <h3 id="rfc.section.2.3.6"><a href="#rfc.section.2.3.6">2.3.6</a>&nbsp;<a id="DELETE" href="#DELETE">DELETE</a></h3>
     1026      <p id="rfc.section.2.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
     1027         has been carried out, even if the status code returned from the origin server indicates that the action has been completed
     1028         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
     1029         location.
     1030      </p>
     1031      <p id="rfc.section.2.3.6.p.2">A successful response <em class="bcp14">SHOULD</em> be 200 (OK) if the response includes an representation describing the status, 202 (Accepted) if the action has not yet been
     1032         enacted, or 204 (No Content) if the action has been enacted but the response does not include a representation.
     1033      </p>
     1034      <p id="rfc.section.2.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
     1035         implementations to reject the request.
     1036      </p>
     1037      <p id="rfc.section.2.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
     1038         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 2.6</a> of <a href="#Part6" id="rfc.xref.Part6.6"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>).
     1039      </p>
     1040      <h3 id="rfc.section.2.3.7"><a href="#rfc.section.2.3.7">2.3.7</a>&nbsp;<a id="TRACE" href="#TRACE">TRACE</a></h3>
     1041      <div id="rfc.iref.t.1"></div>
     1042      <div id="rfc.iref.m.7"></div>
     1043      <p id="rfc.section.2.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 200 (OK) response. The final recipient is either
     1044         the origin server or the first proxy to receive a Max-Forwards value of zero (0) in the request (see <a href="#header.max-forwards" id="rfc.xref.header.max-forwards.2" title="Max-Forwards">Section&nbsp;7.6</a>). A TRACE request <em class="bcp14">MUST NOT</em> include a message body.
     1045      </p>
     1046      <p id="rfc.section.2.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
     1047         or diagnostic information. The value of the Via header field (<a href="p1-messaging.html#header.via" title="Via">Section 6.2</a> of <a href="#Part1" id="rfc.xref.Part1.18"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) is of particular interest, since it acts as a trace of the request chain. Use of the Max-Forwards header field allows the
     1048         client to limit the length of the request chain, which is useful for testing a chain of proxies forwarding messages in an
     1049         infinite loop.
     1050      </p>
     1051      <p id="rfc.section.2.3.7.p.3">If the request is valid, the response <em class="bcp14">SHOULD</em> have a Content-Type 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.19"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[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.
     1052      </p>
     1053      <div id="rfc.iref.c.1"></div>
     1054      <div id="rfc.iref.m.8"></div>
     1055      <h3 id="rfc.section.2.3.8"><a href="#rfc.section.2.3.8">2.3.8</a>&nbsp;<a id="CONNECT" href="#CONNECT">CONNECT</a></h3>
     1056      <p id="rfc.section.2.3.8.p.1">The CONNECT method requests that the proxy establish a tunnel to the request-target and, if successful, thereafter restrict
     1057         its behavior to blind forwarding of packets until the connection is closed.
     1058      </p>
     1059      <p id="rfc.section.2.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.20"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>); i.e., the request-target consists of only the host name and port number of the tunnel destination, separated by a colon.
     1060         For example,
     1061      </p>
     1062      <div id="rfc.figure.u.4"></div><pre class="text2">CONNECT server.example.com:80 HTTP/1.1
     1063Host: server.example.com:80
     1064
     1065</pre><p id="rfc.section.2.3.8.p.4">Any successful (2xx) response to a CONNECT request indicates that the proxy has established a connection to the requested
     1066         host and port, and has switched to tunneling the current connection to that server connection. The tunneled data from the
     1067         server begins immediately after the blank line that concludes the successful response's header block. A server <em class="bcp14">SHOULD NOT</em> send any Transfer-Encoding or Content-Length 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.
     1068      </p>
     1069      <p id="rfc.section.2.3.8.p.5">Any response other than a successful response indicates that the tunnel has not yet been formed and that the connection remains
     1070         governed by HTTP.
     1071      </p>
     1072      <p id="rfc.section.2.3.8.p.6">Proxy authentication might be used to establish the authority to create a tunnel:</p>
     1073      <div id="rfc.figure.u.5"></div><pre class="text2">CONNECT server.example.com:80 HTTP/1.1
     1074Host: server.example.com:80
     1075Proxy-Authorization: basic aGVsbG86d29ybGQ=
     1076
     1077</pre><p id="rfc.section.2.3.8.p.8">A message body on a CONNECT request has no defined semantics. Sending a body on a CONNECT request might cause existing implementations
     1078         to reject the request.
     1079      </p>
     1080      <p id="rfc.section.2.3.8.p.9">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 may be discarded
     1081         if the eventual response is negative, and the connection may be reset with no response if more than one TCP segment is outstanding.
     1082      </p>
     1083      <p id="rfc.section.2.3.8.p.10">It may be the case that the proxy itself can only reach the requested origin server through another proxy. In this case, the
     1084         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 2xx status code unless it has either a direct or tunnel connection established to the authority.
     1085      </p>
     1086      <p id="rfc.section.2.3.8.p.11">If at any point either one of the peers gets disconnected, any outstanding data that came from that peer will be passed to
     1087         the other one, and after that also the other connection will be terminated by the proxy. If there is outstanding data to that
     1088         peer undelivered, that data will be discarded.
     1089      </p>
     1090      <p id="rfc.section.2.3.8.p.12">An origin server which receives a CONNECT request for itself <em class="bcp14">MAY</em> respond with a 2xx status code to indicate that a connection is established. However, most origin servers do not implement
     1091         CONNECT.
    9001092      </p>
    9011093      <h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a>&nbsp;<a id="header.fields" href="#header.fields">Header Fields</a></h1>
    9021094      <p id="rfc.section.3.p.1">Header fields are key value pairs that can be used to communicate data about the message, its payload, the target resource,
    903          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.17"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for a general definition of their syntax.
     1095         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.21"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for a general definition of their syntax.
    9041096      </p>
    9051097      <h2 id="rfc.section.3.1"><a href="#rfc.section.3.1">3.1</a>&nbsp;<a id="considerations.for.creating.header.fields" href="#considerations.for.creating.header.fields">Considerations for Creating Header Fields</a></h2>
    … …  
    9091101         with "X-" if they are to be registered (either immediately or in the future).
    9101102      </p>
    911       <p id="rfc.section.3.1.p.3">New header field values typically have their syntax defined using ABNF (<a href="#RFC5234" id="rfc.xref.RFC5234.3"><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">Section 3.2.5</a> of <a href="#Part1" id="rfc.xref.Part1.18"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> as necessary, and are usually constrained to the range of ASCII characters. Header fields needing a greater range of characters
     1103      <p id="rfc.section.3.1.p.3">New header field values typically have their syntax defined using ABNF (<a href="#RFC5234" id="rfc.xref.RFC5234.3"><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">Section 3.2.5</a> of <a href="#Part1" id="rfc.xref.Part1.22"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> as necessary, and are usually constrained to the range of ASCII characters. Header fields needing a greater range of characters
    9121104         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>.
    9131105      </p>
    9141106      <p id="rfc.section.3.1.p.4">Because commas (",") are used as a generic delimiter between field-values, they need to be treated with care if they are allowed
    9151107         in the field-value's payload. Typically, components that might contain a comma are protected with double-quotes using the
    916          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.19"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).
     1108         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.23"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).
    9171109      </p>
    9181110      <p id="rfc.section.3.1.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
    9191111         these:
    9201112      </p>
    921       <div id="rfc.figure.u.4"></div><pre class="text">  Example-URI-Field: "http://example.com/a.html,foo",
     1113      <div id="rfc.figure.u.6"></div><pre class="text">  Example-URI-Field: "http://example.com/a.html,foo",
    9221114                     "http://without-a-comma.example.com/"
    9231115  Example-Date-Field: "Sat, 04 May 1996", "Wed, 14 Sep 2005"
    … …  
    9251117         double quotes will likely cause unnecessary confusion.
    9261118      </p>
    927       <p id="rfc.section.3.1.p.8">Many header fields use a format including (case-insensitively) named parameters (for instance, Content-Type, defined in <a href="p3-payload.html#header.content-type" title="Content-Type">Section 6.8</a> of <a href="#Part3" id="rfc.xref.Part3.1"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>). Allowing both unquoted (token) and quoted (quoted-string) syntax for the parameter value enables recipients to use existing
     1119      <p id="rfc.section.3.1.p.8">Many header fields use a format including (case-insensitively) named parameters (for instance, Content-Type, defined in <a href="p3-payload.html#header.content-type" title="Content-Type">Section 6.8</a> of <a href="#Part3" id="rfc.xref.Part3.2"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>). Allowing both unquoted (token) and quoted (quoted-string) syntax for the parameter value enables recipients to use existing
    9281120         parser components. When allowing both forms, the meaning of a parameter value ought to be independent of the syntax used for
    929          it (for an example, see the notes on parameter handling for media types in <a href="p3-payload.html#media.types" title="Media Types">Section 2.3</a> of <a href="#Part3" id="rfc.xref.Part3.2"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>).
     1121         it (for an example, see the notes on parameter handling for media types in <a href="p3-payload.html#media.types" title="Media Types">Section 2.3</a> of <a href="#Part3" id="rfc.xref.Part3.3"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>).
    9301122      </p>
    9311123      <p id="rfc.section.3.1.p.9">Authors of specifications defining new header fields are advised to consider documenting: </p>
    9321124      <ul>
    9331125         <li>
    934             <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.20"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).
     1126            <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.24"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).
    9351127            </p>
    9361128            <p>If it does not use the list syntax, document how to treat messages where the header field occurs multiple times (a sensible
    … …  
    9481140         </li>
    9491141         <li>
    950             <p>Whether it is appropriate to list the field-name in the Connection header (i.e., if the header 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.21"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).
     1142            <p>Whether it is appropriate to list the field-name in the Connection header (i.e., if the header 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.25"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).
    9511143            </p>
    9521144         </li>
    … …  
    9551147         </li>
    9561148         <li>
    957             <p>How the header might interact with caching (see <a href="#Part6" id="rfc.xref.Part6.2"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>).
     1149            <p>How the header might interact with caching (see <a href="#Part6" id="rfc.xref.Part6.7"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>).
    9581150            </p>
    9591151         </li>
    9601152         <li>
    961             <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.22"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).
     1153            <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.26"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).
    9621154            </p>
    9631155         </li>
    … …  
    9711163         method invocation.
    9721164      </p>
    973       <div id="rfc.table.u.2">
     1165      <div id="rfc.table.u.1">
    9741166         <table class="tt full left" cellpadding="3" cellspacing="0">
    9751167            <thead>
    … …  
    9821174               <tr>
    9831175                  <td class="left">Accept</td>
    984                   <td class="left"><a href="p3-payload.html#header.accept" title="Accept">Section 6.1</a> of <a href="#Part3" id="rfc.xref.Part3.3"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a></td>
     1176                  <td class="left"><a href="p3-payload.html#header.accept" title="Accept">Section 6.1</a> of <a href="#Part3" id="rfc.xref.Part3.4"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a></td>
    9851177               </tr>
    9861178               <tr>
    9871179                  <td class="left">Accept-Charset</td>
    988                   <td class="left"><a href="p3-payload.html#header.accept-charset" title="Accept-Charset">Section 6.2</a> of <a href="#Part3" id="rfc.xref.Part3.4"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a></td>
     1180                  <td class="left"><a href="p3-payload.html#header.accept-charset" title="Accept-Charset">Section 6.2</a> of <a href="#Part3" id="rfc.xref.Part3.5"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a></td>
    9891181               </tr>
    9901182               <tr>
    9911183                  <td class="left">Accept-Encoding</td>
    992                   <td class="left"><a href="p3-payload.html#header.accept-encoding" title="Accept-Encoding">Section 6.3</a> of <a href="#Part3" id="rfc.xref.Part3.5"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a></td>
     1184                  <td class="left"><a href="p3-payload.html#header.accept-encoding" title="Accept-Encoding">Section 6.3</a> of <a href="#Part3" id="rfc.xref.Part3.6"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a></td>
    9931185               </tr>
    9941186               <tr>
    9951187                  <td class="left">Accept-Language</td>
    996                   <td class="left"><a href="p3-payload.html#header.accept-language" title="Accept-Language">Section 6.4</a> of <a href="#Part3" id="rfc.xref.Part3.6"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a></td>
     1188                  <td class="left"><a href="p3-payload.html#header.accept-language" title="Accept-Language">Section 6.4</a> of <a href="#Part3" id="rfc.xref.Part3.7"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a></td>
    9971189               </tr>
    9981190               <tr>
    … …  
    10021194               <tr>
    10031195                  <td class="left">Expect</td>
    1004                   <td class="left"><a href="#header.expect" id="rfc.xref.header.expect.1" title="Expect">Section&nbsp;8.3</a></td>
     1196                  <td class="left"><a href="#header.expect" id="rfc.xref.header.expect.1" title="Expect">Section&nbsp;7.3</a></td>
    10051197               </tr>
    10061198               <tr>
    10071199                  <td class="left">From</td>
    1008                   <td class="left"><a href="#header.from" id="rfc.xref.header.from.1" title="From">Section&nbsp;8.4</a></td>
     1200                  <td class="left"><a href="#header.from" id="rfc.xref.header.from.1" title="From">Section&nbsp;7.4</a></td>
    10091201               </tr>
    10101202               <tr>
    10111203                  <td class="left">Host</td>
    1012                   <td class="left"><a href="p1-messaging.html#header.host" title="Host">Section 5.4</a> of <a href="#Part1" id="rfc.xref.Part1.23"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a></td>
     1204                  <td class="left"><a href="p1-messaging.html#header.host" title="Host">Section 5.4</a> of <a href="#Part1" id="rfc.xref.Part1.27"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a></td>
    10131205               </tr>
    10141206               <tr>
    … …  
    10261218               <tr>
    10271219                  <td class="left">If-Range</td>
    1028                   <td class="left"><a href="p5-range.html#header.if-range" title="If-Range">Section 5.3</a> of <a href="#Part5" id="rfc.xref.Part5.1"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a></td>
     1220                  <td class="left"><a href="p5-range.html#header.if-range" title="If-Range">Section 5.3</a> of <a href="#Part5" id="rfc.xref.Part5.2"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a></td>
    10291221               </tr>
    10301222               <tr>
    … …  
    10341226               <tr>
    10351227                  <td class="left">Max-Forwards</td>
    1036                   <td class="left"><a href="#header.max-forwards" id="rfc.xref.header.max-forwards.1" title="Max-Forwards">Section&nbsp;8.6</a></td>
     1228                  <td class="left"><a href="#header.max-forwards" id="rfc.xref.header.max-forwards.3" title="Max-Forwards">Section&nbsp;7.6</a></td>
    10371229               </tr>
    10381230               <tr>
    … …  
    10421234               <tr>
    10431235                  <td class="left">Range</td>
    1044                   <td class="left"><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 and Partial Responses">[Part5]</cite></a></td>
     1236                  <td class="left"><a href="p5-range.html#header.range" title="Range">Section 5.4</a> of <a href="#Part5" id="rfc.xref.Part5.3"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a></td>
    10451237               </tr>
    10461238               <tr>
    10471239                  <td class="left">Referer</td>
    1048                   <td class="left"><a href="#header.referer" id="rfc.xref.header.referer.1" title="Referer">Section&nbsp;8.7</a></td>
     1240                  <td class="left"><a href="#header.referer" id="rfc.xref.header.referer.1" title="Referer">Section&nbsp;7.7</a></td>
    10491241               </tr>
    10501242               <tr>
    10511243                  <td class="left">TE</td>
    1052                   <td class="left"><a href="p1-messaging.html#header.te" title="TE">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.24"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a></td>
     1244                  <td class="left"><a href="p1-messaging.html#header.te" title="TE">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.28"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a></td>
    10531245               </tr>
    10541246               <tr>
    10551247                  <td class="left">User-Agent</td>
    1056                   <td class="left"><a href="#header.user-agent" id="rfc.xref.header.user-agent.1" title="User-Agent">Section&nbsp;8.10</a></td>
     1248                  <td class="left"><a href="#header.user-agent" id="rfc.xref.header.user-agent.1" title="User-Agent">Section&nbsp;7.10</a></td>
    10571249               </tr>
    10581250            </tbody>
    … …  
    10611253      <h2 id="rfc.section.3.3"><a href="#rfc.section.3.3">3.3</a>&nbsp;<a id="response.header.fields" href="#response.header.fields">Response Header Fields</a></h2>
    10621254      <p id="rfc.section.3.3.p.1">The response header fields allow the server to pass additional information about the response which cannot be placed in the
    1063          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.25"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).
    1064       </p>
    1065       <div id="rfc.table.u.3">
     1255         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.29"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).
     1256      </p>
     1257      <div id="rfc.table.u.2">
    10661258         <table class="tt full left" cellpadding="3" cellspacing="0">
    10671259            <thead>
    … …  
    10741266               <tr>
    10751267                  <td class="left">Accept-Ranges</td>
    1076                   <td class="left"><a href="p5-range.html#header.accept-ranges" title="Accept-Ranges">Section 5.1</a> of <a href="#Part5" id="rfc.xref.Part5.3"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a></td>
     1268                  <td class="left"><a href="p5-range.html#header.accept-ranges" title="Accept-Ranges">Section 5.1</a> of <a href="#Part5" id="rfc.xref.Part5.4"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a></td>
    10771269               </tr>
    10781270               <tr>
    10791271                  <td class="left">Age</td>
    1080                   <td class="left"><a href="p6-cache.html#header.age" title="Age">Section 3.1</a> of <a href="#Part6" id="rfc.xref.Part6.3"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a></td>
     1272                  <td class="left"><a href="p6-cache.html#header.age" title="Age">Section 3.1</a> of <a href="#Part6" id="rfc.xref.Part6.8"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a></td>
    10811273               </tr>
    10821274               <tr>
    10831275                  <td class="left">Allow</td>
    1084                   <td class="left"><a href="#header.allow" id="rfc.xref.header.allow.2" title="Allow">Section&nbsp;8.1</a></td>
     1276                  <td class="left"><a href="#header.allow" id="rfc.xref.header.allow.2" title="Allow">Section&nbsp;7.1</a></td>
    10851277               </tr>
    10861278               <tr>
    10871279                  <td class="left">Date</td>
    1088                   <td class="left"><a href="#header.date" id="rfc.xref.header.date.1" title="Date">Section&nbsp;8.2</a></td>
     1280                  <td class="left"><a href="#header.date" id="rfc.xref.header.date.1" title="Date">Section&nbsp;7.2</a></td>
    10891281               </tr>
    10901282               <tr>
    … …  
    10941286               <tr>
    10951287                  <td class="left">Location</td>
    1096                   <td class="left"><a href="#header.location" id="rfc.xref.header.location.1" title="Location">Section&nbsp;8.5</a></td>
     1288                  <td class="left"><a href="#header.location" id="rfc.xref.header.location.2" title="Location">Section&nbsp;7.5</a></td>
    10971289               </tr>
    10981290               <tr>
    … …  
    11021294               <tr>
    11031295                  <td class="left">Retry-After</td>
    1104                   <td class="left"><a href="#header.retry-after" id="rfc.xref.header.retry-after.1" title="Retry-After">Section&nbsp;8.8</a></td>
     1296                  <td class="left"><a href="#header.retry-after" id="rfc.xref.header.retry-after.1" title="Retry-After">Section&nbsp;7.8</a></td>
    11051297               </tr>
    11061298               <tr>
    11071299                  <td class="left">Server</td>
    1108                   <td class="left"><a href="#header.server" id="rfc.xref.header.server.1" title="Server">Section&nbsp;8.9</a></td>
     1300                  <td class="left"><a href="#header.server" id="rfc.xref.header.server.1" title="Server">Section&nbsp;7.9</a></td>
    11091301               </tr>
    11101302               <tr>
    11111303                  <td class="left">Vary</td>
    1112                   <td class="left"><a href="p6-cache.html#header.vary" title="Vary">Section 3.5</a> of <a href="#Part6" id="rfc.xref.Part6.4"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a></td>
     1304                  <td class="left"><a href="p6-cache.html#header.vary" title="Vary">Section 3.5</a> of <a href="#Part6" id="rfc.xref.Part6.9"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a></td>
    11131305               </tr>
    11141306               <tr>
    … …  
    11241316         client does not need to examine or display the reason-phrase.
    11251317      </p>
    1126       <div id="rfc.figure.u.5"></div><pre class="inline"><span id="rfc.iref.g.2"></span><span id="rfc.iref.g.3"></span><span id="rfc.iref.g.4"></span>  <a href="#status.code.and.reason.phrase" class="smpl">status-code</a>    = 3<a href="#notation" class="smpl">DIGIT</a>
     1318      <div id="rfc.figure.u.7"></div><pre class="inline"><span id="rfc.iref.g.3"></span><span id="rfc.iref.g.4"></span><span id="rfc.iref.g.5"></span>  <a href="#status.code.and.reason.phrase" class="smpl">status-code</a>    = 3<a href="#notation" class="smpl">DIGIT</a>
    11271319  <a href="#status.code.and.reason.phrase" class="smpl">reason-phrase</a>  = *( <a href="#notation" class="smpl">HTAB</a> / <a href="#notation" class="smpl">SP</a> / <a href="#notation" class="smpl">VCHAR</a> / <a href="#core.rules" class="smpl">obs-text</a> )
    11281320</pre><p id="rfc.section.4.p.4">HTTP status codes are extensible. HTTP applications are not required to understand the meaning of all registered status codes,
    … …  
    11431335      </ul>
    11441336      <h2 id="rfc.section.4.1"><a href="#rfc.section.4.1">4.1</a>&nbsp;<a id="overview.of.status.codes" href="#overview.of.status.codes">Overview of Status Codes</a></h2>
    1145       <p id="rfc.section.4.1.p.1">The status codes listed below are defined in <a href="#status.codes" title="Status Code Definitions">Section&nbsp;4.3</a> of this specification, <a href="p4-conditional.html#status.code.definitions" title="Status Code Definitions">Section 4</a> of <a href="#Part4" id="rfc.xref.Part4.6"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>, <a href="p5-range.html#status.code.definitions" title="Status Code Definitions">Section 3</a> of <a href="#Part5" id="rfc.xref.Part5.4"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>, and <a href="p7-auth.html#status.code.definitions" title="Status Code Definitions">Section 3</a> of <a href="#Part7" id="rfc.xref.Part7.5"><cite title="HTTP/1.1, part 7: Authentication">[Part7]</cite></a>. The reason phrases listed here are only recommendations — they can be replaced by local equivalents without affecting the
     1337      <p id="rfc.section.4.1.p.1">The status codes listed below are defined in <a href="#status.codes" title="Status Code Definitions">Section&nbsp;4.3</a> of this specification, <a href="p4-conditional.html#status.code.definitions" title="Status Code Definitions">Section 4</a> of <a href="#Part4" id="rfc.xref.Part4.6"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>, <a href="p5-range.html#status.code.definitions" title="Status Code Definitions">Section 3</a> of <a href="#Part5" id="rfc.xref.Part5.5"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>, and <a href="p7-auth.html#status.code.definitions" title="Status Code Definitions">Section 3</a> of <a href="#Part7" id="rfc.xref.Part7.5"><cite title="HTTP/1.1, part 7: Authentication">[Part7]</cite></a>. The reason phrases listed here are only recommendations — they can be replaced by local equivalents without affecting the
    11461338         protocol.
    11471339      </p>
    1148       <div id="rfc.table.u.4">
     1340      <div id="rfc.table.u.3">
    11491341         <table class="tt full left" cellpadding="3" cellspacing="0">
    11501342            <thead>
    … …  
    11991391                  <td class="left">206</td>
    12001392                  <td class="left">Partial Content</td>
    1201                   <td id="status.206" class="left"><a href="p5-range.html#status.206" title="206 Partial Content">Section 3.1</a> of <a href="#Part5" id="rfc.xref.Part5.5"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a></td>
     1393                  <td id="status.206" class="left"><a href="p5-range.html#status.206" title="206 Partial Content">Section 3.1</a> of <a href="#Part5" id="rfc.xref.Part5.6"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a></td>
    12021394               </tr>
    12031395               <tr>
    … …  
    13191511                  <td class="left">416</td>
    13201512                  <td class="left">Requested range not satisfiable</td>
    1321                   <td id="status.416" class="left"><a href="p5-range.html#status.416" title="416 Requested Range Not Satisfiable">Section 3.2</a> of <a href="#Part5" id="rfc.xref.Part5.6"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a></td>
     1513                  <td id="status.416" class="left"><a href="p5-range.html#status.416" title="416 Requested Range Not Satisfiable">Section 3.2</a> of <a href="#Part5" id="rfc.xref.Part5.7"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a></td>
    13221514               </tr>
    13231515               <tr>
    … …  
    13861578         a zero-length response body. They can require the presence of one or more particular HTTP response header(s).
    13871579      </p>
    1388       <p id="rfc.section.4.2.1.p.5">Likewise, their definitions can specify that caches are allowed to use heuristics to determine their freshness (see <a href="#Part6" id="rfc.xref.Part6.5"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>; by default, it is not allowed), and can define how to determine the resource which they carry a representation for (see <a href="#identifying.response.associated.with.representation" title="Identifying the Resource Associated with a Representation">Section&nbsp;5.1</a>; by default, it is anonymous).
     1580      <p id="rfc.section.4.2.1.p.5">Likewise, their definitions can specify that caches are allowed to use heuristics to determine their freshness (see <a href="#Part6" id="rfc.xref.Part6.10"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>; by default, it is not allowed), and can define how to determine the resource which they carry a representation for (see <a href="#identifying.response.associated.with.representation" title="Identifying the Resource Associated with a Representation">Section&nbsp;5.1</a>; by default, it is anonymous).
    13891581      </p>
    13901582      <h2 id="rfc.section.4.3"><a href="#rfc.section.4.3">4.3</a>&nbsp;<a id="status.codes" href="#status.codes">Status Code Definitions</a></h2>
    13911583      <p id="rfc.section.4.3.p.1">Each status-code is described below, including any metadata required in the response.</p>
    13921584      <p id="rfc.section.4.3.p.2">For most status codes the response can carry a payload, in which case a Content-Type header field indicates the payload's
    1393          media type (<a href="p3-payload.html#header.content-type" title="Content-Type">Section 6.8</a> of <a href="#Part3" id="rfc.xref.Part3.7"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>).
     1585         media type (<a href="p3-payload.html#header.content-type" title="Content-Type">Section 6.8</a> of <a href="#Part3" id="rfc.xref.Part3.8"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>).
    13941586      </p>
    13951587      <h3 id="rfc.section.4.3.1"><a href="#rfc.section.4.3.1">4.3.1</a>&nbsp;<a id="status.1xx" href="#status.1xx">Informational 1xx</a></h3>
    … …  
    14051597         a request, then it need not forward the corresponding 100 (Continue) response(s).)
    14061598      </p>
    1407       <div id="rfc.iref.4"></div>
    1408       <div id="rfc.iref.s.1"></div>
     1599      <div id="rfc.iref.22"></div>
     1600      <div id="rfc.iref.s.2"></div>
    14091601      <h4 id="rfc.section.4.3.1.1"><a href="#rfc.section.4.3.1.1">4.3.1.1</a>&nbsp;<a id="status.100" href="#status.100">100 Continue</a></h4>
    14101602      <p id="rfc.section.4.3.1.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
    14111603         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
    1412          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.4.3</a> of <a href="#Part1" id="rfc.xref.Part1.26"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for detailed discussion of the use and handling of this status code.
    1413       </p>
    1414       <div id="rfc.iref.5"></div>
    1415       <div id="rfc.iref.s.2"></div>
     1604         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.4.3</a> of <a href="#Part1" id="rfc.xref.Part1.30"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for detailed discussion of the use and handling of this status code.
     1605      </p>
     1606      <div id="rfc.iref.23"></div>
     1607      <div id="rfc.iref.s.3"></div>
    14161608      <h4 id="rfc.section.4.3.1.2"><a href="#rfc.section.4.3.1.2">4.3.1.2</a>&nbsp;<a id="status.101" href="#status.101">101 Switching Protocols</a></h4>
    1417       <p id="rfc.section.4.3.1.2.p.1">The server understands and is willing to comply with the client's request, via the Upgrade message header field (<a href="p1-messaging.html#header.upgrade" title="Upgrade">Section 6.5</a> of <a href="#Part1" id="rfc.xref.Part1.27"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>), for a change in the application protocol being used on this connection. The server will switch protocols to those defined
     1609      <p id="rfc.section.4.3.1.2.p.1">The server understands and is willing to comply with the client's request, via the Upgrade message header field (<a href="p1-messaging.html#header.upgrade" title="Upgrade">Section 6.5</a> of <a href="#Part1" id="rfc.xref.Part1.31"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>), for a change in the application protocol being used on this connection. The server will switch protocols to those defined
    14181610         by the response's Upgrade header field immediately after the empty line which terminates the 101 response.
    14191611      </p>
    … …  
    14241616      <h3 id="rfc.section.4.3.2"><a href="#rfc.section.4.3.2">4.3.2</a>&nbsp;<a id="status.2xx" href="#status.2xx">Successful 2xx</a></h3>
    14251617      <p id="rfc.section.4.3.2.p.1">This class of status code indicates that the client's request was successfully received, understood, and accepted.</p>
    1426       <div id="rfc.iref.6"></div>
    1427       <div id="rfc.iref.s.3"></div>
     1618      <div id="rfc.iref.24"></div>
     1619      <div id="rfc.iref.s.4"></div>
    14281620      <h4 id="rfc.section.4.3.2.1"><a href="#rfc.section.4.3.2.1">4.3.2.1</a>&nbsp;<a id="status.200" href="#status.200">200 OK</a></h4>
    14291621      <p id="rfc.section.4.3.2.1.p.1">The request has succeeded. The payload returned with the response is dependent on the method used in the request, for example: </p>
    … …  
    14381630         <dd>a representation containing the request message as received by the end server.</dd>
    14391631      </dl>
    1440       <p id="rfc.section.4.3.2.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 2.3.1.1</a> of <a href="#Part6" id="rfc.xref.Part6.6"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) to determine freshness for 200 responses.
    1441       </p>
    1442       <div id="rfc.iref.7"></div>
    1443       <div id="rfc.iref.s.4"></div>
     1632      <p id="rfc.section.4.3.2.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 2.3.1.1</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.
     1633      </p>
     1634      <div id="rfc.iref.25"></div>
     1635      <div id="rfc.iref.s.5"></div>
    14441636      <h4 id="rfc.section.4.3.2.2"><a href="#rfc.section.4.3.2.2">4.3.2.2</a>&nbsp;<a id="status.201" href="#status.201">201 Created</a></h4>
    14451637      <p id="rfc.section.4.3.2.2.p.1">The request has been fulfilled and has resulted in a new resource being created.</p>
    … …  
    14531645         just created (see <a href="p4-conditional.html#header.etag" title="ETag">Section 2.3</a> of <a href="#Part4" id="rfc.xref.Part4.9"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>).
    14541646      </p>
    1455       <div id="rfc.iref.8"></div>
    1456       <div id="rfc.iref.s.5"></div>
     1647      <div id="rfc.iref.26"></div>
     1648      <div id="rfc.iref.s.6"></div>
    14571649      <h4 id="rfc.section.4.3.2.3"><a href="#rfc.section.4.3.2.3">4.3.2.3</a>&nbsp;<a id="status.202" href="#status.202">202 Accepted</a></h4>
    14581650      <p id="rfc.section.4.3.2.3.p.1">The request has been accepted for processing, but the processing has not been completed. The request might or might not eventually
    … …  
    14651657         user can expect the request to be fulfilled.
    14661658      </p>
    1467       <div id="rfc.iref.9"></div>
    1468       <div id="rfc.iref.s.6"></div>
     1659      <div id="rfc.iref.27"></div>
     1660      <div id="rfc.iref.s.7"></div>
    14691661      <h4 id="rfc.section.4.3.2.4"><a href="#rfc.section.4.3.2.4">4.3.2.4</a>&nbsp;<a id="status.203" href="#status.203">203 Non-Authoritative Information</a></h4>
    1470       <p id="rfc.section.4.3.2.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.28"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[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 3.2</a> of <a href="#Part6" id="rfc.xref.Part6.7"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>).
     1662      <p id="rfc.section.4.3.2.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.32"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[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 3.2</a> of <a href="#Part6" id="rfc.xref.Part6.12"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>).
    14711663      </p>
    14721664      <p id="rfc.section.4.3.2.4.p.2">This status code is only appropriate when the response status code would have been 200 (OK) otherwise. When the status code
    1473          before transformation would have been different, the 214 Transformation Applied warn-code (<a href="p6-cache.html#header.warning" title="Warning">Section 3.6</a> of <a href="#Part6" id="rfc.xref.Part6.8"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) is appropriate.
    1474       </p>
    1475       <p id="rfc.section.4.3.2.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 2.3.1.1</a> of <a href="#Part6" id="rfc.xref.Part6.9"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) to determine freshness for 203 responses.
    1476       </p>
    1477       <div id="rfc.iref.10"></div>
    1478       <div id="rfc.iref.s.7"></div>
     1665         before transformation would have been different, the 214 Transformation Applied warn-code (<a href="p6-cache.html#header.warning" title="Warning">Section 3.6</a> of <a href="#Part6" id="rfc.xref.Part6.13"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) is appropriate.
     1666      </p>
     1667      <p id="rfc.section.4.3.2.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 2.3.1.1</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.
     1668      </p>
     1669      <div id="rfc.iref.28"></div>
     1670      <div id="rfc.iref.s.8"></div>
    14791671      <h4 id="rfc.section.4.3.2.5"><a href="#rfc.section.4.3.2.5">4.3.2.5</a>&nbsp;<a id="status.204" href="#status.204">204 No Content</a></h4>
    14801672      <p id="rfc.section.4.3.2.5.p.1">The 204 (No Content) status code indicates that the server has successfully fulfilled the request and that there is no additional
    … …  
    14961688      <p id="rfc.section.4.3.2.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.
    14971689      </p>
    1498       <div id="rfc.iref.11"></div>
    1499       <div id="rfc.iref.s.8"></div>
     1690      <div id="rfc.iref.29"></div>
     1691      <div id="rfc.iref.s.9"></div>
    15001692      <h4 id="rfc.section.4.3.2.6"><a href="#rfc.section.4.3.2.6">4.3.2.6</a>&nbsp;<a id="status.205" href="#status.205">205 Reset Content</a></h4>
    15011693      <p id="rfc.section.4.3.2.6.p.1">The server has fulfilled the request and the user agent <em class="bcp14">SHOULD</em> reset the document view which caused the request to be sent. This response is primarily intended to allow input for actions
    … …  
    15031695         another input action.
    15041696      </p>
    1505       <p id="rfc.section.4.3.2.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.29"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>.
     1697      <p id="rfc.section.4.3.2.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.33"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>.
    15061698      </p>
    15071699      <h3 id="rfc.section.4.3.3"><a href="#rfc.section.4.3.3">4.3.3</a>&nbsp;<a id="status.3xx" href="#status.3xx">Redirection 3xx</a></h3>
    15081700      <p id="rfc.section.4.3.3.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.
    15091701         If the required action involves a subsequent HTTP request, it <em class="bcp14">MAY</em> be carried out by the user agent without interaction with the user if and only if the method used in the second request is
    1510          known to be "safe", as defined in <a href="#safe.methods" title="Safe Methods">Section&nbsp;6.1.1</a>.
     1702         known to be "safe", as defined in <a href="#safe.methods" title="Safe Methods">Section&nbsp;2.1.1</a>.
    15111703      </p>
    15121704      <p id="rfc.section.4.3.3.p.2">There are several types of redirects: </p>
    … …  
    15241716         </li>
    15251717         <li>
    1526             <p>Redirection offering a choice of matching resources for use by agent-driven content negotiation (<a href="p3-payload.html#agent-driven.negotiation" title="Agent-driven Negotiation">Section 5.2</a> of <a href="#Part3" id="rfc.xref.Part3.8"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>). This is status code 300 (Multiple Choices).
     1718            <p>Redirection offering a choice of matching resources for use by agent-driven content negotiation (<a href="p3-payload.html#agent-driven.negotiation" title="Agent-driven Negotiation">Section 5.2</a> of <a href="#Part3" id="rfc.xref.Part3.9"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>). This is status code 300 (Multiple Choices).
    15271719            </p>
    15281720         </li>
    … …  
    15411733         </p>
    15421734      </div>
    1543       <p id="rfc.section.4.3.3.p.4">A Location header field on a 3xx response indicates that a client <em class="bcp14">MAY</em> automatically redirect to the URI provided; see <a href="#header.location" id="rfc.xref.header.location.2" title="Location">Section&nbsp;8.5</a>.
    1544       </p>
    1545       <p id="rfc.section.4.3.3.p.5">Note that for methods not known to be "safe", as defined in <a href="#safe.methods" title="Safe Methods">Section&nbsp;6.1.1</a>, automatic redirection needs to done with care, since the redirect might change the conditions under which the request was
     1735      <p id="rfc.section.4.3.3.p.4">A Location header field on a 3xx response indicates that a client <em class="bcp14">MAY</em> automatically redirect to the URI provided; see <a href="#header.location" id="rfc.xref.header.location.3" title="Location">Section&nbsp;7.5</a>.
     1736      </p>
     1737      <p id="rfc.section.4.3.3.p.5">Note that for methods not known to be "safe", as defined in <a href="#safe.methods" title="Safe Methods">Section&nbsp;2.1.1</a>, automatic redirection needs to done with care, since the redirect might change the conditions under which the request was
    15461738         issued.
    15471739      </p>
    … …  
    15521744         </p>
    15531745      </div>
    1554       <div id="rfc.iref.12"></div>
    1555       <div id="rfc.iref.s.9"></div>
     1746      <div id="rfc.iref.30"></div>
     1747      <div id="rfc.iref.s.10"></div>
    15561748      <h4 id="rfc.section.4.3.3.1"><a href="#rfc.section.4.3.3.1">4.3.3.1</a>&nbsp;<a id="status.300" href="#status.300">300 Multiple Choices</a></h4>
    15571749      <p id="rfc.section.4.3.3.1.p.1">The target resource has more than one representation, each with its own specific location, and agent-driven negotiation information
    1558          (<a href="p3-payload.html#content.negotiation" title="Content Negotiation">Section 5</a> of <a href="#Part3" id="rfc.xref.Part3.9"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>) is being provided so that the user (or user agent) can select a preferred representation by redirecting its request to that
     1750         (<a href="p3-payload.html#content.negotiation" title="Content Negotiation">Section 5</a> of <a href="#Part3" id="rfc.xref.Part3.10"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>) is being provided so that the user (or user agent) can select a preferred representation by redirecting its request to that
    15591751         location.
    15601752      </p>
    … …  
    15651757      <p id="rfc.section.4.3.3.1.p.3">If the server has a preferred choice of representation, it <em class="bcp14">SHOULD</em> include the specific URI for that representation in the Location field; user agents <em class="bcp14">MAY</em> use the Location field value for automatic redirection.
    15661758      </p>
    1567       <p id="rfc.section.4.3.3.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 2.3.1.1</a> of <a href="#Part6" id="rfc.xref.Part6.10"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) to determine freshness for 300 responses.
    1568       </p>
    1569       <div id="rfc.iref.13"></div>
    1570       <div id="rfc.iref.s.10"></div>
     1759      <p id="rfc.section.4.3.3.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 2.3.1.1</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.
     1760      </p>
     1761      <div id="rfc.iref.31"></div>
     1762      <div id="rfc.iref.s.11"></div>
    15711763      <h4 id="rfc.section.4.3.3.2"><a href="#rfc.section.4.3.3.2">4.3.3.2</a>&nbsp;<a id="status.301" href="#status.301">301 Moved Permanently</a></h4>
    15721764      <p id="rfc.section.4.3.3.2.p.1">The target resource has been assigned a new permanent URI and any future references to this resource <em class="bcp14">SHOULD</em> use one of the returned URIs. Clients with link editing capabilities ought to automatically re-link references to the effective
    15731765         request URI to one or more of the new references returned by the server, where possible.
    15741766      </p>
    1575       <p id="rfc.section.4.3.3.2.p.2">Caches <em class="bcp14">MAY</em> use a heuristic (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 2.3.1.1</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 301 responses.
     1767      <p id="rfc.section.4.3.3.2.p.2">Caches <em class="bcp14">MAY</em> use a heuristic (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 2.3.1.1</a> of <a href="#Part6" id="rfc.xref.Part6.16"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) to determine freshness for 301 responses.
    15761768      </p>
    15771769      <p id="rfc.section.4.3.3.2.p.3">The new permanent URI <em class="bcp14">SHOULD</em> be given by the Location field in the response. A response payload can contain a short hypertext note with a hyperlink to
    … …  
    15831775         </p>
    15841776      </div>
    1585       <div id="rfc.iref.14"></div>
    1586       <div id="rfc.iref.s.11"></div>
     1777      <div id="rfc.iref.32"></div>
     1778      <div id="rfc.iref.s.12"></div>
    15871779      <h4 id="rfc.section.4.3.3.3"><a href="#rfc.section.4.3.3.3">4.3.3.3</a>&nbsp;<a id="status.302" href="#status.302">302 Found</a></h4>
    15881780      <p id="rfc.section.4.3.3.3.p.1">The target resource resides temporarily under a different URI. Since the redirection might be altered on occasion, the client <em class="bcp14">SHOULD</em> continue to use the effective request URI for future requests.
    … …  
    15961788         </p>
    15971789      </div>
    1598       <div id="rfc.iref.15"></div>
    1599       <div id="rfc.iref.s.12"></div>
     1790      <div id="rfc.iref.33"></div>
     1791      <div id="rfc.iref.s.13"></div>
    16001792      <h4 id="rfc.section.4.3.3.4"><a href="#rfc.section.4.3.3.4">4.3.3.4</a>&nbsp;<a id="status.303" href="#status.303">303 See Other</a></h4>
    16011793      <p id="rfc.section.4.3.3.4.p.1">The 303 status code indicates that the server is redirecting the user agent to a different resource, as indicated by a URI
    … …  
    16171809      <p id="rfc.section.4.3.3.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 Location URI.
    16181810      </p>
    1619       <div id="rfc.iref.16"></div>
    1620       <div id="rfc.iref.s.13"></div>
     1811      <div id="rfc.iref.34"></div>
     1812      <div id="rfc.iref.s.14"></div>
    16211813      <h4 id="rfc.section.4.3.3.5"><a href="#rfc.section.4.3.3.5">4.3.3.5</a>&nbsp;<a id="status.305" href="#status.305">305 Use Proxy</a></h4>
    16221814      <p id="rfc.section.4.3.3.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;A</a>), and is now deprecated.
    16231815      </p>
    1624       <div id="rfc.iref.17"></div>
    1625       <div id="rfc.iref.s.14"></div>
     1816      <div id="rfc.iref.35"></div>
     1817      <div id="rfc.iref.s.15"></div>
    16261818      <h4 id="rfc.section.4.3.3.6"><a href="#rfc.section.4.3.3.6">4.3.3.6</a>&nbsp;<a id="status.306" href="#status.306">306 (Unused)</a></h4>
    16271819      <p id="rfc.section.4.3.3.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>
    1628       <div id="rfc.iref.18"></div>
    1629       <div id="rfc.iref.s.15"></div>
     1820      <div id="rfc.iref.36"></div>
     1821      <div id="rfc.iref.s.16"></div>
    16301822      <h4 id="rfc.section.4.3.3.7"><a href="#rfc.section.4.3.3.7">4.3.3.7</a>&nbsp;<a id="status.307" href="#status.307">307 Temporary Redirect</a></h4>
    16311823      <p id="rfc.section.4.3.3.7.p.1">The target resource resides temporarily under a different URI. Since the redirection can change over time, the client <em class="bcp14">SHOULD</em> continue to use the effective request URI for future requests.
    … …  
    16441836         These status codes are applicable to any request method. User agents <em class="bcp14">SHOULD</em> display any included representation to the user.
    16451837      </p>
    1646       <div id="rfc.iref.19"></div>
    1647       <div id="rfc.iref.s.16"></div>
     1838      <div id="rfc.iref.37"></div>
     1839      <div id="rfc.iref.s.17"></div>
    16481840      <h4 id="rfc.section.4.3.4.1"><a href="#rfc.section.4.3.4.1">4.3.4.1</a>&nbsp;<a id="status.400" href="#status.400">400 Bad Request</a></h4>
    16491841      <p id="rfc.section.4.3.4.1.p.1">The server cannot or will not process the request, due to a client error (e.g., malformed syntax).</p>
    1650       <div id="rfc.iref.20"></div>
    1651       <div id="rfc.iref.s.17"></div>
     1842      <div id="rfc.iref.38"></div>
     1843      <div id="rfc.iref.s.18"></div>
    16521844      <h4 id="rfc.section.4.3.4.2"><a href="#rfc.section.4.3.4.2">4.3.4.2</a>&nbsp;<a id="status.402" href="#status.402">402 Payment Required</a></h4>
    16531845      <p id="rfc.section.4.3.4.2.p.1">This code is reserved for future use.</p>
    1654       <div id="rfc.iref.21"></div>
    1655       <div id="rfc.iref.s.18"></div>
     1846      <div id="rfc.iref.39"></div>
     1847      <div id="rfc.iref.s.19"></div>
    16561848      <h4 id="rfc.section.4.3.4.3"><a href="#rfc.section.4.3.4.3">4.3.4.3</a>&nbsp;<a id="status.403" href="#status.403">403 Forbidden</a></h4>
    16571849      <p id="rfc.section.4.3.4.3.p.1">The server understood the request, but refuses to authorize it. Providing different user authentication credentials might
    … …  
    16611853         to the client, the status code 404 (Not Found) <em class="bcp14">MAY</em> be used instead.
    16621854      </p>
    1663       <div id="rfc.iref.22"></div>
    1664       <div id="rfc.iref.s.19"></div>
     1855      <div id="rfc.iref.40"></div>
     1856      <div id="rfc.iref.s.20"></div>
    16651857      <h4 id="rfc.section.4.3.4.4"><a href="#rfc.section.4.3.4.4">4.3.4.4</a>&nbsp;<a id="status.404" href="#status.404">404 Not Found</a></h4>
    16661858      <p id="rfc.section.4.3.4.4.p.1">The server has not found anything matching the effective request URI. No indication is given of whether the condition is temporary
    … …  
    16691861         has been refused, or when no other response is applicable.
    16701862      </p>
    1671       <div id="rfc.iref.23"></div>
    1672       <div id="rfc.iref.s.20"></div>
     1863      <div id="rfc.iref.41"></div>
     1864      <div id="rfc.iref.s.21"></div>
    16731865      <h4 id="rfc.section.4.3.4.5"><a href="#rfc.section.4.3.4.5">4.3.4.5</a>&nbsp;<a id="status.405" href="#status.405">405 Method Not Allowed</a></h4>
    16741866      <p id="rfc.section.4.3.4.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 Allow header field containing a list of valid methods for the requested resource.
    16751867      </p>
    1676       <div id="rfc.iref.24"></div>
    1677       <div id="rfc.iref.s.21"></div>
     1868      <div id="rfc.iref.42"></div>
     1869      <div id="rfc.iref.s.22"></div>
    16781870      <h4 id="rfc.section.4.3.4.6"><a href="#rfc.section.4.3.4.6">4.3.4.6</a>&nbsp;<a id="status.406" href="#status.406">406 Not Acceptable</a></h4>
    16791871      <p id="rfc.section.4.3.4.6.p.1">The resource identified by the request is only capable of generating response representations which have content characteristics
    1680          not acceptable according to the Accept and Accept-* header fields sent in the request (see <a href="p3-payload.html#header.field.definitions" title="Header Field Definitions">Section 6</a> of <a href="#Part3" id="rfc.xref.Part3.10"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>).
     1872         not acceptable according to the Accept and Accept-* header fields sent in the request (see <a href="p3-payload.html#header.field.definitions" title="Header Field Definitions">Section 6</a> of <a href="#Part3" id="rfc.xref.Part3.11"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>).
    16811873      </p>
    16821874      <p id="rfc.section.4.3.4.6.p.2">Unless it was a HEAD request, the response <em class="bcp14">SHOULD</em> include a representation containing a list of available representation characteristics and location(s) from which the user
    … …  
    16921884      <p id="rfc.section.4.3.4.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.
    16931885      </p>
    1694       <div id="rfc.iref.25"></div>
    1695       <div id="rfc.iref.s.22"></div>
     1886      <div id="rfc.iref.43"></div>
     1887      <div id="rfc.iref.s.23"></div>
    16961888      <h4 id="rfc.section.4.3.4.7"><a href="#rfc.section.4.3.4.7">4.3.4.7</a>&nbsp;<a id="status.408" href="#status.408">408 Request Timeout</a></h4>
    16971889      <p id="rfc.section.4.3.4.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.
    16981890      </p>
    1699       <div id="rfc.iref.26"></div>
    1700       <div id="rfc.iref.s.23"></div>
     1891      <div id="rfc.iref.44"></div>
     1892      <div id="rfc.iref.s.24"></div>
    17011893      <h4 id="rfc.section.4.3.4.8"><a href="#rfc.section.4.3.4.8">4.3.4.8</a>&nbsp;<a id="status.409" href="#status.409">409 Conflict</a></h4>
    17021894      <p id="rfc.section.4.3.4.8.p.1">The request could not be completed due to a conflict with the current state of the resource. This code is only allowed in
    … …  
    17101902         contain a list of the differences between the two versions.
    17111903      </p>
    1712       <div id="rfc.iref.27"></div>
    1713       <div id="rfc.iref.s.24"></div>
     1904      <div id="rfc.iref.45"></div>
     1905      <div id="rfc.iref.s.25"></div>
    17141906      <h4 id="rfc.section.4.3.4.9"><a href="#rfc.section.4.3.4.9">4.3.4.9</a>&nbsp;<a id="status.410" href="#status.410">410 Gone</a></h4>
    17151907      <p id="rfc.section.4.3.4.9.p.1">The target resource is no longer available at the server and no forwarding address is known. This condition is expected to
    … …  
    17231915         — that is left to the discretion of the server owner.
    17241916      </p>
    1725       <p id="rfc.section.4.3.4.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 2.3.1.1</a> of <a href="#Part6" id="rfc.xref.Part6.12"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) to determine freshness for 410 responses.
    1726       </p>
    1727       <div id="rfc.iref.28"></div>
    1728       <div id="rfc.iref.s.25"></div>
     1917      <p id="rfc.section.4.3.4.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 2.3.1.1</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.
     1918      </p>
     1919      <div id="rfc.iref.46"></div>
     1920      <div id="rfc.iref.s.26"></div>
    17291921      <h4 id="rfc.section.4.3.4.10"><a href="#rfc.section.4.3.4.10">4.3.4.10</a>&nbsp;<a id="status.411" href="#status.411">411 Length Required</a></h4>
    17301922      <p id="rfc.section.4.3.4.10.p.1">The server refuses to accept the request without a defined Content-Length. The client <em class="bcp14">MAY</em> repeat the request if it adds a valid Content-Length header field containing the length of the message body in the request
    17311923         message.
    17321924      </p>
    1733       <div id="rfc.iref.29"></div>
    1734       <div id="rfc.iref.s.26"></div>
     1925      <div id="rfc.iref.47"></div>
     1926      <div id="rfc.iref.s.27"></div>
    17351927      <h4 id="rfc.section.4.3.4.11"><a href="#rfc.section.4.3.4.11">4.3.4.11</a>&nbsp;<a id="status.413" href="#status.413">413 Request Representation Too Large</a></h4>
    17361928      <p id="rfc.section.4.3.4.11.p.1">The server is refusing to process a request because the request representation is larger than the server is willing or able
    … …  
    17391931      <p id="rfc.section.4.3.4.11.p.2">If the condition is temporary, the server <em class="bcp14">SHOULD</em> include a Retry-After header field to indicate that it is temporary and after what time the client <em class="bcp14">MAY</em> try again.
    17401932      </p>
    1741       <div id="rfc.iref.30"></div>
    1742       <div id="rfc.iref.s.27"></div>
     1933      <div id="rfc.iref.48"></div>
     1934      <div id="rfc.iref.s.28"></div>
    17431935      <h4 id="rfc.section.4.3.4.12"><a href="#rfc.section.4.3.4.12">4.3.4.12</a>&nbsp;<a id="status.414" href="#status.414">414 URI Too Long</a></h4>
    17441936      <p id="rfc.section.4.3.4.12.p.1">The server is refusing to service the request because the effective request URI is longer than the server is willing to interpret.
    … …  
    17481940         in some servers using fixed-length buffers for reading or manipulating the request-target.
    17491941      </p>
    1750       <div id="rfc.iref.31"></div>
    1751       <div id="rfc.iref.s.28"></div>
     1942      <div id="rfc.iref.49"></div>
     1943      <div id="rfc.iref.s.29"></div>
    17521944      <h4 id="rfc.section.4.3.4.13"><a href="#rfc.section.4.3.4.13">4.3.4.13</a>&nbsp;<a id="status.415" href="#status.415">415 Unsupported Media Type</a></h4>
    17531945      <p id="rfc.section.4.3.4.13.p.1">The server is refusing to service the request because the request payload is in a format not supported by this request method
    17541946         on the target resource.
    17551947      </p>
    1756       <div id="rfc.iref.32"></div>
    1757       <div id="rfc.iref.s.29"></div>
     1948      <div id="rfc.iref.50"></div>
     1949      <div id="rfc.iref.s.30"></div>
    17581950      <h4 id="rfc.section.4.3.4.14"><a href="#rfc.section.4.3.4.14">4.3.4.14</a>&nbsp;<a id="status.417" href="#status.417">417 Expectation Failed</a></h4>
    1759       <p id="rfc.section.4.3.4.14.p.1">The expectation given in an Expect header field (see <a href="#header.expect" id="rfc.xref.header.expect.2" title="Expect">Section&nbsp;8.3</a>) could not be met by this server, or, if the server is a proxy, the server has unambiguous evidence that the request could
     1951      <p id="rfc.section.4.3.4.14.p.1">The expectation given in an Expect header field (see <a href="#header.expect" id="rfc.xref.header.expect.2" title="Expect">Section&nbsp;7.3</a>) could not be met by this server, or, if the server is a proxy, the server has unambiguous evidence that the request could
    17601952         not be met by the next-hop server.
    17611953      </p>
    1762       <div id="rfc.iref.33"></div>
    1763       <div id="rfc.iref.s.30"></div>
     1954      <div id="rfc.iref.51"></div>
     1955      <div id="rfc.iref.s.31"></div>
    17641956      <h4 id="rfc.section.4.3.4.15"><a href="#rfc.section.4.3.4.15">4.3.4.15</a>&nbsp;<a id="status.426" href="#status.426">426 Upgrade Required</a></h4>
    1765       <p id="rfc.section.4.3.4.15.p.1">The request can not be completed without a prior protocol upgrade. This response <em class="bcp14">MUST</em> include an Upgrade header field (<a href="p1-messaging.html#header.upgrade" title="Upgrade">Section 6.5</a> of <a href="#Part1" id="rfc.xref.Part1.30"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) specifying the required protocols.
    1766       </p>
    1767       <div id="rfc.figure.u.6"></div>
     1957      <p id="rfc.section.4.3.4.15.p.1">The request can not be completed without a prior protocol upgrade. This response <em class="bcp14">MUST</em> include an Upgrade header field (<a href="p1-messaging.html#header.upgrade" title="Upgrade">Section 6.5</a> of <a href="#Part1" id="rfc.xref.Part1.34"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) specifying the required protocols.
     1958      </p>
     1959      <div id="rfc.figure.u.8"></div>
    17681960      <p>Example:</p>  <pre class="text">HTTP/1.1 426 Upgrade Required
    17691961Upgrade: HTTP/3.0
    … …  
    17811973         User agents <em class="bcp14">SHOULD</em> display any included representation to the user. These response codes are applicable to any request method.
    17821974      </p>
    1783       <div id="rfc.iref.34"></div>
    1784       <div id="rfc.iref.s.31"></div>
     1975      <div id="rfc.iref.52"></div>
     1976      <div id="rfc.iref.s.32"></div>
    17851977      <h4 id="rfc.section.4.3.5.1"><a href="#rfc.section.4.3.5.1">4.3.5.1</a>&nbsp;<a id="status.500" href="#status.500">500 Internal Server Error</a></h4>
    17861978      <p id="rfc.section.4.3.5.1.p.1">The server encountered an unexpected condition which prevented it from fulfilling the request.</p>
    1787       <div id="rfc.iref.35"></div>
    1788       <div id="rfc.iref.s.32"></div>
     1979      <div id="rfc.iref.53"></div>
     1980      <div id="rfc.iref.s.33"></div>
    17891981      <h4 id="rfc.section.4.3.5.2"><a href="#rfc.section.4.3.5.2">4.3.5.2</a>&nbsp;<a id="status.501" href="#status.501">501 Not Implemented</a></h4>
    17901982      <p id="rfc.section.4.3.5.2.p.1">The server does not support the functionality required to fulfill the request. This is the appropriate response when the server
    17911983         does not recognize the request method and is not capable of supporting it for any resource.
    17921984      </p>
    1793       <div id="rfc.iref.36"></div>
    1794       <div id="rfc.iref.s.33"></div>
     1985      <div id="rfc.iref.54"></div>
     1986      <div id="rfc.iref.s.34"></div>
    17951987      <h4 id="rfc.section.4.3.5.3"><a href="#rfc.section.4.3.5.3">4.3.5.3</a>&nbsp;<a id="status.502" href="#status.502">502 Bad Gateway</a></h4>
    17961988      <p id="rfc.section.4.3.5.3.p.1">The server, while acting as a gateway or proxy, received an invalid response from the upstream server it accessed in attempting
    17971989         to fulfill the request.
    17981990      </p>
    1799       <div id="rfc.iref.37"></div>
    1800       <div id="rfc.iref.s.34"></div>
     1991      <div id="rfc.iref.55"></div>
     1992      <div id="rfc.iref.s.35"></div>
    18011993      <h4 id="rfc.section.4.3.5.4"><a href="#rfc.section.4.3.5.4">4.3.5.4</a>&nbsp;<a id="status.503" href="#status.503">503 Service Unavailable</a></h4>
    18021994      <p id="rfc.section.4.3.5.4.p.1">The server is currently unable to handle the request due to a temporary overloading or maintenance of the server.</p>
    18031995      <p id="rfc.section.4.3.5.4.p.2">The implication is that this is a temporary condition which will be alleviated after some delay. If known, the length of the
    1804          delay <em class="bcp14">MAY</em> be indicated in a Retry-After header field (<a href="#header.retry-after" id="rfc.xref.header.retry-after.2" title="Retry-After">Section&nbsp;8.8</a>). If no Retry-After is given, the client <em class="bcp14">SHOULD</em> handle the response as it would for a 500 response.
     1996         delay <em class="bcp14">MAY</em> be indicated in a Retry-After header field (<a href="#header.retry-after" id="rfc.xref.header.retry-after.2" title="Retry-After">Section&nbsp;7.8</a>). If no Retry-After is given, the client <em class="bcp14">SHOULD</em> handle the response as it would for a 500 response.
    18051997      </p>
    18061998      <div class="note" id="rfc.section.4.3.5.4.p.3">
    … …  
    18092001         </p>
    18102002      </div>
    1811       <div id="rfc.iref.38"></div>
    1812       <div id="rfc.iref.s.35"></div>
     2003      <div id="rfc.iref.56"></div>
     2004      <div id="rfc.iref.s.36"></div>
    18132005      <h4 id="rfc.section.4.3.5.5"><a href="#rfc.section.4.3.5.5">4.3.5.5</a>&nbsp;<a id="status.504" href="#status.504">504 Gateway Timeout</a></h4>
    18142006      <p id="rfc.section.4.3.5.5.p.1">The server, while acting as a gateway or proxy, did not receive a timely response from the upstream server specified by the
    … …  
    18192011         </p>
    18202012      </div>
    1821       <div id="rfc.iref.39"></div>
    1822       <div id="rfc.iref.s.36"></div>
     2013      <div id="rfc.iref.57"></div>
     2014      <div id="rfc.iref.s.37"></div>
    18232015      <h4 id="rfc.section.4.3.5.6"><a href="#rfc.section.4.3.5.6">4.3.5.6</a>&nbsp;<a id="status.505" href="#status.505">505 HTTP Version Not Supported</a></h4>
    18242016      <p id="rfc.section.4.3.5.6.p.1">The server does not support, or refuses to support, the protocol version that was used in the request message. The server
    18252017         is indicating that it is unable or unwilling to complete the request using the same major version as the client, as described
    1826          in <a href="p1-messaging.html#http.version" title="Protocol Versioning">Section 2.6</a> of <a href="#Part1" id="rfc.xref.Part1.31"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[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.
     2018         in <a href="p1-messaging.html#http.version" title="Protocol Versioning">Section 2.6</a> of <a href="#Part1" id="rfc.xref.Part1.35"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[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.
    18272019      </p>
    18282020      <h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a>&nbsp;<a id="representation" href="#representation">Representation</a></h1>
    18292021      <p id="rfc.section.5.p.1">Request and Response messages <em class="bcp14">MAY</em> transfer a representation if not otherwise restricted by the request method or response status code. A representation consists
    18302022         of metadata (representation header fields) and data (representation body). When a complete or partial representation is enclosed
    1831          in an HTTP message, it is referred to as the payload of the message. HTTP representations are defined in <a href="#Part3" id="rfc.xref.Part3.11"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>.
    1832       </p>
    1833       <p id="rfc.section.5.p.2">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.32"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. The representation body is obtained from the message body by decoding any Transfer-Encoding that might have been applied
     2023         in an HTTP message, it is referred to as the payload of the message. HTTP representations are defined in <a href="#Part3" id="rfc.xref.Part3.12"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>.
     2024      </p>
     2025      <p id="rfc.section.5.p.2">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.36"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. The representation body is obtained from the message body by decoding any Transfer-Encoding that might have been applied
    18342026         to ensure safe and proper transfer of the message.
    18352027      </p>
    … …  
    18372029      <p id="rfc.section.5.1.p.1">It is sometimes necessary to determine an identifier for the resource associated with a representation.</p>
    18382030      <p id="rfc.section.5.1.p.2">An HTTP request representation, when present, is always associated with an anonymous (i.e., unidentified) resource.</p>
    1839       <p id="rfc.section.5.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.33"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). However, this is not always the case. To determine the URI of the resource a response is associated with, the following
     2031      <p id="rfc.section.5.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.37"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). However, this is not always the case. To determine the URI of the resource a response is associated with, the following
    18402032         rules are used (with the first applicable one being selected):
    18412033      </p>
    … …  
    18592051            cache invalidation.]</span>
    18602052      </p>
    1861       <h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a>&nbsp;<a id="method.definitions" href="#method.definitions">Method Definitions</a></h1>
    1862       <p id="rfc.section.6.p.1">The set of common request methods for HTTP/1.1 is defined below. Although this set can be expanded, additional methods cannot
    1863          be assumed to share the same semantics for separately extended clients and servers.
    1864       </p>
    1865       <h2 id="rfc.section.6.1"><a href="#rfc.section.6.1">6.1</a>&nbsp;<a id="safe.and.idempotent" href="#safe.and.idempotent">Safe and Idempotent Methods</a></h2>
    1866       <div id="rfc.iref.s.37"></div>
    1867       <h3 id="rfc.section.6.1.1"><a href="#rfc.section.6.1.1">6.1.1</a>&nbsp;<a id="safe.methods" href="#safe.methods">Safe Methods</a></h3>
    1868       <p id="rfc.section.6.1.1.p.1">Implementors need to be aware that the software represents the user in their interactions over the Internet, and need to allow
    1869          the user to be aware of any actions they take which might have an unexpected significance to themselves or others.
    1870       </p>
    1871       <p id="rfc.section.6.1.1.p.2">In particular, the convention has been established that the GET, HEAD, OPTIONS, and TRACE request methods <em class="bcp14">SHOULD NOT</em> have the significance of taking an action other than retrieval. These request methods ought to be considered "<dfn id="safe">safe</dfn>". This allows user agents to represent other methods, such as POST, PUT and DELETE, in a special way, so that the user is
    1872          made aware of the fact that a possibly unsafe action is being requested.
    1873       </p>
    1874       <p id="rfc.section.6.1.1.p.3">Naturally, it is not possible to ensure that the server does not generate side-effects as a result of performing a GET request;
    1875          in fact, some dynamic resources consider that a feature. The important distinction here is that the user did not request the
    1876          side-effects, so therefore cannot be held accountable for them.
    1877       </p>
    1878       <div id="rfc.iref.i.1"></div>
    1879       <h3 id="rfc.section.6.1.2"><a href="#rfc.section.6.1.2">6.1.2</a>&nbsp;<a id="idempotent.methods" href="#idempotent.methods">Idempotent Methods</a></h3>
    1880       <p id="rfc.section.6.1.2.p.1">Request methods can also have the property of "idempotence" in that, aside from error or expiration issues, the intended effect
    1881          of multiple identical requests is the same as for a single request. PUT, DELETE, and all safe request methods are idempotent.
    1882          It is important to note that idempotence refers only to changes requested by the client: a server is free to change its state
    1883          due to multiple requests for the purpose of tracking those requests, versioning of results, etc.
    1884       </p>
    1885       <h2 id="rfc.section.6.2"><a href="#rfc.section.6.2">6.2</a>&nbsp;<a id="OPTIONS" href="#OPTIONS">OPTIONS</a></h2>
    1886       <div id="rfc.iref.o.1"></div>
    1887       <div id="rfc.iref.m.1"></div>
    1888       <p id="rfc.section.6.2.p.1">The OPTIONS method requests information about the communication options available on the request/response chain identified
    1889          by the effective request URI. This method allows a client to determine the options and/or requirements associated with a resource,
    1890          or the capabilities of a server, without implying a resource action or initiating a resource retrieval.
    1891       </p>
    1892       <p id="rfc.section.6.2.p.2">Responses to the OPTIONS method are not cacheable.</p>
    1893       <p id="rfc.section.6.2.p.3">If the OPTIONS request includes a message body (as indicated by the presence of Content-Length or Transfer-Encoding), then
    1894          the media type <em class="bcp14">MUST</em> be indicated by a Content-Type field. Although this specification does not define any use for such a body, future extensions
    1895          to HTTP might use the OPTIONS body to make more detailed queries on the server.
    1896       </p>
    1897       <p id="rfc.section.6.2.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.34"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) is an asterisk ("*"), the OPTIONS request is intended to apply to the server in general rather than to a specific resource.
    1898          Since a server's communication options typically depend on the resource, the "*" request is only useful as a "ping" or "no-op"
    1899          type of method; it does nothing beyond allowing the client to test the capabilities of the server. For example, this can be
    1900          used to test a proxy for HTTP/1.1 conformance (or lack thereof).
    1901       </p>
    1902       <p id="rfc.section.6.2.p.5">If the request-target is not an asterisk, the OPTIONS request applies only to the options that are available when communicating
    1903          with that resource.
    1904       </p>
    1905       <p id="rfc.section.6.2.p.6">A 200 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.,
    1906          Allow), 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,
    1907          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 Content-Length field with a field-value of "0".
    1908       </p>
    1909       <p id="rfc.section.6.2.p.7">The Max-Forwards 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.2" title="Max-Forwards">Section&nbsp;8.6</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.
    1910       </p>
    1911       <h2 id="rfc.section.6.3"><a href="#rfc.section.6.3">6.3</a>&nbsp;<a id="GET" href="#GET">GET</a></h2>
    1912       <div id="rfc.iref.g.5"></div>
    1913       <div id="rfc.iref.m.2"></div>
    1914       <p id="rfc.section.6.3.p.1">The GET method requests transfer of a current representation of the target resource.</p>
    1915       <p id="rfc.section.6.3.p.2">If the target resource is a data-producing process, it is the produced data which shall be returned as the representation
    1916          in the response and not the source text of the process, unless that text happens to be the output of the process.
    1917       </p>
    1918       <p id="rfc.section.6.3.p.3">The semantics of the GET method change to a "conditional GET" if the request message includes an If-Modified-Since, If-Unmodified-Since,
    1919          If-Match, If-None-Match, or If-Range header field. A conditional GET requests that the representation be transferred only
    1920          under the circumstances described by the conditional header field(s). The conditional GET request is intended to reduce unnecessary
    1921          network usage by allowing cached representations to be refreshed without requiring multiple requests or transferring data
    1922          already held by the client.
    1923       </p>
    1924       <p id="rfc.section.6.3.p.4">The semantics of the GET method change to a "partial GET" if the request message includes a Range header field. A partial
    1925          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.7"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>. The partial GET request is intended to reduce unnecessary network usage by allowing partially-retrieved representations
    1926          to be completed without transferring data already held by the client.
    1927       </p>
    1928       <p id="rfc.section.6.3.p.5">Bodies on GET requests have no defined semantics. Note that sending a body on a GET request might cause some existing implementations
    1929          to reject the request.
    1930       </p>
    1931       <p id="rfc.section.6.3.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.13"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>).
    1932       </p>
    1933       <p id="rfc.section.6.3.p.7">See <a href="#encoding.sensitive.information.in.uris" title="Encoding Sensitive Information in URIs">Section&nbsp;10.2</a> for security considerations when used for forms.
    1934       </p>
    1935       <h2 id="rfc.section.6.4"><a href="#rfc.section.6.4">6.4</a>&nbsp;<a id="HEAD" href="#HEAD">HEAD</a></h2>
    1936       <div id="rfc.iref.h.1"></div>
    1937       <div id="rfc.iref.m.3"></div>
    1938       <p id="rfc.section.6.4.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
    1939          representation implied by the request without transferring the representation body. This method is often used for testing
    1940          hypertext links for validity, accessibility, and recent modification.
    1941       </p>
    1942       <p id="rfc.section.6.4.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 2.5</a> of <a href="#Part6" id="rfc.xref.Part6.14"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>.
    1943       </p>
    1944       <p id="rfc.section.6.4.p.3">Bodies on HEAD requests have no defined semantics. Note that sending a body on a HEAD request might cause some existing implementations
    1945          to reject the request.
    1946       </p>
    1947       <div id="rfc.iref.p.1"></div>
    1948       <div id="rfc.iref.m.4"></div>
    1949       <h2 id="rfc.section.6.5"><a href="#rfc.section.6.5">6.5</a>&nbsp;<a id="POST" href="#POST">POST</a></h2>
    1950       <p id="rfc.section.6.5.p.1">The POST method requests that the origin server accept the representation enclosed in the request as data to be processed
    1951          by the target resource. POST is designed to allow a uniform method to cover the following functions:
    1952       </p>
    1953       <ul>
    1954          <li>Annotation of existing resources;</li>
    1955          <li>Posting a message to a bulletin board, newsgroup, mailing list, or similar group of articles;</li>
    1956          <li>Providing a block of data, such as the result of submitting a form, to a data-handling process;</li>
    1957          <li>Extending a database through an append operation.</li>
    1958       </ul>
    1959       <p id="rfc.section.6.5.p.2">The actual function performed by the POST method is determined by the server and is usually dependent on the effective request
    1960          URI.
    1961       </p>
    1962       <p id="rfc.section.6.5.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
    1963          200 (OK) or 204 (No Content) is the appropriate response status code, depending on whether or not the response includes a
    1964          representation that describes the result.
    1965       </p>
    1966       <p id="rfc.section.6.5.p.4">If a resource has been created on the origin server, the response <em class="bcp14">SHOULD</em> be 201 (Created) and contain a representation which describes the status of the request and refers to the new resource, and
    1967          a Location header field (see <a href="#header.location" id="rfc.xref.header.location.3" title="Location">Section&nbsp;8.5</a>).
    1968       </p>
    1969       <p id="rfc.section.6.5.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 2.3.1</a> of <a href="#Part6" id="rfc.xref.Part6.15"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>). A cached POST response with a Content-Location header field (see <a href="p3-payload.html#header.content-location" title="Content-Location">Section 6.7</a> of <a href="#Part3" id="rfc.xref.Part3.12"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>) whose value is the effective Request URI <em class="bcp14">MAY</em> be used to satisfy subsequent GET and HEAD requests.
    1970       </p>
    1971       <p id="rfc.section.6.5.p.6">Note that POST caching is not widely implemented. However, the 303 (See Other) response can be used to direct the user agent
    1972          to retrieve a cacheable representation of the resource.
    1973       </p>
    1974       <div id="rfc.iref.p.2"></div>
    1975       <div id="rfc.iref.m.5"></div>
    1976       <h2 id="rfc.section.6.6"><a href="#rfc.section.6.6">6.6</a>&nbsp;<a id="PUT" href="#PUT">PUT</a></h2>
    1977       <p id="rfc.section.6.6.p.1">The PUT method requests that the state of the target resource be created or replaced with the state defined by the representation
    1978          enclosed in the request message payload. A successful PUT of a given representation would suggest that a subsequent GET on
    1979          that same target resource will result in an equivalent representation being returned in a 200 (OK) response. However, there
    1980          is no guarantee that such a state change will be observable, since the target resource might be acted upon by other user agents
    1981          in parallel, or might be subject to dynamic processing by the origin server, before any subsequent GET is received. A successful
    1982          response only implies that the user agent's intent was achieved at the time of its processing by the origin server.
    1983       </p>
    1984       <p id="rfc.section.6.6.p.2">If the target resource does not have a current representation and the PUT successfully creates one, then the origin server <em class="bcp14">MUST</em> inform the user agent by sending a 201 (Created) response. If the target resource does have a current representation and that
    1985          representation is successfully modified in accordance with the state of the enclosed representation, then either a 200 (OK)
    1986          or 204 (No Content) response <em class="bcp14">SHOULD</em> be sent to indicate successful completion of the request.
    1987       </p>
    1988       <p id="rfc.section.6.6.p.3">Unrecognized header fields <em class="bcp14">SHOULD</em> be ignored (i.e., not saved as part of the resource state).
    1989       </p>
    1990       <p id="rfc.section.6.6.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
    1991          or will not be changed by the PUT. This is particularly important when the origin server uses internal configuration information
    1992          related to the URI in order to set the values for representation metadata on GET responses. When a PUT representation is inconsistent
    1993          with the target resource, the origin server <em class="bcp14">SHOULD</em> either make them consistent, by transforming the representation or changing the resource configuration, or respond with an
    1994          appropriate error message containing sufficient information to explain why the representation is unsuitable. The 409 (Conflict)
    1995          or 415 (Unsupported Media Type) status codes are suggested, with the latter being specific to constraints on Content-Type
    1996          values.
    1997       </p>
    1998       <p id="rfc.section.6.6.p.5">For example, if the target resource is configured to always have a Content-Type of "text/html" and the representation being
    1999          PUT has a Content-Type of "image/jpeg", then the origin server <em class="bcp14">SHOULD</em> do one of: (a) reconfigure the target resource to reflect the new media type; (b) transform the PUT representation to a format
    2000          consistent with that of the resource before saving it as the new resource state; or, (c) reject the request with a 415 response
    2001          indicating that the target resource is limited to "text/html", perhaps including a link to a different resource that would
    2002          be a suitable target for the new representation.
    2003       </p>
    2004       <p id="rfc.section.6.6.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
    2005          of the user agent request and the semantics of the origin server response. It does not define what a resource might be, in
    2006          any sense of that word, beyond the interface provided via HTTP. It does not define how resource state is "stored", nor how
    2007          such storage might change as a result of a change in resource state, nor how the origin server translates resource state into
    2008          representations. Generally speaking, all implementation details behind the resource interface are intentionally hidden by
    2009          the server.
    2010       </p>
    2011       <p id="rfc.section.6.6.p.7">The fundamental difference between the POST and PUT methods is highlighted by the different intent for the target resource.
    2012          The target resource in a POST request is intended to handle the enclosed representation as a data-accepting process, such
    2013          as for a gateway to some other protocol or a document that accepts annotations. In contrast, the target resource in a PUT
    2014          request is intended to take the enclosed representation as a new or replacement value. Hence, the intent of PUT is idempotent
    2015          and visible to intermediaries, even though the exact effect is only known by the origin server.
    2016       </p>
    2017       <p id="rfc.section.6.6.p.8">Proper interpretation of a PUT request presumes that the user agent knows what target resource is desired. A service that
    2018          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
    2019          the target resource and instead wishes to have it applied to a different resource, such as when the resource has been moved
    2020          to a different URI, then the origin server <em class="bcp14">MUST</em> send a 301 (Moved Permanently) response; the user agent <em class="bcp14">MAY</em> then make its own decision regarding whether or not to redirect the request.
    2021       </p>
    2022       <p id="rfc.section.6.6.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)
    2023          which is separate from the URIs identifying each particular version (different resources that at one point shared the same
    2024          state as the current version resource). A successful PUT request on "the current version" URI might therefore create a new
    2025          version resource in addition to changing the state of the target resource, and might also cause links to be added between
    2026          the related resources.
    2027       </p>
    2028       <p id="rfc.section.6.6.p.10">An origin server <em class="bcp14">SHOULD</em> reject any PUT request that contains a Content-Range header field, since it might be misinterpreted as partial content (or
    2029          might be partial content that is being mistakenly PUT as a full representation). Partial content updates are possible by targeting
    2030          a separately identified resource with state that overlaps a portion of the larger resource, or by using a different method
    2031          that has been specifically defined for partial updates (for example, the PATCH method defined in <a href="#RFC5789" id="rfc.xref.RFC5789.1"><cite title="PATCH Method for HTTP">[RFC5789]</cite></a>).
    2032       </p>
    2033       <p id="rfc.section.6.6.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
    2034          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 2.6</a> of <a href="#Part6" id="rfc.xref.Part6.16"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>).
    2035       </p>
    2036       <div id="rfc.iref.d.1"></div>
    2037       <div id="rfc.iref.m.6"></div>
    2038       <h2 id="rfc.section.6.7"><a href="#rfc.section.6.7">6.7</a>&nbsp;<a id="DELETE" href="#DELETE">DELETE</a></h2>
    2039       <p id="rfc.section.6.7.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
    2040          has been carried out, even if the status code returned from the origin server indicates that the action has been completed
    2041          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
    2042          location.
    2043       </p>
    2044       <p id="rfc.section.6.7.p.2">A successful response <em class="bcp14">SHOULD</em> be 200 (OK) if the response includes an representation describing the status, 202 (Accepted) if the action has not yet been
    2045          enacted, or 204 (No Content) if the action has been enacted but the response does not include a representation.
    2046       </p>
    2047       <p id="rfc.section.6.7.p.3">Bodies on DELETE requests have no defined semantics. Note that sending a body on a DELETE request might cause some existing
    2048          implementations to reject the request.
    2049       </p>
    2050       <p id="rfc.section.6.7.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
    2051          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 2.6</a> of <a href="#Part6" id="rfc.xref.Part6.17"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>).
    2052       </p>
    2053       <h2 id="rfc.section.6.8"><a href="#rfc.section.6.8">6.8</a>&nbsp;<a id="TRACE" href="#TRACE">TRACE</a></h2>
    2054       <div id="rfc.iref.t.1"></div>
    2055       <div id="rfc.iref.m.7"></div>
    2056       <p id="rfc.section.6.8.p.1">The TRACE method requests a remote, application-layer loop-back of the request message. The final recipient of the request <em class="bcp14">SHOULD</em> reflect the message received back to the client as the message body of a 200 (OK) response. The final recipient is either
    2057          the origin server or the first proxy to receive a Max-Forwards value of zero (0) in the request (see <a href="#header.max-forwards" id="rfc.xref.header.max-forwards.3" title="Max-Forwards">Section&nbsp;8.6</a>). A TRACE request <em class="bcp14">MUST NOT</em> include a message body.
    2058       </p>
    2059       <p id="rfc.section.6.8.p.2">TRACE allows the client to see what is being received at the other end of the request chain and use that data for testing
    2060          or diagnostic information. The value of the Via header field (<a href="p1-messaging.html#header.via" title="Via">Section 6.2</a> of <a href="#Part1" id="rfc.xref.Part1.35"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) is of particular interest, since it acts as a trace of the request chain. Use of the Max-Forwards header field allows the
    2061          client to limit the length of the request chain, which is useful for testing a chain of proxies forwarding messages in an
    2062          infinite loop.
    2063       </p>
    2064       <p id="rfc.section.6.8.p.3">If the request is valid, the response <em class="bcp14">SHOULD</em> have a Content-Type 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.36"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[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.
    2065       </p>
    2066       <div id="rfc.iref.c.1"></div>
    2067       <div id="rfc.iref.m.8"></div>
    2068       <h2 id="rfc.section.6.9"><a href="#rfc.section.6.9">6.9</a>&nbsp;<a id="CONNECT" href="#CONNECT">CONNECT</a></h2>
    2069       <p id="rfc.section.6.9.p.1">The CONNECT method requests that the proxy establish a tunnel to the request-target and, if successful, thereafter restrict
    2070          its behavior to blind forwarding of packets until the connection is closed.
    2071       </p>
    2072       <p id="rfc.section.6.9.p.2">When using CONNECT, the request-target <em class="bcp14">MUST</em> use the authority form (<a href="p1-messaging.html#request-target" title="Request Target">Section 5.3</a> of <a href="#Part1" id="rfc.xref.Part1.37"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>); i.e., the request-target consists of only the host name and port number of the tunnel destination, separated by a colon.
    2073          For example,
    2074       </p>
    2075       <div id="rfc.figure.u.7"></div><pre class="text2">CONNECT server.example.com:80 HTTP/1.1
    2076 Host: server.example.com:80
    2077 
    2078 </pre><p id="rfc.section.6.9.p.4">Any successful (2xx) response to a CONNECT request indicates that the proxy has established a connection to the requested
    2079          host and port, and has switched to tunneling the current connection to that server connection. The tunneled data from the
    2080          server begins immediately after the blank line that concludes the successful response's header block. A server <em class="bcp14">SHOULD NOT</em> send any Transfer-Encoding or Content-Length 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.
    2081       </p>
    2082       <p id="rfc.section.6.9.p.5">Any response other than a successful response indicates that the tunnel has not yet been formed and that the connection remains
    2083          governed by HTTP.
    2084       </p>
    2085       <p id="rfc.section.6.9.p.6">Proxy authentication might be used to establish the authority to create a tunnel:</p>
    2086       <div id="rfc.figure.u.8"></div><pre class="text2">CONNECT server.example.com:80 HTTP/1.1
    2087 Host: server.example.com:80
    2088 Proxy-Authorization: basic aGVsbG86d29ybGQ=
    2089 
    2090 </pre><p id="rfc.section.6.9.p.8">A message body on a CONNECT request has no defined semantics. Sending a body on a CONNECT request might cause existing implementations
    2091          to reject the request.
    2092       </p>
    2093       <p id="rfc.section.6.9.p.9">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 may be discarded
    2094          if the eventual response is negative, and the connection may be reset with no response if more than one TCP segment is outstanding.
    2095       </p>
    2096       <p id="rfc.section.6.9.p.10">It may be the case that the proxy itself can only reach the requested origin server through another proxy. In this case, the
    2097          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 2xx status code unless it has either a direct or tunnel connection established to the authority.
    2098       </p>
    2099       <p id="rfc.section.6.9.p.11">If at any point either one of the peers gets disconnected, any outstanding data that came from that peer will be passed to
    2100          the other one, and after that also the other connection will be terminated by the proxy. If there is outstanding data to that
    2101          peer undelivered, that data will be discarded.
    2102       </p>
    2103       <p id="rfc.section.6.9.p.12">An origin server which receives a CONNECT request for itself <em class="bcp14">MAY</em> respond with a 2xx status code to indicate that a connection is established. However, most origin servers do not implement
    2104          CONNECT.
    2105       </p>
    2106       <h1 id="rfc.section.7"><a href="#rfc.section.7">7.</a>&nbsp;<a id="common.protocol.parameters" href="#common.protocol.parameters">Common Protocol Parameters</a></h1>
    2107       <h2 id="rfc.section.7.1"><a href="#rfc.section.7.1">7.1</a>&nbsp;<a id="http.date" href="#http.date">Date/Time Formats</a></h2>
    2108       <p id="rfc.section.7.1.p.1">HTTP applications have historically allowed three different formats for date/time stamps. However, the preferred format is
     2053      <h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a>&nbsp;<a id="common.protocol.parameters" href="#common.protocol.parameters">Common Protocol Parameters</a></h1>
     2054      <h2 id="rfc.section.6.1"><a href="#rfc.section.6.1">6.1</a>&nbsp;<a id="http.date" href="#http.date">Date/Time Formats</a></h2>
     2055      <p id="rfc.section.6.1.p.1">HTTP applications have historically allowed three different formats for date/time stamps. However, the preferred format is
    21092056         a fixed-length subset of that defined by <a href="#RFC1123" id="rfc.xref.RFC1123.1"><cite title="Requirements for Internet Hosts - Application and Support">[RFC1123]</cite></a>:
    21102057      </p>
    21112058      <div id="rfc.figure.u.9"></div><pre class="text">Sun, 06 Nov 1994 08:49:37 GMT  ; RFC 1123
    2112 </pre><p id="rfc.section.7.1.p.3">The other formats are described here only for compatibility with obsolete implementations.</p>
     2059</pre><p id="rfc.section.6.1.p.3">The other formats are described here only for compatibility with obsolete implementations.</p>
    21132060      <div id="rfc.figure.u.10"></div><pre class="text">Sunday, 06-Nov-94 08:49:37 GMT ; obsolete RFC 850 format
    21142061Sun Nov  6 08:49:37 1994       ; ANSI C's asctime() format
    2115 </pre><p id="rfc.section.7.1.p.5">HTTP/1.1 clients and servers that parse a date value <em class="bcp14">MUST</em> accept all three formats (for compatibility with HTTP/1.0), though they <em class="bcp14">MUST</em> only generate the RFC 1123 format for representing HTTP-date values in header fields.
    2116       </p>
    2117       <p id="rfc.section.7.1.p.6">All HTTP date/time stamps <em class="bcp14">MUST</em> be represented in Greenwich Mean Time (GMT), without exception. For the purposes of HTTP, GMT is exactly equal to UTC (Coordinated
     2062</pre><p id="rfc.section.6.1.p.5">HTTP/1.1 clients and servers that parse a date value <em class="bcp14">MUST</em> accept all three formats (for compatibility with HTTP/1.0), though they <em class="bcp14">MUST</em> only generate the RFC 1123 format for representing HTTP-date values in header fields.
     2063      </p>
     2064      <p id="rfc.section.6.1.p.6">All HTTP date/time stamps <em class="bcp14">MUST</em> be represented in Greenwich Mean Time (GMT), without exception. For the purposes of HTTP, GMT is exactly equal to UTC (Coordinated
    21182065         Universal Time). This is indicated in the first two formats by the inclusion of "GMT" as the three-letter abbreviation for
    21192066         time zone, and <em class="bcp14">MUST</em> be assumed when reading the asctime format. HTTP-date is case sensitive and <em class="bcp14">MUST NOT</em> include additional whitespace beyond that specifically included as SP in the grammar.
    … …  
    21212068      <div id="rfc.figure.u.11"></div><pre class="inline"><span id="rfc.iref.g.6"></span>  <a href="#http.date" class="smpl">HTTP-date</a>    = <a href="#preferred.date.format" class="smpl">rfc1123-date</a> / <a href="#obsolete.date.formats" class="smpl">obs-date</a>
    21222069</pre><div id="preferred.date.format">
    2123          <p id="rfc.section.7.1.p.8">                    Preferred format:</p>
     2070         <p id="rfc.section.6.1.p.8">                    Preferred format:</p>
    21242071      </div>
    21252072      <div id="rfc.figure.u.12"></div><pre class="inline"><span id="rfc.iref.g.7"></span><span id="rfc.iref.g.8"></span><span id="rfc.iref.g.9"></span><span id="rfc.iref.g.10"></span><span id="rfc.iref.g.11"></span><span id="rfc.iref.g.12"></span><span id="rfc.iref.g.13"></span><span id="rfc.iref.g.14"></span><span id="rfc.iref.g.15"></span><span id="rfc.iref.g.16"></span><span id="rfc.iref.g.17"></span><span id="rfc.iref.g.18"></span>  <a href="#preferred.date.format" class="smpl">rfc1123-date</a> = <a href="#preferred.date.format" class="smpl">day-name</a> "," <a href="#notation" class="smpl">SP</a> date1 <a href="#notation" class="smpl">SP</a> <a href="#preferred.date.format" class="smpl">time-of-day</a> <a href="#notation" class="smpl">SP</a> <a href="#preferred.date.format" class="smpl">GMT</a>
    … …  
    21612108  <a href="#preferred.date.format" class="smpl">minute</a>       = 2<a href="#notation" class="smpl">DIGIT</a>               
    21622109  <a href="#preferred.date.format" class="smpl">second</a>       = 2<a href="#notation" class="smpl">DIGIT</a>               
    2163 </pre><p id="rfc.section.7.1.p.10">The semantics of <a href="#preferred.date.format" class="smpl">day-name</a>, <a href="#preferred.date.format" class="smpl">day</a>, <a href="#preferred.date.format" class="smpl">month</a>, <a href="#preferred.date.format" class="smpl">year</a>, and <a href="#preferred.date.format" class="smpl">time-of-day</a> are the same as those defined for the RFC 5322 constructs with the corresponding name (<a href="#RFC5322" id="rfc.xref.RFC5322.1"><cite title="Internet Message Format">[RFC5322]</cite></a>, <a href="http://tools.ietf.org/html/rfc5322#section-3.3">Section 3.3</a>).
     2110</pre><p id="rfc.section.6.1.p.10">The semantics of <a href="#preferred.date.format" class="smpl">day-name</a>, <a href="#preferred.date.format" class="smpl">day</a>, <a href="#preferred.date.format" class="smpl">month</a>, <a href="#preferred.date.format" class="smpl">year</a>, and <a href="#preferred.date.format" class="smpl">time-of-day</a> are the same as those defined for the RFC 5322 constructs with the corresponding name (<a href="#RFC5322" id="rfc.xref.RFC5322.1"><cite title="Internet Message Format">[RFC5322]</cite></a>, <a href="http://tools.ietf.org/html/rfc5322#section-3.3">Section 3.3</a>).
    21642111      </p>
    21652112      <div id="obsolete.date.formats">
    2166          <p id="rfc.section.7.1.p.11">                Obsolete formats:</p>
     2113         <p id="rfc.section.6.1.p.11">                Obsolete formats:</p>
    21672114      </div>
    21682115      <div id="rfc.figure.u.13"></div><pre class="inline"><span id="rfc.iref.g.19"></span>  <a href="#obsolete.date.formats" class="smpl">obs-date</a>     = <a href="#obsolete.date.formats" class="smpl">rfc850-date</a> / <a href="#obsolete.date.formats" class="smpl">asctime-date</a>
    … …  
    21812128  <a href="#obsolete.date.formats" class="smpl">date3</a>        = <a href="#preferred.date.format" class="smpl">month</a> <a href="#notation" class="smpl">SP</a> ( 2<a href="#notation" class="smpl">DIGIT</a> / ( <a href="#notation" class="smpl">SP</a> 1<a href="#notation" class="smpl">DIGIT</a> ))
    21822129                 ; month day (e.g., Jun  2)
    2183 </pre><div class="note" id="rfc.section.7.1.p.15">
     2130</pre><div class="note" id="rfc.section.6.1.p.15">
    21842131         <p> <b>Note:</b> Recipients of date values are encouraged to be robust in accepting date values that might have been sent by non-HTTP applications,
    21852132            as is sometimes the case when retrieving or posting messages via proxies/gateways to SMTP or NNTP.
    21862133         </p>
    21872134      </div>
    2188       <div class="note" id="rfc.section.7.1.p.16">
     2135      <div class="note" id="rfc.section.6.1.p.16">
    21892136         <p> <b>Note:</b> HTTP requirements for the date/time stamp format apply only to their usage within the protocol stream. Clients and servers
    21902137            are not required to use these formats for user presentation, request logging, etc.
    21912138         </p>
    21922139      </div>
    2193       <h2 id="rfc.section.7.2"><a href="#rfc.section.7.2">7.2</a>&nbsp;<a id="product.tokens" href="#product.tokens">Product Tokens</a></h2>
    2194       <p id="rfc.section.7.2.p.1">Product tokens are used to allow communicating applications to identify themselves by software name and version. Most fields
     2140      <h2 id="rfc.section.6.2"><a href="#rfc.section.6.2">6.2</a>&nbsp;<a id="product.tokens" href="#product.tokens">Product Tokens</a></h2>
     2141      <p id="rfc.section.6.2.p.1">Product tokens are used to allow communicating applications to identify themselves by software name and version. Most fields
    21952142         using product tokens also allow sub-products which form a significant part of the application to be listed, separated by whitespace.
    21962143         By convention, the products are listed in order of their significance for identifying the application.
    … …  
    21982145      <div id="rfc.figure.u.16"></div><pre class="inline"><span id="rfc.iref.g.22"></span><span id="rfc.iref.g.23"></span>  <a href="#product.tokens" class="smpl">product</a>         = <a href="#core.rules" class="smpl">token</a> ["/" <a href="#product.tokens" class="smpl">product-version</a>]
    21992146  <a href="#product.tokens" class="smpl">product-version</a> = <a href="#core.rules" class="smpl">token</a>
    2200 </pre><p id="rfc.section.7.2.p.3">Examples:</p>
     2147</pre><p id="rfc.section.6.2.p.3">Examples:</p>
    22012148      <div id="rfc.figure.u.17"></div><pre class="text">  User-Agent: CERN-LineMode/2.15 libwww/2.17b3
    22022149  Server: Apache/0.8.4
    2203 </pre><p id="rfc.section.7.2.p.5">Product tokens <em class="bcp14">SHOULD</em> be short and to the point. They <em class="bcp14">MUST NOT</em> be used for advertising or other non-essential information. Although any token octet <em class="bcp14">MAY</em> appear in a product-version, this token <em class="bcp14">SHOULD</em> only be used for a version identifier (i.e., successive versions of the same product <em class="bcp14">SHOULD</em> only differ in the product-version portion of the product value).
    2204       </p>
    2205       <h1 id="rfc.section.8"><a href="#rfc.section.8">8.</a>&nbsp;<a id="header.field.definitions" href="#header.field.definitions">Header Field Definitions</a></h1>
    2206       <p id="rfc.section.8.p.1">This section defines the syntax and semantics of HTTP/1.1 header fields related to request and response semantics.</p>
     2150</pre><p id="rfc.section.6.2.p.5">Product tokens <em class="bcp14">SHOULD</em> be short and to the point. They <em class="bcp14">MUST NOT</em> be used for advertising or other non-essential information. Although any token octet <em class="bcp14">MAY</em> appear in a product-version, this token <em class="bcp14">SHOULD</em> only be used for a version identifier (i.e., successive versions of the same product <em class="bcp14">SHOULD</em> only differ in the product-version portion of the product value).
     2151      </p>
     2152      <h1 id="rfc.section.7"><a href="#rfc.section.7">7.</a>&nbsp;<a id="header.field.definitions" href="#header.field.definitions">Header Field Definitions</a></h1>
     2153      <p id="rfc.section.7.p.1">This section defines the syntax and semantics of HTTP/1.1 header fields related to request and response semantics.</p>
    22072154      <div id="rfc.iref.a.1"></div>
    22082155      <div id="rfc.iref.h.2"></div>
    2209       <h2 id="rfc.section.8.1"><a href="#rfc.section.8.1">8.1</a>&nbsp;<a id="header.allow" href="#header.allow">Allow</a></h2>
    2210       <p id="rfc.section.8.1.p.1">The "Allow" header field lists the set of methods advertised as supported by the target resource. The purpose of this field
     2156      <h2 id="rfc.section.7.1"><a href="#rfc.section.7.1">7.1</a>&nbsp;<a id="header.allow" href="#header.allow">Allow</a></h2>
     2157      <p id="rfc.section.7.1.p.1">The "Allow" header field lists the set of methods advertised as supported by the target resource. The purpose of this field
    22112158         is strictly to inform the recipient of valid request methods associated with the resource.
    22122159      </p>
    2213       <div id="rfc.figure.u.18"></div><pre class="inline"><span id="rfc.iref.g.24"></span>  <a href="#header.allow" class="smpl">Allow</a> = #<a href="#method" class="smpl">method</a>
    2214 </pre><p id="rfc.section.8.1.p.3">Example of use:</p>
     2160      <div id="rfc.figure.u.18"></div><pre class="inline"><span id="rfc.iref.g.24"></span>  <a href="#header.allow" class="smpl">Allow</a> = #<a href="#methods" class="smpl">method</a>
     2161</pre><p id="rfc.section.7.1.p.3">Example of use:</p>
    22152162      <div id="rfc.figure.u.19"></div><pre class="text">  Allow: GET, HEAD, PUT
    2216 </pre><p id="rfc.section.8.1.p.5">The actual set of allowed methods is defined by the origin server at the time of each request.</p>
    2217       <p id="rfc.section.8.1.p.6">A proxy <em class="bcp14">MUST NOT</em> modify the Allow header field — it does not need to understand all the methods specified in order to handle them according
     2163</pre><p id="rfc.section.7.1.p.5">The actual set of allowed methods is defined by the origin server at the time of each request.</p>
     2164      <p id="rfc.section.7.1.p.6">A proxy <em class="bcp14">MUST NOT</em> modify the Allow header field — it does not need to understand all the methods specified in order to handle them according
    22182165         to the generic message handling rules.
    22192166      </p>
    22202167      <div id="rfc.iref.d.2"></div>
    22212168      <div id="rfc.iref.h.3"></div>
    2222       <h2 id="rfc.section.8.2"><a href="#rfc.section.8.2">8.2</a>&nbsp;<a id="header.date" href="#header.date">Date</a></h2>
    2223       <p id="rfc.section.8.2.p.1">The "Date" header field represents the date and time at which the message was originated, having the same semantics as the
    2224          Origination Date Field (orig-date) defined in <a href="http://tools.ietf.org/html/rfc5322#section-3.6.1">Section 3.6.1</a> of <a href="#RFC5322" id="rfc.xref.RFC5322.2"><cite title="Internet Message Format">[RFC5322]</cite></a>. The field value is an HTTP-date, as defined in <a href="#http.date" title="Date/Time Formats">Section&nbsp;7.1</a>; it <em class="bcp14">MUST</em> be sent in rfc1123-date format.
     2169      <h2 id="rfc.section.7.2"><a href="#rfc.section.7.2">7.2</a>&nbsp;<a id="header.date" href="#header.date">Date</a></h2>
     2170      <p id="rfc.section.7.2.p.1">The "Date" header field represents the date and time at which the message was originated, having the same semantics as the
     2171         Origination Date Field (orig-date) defined in <a href="http://tools.ietf.org/html/rfc5322#section-3.6.1">Section 3.6.1</a> of <a href="#RFC5322" id="rfc.xref.RFC5322.2"><cite title="Internet Message Format">[RFC5322]</cite></a>. The field value is an HTTP-date, as defined in <a href="#http.date" title="Date/Time Formats">Section&nbsp;6.1</a>; it <em class="bcp14">MUST</em> be sent in rfc1123-date format.
    22252172      </p>
    22262173      <div id="rfc.figure.u.20"></div><pre class="inline"><span id="rfc.iref.g.25"></span>  <a href="#header.date" class="smpl">Date</a> = <a href="#http.date" class="smpl">HTTP-date</a>
    2227 </pre><p id="rfc.section.8.2.p.3">An example is</p>
     2174</pre><p id="rfc.section.7.2.p.3">An example is</p>
    22282175      <div id="rfc.figure.u.21"></div><pre class="text">  Date: Tue, 15 Nov 1994 08:12:31 GMT
    2229 </pre><p id="rfc.section.8.2.p.5">Origin servers <em class="bcp14">MUST</em> include a Date header field in all responses, except in these cases:
     2176</pre><p id="rfc.section.7.2.p.5">Origin servers <em class="bcp14">MUST</em> include a Date header field in all responses, except in these cases:
    22302177      </p>
    22312178      <ol>
    … …  
    22382185         </li>
    22392186      </ol>
    2240       <p id="rfc.section.8.2.p.6">A received message that does not have a Date header field <em class="bcp14">MUST</em> be assigned one by the recipient if the message will be cached by that recipient.
    2241       </p>
    2242       <p id="rfc.section.8.2.p.7">Clients can use the Date header field as well; in order to keep request messages small, they are advised not to include it
     2187      <p id="rfc.section.7.2.p.6">A received message that does not have a Date header field <em class="bcp14">MUST</em> be assigned one by the recipient if the message will be cached by that recipient.
     2188      </p>
     2189      <p id="rfc.section.7.2.p.7">Clients can use the Date header field as well; in order to keep request messages small, they are advised not to include it
    22432190         when it doesn't convey any useful information (as is usually the case for requests that do not contain a payload).
    22442191      </p>
    2245       <p id="rfc.section.8.2.p.8">The HTTP-date sent in a Date header field <em class="bcp14">SHOULD NOT</em> represent a date and time subsequent to the generation of the message. It <em class="bcp14">SHOULD</em> represent the best available approximation of the date and time of message generation, unless the implementation has no means
     2192      <p id="rfc.section.7.2.p.8">The HTTP-date sent in a Date header field <em class="bcp14">SHOULD NOT</em> represent a date and time subsequent to the generation of the message. It <em class="bcp14">SHOULD</em> represent the best available approximation of the date and time of message generation, unless the implementation has no means
    22462193         of generating a reasonably accurate date and time. In theory, the date ought to represent the moment just before the payload
    22472194         is generated. In practice, the date can be generated at any time during the message origination without affecting its semantic
    … …  
    22502197      <div id="rfc.iref.e.1"></div>
    22512198      <div id="rfc.iref.h.4"></div>
    2252       <h2 id="rfc.section.8.3"><a href="#rfc.section.8.3">8.3</a>&nbsp;<a id="header.expect" href="#header.expect">Expect</a></h2>
    2253       <p id="rfc.section.8.3.p.1">The "Expect" header field is used to indicate that particular server behaviors are required by the client.</p>
     2199      <h2 id="rfc.section.7.3"><a href="#rfc.section.7.3">7.3</a>&nbsp;<a id="header.expect" href="#header.expect">Expect</a></h2>
     2200      <p id="rfc.section.7.3.p.1">The "Expect" header field is used to indicate that particular server behaviors are required by the client.</p>
    22542201      <div id="rfc.figure.u.22"></div><pre class="inline"><span id="rfc.iref.g.26"></span><span id="rfc.iref.g.27"></span><span id="rfc.iref.g.28"></span><span id="rfc.iref.g.29"></span><span id="rfc.iref.g.30"></span>  <a href="#header.expect" class="smpl">Expect</a>       = 1#<a href="#header.expect" class="smpl">expectation</a>
    22552202 
    … …  
    22602207  <a href="#header.expect" class="smpl">expect-name</a>  = <a href="#core.rules" class="smpl">token</a>
    22612208  <a href="#header.expect" class="smpl">expect-value</a> = <a href="#core.rules" class="smpl">token</a> / <a href="#core.rules" class="smpl">quoted-string</a>
    2262 </pre><p id="rfc.section.8.3.p.3">If all received Expect header field(s) are syntactically valid but contain an expectation that the recipient does not understand
     2209</pre><p id="rfc.section.7.3.p.3">If all received Expect header field(s) are syntactically valid but contain an expectation that the recipient does not understand
    22632210         or cannot comply with, the recipient <em class="bcp14">MUST</em> respond with a 417 (Expectation Failed) status code. A recipient of a syntactically invalid Expectation header field <em class="bcp14">MUST</em> respond with a 4xx status code other than 417.
    22642211      </p>
    2265       <p id="rfc.section.8.3.p.4">The only expectation defined by this specification is:</p>
    2266       <p id="rfc.section.8.3.p.5"><span id="rfc.iref.89"></span><span id="rfc.iref.e.2"></span> 100-continue
     2212      <p id="rfc.section.7.3.p.4">The only expectation defined by this specification is:</p>
     2213      <p id="rfc.section.7.3.p.5"><span id="rfc.iref.89"></span><span id="rfc.iref.e.2"></span> 100-continue
    22672214      </p>
    22682215      <ul class="empty">
    … …  
    22702217         </li>
    22712218      </ul>
    2272       <p id="rfc.section.8.3.p.6">Comparison is case-insensitive for names (expect-name), and case-sensitive for values (expect-value).</p>
    2273       <p id="rfc.section.8.3.p.7">The Expect mechanism is hop-by-hop: the above requirements apply to any server, including proxies. However, the Expect header
     2219      <p id="rfc.section.7.3.p.6">Comparison is case-insensitive for names (expect-name), and case-sensitive for values (expect-value).</p>
     2220      <p id="rfc.section.7.3.p.7">The Expect mechanism is hop-by-hop: the above requirements apply to any server, including proxies. However, the Expect header
    22742221         field itself is end-to-end; it <em class="bcp14">MUST</em> be forwarded if the request is forwarded.
    22752222      </p>
    2276       <p id="rfc.section.8.3.p.8">Many older HTTP/1.0 and HTTP/1.1 applications do not understand the Expect header field.</p>
     2223      <p id="rfc.section.7.3.p.8">Many older HTTP/1.0 and HTTP/1.1 applications do not understand the Expect header field.</p>
    22772224      <div id="rfc.iref.f.1"></div>
    22782225      <div id="rfc.iref.h.5"></div>
    2279       <h2 id="rfc.section.8.4"><a href="#rfc.section.8.4">8.4</a>&nbsp;<a id="header.from" href="#header.from">From</a></h2>
    2280       <p id="rfc.section.8.4.p.1">The "From" header field, if given, <em class="bcp14">SHOULD</em> contain an Internet e-mail address for the human user who controls the requesting user agent. The address <em class="bcp14">SHOULD</em> be machine-usable, as defined by "mailbox" in <a href="http://tools.ietf.org/html/rfc5322#section-3.4">Section 3.4</a> of <a href="#RFC5322" id="rfc.xref.RFC5322.3"><cite title="Internet Message Format">[RFC5322]</cite></a>:
     2226      <h2 id="rfc.section.7.4"><a href="#rfc.section.7.4">7.4</a>&nbsp;<a id="header.from" href="#header.from">From</a></h2>
     2227      <p id="rfc.section.7.4.p.1">The "From" header field, if given, <em class="bcp14">SHOULD</em> contain an Internet e-mail address for the human user who controls the requesting user agent. The address <em class="bcp14">SHOULD</em> be machine-usable, as defined by "mailbox" in <a href="http://tools.ietf.org/html/rfc5322#section-3.4">Section 3.4</a> of <a href="#RFC5322" id="rfc.xref.RFC5322.3"><cite title="Internet Message Format">[RFC5322]</cite></a>:
    22812228      </p>
    22822229      <div id="rfc.figure.u.23"></div><pre class="inline"><span id="rfc.iref.g.31"></span>  <a href="#header.from" class="smpl">From</a>    = <a href="#header.from" class="smpl">mailbox</a>
    22832230 
    22842231  <a href="#header.from" class="smpl">mailbox</a> = &lt;mailbox, defined in <a href="#RFC5322" id="rfc.xref.RFC5322.4"><cite title="Internet Message Format">[RFC5322]</cite></a>, <a href="http://tools.ietf.org/html/rfc5322#section-3.4">Section 3.4</a>&gt;
    2285 </pre><p id="rfc.section.8.4.p.3">An example is:</p>
     2232</pre><p id="rfc.section.7.4.p.3">An example is:</p>
    22862233      <div id="rfc.figure.u.24"></div><pre class="text">  From: webmaster@example.org
    2287 </pre><p id="rfc.section.8.4.p.5">This header field <em class="bcp14">MAY</em> be used for logging purposes and as a means for identifying the source of invalid or unwanted requests. It <em class="bcp14">SHOULD NOT</em> be used as an insecure form of access protection. The interpretation of this field is that the request is being performed
     2234</pre><p id="rfc.section.7.4.p.5">This header field <em class="bcp14">MAY</em> be used for logging purposes and as a means for identifying the source of invalid or unwanted requests. It <em class="bcp14">SHOULD NOT</em> be used as an insecure form of access protection. The interpretation of this field is that the request is being performed
    22882235         on behalf of the person given, who accepts responsibility for the method performed. In particular, robot agents <em class="bcp14">SHOULD</em> include this header field so that the person responsible for running the robot can be contacted if problems occur on the receiving
    22892236         end.
    22902237      </p>
    2291       <p id="rfc.section.8.4.p.6">The Internet e-mail address in this field <em class="bcp14">MAY</em> be separate from the Internet host which issued the request. For example, when a request is passed through a proxy the original
     2238      <p id="rfc.section.7.4.p.6">The Internet e-mail address in this field <em class="bcp14">MAY</em> be separate from the Internet host which issued the request. For example, when a request is passed through a proxy the original
    22922239         issuer's address <em class="bcp14">SHOULD</em> be used.
    22932240      </p>
    2294       <p id="rfc.section.8.4.p.7">The client <em class="bcp14">SHOULD NOT</em> send the From header field without the user's approval, as it might conflict with the user's privacy interests or their site's
     2241      <p id="rfc.section.7.4.p.7">The client <em class="bcp14">SHOULD NOT</em> send the From header field without the user's approval, as it might conflict with the user's privacy interests or their site's
    22952242         security policy. It is strongly recommended that the user be able to disable, enable, and modify the value of this field at
    22962243         any time prior to a request.
    … …  
    22982245      <div id="rfc.iref.l.1"></div>
    22992246      <div id="rfc.iref.h.6"></div>
    2300       <h2 id="rfc.section.8.5"><a href="#rfc.section.8.5">8.5</a>&nbsp;<a id="header.location" href="#header.location">Location</a></h2>
    2301       <p id="rfc.section.8.5.p.1">The "Location" header field <em class="bcp14">MAY</em> be sent in responses to refer to a specific resource in accordance with the semantics of the status code.
     2247      <h2 id="rfc.section.7.5"><a href="#rfc.section.7.5">7.5</a>&nbsp;<a id="header.location" href="#header.location">Location</a></h2>
     2248      <p id="rfc.section.7.5.p.1">The "Location" header field <em class="bcp14">MAY</em> be sent in responses to refer to a specific resource in accordance with the semantics of the status code.
    23022249      </p>
    23032250      <div id="rfc.figure.u.25"></div><pre class="inline"><span id="rfc.iref.g.32"></span>  <a href="#header.location" class="smpl">Location</a> = <a href="#abnf.dependencies" class="smpl">URI-reference</a>
    2304 </pre><p id="rfc.section.8.5.p.3">For 201 (Created) responses, the Location is the URI of the new resource which was created by the request. For 3xx responses,
     2251</pre><p id="rfc.section.7.5.p.3">For 201 (Created) responses, the Location is the URI of the new resource which was created by the request. For 3xx responses,
    23052252         the location <em class="bcp14">SHOULD</em> indicate the server's preferred URI for automatic redirection to the resource.
    23062253      </p>
    2307       <p id="rfc.section.8.5.p.4">The field value consists of a single URI-reference. When it has the form of a relative reference (<a href="#RFC3986" id="rfc.xref.RFC3986.1"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-4.2">Section 4.2</a>), the final value is computed by resolving it against the effective request URI (<a href="#RFC3986" id="rfc.xref.RFC3986.2"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-5">Section 5</a>). If the original URI, as navigated to by the user agent, did contain a fragment identifier, and the final value does not,
     2254      <p id="rfc.section.7.5.p.4">The field value consists of a single URI-reference. When it has the form of a relative reference (<a href="#RFC3986" id="rfc.xref.RFC3986.1"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-4.2">Section 4.2</a>), the final value is computed by resolving it against the effective request URI (<a href="#RFC3986" id="rfc.xref.RFC3986.2"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-5">Section 5</a>). If the original URI, as navigated to by the user agent, did contain a fragment identifier, and the final value does not,
    23082255         then the original URI's fragment identifier is added to the final value.
    23092256      </p>
    … …  
    23142261      <p>An original URI "http://www.example.org/index.html#larry", combined with a field value given as:</p>  <pre class="text">  Location: http://www.example.net/index.html
    23152262</pre>  <p>would result in a final value of "http://www.example.net/index.html#larry", preserving the original fragment identifier.</p>
    2316       <div class="note" id="rfc.section.8.5.p.7">
     2263      <div class="note" id="rfc.section.7.5.p.7">
    23172264         <p> <b>Note:</b> Some recipients attempt to recover from Location fields that are not valid URI references. This specification does not mandate
    23182265            or define such processing, but does allow it (see <a href="#intro.conformance.and.error.handling" title="Conformance and Error Handling">Section&nbsp;1.1</a>).
    23192266         </p>
    23202267      </div>
    2321       <p id="rfc.section.8.5.p.8">There are circumstances in which a fragment identifier in a Location URI would not be appropriate. For instance, when it appears
     2268      <p id="rfc.section.7.5.p.8">There are circumstances in which a fragment identifier in a Location URI would not be appropriate. For instance, when it appears
    23222269         in a 201 Created response, where the Location header field specifies the URI for the entire created resource.
    23232270      </p>
    2324       <div class="note" id="rfc.section.8.5.p.9">
     2271      <div class="note" id="rfc.section.7.5.p.9">
    23252272         <p> <b>Note:</b> The Content-Location header field (<a href="p3-payload.html#header.content-location" title="Content-Location">Section 6.7</a> of <a href="#Part3" id="rfc.xref.Part3.13"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>) differs from Location in that the Content-Location identifies the most specific resource corresponding to the enclosed representation.
    23262273            It is therefore possible for a response to contain header fields for both Location and Content-Location.
    … …  
    23292276      <div id="rfc.iref.m.9"></div>
    23302277      <div id="rfc.iref.h.7"></div>
    2331       <h2 id="rfc.section.8.6"><a href="#rfc.section.8.6">8.6</a>&nbsp;<a id="header.max-forwards" href="#header.max-forwards">Max-Forwards</a></h2>
    2332       <p id="rfc.section.8.6.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;6.8</a>) and OPTIONS (<a href="#OPTIONS" id="rfc.xref.OPTIONS.2" title="OPTIONS">Section&nbsp;6.2</a>) methods to limit the number of times that the request is forwarded by proxies. This can be useful when the client is attempting
     2278      <h2 id="rfc.section.7.6"><a href="#rfc.section.7.6">7.6</a>&nbsp;<a id="header.max-forwards" href="#header.max-forwards">Max-Forwards</a></h2>
     2279      <p id="rfc.section.7.6.p.1">The "Max-Forwards" header field provides a mechanism with the TRACE (<a href="#TRACE" id="rfc.xref.TRACE.1" title="TRACE">Section&nbsp;2.3.7</a>) and OPTIONS (<a href="#OPTIONS" id="rfc.xref.OPTIONS.1" title="OPTIONS">Section&nbsp;2.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
    23332280         to trace a request which appears to be failing or looping mid-chain.
    23342281      </p>
    23352282      <div id="rfc.figure.u.28"></div><pre class="inline"><span id="rfc.iref.g.33"></span>  <a href="#header.max-forwards" class="smpl">Max-Forwards</a> = 1*<a href="#notation" class="smpl">DIGIT</a>
    2336 </pre><p id="rfc.section.8.6.p.3">The Max-Forwards value is a decimal integer indicating the remaining number of times this request message can be forwarded.</p>
    2337       <p id="rfc.section.8.6.p.4">Each recipient of a TRACE or OPTIONS request containing a Max-Forwards header field <em class="bcp14">MUST</em> check and update its value prior to forwarding the request. If the received value is zero (0), the recipient <em class="bcp14">MUST NOT</em> forward the request; instead, it <em class="bcp14">MUST</em> respond as the final recipient. If the received Max-Forwards value is greater than zero, then the forwarded message <em class="bcp14">MUST</em> contain an updated Max-Forwards field with a value decremented by one (1).
    2338       </p>
    2339       <p id="rfc.section.8.6.p.5">The Max-Forwards header field <em class="bcp14">MAY</em> be ignored for all other request methods.
     2283</pre><p id="rfc.section.7.6.p.3">The Max-Forwards value is a decimal integer indicating the remaining number of times this request message can be forwarded.</p>
     2284      <p id="rfc.section.7.6.p.4">Each recipient of a TRACE or OPTIONS request containing a Max-Forwards header field <em class="bcp14">MUST</em> check and update its value prior to forwarding the request. If the received value is zero (0), the recipient <em class="bcp14">MUST NOT</em> forward the request; instead, it <em class="bcp14">MUST</em> respond as the final recipient. If the received Max-Forwards value is greater than zero, then the forwarded message <em class="bcp14">MUST</em> contain an updated Max-Forwards field with a value decremented by one (1).
     2285      </p>
     2286      <p id="rfc.section.7.6.p.5">The Max-Forwards header field <em class="bcp14">MAY</em> be ignored for all other request methods.
    23402287      </p>
    23412288      <div id="rfc.iref.r.1"></div>
    23422289      <div id="rfc.iref.h.8"></div>
    2343       <h2 id="rfc.section.8.7"><a href="#rfc.section.8.7">8.7</a>&nbsp;<a id="header.referer" href="#header.referer">Referer</a></h2>
    2344       <p id="rfc.section.8.7.p.1">The "Referer" [sic] header field allows the client to specify the URI of the resource from which the target URI was obtained
     2290      <h2 id="rfc.section.7.7"><a href="#rfc.section.7.7">7.7</a>&nbsp;<a id="header.referer" href="#header.referer">Referer</a></h2>
     2291      <p id="rfc.section.7.7.p.1">The "Referer" [sic] header field allows the client to specify the URI of the resource from which the target URI was obtained
    23452292         (the "referrer", although the header field is misspelled.).
    23462293      </p>
    2347       <p id="rfc.section.8.7.p.2">The Referer header field allows servers to generate lists of back-links to resources for interest, logging, optimized caching,
     2294      <p id="rfc.section.7.7.p.2">The Referer header field allows servers to generate lists of back-links to resources for interest, logging, optimized caching,
    23482295         etc. It also allows obsolete or mistyped links to be traced for maintenance. Some servers use Referer as a means of controlling
    23492296         where they allow links from (so-called "deep linking"), but legitimate requests do not always contain a Referer header field.
    23502297      </p>
    2351       <p id="rfc.section.8.7.p.3">If the target URI was obtained from a source that does not have its own URI (e.g., input from the user keyboard), the Referer
     2298      <p id="rfc.section.7.7.p.3">If the target URI was obtained from a source that does not have its own URI (e.g., input from the user keyboard), the Referer
    23522299         field <em class="bcp14">MUST</em> either be sent with the value "about:blank", or not be sent at all. Note that this requirement does not apply to sources with
    23532300         non-HTTP URIs (e.g., FTP).
    23542301      </p>
    23552302      <div id="rfc.figure.u.29"></div><pre class="inline"><span id="rfc.iref.g.34"></span>  <a href="#header.referer" class="smpl">Referer</a> = <a href="#abnf.dependencies" class="smpl">absolute-URI</a> / <a href="#abnf.dependencies" class="smpl">partial-URI</a>
    2356 </pre><p id="rfc.section.8.7.p.5">Example:</p>
     2303</pre><p id="rfc.section.7.7.p.5">Example:</p>
    23572304      <div id="rfc.figure.u.30"></div><pre class="text">  Referer: http://www.example.org/hypertext/Overview.html
    2358 </pre><p id="rfc.section.8.7.p.7">If the field value is a relative URI, it <em class="bcp14">SHOULD</em> be interpreted relative to the effective request URI. The URI <em class="bcp14">MUST NOT</em> include a fragment. See <a href="#encoding.sensitive.information.in.uris" title="Encoding Sensitive Information in URIs">Section&nbsp;10.2</a> for security considerations.
     2305</pre><p id="rfc.section.7.7.p.7">If the field value is a relative URI, it <em class="bcp14">SHOULD</em> be interpreted relative to the effective request URI. The URI <em class="bcp14">MUST NOT</em> include a fragment. See <a href="#encoding.sensitive.information.in.uris" title="Encoding Sensitive Information in URIs">Section&nbsp;9.2</a> for security considerations.
    23592306      </p>
    23602307      <div id="rfc.iref.r.2"></div>
    23612308      <div id="rfc.iref.h.9"></div>
    2362       <h2 id="rfc.section.8.8"><a href="#rfc.section.8.8">8.8</a>&nbsp;<a id="header.retry-after" href="#header.retry-after">Retry-After</a></h2>
    2363       <p id="rfc.section.8.8.p.1">The header "Retry-After" field can be used with a 503 (Service Unavailable) response to indicate how long the service is expected
     2309      <h2 id="rfc.section.7.8"><a href="#rfc.section.7.8">7.8</a>&nbsp;<a id="header.retry-after" href="#header.retry-after">Retry-After</a></h2>
     2310      <p id="rfc.section.7.8.p.1">The header "Retry-After" field can be used with a 503 (Service Unavailable) response to indicate how long the service is expected
    23642311         to be unavailable to the requesting client. This field <em class="bcp14">MAY</em> also be used with any 3xx (Redirection) response to indicate the minimum time the user-agent is asked to wait before issuing
    23652312         the redirected request.
    23662313      </p>
    2367       <p id="rfc.section.8.8.p.2">The value of this field can be either an HTTP-date or an integer number of seconds (in decimal) after the time of the response.</p>
     2314      <p id="rfc.section.7.8.p.2">The value of this field can be either an HTTP-date or an integer number of seconds (in decimal) after the time of the response.</p>
    23682315      <div id="rfc.figure.u.31"></div><pre class="inline"><span id="rfc.iref.g.35"></span>  <a href="#header.retry-after" class="smpl">Retry-After</a> = <a href="#http.date" class="smpl">HTTP-date</a> / <a href="#rule.delta-seconds" class="smpl">delta-seconds</a>
    23692316</pre><div id="rule.delta-seconds">
    2370          <p id="rfc.section.8.8.p.4">  Time spans are non-negative decimal integers, representing time in seconds.</p>
     2317         <p id="rfc.section.7.8.p.4">  Time spans are non-negative decimal integers, representing time in seconds.</p>
    23712318      </div>
    23722319      <div id="rfc.figure.u.32"></div><pre class="inline"><span id="rfc.iref.g.36"></span>  <a href="#rule.delta-seconds" class="smpl">delta-seconds</a>  = 1*<a href="#notation" class="smpl">DIGIT</a>
    2373 </pre><p id="rfc.section.8.8.p.6">Two examples of its use are</p>
     2320</pre><p id="rfc.section.7.8.p.6">Two examples of its use are</p>
    23742321      <div id="rfc.figure.u.33"></div><pre class="text">  Retry-After: Fri, 31 Dec 1999 23:59:59 GMT
    23752322  Retry-After: 120
    2376 </pre><p id="rfc.section.8.8.p.8">In the latter example, the delay is 2 minutes.</p>
     2323</pre><p id="rfc.section.7.8.p.8">In the latter example, the delay is 2 minutes.</p>
    23772324      <div id="rfc.iref.s.38"></div>
    23782325      <div id="rfc.iref.h.10"></div>
    2379       <h2 id="rfc.section.8.9"><a href="#rfc.section.8.9">8.9</a>&nbsp;<a id="header.server" href="#header.server">Server</a></h2>
    2380       <p id="rfc.section.8.9.p.1">The "Server" header field contains information about the software used by the origin server to handle the request.</p>
    2381       <p id="rfc.section.8.9.p.2">The field can contain multiple product tokens (<a href="#product.tokens" title="Product Tokens">Section&nbsp;7.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: URIs, Connections, and Message Parsing">[Part1]</cite></a>) identifying the server and any significant subproducts. The product tokens are listed in order of their significance for
     2326      <h2 id="rfc.section.7.9"><a href="#rfc.section.7.9">7.9</a>&nbsp;<a id="header.server" href="#header.server">Server</a></h2>
     2327      <p id="rfc.section.7.9.p.1">The "Server" header field contains information about the software used by the origin server to handle the request.</p>
     2328      <p id="rfc.section.7.9.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.39"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) identifying the server and any significant subproducts. The product tokens are listed in order of their significance for
    23822329         identifying the application.
    23832330      </p>
    23842331      <div id="rfc.figure.u.34"></div><pre class="inline"><span id="rfc.iref.g.37"></span>  <a href="#header.server" class="smpl">Server</a> = <a href="#product.tokens" class="smpl">product</a> *( <a href="#core.rules" class="smpl">RWS</a> ( <a href="#product.tokens" class="smpl">product</a> / <a href="#abnf.dependencies" class="smpl">comment</a> ) )
    2385 </pre><p id="rfc.section.8.9.p.4">Example:</p>
     2332</pre><p id="rfc.section.7.9.p.4">Example:</p>
    23862333      <div id="rfc.figure.u.35"></div><pre class="text">  Server: CERN/3.0 libwww/2.17
    2387 </pre><p id="rfc.section.8.9.p.6">If the response is being forwarded through a proxy, the proxy application <em class="bcp14">MUST NOT</em> modify the Server header field. Instead, it <em class="bcp14">MUST</em> include a Via field (as described in <a href="p1-messaging.html#header.via" title="Via">Section 6.2</a> of <a href="#Part1" id="rfc.xref.Part1.40"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).
    2388       </p>
    2389       <div class="note" id="rfc.section.8.9.p.7">
     2334</pre><p id="rfc.section.7.9.p.6">If the response is being forwarded through a proxy, the proxy application <em class="bcp14">MUST NOT</em> modify the Server header field. Instead, it <em class="bcp14">MUST</em> include a Via field (as described in <a href="p1-messaging.html#header.via" title="Via">Section 6.2</a> of <a href="#Part1" id="rfc.xref.Part1.40"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).
     2335      </p>
     2336      <div class="note" id="rfc.section.7.9.p.7">
    23902337         <p> <b>Note:</b> Revealing the specific software version of the server might allow the server machine to become more vulnerable to attacks
    23912338            against software that is known to contain security holes. Server implementors are encouraged to make this field a configurable
    … …  
    23952342      <div id="rfc.iref.u.1"></div>
    23962343      <div id="rfc.iref.h.11"></div>
    2397       <h2 id="rfc.section.8.10"><a href="#rfc.section.8.10">8.10</a>&nbsp;<a id="header.user-agent" href="#header.user-agent">User-Agent</a></h2>
    2398       <p id="rfc.section.8.10.p.1">The "User-Agent" header field contains information about the user agent originating the request. User agents <em class="bcp14">SHOULD</em> include this field with requests.
    2399       </p>
    2400       <p id="rfc.section.8.10.p.2">Typically, it is used for statistical purposes, the tracing of protocol violations, and tailoring responses to avoid particular
     2344      <h2 id="rfc.section.7.10"><a href="#rfc.section.7.10">7.10</a>&nbsp;<a id="header.user-agent" href="#header.user-agent">User-Agent</a></h2>
     2345      <p id="rfc.section.7.10.p.1">The "User-Agent" header field contains information about the user agent originating the request. User agents <em class="bcp14">SHOULD</em> include this field with requests.
     2346      </p>
     2347      <p id="rfc.section.7.10.p.2">Typically, it is used for statistical purposes, the tracing of protocol violations, and tailoring responses to avoid particular
    24012348         user agent limitations.
    24022349      </p>
    2403       <p id="rfc.section.8.10.p.3">The field can contain multiple product tokens (<a href="#product.tokens" title="Product Tokens">Section&nbsp;7.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.41"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) identifying the agent and its significant subproducts. By convention, the product tokens are listed in order of their significance
     2350      <p id="rfc.section.7.10.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.41"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) identifying the agent and its significant subproducts. By convention, the product tokens are listed in order of their significance
    24042351         for identifying the application.
    24052352      </p>
    2406       <p id="rfc.section.8.10.p.4">Because this field is usually sent on every request a user agent makes, implementations are encouraged not to include needlessly
     2353      <p id="rfc.section.7.10.p.4">Because this field is usually sent on every request a user agent makes, implementations are encouraged not to include needlessly
    24072354         fine-grained detail, and to limit (or even prohibit) the addition of subproducts by third parties. Overly long and detailed
    24082355         User-Agent field values make requests larger and can also be used to identify ("fingerprint") the user against their wishes.
    24092356      </p>
    2410       <p id="rfc.section.8.10.p.5">Likewise, implementations are encouraged not to use the product tokens of other implementations in order to declare compatibility
     2357      <p id="rfc.section.7.10.p.5">Likewise, implementations are encouraged not to use the product tokens of other implementations in order to declare compatibility
    24112358         with them, as this circumvents the purpose of the field. Finally, they are encouraged not to use comments to identify products;
    24122359         doing so makes the field value more difficult to parse.
    24132360      </p>
    24142361      <div id="rfc.figure.u.36"></div><pre class="inline"><span id="rfc.iref.g.38"></span>  <a href="#header.user-agent" class="smpl">User-Agent</a> = <a href="#product.tokens" class="smpl">product</a> *( <a href="#core.rules" class="smpl">RWS</a> ( <a href="#product.tokens" class="smpl">product</a> / <a href="#abnf.dependencies" class="smpl">comment</a> ) )
    2415 </pre><p id="rfc.section.8.10.p.7">Example:</p>
     2362</pre><p id="rfc.section.7.10.p.7">Example:</p>
    24162363      <div id="rfc.figure.u.37"></div><pre class="text">  User-Agent: CERN-LineMode/2.15 libwww/2.17b3
    2417 </pre><h1 id="rfc.section.9"><a href="#rfc.section.9">9.</a>&nbsp;<a id="IANA.considerations" href="#IANA.considerations">IANA Considerations</a></h1>
    2418       <h2 id="rfc.section.9.1"><a href="#rfc.section.9.1">9.1</a>&nbsp;<a id="method.registration" href="#method.registration">Method Registry</a></h2>
    2419       <p id="rfc.section.9.1.p.1">The registration procedure for HTTP request methods is defined by <a href="#method.registry" title="Method Registry">Section&nbsp;2.2</a> of this document.
    2420       </p>
    2421       <p id="rfc.section.9.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:
     2364</pre><h1 id="rfc.section.8"><a href="#rfc.section.8">8.</a>&nbsp;<a id="IANA.considerations" href="#IANA.considerations">IANA Considerations</a></h1>
     2365      <h2 id="rfc.section.8.1"><a href="#rfc.section.8.1">8.1</a>&nbsp;<a id="method.registration" href="#method.registration">Method Registry</a></h2>
     2366      <p id="rfc.section.8.1.p.1">The registration procedure for HTTP request methods is defined by <a href="#method.registry" title="Method Registry">Section&nbsp;2.2</a> of this document.
     2367      </p>
     2368      <p id="rfc.section.8.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:
    24222369      </p>
    24232370      <div id="rfc.table.1">
    … …  
    24352382                  <td class="left">CONNECT</td>
    24362383                  <td class="left">no</td>
    2437                   <td class="left"> <a href="#CONNECT" id="rfc.xref.CONNECT.2" title="CONNECT">Section&nbsp;6.9</a>
     2384                  <td class="left"> <a href="#CONNECT" id="rfc.xref.CONNECT.1" title="CONNECT">Section&nbsp;2.3.8</a>
    24382385                  </td>
    24392386               </tr>
    … …  
    24412388                  <td class="left">DELETE</td>
    24422389                  <td class="left">no</td>
    2443                   <td class="left"> <a href="#DELETE" id="rfc.xref.DELETE.2" title="DELETE">Section&nbsp;6.7</a>
     2390                  <td class="left"> <a href="#DELETE" id="rfc.xref.DELETE.1" title="DELETE">Section&nbsp;2.3.6</a>
    24442391                  </td>
    24452392               </tr>
    … …  
    24472394                  <td class="left">GET</td>
    24482395                  <td class="left">yes</td>
    2449                   <td class="left"> <a href="#GET" id="rfc.xref.GET.2" title="GET">Section&nbsp;6.3</a>
     2396                  <td class="left"> <a href="#GET" id="rfc.xref.GET.1" title="GET">Section&nbsp;2.3.2</a>
    24502397                  </td>
    24512398               </tr>
    … …  
    24532400                  <td class="left">HEAD</td>
    24542401                  <td class="left">yes</td>
    2455                   <td class="left"> <a href="#HEAD" id="rfc.xref.HEAD.2" title="HEAD">Section&nbsp;6.4</a>
     2402                  <td class="left"> <a href="#HEAD" id="rfc.xref.HEAD.1" title="HEAD">Section&nbsp;2.3.3</a>
    24562403                  </td>
    24572404               </tr>
    … …  
    24592406                  <td class="left">OPTIONS</td>
    24602407                  <td class="left">yes</td>
    2461                   <td class="left"> <a href="#OPTIONS" id="rfc.xref.OPTIONS.3" title="OPTIONS">Section&nbsp;6.2</a>
     2408                  <td class="left"> <a href="#OPTIONS" id="rfc.xref.OPTIONS.2" title="OPTIONS">Section&nbsp;2.3.1</a>
    24622409                  </td>
    24632410               </tr>
    … …  
    24652412                  <td class="left">POST</td>
    24662413                  <td class="left">no</td>
    2467                   <td class="left"> <a href="#POST" id="rfc.xref.POST.2" title="POST">Section&nbsp;6.5</a>
     2414                  <td class="left"> <a href="#POST" id="rfc.xref.POST.1" title="POST">Section&nbsp;2.3.4</a>
    24682415                  </td>
    24692416               </tr>
    … …  
    24712418                  <td class="left">PUT</td>
    24722419                  <td class="left">no</td>
    2473                   <td class="left"> <a href="#PUT" id="rfc.xref.PUT.2" title="PUT">Section&nbsp;6.6</a>
     2420                  <td class="left"> <a href="#PUT" id="rfc.xref.PUT.1" title="PUT">Section&nbsp;2.3.5</a>
    24742421                  </td>
    24752422               </tr>
    … …  
    24772424                  <td class="left">TRACE</td>
    24782425                  <td class="left">yes</td>
    2479                   <td class="left"> <a href="#TRACE" id="rfc.xref.TRACE.3" title="TRACE">Section&nbsp;6.8</a>
     2426                  <td class="left"> <a href="#TRACE" id="rfc.xref.TRACE.2" title="TRACE">Section&nbsp;2.3.7</a>
    24802427                  </td>
    24812428               </tr>
    … …  
    24832430         </table>
    24842431      </div>
    2485       <h2 id="rfc.section.9.2"><a href="#rfc.section.9.2">9.2</a>&nbsp;<a id="status.code.registration" href="#status.code.registration">Status Code Registry</a></h2>
    2486       <p id="rfc.section.9.2.p.1">The registration procedure for HTTP Status Codes — 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.1"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a> — is now defined by <a href="#status.code.registry" title="Status Code Registry">Section&nbsp;4.2</a> of this document.
    2487       </p>
    2488       <p id="rfc.section.9.2.p.2">The HTTP Status Code Registry located at &lt;<a href="http://www.iana.org/assignments/http-status-codes">http://www.iana.org/assignments/http-status-codes</a>&gt; shall be updated with the registrations below:
     2432      <h2 id="rfc.section.8.2"><a href="#rfc.section.8.2">8.2</a>&nbsp;<a id="status.code.registration" href="#status.code.registration">Status Code Registry</a></h2>
     2433      <p id="rfc.section.8.2.p.1">The registration procedure for HTTP Status Codes — 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.1"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a> — is now defined by <a href="#status.code.registry" title="Status Code Registry">Section&nbsp;4.2</a> of this document.
     2434      </p>
     2435      <p id="rfc.section.8.2.p.2">The HTTP Status Code Registry located at &lt;<a href="http://www.iana.org/assignments/http-status-codes">http://www.iana.org/assignments/http-status-codes</a>&gt; shall be updated with the registrations below:
    24892436      </p>
    24902437      <div id="rfc.table.2">
    … …  
    27182665         </table>
    27192666      </div>
    2720       <h2 id="rfc.section.9.3"><a href="#rfc.section.9.3">9.3</a>&nbsp;<a id="header.field.registration" href="#header.field.registration">Header Field Registration</a></h2>
    2721       <p id="rfc.section.9.3.p.1">The Message Header Field Registry located at &lt;<a href="http://www.iana.org/assignments/message-headers/message-header-index.html">http://www.iana.org/assignments/message-headers/message-header-index.html</a>&gt; shall be updated with the permanent registrations below (see <a href="#RFC3864" id="rfc.xref.RFC3864.3"><cite title="Registration Procedures for Message Header Fields">[RFC3864]</cite></a>):
     2667      <h2 id="rfc.section.8.3"><a href="#rfc.section.8.3">8.3</a>&nbsp;<a id="header.field.registration" href="#header.field.registration">Header Field Registration</a></h2>
     2668      <p id="rfc.section.8.3.p.1">The Message Header Field Registry located at &lt;<a href="http://www.iana.org/assignments/message-headers/message-header-index.html">http://www.iana.org/assignments/message-headers/message-header-index.html</a>&gt; shall be updated with the permanent registrations below (see <a href="#RFC3864" id="rfc.xref.RFC3864.3"><cite title="Registration Procedures for Message Header Fields">[RFC3864]</cite></a>):
    27222669      </p>
    27232670      <div id="rfc.table.3">
    … …  
    27372684                  <td class="left">http</td>
    27382685                  <td class="left">standard</td>
    2739                   <td class="left"> <a href="#header.allow" id="rfc.xref.header.allow.3" title="Allow">Section&nbsp;8.1</a>
     2686                  <td class="left"> <a href="#header.allow" id="rfc.xref.header.allow.3" title="Allow">Section&nbsp;7.1</a>
    27402687                  </td>
    27412688               </tr>
    … …  
    27442691                  <td class="left">http</td>
    27452692                  <td class="left">standard</td>
    2746                   <td class="left"> <a href="#header.date" id="rfc.xref.header.date.2" title="Date">Section&nbsp;8.2</a>
     2693                  <td class="left"> <a href="#header.date" id="rfc.xref.header.date.2" title="Date">Section&nbsp;7.2</a>
    27472694                  </td>
    27482695               </tr>
    … …  
    27512698                  <td class="left">http</td>
    27522699                  <td class="left">standard</td>
    2753                   <td class="left"> <a href="#header.expect" id="rfc.xref.header.expect.3" title="Expect">Section&nbsp;8.3</a>
     2700                  <td class="left"> <a href="#header.expect" id="rfc.xref.header.expect.3" title="Expect">Section&nbsp;7.3</a>
    27542701                  </td>
    27552702               </tr>
    … …  
    27582705                  <td class="left">http</td>
    27592706                  <td class="left">standard</td>
    2760                   <td class="left"> <a href="#header.from" id="rfc.xref.header.from.2" title="From">Section&nbsp;8.4</a>
     2707                  <td class="left"> <a href="#header.from" id="rfc.xref.header.from.2" title="From">Section&nbsp;7.4</a>
    27612708                  </td>
    27622709               </tr>
    … …  
    27652712                  <td class="left">http</td>
    27662713                  <td class="left">standard</td>
    2767                   <td class="left"> <a href="#header.location" id="rfc.xref.header.location.4" title="Location">Section&nbsp;8.5</a>
     2714                  <td class="left"> <a href="#header.location" id="rfc.xref.header.location.4" title="Location">Section&nbsp;7.5</a>
    27682715                  </td>
    27692716               </tr>
    … …  
    27722719                  <td class="left">http</td>
    27732720                  <td class="left">standard</td>
    2774                   <td class="left"> <a href="#header.max-forwards" id="rfc.xref.header.max-forwards.4" title="Max-Forwards">Section&nbsp;8.6</a>
     2721                  <td class="left"> <a href="#header.max-forwards" id="rfc.xref.header.max-forwards.4" title="Max-Forwards">Section&nbsp;7.6</a>
    27752722                  </td>
    27762723               </tr>
    … …  
    27792726                  <td class="left">http</td>
    27802727                  <td class="left">standard</td>
    2781                   <td class="left"> <a href="#header.referer" id="rfc.xref.header.referer.2" title="Referer">Section&nbsp;8.7</a>
     2728                  <td class="left"> <a href="#header.referer" id="rfc.xref.header.referer.2" title="Referer">Section&nbsp;7.7</a>
    27822729                  </td>
    27832730               </tr>
    … …  
    27862733                  <td class="left">http</td>
    27872734                  <td class="left">standard</td>
    2788                   <td class="left"> <a href="#header.retry-after" id="rfc.xref.header.retry-after.3" title="Retry-After">Section&nbsp;8.8</a>
     2735                  <td class="left"> <a href="#header.retry-after" id="rfc.xref.header.retry-after.3" title="Retry-After">Section&nbsp;7.8</a>
    27892736                  </td>
    27902737               </tr>
    … …  
    27932740                  <td class="left">http</td>
    27942741                  <td class="left">standard</td>
    2795                   <td class="left"> <a href="#header.server" id="rfc.xref.header.server.2" title="Server">Section&nbsp;8.9</a>
     2742                  <td class="left"> <a href="#header.server" id="rfc.xref.header.server.2" title="Server">Section&nbsp;7.9</a>
    27962743                  </td>
    27972744               </tr>
    … …  
    28002747                  <td class="left">http</td>
    28012748                  <td class="left">standard</td>
    2802                   <td class="left"> <a href="#header.user-agent" id="rfc.xref.header.user-agent.2" title="User-Agent">Section&nbsp;8.10</a>
     2749                  <td class="left"> <a href="#header.user-agent" id="rfc.xref.header.user-agent.2" title="User-Agent">Section&nbsp;7.10</a>
    28032750                  </td>
    28042751               </tr>
    … …  
    28062753         </table>
    28072754      </div>
    2808       <p id="rfc.section.9.3.p.2">The change controller is: "IETF (iesg@ietf.org) - Internet Engineering Task Force".</p>
    2809       <h1 id="rfc.section.10"><a href="#rfc.section.10">10.</a>&nbsp;<a id="security.considerations" href="#security.considerations">Security Considerations</a></h1>
    2810       <p id="rfc.section.10.p.1">This section is meant to inform application developers, information providers, and users of the security limitations in HTTP/1.1
     2755      <p id="rfc.section.8.3.p.2">The change controller is: "IETF (iesg@ietf.org) - Internet Engineering Task Force".</p>
     2756      <h1 id="rfc.section.9"><a href="#rfc.section.9">9.</a>&nbsp;<a id="security.considerations" href="#security.considerations">Security Considerations</a></h1>
     2757      <p id="rfc.section.9.p.1">This section is meant to inform application developers, information providers, and users of the security limitations in HTTP/1.1
    28112758         as described by this document. The discussion does not include definitive solutions to the problems revealed, though it does
    28122759         make some suggestions for reducing security risks.
    28132760      </p>
    2814       <h2 id="rfc.section.10.1"><a href="#rfc.section.10.1">10.1</a>&nbsp;<a id="security.sensitive" href="#security.sensitive">Transfer of Sensitive Information</a></h2>
    2815       <p id="rfc.section.10.1.p.1">Like any generic data transfer protocol, HTTP cannot regulate the content of the data that is transferred, nor is there any
     2761      <h2 id="rfc.section.9.1"><a href="#rfc.section.9.1">9.1</a>&nbsp;<a id="security.sensitive" href="#security.sensitive">Transfer of Sensitive Information</a></h2>
     2762      <p id="rfc.section.9.1.p.1">Like any generic data transfer protocol, HTTP cannot regulate the content of the data that is transferred, nor is there any
    28162763         a priori method of determining the sensitivity of any particular piece of information within the context of any given request.
    28172764         Therefore, applications <em class="bcp14">SHOULD</em> supply as much control over this information as possible to the provider of that information. Four header fields are worth
    28182765         special mention in this context: Server, Via, Referer and From.
    28192766      </p>
    2820       <p id="rfc.section.10.1.p.2">Revealing the specific software version of the server might allow the server machine to become more vulnerable to attacks
     2767      <p id="rfc.section.9.1.p.2">Revealing the specific software version of the server might allow the server machine to become more vulnerable to attacks
    28212768         against software that is known to contain security holes. Implementors <em class="bcp14">SHOULD</em> make the Server header field a configurable option.
    28222769      </p>
    2823       <p id="rfc.section.10.1.p.3">Proxies which serve as a portal through a network firewall <em class="bcp14">SHOULD</em> take special precautions regarding the transfer of header information that identifies the hosts behind the firewall. In particular,
     2770      <p id="rfc.section.9.1.p.3">Proxies which serve as a portal through a network firewall <em class="bcp14">SHOULD</em> take special precautions regarding the transfer of header information that identifies the hosts behind the firewall. In particular,
    28242771         they <em class="bcp14">SHOULD</em> remove, or replace with sanitized versions, any Via fields generated behind the firewall.
    28252772      </p>
    2826       <p id="rfc.section.10.1.p.4">The Referer header field allows reading patterns to be studied and reverse links drawn. Although it can be very useful, its
     2773      <p id="rfc.section.9.1.p.4">The Referer header field allows reading patterns to be studied and reverse links drawn. Although it can be very useful, its
    28272774         power can be abused if user details are not separated from the information contained in the Referer. Even when the personal
    28282775         information has been removed, the Referer header field might indicate a private document's URI whose publication would be
    28292776         inappropriate.
    28302777      </p>
    2831       <p id="rfc.section.10.1.p.5">The information sent in the From field might conflict with the user's privacy interests or their site's security policy, and
     2778      <p id="rfc.section.9.1.p.5">The information sent in the From field might conflict with the user's privacy interests or their site's security policy, and
    28322779         hence it <em class="bcp14">SHOULD NOT</em> be transmitted without the user being able to disable, enable, and modify the contents of the field. The user <em class="bcp14">MUST</em> be able to set the contents of this field within a user preference or application defaults configuration.
    28332780      </p>
    2834       <p id="rfc.section.10.1.p.6">We suggest, though do not require, that a convenient toggle interface be provided for the user to enable or disable the sending
     2781      <p id="rfc.section.9.1.p.6">We suggest, though do not require, that a convenient toggle interface be provided for the user to enable or disable the sending
    28352782         of From and Referer information.
    28362783      </p>
    2837       <p id="rfc.section.10.1.p.7">The User-Agent (<a href="#header.user-agent" id="rfc.xref.header.user-agent.3" title="User-Agent">Section&nbsp;8.10</a>) or Server (<a href="#header.server" id="rfc.xref.header.server.3" title="Server">Section&nbsp;8.9</a>) header fields can sometimes be used to determine that a specific client or server has a particular security hole which might
     2784      <p id="rfc.section.9.1.p.7">The User-Agent (<a href="#header.user-agent" id="rfc.xref.header.user-agent.3" title="User-Agent">Section&nbsp;7.10</a>) or Server (<a href="#header.server" id="rfc.xref.header.server.3" title="Server">Section&nbsp;7.9</a>) header fields can sometimes be used to determine that a specific client or server has a particular security hole which might
    28382785         be exploited. Unfortunately, this same information is often used for other valuable purposes for which HTTP currently has
    28392786         no better mechanism.
    28402787      </p>
    2841       <p id="rfc.section.10.1.p.8">Furthermore, the User-Agent header field may contain enough entropy to be used, possibly in conjunction with other material,
     2788      <p id="rfc.section.9.1.p.8">Furthermore, the User-Agent header field may contain enough entropy to be used, possibly in conjunction with other material,
    28422789         to uniquely identify the user.
    28432790      </p>
    2844       <p id="rfc.section.10.1.p.9">Some request methods, like TRACE (<a href="#TRACE" id="rfc.xref.TRACE.4" title="TRACE">Section&nbsp;6.8</a>), expose information that was sent in request header fields within the body of their response. Clients <em class="bcp14">SHOULD</em> be careful with sensitive information, like Cookies, Authorization credentials, and other header fields that might be used
     2791      <p id="rfc.section.9.1.p.9">Some request methods, like TRACE (<a href="#TRACE" id="rfc.xref.TRACE.3" title="TRACE">Section&nbsp;2.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
    28452792         to collect data from the client.
    28462793      </p>
    2847       <h2 id="rfc.section.10.2"><a href="#rfc.section.10.2">10.2</a>&nbsp;<a id="encoding.sensitive.information.in.uris" href="#encoding.sensitive.information.in.uris">Encoding Sensitive Information in URIs</a></h2>
    2848       <p id="rfc.section.10.2.p.1">Because the source of a link might be private information or might reveal an otherwise private information source, it is strongly
     2794      <h2 id="rfc.section.9.2"><a href="#rfc.section.9.2">9.2</a>&nbsp;<a id="encoding.sensitive.information.in.uris" href="#encoding.sensitive.information.in.uris">Encoding Sensitive Information in URIs</a></h2>
     2795      <p id="rfc.section.9.2.p.1">Because the source of a link might be private information or might reveal an otherwise private information source, it is strongly
    28492796         recommended that the user be able to select whether or not the Referer field is sent. For example, a browser client could
    28502797         have a toggle switch for browsing openly/anonymously, which would respectively enable/disable the sending of Referer and From
    28512798         information.
    28522799      </p>
    2853       <p id="rfc.section.10.2.p.2">Clients <em class="bcp14">SHOULD NOT</em> include a Referer header field in a (non-secure) HTTP request if the referring page was transferred with a secure protocol.
    2854       </p>
    2855       <p id="rfc.section.10.2.p.3">Authors of services <em class="bcp14">SHOULD NOT</em> use GET-based forms for the submission of sensitive data because that data will be placed in the request-target. Many existing
     2800      <p id="rfc.section.9.2.p.2">Clients <em class="bcp14">SHOULD NOT</em> include a Referer header field in a (non-secure) HTTP request if the referring page was transferred with a secure protocol.
     2801      </p>
     2802      <p id="rfc.section.9.2.p.3">Authors of services <em class="bcp14">SHOULD NOT</em> use GET-based forms for the submission of sensitive data because that data will be placed in the request-target. Many existing
    28562803         servers, proxies, and user agents log or display the request-target in places where it might be visible to third parties.
    28572804         Such services can use POST-based form submission instead.
    28582805      </p>
    2859       <h2 id="rfc.section.10.3"><a href="#rfc.section.10.3">10.3</a>&nbsp;<a id="location.spoofing-leakage" href="#location.spoofing-leakage">Location Header Fields: Spoofing and Information Leakage</a></h2>
    2860       <p id="rfc.section.10.3.p.1">If a single server supports multiple organizations that do not trust one another, then it <em class="bcp14">MUST</em> check the values of Location and Content-Location header fields in responses that are generated under control of said organizations
     2806      <h2 id="rfc.section.9.3"><a href="#rfc.section.9.3">9.3</a>&nbsp;<a id="location.spoofing-leakage" href="#location.spoofing-leakage">Location Header Fields: Spoofing and Information Leakage</a></h2>
     2807      <p id="rfc.section.9.3.p.1">If a single server supports multiple organizations that do not trust one another, then it <em class="bcp14">MUST</em> check the values of Location and Content-Location header fields in responses that are generated under control of said organizations
    28612808         to make sure that they do not attempt to invalidate resources over which they have no authority.
    28622809      </p>
    2863       <p id="rfc.section.10.3.p.2">Furthermore, appending the fragment identifier from one URI to another one obtained from a Location header field might leak
     2810      <p id="rfc.section.9.3.p.2">Furthermore, appending the fragment identifier from one URI to another one obtained from a Location header field might leak
    28642811         confidential information to the target server — although the fragment identifier is not transmitted in the final request,
    28652812         it might be visible to the user agent through other means, such as scripting.
    28662813      </p>
    2867       <h2 id="rfc.section.10.4"><a href="#rfc.section.10.4">10.4</a>&nbsp;Security Considerations for CONNECT
     2814      <h2 id="rfc.section.9.4"><a href="#rfc.section.9.4">9.4</a>&nbsp;Security Considerations for CONNECT
    28682815      </h2>
    2869       <p id="rfc.section.10.4.p.1">Since tunneled data is opaque to the proxy, there are additional risks to tunneling to other well-known or reserved ports.
     2816      <p id="rfc.section.9.4.p.1">Since tunneled data is opaque to the proxy, there are additional risks to tunneling to other well-known or reserved ports.
    28702817         A HTTP client CONNECTing to port 25 could relay spam via SMTP, for example. As such, proxies <em class="bcp14">SHOULD</em> restrict CONNECT access to a small number of known ports.
    28712818      </p>
    2872       <h1 id="rfc.section.11"><a href="#rfc.section.11">11.</a>&nbsp;<a id="acks" href="#acks">Acknowledgments</a></h1>
    2873       <p id="rfc.section.11.p.1">See <a href="p1-messaging.html#acks" title="Acknowledgments">Section 9</a> of <a href="#Part1" id="rfc.xref.Part1.42"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>.
    2874       </p>
    2875       <h1 id="rfc.references"><a id="rfc.section.12" href="#rfc.section.12">12.</a> References
     2819      <h1 id="rfc.section.10"><a href="#rfc.section.10">10.</a>&nbsp;<a id="acks" href="#acks">Acknowledgments</a></h1>
     2820      <p id="rfc.section.10.p.1">See <a href="p1-messaging.html#acks" title="Acknowledgments">Section 9</a> of <a href="#Part1" id="rfc.xref.Part1.42"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>.
     2821      </p>
     2822      <h1 id="rfc.references"><a id="rfc.section.11" href="#rfc.section.11">11.</a> References
    28762823      </h1>
    2877       <h2 id="rfc.references.1"><a href="#rfc.section.12.1" id="rfc.section.12.1">12.1</a> Normative References
     2824      <h2 id="rfc.references.1"><a href="#rfc.section.11.1" id="rfc.section.11.1">11.1</a> Normative References
    28782825      </h2>
    28792826      <table>                 
    … …  
    29242871         </tr>
    29252872      </table>
    2926       <h2 id="rfc.references.2"><a href="#rfc.section.12.2" id="rfc.section.12.2">12.2</a> Informative References
     2873      <h2 id="rfc.references.2"><a href="#rfc.section.11.2" id="rfc.section.11.2">11.2</a> Informative References
    29272874      </h2>
    29282875      <table>                     
    … …  
    29962943      </div>
    29972944      <h1 id="rfc.section.A" class="np"><a href="#rfc.section.A">A.</a>&nbsp;<a id="changes.from.rfc.2616" href="#changes.from.rfc.2616">Changes from RFC 2616</a></h1>
    2998       <p id="rfc.section.A.p.1">This document takes 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.2"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a>. (<a href="#status.code.registry" title="Status Code Registry">Section&nbsp;4.2</a>)
    2999       </p>
    3000       <p id="rfc.section.A.p.2">Broadened the definition of 203 (Non-Authoritative Information) to include cases of payload transformations as well. (<a href="#status.203" id="rfc.xref.status.203.3" title="203 Non-Authoritative Information">Section&nbsp;4.3.2.4</a>)
    3001       </p>
    3002       <p id="rfc.section.A.p.3">Status codes 301, 302, and 307: removed the normative requirements on both response payloads and user interaction. (<a href="#status.3xx" title="Redirection 3xx">Section&nbsp;4.3.3</a>)
    3003       </p>
    3004       <p id="rfc.section.A.p.4">Failed to consider that there are many other request methods that are safe to automatically redirect, and further that the
     2945      <p id="rfc.section.A.p.1">Clarify definition of POST. (<a href="#POST" id="rfc.xref.POST.2" title="POST">Section&nbsp;2.3.4</a>)
     2946      </p>
     2947      <p id="rfc.section.A.p.2">Remove requirement to handle all Content-* header fields; ban use of Content-Range with PUT. (<a href="#PUT" id="rfc.xref.PUT.2" title="PUT">Section&nbsp;2.3.5</a>)
     2948      </p>
     2949      <p id="rfc.section.A.p.3">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.2" title="CONNECT">Section&nbsp;2.3.8</a>)
     2950      </p>
     2951      <p id="rfc.section.A.p.4">This document takes 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;4.2</a>)
     2952      </p>
     2953      <p id="rfc.section.A.p.5">Broadened the definition of 203 (Non-Authoritative Information) to include cases of payload transformations as well. (<a href="#status.203" id="rfc.xref.status.203.3" title="203 Non-Authoritative Information">Section&nbsp;4.3.2.4</a>)
     2954      </p>
     2955      <p id="rfc.section.A.p.6">Status codes 301, 302, and 307: removed the normative requirements on both response payloads and user interaction. (<a href="#status.3xx" title="Redirection 3xx">Section&nbsp;4.3.3</a>)
     2956      </p>
     2957      <p id="rfc.section.A.p.7">Failed to consider that there are many other request methods that are safe to automatically redirect, and further that the
    30052958         user agent is able to make that determination based on the request method semantics. Furthermore, allow user agents to rewrite
    30062959         the method from POST to GET for status codes 301 and 302. (Sections <a href="#status.301" id="rfc.xref.status.301.3" title="301 Moved Permanently">4.3.3.2</a>, <a href="#status.302" id="rfc.xref.status.302.3" title="302 Found">4.3.3.3</a> and <a href="#status.307" id="rfc.xref.status.307.3" title="307 Temporary Redirect">4.3.3.7</a>)
    30072960      </p>
    3008       <p id="rfc.section.A.p.5">Deprecate 305 Use Proxy status code, because user agents did not implement it. It used to indicate that the target resource
     2961      <p id="rfc.section.A.p.8">Deprecate 305 Use Proxy status code, because user agents did not implement it. It used to indicate that the target resource
    30092962         needs to be accessed through the proxy given by the Location field. The Location field gave the URI of the proxy. The recipient
    30102963         was expected to repeat this single request via the proxy. (<a href="#status.305" id="rfc.xref.status.305.3" title="305 Use Proxy">Section&nbsp;4.3.3.5</a>)
    30112964      </p>
    3012       <p id="rfc.section.A.p.6">Define status 426 (Upgrade Required) (this was incorporated from <a href="#RFC2817" id="rfc.xref.RFC2817.3"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a>). (<a href="#status.426" id="rfc.xref.status.426.3" title="426 Upgrade Required">Section&nbsp;4.3.4.15</a>)
    3013       </p>
    3014       <p id="rfc.section.A.p.7">Clarify definition of POST. (<a href="#POST" id="rfc.xref.POST.3" title="POST">Section&nbsp;6.5</a>)
    3015       </p>
    3016       <p id="rfc.section.A.p.8">Remove requirement to handle all Content-* header fields; ban use of Content-Range with PUT. (<a href="#PUT" id="rfc.xref.PUT.3" title="PUT">Section&nbsp;6.6</a>)
    3017       </p>
    3018       <p id="rfc.section.A.p.9">Take over definition of CONNECT method from <a href="#RFC2817" id="rfc.xref.RFC2817.4"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a>. (<a href="#CONNECT" id="rfc.xref.CONNECT.3" title="CONNECT">Section&nbsp;6.9</a>)
    3019       </p>
    3020       <p id="rfc.section.A.p.10">Change ABNF productions for header fields to only define the field value. (<a href="#header.field.definitions" title="Header Field Definitions">Section&nbsp;8</a>)
     2965      <p id="rfc.section.A.p.9">Define status 426 (Upgrade Required) (this was incorporated from <a href="#RFC2817" id="rfc.xref.RFC2817.4"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a>). (<a href="#status.426" id="rfc.xref.status.426.3" title="426 Upgrade Required">Section&nbsp;4.3.4.15</a>)
     2966      </p>
     2967      <p id="rfc.section.A.p.10">Change ABNF productions for header fields to only define the field value. (<a href="#header.field.definitions" title="Header Field Definitions">Section&nbsp;7</a>)
    30212968      </p>
    30222969      <p id="rfc.section.A.p.11">Reclassify "Allow" as response header field, removing the option to specify it in a PUT request. Relax the server requirement
    3023          on the contents of the Allow header field and remove requirement on clients to always trust the header field value. (<a href="#header.allow" id="rfc.xref.header.allow.4" title="Allow">Section&nbsp;8.1</a>)
     2970         on the contents of the Allow header field and remove requirement on clients to always trust the header field value. (<a href="#header.allow" id="rfc.xref.header.allow.4" title="Allow">Section&nbsp;7.1</a>)
    30242971      </p>
    30252972      <p id="rfc.section.A.p.12">The ABNF for the Expect header field has been both fixed (allowing parameters for value-less expectations as well) and simplified
    3026          (allowing trailing semicolons after "100-continue" when they were invalid before). (<a href="#header.expect" id="rfc.xref.header.expect.4" title="Expect">Section&nbsp;8.3</a>)
     2973         (allowing trailing semicolons after "100-continue" when they were invalid before). (<a href="#header.expect" id="rfc.xref.header.expect.4" title="Expect">Section&nbsp;7.3</a>)
    30272974      </p>
    30282975      <p id="rfc.section.A.p.13">Correct syntax of Location header field to allow URI references (including relative references and fragments), as referred
    30292976         symbol "absoluteURI" wasn't what was expected, and add some clarifications as to when use of fragments would not be appropriate.
    3030          (<a href="#header.location" id="rfc.xref.header.location.5" title="Location">Section&nbsp;8.5</a>)
    3031       </p>
    3032       <p id="rfc.section.A.p.14">Restrict Max-Forwards header field to OPTIONS and TRACE (previously, extension methods could have used it as well). (<a href="#header.max-forwards" id="rfc.xref.header.max-forwards.5" title="Max-Forwards">Section&nbsp;8.6</a>)
    3033       </p>
    3034       <p id="rfc.section.A.p.15">Allow Referer field value of "about:blank" as alternative to not specifying it. (<a href="#header.referer" id="rfc.xref.header.referer.3" title="Referer">Section&nbsp;8.7</a>)
     2977         (<a href="#header.location" id="rfc.xref.header.location.5" title="Location">Section&nbsp;7.5</a>)
     2978      </p>
     2979      <p id="rfc.section.A.p.14">Restrict Max-Forwards header field to OPTIONS and TRACE (previously, extension methods could have used it as well). (<a href="#header.max-forwards" id="rfc.xref.header.max-forwards.5" title="Max-Forwards">Section&nbsp;7.6</a>)
     2980      </p>
     2981      <p id="rfc.section.A.p.15">Allow Referer field value of "about:blank" as alternative to not specifying it. (<a href="#header.referer" id="rfc.xref.header.referer.3" title="Referer">Section&nbsp;7.7</a>)
    30352982      </p>
    30362983      <p id="rfc.section.A.p.16">In the description of the Server header field, the Via field was described as a SHOULD. The requirement was and is stated
    3037          correctly in the description of the Via header field in <a href="p1-messaging.html#header.via" title="Via">Section 6.2</a> of <a href="#Part1" id="rfc.xref.Part1.43"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. (<a href="#header.server" id="rfc.xref.header.server.4" title="Server">Section&nbsp;8.9</a>)
     2984         correctly in the description of the Via header field in <a href="p1-messaging.html#header.via" title="Via">Section 6.2</a> of <a href="#Part1" id="rfc.xref.Part1.43"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. (<a href="#header.server" id="rfc.xref.header.server.4" title="Server">Section&nbsp;7.9</a>)
    30382985      </p>
    30392986      <h1 id="rfc.section.B"><a href="#rfc.section.B">B.</a>&nbsp;<a id="collected.abnf" href="#collected.abnf">Collected ABNF</a></h1>
    … …  
    31013048
    31023049<a href="#header.from" class="smpl">mailbox</a> = &lt;mailbox, defined in [RFC5322], Section 3.4&gt;
    3103 <a href="#method" class="smpl">method</a> = token
     3050<a href="#methods" class="smpl">method</a> = token
    31043051<a href="#preferred.date.format" class="smpl">minute</a> = 2DIGIT
    31053052<a href="#preferred.date.format" class="smpl">month</a> = %x4A.61.6E ; Jan
    … …  
    34783425         <ul class="ind">
    34793426            <li><a id="rfc.index.1" href="#rfc.index.1"><b>1</b></a><ul>
    3480                   <li>100 Continue (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.100.1">4.1</a>, <a href="#rfc.iref.4"><b>4.3.1.1</b></a>, <a href="#rfc.xref.status.100.2">9.2</a></li>
    3481                   <li>100-continue (expect value)&nbsp;&nbsp;<a href="#rfc.iref.89"><b>8.3</b></a></li>
    3482                   <li>101 Switching Protocols (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.101.1">4.1</a>, <a href="#rfc.iref.5"><b>4.3.1.2</b></a>, <a href="#rfc.xref.status.101.2">9.2</a></li>
     3427                  <li>100 Continue (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.100.1">4.1</a>, <a href="#rfc.iref.22"><b>4.3.1.1</b></a>, <a href="#rfc.xref.status.100.2">8.2</a></li>
     3428                  <li>100-continue (expect value)&nbsp;&nbsp;<a href="#rfc.iref.89"><b>7.3</b></a></li>
     3429                  <li>101 Switching Protocols (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.101.1">4.1</a>, <a href="#rfc.iref.23"><b>4.3.1.2</b></a>, <a href="#rfc.xref.status.101.2">8.2</a></li>
    34833430               </ul>
    34843431            </li>
    34853432            <li><a id="rfc.index.2" href="#rfc.index.2"><b>2</b></a><ul>
    3486                   <li>200 OK (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.200.1">4.1</a>, <a href="#rfc.iref.6"><b>4.3.2.1</b></a>, <a href="#rfc.xref.status.200.2">9.2</a></li>
    3487                   <li>201 Created (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.201.1">4.1</a>, <a href="#rfc.iref.7"><b>4.3.2.2</b></a>, <a href="#rfc.xref.status.201.2">9.2</a></li>
    3488                   <li>202 Accepted (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.202.1">4.1</a>, <a href="#rfc.iref.8"><b>4.3.2.3</b></a>, <a href="#rfc.xref.status.202.2">9.2</a></li>
    3489                   <li>203 Non-Authoritative Information (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.203.1">4.1</a>, <a href="#rfc.iref.9"><b>4.3.2.4</b></a>, <a href="#rfc.xref.status.203.2">9.2</a>, <a href="#rfc.xref.status.203.3">A</a></li>
    3490                   <li>204 No Content (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.204.1">4.1</a>, <a href="#rfc.iref.10"><b>4.3.2.5</b></a>, <a href="#rfc.xref.status.204.2">9.2</a></li>
    3491                   <li>205 Reset Content (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.205.1">4.1</a>, <a href="#rfc.iref.11"><b>4.3.2.6</b></a>, <a href="#rfc.xref.status.205.2">9.2</a></li>
     3433                  <li>200 OK (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.200.1">4.1</a>, <a href="#rfc.iref.24"><b>4.3.2.1</b></a>, <a href="#rfc.xref.status.200.2">8.2</a></li>
     3434                  <li>201 Created (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.201.1">4.1</a>, <a href="#rfc.iref.25"><b>4.3.2.2</b></a>, <a href="#rfc.xref.status.201.2">8.2</a></li>
     3435                  <li>202 Accepted (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.202.1">4.1</a>, <a href="#rfc.iref.26"><b>4.3.2.3</b></a>, <a href="#rfc.xref.status.202.2">8.2</a></li>
     3436                  <li>203 Non-Authoritative Information (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.203.1">4.1</a>, <a href="#rfc.iref.27"><b>4.3.2.4</b></a>, <a href="#rfc.xref.status.203.2">8.2</a>, <a href="#rfc.xref.status.203.3">A</a></li>
     3437                  <li>204 No Content (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.204.1">4.1</a>, <a href="#rfc.iref.28"><b>4.3.2.5</b></a>, <a href="#rfc.xref.status.204.2">8.2</a></li>
     3438                  <li>205 Reset Content (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.205.1">4.1</a>, <a href="#rfc.iref.29"><b>4.3.2.6</b></a>, <a href="#rfc.xref.status.205.2">8.2</a></li>
    34923439               </ul>
    34933440            </li>
    34943441            <li><a id="rfc.index.3" href="#rfc.index.3"><b>3</b></a><ul>
    3495                   <li>300 Multiple Choices (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.300.1">4.1</a>, <a href="#rfc.iref.12"><b>4.3.3.1</b></a>, <a href="#rfc.xref.status.300.2">9.2</a></li>
    3496                   <li>301 Moved Permanently (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.301.1">4.1</a>, <a href="#rfc.iref.13"><b>4.3.3.2</b></a>, <a href="#rfc.xref.status.301.2">9.2</a>, <a href="#rfc.xref.status.301.3">A</a></li>
    3497                   <li>302 Found (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.302.1">4.1</a>, <a href="#rfc.iref.14"><b>4.3.3.3</b></a>, <a href="#rfc.xref.status.302.2">9.2</a>, <a href="#rfc.xref.status.302.3">A</a></li>
    3498                   <li>303 See Other (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.303.1">4.1</a>, <a href="#rfc.iref.15"><b>4.3.3.4</b></a>, <a href="#rfc.xref.status.303.2">9.2</a></li>
    3499                   <li>305 Use Proxy (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.305.1">4.1</a>, <a href="#rfc.iref.16"><b>4.3.3.5</b></a>, <a href="#rfc.xref.status.305.2">9.2</a>, <a href="#rfc.xref.status.305.3">A</a></li>
    3500                   <li>306 (Unused) (status code)&nbsp;&nbsp;<a href="#rfc.iref.17"><b>4.3.3.6</b></a>, <a href="#rfc.xref.status.306.1">9.2</a></li>
    3501                   <li>307 Temporary Redirect (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.307.1">4.1</a>, <a href="#rfc.iref.18"><b>4.3.3.7</b></a>, <a href="#rfc.xref.status.307.2">9.2</a>, <a href="#rfc.xref.status.307.3">A</a></li>
     3442                  <li>300 Multiple Choices (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.300.1">4.1</a>, <a href="#rfc.iref.30"><b>4.3.3.1</b></a>, <a href="#rfc.xref.status.300.2">8.2</a></li>
     3443                  <li>301 Moved Permanently (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.301.1">4.1</a>, <a href="#rfc.iref.31"><b>4.3.3.2</b></a>, <a href="#rfc.xref.status.301.2">8.2</a>, <a href="#rfc.xref.status.301.3">A</a></li>
     3444                  <li>302 Found (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.302.1">4.1</a>, <a href="#rfc.iref.32"><b>4.3.3.3</b></a>, <a href="#rfc.xref.status.302.2">8.2</a>, <a href="#rfc.xref.status.302.3">A</a></li>
     3445                  <li>303 See Other (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.303.1">4.1</a>, <a href="#rfc.iref.33"><b>4.3.3.4</b></a>, <a href="#rfc.xref.status.303.2">8.2</a></li>
     3446                  <li>305 Use Proxy (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.305.1">4.1</a>, <a href="#rfc.iref.34"><b>4.3.3.5</b></a>, <a href="#rfc.xref.status.305.2">8.2</a>, <a href="#rfc.xref.status.305.3">A</a></li>
     3447                  <li>306 (Unused) (status code)&nbsp;&nbsp;<a href="#rfc.iref.35"><b>4.3.3.6</b></a>, <a href="#rfc.xref.status.306.1">8.2</a></li>
     3448                  <li>307 Temporary Redirect (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.307.1">4.1</a>, <a href="#rfc.iref.36"><b>4.3.3.7</b></a>, <a href="#rfc.xref.status.307.2">8.2</a>, <a href="#rfc.xref.status.307.3">A</a></li>
    35023449               </ul>
    35033450            </li>
    35043451            <li><a id="rfc.index.4" href="#rfc.index.4"><b>4</b></a><ul>
    3505                   <li>400 Bad Request (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.400.1">4.1</a>, <a href="#rfc.iref.19"><b>4.3.4.1</b></a>, <a href="#rfc.xref.status.400.2">9.2</a></li>
    3506                   <li>402 Payment Required (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.402.1">4.1</a>, <a href="#rfc.iref.20"><b>4.3.4.2</b></a>, <a href="#rfc.xref.status.402.2">9.2</a></li>
    3507                   <li>403 Forbidden (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.403.1">4.1</a>, <a href="#rfc.iref.21"><b>4.3.4.3</b></a>, <a href="#rfc.xref.status.403.2">9.2</a></li>
    3508                   <li>404 Not Found (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.404.1">4.1</a>, <a href="#rfc.iref.22"><b>4.3.4.4</b></a>, <a href="#rfc.xref.status.404.2">9.2</a></li>
    3509                   <li>405 Method Not Allowed (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.405.1">4.1</a>, <a href="#rfc.iref.23"><b>4.3.4.5</b></a>, <a href="#rfc.xref.status.405.2">9.2</a></li>
    3510                   <li>406 Not Acceptable (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.406.1">4.1</a>, <a href="#rfc.iref.24"><b>4.3.4.6</b></a>, <a href="#rfc.xref.status.406.2">9.2</a></li>
    3511                   <li>408 Request Timeout (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.408.1">4.1</a>, <a href="#rfc.iref.25"><b>4.3.4.7</b></a>, <a href="#rfc.xref.status.408.2">9.2</a></li>
    3512                   <li>409 Conflict (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.409.1">4.1</a>, <a href="#rfc.iref.26"><b>4.3.4.8</b></a>, <a href="#rfc.xref.status.409.2">9.2</a></li>
    3513                   <li>410 Gone (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.410.1">4.1</a>, <a href="#rfc.iref.27"><b>4.3.4.9</b></a>, <a href="#rfc.xref.status.410.2">9.2</a></li>
    3514                   <li>411 Length Required (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.411.1">4.1</a>, <a href="#rfc.iref.28"><b>4.3.4.10</b></a>, <a href="#rfc.xref.status.411.2">9.2</a></li>
    3515                   <li>413 Request Representation Too Large (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.413.1">4.1</a>, <a href="#rfc.iref.29"><b>4.3.4.11</b></a>, <a href="#rfc.xref.status.413.2">9.2</a></li>
    3516                   <li>414 URI Too Long (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.414.1">4.1</a>, <a href="#rfc.iref.30"><b>4.3.4.12</b></a>, <a href="#rfc.xref.status.414.2">9.2</a></li>
    3517                   <li>415 Unsupported Media Type (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.415.1">4.1</a>, <a href="#rfc.iref.31"><b>4.3.4.13</b></a>, <a href="#rfc.xref.status.415.2">9.2</a></li>
    3518                   <li>417 Expectation Failed (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.417.1">4.1</a>, <a href="#rfc.iref.32"><b>4.3.4.14</b></a>, <a href="#rfc.xref.status.417.2">9.2</a></li>
    3519                   <li>426 Upgrade Required (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.426.1">4.1</a>, <a href="#rfc.iref.33"><b>4.3.4.15</b></a>, <a href="#rfc.xref.status.426.2">9.2</a>, <a href="#rfc.xref.status.426.3">A</a></li>
     3452                  <li>400 Bad Request (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.400.1">4.1</a>, <a href="#rfc.iref.37"><b>4.3.4.1</b></a>, <a href="#rfc.xref.status.400.2">8.2</a></li>
     3453                  <li>402 Payment Required (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.402.1">4.1</a>, <a href="#rfc.iref.38"><b>4.3.4.2</b></a>, <a href="#rfc.xref.status.402.2">8.2</a></li>
     3454                  <li>403 Forbidden (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.403.1">4.1</a>, <a href="#rfc.iref.39"><b>4.3.4.3</b></a>, <a href="#rfc.xref.status.403.2">8.2</a></li>
     3455                  <li>404 Not Found (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.404.1">4.1</a>, <a href="#rfc.iref.40"><b>4.3.4.4</b></a>, <a href="#rfc.xref.status.404.2">8.2</a></li>
     3456                  <li>405 Method Not Allowed (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.405.1">4.1</a>, <a href="#rfc.iref.41"><b>4.3.4.5</b></a>, <a href="#rfc.xref.status.405.2">8.2</a></li>
     3457                  <li>406 Not Acceptable (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.406.1">4.1</a>, <a href="#rfc.iref.42"><b>4.3.4.6</b></a>, <a href="#rfc.xref.status.406.2">8.2</a></li>
     3458                  <li>408 Request Timeout (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.408.1">4.1</a>, <a href="#rfc.iref.43"><b>4.3.4.7</b></a>, <a href="#rfc.xref.status.408.2">8.2</a></li>
     3459                  <li>409 Conflict (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.409.1">4.1</a>, <a href="#rfc.iref.44"><b>4.3.4.8</b></a>, <a href="#rfc.xref.status.409.2">8.2</a></li>
     3460                  <li>410 Gone (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.410.1">4.1</a>, <a href="#rfc.iref.45"><b>4.3.4.9</b></a>, <a href="#rfc.xref.status.410.2">8.2</a></li>
     3461                  <li>411 Length Required (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.411.1">4.1</a>, <a href="#rfc.iref.46"><b>4.3.4.10</b></a>, <a href="#rfc.xref.status.411.2">8.2</a></li>
     3462                  <li>413 Request Representation Too Large (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.413.1">4.1</a>, <a href="#rfc.iref.47"><b>4.3.4.11</b></a>, <a href="#rfc.xref.status.413.2">8.2</a></li>
     3463                  <li>414 URI Too Long (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.414.1">4.1</a>, <a href="#rfc.iref.48"><b>4.3.4.12</b></a>, <a href="#rfc.xref.status.414.2">8.2</a></li>
     3464                  <li>415 Unsupported Media Type (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.415.1">4.1</a>, <a href="#rfc.iref.49"><b>4.3.4.13</b></a>, <a href="#rfc.xref.status.415.2">8.2</a></li>
     3465                  <li>417 Expectation Failed (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.417.1">4.1</a>, <a href="#rfc.iref.50"><b>4.3.4.14</b></a>, <a href="#rfc.xref.status.417.2">8.2</a></li>
     3466                  <li>426 Upgrade Required (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.426.1">4.1</a>, <a href="#rfc.iref.51"><b>4.3.4.15</b></a>, <a href="#rfc.xref.status.426.2">8.2</a>, <a href="#rfc.xref.status.426.3">A</a></li>
    35203467               </ul>
    35213468            </li>
    35223469            <li><a id="rfc.index.5" href="#rfc.index.5"><b>5</b></a><ul>
    3523                   <li>500 Internal Server Error (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.500.1">4.1</a>, <a href="#rfc.iref.34"><b>4.3.5.1</b></a>, <a href="#rfc.xref.status.500.2">9.2</a></li>
    3524                   <li>501 Not Implemented (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.501.1">4.1</a>, <a href="#rfc.iref.35"><b>4.3.5.2</b></a>, <a href="#rfc.xref.status.501.2">9.2</a></li>
    3525                   <li>502 Bad Gateway (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.502.1">4.1</a>, <a href="#rfc.iref.36"><b>4.3.5.3</b></a>, <a href="#rfc.xref.status.502.2">9.2</a></li>
    3526                   <li>503 Service Unavailable (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.503.1">4.1</a>, <a href="#rfc.iref.37"><b>4.3.5.4</b></a>, <a href="#rfc.xref.status.503.2">9.2</a></li>
    3527                   <li>504 Gateway Timeout (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.504.1">4.1</a>, <a href="#rfc.iref.38"><b>4.3.5.5</b></a>, <a href="#rfc.xref.status.504.2">9.2</a></li>
    3528                   <li>505 HTTP Version Not Supported (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.505.1">4.1</a>, <a href="#rfc.iref.39"><b>4.3.5.6</b></a>, <a href="#rfc.xref.status.505.2">9.2</a></li>
     3470                  <li>500 Internal Server Error (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.500.1">4.1</a>, <a href="#rfc.iref.52"><b>4.3.5.1</b></a>, <a href="#rfc.xref.status.500.2">8.2</a></li>
     3471                  <li>501 Not Implemented (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.501.1">4.1</a>, <a href="#rfc.iref.53"><b>4.3.5.2</b></a>, <a href="#rfc.xref.status.501.2">8.2</a></li>
     3472                  <li>502 Bad Gateway (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.502.1">4.1</a>, <a href="#rfc.iref.54"><b>4.3.5.3</b></a>, <a href="#rfc.xref.status.502.2">8.2</a></li>
     3473                  <li>503 Service Unavailable (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.503.1">4.1</a>, <a href="#rfc.iref.55"><b>4.3.5.4</b></a>, <a href="#rfc.xref.status.503.2">8.2</a></li>
     3474                  <li>504 Gateway Timeout (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.504.1">4.1</a>, <a href="#rfc.iref.56"><b>4.3.5.5</b></a>, <a href="#rfc.xref.status.504.2">8.2</a></li>
     3475                  <li>505 HTTP Version Not Supported (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.505.1">4.1</a>, <a href="#rfc.iref.57"><b>4.3.5.6</b></a>, <a href="#rfc.xref.status.505.2">8.2</a></li>
    35293476               </ul>
    35303477            </li>
    35313478            <li><a id="rfc.index.A" href="#rfc.index.A"><b>A</b></a><ul>
    3532                   <li>Allow header field&nbsp;&nbsp;<a href="#rfc.xref.header.allow.1">2</a>, <a href="#rfc.xref.header.allow.2">3.3</a>, <a href="#rfc.iref.a.1"><b>8.1</b></a>, <a href="#rfc.xref.header.allow.3">9.3</a>, <a href="#rfc.xref.header.allow.4">A</a></li>
     3479                  <li>Allow header field&nbsp;&nbsp;<a href="#rfc.xref.header.allow.1">2</a>, <a href="#rfc.xref.header.allow.2">3.3</a>, <a href="#rfc.iref.a.1"><b>7.1</b></a>, <a href="#rfc.xref.header.allow.3">8.3</a>, <a href="#rfc.xref.header.allow.4">A</a></li>
    35333480               </ul>
    35343481            </li>
    35353482            <li><a id="rfc.index.C" href="#rfc.index.C"><b>C</b></a><ul>
    3536                   <li>CONNECT method&nbsp;&nbsp;<a href="#rfc.xref.CONNECT.1">2.1</a>, <a href="#rfc.iref.c.1"><b>6.9</b></a>, <a href="#rfc.xref.CONNECT.2">9.1</a>, <a href="#rfc.xref.CONNECT.3">A</a></li>
     3483                  <li>CONNECT method&nbsp;&nbsp;<a href="#rfc.iref.c.1"><b>2.3.8</b></a>, <a href="#rfc.xref.CONNECT.1">8.1</a>, <a href="#rfc.xref.CONNECT.2">A</a></li>
    35373484               </ul>
    35383485            </li>
    35393486            <li><a id="rfc.index.D" href="#rfc.index.D"><b>D</b></a><ul>
    3540                   <li>Date header field&nbsp;&nbsp;<a href="#rfc.xref.header.date.1">3.3</a>, <a href="#rfc.iref.d.2"><b>8.2</b></a>, <a href="#rfc.xref.header.date.2">9.3</a></li>
    3541                   <li>DELETE method&nbsp;&nbsp;<a href="#rfc.xref.DELETE.1">2.1</a>, <a href="#rfc.iref.d.1"><b>6.7</b></a>, <a href="#rfc.xref.DELETE.2">9.1</a></li>
    3542                   <li><em>draft-reschke-http-status-308</em>&nbsp;&nbsp;<a href="#rfc.xref.draft-reschke-http-status-308.1">4.3.3.7</a>, <a href="#draft-reschke-http-status-308"><b>12.2</b></a></li>
     3487                  <li>Date header field&nbsp;&nbsp;<a href="#rfc.xref.header.date.1">3.3</a>, <a href="#rfc.iref.d.2"><b>7.2</b></a>, <a href="#rfc.xref.header.date.2">8.3</a></li>
     3488                  <li>DELETE method&nbsp;&nbsp;<a href="#rfc.iref.d.1"><b>2.3.6</b></a>, <a href="#rfc.xref.DELETE.1">8.1</a></li>
     3489                  <li><em>draft-reschke-http-status-308</em>&nbsp;&nbsp;<a href="#rfc.xref.draft-reschke-http-status-308.1">4.3.3.7</a>, <a href="#draft-reschke-http-status-308"><b>11.2</b></a></li>
    35433490               </ul>
    35443491            </li>
    35453492            <li><a id="rfc.index.E" href="#rfc.index.E"><b>E</b></a><ul>
    3546                   <li>Expect header field&nbsp;&nbsp;<a href="#rfc.xref.header.expect.1">3.2</a>, <a href="#rfc.xref.header.expect.2">4.3.4.14</a>, <a href="#rfc.iref.e.1"><b>8.3</b></a>, <a href="#rfc.xref.header.expect.3">9.3</a>, <a href="#rfc.xref.header.expect.4">A</a></li>
     3493                  <li>Expect header field&nbsp;&nbsp;<a href="#rfc.xref.header.expect.1">3.2</a>, <a href="#rfc.xref.header.expect.2">4.3.4.14</a>, <a href="#rfc.iref.e.1"><b>7.3</b></a>, <a href="#rfc.xref.header.expect.3">8.3</a>, <a href="#rfc.xref.header.expect.4">A</a></li>
    35473494                  <li>Expect Values&nbsp;&nbsp;
    35483495                     <ul>
    3549                         <li>100-continue&nbsp;&nbsp;<a href="#rfc.iref.e.2"><b>8.3</b></a></li>
     3496                        <li>100-continue&nbsp;&nbsp;<a href="#rfc.iref.e.2"><b>7.3</b></a></li>
    35503497                     </ul>
    35513498                  </li>
    … …  
    35533500            </li>
    35543501            <li><a id="rfc.index.F" href="#rfc.index.F"><b>F</b></a><ul>
    3555                   <li>From header field&nbsp;&nbsp;<a href="#rfc.xref.header.from.1">3.2</a>, <a href="#rfc.iref.f.1"><b>8.4</b></a>, <a href="#rfc.xref.header.from.2">9.3</a></li>
     3502                  <li>From header field&nbsp;&nbsp;<a href="#rfc.xref.header.from.1">3.2</a>, <a href="#rfc.iref.f.1"><b>7.4</b></a>, <a href="#rfc.xref.header.from.2">8.3</a></li>
    35563503               </ul>
    35573504            </li>
    35583505            <li><a id="rfc.index.G" href="#rfc.index.G"><b>G</b></a><ul>
    3559                   <li>GET method&nbsp;&nbsp;<a href="#rfc.xref.GET.1">2.1</a>, <a href="#rfc.iref.g.5"><b>6.3</b></a>, <a href="#rfc.xref.GET.2">9.1</a></li>
     3506                  <li>GET method&nbsp;&nbsp;<a href="#rfc.iref.g.2"><b>2.3.2</b></a>, <a href="#rfc.xref.GET.1">8.1</a></li>
    35603507                  <li><tt>Grammar</tt>&nbsp;&nbsp;
    35613508                     <ul>
    3562                         <li><tt>Allow</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.24"><b>8.1</b></a></li>
    3563                         <li><tt>asctime-date</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.21"><b>7.1</b></a></li>
    3564                         <li><tt>Date</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.25"><b>8.2</b></a></li>
    3565                         <li><tt>date1</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.8"><b>7.1</b></a></li>
    3566                         <li><tt>day</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.15"><b>7.1</b></a></li>
    3567                         <li><tt>day-name</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.13"><b>7.1</b></a></li>
    3568                         <li><tt>day-name-l</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.14"><b>7.1</b></a></li>
    3569                         <li><tt>delta-seconds</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.36"><b>8.8</b></a></li>
    3570                         <li><tt>Expect</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.26"><b>8.3</b></a></li>
    3571                         <li><tt>expect-name</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.30"><b>8.3</b></a></li>
    3572                         <li><tt>expect-param</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.28"><b>8.3</b></a></li>
    3573                         <li><tt>expect-value</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.29"><b>8.3</b></a></li>
    3574                         <li><tt>expectation</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.27"><b>8.3</b></a></li>
    3575                         <li><tt>extension-code</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.3"><b>4</b></a></li>
    3576                         <li><tt>From</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.31"><b>8.4</b></a></li>
    3577                         <li><tt>GMT</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.18"><b>7.1</b></a></li>
    3578                         <li><tt>hour</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.10"><b>7.1</b></a></li>
    3579                         <li><tt>HTTP-date</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.6"><b>7.1</b></a></li>
    3580                         <li><tt>Location</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.32"><b>8.5</b></a></li>
    3581                         <li><tt>Max-Forwards</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.33"><b>8.6</b></a></li>
     3509                        <li><tt>Allow</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.24"><b>7.1</b></a></li>
     3510                        <li><tt>asctime-date</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.21"><b>6.1</b></a></li>
     3511                        <li><tt>Date</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.25"><b>7.2</b></a></li>
     3512                        <li><tt>date1</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.8"><b>6.1</b></a></li>
     3513                        <li><tt>day</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.15"><b>6.1</b></a></li>
     3514                        <li><tt>day-name</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.13"><b>6.1</b></a></li>
     3515                        <li><tt>day-name-l</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.14"><b>6.1</b></a></li>
     3516                        <li><tt>delta-seconds</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.36"><b>7.8</b></a></li>
     3517                        <li><tt>Expect</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.26"><b>7.3</b></a></li>
     3518                        <li><tt>expect-name</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.30"><b>7.3</b></a></li>
     3519                        <li><tt>expect-param</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.28"><b>7.3</b></a></li>
     3520                        <li><tt>expect-value</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.29"><b>7.3</b></a></li>
     3521                        <li><tt>expectation</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.27"><b>7.3</b></a></li>
     3522                        <li><tt>extension-code</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.4"><b>4</b></a></li>
     3523                        <li><tt>From</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.31"><b>7.4</b></a></li>
     3524                        <li><tt>GMT</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.18"><b>6.1</b></a></li>
     3525                        <li><tt>hour</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.10"><b>6.1</b></a></li>
     3526                        <li><tt>HTTP-date</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.6"><b>6.1</b></a></li>
     3527                        <li><tt>Location</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.32"><b>7.5</b></a></li>
     3528                        <li><tt>Max-Forwards</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.33"><b>7.6</b></a></li>
    35823529                        <li><tt>method</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.1"><b>2</b></a></li>
    3583                         <li><tt>minute</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.11"><b>7.1</b></a></li>
    3584                         <li><tt>month</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.16"><b>7.1</b></a></li>
    3585                         <li><tt>obs-date</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.19"><b>7.1</b></a></li>
    3586                         <li><tt>product</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.22"><b>7.2</b></a></li>
    3587                         <li><tt>product-version</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.23"><b>7.2</b></a></li>
    3588                         <li><tt>reason-phrase</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.4"><b>4</b></a></li>
    3589                         <li><tt>Referer</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.34"><b>8.7</b></a></li>
    3590                         <li><tt>Retry-After</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.35"><b>8.8</b></a></li>
    3591                         <li><tt>rfc1123-date</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.7"><b>7.1</b></a></li>
    3592                         <li><tt>rfc850-date</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.20"><b>7.1</b></a></li>
    3593                         <li><tt>second</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.12"><b>7.1</b></a></li>
    3594                         <li><tt>Server</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.37"><b>8.9</b></a></li>
    3595                         <li><tt>status-code</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.2"><b>4</b></a></li>
    3596                         <li><tt>time-of-day</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.9"><b>7.1</b></a></li>
    3597                         <li><tt>User-Agent</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.38"><b>8.10</b></a></li>
    3598                         <li><tt>year</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.17"><b>7.1</b></a></li>
     3530                        <li><tt>minute</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.11"><b>6.1</b></a></li>
     3531                        <li><tt>month</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.16"><b>6.1</b></a></li>
     3532                        <li><tt>obs-date</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.19"><b>6.1</b></a></li>
     3533                        <li><tt>product</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.22"><b>6.2</b></a></li>
     3534                        <li><tt>product-version</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.23"><b>6.2</b></a></li>
     3535                        <li><tt>reason-phrase</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.5"><b>4</b></a></li>
     3536                        <li><tt>Referer</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.34"><b>7.7</b></a></li>
     3537                        <li><tt>Retry-After</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.35"><b>7.8</b></a></li>
     3538                        <li><tt>rfc1123-date</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.7"><b>6.1</b></a></li>
     3539                        <li><tt>rfc850-date</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.20"><b>6.1</b></a></li>
     3540                        <li><tt>second</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.12"><b>6.1</b></a></li>
     3541                        <li><tt>Server</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.37"><b>7.9</b></a></li>
     3542                        <li><tt>status-code</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.3"><b>4</b></a></li>
     3543                        <li><tt>time-of-day</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.9"><b>6.1</b></a></li>
     3544                        <li><tt>User-Agent</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.38"><b>7.10</b></a></li>
     3545                        <li><tt>year</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.17"><b>6.1</b></a></li>
    35993546                     </ul>
    36003547                  </li>
    … …  
    36023549            </li>
    36033550            <li><a id="rfc.index.H" href="#rfc.index.H"><b>H</b></a><ul>
    3604                   <li>HEAD method&nbsp;&nbsp;<a href="#rfc.xref.HEAD.1">2.1</a>, <a href="#rfc.iref.h.1"><b>6.4</b></a>, <a href="#rfc.xref.HEAD.2">9.1</a></li>
     3551                  <li>HEAD method&nbsp;&nbsp;<a href="#rfc.iref.h.1"><b>2.3.3</b></a>, <a href="#rfc.xref.HEAD.1">8.1</a></li>
    36053552                  <li>Header Fields&nbsp;&nbsp;
    36063553                     <ul>
    3607                         <li>Allow&nbsp;&nbsp;<a href="#rfc.xref.header.allow.1">2</a>, <a href="#rfc.xref.header.allow.2">3.3</a>, <a href="#rfc.iref.h.2"><b>8.1</b></a>, <a href="#rfc.xref.header.allow.3">9.3</a>, <a href="#rfc.xref.header.allow.4">A</a></li>
    3608                         <li>Date&nbsp;&nbsp;<a href="#rfc.xref.header.date.1">3.3</a>, <a href="#rfc.iref.h.3"><b>8.2</b></a>, <a href="#rfc.xref.header.date.2">9.3</a></li>
    3609                         <li>Expect&nbsp;&nbsp;<a href="#rfc.xref.header.expect.1">3.2</a>, <a href="#rfc.xref.header.expect.2">4.3.4.14</a>, <a href="#rfc.iref.h.4"><b>8.3</b></a>, <a href="#rfc.xref.header.expect.3">9.3</a>, <a href="#rfc.xref.header.expect.4">A</a></li>
    3610                         <li>From&nbsp;&nbsp;<a href="#rfc.xref.header.from.1">3.2</a>, <a href="#rfc.iref.h.5"><b>8.4</b></a>, <a href="#rfc.xref.header.from.2">9.3</a></li>
    3611                         <li>Location&nbsp;&nbsp;<a href="#rfc.xref.header.location.1">3.3</a>, <a href="#rfc.xref.header.location.2">4.3.3</a>, <a href="#rfc.xref.header.location.3">6.5</a>, <a href="#rfc.iref.h.6"><b>8.5</b></a>, <a href="#rfc.xref.header.location.4">9.3</a>, <a href="#rfc.xref.header.location.5">A</a></li>
    3612                         <li>Max-Forwards&nbsp;&nbsp;<a href="#rfc.xref.header.max-forwards.1">3.2</a>, <a href="#rfc.xref.header.max-forwards.2">6.2</a>, <a href="#rfc.xref.header.max-forwards.3">6.8</a>, <a href="#rfc.iref.h.7"><b>8.6</b></a>, <a href="#rfc.xref.header.max-forwards.4">9.3</a>, <a href="#rfc.xref.header.max-forwards.5">A</a></li>
    3613                         <li>Referer&nbsp;&nbsp;<a href="#rfc.xref.header.referer.1">3.2</a>, <a href="#rfc.iref.h.8"><b>8.7</b></a>, <a href="#rfc.xref.header.referer.2">9.3</a>, <a href="#rfc.xref.header.referer.3">A</a></li>
    3614                         <li>Retry-After&nbsp;&nbsp;<a href="#rfc.xref.header.retry-after.1">3.3</a>, <a href="#rfc.xref.header.retry-after.2">4.3.5.4</a>, <a href="#rfc.iref.h.9"><b>8.8</b></a>, <a href="#rfc.xref.header.retry-after.3">9.3</a></li>
    3615                         <li>Server&nbsp;&nbsp;<a href="#rfc.xref.header.server.1">3.3</a>, <a href="#rfc.iref.h.10"><b>8.9</b></a>, <a href="#rfc.xref.header.server.2">9.3</a>, <a href="#rfc.xref.header.server.3">10.1</a>, <a href="#rfc.xref.header.server.4">A</a></li>
    3616                         <li>User-Agent&nbsp;&nbsp;<a href="#rfc.xref.header.user-agent.1">3.2</a>, <a href="#rfc.iref.h.11"><b>8.10</b></a>, <a href="#rfc.xref.header.user-agent.2">9.3</a>, <a href="#rfc.xref.header.user-agent.3">10.1</a></li>
     3554                        <li>Allow&nbsp;&nbsp;<a href="#rfc.xref.header.allow.1">2</a>, <a href="#rfc.xref.header.allow.2">3.3</a>, <a href="#rfc.iref.h.2"><b>7.1</b></a>, <a href="#rfc.xref.header.allow.3">8.3</a>, <a href="#rfc.xref.header.allow.4">A</a></li>
     3555                        <li>Date&nbsp;&nbsp;<a href="#rfc.xref.header.date.1">3.3</a>, <a href="#rfc.iref.h.3"><b>7.2</b></a>, <a href="#rfc.xref.header.date.2">8.3</a></li>
     3556                        <li>Expect&nbsp;&nbsp;<a href="#rfc.xref.header.expect.1">3.2</a>, <a href="#rfc.xref.header.expect.2">4.3.4.14</a>, <a href="#rfc.iref.h.4"><b>7.3</b></a>, <a href="#rfc.xref.header.expect.3">8.3</a>, <a href="#rfc.xref.header.expect.4">A</a></li>
     3557                        <li>From&nbsp;&nbsp;<a href="#rfc.xref.header.from.1">3.2</a>, <a href="#rfc.iref.h.5"><b>7.4</b></a>, <a href="#rfc.xref.header.from.2">8.3</a></li>
     3558                        <li>Location&nbsp;&nbsp;<a href="#rfc.xref.header.location.1">2.3.4</a>, <a href="#rfc.xref.header.location.2">3.3</a>, <a href="#rfc.xref.header.location.3">4.3.3</a>, <a href="#rfc.iref.h.6"><b>7.5</b></a>, <a href="#rfc.xref.header.location.4">8.3</a>, <a href="#rfc.xref.header.location.5">A</a></li>
     3559                        <li>Max-Forwards&nbsp;&nbsp;<a href="#rfc.xref.header.max-forwards.1">2.3.1</a>, <a href="#rfc.xref.header.max-forwards.2">2.3.7</a>, <a href="#rfc.xref.header.max-forwards.3">3.2</a>, <a href="#rfc.iref.h.7"><b>7.6</b></a>, <a href="#rfc.xref.header.max-forwards.4">8.3</a>, <a href="#rfc.xref.header.max-forwards.5">A</a></li>
     3560                        <li>Referer&nbsp;&nbsp;<a href="#rfc.xref.header.referer.1">3.2</a>, <a href="#rfc.iref.h.8"><b>7.7</b></a>, <a href="#rfc.xref.header.referer.2">8.3</a>, <a href="#rfc.xref.header.referer.3">A</a></li>
     3561                        <li>Retry-After&nbsp;&nbsp;<a href="#rfc.xref.header.retry-after.1">3.3</a>, <a href="#rfc.xref.header.retry-after.2">4.3.5.4</a>, <a href="#rfc.iref.h.9"><b>7.8</b></a>, <a href="#rfc.xref.header.retry-after.3">8.3</a></li>
     3562                        <li>Server&nbsp;&nbsp;<a href="#rfc.xref.header.server.1">3.3</a>, <a href="#rfc.iref.h.10"><b>7.9</b></a>, <a href="#rfc.xref.header.server.2">8.3</a>, <a href="#rfc.xref.header.server.3">9.1</a>, <a href="#rfc.xref.header.server.4">A</a></li>
     3563                        <li>User-Agent&nbsp;&nbsp;<a href="#rfc.xref.header.user-agent.1">3.2</a>, <a href="#rfc.iref.h.11"><b>7.10</b></a>, <a href="#rfc.xref.header.user-agent.2">8.3</a>, <a href="#rfc.xref.header.user-agent.3">9.1</a></li>
    36173564                     </ul>
    36183565                  </li>
    … …  
    36203567            </li>
    36213568            <li><a id="rfc.index.I" href="#rfc.index.I"><b>I</b></a><ul>
    3622                   <li>Idempotent Methods&nbsp;&nbsp;<a href="#rfc.iref.i.1"><b>6.1.2</b></a></li>
     3569                  <li>Idempotent Methods&nbsp;&nbsp;<a href="#rfc.iref.i.1"><b>2.1.2</b></a></li>
    36233570               </ul>
    36243571            </li>
    36253572            <li><a id="rfc.index.L" href="#rfc.index.L"><b>L</b></a><ul>
    3626                   <li>Location header field&nbsp;&nbsp;<a href="#rfc.xref.header.location.1">3.3</a>, <a href="#rfc.xref.header.location.2">4.3.3</a>, <a href="#rfc.xref.header.location.3">6.5</a>, <a href="#rfc.iref.l.1"><b>8.5</b></a>, <a href="#rfc.xref.header.location.4">9.3</a>, <a href="#rfc.xref.header.location.5">A</a></li>
     3573                  <li>Location header field&nbsp;&nbsp;<a href="#rfc.xref.header.location.1">2.3.4</a>, <a href="#rfc.xref.header.location.2">3.3</a>, <a href="#rfc.xref.header.location.3">4.3.3</a>, <a href="#rfc.iref.l.1"><b>7.5</b></a>, <a href="#rfc.xref.header.location.4">8.3</a>, <a href="#rfc.xref.header.location.5">A</a></li>
    36273574               </ul>
    36283575            </li>
    36293576            <li><a id="rfc.index.M" href="#rfc.index.M"><b>M</b></a><ul>
    3630                   <li>Max-Forwards header field&nbsp;&nbsp;<a href="#rfc.xref.header.max-forwards.1">3.2</a>, <a href="#rfc.xref.header.max-forwards.2">6.2</a>, <a href="#rfc.xref.header.max-forwards.3">6.8</a>, <a href="#rfc.iref.m.9"><b>8.6</b></a>, <a href="#rfc.xref.header.max-forwards.4">9.3</a>, <a href="#rfc.xref.header.max-forwards.5">A</a></li>
     3577                  <li>Max-Forwards header field&nbsp;&nbsp;<a href="#rfc.xref.header.max-forwards.1">2.3.1</a>, <a href="#rfc.xref.header.max-forwards.2">2.3.7</a>, <a href="#rfc.xref.header.max-forwards.3">3.2</a>, <a href="#rfc.iref.m.9"><b>7.6</b></a>, <a href="#rfc.xref.header.max-forwards.4">8.3</a>, <a href="#rfc.xref.header.max-forwards.5">A</a></li>
    36313578                  <li>Methods&nbsp;&nbsp;
    36323579                     <ul>
    3633                         <li>CONNECT&nbsp;&nbsp;<a href="#rfc.xref.CONNECT.1">2.1</a>, <a href="#rfc.iref.m.8"><b>6.9</b></a>, <a href="#rfc.xref.CONNECT.2">9.1</a>, <a href="#rfc.xref.CONNECT.3">A</a></li>
    3634                         <li>DELETE&nbsp;&nbsp;<a href="#rfc.xref.DELETE.1">2.1</a>, <a href="#rfc.iref.m.6"><b>6.7</b></a>, <a href="#rfc.xref.DELETE.2">9.1</a></li>
    3635                         <li>GET&nbsp;&nbsp;<a href="#rfc.xref.GET.1">2.1</a>, <a href="#rfc.iref.m.2"><b>6.3</b></a>, <a href="#rfc.xref.GET.2">9.1</a></li>
    3636                         <li>HEAD&nbsp;&nbsp;<a href="#rfc.xref.HEAD.1">2.1</a>, <a href="#rfc.iref.m.3"><b>6.4</b></a>, <a href="#rfc.xref.HEAD.2">9.1</a></li>
    3637                         <li>OPTIONS&nbsp;&nbsp;<a href="#rfc.xref.OPTIONS.1">2.1</a>, <a href="#rfc.iref.m.1"><b>6.2</b></a>, <a href="#rfc.xref.OPTIONS.2">8.6</a>, <a href="#rfc.xref.OPTIONS.3">9.1</a></li>
    3638                         <li>POST&nbsp;&nbsp;<a href="#rfc.xref.POST.1">2.1</a>, <a href="#rfc.iref.m.4"><b>6.5</b></a>, <a href="#rfc.xref.POST.2">9.1</a>, <a href="#rfc.xref.POST.3">A</a></li>
    3639                         <li>PUT&nbsp;&nbsp;<a href="#rfc.xref.PUT.1">2.1</a>, <a href="#rfc.iref.m.5"><b>6.6</b></a>, <a href="#rfc.xref.PUT.2">9.1</a>, <a href="#rfc.xref.PUT.3">A</a></li>
    3640                         <li>TRACE&nbsp;&nbsp;<a href="#rfc.xref.TRACE.1">2.1</a>, <a href="#rfc.iref.m.7"><b>6.8</b></a>, <a href="#rfc.xref.TRACE.2">8.6</a>, <a href="#rfc.xref.TRACE.3">9.1</a>, <a href="#rfc.xref.TRACE.4">10.1</a></li>
     3580                        <li>CONNECT&nbsp;&nbsp;<a href="#rfc.iref.m.8"><b>2.3.8</b></a>, <a href="#rfc.xref.CONNECT.1">8.1</a>, <a href="#rfc.xref.CONNECT.2">A</a></li>
     3581                        <li>DELETE&nbsp;&nbsp;<a href="#rfc.iref.m.6"><b>2.3.6</b></a>, <a href="#rfc.xref.DELETE.1">8.1</a></li>
     3582                        <li>GET&nbsp;&nbsp;<a href="#rfc.iref.m.2"><b>2.3.2</b></a>, <a href="#rfc.xref.GET.1">8.1</a></li>
     3583                        <li>HEAD&nbsp;&nbsp;<a href="#rfc.iref.m.3"><b>2.3.3</b></a>, <a href="#rfc.xref.HEAD.1">8.1</a></li>
     3584                        <li>OPTIONS&nbsp;&nbsp;<a href="#rfc.iref.m.1"><b>2.3.1</b></a>, <a href="#rfc.xref.OPTIONS.1">7.6</a>, <a href="#rfc.xref.OPTIONS.2">8.1</a></li>
     3585                        <li>POST&nbsp;&nbsp;<a href="#rfc.iref.m.4"><b>2.3.4</b></a>, <a href="#rfc.xref.POST.1">8.1</a>, <a href="#rfc.xref.POST.2">A</a></li>
     3586                        <li>PUT&nbsp;&nbsp;<a href="#rfc.iref.m.5"><b>2.3.5</b></a>, <a href="#rfc.xref.PUT.1">8.1</a>, <a href="#rfc.xref.PUT.2">A</a></li>
     3587                        <li>TRACE&nbsp;&nbsp;<a href="#rfc.iref.m.7"><b>2.3.7</b></a>, <a href="#rfc.xref.TRACE.1">7.6</a>, <a href="#rfc.xref.TRACE.2">8.1</a>, <a href="#rfc.xref.TRACE.3">9.1</a></li>
    36413588                     </ul>
    36423589                  </li>
    … …  
    36443591            </li>
    36453592            <li><a id="rfc.index.O" href="#rfc.index.O"><b>O</b></a><ul>
    3646                   <li>OPTIONS method&nbsp;&nbsp;<a href="#rfc.xref.OPTIONS.1">2.1</a>, <a href="#rfc.iref.o.1"><b>6.2</b></a>, <a href="#rfc.xref.OPTIONS.2">8.6</a>, <a href="#rfc.xref.OPTIONS.3">9.1</a></li>
     3593                  <li>OPTIONS method&nbsp;&nbsp;<a href="#rfc.iref.o.1"><b>2.3.1</b></a>, <a href="#rfc.xref.OPTIONS.1">7.6</a>, <a href="#rfc.xref.OPTIONS.2">8.1</a></li>
    36473594               </ul>
    36483595            </li>
    36493596            <li><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul>
    3650                   <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">1.2.1</a>, <a href="#rfc.xref.Part1.5">1.2.1</a>, <a href="#rfc.xref.Part1.6">1.2.1</a>, <a href="#rfc.xref.Part1.7">1.2.1</a>, <a href="#rfc.xref.Part1.8">1.2.1</a>, <a href="#rfc.xref.Part1.9">1.2.1</a>, <a href="#rfc.xref.Part1.10">1.2.1</a>, <a href="#rfc.xref.Part1.11">1.2.2</a>, <a href="#rfc.xref.Part1.12">1.2.2</a>, <a href="#rfc.xref.Part1.13">1.2.2</a>, <a href="#rfc.xref.Part1.14">1.2.2</a>, <a href="#rfc.xref.Part1.15">2</a>, <a href="#rfc.xref.Part1.16">2.2.1</a>, <a href="#rfc.xref.Part1.17">3</a>, <a href="#rfc.xref.Part1.18">3.1</a>, <a href="#rfc.xref.Part1.19">3.1</a>, <a href="#rfc.xref.Part1.20">3.1</a>, <a href="#rfc.xref.Part1.21">3.1</a>, <a href="#rfc.xref.Part1.22">3.1</a>, <a href="#rfc.xref.Part1.23">3.2</a>, <a href="#rfc.xref.Part1.24">3.2</a>, <a href="#rfc.xref.Part1.25">3.3</a>, <a href="#rfc.xref.Part1.26">4.3.1.1</a>, <a href="#rfc.xref.Part1.27">4.3.1.2</a>, <a href="#rfc.xref.Part1.28">4.3.2.4</a>, <a href="#rfc.xref.Part1.29">4.3.2.6</a>, <a href="#rfc.xref.Part1.30">4.3.4.15</a>, <a href="#rfc.xref.Part1.31">4.3.5.6</a>, <a href="#rfc.xref.Part1.32">5</a>, <a href="#rfc.xref.Part1.33">5.1</a>, <a href="#rfc.xref.Part1.34">6.2</a>, <a href="#rfc.xref.Part1.35">6.8</a>, <a href="#rfc.xref.Part1.36">6.8</a>, <a href="#rfc.xref.Part1.37">6.9</a>, <a href="#rfc.xref.Part1.38">8.3</a>, <a href="#rfc.xref.Part1.39">8.9</a>, <a href="#rfc.xref.Part1.40">8.9</a>, <a href="#rfc.xref.Part1.41">8.10</a>, <a href="#rfc.xref.Part1.42">11</a>, <a href="#Part1"><b>12.1</b></a>, <a href="#rfc.xref.Part1.43">A</a><ul>
     3597                  <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">1.2.1</a>, <a href="#rfc.xref.Part1.5">1.2.1</a>, <a href="#rfc.xref.Part1.6">1.2.1</a>, <a href="#rfc.xref.Part1.7">1.2.1</a>, <a href="#rfc.xref.Part1.8">1.2.1</a>, <a href="#rfc.xref.Part1.9">1.2.1</a>, <a href="#rfc.xref.Part1.10">1.2.1</a>, <a href="#rfc.xref.Part1.11">1.2.2</a>, <a href="#rfc.xref.Part1.12">1.2.2</a>, <a href="#rfc.xref.Part1.13">1.2.2</a>, <a href="#rfc.xref.Part1.14">1.2.2</a>, <a href="#rfc.xref.Part1.15">2</a>, <a href="#rfc.xref.Part1.16">2.2.1</a>, <a href="#rfc.xref.Part1.17">2.3.1</a>, <a href="#rfc.xref.Part1.18">2.3.7</a>, <a href="#rfc.xref.Part1.19">2.3.7</a>, <a href="#rfc.xref.Part1.20">2.3.8</a>, <a href="#rfc.xref.Part1.21">3</a>, <a href="#rfc.xref.Part1.22">3.1</a>, <a href="#rfc.xref.Part1.23">3.1</a>, <a href="#rfc.xref.Part1.24">3.1</a>, <a href="#rfc.xref.Part1.25">3.1</a>, <a href="#rfc.xref.Part1.26">3.1</a>, <a href="#rfc.xref.Part1.27">3.2</a>, <a href="#rfc.xref.Part1.28">3.2</a>, <a href="#rfc.xref.Part1.29">3.3</a>, <a href="#rfc.xref.Part1.30">4.3.1.1</a>, <a href="#rfc.xref.Part1.31">4.3.1.2</a>, <a href="#rfc.xref.Part1.32">4.3.2.4</a>, <a href="#rfc.xref.Part1.33">4.3.2.6</a>, <a href="#rfc.xref.Part1.34">4.3.4.15</a>, <a href="#rfc.xref.Part1.35">4.3.5.6</a>, <a href="#rfc.xref.Part1.36">5</a>, <a href="#rfc.xref.Part1.37">5.1</a>, <a href="#rfc.xref.Part1.38">7.3</a>, <a href="#rfc.xref.Part1.39">7.9</a>, <a href="#rfc.xref.Part1.40">7.9</a>, <a href="#rfc.xref.Part1.41">7.10</a>, <a href="#rfc.xref.Part1.42">10</a>, <a href="#Part1"><b>11.1</b></a>, <a href="#rfc.xref.Part1.43">A</a><ul>
    36513598                        <li><em>Section 1.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.3">1.2</a></li>
    36523599                        <li><em>Section 2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.2">1.1</a></li>
    3653                         <li><em>Section 2.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.28">4.3.2.4</a></li>
    3654                         <li><em>Section 2.6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.31">4.3.5.6</a></li>
     3600                        <li><em>Section 2.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.32">4.3.2.4</a></li>
     3601                        <li><em>Section 2.6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.35">4.3.5.6</a></li>
    36553602                        <li><em>Section 2.7</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.11">1.2.2</a>, <a href="#rfc.xref.Part1.13">1.2.2</a>, <a href="#rfc.xref.Part1.14">1.2.2</a></li>
    36563603                        <li><em>Section 3.2.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.5">1.2.1</a>, <a href="#rfc.xref.Part1.6">1.2.1</a>, <a href="#rfc.xref.Part1.7">1.2.1</a></li>
    3657                         <li><em>Section 3.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.17">3</a>, <a href="#rfc.xref.Part1.20">3.1</a>, <a href="#rfc.xref.Part1.39">8.9</a>, <a href="#rfc.xref.Part1.41">8.10</a></li>
    3658                         <li><em>Section 3.2.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.8">1.2.1</a>, <a href="#rfc.xref.Part1.9">1.2.1</a>, <a href="#rfc.xref.Part1.10">1.2.1</a>, <a href="#rfc.xref.Part1.12">1.2.2</a>, <a href="#rfc.xref.Part1.19">3.1</a></li>
    3659                         <li><em>Section 3.2.5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.18">3.1</a></li>
    3660                         <li><em>Section 3.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.16">2.2.1</a>, <a href="#rfc.xref.Part1.29">4.3.2.6</a>, <a href="#rfc.xref.Part1.32">5</a></li>
    3661                         <li><em>Section 4.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.22">3.1</a></li>
    3662                         <li><em>Section 4.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.24">3.2</a></li>
    3663                         <li><em>Section 5.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.34">6.2</a>, <a href="#rfc.xref.Part1.37">6.9</a></li>
    3664                         <li><em>Section 5.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.23">3.2</a></li>
    3665                         <li><em>Section 5.5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.15">2</a>, <a href="#rfc.xref.Part1.25">3.3</a>, <a href="#rfc.xref.Part1.33">5.1</a></li>
    3666                         <li><em>Section 6.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.21">3.1</a></li>
    3667                         <li><em>Section 6.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.35">6.8</a>, <a href="#rfc.xref.Part1.40">8.9</a>, <a href="#rfc.xref.Part1.43">A</a></li>
    3668                         <li><em>Section 6.4.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.26">4.3.1.1</a>, <a href="#rfc.xref.Part1.38">8.3</a></li>
    3669                         <li><em>Section 6.5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.27">4.3.1.2</a>, <a href="#rfc.xref.Part1.30">4.3.4.15</a></li>
    3670                         <li><em>Section 7.3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.36">6.8</a></li>
    3671                         <li><em>Section 9</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.42">11</a></li>
     3604                        <li><em>Section 3.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.21">3</a>, <a href="#rfc.xref.Part1.24">3.1</a>, <a href="#rfc.xref.Part1.39">7.9</a>, <a href="#rfc.xref.Part1.41">7.10</a></li>
     3605                        <li><em>Section 3.2.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.8">1.2.1</a>, <a href="#rfc.xref.Part1.9">1.2.1</a>, <a href="#rfc.xref.Part1.10">1.2.1</a>, <a href="#rfc.xref.Part1.12">1.2.2</a>, <a href="#rfc.xref.Part1.23">3.1</a></li>
     3606                        <li><em>Section 3.2.5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.22">3.1</a></li>
     3607                        <li><em>Section 3.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.16">2.2.1</a>, <a href="#rfc.xref.Part1.33">4.3.2.6</a>, <a href="#rfc.xref.Part1.36">5</a></li>
     3608                        <li><em>Section 4.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.26">3.1</a></li>
     3609                        <li><em>Section 4.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.28">3.2</a></li>
     3610                        <li><em>Section 5.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.17">2.3.1</a>, <a href="#rfc.xref.Part1.20">2.3.8</a></li>
     3611                        <li><em>Section 5.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.27">3.2</a></li>
     3612                        <li><em>Section 5.5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.15">2</a>, <a href="#rfc.xref.Part1.29">3.3</a>, <a href="#rfc.xref.Part1.37">5.1</a></li>
     3613                        <li><em>Section 6.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.25">3.1</a></li>
     3614                        <li><em>Section 6.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.18">2.3.7</a>, <a href="#rfc.xref.Part1.40">7.9</a>, <a href="#rfc.xref.Part1.43">A</a></li>
     3615                        <li><em>Section 6.4.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.30">4.3.1.1</a>, <a href="#rfc.xref.Part1.38">7.3</a></li>
     3616                        <li><em>Section 6.5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.31">4.3.1.2</a>, <a href="#rfc.xref.Part1.34">4.3.4.15</a></li>
     3617                        <li><em>Section 7.3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.19">2.3.7</a></li>
     3618                        <li><em>Section 9</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.42">10</a></li>
    36723619                     </ul>
    36733620                  </li>
    3674                   <li><em>Part3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part3.1">3.1</a>, <a href="#rfc.xref.Part3.2">3.1</a>, <a href="#rfc.xref.Part3.3">3.2</a>, <a href="#rfc.xref.Part3.4">3.2</a>, <a href="#rfc.xref.Part3.5">3.2</a>, <a href="#rfc.xref.Part3.6">3.2</a>, <a href="#rfc.xref.Part3.7">4.3</a>, <a href="#rfc.xref.Part3.8">4.3.3</a>, <a href="#rfc.xref.Part3.9">4.3.3.1</a>, <a href="#rfc.xref.Part3.10">4.3.4.6</a>, <a href="#rfc.xref.Part3.11">5</a>, <a href="#rfc.xref.Part3.12">6.5</a>, <a href="#rfc.xref.Part3.13">8.5</a>, <a href="#Part3"><b>12.1</b></a><ul>
    3675                         <li><em>Section 2.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part3.2">3.1</a></li>
    3676                         <li><em>Section 5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part3.9">4.3.3.1</a></li>
    3677                         <li><em>Section 5.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part3.8">4.3.3</a></li>
    3678                         <li><em>Section 6.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part3.3">3.2</a></li>
    3679                         <li><em>Section 6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part3.10">4.3.4.6</a></li>
    3680                         <li><em>Section 6.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part3.4">3.2</a></li>
    3681                         <li><em>Section 6.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part3.5">3.2</a></li>
    3682                         <li><em>Section 6.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part3.6">3.2</a></li>
    3683                         <li><em>Section 6.7</em>&nbsp;&nbsp;<a href="#rfc.xref.Part3.12">6.5</a>, <a href="#rfc.xref.Part3.13">8.5</a></li>
    3684                         <li><em>Section 6.8</em>&nbsp;&nbsp;<a href="#rfc.xref.Part3.1">3.1</a>, <a href="#rfc.xref.Part3.7">4.3</a></li>
     3621                  <li><em>Part3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part3.1">2.3.4</a>, <a href="#rfc.xref.Part3.2">3.1</a>, <a href="#rfc.xref.Part3.3">3.1</a>, <a href="#rfc.xref.Part3.4">3.2</a>, <a href="#rfc.xref.Part3.5">3.2</a>, <a href="#rfc.xref.Part3.6">3.2</a>, <a href="#rfc.xref.Part3.7">3.2</a>, <a href="#rfc.xref.Part3.8">4.3</a>, <a href="#rfc.xref.Part3.9">4.3.3</a>, <a href="#rfc.xref.Part3.10">4.3.3.1</a>, <a href="#rfc.xref.Part3.11">4.3.4.6</a>, <a href="#rfc.xref.Part3.12">5</a>, <a href="#rfc.xref.Part3.13">7.5</a>, <a href="#Part3"><b>11.1</b></a><ul>
     3622                        <li><em>Section 2.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part3.3">3.1</a></li>
     3623                        <li><em>Section 5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part3.10">4.3.3.1</a></li>
     3624                        <li><em>Section 5.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part3.9">4.3.3</a></li>
     3625                        <li><em>Section 6.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part3.4">3.2</a></li>
     3626                        <li><em>Section 6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part3.11">4.3.4.6</a></li>
     3627                        <li><em>Section 6.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part3.5">3.2</a></li>
     3628                        <li><em>Section 6.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part3.6">3.2</a></li>
     3629                        <li><em>Section 6.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part3.7">3.2</a></li>
     3630                        <li><em>Section 6.7</em>&nbsp;&nbsp;<a href="#rfc.xref.Part3.1">2.3.4</a>, <a href="#rfc.xref.Part3.13">7.5</a></li>
     3631                        <li><em>Section 6.8</em>&nbsp;&nbsp;<a href="#rfc.xref.Part3.2">3.1</a>, <a href="#rfc.xref.Part3.8">4.3</a></li>
    36853632                     </ul>
    36863633                  </li>
    3687                   <li><em>Part4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.1">3.2</a>, <a href="#rfc.xref.Part4.2">3.2</a>, <a href="#rfc.xref.Part4.3">3.2</a>, <a href="#rfc.xref.Part4.4">3.2</a>, <a href="#rfc.xref.Part4.5">3.3</a>, <a href="#rfc.xref.Part4.6">4.1</a>, <a href="#rfc.xref.Part4.7">4.1</a>, <a href="#rfc.xref.Part4.8">4.1</a>, <a href="#rfc.xref.Part4.9">4.3.2.2</a>, <a href="#rfc.xref.Part4.10">4.3.3</a>, <a href="#Part4"><b>12.1</b></a>, <a href="#rfc.xref.Part4.11">C.2</a><ul>
     3634                  <li><em>Part4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.1">3.2</a>, <a href="#rfc.xref.Part4.2">3.2</a>, <a href="#rfc.xref.Part4.3">3.2</a>, <a href="#rfc.xref.Part4.4">3.2</a>, <a href="#rfc.xref.Part4.5">3.3</a>, <a href="#rfc.xref.Part4.6">4.1</a>, <a href="#rfc.xref.Part4.7">4.1</a>, <a href="#rfc.xref.Part4.8">4.1</a>, <a href="#rfc.xref.Part4.9">4.3.2.2</a>, <a href="#rfc.xref.Part4.10">4.3.3</a>, <a href="#Part4"><b>11.1</b></a>, <a href="#rfc.xref.Part4.11">C.2</a><ul>
    36883635                        <li><em>Section 2.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.5">3.3</a>, <a href="#rfc.xref.Part4.9">4.3.2.2</a></li>
    36893636                        <li><em>Section 3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.1">3.2</a></li>
    … …  
    36963643                     </ul>
    36973644                  </li>
    3698                   <li><em>Part5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part5.1">3.2</a>, <a href="#rfc.xref.Part5.2">3.2</a>, <a href="#rfc.xref.Part5.3">3.3</a>, <a href="#rfc.xref.Part5.4">4.1</a>, <a href="#rfc.xref.Part5.5">4.1</a>, <a href="#rfc.xref.Part5.6">4.1</a>, <a href="#rfc.xref.Part5.7">6.3</a>, <a href="#Part5"><b>12.1</b></a><ul>
    3699                         <li><em>Section 3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part5.4">4.1</a></li>
    3700                         <li><em>Section 3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part5.5">4.1</a></li>
    3701                         <li><em>Section 3.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part5.6">4.1</a></li>
    3702                         <li><em>Section 5.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part5.3">3.3</a></li>
    3703                         <li><em>Section 5.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part5.1">3.2</a></li>
    3704                         <li><em>Section 5.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part5.2">3.2</a>, <a href="#rfc.xref.Part5.7">6.3</a></li>
     3645                  <li><em>Part5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part5.1">2.3.2</a>, <a href="#rfc.xref.Part5.2">3.2</a>, <a href="#rfc.xref.Part5.3">3.2</a>, <a href="#rfc.xref.Part5.4">3.3</a>, <a href="#rfc.xref.Part5.5">4.1</a>, <a href="#rfc.xref.Part5.6">4.1</a>, <a href="#rfc.xref.Part5.7">4.1</a>, <a href="#Part5"><b>11.1</b></a><ul>
     3646                        <li><em>Section 3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part5.5">4.1</a></li>
     3647                        <li><em>Section 3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part5.6">4.1</a></li>
     3648                        <li><em>Section 3.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part5.7">4.1</a></li>
     3649                        <li><em>Section 5.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part5.4">3.3</a></li>
     3650                        <li><em>Section 5.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part5.2">3.2</a></li>
     3651                        <li><em>Section 5.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part5.1">2.3.2</a>, <a href="#rfc.xref.Part5.3">3.2</a></li>
    37053652                     </ul>
    37063653                  </li>
    3707                   <li><em>Part6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.1">2.2.1</a>, <a href="#rfc.xref.Part6.2">3.1</a>, <a href="#rfc.xref.Part6.3">3.3</a>, <a href="#rfc.xref.Part6.4">3.3</a>, <a href="#rfc.xref.Part6.5">4.2.1</a>, <a href="#rfc.xref.Part6.6">4.3.2.1</a>, <a href="#rfc.xref.Part6.7">4.3.2.4</a>, <a href="#rfc.xref.Part6.8">4.3.2.4</a>, <a href="#rfc.xref.Part6.9">4.3.2.4</a>, <a href="#rfc.xref.Part6.10">4.3.3.1</a>, <a href="#rfc.xref.Part6.11">4.3.3.2</a>, <a href="#rfc.xref.Part6.12">4.3.4.9</a>, <a href="#rfc.xref.Part6.13">6.3</a>, <a href="#rfc.xref.Part6.14">6.4</a>, <a href="#rfc.xref.Part6.15">6.5</a>, <a href="#rfc.xref.Part6.16">6.6</a>, <a href="#rfc.xref.Part6.17">6.7</a>, <a href="#Part6"><b>12.1</b></a><ul>
    3708                         <li><em>Section 2.3.1.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.6">4.3.2.1</a>, <a href="#rfc.xref.Part6.9">4.3.2.4</a>, <a href="#rfc.xref.Part6.10">4.3.3.1</a>, <a href="#rfc.xref.Part6.11">4.3.3.2</a>, <a href="#rfc.xref.Part6.12">4.3.4.9</a></li>
    3709                         <li><em>Section 2.3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.15">6.5</a></li>
    3710                         <li><em>Section 2.5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.14">6.4</a></li>
    3711                         <li><em>Section 2.6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.16">6.6</a>, <a href="#rfc.xref.Part6.17">6.7</a></li>
    3712                         <li><em>Section 3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.3">3.3</a></li>
    3713                         <li><em>Section 3.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.7">4.3.2.4</a></li>
    3714                         <li><em>Section 3.5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.4">3.3</a></li>
    3715                         <li><em>Section 3.6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.8">4.3.2.4</a></li>
     3654                  <li><em>Part6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.1">2.2.1</a>, <a href="#rfc.xref.Part6.2">2.3.2</a>, <a href="#rfc.xref.Part6.3">2.3.3</a>, <a href="#rfc.xref.Part6.4">2.3.4</a>, <a href="#rfc.xref.Part6.5">2.3.5</a>, <a href="#rfc.xref.Part6.6">2.3.6</a>, <a href="#rfc.xref.Part6.7">3.1</a>, <a href="#rfc.xref.Part6.8">3.3</a>, <a href="#rfc.xref.Part6.9">3.3</a>, <a href="#rfc.xref.Part6.10">4.2.1</a>, <a href="#rfc.xref.Part6.11">4.3.2.1</a>, <a href="#rfc.xref.Part6.12">4.3.2.4</a>, <a href="#rfc.xref.Part6.13">4.3.2.4</a>, <a href="#rfc.xref.Part6.14">4.3.2.4</a>, <a href="#rfc.xref.Part6.15">4.3.3.1</a>, <a href="#rfc.xref.Part6.16">4.3.3.2</a>, <a href="#rfc.xref.Part6.17">4.3.4.9</a>, <a href="#Part6"><b>11.1</b></a><ul>
     3655                        <li><em>Section 2.3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.4">2.3.4</a></li>
     3656                        <li><em>Section 2.3.1.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.11">4.3.2.1</a>, <a href="#rfc.xref.Part6.14">4.3.2.4</a>, <a href="#rfc.xref.Part6.15">4.3.3.1</a>, <a href="#rfc.xref.Part6.16">4.3.3.2</a>, <a href="#rfc.xref.Part6.17">4.3.4.9</a></li>
     3657                        <li><em>Section 2.5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.3">2.3.3</a></li>
     3658                        <li><em>Section 2.6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.5">2.3.5</a>, <a href="#rfc.xref.Part6.6">2.3.6</a></li>
     3659                        <li><em>Section 3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.8">3.3</a></li>
     3660                        <li><em>Section 3.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.12">4.3.2.4</a></li>
     3661                        <li><em>Section 3.5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.9">3.3</a></li>
     3662                        <li><em>Section 3.6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.13">4.3.2.4</a></li>
    37163663                     </ul>
    37173664                  </li>
    3718                   <li><em>Part7</em>&nbsp;&nbsp;<a href="#rfc.xref.Part7.1">3.2</a>, <a href="#rfc.xref.Part7.2">3.2</a>, <a href="#rfc.xref.Part7.3">3.3</a>, <a href="#rfc.xref.Part7.4">3.3</a>, <a href="#rfc.xref.Part7.5">4.1</a>, <a href="#rfc.xref.Part7.6">4.1</a>, <a href="#rfc.xref.Part7.7">4.1</a>, <a href="#Part7"><b>12.1</b></a><ul>
     3665                  <li><em>Part7</em>&nbsp;&nbsp;<a href="#rfc.xref.Part7.1">3.2</a>, <a href="#rfc.xref.Part7.2">3.2</a>, <a href="#rfc.xref.Part7.3">3.3</a>, <a href="#rfc.xref.Part7.4">3.3</a>, <a href="#rfc.xref.Part7.5">4.1</a>, <a href="#rfc.xref.Part7.6">4.1</a>, <a href="#rfc.xref.Part7.7">4.1</a>, <a href="#Part7"><b>11.1</b></a><ul>
    37193666                        <li><em>Section 3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part7.5">4.1</a></li>
    37203667                        <li><em>Section 3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part7.6">4.1</a></li>
    … …  
    37263673                     </ul>
    37273674                  </li>
    3728                   <li>POST method&nbsp;&nbsp;<a href="#rfc.xref.POST.1">2.1</a>, <a href="#rfc.iref.p.1"><b>6.5</b></a>, <a href="#rfc.xref.POST.2">9.1</a>, <a href="#rfc.xref.POST.3">A</a></li>
    3729                   <li>PUT method&nbsp;&nbsp;<a href="#rfc.xref.PUT.1">2.1</a>, <a href="#rfc.iref.p.2"><b>6.6</b></a>, <a href="#rfc.xref.PUT.2">9.1</a>, <a href="#rfc.xref.PUT.3">A</a></li>
     3675                  <li>POST method&nbsp;&nbsp;<a href="#rfc.iref.p.1"><b>2.3.4</b></a>, <a href="#rfc.xref.POST.1">8.1</a>, <a href="#rfc.xref.POST.2">A</a></li>
     3676                  <li>PUT method&nbsp;&nbsp;<a href="#rfc.iref.p.2"><b>2.3.5</b></a>, <a href="#rfc.xref.PUT.1">8.1</a>, <a href="#rfc.xref.PUT.2">A</a></li>
    37303677               </ul>
    37313678            </li>
    37323679            <li><a id="rfc.index.R" href="#rfc.index.R"><b>R</b></a><ul>
    3733                   <li>Referer header field&nbsp;&nbsp;<a href="#rfc.xref.header.referer.1">3.2</a>, <a href="#rfc.iref.r.1"><b>8.7</b></a>, <a href="#rfc.xref.header.referer.2">9.3</a>, <a href="#rfc.xref.header.referer.3">A</a></li>
    3734                   <li>Retry-After header field&nbsp;&nbsp;<a href="#rfc.xref.header.retry-after.1">3.3</a>, <a href="#rfc.xref.header.retry-after.2">4.3.5.4</a>, <a href="#rfc.iref.r.2"><b>8.8</b></a>, <a href="#rfc.xref.header.retry-after.3">9.3</a></li>
    3735                   <li><em>RFC1123</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC1123.1">7.1</a>, <a href="#rfc.xref.RFC1123.2">7.1</a>, <a href="#RFC1123"><b>12.2</b></a><ul>
    3736                         <li><em>Section 5.2.14</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC1123.2">7.1</a></li>
     3680                  <li>Referer header field&nbsp;&nbsp;<a href="#rfc.xref.header.referer.1">3.2</a>, <a href="#rfc.iref.r.1"><b>7.7</b></a>, <a href="#rfc.xref.header.referer.2">8.3</a>, <a href="#rfc.xref.header.referer.3">A</a></li>
     3681                  <li>Retry-After header field&nbsp;&nbsp;<a href="#rfc.xref.header.retry-after.1">3.3</a>, <a href="#rfc.xref.header.retry-after.2">4.3.5.4</a>, <a href="#rfc.iref.r.2"><b>7.8</b></a>, <a href="#rfc.xref.header.retry-after.3">8.3</a></li>
     3682                  <li><em>RFC1123</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC1123.1">6.1</a>, <a href="#rfc.xref.RFC1123.2">6.1</a>, <a href="#RFC1123"><b>11.2</b></a><ul>
     3683                        <li><em>Section 5.2.14</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC1123.2">6.1</a></li>
    37373684                     </ul>
    37383685                  </li>
    3739                   <li><em>RFC1945</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC1945.1">4.3.3</a>, <a href="#RFC1945"><b>12.2</b></a><ul>
     3686                  <li><em>RFC1945</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC1945.1">4.3.3</a>, <a href="#RFC1945"><b>11.2</b></a><ul>
    37403687                        <li><em>Section 9.3</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC1945.1">4.3.3</a></li>
    37413688                     </ul>
    37423689                  </li>
    3743                   <li><em>RFC2068</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2068.1">4.3.3</a>, <a href="#rfc.xref.RFC2068.2">4.3.3</a>, <a href="#RFC2068"><b>12.2</b></a><ul>
     3690                  <li><em>RFC2068</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2068.1">4.3.3</a>, <a href="#rfc.xref.RFC2068.2">4.3.3</a>, <a href="#RFC2068"><b>11.2</b></a><ul>
    37443691                        <li><em>Section 10.3</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2068.2">4.3.3</a></li>
    37453692                        <li><em>Section 10.3.4</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2068.1">4.3.3</a></li>
    37463693                     </ul>
    37473694                  </li>
    3748                   <li><em>RFC2119</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2119.1">1.1</a>, <a href="#RFC2119"><b>12.1</b></a></li>
    3749                   <li><em>RFC2616</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2616.1">1</a>, <a href="#rfc.xref.RFC2616.2">4.3.3</a>, <a href="#RFC2616"><b>12.2</b></a>, <a href="#rfc.xref.RFC2616.3">C.1</a><ul>
     3695                  <li><em>RFC2119</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2119.1">1.1</a>, <a href="#RFC2119"><b>11.1</b></a></li>
     3696                  <li><em>RFC2616</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2616.1">1</a>, <a href="#rfc.xref.RFC2616.2">4.3.3</a>, <a href="#RFC2616"><b>11.2</b></a>, <a href="#rfc.xref.RFC2616.3">C.1</a><ul>
    37503697                        <li><em>Section 10.3.8</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2616.2">4.3.3</a></li>
    37513698                     </ul>
    37523699                  </li>
    3753                   <li><em>RFC2817</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2817.1">9.2</a>, <a href="#RFC2817"><b>12.2</b></a>, <a href="#rfc.xref.RFC2817.2">A</a>, <a href="#rfc.xref.RFC2817.3">A</a>, <a href="#rfc.xref.RFC2817.4">A</a><ul>
    3754                         <li><em>Section 7.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2817.1">9.2</a>, <a href="#rfc.xref.RFC2817.2">A</a></li>
     3700                  <li><em>RFC2817</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2817.1">8.2</a>, <a href="#RFC2817"><b>11.2</b></a>, <a href="#rfc.xref.RFC2817.2">A</a>, <a href="#rfc.xref.RFC2817.3">A</a>, <a href="#rfc.xref.RFC2817.4">A</a><ul>
     3701                        <li><em>Section 7.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2817.1">8.2</a>, <a href="#rfc.xref.RFC2817.3">A</a></li>
    37553702                     </ul>
    37563703                  </li>
    3757                   <li><em>RFC3864</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3864.1">3.1</a>, <a href="#rfc.xref.RFC3864.2">3.1</a>, <a href="#rfc.xref.RFC3864.3">9.3</a>, <a href="#RFC3864"><b>12.2</b></a><ul>
     3704                  <li><em>RFC3864</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3864.1">3.1</a>, <a href="#rfc.xref.RFC3864.2">3.1</a>, <a href="#rfc.xref.RFC3864.3">8.3</a>, <a href="#RFC3864"><b>11.2</b></a><ul>
    37583705                        <li><em>Section 4.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3864.2">3.1</a></li>
    37593706                     </ul>
    37603707                  </li>
    3761                   <li><em>RFC3986</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3986.1">8.5</a>, <a href="#rfc.xref.RFC3986.2">8.5</a>, <a href="#RFC3986"><b>12.1</b></a><ul>
    3762                         <li><em>Section 4.2</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3986.1">8.5</a></li>
    3763                         <li><em>Section 5</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3986.2">8.5</a></li>
     3708                  <li><em>RFC3986</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3986.1">7.5</a>, <a href="#rfc.xref.RFC3986.2">7.5</a>, <a href="#RFC3986"><b>11.1</b></a><ul>
     3709                        <li><em>Section 4.2</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3986.1">7.5</a></li>
     3710                        <li><em>Section 5</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3986.2">7.5</a></li>
    37643711                     </ul>
    37653712                  </li>
    3766                   <li><em>RFC5226</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5226.1">2.2</a>, <a href="#rfc.xref.RFC5226.2">4.2</a>, <a href="#RFC5226"><b>12.2</b></a><ul>
     3713                  <li><em>RFC5226</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5226.1">2.2</a>, <a href="#rfc.xref.RFC5226.2">4.2</a>, <a href="#RFC5226"><b>11.2</b></a><ul>
    37673714                        <li><em>Section 4.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5226.1">2.2</a>, <a href="#rfc.xref.RFC5226.2">4.2</a></li>
    37683715                     </ul>
    37693716                  </li>
    3770                   <li><em>RFC5234</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5234.1">1.2</a>, <a href="#rfc.xref.RFC5234.2">1.2</a>, <a href="#rfc.xref.RFC5234.3">3.1</a>, <a href="#RFC5234"><b>12.1</b></a><ul>
     3717                  <li><em>RFC5234</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5234.1">1.2</a>, <a href="#rfc.xref.RFC5234.2">1.2</a>, <a href="#rfc.xref.RFC5234.3">3.1</a>, <a href="#RFC5234"><b>11.1</b></a><ul>
    37713718                        <li><em>Appendix B.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5234.2">1.2</a></li>
    37723719                     </ul>
    37733720                  </li>
    3774                   <li><em>RFC5322</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5322.1">7.1</a>, <a href="#rfc.xref.RFC5322.2">8.2</a>, <a href="#rfc.xref.RFC5322.3">8.4</a>, <a href="#rfc.xref.RFC5322.4">8.4</a>, <a href="#RFC5322"><b>12.2</b></a><ul>
    3775                         <li><em>Section 3.3</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5322.1">7.1</a></li>
    3776                         <li><em>Section 3.4</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5322.3">8.4</a>, <a href="#rfc.xref.RFC5322.4">8.4</a></li>
    3777                         <li><em>Section 3.6.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5322.2">8.2</a></li>
     3721                  <li><em>RFC5322</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5322.1">6.1</a>, <a href="#rfc.xref.RFC5322.2">7.2</a>, <a href="#rfc.xref.RFC5322.3">7.4</a>, <a href="#rfc.xref.RFC5322.4">7.4</a>, <a href="#RFC5322"><b>11.2</b></a><ul>
     3722                        <li><em>Section 3.3</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5322.1">6.1</a></li>
     3723                        <li><em>Section 3.4</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5322.3">7.4</a>, <a href="#rfc.xref.RFC5322.4">7.4</a></li>
     3724                        <li><em>Section 3.6.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5322.2">7.2</a></li>
    37783725                     </ul>
    37793726                  </li>
    3780                   <li><em>RFC5789</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5789.1">6.6</a>, <a href="#RFC5789"><b>12.2</b></a></li>
    3781                   <li><em>RFC5987</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5987.1">3.1</a>, <a href="#RFC5987"><b>12.2</b></a></li>
     3727                  <li><em>RFC5789</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5789.1">2.3.5</a>, <a href="#RFC5789"><b>11.2</b></a></li>
     3728                  <li><em>RFC5987</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5987.1">3.1</a>, <a href="#RFC5987"><b>11.2</b></a></li>
    37823729               </ul>
    37833730            </li>
    37843731            <li><a id="rfc.index.S" href="#rfc.index.S"><b>S</b></a><ul>
    3785                   <li>Safe Methods&nbsp;&nbsp;<a href="#rfc.iref.s.37"><b>6.1.1</b></a></li>
    3786                   <li>Server header field&nbsp;&nbsp;<a href="#rfc.xref.header.server.1">3.3</a>, <a href="#rfc.iref.s.38"><b>8.9</b></a>, <a href="#rfc.xref.header.server.2">9.3</a>, <a href="#rfc.xref.header.server.3">10.1</a>, <a href="#rfc.xref.header.server.4">A</a></li>
     3732                  <li>Safe Methods&nbsp;&nbsp;<a href="#rfc.iref.s.1"><b>2.1.1</b></a></li>
     3733                  <li>Server header field&nbsp;&nbsp;<a href="#rfc.xref.header.server.1">3.3</a>, <a href="#rfc.iref.s.38"><b>7.9</b></a>, <a href="#rfc.xref.header.server.2">8.3</a>, <a href="#rfc.xref.header.server.3">9.1</a>, <a href="#rfc.xref.header.server.4">A</a></li>
    37873734                  <li>Status Codes&nbsp;&nbsp;
    37883735                     <ul>
    3789                         <li>100 Continue&nbsp;&nbsp;<a href="#rfc.xref.status.100.1">4.1</a>, <a href="#rfc.iref.s.1"><b>4.3.1.1</b></a>, <a href="#rfc.xref.status.100.2">9.2</a></li>
    3790                         <li>101 Switching Protocols&nbsp;&nbsp;<a href="#rfc.xref.status.101.1">4.1</a>, <a href="#rfc.iref.s.2"><b>4.3.1.2</b></a>, <a href="#rfc.xref.status.101.2">9.2</a></li>
    3791                         <li>200 OK&nbsp;&nbsp;<a href="#rfc.xref.status.200.1">4.1</a>, <a href="#rfc.iref.s.3"><b>4.3.2.1</b></a>, <a href="#rfc.xref.status.200.2">9.2</a></li>
    3792                         <li>201 Created&nbsp;&nbsp;<a href="#rfc.xref.status.201.1">4.1</a>, <a href="#rfc.iref.s.4"><b>4.3.2.2</b></a>, <a href="#rfc.xref.status.201.2">9.2</a></li>
    3793                         <li>202 Accepted&nbsp;&nbsp;<a href="#rfc.xref.status.202.1">4.1</a>, <a href="#rfc.iref.s.5"><b>4.3.2.3</b></a>, <a href="#rfc.xref.status.202.2">9.2</a></li>
    3794                         <li>203 Non-Authoritative Information&nbsp;&nbsp;<a href="#rfc.xref.status.203.1">4.1</a>, <a href="#rfc.iref.s.6"><b>4.3.2.4</b></a>, <a href="#rfc.xref.status.203.2">9.2</a>, <a href="#rfc.xref.status.203.3">A</a></li>
    3795                         <li>204 No Content&nbsp;&nbsp;<a href="#rfc.xref.status.204.1">4.1</a>, <a href="#rfc.iref.s.7"><b>4.3.2.5</b></a>, <a href="#rfc.xref.status.204.2">9.2</a></li>
    3796                         <li>205 Reset Content&nbsp;&nbsp;<a href="#rfc.xref.status.205.1">4.1</a>, <a href="#rfc.iref.s.8"><b>4.3.2.6</b></a>, <a href="#rfc.xref.status.205.2">9.2</a></li>
    3797                         <li>300 Multiple Choices&nbsp;&nbsp;<a href="#rfc.xref.status.300.1">4.1</a>, <a href="#rfc.iref.s.9"><b>4.3.3.1</b></a>, <a href="#rfc.xref.status.300.2">9.2</a></li>
    3798                         <li>301 Moved Permanently&nbsp;&nbsp;<a href="#rfc.xref.status.301.1">4.1</a>, <a href="#rfc.iref.s.10"><b>4.3.3.2</b></a>, <a href="#rfc.xref.status.301.2">9.2</a>, <a href="#rfc.xref.status.301.3">A</a></li>
    3799                         <li>302 Found&nbsp;&nbsp;<a href="#rfc.xref.status.302.1">4.1</a>, <a href="#rfc.iref.s.11"><b>4.3.3.3</b></a>, <a href="#rfc.xref.status.302.2">9.2</a>, <a href="#rfc.xref.status.302.3">A</a></li>
    3800                         <li>303 See Other&nbsp;&nbsp;<a href="#rfc.xref.status.303.1">4.1</a>, <a href="#rfc.iref.s.12"><b>4.3.3.4</b></a>, <a href="#rfc.xref.status.303.2">9.2</a></li>
    3801                         <li>305 Use Proxy&nbsp;&nbsp;<a href="#rfc.xref.status.305.1">4.1</a>, <a href="#rfc.iref.s.13"><b>4.3.3.5</b></a>, <a href="#rfc.xref.status.305.2">9.2</a>, <a href="#rfc.xref.status.305.3">A</a></li>
    3802                         <li>306 (Unused)&nbsp;&nbsp;<a href="#rfc.iref.s.14"><b>4.3.3.6</b></a>, <a href="#rfc.xref.status.306.1">9.2</a></li>
    3803                         <li>307 Temporary Redirect&nbsp;&nbsp;<a href="#rfc.xref.status.307.1">4.1</a>, <a href="#rfc.iref.s.15"><b>4.3.3.7</b></a>, <a href="#rfc.xref.status.307.2">9.2</a>, <a href="#rfc.xref.status.307.3">A</a></li>
    3804                         <li>400 Bad Request&nbsp;&nbsp;<a href="#rfc.xref.status.400.1">4.1</a>, <a href="#rfc.iref.s.16"><b>4.3.4.1</b></a>, <a href="#rfc.xref.status.400.2">9.2</a></li>
    3805                         <li>402 Payment Required&nbsp;&nbsp;<a href="#rfc.xref.status.402.1">4.1</a>, <a href="#rfc.iref.s.17"><b>4.3.4.2</b></a>, <a href="#rfc.xref.status.402.2">9.2</a></li>
    3806                         <li>403 Forbidden&nbsp;&nbsp;<a href="#rfc.xref.status.403.1">4.1</a>, <a href="#rfc.iref.s.18"><b>4.3.4.3</b></a>, <a href="#rfc.xref.status.403.2">9.2</a></li>
    3807                         <li>404 Not Found&nbsp;&nbsp;<a href="#rfc.xref.status.404.1">4.1</a>, <a href="#rfc.iref.s.19"><b>4.3.4.4</b></a>, <a href="#rfc.xref.status.404.2">9.2</a></li>
    3808                         <li>405 Method Not Allowed&nbsp;&nbsp;<a href="#rfc.xref.status.405.1">4.1</a>, <a href="#rfc.iref.s.20"><b>4.3.4.5</b></a>, <a href="#rfc.xref.status.405.2">9.2</a></li>
    3809                         <li>406 Not Acceptable&nbsp;&nbsp;<a href="#rfc.xref.status.406.1">4.1</a>, <a href="#rfc.iref.s.21"><b>4.3.4.6</b></a>, <a href="#rfc.xref.status.406.2">9.2</a></li>
    3810                         <li>408 Request Timeout&nbsp;&nbsp;<a href="#rfc.xref.status.408.1">4.1</a>, <a href="#rfc.iref.s.22"><b>4.3.4.7</b></a>, <a href="#rfc.xref.status.408.2">9.2</a></li>
    3811                         <li>409 Conflict&nbsp;&nbsp;<a href="#rfc.xref.status.409.1">4.1</a>, <a href="#rfc.iref.s.23"><b>4.3.4.8</b></a>, <a href="#rfc.xref.status.409.2">9.2</a></li>
    3812                         <li>410 Gone&nbsp;&nbsp;<a href="#rfc.xref.status.410.1">4.1</a>, <a href="#rfc.iref.s.24"><b>4.3.4.9</b></a>, <a href="#rfc.xref.status.410.2">9.2</a></li>
    3813                         <li>411 Length Required&nbsp;&nbsp;<a href="#rfc.xref.status.411.1">4.1</a>, <a href="#rfc.iref.s.25"><b>4.3.4.10</b></a>, <a href="#rfc.xref.status.411.2">9.2</a></li>
    3814                         <li>413 Request Representation Too Large&nbsp;&nbsp;<a href="#rfc.xref.status.413.1">4.1</a>, <a href="#rfc.iref.s.26"><b>4.3.4.11</b></a>, <a href="#rfc.xref.status.413.2">9.2</a></li>
    3815                         <li>414 URI Too Long&nbsp;&nbsp;<a href="#rfc.xref.status.414.1">4.1</a>, <a href="#rfc.iref.s.27"><b>4.3.4.12</b></a>, <a href="#rfc.xref.status.414.2">9.2</a></li>
    3816                         <li>415 Unsupported Media Type&nbsp;&nbsp;<a href="#rfc.xref.status.415.1">4.1</a>, <a href="#rfc.iref.s.28"><b>4.3.4.13</b></a>, <a href="#rfc.xref.status.415.2">9.2</a></li>
    3817                         <li>417 Expectation Failed&nbsp;&nbsp;<a href="#rfc.xref.status.417.1">4.1</a>, <a href="#rfc.iref.s.29"><b>4.3.4.14</b></a>, <a href="#rfc.xref.status.417.2">9.2</a></li>
    3818                         <li>426 Upgrade Required&nbsp;&nbsp;<a href="#rfc.xref.status.426.1">4.1</a>, <a href="#rfc.iref.s.30"><b>4.3.4.15</b></a>, <a href="#rfc.xref.status.426.2">9.2</a>, <a href="#rfc.xref.status.426.3">A</a></li>
    3819                         <li>500 Internal Server Error&nbsp;&nbsp;<a href="#rfc.xref.status.500.1">4.1</a>, <a href="#rfc.iref.s.31"><b>4.3.5.1</b></a>, <a href="#rfc.xref.status.500.2">9.2</a></li>
    3820                         <li>501 Not Implemented&nbsp;&nbsp;<a href="#rfc.xref.status.501.1">4.1</a>, <a href="#rfc.iref.s.32"><b>4.3.5.2</b></a>, <a href="#rfc.xref.status.501.2">9.2</a></li>
    3821                         <li>502 Bad Gateway&nbsp;&nbsp;<a href="#rfc.xref.status.502.1">4.1</a>, <a href="#rfc.iref.s.33"><b>4.3.5.3</b></a>, <a href="#rfc.xref.status.502.2">9.2</a></li>
    3822                         <li>503 Service Unavailable&nbsp;&nbsp;<a href="#rfc.xref.status.503.1">4.1</a>, <a href="#rfc.iref.s.34"><b>4.3.5.4</b></a>, <a href="#rfc.xref.status.503.2">9.2</a></li>
    3823                         <li>504 Gateway Timeout&nbsp;&nbsp;<a href="#rfc.xref.status.504.1">4.1</a>, <a href="#rfc.iref.s.35"><b>4.3.5.5</b></a>, <a href="#rfc.xref.status.504.2">9.2</a></li>
    3824                         <li>505 HTTP Version Not Supported&nbsp;&nbsp;<a href="#rfc.xref.status.505.1">4.1</a>, <a href="#rfc.iref.s.36"><b>4.3.5.6</b></a>, <a href="#rfc.xref.status.505.2">9.2</a></li>
     3736                        <li>100 Continue&nbsp;&nbsp;<a href="#rfc.xref.status.100.1">4.1</a>, <a href="#rfc.iref.s.2"><b>4.3.1.1</b></a>, <a href="#rfc.xref.status.100.2">8.2</a></li>
     3737                        <li>101 Switching Protocols&nbsp;&nbsp;<a href="#rfc.xref.status.101.1">4.1</a>, <a href="#rfc.iref.s.3"><b>4.3.1.2</b></a>, <a href="#rfc.xref.status.101.2">8.2</a></li>
     3738                        <li>200 OK&nbsp;&nbsp;<a href="#rfc.xref.status.200.1">4.1</a>, <a href="#rfc.iref.s.4"><b>4.3.2.1</b></a>, <a href="#rfc.xref.status.200.2">8.2</a></li>
     3739                        <li>201 Created&nbsp;&nbsp;<a href="#rfc.xref.status.201.1">4.1</a>, <a href="#rfc.iref.s.5"><b>4.3.2.2</b></a>, <a href="#rfc.xref.status.201.2">8.2</a></li>
     3740                        <li>202 Accepted&nbsp;&nbsp;<a href="#rfc.xref.status.202.1">4.1</a>, <a href="#rfc.iref.s.6"><b>4.3.2.3</b></a>, <a href="#rfc.xref.status.202.2">8.2</a></li>
     3741                        <li>203 Non-Authoritative Information&nbsp;&nbsp;<a href="#rfc.xref.status.203.1">4.1</a>, <a href="#rfc.iref.s.7"><b>4.3.2.4</b></a>, <a href="#rfc.xref.status.203.2">8.2</a>, <a href="#rfc.xref.status.203.3">A</a></li>
     3742                        <li>204 No Content&nbsp;&nbsp;<a href="#rfc.xref.status.204.1">4.1</a>, <a href="#rfc.iref.s.8"><b>4.3.2.5</b></a>, <a href="#rfc.xref.status.204.2">8.2</a></li>
     3743                        <li>205 Reset Content&nbsp;&nbsp;<a href="#rfc.xref.status.205.1">4.1</a>, <a href="#rfc.iref.s.9"><b>4.3.2.6</b></a>, <a href="#rfc.xref.status.205.2">8.2</a></li>
     3744                        <li>300 Multiple Choices&nbsp;&nbsp;<a href="#rfc.xref.status.300.1">4.1</a>, <a href="#rfc.iref.s.10"><b>4.3.3.1</b></a>, <a href="#rfc.xref.status.300.2">8.2</a></li>
     3745                        <li>301 Moved Permanently&nbsp;&nbsp;<a href="#rfc.xref.status.301.1">4.1</a>, <a href="#rfc.iref.s.11"><b>4.3.3.2</b></a>, <a href="#rfc.xref.status.301.2">8.2</a>, <a href="#rfc.xref.status.301.3">A</a></li>
     3746                        <li>302 Found&nbsp;&nbsp;<a href="#rfc.xref.status.302.1">4.1</a>, <a href="#rfc.iref.s.12"><b>4.3.3.3</b></a>, <a href="#rfc.xref.status.302.2">8.2</a>, <a href="#rfc.xref.status.302.3">A</a></li>
     3747                        <li>303 See Other&nbsp;&nbsp;<a href="#rfc.xref.status.303.1">4.1</a>, <a href="#rfc.iref.s.13"><b>4.3.3.4</b></a>, <a href="#rfc.xref.status.303.2">8.2</a></li>
     3748                        <li>305 Use Proxy&nbsp;&nbsp;<a href="#rfc.xref.status.305.1">4.1</a>, <a href="#rfc.iref.s.14"><b>4.3.3.5</b></a>, <a href="#rfc.xref.status.305.2">8.2</a>, <a href="#rfc.xref.status.305.3">A</a></li>
     3749                        <li>306 (Unused)&nbsp;&nbsp;<a href="#rfc.iref.s.15"><b>4.3.3.6</b></a>, <a href="#rfc.xref.status.306.1">8.2</a></li>
     3750                        <li>307 Temporary Redirect&nbsp;&nbsp;<a href="#rfc.xref.status.307.1">4.1</a>, <a href="#rfc.iref.s.16"><b>4.3.3.7</b></a>, <a href="#rfc.xref.status.307.2">8.2</a>, <a href="#rfc.xref.status.307.3">A</a></li>
     3751                        <li>400 Bad Request&nbsp;&nbsp;<a href="#rfc.xref.status.400.1">4.1</a>, <a href="#rfc.iref.s.17"><b>4.3.4.1</b></a>, <a href="#rfc.xref.status.400.2">8.2</a></li>
     3752                        <li>402 Payment Required&nbsp;&nbsp;<a href="#rfc.xref.status.402.1">4.1</a>, <a href="#rfc.iref.s.18"><b>4.3.4.2</b></a>, <a href="#rfc.xref.status.402.2">8.2</a></li>
     3753                        <li>403 Forbidden&nbsp;&nbsp;<a href="#rfc.xref.status.403.1">4.1</a>, <a href="#rfc.iref.s.19"><b>4.3.4.3</b></a>, <a href="#rfc.xref.status.403.2">8.2</a></li>
     3754                        <li>404 Not Found&nbsp;&nbsp;<a href="#rfc.xref.status.404.1">4.1</a>, <a href="#rfc.iref.s.20"><b>4.3.4.4</b></a>, <a href="#rfc.xref.status.404.2">8.2</a></li>
     3755                        <li>405 Method Not Allowed&nbsp;&nbsp;<a href="#rfc.xref.status.405.1">4.1</a>, <a href="#rfc.iref.s.21"><b>4.3.4.5</b></a>, <a href="#rfc.xref.status.405.2">8.2</a></li>
     3756                        <li>406 Not Acceptable&nbsp;&nbsp;<a href="#rfc.xref.status.406.1">4.1</a>, <a href="#rfc.iref.s.22"><b>4.3.4.6</b></a>, <a href="#rfc.xref.status.406.2">8.2</a></li>
     3757                        <li>408 Request Timeout&nbsp;&nbsp;<a href="#rfc.xref.status.408.1">4.1</a>, <a href="#rfc.iref.s.23"><b>4.3.4.7</b></a>, <a href="#rfc.xref.status.408.2">8.2</a></li>
     3758                        <li>409 Conflict&nbsp;&nbsp;<a href="#rfc.xref.status.409.1">4.1</a>, <a href="#rfc.iref.s.24"><b>4.3.4.8</b></a>, <a href="#rfc.xref.status.409.2">8.2</a></li>
     3759                        <li>410 Gone&nbsp;&nbsp;<a href="#rfc.xref.status.410.1">4.1</a>, <a href="#rfc.iref.s.25"><b>4.3.4.9</b></a>, <a href="#rfc.xref.status.410.2">8.2</a></li>
     3760                        <li>411 Length Required&nbsp;&nbsp;<a href="#rfc.xref.status.411.1">4.1</a>, <a href="#rfc.iref.s.26"><b>4.3.4.10</b></a>, <a href="#rfc.xref.status.411.2">8.2</a></li>
     3761                        <li>413 Request Representation Too Large&nbsp;&nbsp;<a href="#rfc.xref.status.413.1">4.1</a>, <a href="#rfc.iref.s.27"><b>4.3.4.11</b></a>, <a href="#rfc.xref.status.413.2">8.2</a></li>
     3762                        <li>414 URI Too Long&nbsp;&nbsp;<a href="#rfc.xref.status.414.1">4.1</a>, <a href="#rfc.iref.s.28"><b>4.3.4.12</b></a>, <a href="#rfc.xref.status.414.2">8.2</a></li>
     3763                        <li>415 Unsupported Media Type&nbsp;&nbsp;<a href="#rfc.xref.status.415.1">4.1</a>, <a href="#rfc.iref.s.29"><b>4.3.4.13</b></a>, <a href="#rfc.xref.status.415.2">8.2</a></li>
     3764                        <li>417 Expectation Failed&nbsp;&nbsp;<a href="#rfc.xref.status.417.1">4.1</a>, <a href="#rfc.iref.s.30"><b>4.3.4.14</b></a>, <a href="#rfc.xref.status.417.2">8.2</a></li>
     3765                        <li>426 Upgrade Required&nbsp;&nbsp;<a href="#rfc.xref.status.426.1">4.1</a>, <a href="#rfc.iref.s.31"><b>4.3.4.15</b></a>, <a href="#rfc.xref.status.426.2">8.2</a>, <a href="#rfc.xref.status.426.3">A</a></li>
     3766                        <li>500 Internal Server Error&nbsp;&nbsp;<a href="#rfc.xref.status.500.1">4.1</a>, <a href="#rfc.iref.s.32"><b>4.3.5.1</b></a>, <a href="#rfc.xref.status.500.2">8.2</a></li>
     3767                        <li>501 Not Implemented&nbsp;&nbsp;<a href="#rfc.xref.status.501.1">4.1</a>, <a href="#rfc.iref.s.33"><b>4.3.5.2</b></a>, <a href="#rfc.xref.status.501.2">8.2</a></li>
     3768                        <li>502 Bad Gateway&nbsp;&nbsp;<a href="#rfc.xref.status.502.1">4.1</a>, <a href="#rfc.iref.s.34"><b>4.3.5.3</b></a>, <a href="#rfc.xref.status.502.2">8.2</a></li>
     3769                        <li>503 Service Unavailable&nbsp;&nbsp;<a href="#rfc.xref.status.503.1">4.1</a>, <a href="#rfc.iref.s.35"><b>4.3.5.4</b></a>, <a href="#rfc.xref.status.503.2">8.2</a></li>
     3770                        <li>504 Gateway Timeout&nbsp;&nbsp;<a href="#rfc.xref.status.504.1">4.1</a>, <a href="#rfc.iref.s.36"><b>4.3.5.5</b></a>, <a href="#rfc.xref.status.504.2">8.2</a></li>
     3771                        <li>505 HTTP Version Not Supported&nbsp;&nbsp;<a href="#rfc.xref.status.505.1">4.1</a>, <a href="#rfc.iref.s.37"><b>4.3.5.6</b></a>, <a href="#rfc.xref.status.505.2">8.2</a></li>
    38253772                     </ul>
    38263773                  </li>
    … …  
    38283775            </li>
    38293776            <li><a id="rfc.index.T" href="#rfc.index.T"><b>T</b></a><ul>
    3830                   <li>TRACE method&nbsp;&nbsp;<a href="#rfc.xref.TRACE.1">2.1</a>, <a href="#rfc.iref.t.1"><b>6.8</b></a>, <a href="#rfc.xref.TRACE.2">8.6</a>, <a href="#rfc.xref.TRACE.3">9.1</a>, <a href="#rfc.xref.TRACE.4">10.1</a></li>
     3777                  <li>TRACE method&nbsp;&nbsp;<a href="#rfc.iref.t.1"><b>2.3.7</b></a>, <a href="#rfc.xref.TRACE.1">7.6</a>, <a href="#rfc.xref.TRACE.2">8.1</a>, <a href="#rfc.xref.TRACE.3">9.1</a></li>
    38313778               </ul>
    38323779            </li>
    38333780            <li><a id="rfc.index.U" href="#rfc.index.U"><b>U</b></a><ul>
    3834                   <li>User-Agent header field&nbsp;&nbsp;<a href="#rfc.xref.header.user-agent.1">3.2</a>, <a href="#rfc.iref.u.1"><b>8.10</b></a>, <a href="#rfc.xref.header.user-agent.2">9.3</a>, <a href="#rfc.xref.header.user-agent.3">10.1</a></li>
     3781                  <li>User-Agent header field&nbsp;&nbsp;<a href="#rfc.xref.header.user-agent.1">3.2</a>, <a href="#rfc.iref.u.1"><b>7.10</b></a>, <a href="#rfc.xref.header.user-agent.2">8.3</a>, <a href="#rfc.xref.header.user-agent.3">9.1</a></li>
    38353782               </ul>
    38363783            </li>

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

    r1618 r1619  
    311311</section>
    312312
    313 <section title="Method" anchor="method">
     313<section title="Methods" anchor="methods">
    314314  <x:anchor-alias value="method"/>
    315   <x:anchor-alias value="extension-method"/>
    316315<t>
    317316   The method token indicates the request method to be performed on the target
    … …  
    336335</t>
    337336
    338 <section title="Overview of Methods" anchor="overview.of.methods">
    339 <t>
    340   The methods listed below are defined in <xref target="method.definitions"/>.
    341 </t>
    342 <texttable align="left">
    343   <ttcol>Method Name</ttcol><ttcol>Defined in...</ttcol>
    344  
    345   <c>OPTIONS</c> <c><xref target="OPTIONS"/></c>
    346   <c>GET</c> <c><xref target="GET"/></c>
    347   <c>HEAD</c> <c><xref target="HEAD"/></c>
    348   <c>POST</c> <c><xref target="POST"/></c>
    349   <c>PUT</c> <c><xref target="PUT"/></c>
    350   <c>DELETE</c> <c><xref target="DELETE"/></c>
    351   <c>TRACE</c> <c><xref target="TRACE"/></c>
    352   <c>CONNECT</c> <c><xref target="CONNECT"/></c>
    353 </texttable>
    354 <t>
    355   Note that this list is not exhaustive &mdash; it does not include request methods defined
    356   in other specifications.
    357 </t>
     337<section title="Safe and Idempotent Methods" anchor="safe.and.idempotent">
     338
     339<section title="Safe Methods" anchor="safe.methods">
     340<iref item="Safe Methods" primary="true"/>
     341<t>
     342   Implementors need to be aware that the software represents the user in
     343   their interactions over the Internet, and need to allow
     344   the user to be aware of any actions they take which might have an
     345   unexpected significance to themselves or others.
     346</t>
     347<t>
     348   In particular, the convention has been established that the GET, HEAD,
     349   OPTIONS, and TRACE request methods &SHOULD-NOT; have the significance
     350   of taking an action other than retrieval. These request methods ought
     351   to be considered "<x:dfn anchor="safe">safe</x:dfn>".
     352   This allows user agents to represent other methods, such as POST, PUT
     353   and DELETE, in a special way, so that the user is made aware of the
     354   fact that a possibly unsafe action is being requested.
     355</t>
     356<t>
     357   Naturally, it is not possible to ensure that the server does not
     358   generate side-effects as a result of performing a GET request; in
     359   fact, some dynamic resources consider that a feature. The important
     360   distinction here is that the user did not request the side-effects,
     361   so therefore cannot be held accountable for them.
     362</t>
     363</section>
     364
     365<section title="Idempotent Methods" anchor="idempotent.methods">
     366<iref item="Idempotent Methods" primary="true"/>
     367<t>
     368   Request methods can also have the property of "idempotence" in that,
     369   aside from error or expiration issues, the intended effect of multiple
     370   identical requests is the same as for a single request.
     371   PUT, DELETE, and all safe request methods are idempotent.
     372   It is important to note that idempotence refers only to changes
     373   requested by the client: a server is free to change its state due
     374   to multiple requests for the purpose of tracking those requests,
     375   versioning of results, etc.
     376</t>
     377</section>
    358378</section>
    359379
    … …  
    366386  Registrations &MUST; include the following fields:
    367387  <list style="symbols">
    368     <t>Method Name (see <xref target="method"/>)</t>
     388    <t>Method Name (see <xref target="methods"/>)</t>
    369389    <t>Safe ("yes" or "no", see <xref target="safe.methods"/>)</t>
    370390    <t>Pointer to specification text</t>
    … …  
    409429</t>
    410430</section>
    411 
    412 </section>
     431</section>
     432
     433<section title="Method Definitions" anchor="method.definitions">
     434
     435<section title="OPTIONS" anchor="OPTIONS">
     436  <rdf:Description>
     437    <safe xmlns="urn:ietf:id:draft-ietf-httpbis-p2-semantics#">yes</safe>
     438  </rdf:Description>
     439  <iref primary="true" item="OPTIONS method" x:for-anchor=""/>
     440  <iref primary="true" item="Methods" subitem="OPTIONS" x:for-anchor=""/>
     441<t>
     442   The OPTIONS method requests information about the
     443   communication options available on the request/response chain
     444   identified by the effective request URI. This method allows a client to
     445   determine the options and/or requirements associated with a resource,
     446   or the capabilities of a server, without implying a resource action
     447   or initiating a resource retrieval.
     448</t>
     449<t>
     450   Responses to the OPTIONS method are not cacheable.
     451</t>
     452<t>
     453   If the OPTIONS request includes a message body (as indicated by the
     454   presence of Content-Length or Transfer-Encoding), then the media type
     455   &MUST; be indicated by a Content-Type field. Although this
     456   specification does not define any use for such a body, future
     457   extensions to HTTP might use the OPTIONS body to make more detailed
     458   queries on the server.
     459</t>
     460<t>
     461   If the request-target (&request-target;) is an asterisk ("*"),
     462   the OPTIONS request is
     463   intended to apply to the server in general rather than to a specific
     464   resource. Since a server's communication options typically depend on
     465   the resource, the "*" request is only useful as a "ping" or "no-op"
     466   type of method; it does nothing beyond allowing the client to test
     467   the capabilities of the server. For example, this can be used to test
     468   a proxy for HTTP/1.1 conformance (or lack thereof).
     469</t>
     470<t>
     471   If the request-target is not an asterisk, the OPTIONS request applies
     472   only to the options that are available when communicating with that
     473   resource.
     474</t>
     475<t>
     476   A 200 response &SHOULD; include any header fields that indicate
     477   optional features implemented by the server and applicable to that
     478   resource (e.g., Allow), possibly including extensions not defined by
     479   this specification. The response body, if any, &SHOULD; also include
     480   information about the communication options. The format for such a
     481   body is not defined by this specification, but might be defined by
     482   future extensions to HTTP. Content negotiation &MAY; be used to select
     483   the appropriate response format. If no response body is included, the
     484   response &MUST; include a Content-Length field with a field-value of
     485   "0".
     486</t>
     487<t>
     488   The Max-Forwards header field &MAY; be used to target a
     489   specific proxy in the request chain (see <xref target="header.max-forwards"/>).
     490   If no Max-Forwards field is present in the request, then the forwarded
     491   request &MUST-NOT; include a Max-Forwards field.
     492</t>
     493</section>
     494
     495<section title="GET" anchor="GET">
     496  <rdf:Description>
     497    <safe xmlns="urn:ietf:id:draft-ietf-httpbis-p2-semantics#">yes</safe>
     498  </rdf:Description>
     499  <iref primary="true" item="GET method" x:for-anchor=""/>
     500  <iref primary="true" item="Methods" subitem="GET" x:for-anchor=""/>
     501<t>
     502   The GET method requests transfer of a current representation of
     503   the target resource.
     504</t>
     505<t>   
     506   If the target resource is a data-producing process, it is the
     507   produced data which shall be returned as the representation in the response and not
     508   the source text of the process, unless that text happens to be the output of
     509   the process.
     510</t>
     511<t>
     512   The semantics of the GET method change to a "conditional GET" if the
     513   request message includes an If-Modified-Since, If-Unmodified-Since,
     514   If-Match, If-None-Match, or If-Range header field. A conditional GET
     515   requests that the representation be transferred only under the
     516   circumstances described by the conditional header field(s). The
     517   conditional GET request is intended to reduce unnecessary network
     518   usage by allowing cached representations to be refreshed without requiring
     519   multiple requests or transferring data already held by the client.
     520</t>
     521<t>
     522   The semantics of the GET method change to a "partial GET" if the
     523   request message includes a Range header field. A partial GET requests
     524   that only part of the representation be transferred, as described in &header-range;.
     525   The partial GET request is intended to reduce unnecessary
     526   network usage by allowing partially-retrieved representations to be
     527   completed without transferring data already held by the client.
     528</t>
     529<t>
     530   Bodies on GET requests have no defined semantics. Note that sending a body
     531   on a GET request might cause some existing implementations to reject the
     532   request.
     533</t>
     534<t>
     535   The response to a GET request is cacheable and &MAY; be used to satisfy
     536   subsequent GET and HEAD requests (see &caching;).
     537</t>
     538<t>
     539   See <xref target="encoding.sensitive.information.in.uris"/> for security considerations when used for forms.
     540</t>
     541</section>
     542
     543<section title="HEAD" anchor="HEAD">
     544  <rdf:Description>
     545    <safe xmlns="urn:ietf:id:draft-ietf-httpbis-p2-semantics#">yes</safe>
     546  </rdf:Description>
     547  <iref primary="true" item="HEAD method" x:for-anchor=""/>
     548  <iref primary="true" item="Methods" subitem="HEAD" x:for-anchor=""/>
     549<t>
     550   The HEAD method is identical to GET except that the server &MUST-NOT;
     551   return a message body in the response. The metadata contained
     552   in the HTTP header fields in response to a HEAD request &SHOULD; be identical
     553   to the information sent in response to a GET request. This method can
     554   be used for obtaining metadata about the representation implied by the
     555   request without transferring the representation body. This method is
     556   often used for testing hypertext links for validity, accessibility,
     557   and recent modification.
     558</t>
     559<t>
     560   The response to a HEAD request is cacheable and &MAY; be used to satisfy
     561   a subsequent HEAD request. It also has potential side effects on
     562   previously stored responses to GET; see &p6-head;.
     563</t>
     564<t>
     565   Bodies on HEAD requests have no defined semantics. Note that sending a body
     566   on a HEAD request might cause some existing implementations to reject the
     567   request.
     568</t>
     569</section>
     570
     571<section title="POST" anchor="POST">
     572  <iref primary="true" item="POST method" x:for-anchor=""/>
     573  <iref primary="true" item="Methods" subitem="POST" x:for-anchor=""/>
     574<t>
     575   The POST method requests that the origin server accept the
     576   representation enclosed in the request as data to be processed by the
     577   target resource. POST is designed to allow a uniform method to cover the
     578   following functions:
     579  <list style="symbols">
     580    <t>
     581      Annotation of existing resources;
     582    </t>
     583    <t>
     584        Posting a message to a bulletin board, newsgroup, mailing list,
     585        or similar group of articles;
     586    </t>
     587    <t>
     588        Providing a block of data, such as the result of submitting a
     589        form, to a data-handling process;
     590    </t>
     591    <t>
     592        Extending a database through an append operation.
     593    </t>
     594  </list>
     595</t>
     596<t>
     597   The actual function performed by the POST method is determined by the
     598   server and is usually dependent on the effective request URI.
     599</t>
     600<t>
     601   The action performed by the POST method might not result in a
     602   resource that can be identified by a URI. In this case, either 200
     603   (OK) or 204 (No Content) is the appropriate response status code,
     604   depending on whether or not the response includes a representation that
     605   describes the result.
     606</t>
     607<t>
     608   If a resource has been created on the origin server, the response
     609   &SHOULD; be 201 (Created) and contain a representation which describes the
     610   status of the request and refers to the new resource, and a Location
     611   header field (see <xref target="header.location"/>).
     612</t>
     613<t>
     614   Responses to POST requests are only cacheable when they
     615   include explicit freshness information (see &p6-explicit;). A
     616   cached POST response with a Content-Location header field
     617   (see &header-content-location;) whose value is the effective
     618   Request URI &MAY; be used to satisfy subsequent GET and HEAD requests.
     619</t>
     620<t>
     621   Note that POST caching is not widely implemented.
     622   However, the 303 (See Other) response can be used to direct the
     623   user agent to retrieve a cacheable representation of the resource.
     624</t>
     625</section>
     626
     627<section title="PUT" anchor="PUT">
     628  <iref primary="true" item="PUT method" x:for-anchor=""/>
     629  <iref primary="true" item="Methods" subitem="PUT" x:for-anchor=""/>
     630<t>
     631   The PUT method requests that the state of the target resource
     632   be created or replaced with the state defined by the representation
     633   enclosed in the request message payload.  A successful PUT of a given
     634   representation would suggest that a subsequent GET on that same target
     635   resource will result in an equivalent representation being returned in
     636   a 200 (OK) response.  However, there is no guarantee that such a state
     637   change will be observable, since the target resource might be acted
     638   upon by other user agents in parallel, or might be subject to dynamic
     639   processing by the origin server, before any subsequent GET is received.
     640   A successful response only implies that the user agent's intent was
     641   achieved at the time of its processing by the origin server.
     642</t>
     643<t>   
     644   If the target resource does not have a current representation and
     645   the PUT successfully creates one, then the origin server &MUST; inform
     646   the user agent by sending a 201 (Created) response.  If the target
     647   resource does have a current representation and that representation is
     648   successfully modified in accordance with the state of the enclosed
     649   representation, then either a 200 (OK) or 204 (No Content) response
     650   &SHOULD; be sent to indicate successful completion of the request.
     651</t>
     652<t>
     653   Unrecognized header fields &SHOULD; be ignored (i.e., not saved
     654   as part of the resource state).
     655</t>
     656<t>
     657   An origin server &SHOULD; verify that the PUT representation is
     658   consistent with any constraints which the server has for the target
     659   resource that cannot or will not be changed by the PUT.  This is
     660   particularly important when the origin server uses internal
     661   configuration information related to the URI in order to set the
     662   values for representation metadata on GET responses.  When a PUT
     663   representation is inconsistent with the target resource, the origin
     664   server &SHOULD; either make them consistent, by transforming the
     665   representation or changing the resource configuration, or respond
     666   with an appropriate error message containing sufficient information
     667   to explain why the representation is unsuitable.  The 409 (Conflict)
     668   or 415 (Unsupported Media Type) status codes are suggested, with the
     669   latter being specific to constraints on Content-Type values.
     670</t>
     671<t>
     672   For example, if the target resource is configured to always have a
     673   Content-Type of "text/html" and the representation being PUT has a
     674   Content-Type of "image/jpeg", then the origin server &SHOULD; do one of:
     675   (a) reconfigure the target resource to reflect the new media type;
     676   (b) transform the PUT representation to a format consistent with that
     677   of the resource before saving it as the new resource state; or,
     678   (c) reject the request with a 415 response indicating that the target
     679   resource is limited to "text/html", perhaps including a link to a
     680   different resource that would be a suitable target for the new
     681   representation.
     682</t>
     683<t>
     684   HTTP does not define exactly how a PUT method affects the state
     685   of an origin server beyond what can be expressed by the intent of
     686   the user agent request and the semantics of the origin server response.
     687   It does not define what a resource might be, in any sense of that
     688   word, beyond the interface provided via HTTP.  It does not define
     689   how resource state is "stored", nor how such storage might change
     690   as a result of a change in resource state, nor how the origin server
     691   translates resource state into representations.  Generally speaking,
     692   all implementation details behind the resource interface are
     693   intentionally hidden by the server.
     694</t>
     695<t>
     696   The fundamental difference between the POST and PUT methods is
     697   highlighted by the different intent for the target resource.
     698   The target resource in a POST request is intended to handle the
     699   enclosed representation as a data-accepting process, such as for
     700   a gateway to some other protocol or a document that accepts annotations.
     701   In contrast, the target resource in a PUT request is intended to
     702   take the enclosed representation as a new or replacement value.
     703   Hence, the intent of PUT is idempotent and visible to intermediaries,
     704   even though the exact effect is only known by the origin server.
     705</t>
     706<t>
     707   Proper interpretation of a PUT request presumes that the user agent
     708   knows what target resource is desired.  A service that is intended
     709   to select a proper URI on behalf of the client, after receiving
     710   a state-changing request, &SHOULD; be implemented using the POST
     711   method rather than PUT.  If the origin server will not make the
     712   requested PUT state change to the target resource and instead
     713   wishes to have it applied to a different resource, such as when the
     714   resource has been moved to a different URI, then the origin server
     715   &MUST; send a 301 (Moved Permanently) response; the user agent &MAY;
     716   then make its own decision regarding whether or not to redirect the
     717   request.
     718</t>
     719<t>
     720   A PUT request applied to the target resource &MAY; have side-effects
     721   on other resources.  For example, an article might have a URI for
     722   identifying "the current version" (a resource) which is separate
     723   from the URIs identifying each particular version (different
     724   resources that at one point shared the same state as the current version
     725   resource).  A successful PUT request on "the current version" URI might
     726   therefore create a new version resource in addition to changing the
     727   state of the target resource, and might also cause links to be added
     728   between the related resources.
     729</t>
     730<t>
     731   An origin server &SHOULD; reject any PUT request that contains a
     732   Content-Range header field, since it might be misinterpreted as
     733   partial content (or might be partial content that is being mistakenly
     734   PUT as a full representation).  Partial content updates are
     735   possible by targeting a separately identified resource with state
     736   that overlaps a portion of the larger resource, or by using a
     737   different method that has been specifically defined for partial
     738   updates (for example, the PATCH method defined in
     739   <xref target="RFC5789"/>).
     740</t>
     741<t>
     742   Responses to the PUT method are not cacheable. If a PUT request passes
     743   through a cache that has one or more stored responses for the effective
     744   request URI, those stored responses will be invalidated (see
     745   &p6-invalid;).
     746</t>
     747</section>
     748
     749<section title="DELETE" anchor="DELETE">
     750  <iref primary="true" item="DELETE method" x:for-anchor=""/>
     751  <iref primary="true" item="Methods" subitem="DELETE" x:for-anchor=""/>
     752<t>
     753   The DELETE method requests that the origin server delete the target
     754   resource. This method &MAY; be overridden by
     755   human intervention (or other means) on the origin server. The client cannot
     756   be guaranteed that the operation has been carried out, even if the
     757   status code returned from the origin server indicates that the action
     758   has been completed successfully. However, the server &SHOULD-NOT;
     759   indicate success unless, at the time the response is given, it
     760   intends to delete the resource or move it to an inaccessible
     761   location.
     762</t>
     763<t>
     764   A successful response &SHOULD; be 200 (OK) if the response includes an
     765   representation describing the status, 202 (Accepted) if the action has not
     766   yet been enacted, or 204 (No Content) if the action has been enacted
     767   but the response does not include a representation.
     768</t>
     769<t>
     770   Bodies on DELETE requests have no defined semantics. Note that sending a body
     771   on a DELETE request might cause some existing implementations to reject the
     772   request.
     773</t>
     774<t>
     775   Responses to the DELETE method are not cacheable. If a DELETE request
     776   passes through a cache that has one or more stored responses for the
     777   effective request URI, those stored responses will be invalidated (see
     778   &p6-invalid;).
     779</t>
     780</section>
     781
     782<section title="TRACE" anchor="TRACE">
     783  <rdf:Description>
     784    <safe xmlns="urn:ietf:id:draft-ietf-httpbis-p2-semantics#">yes</safe>
     785  </rdf:Description>
     786  <iref primary="true" item="TRACE method" x:for-anchor=""/>
     787  <iref primary="true" item="Methods" subitem="TRACE" x:for-anchor=""/>
     788<t>
     789   The TRACE method requests a remote, application-layer loop-back
     790   of the request message. The final recipient of the request
     791   &SHOULD; reflect the message received back to the client as the
     792   message body of a 200 (OK) response. The final recipient is either the
     793   origin server or the first proxy to receive a Max-Forwards
     794   value of zero (0) in the request (see <xref target="header.max-forwards"/>).
     795   A TRACE request &MUST-NOT; include a message body.
     796</t>
     797<t>
     798   TRACE allows the client to see what is being received at the other
     799   end of the request chain and use that data for testing or diagnostic
     800   information. The value of the Via header field (&header-via;) is of
     801   particular interest, since it acts as a trace of the request chain.
     802   Use of the Max-Forwards header field allows the client to limit the
     803   length of the request chain, which is useful for testing a chain of
     804   proxies forwarding messages in an infinite loop.
     805</t>
     806<t>
     807   If the request is valid, the response &SHOULD; have a Content-Type of
     808   "message/http" (see &media-type-message-http;) and contain a message body
     809   that encloses a copy of the entire request message.
     810   Responses to the TRACE method are not cacheable.
     811</t>
     812</section>
     813
     814<section title="CONNECT" anchor="CONNECT">
     815  <iref primary="true" item="CONNECT method" x:for-anchor=""/>
     816  <iref primary="true" item="Methods" subitem="CONNECT" x:for-anchor=""/>
     817<t>
     818   The CONNECT method requests that the proxy establish a tunnel
     819   to the request-target and, if successful, thereafter restrict its behavior
     820   to blind forwarding of packets until the connection is closed.
     821</t>
     822<t>
     823   When using CONNECT, the request-target &MUST; use the authority form
     824   (&request-target;); i.e., the request-target consists of only the
     825   host name and port number of the tunnel destination, separated by a colon.
     826   For example,
     827</t>
     828<figure><artwork type="message/http; msgtype=&#34;request&#34;" x:indent-with="  ">
     829CONNECT server.example.com:80 HTTP/1.1
     830Host: server.example.com:80
     831
     832</artwork></figure>
     833<t>
     834   Any successful (2xx) response to a CONNECT request indicates that the
     835   proxy has established a connection to the requested host and port,
     836   and has switched to tunneling the current connection to that server
     837   connection.
     838   The tunneled data from the server begins immediately after the blank line
     839   that concludes the successful response's header block.
     840   A server &SHOULD-NOT; send any Transfer-Encoding or Content-Length
     841   header fields in a successful response.
     842   A client &MUST; ignore any Content-Length or Transfer-Encoding header
     843   fields received in a successful response.
     844</t>
     845<t>
     846   Any response other than a successful response indicates that the tunnel
     847   has not yet been formed and that the connection remains governed by HTTP.
     848</t>
     849<t>
     850   Proxy authentication might be used to establish the
     851   authority to create a tunnel:
     852</t>
     853<figure><artwork type="message/http; msgtype=&#34;request&#34;" x:indent-with="  ">
     854CONNECT server.example.com:80 HTTP/1.1
     855Host: server.example.com:80
     856Proxy-Authorization: basic aGVsbG86d29ybGQ=
     857
     858</artwork></figure>
     859<t>
     860   A message body on a CONNECT request has no defined semantics. Sending a
     861   body on a CONNECT request might cause existing implementations to reject
     862   the request.
     863</t>
     864<t>
     865   Similar to a pipelined HTTP/1.1 request, data to be tunneled from client
     866   to server &MAY; be sent immediately after the request (before a response
     867   is received). The usual caveats also apply:
     868   data may be discarded if the eventual response is negative, and the
     869   connection may be reset with no response if more than one TCP segment
     870   is outstanding.
     871</t>
     872<t>
     873   It may be the case that the proxy itself can only reach the requested
     874   origin server through another proxy.  In this case, the first proxy
     875   &SHOULD; make a CONNECT request of that next proxy, requesting a tunnel
     876   to the authority.  A proxy &MUST-NOT; respond with any 2xx status code
     877   unless it has either a direct or tunnel connection established to the
     878   authority.
     879</t>
     880<t>
     881   If at any point either one of the peers gets disconnected, any
     882   outstanding data that came from that peer will be passed to the other
     883   one, and after that also the other connection will be terminated by
     884   the proxy. If there is outstanding data to that peer undelivered,
     885   that data will be discarded.
     886</t>
     887<t>
     888   An origin server which receives a CONNECT request for itself &MAY;
     889   respond with a 2xx status code to indicate that a connection is
     890   established.  However, most origin servers do not implement CONNECT.
     891</t>
     892</section>
     893</section>
     894
    413895</section>
    414896
    … …  
    16362118
    16372119
    1638 <section title="Method Definitions" anchor="method.definitions">
    1639 <t>
    1640    The set of common request methods for HTTP/1.1 is defined below. Although
    1641    this set can be expanded, additional methods cannot be assumed to
    1642    share the same semantics for separately extended clients and servers.
    1643 </t>
    1644 
    1645 <section title="Safe and Idempotent Methods" anchor="safe.and.idempotent">
    1646 
    1647 <section title="Safe Methods" anchor="safe.methods">
    1648 <iref item="Safe Methods" primary="true"/>
    1649 <t>
    1650    Implementors need to be aware that the software represents the user in
    1651    their interactions over the Internet, and need to allow
    1652    the user to be aware of any actions they take which might have an
    1653    unexpected significance to themselves or others.
    1654 </t>
    1655 <t>
    1656    In particular, the convention has been established that the GET, HEAD,
    1657    OPTIONS, and TRACE request methods &SHOULD-NOT; have the significance
    1658    of taking an action other than retrieval. These request methods ought
    1659    to be considered "<x:dfn anchor="safe">safe</x:dfn>".
    1660    This allows user agents to represent other methods, such as POST, PUT
    1661    and DELETE, in a special way, so that the user is made aware of the
    1662    fact that a possibly unsafe action is being requested.
    1663 </t>
    1664 <t>
    1665    Naturally, it is not possible to ensure that the server does not
    1666    generate side-effects as a result of performing a GET request; in
    1667    fact, some dynamic resources consider that a feature. The important
    1668    distinction here is that the user did not request the side-effects,
    1669    so therefore cannot be held accountable for them.
    1670 </t>
    1671 </section>
    1672 
    1673 <section title="Idempotent Methods" anchor="idempotent.methods">
    1674 <iref item="Idempotent Methods" primary="true"/>
    1675 <t>
    1676    Request methods can also have the property of "idempotence" in that,
    1677    aside from error or expiration issues, the intended effect of multiple
    1678    identical requests is the same as for a single request.
    1679    PUT, DELETE, and all safe request methods are idempotent.
    1680    It is important to note that idempotence refers only to changes
    1681    requested by the client: a server is free to change its state due
    1682    to multiple requests for the purpose of tracking those requests,
    1683    versioning of results, etc.
    1684 </t>
    1685 </section>
    1686 </section>
    1687 
    1688 <section title="OPTIONS" anchor="OPTIONS">
    1689   <rdf:Description>
    1690     <safe xmlns="urn:ietf:id:draft-ietf-httpbis-p2-semantics#">yes</safe>
    1691   </rdf:Description>
    1692   <iref primary="true" item="OPTIONS method" x:for-anchor=""/>
    1693   <iref primary="true" item="Methods" subitem="OPTIONS" x:for-anchor=""/>
    1694 <t>
    1695    The OPTIONS method requests information about the
    1696    communication options available on the request/response chain
    1697    identified by the effective request URI. This method allows a client to
    1698    determine the options and/or requirements associated with a resource,
    1699    or the capabilities of a server, without implying a resource action
    1700    or initiating a resource retrieval.
    1701 </t>
    1702 <t>
    1703    Responses to the OPTIONS method are not cacheable.
    1704 </t>
    1705 <t>
    1706    If the OPTIONS request includes a message body (as indicated by the
    1707    presence of Content-Length or Transfer-Encoding), then the media type
    1708    &MUST; be indicated by a Content-Type field. Although this
    1709    specification does not define any use for such a body, future
    1710    extensions to HTTP might use the OPTIONS body to make more detailed
    1711    queries on the server.
    1712 </t>
    1713 <t>
    1714    If the request-target (&request-target;) is an asterisk ("*"),
    1715    the OPTIONS request is
    1716    intended to apply to the server in general rather than to a specific
    1717    resource. Since a server's communication options typically depend on
    1718    the resource, the "*" request is only useful as a "ping" or "no-op"
    1719    type of method; it does nothing beyond allowing the client to test
    1720    the capabilities of the server. For example, this can be used to test
    1721    a proxy for HTTP/1.1 conformance (or lack thereof).
    1722 </t>
    1723 <t>
    1724    If the request-target is not an asterisk, the OPTIONS request applies
    1725    only to the options that are available when communicating with that
    1726    resource.
    1727 </t>
    1728 <t>
    1729    A 200 response &SHOULD; include any header fields that indicate
    1730    optional features implemented by the server and applicable to that
    1731    resource (e.g., Allow), possibly including extensions not defined by
    1732    this specification. The response body, if any, &SHOULD; also include
    1733    information about the communication options. The format for such a
    1734    body is not defined by this specification, but might be defined by
    1735    future extensions to HTTP. Content negotiation &MAY; be used to select
    1736    the appropriate response format. If no response body is included, the
    1737    response &MUST; include a Content-Length field with a field-value of
    1738    "0".
    1739 </t>
    1740 <t>
    1741    The Max-Forwards header field &MAY; be used to target a
    1742    specific proxy in the request chain (see <xref target="header.max-forwards"/>).
    1743    If no Max-Forwards field is present in the request, then the forwarded
    1744    request &MUST-NOT; include a Max-Forwards field.
    1745 </t>
    1746 </section>
    1747 
    1748 <section title="GET" anchor="GET">
    1749   <rdf:Description>
    1750     <safe xmlns="urn:ietf:id:draft-ietf-httpbis-p2-semantics#">yes</safe>
    1751   </rdf:Description>
    1752   <iref primary="true" item="GET method" x:for-anchor=""/>
    1753   <iref primary="true" item="Methods" subitem="GET" x:for-anchor=""/>
    1754 <t>
    1755    The GET method requests transfer of a current representation of
    1756    the target resource.
    1757 </t>
    1758 <t>   
    1759    If the target resource is a data-producing process, it is the
    1760    produced data which shall be returned as the representation in the response and not
    1761    the source text of the process, unless that text happens to be the output of
    1762    the process.
    1763 </t>
    1764 <t>
    1765    The semantics of the GET method change to a "conditional GET" if the
    1766    request message includes an If-Modified-Since, If-Unmodified-Since,
    1767    If-Match, If-None-Match, or If-Range header field. A conditional GET
    1768    requests that the representation be transferred only under the
    1769    circumstances described by the conditional header field(s). The
    1770    conditional GET request is intended to reduce unnecessary network
    1771    usage by allowing cached representations to be refreshed without requiring
    1772    multiple requests or transferring data already held by the client.
    1773 </t>
    1774 <t>
    1775    The semantics of the GET method change to a "partial GET" if the
    1776    request message includes a Range header field. A partial GET requests
    1777    that only part of the representation be transferred, as described in &header-range;.
    1778    The partial GET request is intended to reduce unnecessary
    1779    network usage by allowing partially-retrieved representations to be
    1780    completed without transferring data already held by the client.
    1781 </t>
    1782 <t>
    1783    Bodies on GET requests have no defined semantics. Note that sending a body
    1784    on a GET request might cause some existing implementations to reject the
    1785    request.
    1786 </t>
    1787 <t>
    1788    The response to a GET request is cacheable and &MAY; be used to satisfy
    1789    subsequent GET and HEAD requests (see &caching;).
    1790 </t>
    1791 <t>
    1792    See <xref target="encoding.sensitive.information.in.uris"/> for security considerations when used for forms.
    1793 </t>
    1794 </section>
    1795 
    1796 <section title="HEAD" anchor="HEAD">
    1797   <rdf:Description>
    1798     <safe xmlns="urn:ietf:id:draft-ietf-httpbis-p2-semantics#">yes</safe>
    1799   </rdf:Description>
    1800   <iref primary="true" item="HEAD method" x:for-anchor=""/>
    1801   <iref primary="true" item="Methods" subitem="HEAD" x:for-anchor=""/>
    1802 <t>
    1803    The HEAD method is identical to GET except that the server &MUST-NOT;
    1804    return a message body in the response. The metadata contained
    1805    in the HTTP header fields in response to a HEAD request &SHOULD; be identical
    1806    to the information sent in response to a GET request. This method can
    1807    be used for obtaining metadata about the representation implied by the
    1808    request without transferring the representation body. This method is
    1809    often used for testing hypertext links for validity, accessibility,
    1810    and recent modification.
    1811 </t>
    1812 <t>
    1813    The response to a HEAD request is cacheable and &MAY; be used to satisfy
    1814    a subsequent HEAD request. It also has potential side effects on
    1815    previously stored responses to GET; see &p6-head;.
    1816 </t>
    1817 <t>
    1818    Bodies on HEAD requests have no defined semantics. Note that sending a body
    1819    on a HEAD request might cause some existing implementations to reject the
    1820    request.
    1821 </t>
    1822 </section>
    1823 
    1824 <section title="POST" anchor="POST">
    1825   <iref primary="true" item="POST method" x:for-anchor=""/>
    1826   <iref primary="true" item="Methods" subitem="POST" x:for-anchor=""/>
    1827 <t>
    1828    The POST method requests that the origin server accept the
    1829    representation enclosed in the request as data to be processed by the
    1830    target resource. POST is designed to allow a uniform method to cover the
    1831    following functions:
    1832   <list style="symbols">
    1833     <t>
    1834       Annotation of existing resources;
    1835     </t>
    1836     <t>
    1837         Posting a message to a bulletin board, newsgroup, mailing list,
    1838         or similar group of articles;
    1839     </t>
    1840     <t>
    1841         Providing a block of data, such as the result of submitting a
    1842         form, to a data-handling process;
    1843     </t>
    1844     <t>
    1845         Extending a database through an append operation.
    1846     </t>
    1847   </list>
    1848 </t>
    1849 <t>
    1850    The actual function performed by the POST method is determined by the
    1851    server and is usually dependent on the effective request URI.
    1852 </t>
    1853 <t>
    1854    The action performed by the POST method might not result in a
    1855    resource that can be identified by a URI. In this case, either 200
    1856    (OK) or 204 (No Content) is the appropriate response status code,
    1857    depending on whether or not the response includes a representation that
    1858    describes the result.
    1859 </t>
    1860 <t>
    1861    If a resource has been created on the origin server, the response
    1862    &SHOULD; be 201 (Created) and contain a representation which describes the
    1863    status of the request and refers to the new resource, and a Location
    1864    header field (see <xref target="header.location"/>).
    1865 </t>
    1866 <t>
    1867    Responses to POST requests are only cacheable when they
    1868    include explicit freshness information (see &p6-explicit;). A
    1869    cached POST response with a Content-Location header field
    1870    (see &header-content-location;) whose value is the effective
    1871    Request URI &MAY; be used to satisfy subsequent GET and HEAD requests.
    1872 </t>
    1873 <t>
    1874    Note that POST caching is not widely implemented.
    1875    However, the 303 (See Other) response can be used to direct the
    1876    user agent to retrieve a cacheable representation of the resource.
    1877 </t>
    1878 </section>
    1879 
    1880 <section title="PUT" anchor="PUT">
    1881   <iref primary="true" item="PUT method" x:for-anchor=""/>
    1882   <iref primary="true" item="Methods" subitem="PUT" x:for-anchor=""/>
    1883 <t>
    1884    The PUT method requests that the state of the target resource
    1885    be created or replaced with the state defined by the representation
    1886    enclosed in the request message payload.  A successful PUT of a given
    1887    representation would suggest that a subsequent GET on that same target
    1888    resource will result in an equivalent representation being returned in
    1889    a 200 (OK) response.  However, there is no guarantee that such a state
    1890    change will be observable, since the target resource might be acted
    1891    upon by other user agents in parallel, or might be subject to dynamic
    1892    processing by the origin server, before any subsequent GET is received.
    1893    A successful response only implies that the user agent's intent was
    1894    achieved at the time of its processing by the origin server.
    1895 </t>
    1896 <t>   
    1897    If the target resource does not have a current representation and
    1898    the PUT successfully creates one, then the origin server &MUST; inform
    1899    the user agent by sending a 201 (Created) response.  If the target
    1900    resource does have a current representation and that representation is
    1901    successfully modified in accordance with the state of the enclosed
    1902    representation, then either a 200 (OK) or 204 (No Content) response
    1903    &SHOULD; be sent to indicate successful completion of the request.
    1904 </t>
    1905 <t>
    1906    Unrecognized header fields &SHOULD; be ignored (i.e., not saved
    1907    as part of the resource state).
    1908 </t>
    1909 <t>
    1910    An origin server &SHOULD; verify that the PUT representation is
    1911    consistent with any constraints which the server has for the target
    1912    resource that cannot or will not be changed by the PUT.  This is
    1913    particularly important when the origin server uses internal
    1914    configuration information related to the URI in order to set the
    1915    values for representation metadata on GET responses.  When a PUT
    1916    representation is inconsistent with the target resource, the origin
    1917    server &SHOULD; either make them consistent, by transforming the
    1918    representation or changing the resource configuration, or respond
    1919    with an appropriate error message containing sufficient information
    1920    to explain why the representation is unsuitable.  The 409 (Conflict)
    1921    or 415 (Unsupported Media Type) status codes are suggested, with the
    1922    latter being specific to constraints on Content-Type values.
    1923 </t>
    1924 <t>
    1925    For example, if the target resource is configured to always have a
    1926    Content-Type of "text/html" and the representation being PUT has a
    1927    Content-Type of "image/jpeg", then the origin server &SHOULD; do one of:
    1928    (a) reconfigure the target resource to reflect the new media type;
    1929    (b) transform the PUT representation to a format consistent with that
    1930    of the resource before saving it as the new resource state; or,
    1931    (c) reject the request with a 415 response indicating that the target
    1932    resource is limited to "text/html", perhaps including a link to a
    1933    different resource that would be a suitable target for the new
    1934    representation.
    1935 </t>
    1936 <t>
    1937    HTTP does not define exactly how a PUT method affects the state
    1938    of an origin server beyond what can be expressed by the intent of
    1939    the user agent request and the semantics of the origin server response.
    1940    It does not define what a resource might be, in any sense of that
    1941    word, beyond the interface provided via HTTP.  It does not define
    1942    how resource state is "stored", nor how such storage might change
    1943    as a result of a change in resource state, nor how the origin server
    1944    translates resource state into representations.  Generally speaking,
    1945    all implementation details behind the resource interface are
    1946    intentionally hidden by the server.
    1947 </t>
    1948 <t>
    1949    The fundamental difference between the POST and PUT methods is
    1950    highlighted by the different intent for the target resource.
    1951    The target resource in a POST request is intended to handle the
    1952    enclosed representation as a data-accepting process, such as for
    1953    a gateway to some other protocol or a document that accepts annotations.
    1954    In contrast, the target resource in a PUT request is intended to
    1955    take the enclosed representation as a new or replacement value.
    1956    Hence, the intent of PUT is idempotent and visible to intermediaries,
    1957    even though the exact effect is only known by the origin server.
    1958 </t>
    1959 <t>
    1960    Proper interpretation of a PUT request presumes that the user agent
    1961    knows what target resource is desired.  A service that is intended
    1962    to select a proper URI on behalf of the client, after receiving
    1963    a state-changing request, &SHOULD; be implemented using the POST
    1964    method rather than PUT.  If the origin server will not make the
    1965    requested PUT state change to the target resource and instead
    1966    wishes to have it applied to a different resource, such as when the
    1967    resource has been moved to a different URI, then the origin server
    1968    &MUST; send a 301 (Moved Permanently) response; the user agent &MAY;
    1969    then make its own decision regarding whether or not to redirect the
    1970    request.
    1971 </t>
    1972 <t>
    1973    A PUT request applied to the target resource &MAY; have side-effects
    1974    on other resources.  For example, an article might have a URI for
    1975    identifying "the current version" (a resource) which is separate
    1976    from the URIs identifying each particular version (different
    1977    resources that at one point shared the same state as the current version
    1978    resource).  A successful PUT request on "the current version" URI might
    1979    therefore create a new version resource in addition to changing the
    1980    state of the target resource, and might also cause links to be added
    1981    between the related resources.
    1982 </t>
    1983 <t>
    1984    An origin server &SHOULD; reject any PUT request that contains a
    1985    Content-Range header field, since it might be misinterpreted as
    1986    partial content (or might be partial content that is being mistakenly
    1987    PUT as a full representation).  Partial content updates are
    1988    possible by targeting a separately identified resource with state
    1989    that overlaps a portion of the larger resource, or by using a
    1990    different method that has been specifically defined for partial
    1991    updates (for example, the PATCH method defined in
    1992    <xref target="RFC5789"/>).
    1993 </t>
    1994 <t>
    1995    Responses to the PUT method are not cacheable. If a PUT request passes
    1996    through a cache that has one or more stored responses for the effective
    1997    request URI, those stored responses will be invalidated (see
    1998    &p6-invalid;).
    1999 </t>
    2000 </section>
    2001 
    2002 <section title="DELETE" anchor="DELETE">
    2003   <iref primary="true" item="DELETE method" x:for-anchor=""/>
    2004   <iref primary="true" item="Methods" subitem="DELETE" x:for-anchor=""/>
    2005 <t>
    2006    The DELETE method requests that the origin server delete the target
    2007    resource. This method &MAY; be overridden by
    2008    human intervention (or other means) on the origin server. The client cannot
    2009    be guaranteed that the operation has been carried out, even if the
    2010    status code returned from the origin server indicates that the action
    2011    has been completed successfully. However, the server &SHOULD-NOT;
    2012    indicate success unless, at the time the response is given, it
    2013    intends to delete the resource or move it to an inaccessible
    2014    location.
    2015 </t>
    2016 <t>
    2017    A successful response &SHOULD; be 200 (OK) if the response includes an
    2018    representation describing the status, 202 (Accepted) if the action has not
    2019    yet been enacted, or 204 (No Content) if the action has been enacted
    2020    but the response does not include a representation.
    2021 </t>
    2022 <t>
    2023    Bodies on DELETE requests have no defined semantics. Note that sending a body
    2024    on a DELETE request might cause some existing implementations to reject the
    2025    request.
    2026 </t>
    2027 <t>
    2028    Responses to the DELETE method are not cacheable. If a DELETE request
    2029    passes through a cache that has one or more stored responses for the
    2030    effective request URI, those stored responses will be invalidated (see
    2031    &p6-invalid;).
    2032 </t>
    2033 </section>
    2034 
    2035 <section title="TRACE" anchor="TRACE">
    2036   <rdf:Description>
    2037     <safe xmlns="urn:ietf:id:draft-ietf-httpbis-p2-semantics#">yes</safe>
    2038   </rdf:Description>
    2039   <iref primary="true" item="TRACE method" x:for-anchor=""/>
    2040   <iref primary="true" item="Methods" subitem="TRACE" x:for-anchor=""/>
    2041 <t>
    2042    The TRACE method requests a remote, application-layer loop-back
    2043    of the request message. The final recipient of the request
    2044    &SHOULD; reflect the message received back to the client as the
    2045    message body of a 200 (OK) response. The final recipient is either the
    2046    origin server or the first proxy to receive a Max-Forwards
    2047    value of zero (0) in the request (see <xref target="header.max-forwards"/>).
    2048    A TRACE request &MUST-NOT; include a message body.
    2049 </t>
    2050 <t>
    2051    TRACE allows the client to see what is being received at the other
    2052    end of the request chain and use that data for testing or diagnostic
    2053    information. The value of the Via header field (&header-via;) is of
    2054    particular interest, since it acts as a trace of the request chain.
    2055    Use of the Max-Forwards header field allows the client to limit the
    2056    length of the request chain, which is useful for testing a chain of
    2057    proxies forwarding messages in an infinite loop.
    2058 </t>
    2059 <t>
    2060    If the request is valid, the response &SHOULD; have a Content-Type of
    2061    "message/http" (see &media-type-message-http;) and contain a message body
    2062    that encloses a copy of the entire request message.
    2063    Responses to the TRACE method are not cacheable.
    2064 </t>
    2065 </section>
    2066 
    2067 <section title="CONNECT" anchor="CONNECT">
    2068   <iref primary="true" item="CONNECT method" x:for-anchor=""/>
    2069   <iref primary="true" item="Methods" subitem="CONNECT" x:for-anchor=""/>
    2070 <t>
    2071    The CONNECT method requests that the proxy establish a tunnel
    2072    to the request-target and, if successful, thereafter restrict its behavior
    2073    to blind forwarding of packets until the connection is closed.
    2074 </t>
    2075 <t>
    2076    When using CONNECT, the request-target &MUST; use the authority form
    2077    (&request-target;); i.e., the request-target consists of only the
    2078    host name and port number of the tunnel destination, separated by a colon.
    2079    For example,
    2080 </t>
    2081 <figure><artwork type="message/http; msgtype=&#34;request&#34;" x:indent-with="  ">
    2082 CONNECT server.example.com:80 HTTP/1.1
    2083 Host: server.example.com:80
    2084 
    2085 </artwork></figure>
    2086 <t>
    2087    Any successful (2xx) response to a CONNECT request indicates that the
    2088    proxy has established a connection to the requested host and port,
    2089    and has switched to tunneling the current connection to that server
    2090    connection.
    2091    The tunneled data from the server begins immediately after the blank line
    2092    that concludes the successful response's header block.
    2093    A server &SHOULD-NOT; send any Transfer-Encoding or Content-Length
    2094    header fields in a successful response.
    2095    A client &MUST; ignore any Content-Length or Transfer-Encoding header
    2096    fields received in a successful response.
    2097 </t>
    2098 <t>
    2099    Any response other than a successful response indicates that the tunnel
    2100    has not yet been formed and that the connection remains governed by HTTP.
    2101 </t>
    2102 <t>
    2103    Proxy authentication might be used to establish the
    2104    authority to create a tunnel:
    2105 </t>
    2106 <figure><artwork type="message/http; msgtype=&#34;request&#34;" x:indent-with="  ">
    2107 CONNECT server.example.com:80 HTTP/1.1
    2108 Host: server.example.com:80
    2109 Proxy-Authorization: basic aGVsbG86d29ybGQ=
    2110 
    2111 </artwork></figure>
    2112 <t>
    2113    A message body on a CONNECT request has no defined semantics. Sending a
    2114    body on a CONNECT request might cause existing implementations to reject
    2115    the request.
    2116 </t>
    2117 <t>
    2118    Similar to a pipelined HTTP/1.1 request, data to be tunneled from client
    2119    to server &MAY; be sent immediately after the request (before a response
    2120    is received). The usual caveats also apply:
    2121    data may be discarded if the eventual response is negative, and the
    2122    connection may be reset with no response if more than one TCP segment
    2123    is outstanding.
    2124 </t>
    2125 <t>
    2126    It may be the case that the proxy itself can only reach the requested
    2127    origin server through another proxy.  In this case, the first proxy
    2128    &SHOULD; make a CONNECT request of that next proxy, requesting a tunnel
    2129    to the authority.  A proxy &MUST-NOT; respond with any 2xx status code
    2130    unless it has either a direct or tunnel connection established to the
    2131    authority.
    2132 </t>
    2133 <t>
    2134    If at any point either one of the peers gets disconnected, any
    2135    outstanding data that came from that peer will be passed to the other
    2136    one, and after that also the other connection will be terminated by
    2137    the proxy. If there is outstanding data to that peer undelivered,
    2138    that data will be discarded.
    2139 </t>
    2140 <t>
    2141    An origin server which receives a CONNECT request for itself &MAY;
    2142    respond with a 2xx status code to indicate that a connection is
    2143    established.  However, most origin servers do not implement CONNECT.
    2144 </t>
    2145 </section>
    2146 </section>
    2147 
    21482120<section title="Common Protocol Parameters" anchor="common.protocol.parameters">
    21492121<section title="Date/Time Formats" anchor="http.date">
    … …  
    36793651<section title="Changes from RFC 2616" anchor="changes.from.rfc.2616">
    36803652<t>
     3653  Clarify definition of POST.
     3654  (<xref target="POST"/>)
     3655</t>
     3656<t>
     3657  Remove requirement to handle all Content-* header fields; ban use of
     3658  Content-Range with PUT.
     3659  (<xref target="PUT"/>)
     3660</t>
     3661<t>
     3662  Take over definition of CONNECT method from <xref target="RFC2817"/>.
     3663  (<xref target="CONNECT"/>)
     3664</t>
     3665<t>
    36813666  This document takes over the Status Code Registry, previously defined
    36823667  in <xref target="RFC2817" x:fmt="of" x:sec="7.1"/>.
    … …  
    37143699  <xref target="RFC2817"/>).
    37153700  (<xref target="status.426"/>)
    3716 </t>
    3717 <t>
    3718   Clarify definition of POST.
    3719   (<xref target="POST"/>)
    3720 </t>
    3721 <t>
    3722   Remove requirement to handle all Content-* header fields; ban use of
    3723   Content-Range with PUT.
    3724   (<xref target="PUT"/>)
    3725 </t>
    3726 <t>
    3727   Take over definition of CONNECT method from <xref target="RFC2817"/>.
    3728   (<xref target="CONNECT"/>)
    37293701</t>
    37303702<t>
Note: See TracChangeset for help on using the changeset viewer.