Changeset 2561 for draft-ietf-httpbis


Ignore:
Timestamp:
19/01/14 02:53:35 (6 years ago)
Author:
fielding@…
Message:

(editorial) add section xrefs where the common method names are first used; see #531

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

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpbis/latest/p1-messaging.html

    r2557 r2561  
    448448  }
    449449  @bottom-center {
    450        content: "Expires July 21, 2014";
     450       content: "Expires July 22, 2014";
    451451  }
    452452  @bottom-right {
     
    490490      <meta name="dct.creator" content="Reschke, J. F.">
    491491      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p1-messaging-latest">
    492       <meta name="dct.issued" scheme="ISO8601" content="2014-01-17">
     492      <meta name="dct.issued" scheme="ISO8601" content="2014-01-18">
    493493      <meta name="dct.replaces" content="urn:ietf:rfc:2145">
    494494      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
     
    519519            <tr>
    520520               <td class="left">Intended status: Standards Track</td>
    521                <td class="right">January 17, 2014</td>
     521               <td class="right">January 18, 2014</td>
    522522            </tr>
    523523            <tr>
    524                <td class="left">Expires: July 21, 2014</td>
     524               <td class="left">Expires: July 22, 2014</td>
    525525               <td class="right"></td>
    526526            </tr>
     
    551551            in progress”.
    552552         </p>
    553          <p>This Internet-Draft will expire on July 21, 2014.</p>
     553         <p>This Internet-Draft will expire on July 22, 2014.</p>
    554554      </div>
    555555      <div id="rfc.copyrightnotice">
     
    837837            <p id="rfc.section.2.1.p.8">A connection might be used for multiple request/response exchanges, as defined in <a href="#persistent.connections" title="Persistence">Section&nbsp;6.3</a>.
    838838            </p>
    839             <p id="rfc.section.2.1.p.9">The following example illustrates a typical message exchange for a GET request on the URI "http://www.example.com/hello.txt":</p>
     839            <p id="rfc.section.2.1.p.9">The following example illustrates a typical message exchange for a GET request (<a href="p2-semantics.html#GET" title="GET">Section 4.3.1</a> of <a href="#Part2" id="rfc.xref.Part2.3"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>) on the URI "http://www.example.com/hello.txt":
     840            </p>
    840841            <div id="rfc.figure.u.2"></div>
    841842            <p>Client request:</p><pre class="text2">GET /hello.txt HTTP/1.1
     
    911912               or an intranet-to-Internet privacy filter. Such transformations are presumed to be desired by the client (or client organization)
    912913               that selected the proxy and are beyond the scope of this specification. However, when a proxy is not intended to transform
    913                a given message, we use the term "<dfn>non-transforming proxy</dfn>" to target requirements that preserve HTTP message semantics. See <a href="p2-semantics.html#status.203" title="203 Non-Authoritative Information">Section 6.3.4</a> of <a href="#Part2" id="rfc.xref.Part2.3"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a> and <a href="p6-cache.html#header.warning" title="Warning">Section 5.5</a> of <a href="#Part6" id="rfc.xref.Part6.2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a> for status and warning codes related to transformations.
     914               a given message, we use the term "<dfn>non-transforming proxy</dfn>" to target requirements that preserve HTTP message semantics. See <a href="p2-semantics.html#status.203" title="203 Non-Authoritative Information">Section 6.3.4</a> of <a href="#Part2" id="rfc.xref.Part2.4"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a> and <a href="p6-cache.html#header.warning" title="Warning">Section 5.5</a> of <a href="#Part6" id="rfc.xref.Part6.2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a> for status and warning codes related to transformations.
    914915            </p>
    915916            <p id="rfc.section.2.3.p.7"><span id="rfc.iref.g.13"></span><span id="rfc.iref.r.4"></span> <span id="rfc.iref.a.1"></span> A "<dfn>gateway</dfn>" (a.k.a., "<dfn>reverse proxy</dfn>") is an intermediary that acts as an origin server for the outbound connection, but translates received requests and forwards
     
    10701071            <div id="rfc.iref.r.5"></div>
    10711072            <h2 id="rfc.section.2.7"><a href="#rfc.section.2.7">2.7</a>&nbsp;<a href="#uri">Uniform Resource Identifiers</a></h2>
    1072             <p id="rfc.section.2.7.p.1">Uniform Resource Identifiers (URIs) <a href="#RFC3986" id="rfc.xref.RFC3986.2"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a> are used throughout HTTP as the means for identifying resources (<a href="p2-semantics.html#resources" title="Resources">Section 2</a> of <a href="#Part2" id="rfc.xref.Part2.4"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). URI references are used to target requests, indicate redirects, and define relationships.
     1073            <p id="rfc.section.2.7.p.1">Uniform Resource Identifiers (URIs) <a href="#RFC3986" id="rfc.xref.RFC3986.2"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a> are used throughout HTTP as the means for identifying resources (<a href="p2-semantics.html#resources" title="Resources">Section 2</a> of <a href="#Part2" id="rfc.xref.Part2.5"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). URI references are used to target requests, indicate redirects, and define relationships.
    10731074            </p>
    10741075            <p id="rfc.section.2.7.p.2">This specification adopts the definitions of "URI-reference", "absolute-URI", "relative-part", "authority", "port", "host",
     
    11211122               </p>
    11221123               <p id="rfc.section.2.7.1.p.7">When an "http" URI is used within a context that calls for access to the indicated resource, a client <em class="bcp14">MAY</em> attempt access by resolving the host to an IP address, establishing a TCP connection to that address on the indicated port,
    1123                   and sending an HTTP request message (<a href="#http.message" title="Message Format">Section&nbsp;3</a>) containing the URI's identifying data (<a href="#message.routing" title="Message Routing">Section&nbsp;5</a>) to the server. If the server responds to that request with a non-interim HTTP response message, as described in <a href="p2-semantics.html#status.codes" title="Response Status Codes">Section 6</a> of <a href="#Part2" id="rfc.xref.Part2.5"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>, then that response is considered an authoritative answer to the client's request.
     1124                  and sending an HTTP request message (<a href="#http.message" title="Message Format">Section&nbsp;3</a>) containing the URI's identifying data (<a href="#message.routing" title="Message Routing">Section&nbsp;5</a>) to the server. If the server responds to that request with a non-interim HTTP response message, as described in <a href="p2-semantics.html#status.codes" title="Response Status Codes">Section 6</a> of <a href="#Part2" id="rfc.xref.Part2.6"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>, then that response is considered an authoritative answer to the client's request.
    11241125               </p>
    11251126               <p id="rfc.section.2.7.1.p.8">Although HTTP is independent of the transport protocol, the "http" scheme is specific to TCP-based services because the name
     
    12351236               </div>
    12361237               <div id="rfc.figure.u.14"></div><pre class="inline"><span id="rfc.iref.g.31"></span>  <a href="#method" class="smpl">method</a>         = <a href="#rule.token.separators" class="smpl">token</a>
    1237 </pre><p id="rfc.section.3.1.1.p.5">The request methods defined by this specification can be found in <a href="p2-semantics.html#methods" title="Request Methods">Section 4</a> of <a href="#Part2" id="rfc.xref.Part2.6"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>, along with information regarding the HTTP method registry and considerations for defining new methods.
     1238</pre><p id="rfc.section.3.1.1.p.5">The request methods defined by this specification can be found in <a href="p2-semantics.html#methods" title="Request Methods">Section 4</a> of <a href="#Part2" id="rfc.xref.Part2.7"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>, along with information regarding the HTTP method registry and considerations for defining new methods.
    12381239               </p>
    12391240               <div id="rfc.iref.r.6"></div>
     
    12471248               </p>
    12481249               <p id="rfc.section.3.1.1.p.9">HTTP does not place a pre-defined limit on the length of a request-line. A server that receives a method longer than any that
    1249                   it implements <em class="bcp14">SHOULD</em> respond with a <a href="p2-semantics.html#status.501" class="smpl">501 (Not Implemented)</a> status code. A server ought to be prepared to receive URIs of unbounded length, as described in <a href="#conformance" title="Conformance and Error Handling">Section&nbsp;2.5</a>, and <em class="bcp14">MUST</em> respond with a <a href="p2-semantics.html#status.414" class="smpl">414 (URI Too Long)</a> status code if the received request-target is longer than the server wishes to parse (see <a href="p2-semantics.html#status.414" title="414 URI Too Long">Section 6.5.12</a> of <a href="#Part2" id="rfc.xref.Part2.7"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>).
     1250                  it implements <em class="bcp14">SHOULD</em> respond with a <a href="p2-semantics.html#status.501" class="smpl">501 (Not Implemented)</a> status code. A server ought to be prepared to receive URIs of unbounded length, as described in <a href="#conformance" title="Conformance and Error Handling">Section&nbsp;2.5</a>, and <em class="bcp14">MUST</em> respond with a <a href="p2-semantics.html#status.414" class="smpl">414 (URI Too Long)</a> status code if the received request-target is longer than the server wishes to parse (see <a href="p2-semantics.html#status.414" title="414 URI Too Long">Section 6.5.12</a> of <a href="#Part2" id="rfc.xref.Part2.8"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>).
    12501251               </p>
    12511252               <p id="rfc.section.3.1.1.p.10">Various ad-hoc limitations on request-line length are found in practice. It is <em class="bcp14">RECOMMENDED</em> that all HTTP senders and recipients support, at a minimum, request-line lengths of 8000 octets.
     
    12601261</pre><p id="rfc.section.3.1.2.p.3">The status-code element is a 3-digit integer code describing the result of the server's attempt to understand and satisfy
    12611262                  the client's corresponding request. The rest of the response message is to be interpreted in light of the semantics defined
    1262                   for that status code. See <a href="p2-semantics.html#status.codes" title="Response Status Codes">Section 6</a> of <a href="#Part2" id="rfc.xref.Part2.8"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a> for information about the semantics of status codes, including the classes of status code (indicated by the first digit),
     1263                  for that status code. See <a href="p2-semantics.html#status.codes" title="Response Status Codes">Section 6</a> of <a href="#Part2" id="rfc.xref.Part2.9"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a> for information about the semantics of status codes, including the classes of status code (indicated by the first digit),
    12631264                  the status codes defined by this specification, considerations for the definition of new status codes, and the IANA registry.
    12641265               </p>
     
    12841285                 ; see <a href="#field.parsing" title="Field Parsing">Section&nbsp;3.2.4</a>
    12851286</pre><p id="rfc.section.3.2.p.3">The field-name token labels the corresponding field-value as having the semantics defined by that header field. For example,
    1286                the <a href="p2-semantics.html#header.date" class="smpl">Date</a> header field is defined in <a href="p2-semantics.html#header.date" title="Date">Section 7.1.1.2</a> of <a href="#Part2" id="rfc.xref.Part2.9"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a> as containing the origination timestamp for the message in which it appears.
     1287               the <a href="p2-semantics.html#header.date" class="smpl">Date</a> header field is defined in <a href="p2-semantics.html#header.date" title="Date">Section 7.1.1.2</a> of <a href="#Part2" id="rfc.xref.Part2.10"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a> as containing the origination timestamp for the message in which it appears.
    12871288            </p>
    12881289            <div id="field.extensibility">
     
    12981299                  of deployed intermediaries.
    12991300               </p>
    1300                <p id="rfc.section.3.2.1.p.4">All defined header fields ought to be registered with IANA in the Message Header Field Registry, as described in <a href="p2-semantics.html#header.field.registry" title="Header Field Registry">Section 8.3</a> of <a href="#Part2" id="rfc.xref.Part2.10"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>.
     1301               <p id="rfc.section.3.2.1.p.4">All defined header fields ought to be registered with IANA in the Message Header Field Registry, as described in <a href="p2-semantics.html#header.field.registry" title="Header Field Registry">Section 8.3</a> of <a href="#Part2" id="rfc.xref.Part2.11"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>.
    13011302               </p>
    13021303            </div>
     
    14461447            </p>
    14471448            <p id="rfc.section.3.3.p.5">The presence of a message body in a response depends on both the request method to which it is responding and the response
    1448                status code (<a href="#status.line" title="Status Line">Section&nbsp;3.1.2</a>). Responses to the HEAD request method never include a message body because the associated response header fields (e.g., <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a>, <a href="#header.content-length" class="smpl">Content-Length</a>, etc.), if present, indicate only what their values would have been if the request method had been GET (<a href="p2-semantics.html#HEAD" title="HEAD">Section 4.3.2</a> of <a href="#Part2" id="rfc.xref.Part2.11"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). <a href="p2-semantics.html#status.2xx" class="smpl">2xx (Successful)</a> responses to CONNECT switch to tunnel mode instead of having a message body (<a href="p2-semantics.html#CONNECT" title="CONNECT">Section 4.3.6</a> of <a href="#Part2" id="rfc.xref.Part2.12"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). All <a href="p2-semantics.html#status.1xx" class="smpl">1xx (Informational)</a>, <a href="p2-semantics.html#status.204" class="smpl">204 (No Content)</a>, and <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a> responses do not include a message body. All other responses do include a message body, although the body might be of zero
     1449               status code (<a href="#status.line" title="Status Line">Section&nbsp;3.1.2</a>). Responses to the HEAD request method (<a href="p2-semantics.html#HEAD" title="HEAD">Section 4.3.2</a> of <a href="#Part2" id="rfc.xref.Part2.12"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>) never include a message body because the associated response header fields (e.g., <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a>, <a href="#header.content-length" class="smpl">Content-Length</a>, etc.), if present, indicate only what their values would have been if the request method had been GET (<a href="p2-semantics.html#GET" title="GET">Section 4.3.1</a> of <a href="#Part2" id="rfc.xref.Part2.13"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). <a href="p2-semantics.html#status.2xx" class="smpl">2xx (Successful)</a> responses to a CONNECT request method (<a href="p2-semantics.html#CONNECT" title="CONNECT">Section 4.3.6</a> of <a href="#Part2" id="rfc.xref.Part2.14"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>) switch to tunnel mode instead of having a message body. All <a href="p2-semantics.html#status.1xx" class="smpl">1xx (Informational)</a>, <a href="p2-semantics.html#status.204" class="smpl">204 (No Content)</a>, and <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a> responses do not include a message body. All other responses do include a message body, although the body might be of zero
    14491450               length.
    14501451            </p>
     
    14711472                  forming the message body.
    14721473               </p>
    1473                <p id="rfc.section.3.3.1.p.6">Unlike <a href="p2-semantics.html#header.content-encoding" class="smpl">Content-Encoding</a> (<a href="p2-semantics.html#content.codings" title="Content Codings">Section 3.1.2.1</a> of <a href="#Part2" id="rfc.xref.Part2.13"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>), Transfer-Encoding is a property of the message, not of the representation, and any recipient along the request/response
     1474               <p id="rfc.section.3.3.1.p.6">Unlike <a href="p2-semantics.html#header.content-encoding" class="smpl">Content-Encoding</a> (<a href="p2-semantics.html#content.codings" title="Content Codings">Section 3.1.2.1</a> of <a href="#Part2" id="rfc.xref.Part2.15"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>), Transfer-Encoding is a property of the message, not of the representation, and any recipient along the request/response
    14741475                  chain <em class="bcp14">MAY</em> decode the received transfer coding(s) or apply additional transfer coding(s) to the message body, assuming that corresponding
    14751476                  changes are made to the Transfer-Encoding field-value. Additional information about the encoding parameters <em class="bcp14">MAY</em> be provided by other header fields not defined by this specification.
     
    14791480                  any recipient on the response chain (including the origin server) can remove transfer codings when they are not needed.
    14801481               </p>
    1481                <p id="rfc.section.3.3.1.p.8">A server <em class="bcp14">MUST NOT</em> send a Transfer-Encoding header field in any response with a status code of <a href="p2-semantics.html#status.1xx" class="smpl">1xx (Informational)</a> or <a href="p2-semantics.html#status.204" class="smpl">204 (No Content)</a>. A server <em class="bcp14">MUST NOT</em> send a Transfer-Encoding header field in any <a href="p2-semantics.html#status.2xx" class="smpl">2xx (Successful)</a> response to a CONNECT request (<a href="p2-semantics.html#CONNECT" title="CONNECT">Section 4.3.6</a> of <a href="#Part2" id="rfc.xref.Part2.14"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>).
     1482               <p id="rfc.section.3.3.1.p.8">A server <em class="bcp14">MUST NOT</em> send a Transfer-Encoding header field in any response with a status code of <a href="p2-semantics.html#status.1xx" class="smpl">1xx (Informational)</a> or <a href="p2-semantics.html#status.204" class="smpl">204 (No Content)</a>. A server <em class="bcp14">MUST NOT</em> send a Transfer-Encoding header field in any <a href="p2-semantics.html#status.2xx" class="smpl">2xx (Successful)</a> response to a CONNECT request (<a href="p2-semantics.html#CONNECT" title="CONNECT">Section 4.3.6</a> of <a href="#Part2" id="rfc.xref.Part2.16"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>).
    14821483               </p>
    14831484               <p id="rfc.section.3.3.1.p.9">Transfer-Encoding was added in HTTP/1.1. It is generally assumed that implementations advertising only HTTP/1.0 support will
     
    14941495                  payload body. For messages that do include a payload body, the Content-Length field-value provides the framing information
    14951496                  necessary for determining where the body (and message) ends. For messages that do not include a payload body, the Content-Length
    1496                   indicates the size of the selected representation (<a href="p2-semantics.html#representations" title="Representations">Section 3</a> of <a href="#Part2" id="rfc.xref.Part2.15"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>).
     1497                  indicates the size of the selected representation (<a href="p2-semantics.html#representations" title="Representations">Section 3</a> of <a href="#Part2" id="rfc.xref.Part2.17"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>).
    14971498               </p>
    14981499               <div id="rfc.figure.u.27"></div><pre class="inline"><span id="rfc.iref.g.53"></span>  <a href="#header.content-length" class="smpl">Content-Length</a> = 1*<a href="#core.rules" class="smpl">DIGIT</a>
     
    15051506                  anticipate such a body.
    15061507               </p>
    1507                <p id="rfc.section.3.3.2.p.7">A server <em class="bcp14">MAY</em> send a Content-Length header field in a response to a HEAD request (<a href="p2-semantics.html#HEAD" title="HEAD">Section 4.3.2</a> of <a href="#Part2" id="rfc.xref.Part2.16"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>); a server <em class="bcp14">MUST NOT</em> send Content-Length in such a response unless its field-value equals the decimal number of octets that would have been sent
     1508               <p id="rfc.section.3.3.2.p.7">A server <em class="bcp14">MAY</em> send a Content-Length header field in a response to a HEAD request (<a href="p2-semantics.html#HEAD" title="HEAD">Section 4.3.2</a> of <a href="#Part2" id="rfc.xref.Part2.18"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>); a server <em class="bcp14">MUST NOT</em> send Content-Length in such a response unless its field-value equals the decimal number of octets that would have been sent
    15081509                  in the payload body of a response if the same request had used the GET method.
    15091510               </p>
     
    15111512                  in the payload body of a <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> response to the same request.
    15121513               </p>
    1513                <p id="rfc.section.3.3.2.p.9">A server <em class="bcp14">MUST NOT</em> send a Content-Length header field in any response with a status code of <a href="p2-semantics.html#status.1xx" class="smpl">1xx (Informational)</a> or <a href="p2-semantics.html#status.204" class="smpl">204 (No Content)</a>. A server <em class="bcp14">MUST NOT</em> send a Content-Length header field in any <a href="p2-semantics.html#status.2xx" class="smpl">2xx (Successful)</a> response to a CONNECT request (<a href="p2-semantics.html#CONNECT" title="CONNECT">Section 4.3.6</a> of <a href="#Part2" id="rfc.xref.Part2.17"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>).
     1514               <p id="rfc.section.3.3.2.p.9">A server <em class="bcp14">MUST NOT</em> send a Content-Length header field in any response with a status code of <a href="p2-semantics.html#status.1xx" class="smpl">1xx (Informational)</a> or <a href="p2-semantics.html#status.204" class="smpl">204 (No Content)</a>. A server <em class="bcp14">MUST NOT</em> send a Content-Length header field in any <a href="p2-semantics.html#status.2xx" class="smpl">2xx (Successful)</a> response to a CONNECT request (<a href="p2-semantics.html#CONNECT" title="CONNECT">Section 4.3.6</a> of <a href="#Part2" id="rfc.xref.Part2.19"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>).
    15141515               </p>
    15151516               <p id="rfc.section.3.3.2.p.10">Aside from the cases defined above, in the absence of Transfer-Encoding, an origin server <em class="bcp14">SHOULD</em> send a Content-Length header field when the payload body size is known prior to sending the complete header section. This
     
    18001801            </p>
    18011802            <p id="rfc.section.4.3.p.7">When multiple transfer codings are acceptable, the client <em class="bcp14">MAY</em> rank the codings by preference using a case-insensitive "q" parameter (similar to the qvalues used in content negotiation
    1802                fields, <a href="p2-semantics.html#quality.values" title="Quality Values">Section 5.3.1</a> of <a href="#Part2" id="rfc.xref.Part2.18"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). The rank value is a real number in the range 0 through 1, where 0.001 is the least preferred and 1 is the most preferred;
     1803               fields, <a href="p2-semantics.html#quality.values" title="Quality Values">Section 5.3.1</a> of <a href="#Part2" id="rfc.xref.Part2.20"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). The rank value is a real number in the range 0 through 1, where 0.001 is the least preferred and 1 is the most preferred;
    18031804               a value of 0 means "not acceptable".
    18041805            </p>
     
    18351836            </p>
    18361837            <p id="rfc.section.5.1.p.2">HTTP communication is initiated by a user agent for some purpose. The purpose is a combination of request semantics, which
    1837                are defined in <a href="#Part2" id="rfc.xref.Part2.19"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>, and a target resource upon which to apply those semantics. A URI reference (<a href="#uri" title="Uniform Resource Identifiers">Section&nbsp;2.7</a>) is typically used as an identifier for the "<dfn>target resource</dfn>", which a user agent would resolve to its absolute form in order to obtain the "<dfn>target URI</dfn>". The target URI excludes the reference's fragment component, if any, since fragment identifiers are reserved for client-side
     1838               are defined in <a href="#Part2" id="rfc.xref.Part2.21"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>, and a target resource upon which to apply those semantics. A URI reference (<a href="#uri" title="Uniform Resource Identifiers">Section&nbsp;2.7</a>) is typically used as an identifier for the "<dfn>target resource</dfn>", which a user agent would resolve to its absolute form in order to obtain the "<dfn>target URI</dfn>". The target URI excludes the reference's fragment component, if any, since fragment identifiers are reserved for client-side
    18381839               processing (<a href="#RFC3986" id="rfc.xref.RFC3986.19"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-3.5">Section 3.5</a>).
    18391840            </p>
     
    19051906               </p>
    19061907            </div>
    1907             <p id="rfc.section.5.3.p.16">The <dfn>authority-form</dfn> of request-target is only used for CONNECT requests (<a href="p2-semantics.html#CONNECT" title="CONNECT">Section 4.3.6</a> of <a href="#Part2" id="rfc.xref.Part2.20"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). When making a CONNECT request to establish a tunnel through one or more proxies, a client <em class="bcp14">MUST</em> send only the target URI's authority component (excluding any userinfo and its "@" delimiter) as the request-target. For example,
     1908            <p id="rfc.section.5.3.p.16">The <dfn>authority-form</dfn> of request-target is only used for CONNECT requests (<a href="p2-semantics.html#CONNECT" title="CONNECT">Section 4.3.6</a> of <a href="#Part2" id="rfc.xref.Part2.22"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). When making a CONNECT request to establish a tunnel through one or more proxies, a client <em class="bcp14">MUST</em> send only the target URI's authority component (excluding any userinfo and its "@" delimiter) as the request-target. For example,
    19081909            </p>
    19091910            <div id="rfc.figure.u.42"></div><pre class="text2">CONNECT www.example.com:80 HTTP/1.1
     
    19121913               </p>
    19131914            </div>
    1914             <p id="rfc.section.5.3.p.19">The <dfn>asterisk-form</dfn> of request-target is only used for a server-wide OPTIONS request (<a href="p2-semantics.html#OPTIONS" title="OPTIONS">Section 4.3.7</a> of <a href="#Part2" id="rfc.xref.Part2.21"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). When a client wishes to request OPTIONS for the server as a whole, as opposed to a specific named resource of that server,
     1915            <p id="rfc.section.5.3.p.19">The <dfn>asterisk-form</dfn> of request-target is only used for a server-wide OPTIONS request (<a href="p2-semantics.html#OPTIONS" title="OPTIONS">Section 4.3.7</a> of <a href="#Part2" id="rfc.xref.Part2.23"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). When a client wishes to request OPTIONS for the server as a whole, as opposed to a specific named resource of that server,
    19151916               the client <em class="bcp14">MUST</em> send only "*" (%x2A) as the request-target. For example,
    19161917            </p>
     
    20002001            <p id="rfc.section.5.6.p.1">HTTP does not include a request identifier for associating a given request message with its corresponding one or more response
    20012002               messages. Hence, it relies on the order of response arrival to correspond exactly to the order in which requests are made
    2002                on the same connection. More than one response message per request only occurs when one or more informational responses (<a href="p2-semantics.html#status.1xx" class="smpl">1xx</a>, see <a href="p2-semantics.html#status.1xx" title="Informational 1xx">Section 6.2</a> of <a href="#Part2" id="rfc.xref.Part2.22"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>) precede a final response to the same request.
     2003               on the same connection. More than one response message per request only occurs when one or more informational responses (<a href="p2-semantics.html#status.1xx" class="smpl">1xx</a>, see <a href="p2-semantics.html#status.1xx" title="Informational 1xx">Section 6.2</a> of <a href="#Part2" id="rfc.xref.Part2.24"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>) precede a final response to the same request.
    20032004            </p>
    20042005            <p id="rfc.section.5.6.p.2">A client that has more than one outstanding request on a connection <em class="bcp14">MUST</em> maintain a list of outstanding requests in the order sent and <em class="bcp14">MUST</em> associate each received response message on that connection to the highest ordered request that has not yet received a final
     
    20822083                  selected representation. A proxy <em class="bcp14">MAY</em> change the message body through application or removal of a transfer coding (<a href="#transfer.codings" title="Transfer Codings">Section&nbsp;4</a>).
    20832084               </p>
    2084                <p id="rfc.section.5.7.2.p.5">A non-transforming proxy <em class="bcp14">MUST NOT</em> modify the message payload (<a href="p2-semantics.html#payload" title="Payload Semantics">Section 3.3</a> of <a href="#Part2" id="rfc.xref.Part2.23"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). A transforming proxy <em class="bcp14">MUST NOT</em> modify the payload of a message that contains the no-transform cache-control directive (<a href="p6-cache.html#header.cache-control" title="Cache-Control">Section 5.2</a> of <a href="#Part6" id="rfc.xref.Part6.6"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>).
     2085               <p id="rfc.section.5.7.2.p.5">A non-transforming proxy <em class="bcp14">MUST NOT</em> modify the message payload (<a href="p2-semantics.html#payload" title="Payload Semantics">Section 3.3</a> of <a href="#Part2" id="rfc.xref.Part2.25"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). A transforming proxy <em class="bcp14">MUST NOT</em> modify the payload of a message that contains the no-transform cache-control directive (<a href="p6-cache.html#header.cache-control" title="Cache-Control">Section 5.2</a> of <a href="#Part6" id="rfc.xref.Part6.6"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>).
    20852086               </p>
    20862087               <p id="rfc.section.5.7.2.p.6">A transforming proxy <em class="bcp14">MAY</em> transform the payload of a message that does not contain the no-transform cache-control directive; if the payload is transformed,
    20872088                  the transforming proxy <em class="bcp14">MUST</em> add a Warning header field with the warn-code of 214 ("Transformation Applied") if one does not already appear in the message
    20882089                  (see <a href="p6-cache.html#header.warning" title="Warning">Section 5.5</a> of <a href="#Part6" id="rfc.xref.Part6.7"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>). If the payload of a <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> response is transformed, the transforming proxy can also inform downstream recipients that a transformation has been applied
    2089                   by changing the response status code to <a href="p2-semantics.html#status.203" class="smpl">203 (Non-Authoritative Information)</a> (<a href="p2-semantics.html#status.203" title="203 Non-Authoritative Information">Section 6.3.4</a> of <a href="#Part2" id="rfc.xref.Part2.24"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>).
     2090                  by changing the response status code to <a href="p2-semantics.html#status.203" class="smpl">203 (Non-Authoritative Information)</a> (<a href="p2-semantics.html#status.203" title="203 Non-Authoritative Information">Section 6.3.4</a> of <a href="#Part2" id="rfc.xref.Part2.26"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>).
    20902091               </p>
    20912092            </div>
     
    21912192               </p>
    21922193               <p id="rfc.section.6.3.1.p.2">When an inbound connection is closed prematurely, a client <em class="bcp14">MAY</em> open a new connection and automatically retransmit an aborted sequence of requests if all of those requests have idempotent
    2193                   methods (<a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 4.2.2</a> of <a href="#Part2" id="rfc.xref.Part2.25"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). A proxy <em class="bcp14">MUST NOT</em> automatically retry non-idempotent requests.
     2194                  methods (<a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 4.2.2</a> of <a href="#Part2" id="rfc.xref.Part2.27"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). A proxy <em class="bcp14">MUST NOT</em> automatically retry non-idempotent requests.
    21942195               </p>
    21952196               <p id="rfc.section.6.3.1.p.3">A user agent <em class="bcp14">MUST NOT</em> automatically retry a request with a non-idempotent method unless it has some means to know that the request semantics are
     
    22052206            <div id="pipelining">
    22062207               <h3 id="rfc.section.6.3.2"><a href="#rfc.section.6.3.2">6.3.2</a>&nbsp;<a href="#pipelining">Pipelining</a></h3>
    2207                <p id="rfc.section.6.3.2.p.1">A client that supports persistent connections <em class="bcp14">MAY</em> "<dfn>pipeline</dfn>" its requests (i.e., send multiple requests without waiting for each response). A server <em class="bcp14">MAY</em> process a sequence of pipelined requests in parallel if they all have safe methods (<a href="p2-semantics.html#safe.methods" title="Safe Methods">Section 4.2.1</a> of <a href="#Part2" id="rfc.xref.Part2.26"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>), but <em class="bcp14">MUST</em> send the corresponding responses in the same order that the requests were received.
     2208               <p id="rfc.section.6.3.2.p.1">A client that supports persistent connections <em class="bcp14">MAY</em> "<dfn>pipeline</dfn>" its requests (i.e., send multiple requests without waiting for each response). A server <em class="bcp14">MAY</em> process a sequence of pipelined requests in parallel if they all have safe methods (<a href="p2-semantics.html#safe.methods" title="Safe Methods">Section 4.2.1</a> of <a href="#Part2" id="rfc.xref.Part2.28"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>), but <em class="bcp14">MUST</em> send the corresponding responses in the same order that the requests were received.
    22082209               </p>
    22092210               <p id="rfc.section.6.3.2.p.2">A client that pipelines requests <em class="bcp14">SHOULD</em> retry unanswered requests if the connection closes before it receives all of the corresponding responses. When retrying pipelined
     
    22122213                  problem described in <a href="#persistent.tear-down" id="rfc.xref.persistent.tear-down.2" title="Tear-down">Section&nbsp;6.6</a>).
    22132214               </p>
    2214                <p id="rfc.section.6.3.2.p.3">Idempotent methods (<a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 4.2.2</a> of <a href="#Part2" id="rfc.xref.Part2.27"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>) are significant to pipelining because they can be automatically retried after a connection failure. A user agent <em class="bcp14">SHOULD NOT</em> pipeline requests after a non-idempotent method, until the final response status code for that method has been received, unless
     2215               <p id="rfc.section.6.3.2.p.3">Idempotent methods (<a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 4.2.2</a> of <a href="#Part2" id="rfc.xref.Part2.29"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>) are significant to pipelining because they can be automatically retried after a connection failure. A user agent <em class="bcp14">SHOULD NOT</em> pipeline requests after a non-idempotent method, until the final response status code for that method has been received, unless
    22152216                  the user agent has a means to detect and recover from partial failure conditions involving the pipelined sequence.
    22162217               </p>
     
    23362337            </p>
    23372338            <p id="rfc.section.6.7.p.11">A client cannot begin using an upgraded protocol on the connection until it has completely sent the request message (i.e.,
    2338                the client can't change the protocol it is sending in the middle of a message). If a server receives both Upgrade and an <a href="p2-semantics.html#header.expect" class="smpl">Expect</a> header field with the "100-continue" expectation (<a href="p2-semantics.html#header.expect" title="Expect">Section 5.1.1</a> of <a href="#Part2" id="rfc.xref.Part2.28"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>), the server <em class="bcp14">MUST</em> send a <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> response before sending a <a href="p2-semantics.html#status.101" class="smpl">101 (Switching Protocols)</a> response.
     2339               the client can't change the protocol it is sending in the middle of a message). If a server receives both Upgrade and an <a href="p2-semantics.html#header.expect" class="smpl">Expect</a> header field with the "100-continue" expectation (<a href="p2-semantics.html#header.expect" title="Expect">Section 5.1.1</a> of <a href="#Part2" id="rfc.xref.Part2.30"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>), the server <em class="bcp14">MUST</em> send a <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> response before sending a <a href="p2-semantics.html#status.101" class="smpl">101 (Switching Protocols)</a> response.
    23392340            </p>
    23402341            <p id="rfc.section.6.7.p.12">The Upgrade header field only applies to switching protocols on top of the existing connection; it cannot be used to switch
    23412342               the underlying connection (transport) protocol, nor to switch the existing communication to a different connection. For those
    2342                purposes, it is more appropriate to use a <a href="p2-semantics.html#status.3xx" class="smpl">3xx (Redirection)</a> response (<a href="p2-semantics.html#status.3xx" title="Redirection 3xx">Section 6.4</a> of <a href="#Part2" id="rfc.xref.Part2.29"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>).
     2343               purposes, it is more appropriate to use a <a href="p2-semantics.html#status.3xx" class="smpl">3xx (Redirection)</a> response (<a href="p2-semantics.html#status.3xx" title="Redirection 3xx">Section 6.4</a> of <a href="#Part2" id="rfc.xref.Part2.31"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>).
    23432344            </p>
    23442345            <p id="rfc.section.6.7.p.13">This specification only defines the protocol name "HTTP" for use by the family of Hypertext Transfer Protocols, as defined
     
    26722673                  <li>Pointer to specification text</li>
    26732674               </ul>
    2674                <p id="rfc.section.8.4.1.p.2">Names of transfer codings <em class="bcp14">MUST NOT</em> overlap with names of content codings (<a href="p2-semantics.html#content.codings" title="Content Codings">Section 3.1.2.1</a> of <a href="#Part2" id="rfc.xref.Part2.30"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>) unless the encoding transformation is identical, as is the case for the compression codings defined in <a href="#compression.codings" title="Compression Codings">Section&nbsp;4.2</a>.
     2675               <p id="rfc.section.8.4.1.p.2">Names of transfer codings <em class="bcp14">MUST NOT</em> overlap with names of content codings (<a href="p2-semantics.html#content.codings" title="Content Codings">Section 3.1.2.1</a> of <a href="#Part2" id="rfc.xref.Part2.32"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>) unless the encoding transformation is identical, as is the case for the compression codings defined in <a href="#compression.codings" title="Compression Codings">Section&nbsp;4.2</a>.
    26752676               </p>
    26762677               <p id="rfc.section.8.4.1.p.3">Values to be added to this name space require IETF Review (see <a href="http://tools.ietf.org/html/rfc5226#section-4.1">Section 4.1</a> of <a href="#RFC5226" id="rfc.xref.RFC5226.1"><cite title="Guidelines for Writing an IANA Considerations Section in RFCs">[RFC5226]</cite></a>), and <em class="bcp14">MUST</em> conform to the purpose of transfer coding defined in this specification.
     
    28812882               that most implementations will choose substantially higher limits.
    28822883            </p>
    2883             <p id="rfc.section.9.3.p.3">This specification also provides a way for servers to reject messages that have request-targets that are too long (<a href="p2-semantics.html#status.414" title="414 URI Too Long">Section 6.5.12</a> of <a href="#Part2" id="rfc.xref.Part2.31"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>) or request entities that are too large (<a href="p2-semantics.html#status.4xx" title="Client Error 4xx">Section 6.5</a> of <a href="#Part2" id="rfc.xref.Part2.32"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). Additional status codes related to capacity limits have been defined by extensions to HTTP <a href="#RFC6585" id="rfc.xref.RFC6585.1"><cite title="Additional HTTP Status Codes">[RFC6585]</cite></a>.
     2884            <p id="rfc.section.9.3.p.3">This specification also provides a way for servers to reject messages that have request-targets that are too long (<a href="p2-semantics.html#status.414" title="414 URI Too Long">Section 6.5.12</a> of <a href="#Part2" id="rfc.xref.Part2.33"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>) or request entities that are too large (<a href="p2-semantics.html#status.4xx" title="Client Error 4xx">Section 6.5</a> of <a href="#Part2" id="rfc.xref.Part2.34"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). Additional status codes related to capacity limits have been defined by extensions to HTTP <a href="#RFC6585" id="rfc.xref.RFC6585.1"><cite title="Additional HTTP Status Codes">[RFC6585]</cite></a>.
    28842885            </p>
    28852886            <p id="rfc.section.9.3.p.4">Recipients ought to carefully limit the extent to which they read other fields, including (but not limited to) request methods,
     
    36463647            </li>
    36473648            <li><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul>
    3648                   <li><em>Part2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.1">1</a>, <a href="#rfc.xref.Part2.2">2.1</a>, <a href="#rfc.xref.Part2.3">2.3</a>, <a href="#rfc.xref.Part2.4">2.7</a>, <a href="#rfc.xref.Part2.5">2.7.1</a>, <a href="#rfc.xref.Part2.6">3.1.1</a>, <a href="#rfc.xref.Part2.7">3.1.1</a>, <a href="#rfc.xref.Part2.8">3.1.2</a>, <a href="#rfc.xref.Part2.9">3.2</a>, <a href="#rfc.xref.Part2.10">3.2.1</a>, <a href="#rfc.xref.Part2.11">3.3</a>, <a href="#rfc.xref.Part2.12">3.3</a>, <a href="#rfc.xref.Part2.13">3.3.1</a>, <a href="#rfc.xref.Part2.14">3.3.1</a>, <a href="#rfc.xref.Part2.15">3.3.2</a>, <a href="#rfc.xref.Part2.16">3.3.2</a>, <a href="#rfc.xref.Part2.17">3.3.2</a>, <a href="#rfc.xref.Part2.18">4.3</a>, <a href="#rfc.xref.Part2.19">5.1</a>, <a href="#rfc.xref.Part2.20">5.3</a>, <a href="#rfc.xref.Part2.21">5.3</a>, <a href="#rfc.xref.Part2.22">5.6</a>, <a href="#rfc.xref.Part2.23">5.7.2</a>, <a href="#rfc.xref.Part2.24">5.7.2</a>, <a href="#rfc.xref.Part2.25">6.3.1</a>, <a href="#rfc.xref.Part2.26">6.3.2</a>, <a href="#rfc.xref.Part2.27">6.3.2</a>, <a href="#rfc.xref.Part2.28">6.7</a>, <a href="#rfc.xref.Part2.29">6.7</a>, <a href="#rfc.xref.Part2.30">8.4.1</a>, <a href="#rfc.xref.Part2.31">9.3</a>, <a href="#rfc.xref.Part2.32">9.3</a>, <a href="#Part2"><b>11.1</b></a><ul>
    3649                         <li><em>Section 2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.4">2.7</a></li>
    3650                         <li><em>Section 3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.15">3.3.2</a></li>
    3651                         <li><em>Section 3.1.2.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.13">3.3.1</a>, <a href="#rfc.xref.Part2.30">8.4.1</a></li>
    3652                         <li><em>Section 3.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.23">5.7.2</a></li>
    3653                         <li><em>Section 4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.6">3.1.1</a></li>
    3654                         <li><em>Section 4.2.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.26">6.3.2</a></li>
    3655                         <li><em>Section 4.2.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.25">6.3.1</a>, <a href="#rfc.xref.Part2.27">6.3.2</a></li>
    3656                         <li><em>Section 4.3.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.11">3.3</a>, <a href="#rfc.xref.Part2.16">3.3.2</a></li>
    3657                         <li><em>Section 4.3.6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.12">3.3</a>, <a href="#rfc.xref.Part2.14">3.3.1</a>, <a href="#rfc.xref.Part2.17">3.3.2</a>, <a href="#rfc.xref.Part2.20">5.3</a></li>
    3658                         <li><em>Section 4.3.7</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.21">5.3</a></li>
    3659                         <li><em>Section 5.1.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.28">6.7</a></li>
    3660                         <li><em>Section 5.3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.18">4.3</a></li>
    3661                         <li><em>Section 6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.5">2.7.1</a>, <a href="#rfc.xref.Part2.8">3.1.2</a></li>
    3662                         <li><em>Section 6.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.22">5.6</a></li>
    3663                         <li><em>Section 6.3.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.3">2.3</a>, <a href="#rfc.xref.Part2.24">5.7.2</a></li>
    3664                         <li><em>Section 6.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.29">6.7</a></li>
    3665                         <li><em>Section 6.5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.32">9.3</a></li>
    3666                         <li><em>Section 6.5.12</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.7">3.1.1</a>, <a href="#rfc.xref.Part2.31">9.3</a></li>
    3667                         <li><em>Section 7.1.1.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.9">3.2</a></li>
    3668                         <li><em>Section 8.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.10">3.2.1</a></li>
     3649                  <li><em>Part2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.1">1</a>, <a href="#rfc.xref.Part2.2">2.1</a>, <a href="#rfc.xref.Part2.3">2.1</a>, <a href="#rfc.xref.Part2.4">2.3</a>, <a href="#rfc.xref.Part2.5">2.7</a>, <a href="#rfc.xref.Part2.6">2.7.1</a>, <a href="#rfc.xref.Part2.7">3.1.1</a>, <a href="#rfc.xref.Part2.8">3.1.1</a>, <a href="#rfc.xref.Part2.9">3.1.2</a>, <a href="#rfc.xref.Part2.10">3.2</a>, <a href="#rfc.xref.Part2.11">3.2.1</a>, <a href="#rfc.xref.Part2.12">3.3</a>, <a href="#rfc.xref.Part2.13">3.3</a>, <a href="#rfc.xref.Part2.14">3.3</a>, <a href="#rfc.xref.Part2.15">3.3.1</a>, <a href="#rfc.xref.Part2.16">3.3.1</a>, <a href="#rfc.xref.Part2.17">3.3.2</a>, <a href="#rfc.xref.Part2.18">3.3.2</a>, <a href="#rfc.xref.Part2.19">3.3.2</a>, <a href="#rfc.xref.Part2.20">4.3</a>, <a href="#rfc.xref.Part2.21">5.1</a>, <a href="#rfc.xref.Part2.22">5.3</a>, <a href="#rfc.xref.Part2.23">5.3</a>, <a href="#rfc.xref.Part2.24">5.6</a>, <a href="#rfc.xref.Part2.25">5.7.2</a>, <a href="#rfc.xref.Part2.26">5.7.2</a>, <a href="#rfc.xref.Part2.27">6.3.1</a>, <a href="#rfc.xref.Part2.28">6.3.2</a>, <a href="#rfc.xref.Part2.29">6.3.2</a>, <a href="#rfc.xref.Part2.30">6.7</a>, <a href="#rfc.xref.Part2.31">6.7</a>, <a href="#rfc.xref.Part2.32">8.4.1</a>, <a href="#rfc.xref.Part2.33">9.3</a>, <a href="#rfc.xref.Part2.34">9.3</a>, <a href="#Part2"><b>11.1</b></a><ul>
     3650                        <li><em>Section 2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.5">2.7</a></li>
     3651                        <li><em>Section 3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.17">3.3.2</a></li>
     3652                        <li><em>Section 3.1.2.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.15">3.3.1</a>, <a href="#rfc.xref.Part2.32">8.4.1</a></li>
     3653                        <li><em>Section 3.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.25">5.7.2</a></li>
     3654                        <li><em>Section 4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.7">3.1.1</a></li>
     3655                        <li><em>Section 4.2.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.28">6.3.2</a></li>
     3656                        <li><em>Section 4.2.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.27">6.3.1</a>, <a href="#rfc.xref.Part2.29">6.3.2</a></li>
     3657                        <li><em>Section 4.3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.3">2.1</a>, <a href="#rfc.xref.Part2.13">3.3</a></li>
     3658                        <li><em>Section 4.3.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.12">3.3</a>, <a href="#rfc.xref.Part2.18">3.3.2</a></li>
     3659                        <li><em>Section 4.3.6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.14">3.3</a>, <a href="#rfc.xref.Part2.16">3.3.1</a>, <a href="#rfc.xref.Part2.19">3.3.2</a>, <a href="#rfc.xref.Part2.22">5.3</a></li>
     3660                        <li><em>Section 4.3.7</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.23">5.3</a></li>
     3661                        <li><em>Section 5.1.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.30">6.7</a></li>
     3662                        <li><em>Section 5.3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.20">4.3</a></li>
     3663                        <li><em>Section 6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.6">2.7.1</a>, <a href="#rfc.xref.Part2.9">3.1.2</a></li>
     3664                        <li><em>Section 6.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.24">5.6</a></li>
     3665                        <li><em>Section 6.3.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.4">2.3</a>, <a href="#rfc.xref.Part2.26">5.7.2</a></li>
     3666                        <li><em>Section 6.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.31">6.7</a></li>
     3667                        <li><em>Section 6.5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.34">9.3</a></li>
     3668                        <li><em>Section 6.5.12</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.8">3.1.1</a>, <a href="#rfc.xref.Part2.33">9.3</a></li>
     3669                        <li><em>Section 7.1.1.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.10">3.2</a></li>
     3670                        <li><em>Section 8.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.11">3.2.1</a></li>
    36693671                        <li><em>Appendix A</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.2">2.1</a></li>
    36703672                     </ul>
  • draft-ietf-httpbis/latest/p1-messaging.xml

    r2557 r2561  
    2626  <!ENTITY diff-mime              "<xref target='Part2' x:rel='#differences.between.http.and.mime' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    2727  <!ENTITY representation         "<xref target='Part2' x:rel='#representations' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
     28  <!ENTITY GET                    "<xref target='Part2' x:rel='#GET' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    2829  <!ENTITY HEAD                   "<xref target='Part2' x:rel='#HEAD' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    2930  <!ENTITY header-allow           "<xref target='Part2' x:rel='#header.allow' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
     
    364365<t>
    365366   The following example illustrates a typical message exchange for a
    366    GET request on the URI "http://www.example.com/hello.txt":
     367   GET request (&GET;) on the URI "http://www.example.com/hello.txt":
    367368</t>
    368369<figure><preamble>
     
    15431544   the request method to which it is responding and the response
    15441545   status code (<xref target="status.line"/>).
    1545    Responses to the HEAD request method never include a message body
     1546   Responses to the HEAD request method (&HEAD;) never include a message body
    15461547   because the associated response header fields (e.g.,
    15471548   <x:ref>Transfer-Encoding</x:ref>, <x:ref>Content-Length</x:ref>, etc.),
    15481549   if present, indicate only what their values would have been if the request
    1549    method had been GET (&HEAD;).
    1550    <x:ref>2xx (Successful)</x:ref> responses to CONNECT switch to tunnel
    1551    mode instead of having a message body (&CONNECT;).
     1550   method had been GET (&GET;).
     1551   <x:ref>2xx (Successful)</x:ref> responses to a CONNECT request method
     1552   (&CONNECT;) switch to tunnel mode instead of having a message body.
    15521553   All <x:ref>1xx (Informational)</x:ref>, <x:ref>204 (No Content)</x:ref>, and
    15531554   <x:ref>304 (Not Modified)</x:ref> responses do not include a message body.
  • draft-ietf-httpbis/latest/p2-semantics.html

    r2556 r2561  
    448448  }
    449449  @bottom-center {
    450        content: "Expires July 21, 2014";
     450       content: "Expires July 22, 2014";
    451451  }
    452452  @bottom-right {
     
    493493      <meta name="dct.creator" content="Reschke, J. F.">
    494494      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p2-semantics-latest">
    495       <meta name="dct.issued" scheme="ISO8601" content="2014-01-17">
     495      <meta name="dct.issued" scheme="ISO8601" content="2014-01-18">
    496496      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    497497      <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP/1.1 messages, as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation.">
     
    521521            <tr>
    522522               <td class="left">Intended status: Standards Track</td>
    523                <td class="right">January 17, 2014</td>
     523               <td class="right">January 18, 2014</td>
    524524            </tr>
    525525            <tr>
    526                <td class="left">Expires: July 21, 2014</td>
     526               <td class="left">Expires: July 22, 2014</td>
    527527               <td class="right"></td>
    528528            </tr>
     
    553553            in progress”.
    554554         </p>
    555          <p>This Internet-Draft will expire on July 21, 2014.</p>
     555         <p>This Internet-Draft will expire on July 22, 2014.</p>
    556556      </div>
    557557      <div id="rfc.copyrightnotice">
     
    11131113                  <p id="rfc.section.3.1.4.1.p.3">For a response message, the following rules are applied in order until a match is found: </p>
    11141114                  <ol>
    1115                      <li>If the request is GET or HEAD and the response status code is <a href="#status.200" class="smpl">200 (OK)</a>, <a href="#status.204" class="smpl">204 (No Content)</a>, <a href="p5-range.html#status.206" class="smpl">206 (Partial Content)</a>, or <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a>, the payload is a representation of the resource identified by the effective request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 5.5</a> of <a href="#Part1" id="rfc.xref.Part1.11"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>).
     1115                     <li>If the request method is GET or HEAD and the response status code is <a href="#status.200" class="smpl">200 (OK)</a>, <a href="#status.204" class="smpl">204 (No Content)</a>, <a href="p5-range.html#status.206" class="smpl">206 (Partial Content)</a>, or <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a>, the payload is a representation of the resource identified by the effective request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 5.5</a> of <a href="#Part1" id="rfc.xref.Part1.11"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>).
    11161116                     </li>
    1117                      <li>If the request is GET or HEAD and the response status code is <a href="#status.203" class="smpl">203 (Non-Authoritative Information)</a>, the payload is a potentially modified or enhanced representation of the <a href="#resources" class="smpl">target resource</a> as provided by an intermediary.
     1117                     <li>If the request method is GET or HEAD and the response status code is <a href="#status.203" class="smpl">203 (Non-Authoritative Information)</a>, the payload is a potentially modified or enhanced representation of the <a href="#resources" class="smpl">target resource</a> as provided by an intermediary.
    11181118                     </li>
    11191119                     <li>If the response has a <a href="#header.content-location" class="smpl">Content-Location</a> header field and its field-value is a reference to the same URI as the effective request URI, the payload is a representation
     
    11401140                  <p id="rfc.section.3.1.4.2.p.4">If Content-Location is included in a <a href="#status.2xx" class="smpl">2xx (Successful)</a> response message and its value refers (after conversion to absolute form) to a URI that is the same as the effective request
    11411141                     URI, then the recipient <em class="bcp14">MAY</em> consider the payload to be a current representation of that resource at the time indicated by the message origination date.
    1142                      For a GET or HEAD request, this is the same as the default semantics when no Content-Location is provided by the server. For
    1143                      a state-changing request like PUT or POST, it implies that the server's response contains the new representation of that resource,
    1144                      thereby distinguishing it from representations that might only report about the action (e.g., "It worked!"). This allows authoring
    1145                      applications to update their local copies without the need for a subsequent GET request.
     1142                     For a GET (<a href="#GET" id="rfc.xref.GET.2" title="GET">Section&nbsp;4.3.1</a>) or HEAD (<a href="#HEAD" id="rfc.xref.HEAD.1" title="HEAD">Section&nbsp;4.3.2</a>) request, this is the same as the default semantics when no Content-Location is provided by the server. For a state-changing
     1143                     request like PUT (<a href="#PUT" id="rfc.xref.PUT.1" title="PUT">Section&nbsp;4.3.4</a>) or POST (<a href="#POST" id="rfc.xref.POST.1" title="POST">Section&nbsp;4.3.3</a>), it implies that the server's response contains the new representation of that resource, thereby distinguishing it from
     1144                     representations that might only report about the action (e.g., "It worked!"). This allows authoring applications to update
     1145                     their local copies without the need for a subsequent GET request.
    11461146                  </p>
    11471147                  <p id="rfc.section.3.1.4.2.p.5">If Content-Location is included in a <a href="#status.2xx" class="smpl">2xx (Successful)</a> response message and its field-value refers to a URI that differs from the effective request URI, then the origin server claims
     
    11931193            </p>
    11941194            <p id="rfc.section.3.3.p.2">The purpose of a payload in a request is defined by the method semantics. For example, a representation in the payload of
    1195                a PUT request (<a href="#PUT" id="rfc.xref.PUT.1" title="PUT">Section&nbsp;4.3.4</a>) represents the desired state of the <a href="#resources" class="smpl">target resource</a> if the request is successfully applied, whereas a representation in the payload of a POST request (<a href="#POST" id="rfc.xref.POST.1" title="POST">Section&nbsp;4.3.3</a>) represents information to be processed by the target resource.
     1195               a PUT request (<a href="#PUT" id="rfc.xref.PUT.2" title="PUT">Section&nbsp;4.3.4</a>) represents the desired state of the <a href="#resources" class="smpl">target resource</a> if the request is successfully applied, whereas a representation in the payload of a POST request (<a href="#POST" id="rfc.xref.POST.2" title="POST">Section&nbsp;4.3.3</a>) represents information to be processed by the target resource.
    11961196            </p>
    11971197            <p id="rfc.section.3.3.p.3">In a response, the payload's purpose is defined by both the request method and the response status code. For example, the
    1198                payload of a <a href="#status.200" class="smpl">200 (OK)</a> response to GET (<a href="#GET" id="rfc.xref.GET.2" title="GET">Section&nbsp;4.3.1</a>) represents the current state of the <a href="#resources" class="smpl">target resource</a>, as observed at the time of the message origination date (<a href="#header.date" id="rfc.xref.header.date.1" title="Date">Section&nbsp;7.1.1.2</a>), whereas the payload of the same status code in a response to POST might represent either the processing result or the new
     1198               payload of a <a href="#status.200" class="smpl">200 (OK)</a> response to GET (<a href="#GET" id="rfc.xref.GET.3" title="GET">Section&nbsp;4.3.1</a>) represents the current state of the <a href="#resources" class="smpl">target resource</a>, as observed at the time of the message origination date (<a href="#header.date" id="rfc.xref.header.date.1" title="Date">Section&nbsp;7.1.1.2</a>), whereas the payload of the same status code in a response to POST might represent either the processing result or the new
    11991199               state of the target resource after applying the processing. Response messages with an error status code usually contain a
    12001200               payload that represents the error condition, such that it describes the error state and what next steps are suggested for
     
    13491349                        <td class="left">GET</td>
    13501350                        <td class="left">Transfer a current representation of the target resource.</td>
    1351                         <td class="left"><a href="#GET" id="rfc.xref.GET.3" title="GET">4.3.1</a></td>
     1351                        <td class="left"><a href="#GET" id="rfc.xref.GET.4" title="GET">4.3.1</a></td>
    13521352                     </tr>
    13531353                     <tr>
    13541354                        <td class="left">HEAD</td>
    13551355                        <td class="left">Same as GET, but only transfer the status line and header section.</td>
    1356                         <td class="left"><a href="#HEAD" id="rfc.xref.HEAD.1" title="HEAD">4.3.2</a></td>
     1356                        <td class="left"><a href="#HEAD" id="rfc.xref.HEAD.2" title="HEAD">4.3.2</a></td>
    13571357                     </tr>
    13581358                     <tr>
    13591359                        <td class="left">POST</td>
    13601360                        <td class="left">Perform resource-specific processing on the request payload.</td>
    1361                         <td class="left"><a href="#POST" id="rfc.xref.POST.2" title="POST">4.3.3</a></td>
     1361                        <td class="left"><a href="#POST" id="rfc.xref.POST.3" title="POST">4.3.3</a></td>
    13621362                     </tr>
    13631363                     <tr>
    13641364                        <td class="left">PUT</td>
    13651365                        <td class="left">Replace all current representations of the target resource with the request payload.</td>
    1366                         <td class="left"><a href="#PUT" id="rfc.xref.PUT.2" title="PUT">4.3.4</a></td>
     1366                        <td class="left"><a href="#PUT" id="rfc.xref.PUT.3" title="PUT">4.3.4</a></td>
    13671367                     </tr>
    13681368                     <tr>
     
    35153515                           <td class="left">yes</td>
    35163516                           <td class="left">yes</td>
    3517                            <td class="left"><a href="#GET" id="rfc.xref.GET.4" title="GET">Section&nbsp;4.3.1</a>
     3517                           <td class="left"><a href="#GET" id="rfc.xref.GET.5" title="GET">Section&nbsp;4.3.1</a>
    35183518                           </td>
    35193519                        </tr>
     
    35223522                           <td class="left">yes</td>
    35233523                           <td class="left">yes</td>
    3524                            <td class="left"><a href="#HEAD" id="rfc.xref.HEAD.2" title="HEAD">Section&nbsp;4.3.2</a>
     3524                           <td class="left"><a href="#HEAD" id="rfc.xref.HEAD.3" title="HEAD">Section&nbsp;4.3.2</a>
    35253525                           </td>
    35263526                        </tr>
     
    35363536                           <td class="left">no</td>
    35373537                           <td class="left">no</td>
    3538                            <td class="left"><a href="#POST" id="rfc.xref.POST.3" title="POST">Section&nbsp;4.3.3</a>
     3538                           <td class="left"><a href="#POST" id="rfc.xref.POST.4" title="POST">Section&nbsp;4.3.3</a>
    35393539                           </td>
    35403540                        </tr>
     
    35433543                           <td class="left">no</td>
    35443544                           <td class="left">yes</td>
    3545                            <td class="left"><a href="#PUT" id="rfc.xref.PUT.3" title="PUT">Section&nbsp;4.3.4</a>
     3545                           <td class="left"><a href="#PUT" id="rfc.xref.PUT.4" title="PUT">Section&nbsp;4.3.4</a>
    35463546                           </td>
    35473547                        </tr>
     
    45224522            and the undesirable effect of potentially breaking relative links in content-negotiated resources. (<a href="#header.content-location" id="rfc.xref.header.content-location.5" title="Content-Location">Section&nbsp;3.1.4.2</a>)
    45234523         </p>
    4524          <p id="rfc.section.B.p.6">To be consistent with the method-neutral parsing algorithm of <a href="#Part1" id="rfc.xref.Part1.45"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, the definition of GET has been relaxed so that requests can have a body, even though a body has no meaning for GET. (<a href="#GET" id="rfc.xref.GET.5" title="GET">Section&nbsp;4.3.1</a>)
    4525          </p>
    4526          <p id="rfc.section.B.p.7">Servers are no longer required to handle all Content-* header fields and use of <a href="p5-range.html#header.content-range" class="smpl">Content-Range</a> has been explicitly banned in PUT requests. (<a href="#PUT" id="rfc.xref.PUT.4" title="PUT">Section&nbsp;4.3.4</a>)
     4524         <p id="rfc.section.B.p.6">To be consistent with the method-neutral parsing algorithm of <a href="#Part1" id="rfc.xref.Part1.45"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, the definition of GET has been relaxed so that requests can have a body, even though a body has no meaning for GET. (<a href="#GET" id="rfc.xref.GET.6" title="GET">Section&nbsp;4.3.1</a>)
     4525         </p>
     4526         <p id="rfc.section.B.p.7">Servers are no longer required to handle all Content-* header fields and use of <a href="p5-range.html#header.content-range" class="smpl">Content-Range</a> has been explicitly banned in PUT requests. (<a href="#PUT" id="rfc.xref.PUT.5" title="PUT">Section&nbsp;4.3.4</a>)
    45274527         </p>
    45284528         <p id="rfc.section.B.p.8">Definition of the CONNECT method has been moved from <a href="#RFC2817" id="rfc.xref.RFC2817.2"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a> to this specification. (<a href="#CONNECT" id="rfc.xref.CONNECT.3" title="CONNECT">Section&nbsp;4.3.6</a>)
     
    48764876            </li>
    48774877            <li><a id="rfc.index.G" href="#rfc.index.G"><b>G</b></a><ul>
    4878                   <li>GET method&nbsp;&nbsp;<a href="#rfc.xref.GET.1">3</a>, <a href="#rfc.xref.GET.2">3.3</a>, <a href="#rfc.xref.GET.3">4.1</a>, <a href="#rfc.iref.g.14"><b>4.3.1</b></a>, <a href="#rfc.xref.GET.4">8.1.3</a>, <a href="#rfc.xref.GET.5">B</a></li>
     4878                  <li>GET method&nbsp;&nbsp;<a href="#rfc.xref.GET.1">3</a>, <a href="#rfc.xref.GET.2">3.1.4.2</a>, <a href="#rfc.xref.GET.3">3.3</a>, <a href="#rfc.xref.GET.4">4.1</a>, <a href="#rfc.iref.g.14"><b>4.3.1</b></a>, <a href="#rfc.xref.GET.5">8.1.3</a>, <a href="#rfc.xref.GET.6">B</a></li>
    48794879                  <li><tt>Grammar</tt>&nbsp;&nbsp;
    48804880                     <ul>
     
    49384938            </li>
    49394939            <li><a id="rfc.index.H" href="#rfc.index.H"><b>H</b></a><ul>
    4940                   <li>HEAD method&nbsp;&nbsp;<a href="#rfc.xref.HEAD.1">4.1</a>, <a href="#rfc.iref.h.1"><b>4.3.2</b></a>, <a href="#rfc.xref.HEAD.2">8.1.3</a></li>
     4940                  <li>HEAD method&nbsp;&nbsp;<a href="#rfc.xref.HEAD.1">3.1.4.2</a>, <a href="#rfc.xref.HEAD.2">4.1</a>, <a href="#rfc.iref.h.1"><b>4.3.2</b></a>, <a href="#rfc.xref.HEAD.3">8.1.3</a></li>
    49414941               </ul>
    49424942            </li>
     
    50405040                  </li>
    50415041                  <li>payload&nbsp;&nbsp;<a href="#rfc.iref.p.1">3.3</a></li>
    5042                   <li>POST method&nbsp;&nbsp;<a href="#rfc.xref.POST.1">3.3</a>, <a href="#rfc.xref.POST.2">4.1</a>, <a href="#rfc.iref.p.2"><b>4.3.3</b></a>, <a href="#rfc.xref.POST.3">8.1.3</a></li>
    5043                   <li>PUT method&nbsp;&nbsp;<a href="#rfc.xref.PUT.1">3.3</a>, <a href="#rfc.xref.PUT.2">4.1</a>, <a href="#rfc.iref.p.3"><b>4.3.4</b></a>, <a href="#rfc.xref.PUT.3">8.1.3</a>, <a href="#rfc.xref.PUT.4">B</a></li>
     5042                  <li>POST method&nbsp;&nbsp;<a href="#rfc.xref.POST.1">3.1.4.2</a>, <a href="#rfc.xref.POST.2">3.3</a>, <a href="#rfc.xref.POST.3">4.1</a>, <a href="#rfc.iref.p.2"><b>4.3.3</b></a>, <a href="#rfc.xref.POST.4">8.1.3</a></li>
     5043                  <li>PUT method&nbsp;&nbsp;<a href="#rfc.xref.PUT.1">3.1.4.2</a>, <a href="#rfc.xref.PUT.2">3.3</a>, <a href="#rfc.xref.PUT.3">4.1</a>, <a href="#rfc.iref.p.3"><b>4.3.4</b></a>, <a href="#rfc.xref.PUT.4">8.1.3</a>, <a href="#rfc.xref.PUT.5">B</a></li>
    50445044               </ul>
    50455045            </li>
  • draft-ietf-httpbis/latest/p2-semantics.xml

    r2556 r2561  
    738738   match is found:
    739739   <list style="numbers">
    740       <t>If the request is GET or HEAD and the response status code is
     740      <t>If the request method is GET or HEAD and the response status code is
    741741         <x:ref>200 (OK)</x:ref>,
    742742         <x:ref>204 (No Content)</x:ref>,
     
    745745         the payload is a representation of the resource identified by the
    746746         effective request URI (&effective-request-uri;).</t>
    747       <t>If the request is GET or HEAD and the response status code is
     747      <t>If the request method is GET or HEAD and the response status code is
    748748         <x:ref>203 (Non-Authoritative Information)</x:ref>, the payload is
    749749         a potentially modified or enhanced representation of the
     
    792792   the recipient &MAY; consider the payload to be a current representation of
    793793   that resource at the time indicated by the message origination date.
    794    For a GET or HEAD request, this is the same as the default semantics
    795    when no Content-Location is provided by the server.  For a state-changing
    796    request like PUT or POST, it implies that the server's response contains
    797    the new representation of that resource, thereby distinguishing it from
    798    representations that might only report about the action (e.g., "It worked!").
     794   For a GET (<xref target="GET"/>) or HEAD (<xref target="HEAD"/>) request,
     795   this is the same as the default semantics when no Content-Location is
     796   provided by the server.
     797   For a state-changing request like PUT (<xref target="PUT"/>) or
     798   POST (<xref target="POST"/>), it implies that the server's response
     799   contains the new representation of that resource, thereby distinguishing it
     800   from representations that might only report about the action
     801   (e.g., "It worked!").
    799802   This allows authoring applications to update their local copies without
    800803   the need for a subsequent GET request.
Note: See TracChangeset for help on using the changeset viewer.