Ignore:
Timestamp:
Jul 29, 2010, 11:12:22 PM (9 years ago)
Author:
fielding@…
Message:

regenerate html, but needs appendix updates

File:
1 edited

Legend:

Unmodified
Added
Removed

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

    r964 r966  
    684684         to each request, in the order received on that connection, with one or more HTTP response messages. This document defines
    685685         the commonly agreed upon semantics of the HTTP uniform interface, the intentions defined by each request method, and the various
    686          response messages that might be expected as a result of applying that method for the requested resource.
     686         response messages that might be expected as a result of applying that method to the target resource.
    687687      </p>
    688688      <p id="rfc.section.1.p.2">This document is currently disorganized in order to minimize the changes between drafts and enable reviewers to see the smaller
    … …  
    726726  <a href="#abnf.dependencies" class="smpl">TE</a>            = &lt;TE, defined in <a href="#Part1" id="rfc.xref.Part1.15"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#header.te" title="TE">Section 9.5</a>&gt;
    727727  <a href="#abnf.dependencies" class="smpl">URI-reference</a> = &lt;URI-reference, defined in <a href="#Part1" id="rfc.xref.Part1.16"><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.6</a>&gt;
    728 </pre><div id="rfc.figure.u.3"></div><pre class="inline">  <a href="#abnf.dependencies" class="smpl">Accept</a>        = &lt;Accept, defined in <a href="#Part3" id="rfc.xref.Part3.1"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#header.accept" title="Accept">Section 5.1</a>&gt;
     728</pre><div id="rfc.figure.u.3"></div><pre class="inline">  <a href="#abnf.dependencies" class="smpl">Accept</a>        = &lt;Accept, defined in <a href="#Part3" id="rfc.xref.Part3.1"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#header.accept" title="Accept">Section 6.1</a>&gt;
    729729  <a href="#abnf.dependencies" class="smpl">Accept-Charset</a> =
    730              &lt;Accept-Charset, defined in <a href="#Part3" id="rfc.xref.Part3.2"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#header.accept-charset" title="Accept-Charset">Section 5.2</a>&gt;
     730             &lt;Accept-Charset, defined in <a href="#Part3" id="rfc.xref.Part3.2"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#header.accept-charset" title="Accept-Charset">Section 6.2</a>&gt;
    731731  <a href="#abnf.dependencies" class="smpl">Accept-Encoding</a> =
    732              &lt;Accept-Encoding, defined in <a href="#Part3" id="rfc.xref.Part3.3"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#header.accept-encoding" title="Accept-Encoding">Section 5.3</a>&gt;
     732             &lt;Accept-Encoding, defined in <a href="#Part3" id="rfc.xref.Part3.3"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#header.accept-encoding" title="Accept-Encoding">Section 6.3</a>&gt;
    733733  <a href="#abnf.dependencies" class="smpl">Accept-Language</a> =
    734              &lt;Accept-Language, defined in <a href="#Part3" id="rfc.xref.Part3.4"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#header.accept-language" title="Accept-Language">Section 5.4</a>&gt;
     734             &lt;Accept-Language, defined in <a href="#Part3" id="rfc.xref.Part3.4"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#header.accept-language" title="Accept-Language">Section 6.4</a>&gt;
    735735</pre><div id="rfc.figure.u.4"></div><pre class="inline">  <a href="#abnf.dependencies" class="smpl">ETag</a>          = &lt;ETag, defined in <a href="#Part4" id="rfc.xref.Part4.1"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>, <a href="p4-conditional.html#header.etag" title="ETag">Section 6.1</a>&gt;
    736736  <a href="#abnf.dependencies" class="smpl">If-Match</a>      = &lt;If-Match, defined in <a href="#Part4" id="rfc.xref.Part4.2"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>, <a href="p4-conditional.html#header.if-match" title="If-Match">Section 6.2</a>&gt;
    … …  
    753753             &lt;WWW-Authenticate, defined in <a href="#Part7" id="rfc.xref.Part7.4"><cite title="HTTP/1.1, part 7: Authentication">[Part7]</cite></a>, <a href="p7-auth.html#header.www-authenticate" title="WWW-Authenticate">Section 3.4</a>&gt;
    754754</pre><h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a>&nbsp;<a id="method" href="#method">Method</a></h1>
    755       <p id="rfc.section.2.p.1">The Method token indicates the method to be performed on the resource identified by the Effective Request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.17"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). The method is case-sensitive.
     755      <p id="rfc.section.2.p.1">The Method token indicates the method to be performed on the resource identified by the effective request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.17"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). The method is case-sensitive.
    756756      </p>
    757757      <div id="rfc.figure.u.8"></div><pre class="inline"><span id="rfc.iref.g.1"></span><span id="rfc.iref.g.2"></span>  <a href="#method" class="smpl">Method</a>         = %x4F.50.54.49.4F.4E.53   ; "OPTIONS", <a href="#OPTIONS" id="rfc.xref.OPTIONS.1" title="OPTIONS">Section&nbsp;7.2</a>
    … …  
    765765                 / <a href="#method" class="smpl">extension-method</a>
    766766  <a href="#method" class="smpl">extension-method</a> = <a href="#core.rules" class="smpl">token</a>
    767 </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;9.1</a>). The return code of the response always notifies the client whether a method is currently allowed on a resource, since the
    768          set of allowed methods can change dynamically. An origin server <em class="bcp14">SHOULD</em> return the status code 405 (Method Not Allowed) if the method is known by the origin server but not allowed for the requested
     767</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;9.1</a>). The status code of the response always notifies the client whether a method is currently allowed on a resource, since the
     768         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
    769769         resource, and 501 (Not Implemented) if the method is unrecognized or not implemented by the origin server. The methods GET
    770770         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;7</a>.
    … …  
    790790         method invocation.
    791791      </p>
    792       <div id="rfc.figure.u.9"></div><pre class="inline"><span id="rfc.iref.g.3"></span>  <a href="#request.header.fields" class="smpl">request-header</a> = <a href="#abnf.dependencies" class="smpl">Accept</a>                   ; <a href="#Part3" id="rfc.xref.Part3.5"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#header.accept" title="Accept">Section 5.1</a>
    793                  / <a href="#abnf.dependencies" class="smpl">Accept-Charset</a>           ; <a href="#Part3" id="rfc.xref.Part3.6"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#header.accept-charset" title="Accept-Charset">Section 5.2</a>
    794                  / <a href="#abnf.dependencies" class="smpl">Accept-Encoding</a>          ; <a href="#Part3" id="rfc.xref.Part3.7"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#header.accept-encoding" title="Accept-Encoding">Section 5.3</a>
    795                  / <a href="#abnf.dependencies" class="smpl">Accept-Language</a>          ; <a href="#Part3" id="rfc.xref.Part3.8"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#header.accept-language" title="Accept-Language">Section 5.4</a>
     792      <div id="rfc.figure.u.9"></div><pre class="inline"><span id="rfc.iref.g.3"></span>  <a href="#request.header.fields" class="smpl">request-header</a> = <a href="#abnf.dependencies" class="smpl">Accept</a>                   ; <a href="#Part3" id="rfc.xref.Part3.5"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#header.accept" title="Accept">Section 6.1</a>
     793                 / <a href="#abnf.dependencies" class="smpl">Accept-Charset</a>           ; <a href="#Part3" id="rfc.xref.Part3.6"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#header.accept-charset" title="Accept-Charset">Section 6.2</a>
     794                 / <a href="#abnf.dependencies" class="smpl">Accept-Encoding</a>          ; <a href="#Part3" id="rfc.xref.Part3.7"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#header.accept-encoding" title="Accept-Encoding">Section 6.3</a>
     795                 / <a href="#abnf.dependencies" class="smpl">Accept-Language</a>          ; <a href="#Part3" id="rfc.xref.Part3.8"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#header.accept-language" title="Accept-Language">Section 6.4</a>
    796796                 / <a href="#abnf.dependencies" class="smpl">Authorization</a>            ; <a href="#Part7" id="rfc.xref.Part7.5"><cite title="HTTP/1.1, part 7: Authentication">[Part7]</cite></a>, <a href="p7-auth.html#header.authorization" title="Authorization">Section 3.1</a>
    797797                 / <a href="#header.expect" class="smpl">Expect</a>                   ; <a href="#header.expect" id="rfc.xref.header.expect.1" title="Expect">Section&nbsp;9.2</a>
    … …  
    811811</pre><p id="rfc.section.3.p.3">Request-header field names can be extended reliably only in combination with a change in the protocol version. However, new
    812812         or experimental header fields <em class="bcp14">MAY</em> be given the semantics of request-header fields if all parties in the communication recognize them to be request-header fields.
    813          Unrecognized header fields are treated as entity-header fields.
    814813      </p>
    815814      <h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a>&nbsp;<a id="status.code.and.reason.phrase" href="#status.code.and.reason.phrase">Status Code and Reason Phrase</a></h1>
    … …  
    883882      <p id="rfc.section.5.p.1">The response-header fields allow the server to pass additional information about the response which cannot be placed in the
    884883         Status-Line. These header fields give information about the server and about further access to the resource identified by
    885          the Effective Request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.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>).
     884         the effective request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.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>).
    886885      </p>
    887886      <div id="rfc.figure.u.11"></div><pre class="inline"><span id="rfc.iref.g.7"></span>  <a href="#response.header.fields" class="smpl">response-header</a> = <a href="#abnf.dependencies" class="smpl">Accept-Ranges</a>           ; <a href="#Part5" id="rfc.xref.Part5.9"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>, <a href="p5-range.html#header.accept-ranges" title="Accept-Ranges">Section 5.1</a>
    … …  
    897896</pre><p id="rfc.section.5.p.3">Response-header field names can be extended reliably only in combination with a change in the protocol version. However, new
    898897         or experimental header fields <em class="bcp14">MAY</em> be given the semantics of response-header fields if all parties in the communication recognize them to be response-header
    899          fields. Unrecognized header fields are treated as entity-header fields.
     898         fields.
    900899      </p>
    901900      <h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a>&nbsp;<a id="representation" href="#representation">Representation</a></h1>
    … …  
    908907      </p>
    909908      <h2 id="rfc.section.6.1"><a href="#rfc.section.6.1">6.1</a>&nbsp;<a id="identifying.response.associated.with.representation" href="#identifying.response.associated.with.representation">Identifying the Resource Associated with a Representation</a></h2>
    910       <p id="rfc.section.6.1.p.1">It is sometimes necessary to determine the identity of the resource associated with a representation.</p>
     909      <p id="rfc.section.6.1.p.1">It is sometimes necessary to determine an identifier for the resource associated with a representation.</p>
    911910      <p id="rfc.section.6.1.p.2">An HTTP request representation, when present, is always associated with an anonymous (i.e., unidentified) resource.</p>
    912       <p id="rfc.section.6.1.p.3">In the common case, an HTTP response is a representation of the resource located at the Effective Request URI (see <a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</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>). However, this is not always the case. To determine the URI of the resource a response is associated with, the following
     911      <p id="rfc.section.6.1.p.3">In the common case, an HTTP response is a representation of the resource located at the effective request URI (see <a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</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>). However, this is not always the case. To determine the URI of the resource a response is associated with, the following
    913912         rules are used (with the first applicable one being selected):
    914913      </p>
    915914      <ol>
    916          <li>If the response status code is 200 or 203 and the request method was GET, the response is a representation of the resource
    917             at the Effective Request URI.
    918          </li>
    919          <li>If the response status code is 204, 206, or 304 and the request method was GET or HEAD, the response is a partial representation
    920             of the resource at the Effective Request URI (see <a href="p6-cache.html#combining.headers" title="Combining Responses">Section 2.8</a> of <a href="#Part6" id="rfc.xref.Part6.5"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>).
    921          </li>
    922          <li>If the response has a Content-Location header, and that URI is the same as the Effective Request URI, the response is a representation
    923             of the resource at the Effective Request URI.
    924          </li>
    925          <li>If the response has a Content-Location header, and that URI is not the same as the Effective Request URI, the response asserts
    926             that it is a representation of the resource at the Content-Location URI (but it might not be).
     915         <li>If the response status code is 200 or 203 and the request method was GET, the response payload is a representation of the
     916            resource identified by the effective request URI.
     917         </li>
     918         <li>If the response status code is 204, 206, or 304 and the request method was GET or HEAD, the response payload is a partial
     919            representation of the resource identified by the effective request URI (see <a href="p6-cache.html#combining.headers" title="Combining Responses">Section 2.8</a> of <a href="#Part6" id="rfc.xref.Part6.5"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>).
     920         </li>
     921         <li>If the response has a Content-Location header, and that URI is the same as the effective request URI, the response payload
     922            is a representation of the resource identified by the effective request URI.
     923         </li>
     924         <li>If the response has a Content-Location header, and that URI is not the same as the effective request URI, then the response
     925            asserts that its payload is a representation of the resource identified by the Content-Location URI. However, such an assertion
     926            cannot be trusted unless it can be verified by other means (not defined by HTTP).
    927927         </li>
    928928         <li>Otherwise, the response is a representation of an anonymous (i.e., unidentified) resource.</li>
    … …  
    960960      <div id="rfc.iref.m.1"></div>
    961961      <p id="rfc.section.7.2.p.1">The OPTIONS method represents a request for information about the communication options available on the request/response
    962          chain identified by the Effective Request URI. This method allows the client to determine the options and/or requirements
     962         chain identified by the effective request URI. This method allows the client to determine the options and/or requirements
    963963         associated with a resource, or the capabilities of a server, without implying a resource action or initiating a resource retrieval.
    964964      </p>
    … …  
    986986      <div id="rfc.iref.m.2"></div>
    987987      <p id="rfc.section.7.3.p.1">The GET method means retrieve whatever information (in the form of a representation) currently corresponds to the resource
    988          identified by the Effective Request URI.
    989       </p>
    990       <p id="rfc.section.7.3.p.2">If the Effective Request URI identifies a data-producing process, it is the produced data which shall be returned as the representation
     988         identified by the effective request URI.
     989      </p>
     990      <p id="rfc.section.7.3.p.2">If the effective request URI identifies a data-producing process, it is the produced data which shall be returned as the representation
    991991         in the response and not the source text of the process, unless that text happens to be the output of the process.
    992992      </p>
    … …  
    10201020      <h2 id="rfc.section.7.5"><a href="#rfc.section.7.5">7.5</a>&nbsp;<a id="POST" href="#POST">POST</a></h2>
    10211021      <p id="rfc.section.7.5.p.1">The POST method is used to request that the origin server accept the representation enclosed in the request as data to be
    1022          processed by the resource identified by the Effective Request URI. POST is designed to allow a uniform method to cover the
     1022         processed by the resource identified by the effective request URI. POST is designed to allow a uniform method to cover the
    10231023         following functions:
    10241024      </p>
    … …  
    10291029         <li>Extending a database through an append operation.</li>
    10301030      </ul>
    1031       <p id="rfc.section.7.5.p.2">The actual function performed by the POST method is determined by the server and is usually dependent on the Effective Request
     1031      <p id="rfc.section.7.5.p.2">The actual function performed by the POST method is determined by the server and is usually dependent on the effective request
    10321032         URI.
    10331033      </p>
    … …  
    10391039         a Location header (see <a href="#header.location" id="rfc.xref.header.location.2" title="Location">Section&nbsp;9.4</a>).
    10401040      </p>
    1041       <p id="rfc.section.7.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.8"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>). A cached POST response with a Content-Location header (see <a href="p3-payload.html#header.content-location" title="Content-Location">Section 5.7</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>) whose value is the Effective Request URI <em class="bcp14">MAY</em> be used to satisfy subsequent GET and HEAD requests.
     1041      <p id="rfc.section.7.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.8"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>). A cached POST response with a Content-Location header (see <a href="p3-payload.html#header.content-location" title="Content-Location">Section 6.7</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>) whose value is the Effective Request URI <em class="bcp14">MAY</em> be used to satisfy subsequent GET and HEAD requests.
    10421042      </p>
    10431043      <p id="rfc.section.7.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
    … …  
    10471047      <div id="rfc.iref.m.5"></div>
    10481048      <h2 id="rfc.section.7.6"><a href="#rfc.section.7.6">7.6</a>&nbsp;<a id="PUT" href="#PUT">PUT</a></h2>
    1049       <p id="rfc.section.7.6.p.1">The PUT method requests that the enclosed representation be stored at the Effective Request URI. If the Effective Request
    1050          URI refers to an already existing resource, the enclosed representation <em class="bcp14">SHOULD</em> be considered a modified version of the one residing on the origin server. Otherwise, if the Effective Request URI does not
     1049      <p id="rfc.section.7.6.p.1">The PUT method requests that the enclosed representation be stored at the effective request URI. If the effective request
     1050         URI refers to an already existing resource, the enclosed representation <em class="bcp14">SHOULD</em> be considered a modified version of the one residing on the origin server. Otherwise, if the effective request URI does not
    10511051         point to an existing resource, and that URI is capable of being defined as a new resource by the requesting user agent, the
    10521052         origin server can create the resource with that URI.
    10531053      </p>
    1054       <p id="rfc.section.7.6.p.2">If a new resource is created at the Effective Request URI, the origin server <em class="bcp14">MUST</em> inform the user agent via the 201 (Created) response. If an existing resource is modified, either the 200 (OK) or 204 (No
     1054      <p id="rfc.section.7.6.p.2">If a new resource is created at the effective request URI, the origin server <em class="bcp14">MUST</em> inform the user agent via the 201 (Created) response. If an existing resource is modified, either the 200 (OK) or 204 (No
    10551055         Content) response codes <em class="bcp14">SHOULD</em> be sent to indicate successful completion of the request.
    10561056      </p>
    1057       <p id="rfc.section.7.6.p.3">If the resource identified by the Effective Request URI could not be created or modified, an appropriate error response <em class="bcp14">SHOULD</em> be given that reflects the nature of the problem. The recipient of the representation <em class="bcp14">MUST NOT</em> ignore any Content-* headers (headers starting with the prefix "Content-") that it does not understand or implement and <em class="bcp14">MUST</em> return a 501 (Not Implemented) response in such cases.
    1058       </p>
    1059       <p id="rfc.section.7.6.p.4">If the request passes through a cache that has one or more stored responses for the Effective Request URI, those stored responses <em class="bcp14">SHOULD</em> be marked as stale if the response to the PUT request has a success status code. Responses to the PUT method are not cacheable.
    1060       </p>
    1061       <p id="rfc.section.7.6.p.5">The fundamental difference between the POST and PUT requests is reflected in the different meaning of the Effective Request
     1057      <p id="rfc.section.7.6.p.3">If the resource identified by the effective request URI could not be created or modified, an appropriate error response <em class="bcp14">SHOULD</em> be given that reflects the nature of the problem. The recipient of the representation <em class="bcp14">MUST NOT</em> ignore any Content-* headers (headers starting with the prefix "Content-") that it does not understand or implement and <em class="bcp14">MUST</em> return a 501 (Not Implemented) response in such cases.
     1058      </p>
     1059      <p id="rfc.section.7.6.p.4">If the request passes through a cache that has one or more stored responses for the effective request URI, those stored responses <em class="bcp14">SHOULD</em> be marked as stale if the response to the PUT request has a success status code. Responses to the PUT method are not cacheable.
     1060      </p>
     1061      <p id="rfc.section.7.6.p.5">The fundamental difference between the POST and PUT requests is reflected in the different meaning of the effective request
    10621062         URI. The URI in a POST request identifies the resource that will handle the enclosed representation. That resource might be
    10631063         a data-accepting process, a gateway to some other protocol, or a document that accepts annotations. In contrast, the URI in
    … …  
    10711071      </p>
    10721072      <p id="rfc.section.7.6.p.7">HTTP/1.1 does not define how a PUT method affects the state of an origin server.</p>
    1073       <p id="rfc.section.7.6.p.8">Unless otherwise specified for a particular entity-header, the entity-headers in the PUT request <em class="bcp14">SHOULD</em> be applied to the resource created or modified by the PUT.
     1073      <p id="rfc.section.7.6.p.8">Header fields in a PUT request that are recognized as representation metadata <em class="bcp14">SHOULD</em> be applied to the resource created or modified by the PUT. Unrecognized header fields <em class="bcp14">SHOULD</em> be ignored.
    10741074      </p>
    10751075      <div id="rfc.iref.d.1"></div>
    10761076      <div id="rfc.iref.m.6"></div>
    10771077      <h2 id="rfc.section.7.7"><a href="#rfc.section.7.7">7.7</a>&nbsp;<a id="DELETE" href="#DELETE">DELETE</a></h2>
    1078       <p id="rfc.section.7.7.p.1">The DELETE method requests that the origin server delete the resource identified by the Effective Request URI. 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
     1078      <p id="rfc.section.7.7.p.1">The DELETE method requests that the origin server delete the resource identified by the effective request URI. 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
    10791079         has been carried out, even if the status code returned from the origin server indicates that the action has been completed
    10801080         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
    … …  
    10841084         enacted, or 204 (No Content) if the action has been enacted but the response does not include a representation.
    10851085      </p>
    1086       <p id="rfc.section.7.7.p.3">If the request passes through a cache and the Effective Request URI identifies one or more currently cached representations,
     1086      <p id="rfc.section.7.7.p.3">If the request passes through a cache and the effective request URI identifies one or more currently cached representations,
    10871087         those entries <em class="bcp14">SHOULD</em> be treated as stale. Responses to the DELETE method are not cacheable.
    10881088      </p>
    … …  
    11431143      <div id="rfc.iref.s.4"></div>
    11441144      <h3 id="rfc.section.8.2.1"><a href="#rfc.section.8.2.1">8.2.1</a>&nbsp;<a id="status.200" href="#status.200">200 OK</a></h3>
    1145       <p id="rfc.section.8.2.1.p.1">The request has succeeded. The information returned with the response is dependent on the method used in the request, for
    1146          example:
    1147       </p>
     1145      <p id="rfc.section.8.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>
    11481146      <dl>
    11491147         <dt>GET</dt>
    1150          <dd>a representation corresponding to the requested resource is sent in the response;</dd>
     1148         <dd>a representation of the resource corresponding to the effective request URI is sent in the response;</dd>
    11511149         <dt>HEAD</dt>
    1152          <dd>the entity-header fields corresponding to the requested resource are sent in the response without any message-body;</dd>
     1150         <dd>the same representation as GET, except without the message-body;</dd>
    11531151         <dt>POST</dt>
    11541152         <dd>a representation describing or containing the result of the action;</dd>
    … …  
    11851183      <div id="rfc.iref.s.7"></div>
    11861184      <h3 id="rfc.section.8.2.4"><a href="#rfc.section.8.2.4">8.2.4</a>&nbsp;<a id="status.203" href="#status.203">203 Non-Authoritative Information</a></h3>
    1187       <p id="rfc.section.8.2.4.p.1">The returned metadata in the entity-header is not the definitive set as available from the origin server, but is gathered
     1185      <p id="rfc.section.8.2.4.p.1">The returned metadata in the header fields is not the definitive set as available from the origin server, but is gathered
    11881186         from a local or a third-party copy. The set presented <em class="bcp14">MAY</em> be a subset or superset of the original version. For example, including local annotation information about the resource might
    11891187         result in a superset of the metadata known by the origin server. Use of this response code is not required and is only appropriate
    … …  
    11961194      <h3 id="rfc.section.8.2.5"><a href="#rfc.section.8.2.5">8.2.5</a>&nbsp;<a id="status.204" href="#status.204">204 No Content</a></h3>
    11971195      <p id="rfc.section.8.2.5.p.1">The server has successfully fulfilled the request, but there is no additional content to return in the response payload body.
    1198          The resource metadata and representation metadata in the response message's header fields refer to the requested resource
    1199          and its current representation, respectively, after the requested action. For example, if a 204 status code is received in
    1200          response to a PUT and the response contains an ETag header field, then the value of that field is the current entity-tag for
    1201          the representation that was successfully PUT to the requested resource.
     1196         The resource metadata and representation metadata in the response message's header fields refer to the target resource and
     1197         its current representation, respectively, after the requested action. For example, if a 204 status code is received in response
     1198         to a PUT and the response contains an ETag header field, then the value of that field is the current entity-tag for the representation
     1199         that was successfully PUT.
    12021200      </p>
    12031201      <p id="rfc.section.8.2.5.p.2">If the client is a user agent, it <em class="bcp14">SHOULD NOT</em> change its document view from that which caused the request to be sent. This response is primarily intended to allow input
    … …  
    12331231      <div id="rfc.iref.s.11"></div>
    12341232      <h3 id="rfc.section.8.3.1"><a href="#rfc.section.8.3.1">8.3.1</a>&nbsp;<a id="status.300" href="#status.300">300 Multiple Choices</a></h3>
    1235       <p id="rfc.section.8.3.1.p.1">The requested resource corresponds to any one of a set of representations, each with its own specific location, and agent-driven
    1236          negotiation information (<a href="p3-payload.html#content.negotiation" title="Content Negotiation">Section 4</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>) is being provided so that the user (or user agent) can select a preferred representation and redirect its request to that
     1233      <p id="rfc.section.8.3.1.p.1">The target resource more than one representation, each with its own specific location, and agent-driven negotiation information
     1234         (<a href="p3-payload.html#content.negotiation" title="Content Negotiation">Section 5</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>) is being provided so that the user (or user agent) can select a preferred representation by redirecting its request to that
    12371235         location.
    12381236      </p>
    1239       <p id="rfc.section.8.3.1.p.2">Unless it was a HEAD request, the response <em class="bcp14">SHOULD</em> include a representation containing a list of resource characteristics and location(s) from which the user or user agent can
     1237      <p id="rfc.section.8.3.1.p.2">Unless it was a HEAD request, the response <em class="bcp14">SHOULD</em> include a representation containing a list of representation metadata and location(s) from which the user or user agent can
    12401238         choose the one most appropriate. The data format is specified by the media type given in the Content-Type header field. Depending
    12411239         upon the format and the capabilities of the user agent, selection of the most appropriate choice <em class="bcp14">MAY</em> be performed automatically. However, this specification does not define any standard for such automatic selection.
    … …  
    12481246      <div id="rfc.iref.s.12"></div>
    12491247      <h3 id="rfc.section.8.3.2"><a href="#rfc.section.8.3.2">8.3.2</a>&nbsp;<a id="status.301" href="#status.301">301 Moved Permanently</a></h3>
    1250       <p id="rfc.section.8.3.2.p.1">The requested 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
    1251          Request URI to one or more of the new references returned by the server, where possible.
     1248      <p id="rfc.section.8.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
     1249         request URI to one or more of the new references returned by the server, where possible.
    12521250      </p>
    12531251      <p id="rfc.section.8.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.13"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) to determine freshness for 301 responses.
    … …  
    12661264      <div id="rfc.iref.s.13"></div>
    12671265      <h3 id="rfc.section.8.3.3"><a href="#rfc.section.8.3.3">8.3.3</a>&nbsp;<a id="status.302" href="#status.302">302 Found</a></h3>
    1268       <p id="rfc.section.8.3.3.p.1">The requested resource resides temporarily under a different URI. Since the redirection might be altered on occasion, the
    1269          client <em class="bcp14">SHOULD</em> continue to use the Effective Request URI for future requests.
     1266      <p id="rfc.section.8.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.
    12701267      </p>
    12711268      <p id="rfc.section.8.3.3.p.2">The temporary URI <em class="bcp14">SHOULD</em> be given by the Location field in the response. Unless the request method was HEAD, the representation of the response <em class="bcp14">SHOULD</em> contain a short hypertext note with a hyperlink to the new URI(s).
    … …  
    12851282      <p id="rfc.section.8.3.4.p.1">The server directs the user agent to a different resource, indicated by a URI in the Location header field, that provides
    12861283         an indirect response to the original request. The user agent <em class="bcp14">MAY</em> perform a GET request on the URI in the Location field in order to obtain a representation corresponding to the response,
    1287          be redirected again, or end with an error status. The Location URI is not a substitute reference for the originally requested
    1288          resource.
     1284         be redirected again, or end with an error status. The Location URI is not a substitute reference for the effective request
     1285         URI.
    12891286      </p>
    12901287      <p id="rfc.section.8.3.4.p.2">The 303 status code is generally applicable to any HTTP method. It is primarily used to allow the output of a POST action
    … …  
    12931290      </p>
    12941291      <p id="rfc.section.8.3.4.p.3">A 303 response to a GET request indicates that the requested resource does not have a representation of its own that can be
    1295          transferred by the server over HTTP. The Location URI indicates a resource that is descriptive of the requested resource such
    1296          that the follow-on representation might be useful without implying that it adequately represents the previously requested
     1292         transferred by the server over HTTP. The Location URI indicates a resource that is descriptive of the target resource, such
     1293         that the follow-on representation might be useful to recipients without implying that it adequately represents the target
    12971294         resource. Note that answers to the questions of what can be represented, what representations are adequate, and what might
    12981295         be a useful description are outside the scope of HTTP and thus entirely determined by the URI owner(s).
    … …  
    13181315      <div id="rfc.iref.s.18"></div>
    13191316      <h3 id="rfc.section.8.3.8"><a href="#rfc.section.8.3.8">8.3.8</a>&nbsp;<a id="status.307" href="#status.307">307 Temporary Redirect</a></h3>
    1320       <p id="rfc.section.8.3.8.p.1">The requested 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.
     1317      <p id="rfc.section.8.3.8.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.
    13211318      </p>
    13221319      <p id="rfc.section.8.3.8.p.2">The temporary URI <em class="bcp14">SHOULD</em> be given by the Location field in the response. Unless the request method was HEAD, the representation of the response <em class="bcp14">SHOULD</em> contain a short hypertext note with a hyperlink to the new URI(s) , since many pre-HTTP/1.1 user agents do not understand
    … …  
    13601357      <div id="rfc.iref.s.23"></div>
    13611358      <h3 id="rfc.section.8.4.5"><a href="#rfc.section.8.4.5">8.4.5</a>&nbsp;<a id="status.404" href="#status.404">404 Not Found</a></h3>
    1362       <p id="rfc.section.8.4.5.p.1">The server has not found anything matching the Effective Request URI. No indication is given of whether the condition is temporary
     1359      <p id="rfc.section.8.4.5.p.1">The server has not found anything matching the effective request URI. No indication is given of whether the condition is temporary
    13631360         or permanent. The 410 (Gone) status code <em class="bcp14">SHOULD</em> be used if the server knows, through some internally configurable mechanism, that an old resource is permanently unavailable
    13641361         and has no forwarding address. This status code is commonly used when the server does not wish to reveal exactly why the request
    … …  
    13681365      <div id="rfc.iref.s.24"></div>
    13691366      <h3 id="rfc.section.8.4.6"><a href="#rfc.section.8.4.6">8.4.6</a>&nbsp;<a id="status.405" href="#status.405">405 Method Not Allowed</a></h3>
    1370       <p id="rfc.section.8.4.6.p.1">The method specified in the Request-Line is not allowed for the resource identified by the Effective Request URI. The response <em class="bcp14">MUST</em> include an Allow header containing a list of valid methods for the requested resource.
     1367      <p id="rfc.section.8.4.6.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 containing a list of valid methods for the requested resource.
    13711368      </p>
    13721369      <div id="rfc.iref.48"></div>
    … …  
    14141411      <div id="rfc.iref.s.29"></div>
    14151412      <h3 id="rfc.section.8.4.11"><a href="#rfc.section.8.4.11">8.4.11</a>&nbsp;<a id="status.410" href="#status.410">410 Gone</a></h3>
    1416       <p id="rfc.section.8.4.11.p.1">The requested resource is no longer available at the server and no forwarding address is known. This condition is expected
    1417          to be considered permanent. Clients with link editing capabilities <em class="bcp14">SHOULD</em> delete references to the Effective Request URI after user approval. If the server does not know, or has no facility to determine,
     1413      <p id="rfc.section.8.4.11.p.1">The target resource is no longer available at the server and no forwarding address is known. This condition is expected to
     1414         be considered permanent. Clients with link editing capabilities <em class="bcp14">SHOULD</em> delete references to the effective request URI after user approval. If the server does not know, or has no facility to determine,
    14181415         whether or not the condition is permanent, the status code 404 (Not Found) <em class="bcp14">SHOULD</em> be used instead.
    14191416      </p>
    … …  
    14491446      <div id="rfc.iref.s.33"></div>
    14501447      <h3 id="rfc.section.8.4.15"><a href="#rfc.section.8.4.15">8.4.15</a>&nbsp;<a id="status.414" href="#status.414">414 URI Too Long</a></h3>
    1451       <p id="rfc.section.8.4.15.p.1">The server is refusing to service the request because the Effective Request URI is longer than the server is willing to interpret.
     1448      <p id="rfc.section.8.4.15.p.1">The server is refusing to service the request because the effective request URI is longer than the server is willing to interpret.
    14521449         This rare condition is only likely to occur when a client has improperly converted a POST request to a GET request with long
    14531450         query information, when the client has descended into a URI "black hole" of redirection (e.g., a redirected URI prefix that
    14541451         points to a suffix of itself), or when the server is under attack by a client attempting to exploit security holes present
    1455          in some servers using fixed-length buffers for reading or manipulating the Effective Request URI.
     1452         in some servers using fixed-length buffers for reading or manipulating the effective request URI.
    14561453      </p>
    14571454      <div id="rfc.iref.57"></div>
    … …  
    14591456      <h3 id="rfc.section.8.4.16"><a href="#rfc.section.8.4.16">8.4.16</a>&nbsp;<a id="status.415" href="#status.415">415 Unsupported Media Type</a></h3>
    14601457      <p id="rfc.section.8.4.16.p.1">The server is refusing to service the request because the representation of the request is in a format not supported by the
    1461          requested resource for the requested method.
     1458         target resource for the requested method.
    14621459      </p>
    14631460      <div id="rfc.iref.58"></div>
    … …  
    15231520      <h1 id="rfc.section.9"><a href="#rfc.section.9">9.</a>&nbsp;<a id="header.fields" href="#header.fields">Header Field Definitions</a></h1>
    15241521      <p id="rfc.section.9.p.1">This section defines the syntax and semantics of HTTP/1.1 header fields related to request and response semantics.</p>
    1525       <p id="rfc.section.9.p.2">For entity-header fields, both sender and recipient refer to either the client or the server, depending on who sends and who
    1526          receives the message.
    1527       </p>
    15281522      <div id="rfc.iref.a.1"></div>
    15291523      <div id="rfc.iref.h.2"></div>
    15301524      <h2 id="rfc.section.9.1"><a href="#rfc.section.9.1">9.1</a>&nbsp;<a id="header.allow" href="#header.allow">Allow</a></h2>
    1531       <p id="rfc.section.9.1.p.1">The "Allow" response-header field lists the set of methods advertised as supported by the resource identified by the Effective
    1532          Request URI. The purpose of this field is strictly to inform the recipient of valid methods associated with the resource.
     1525      <p id="rfc.section.9.1.p.1">The "Allow" response-header field lists the set of methods advertised as supported by the target resource. The purpose of
     1526         this field is strictly to inform the recipient of valid methods associated with the resource.
    15331527      </p>
    15341528      <div id="rfc.figure.u.12"></div><pre class="inline"><span id="rfc.iref.g.9"></span><span id="rfc.iref.g.10"></span>  <a href="#header.allow" class="smpl">Allow</a>   = "Allow" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.allow" class="smpl">Allow-v</a>
    … …  
    16151609      </div>
    16161610      <div class="note" id="rfc.section.9.4.p.9">
    1617          <p> <b>Note:</b> The Content-Location header field (<a href="p3-payload.html#header.content-location" title="Content-Location">Section 5.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>) differs from Location in that the Content-Location identifies the most specific resource corresponding to the enclosed representation.
     1611         <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.12"><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.
    16181612            It is therefore possible for a response to contain header fields for both Location and Content-Location.
    16191613         </p>
    … …  
    16361630      <div id="rfc.iref.h.7"></div>
    16371631      <h2 id="rfc.section.9.6"><a href="#rfc.section.9.6">9.6</a>&nbsp;<a id="header.referer" href="#header.referer">Referer</a></h2>
    1638       <p id="rfc.section.9.6.p.1">The "Referer" [sic] request-header field allows the client to specify the URI of the resource from which the Effective Request
     1632      <p id="rfc.section.9.6.p.1">The "Referer" [sic] request-header field allows the client to specify the URI of the resource from which the effective request
    16391633         URI was obtained (the "referrer", although the header field is misspelled.).
    16401634      </p>
    … …  
    16441638         contain a Referer header field.
    16451639      </p>
    1646       <p id="rfc.section.9.6.p.3">If the Effective Request URI was obtained from a source that does not have its own URI (e.g., input from the user keyboard),
     1640      <p id="rfc.section.9.6.p.3">If the effective request URI was obtained from a source that does not have its own URI (e.g., input from the user keyboard),
    16471641         the Referer 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
    16481642         non-HTTP URIs (e.g., FTP).
    … …  
    16521646</pre><p id="rfc.section.9.6.p.5">Example:</p>
    16531647      <div id="rfc.figure.u.22"></div><pre class="text">  Referer: http://www.example.org/hypertext/Overview.html
    1654 </pre><p id="rfc.section.9.6.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;11.2</a> for security considerations.
     1648</pre><p id="rfc.section.9.6.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;11.2</a> for security considerations.
    16551649      </p>
    16561650      <div id="rfc.iref.r.2"></div>
    … …  
    22592253         user agent is able to make that determination based on the request method semantics. (Sections <a href="#status.301" id="rfc.xref.status.301.3" title="301 Moved Permanently">8.3.2</a>, <a href="#status.302" id="rfc.xref.status.302.3" title="302 Found">8.3.3</a> and <a href="#status.307" id="rfc.xref.status.307.4" title="307 Temporary Redirect">8.3.8</a>)
    22602254      </p>
    2261       <p id="rfc.section.A.p.4">Deprecate 305 Use Proxy status code, because user agents did not implement it. It used to indicate that the requested resource
     2255      <p id="rfc.section.A.p.4">Deprecate 305 Use Proxy status code, because user agents did not implement it. It used to indicate that the target resource
    22622256         must be accessed through the proxy given by the Location field. The Location field gave the URI of the proxy. The recipient
    22632257         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;8.3.6</a>)
    … …  
    27592753                  </li>
    27602754                  <li class="indline1"><em>Part3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.1">1.2.2</a>, <a class="iref" href="#rfc.xref.Part3.2">1.2.2</a>, <a class="iref" href="#rfc.xref.Part3.3">1.2.2</a>, <a class="iref" href="#rfc.xref.Part3.4">1.2.2</a>, <a class="iref" href="#rfc.xref.Part3.5">3</a>, <a class="iref" href="#rfc.xref.Part3.6">3</a>, <a class="iref" href="#rfc.xref.Part3.7">3</a>, <a class="iref" href="#rfc.xref.Part3.8">3</a>, <a class="iref" href="#rfc.xref.Part3.9">6</a>, <a class="iref" href="#rfc.xref.Part3.10">7.5</a>, <a class="iref" href="#rfc.xref.Part3.11">8.3.1</a>, <a class="iref" href="#rfc.xref.Part3.12">9.4</a>, <a class="iref" href="#Part3"><b>13.1</b></a><ul class="ind">
    2761                         <li class="indline1"><em>Section 4</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.11">8.3.1</a></li>
    2762                         <li class="indline1"><em>Section 5.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.1">1.2.2</a>, <a class="iref" href="#rfc.xref.Part3.5">3</a></li>
    2763                         <li class="indline1"><em>Section 5.2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.2">1.2.2</a>, <a class="iref" href="#rfc.xref.Part3.6">3</a></li>
    2764                         <li class="indline1"><em>Section 5.3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.3">1.2.2</a>, <a class="iref" href="#rfc.xref.Part3.7">3</a></li>
    2765                         <li class="indline1"><em>Section 5.4</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.4">1.2.2</a>, <a class="iref" href="#rfc.xref.Part3.8">3</a></li>
    2766                         <li class="indline1"><em>Section 5.7</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.10">7.5</a>, <a class="iref" href="#rfc.xref.Part3.12">9.4</a></li>
     2755                        <li class="indline1"><em>Section 5</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.11">8.3.1</a></li>
     2756                        <li class="indline1"><em>Section 6.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.1">1.2.2</a>, <a class="iref" href="#rfc.xref.Part3.5">3</a></li>
     2757                        <li class="indline1"><em>Section 6.2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.2">1.2.2</a>, <a class="iref" href="#rfc.xref.Part3.6">3</a></li>
     2758                        <li class="indline1"><em>Section 6.3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.3">1.2.2</a>, <a class="iref" href="#rfc.xref.Part3.7">3</a></li>
     2759                        <li class="indline1"><em>Section 6.4</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.4">1.2.2</a>, <a class="iref" href="#rfc.xref.Part3.8">3</a></li>
     2760                        <li class="indline1"><em>Section 6.7</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.10">7.5</a>, <a class="iref" href="#rfc.xref.Part3.12">9.4</a></li>
    27672761                     </ul>
    27682762                  </li>
Note: See TracChangeset for help on using the changeset viewer.