![(please configure the [header_logo] section in trac.ini)](https://www.ietf.org/images/ietflogotrans.gif)
Changeset 2561 for draft-ietf-httpbis
- Timestamp:
- 19/01/14 02:53:35 (9 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 4 edited
-
p1-messaging.html (modified) (32 diffs)
-
p1-messaging.xml (modified) (3 diffs)
-
p2-semantics.html (modified) (16 diffs)
-
p2-semantics.xml (modified) (3 diffs)
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.html
r2557 r2561 448 448 } 449 449 @bottom-center { 450 content: "Expires July 2 1, 2014";450 content: "Expires July 22, 2014"; 451 451 } 452 452 @bottom-right { … … 490 490 <meta name="dct.creator" content="Reschke, J. F."> 491 491 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p1-messaging-latest"> 492 <meta name="dct.issued" scheme="ISO8601" content="2014-01-1 7">492 <meta name="dct.issued" scheme="ISO8601" content="2014-01-18"> 493 493 <meta name="dct.replaces" content="urn:ietf:rfc:2145"> 494 494 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> … … 519 519 <tr> 520 520 <td class="left">Intended status: Standards Track</td> 521 <td class="right">January 1 7, 2014</td>521 <td class="right">January 18, 2014</td> 522 522 </tr> 523 523 <tr> 524 <td class="left">Expires: July 2 1, 2014</td>524 <td class="left">Expires: July 22, 2014</td> 525 525 <td class="right"></td> 526 526 </tr> … … 551 551 in progress”. 552 552 </p> 553 <p>This Internet-Draft will expire on July 2 1, 2014.</p>553 <p>This Internet-Draft will expire on July 22, 2014.</p> 554 554 </div> 555 555 <div id="rfc.copyrightnotice"> … … 837 837 <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 6.3</a>. 838 838 </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> 840 841 <div id="rfc.figure.u.2"></div> 841 842 <p>Client request:</p><pre class="text2">GET /hello.txt HTTP/1.1 … … 911 912 or an intranet-to-Internet privacy filter. Such transformations are presumed to be desired by the client (or client organization) 912 913 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. 914 915 </p> 915 916 <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 … … 1070 1071 <div id="rfc.iref.r.5"></div> 1071 1072 <h2 id="rfc.section.2.7"><a href="#rfc.section.2.7">2.7</a> <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. 1073 1074 </p> 1074 1075 <p id="rfc.section.2.7.p.2">This specification adopts the definitions of "URI-reference", "absolute-URI", "relative-part", "authority", "port", "host", … … 1121 1122 </p> 1122 1123 <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 3</a>) containing the URI's identifying data (<a href="#message.routing" title="Message Routing">Section 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 3</a>) containing the URI's identifying data (<a href="#message.routing" title="Message Routing">Section 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. 1124 1125 </p> 1125 1126 <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 … … 1235 1236 </div> 1236 1237 <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. 1238 1239 </p> 1239 1240 <div id="rfc.iref.r.6"></div> … … 1247 1248 </p> 1248 1249 <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 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 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>). 1250 1251 </p> 1251 1252 <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. … … 1260 1261 </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 1261 1262 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), 1263 1264 the status codes defined by this specification, considerations for the definition of new status codes, and the IANA registry. 1264 1265 </p> … … 1284 1285 ; see <a href="#field.parsing" title="Field Parsing">Section 3.2.4</a> 1285 1286 </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. 1287 1288 </p> 1288 1289 <div id="field.extensibility"> … … 1298 1299 of deployed intermediaries. 1299 1300 </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.1 0"><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>. 1301 1302 </p> 1302 1303 </div> … … 1446 1447 </p> 1447 1448 <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 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 zero1449 status code (<a href="#status.line" title="Status Line">Section 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 1449 1450 length. 1450 1451 </p> … … 1471 1472 forming the message body. 1472 1473 </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.1 3"><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/response1474 <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 1474 1475 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 1475 1476 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. … … 1479 1480 any recipient on the response chain (including the origin server) can remove transfer codings when they are not needed. 1480 1481 </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.1 4"><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>). 1482 1483 </p> 1483 1484 <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 … … 1494 1495 payload body. For messages that do include a payload body, the Content-Length field-value provides the framing information 1495 1496 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.1 5"><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>). 1497 1498 </p> 1498 1499 <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> … … 1505 1506 anticipate such a body. 1506 1507 </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.1 6"><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 sent1508 <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 1508 1509 in the payload body of a response if the same request had used the GET method. 1509 1510 </p> … … 1511 1512 in the payload body of a <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> response to the same request. 1512 1513 </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.1 7"><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>). 1514 1515 </p> 1515 1516 <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 … … 1800 1801 </p> 1801 1802 <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; 1803 1804 a value of 0 means "not acceptable". 1804 1805 </p> … … 1835 1836 </p> 1836 1837 <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 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-side1838 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 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 1839 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>). 1839 1840 </p> … … 1905 1906 </p> 1906 1907 </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.2 0"><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, 1908 1909 </p> 1909 1910 <div id="rfc.figure.u.42"></div><pre class="text2">CONNECT www.example.com:80 HTTP/1.1 … … 1912 1913 </p> 1913 1914 </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.2 1"><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, 1915 1916 the client <em class="bcp14">MUST</em> send only "*" (%x2A) as the request-target. For example, 1916 1917 </p> … … 2000 2001 <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 2001 2002 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.2 2"><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. 2003 2004 </p> 2004 2005 <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 … … 2082 2083 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 4</a>). 2083 2084 </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.2 3"><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>). 2085 2086 </p> 2086 2087 <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, 2087 2088 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 2088 2089 (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.2 4"><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>). 2090 2091 </p> 2091 2092 </div> … … 2191 2192 </p> 2192 2193 <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.2 5"><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. 2194 2195 </p> 2195 2196 <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 … … 2205 2206 <div id="pipelining"> 2206 2207 <h3 id="rfc.section.6.3.2"><a href="#rfc.section.6.3.2">6.3.2</a> <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.2 6"><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. 2208 2209 </p> 2209 2210 <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 … … 2212 2213 problem described in <a href="#persistent.tear-down" id="rfc.xref.persistent.tear-down.2" title="Tear-down">Section 6.6</a>). 2213 2214 </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.2 7"><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, unless2215 <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 2215 2216 the user agent has a means to detect and recover from partial failure conditions involving the pipelined sequence. 2216 2217 </p> … … 2336 2337 </p> 2337 2338 <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. 2339 2340 </p> 2340 2341 <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 2341 2342 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>). 2343 2344 </p> 2344 2345 <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 … … 2672 2673 <li>Pointer to specification text</li> 2673 2674 </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.3 0"><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 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 4.2</a>. 2675 2676 </p> 2676 2677 <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. … … 2881 2882 that most implementations will choose substantially higher limits. 2882 2883 </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.3 1"><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>. 2884 2885 </p> 2885 2886 <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, … … 3646 3647 </li> 3647 3648 <li><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul> 3648 <li><em>Part2</em> <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> <a href="#rfc.xref.Part2.4">2.7</a></li> 3650 <li><em>Section 3</em> <a href="#rfc.xref.Part2.15">3.3.2</a></li> 3651 <li><em>Section 3.1.2.1</em> <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> <a href="#rfc.xref.Part2.23">5.7.2</a></li> 3653 <li><em>Section 4</em> <a href="#rfc.xref.Part2.6">3.1.1</a></li> 3654 <li><em>Section 4.2.1</em> <a href="#rfc.xref.Part2.26">6.3.2</a></li> 3655 <li><em>Section 4.2.2</em> <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> <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> <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> <a href="#rfc.xref.Part2.21">5.3</a></li> 3659 <li><em>Section 5.1.1</em> <a href="#rfc.xref.Part2.28">6.7</a></li> 3660 <li><em>Section 5.3.1</em> <a href="#rfc.xref.Part2.18">4.3</a></li> 3661 <li><em>Section 6</em> <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> <a href="#rfc.xref.Part2.22">5.6</a></li> 3663 <li><em>Section 6.3.4</em> <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> <a href="#rfc.xref.Part2.29">6.7</a></li> 3665 <li><em>Section 6.5</em> <a href="#rfc.xref.Part2.32">9.3</a></li> 3666 <li><em>Section 6.5.12</em> <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> <a href="#rfc.xref.Part2.9">3.2</a></li> 3668 <li><em>Section 8.3</em> <a href="#rfc.xref.Part2.10">3.2.1</a></li> 3649 <li><em>Part2</em> <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> <a href="#rfc.xref.Part2.5">2.7</a></li> 3651 <li><em>Section 3</em> <a href="#rfc.xref.Part2.17">3.3.2</a></li> 3652 <li><em>Section 3.1.2.1</em> <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> <a href="#rfc.xref.Part2.25">5.7.2</a></li> 3654 <li><em>Section 4</em> <a href="#rfc.xref.Part2.7">3.1.1</a></li> 3655 <li><em>Section 4.2.1</em> <a href="#rfc.xref.Part2.28">6.3.2</a></li> 3656 <li><em>Section 4.2.2</em> <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> <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> <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> <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> <a href="#rfc.xref.Part2.23">5.3</a></li> 3661 <li><em>Section 5.1.1</em> <a href="#rfc.xref.Part2.30">6.7</a></li> 3662 <li><em>Section 5.3.1</em> <a href="#rfc.xref.Part2.20">4.3</a></li> 3663 <li><em>Section 6</em> <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> <a href="#rfc.xref.Part2.24">5.6</a></li> 3665 <li><em>Section 6.3.4</em> <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> <a href="#rfc.xref.Part2.31">6.7</a></li> 3667 <li><em>Section 6.5</em> <a href="#rfc.xref.Part2.34">9.3</a></li> 3668 <li><em>Section 6.5.12</em> <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> <a href="#rfc.xref.Part2.10">3.2</a></li> 3670 <li><em>Section 8.3</em> <a href="#rfc.xref.Part2.11">3.2.1</a></li> 3669 3671 <li><em>Appendix A</em> <a href="#rfc.xref.Part2.2">2.1</a></li> 3670 3672 </ul> -
draft-ietf-httpbis/latest/p1-messaging.xml
r2557 r2561 26 26 <!ENTITY diff-mime "<xref target='Part2' x:rel='#differences.between.http.and.mime' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 27 27 <!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'/>"> 28 29 <!ENTITY HEAD "<xref target='Part2' x:rel='#HEAD' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 29 30 <!ENTITY header-allow "<xref target='Part2' x:rel='#header.allow' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> … … 364 365 <t> 365 366 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": 367 368 </t> 368 369 <figure><preamble> … … 1543 1544 the request method to which it is responding and the response 1544 1545 status code (<xref target="status.line"/>). 1545 Responses to the HEAD request method never include a message body1546 Responses to the HEAD request method (&HEAD;) never include a message body 1546 1547 because the associated response header fields (e.g., 1547 1548 <x:ref>Transfer-Encoding</x:ref>, <x:ref>Content-Length</x:ref>, etc.), 1548 1549 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 tunnel1551 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. 1552 1553 All <x:ref>1xx (Informational)</x:ref>, <x:ref>204 (No Content)</x:ref>, and 1553 1554 <x:ref>304 (Not Modified)</x:ref> responses do not include a message body. -
draft-ietf-httpbis/latest/p2-semantics.html
r2556 r2561 448 448 } 449 449 @bottom-center { 450 content: "Expires July 2 1, 2014";450 content: "Expires July 22, 2014"; 451 451 } 452 452 @bottom-right { … … 493 493 <meta name="dct.creator" content="Reschke, J. F."> 494 494 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p2-semantics-latest"> 495 <meta name="dct.issued" scheme="ISO8601" content="2014-01-1 7">495 <meta name="dct.issued" scheme="ISO8601" content="2014-01-18"> 496 496 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 497 497 <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."> … … 521 521 <tr> 522 522 <td class="left">Intended status: Standards Track</td> 523 <td class="right">January 1 7, 2014</td>523 <td class="right">January 18, 2014</td> 524 524 </tr> 525 525 <tr> 526 <td class="left">Expires: July 2 1, 2014</td>526 <td class="left">Expires: July 22, 2014</td> 527 527 <td class="right"></td> 528 528 </tr> … … 553 553 in progress”. 554 554 </p> 555 <p>This Internet-Draft will expire on July 2 1, 2014.</p>555 <p>This Internet-Draft will expire on July 22, 2014.</p> 556 556 </div> 557 557 <div id="rfc.copyrightnotice"> … … 1113 1113 <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> 1114 1114 <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>). 1116 1116 </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. 1118 1118 </li> 1119 1119 <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 … … 1140 1140 <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 1141 1141 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. For1143 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 authoring1145 applications to updatetheir 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 4.3.1</a>) or HEAD (<a href="#HEAD" id="rfc.xref.HEAD.1" title="HEAD">Section 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 4.3.4</a>) or POST (<a href="#POST" id="rfc.xref.POST.1" title="POST">Section 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. 1146 1146 </p> 1147 1147 <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 … … 1193 1193 </p> 1194 1194 <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 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 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 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 4.3.3</a>) represents information to be processed by the target resource. 1196 1196 </p> 1197 1197 <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 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 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 new1198 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 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 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 1199 1199 state of the target resource after applying the processing. Response messages with an error status code usually contain a 1200 1200 payload that represents the error condition, such that it describes the error state and what next steps are suggested for … … 1349 1349 <td class="left">GET</td> 1350 1350 <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> 1352 1352 </tr> 1353 1353 <tr> 1354 1354 <td class="left">HEAD</td> 1355 1355 <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> 1357 1357 </tr> 1358 1358 <tr> 1359 1359 <td class="left">POST</td> 1360 1360 <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> 1362 1362 </tr> 1363 1363 <tr> 1364 1364 <td class="left">PUT</td> 1365 1365 <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> 1367 1367 </tr> 1368 1368 <tr> … … 3515 3515 <td class="left">yes</td> 3516 3516 <td class="left">yes</td> 3517 <td class="left"><a href="#GET" id="rfc.xref.GET. 4" title="GET">Section 4.3.1</a>3517 <td class="left"><a href="#GET" id="rfc.xref.GET.5" title="GET">Section 4.3.1</a> 3518 3518 </td> 3519 3519 </tr> … … 3522 3522 <td class="left">yes</td> 3523 3523 <td class="left">yes</td> 3524 <td class="left"><a href="#HEAD" id="rfc.xref.HEAD. 2" title="HEAD">Section 4.3.2</a>3524 <td class="left"><a href="#HEAD" id="rfc.xref.HEAD.3" title="HEAD">Section 4.3.2</a> 3525 3525 </td> 3526 3526 </tr> … … 3536 3536 <td class="left">no</td> 3537 3537 <td class="left">no</td> 3538 <td class="left"><a href="#POST" id="rfc.xref.POST. 3" title="POST">Section 4.3.3</a>3538 <td class="left"><a href="#POST" id="rfc.xref.POST.4" title="POST">Section 4.3.3</a> 3539 3539 </td> 3540 3540 </tr> … … 3543 3543 <td class="left">no</td> 3544 3544 <td class="left">yes</td> 3545 <td class="left"><a href="#PUT" id="rfc.xref.PUT. 3" title="PUT">Section 4.3.4</a>3545 <td class="left"><a href="#PUT" id="rfc.xref.PUT.4" title="PUT">Section 4.3.4</a> 3546 3546 </td> 3547 3547 </tr> … … 4522 4522 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 3.1.4.2</a>) 4523 4523 </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 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 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 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 4.3.4</a>) 4527 4527 </p> 4528 4528 <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 4.3.6</a>) … … 4876 4876 </li> 4877 4877 <li><a id="rfc.index.G" href="#rfc.index.G"><b>G</b></a><ul> 4878 <li>GET method <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 <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> 4879 4879 <li><tt>Grammar</tt> 4880 4880 <ul> … … 4938 4938 </li> 4939 4939 <li><a id="rfc.index.H" href="#rfc.index.H"><b>H</b></a><ul> 4940 <li>HEAD method <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 <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> 4941 4941 </ul> 4942 4942 </li> … … 5040 5040 </li> 5041 5041 <li>payload <a href="#rfc.iref.p.1">3.3</a></li> 5042 <li>POST method <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 <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 <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 <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> 5044 5044 </ul> 5045 5045 </li> -
draft-ietf-httpbis/latest/p2-semantics.xml
r2556 r2561 738 738 match is found: 739 739 <list style="numbers"> 740 <t>If the request is GET or HEAD and the response status code is740 <t>If the request method is GET or HEAD and the response status code is 741 741 <x:ref>200 (OK)</x:ref>, 742 742 <x:ref>204 (No Content)</x:ref>, … … 745 745 the payload is a representation of the resource identified by the 746 746 effective request URI (&effective-request-uri;).</t> 747 <t>If the request is GET or HEAD and the response status code is747 <t>If the request method is GET or HEAD and the response status code is 748 748 <x:ref>203 (Non-Authoritative Information)</x:ref>, the payload is 749 749 a potentially modified or enhanced representation of the … … 792 792 the recipient &MAY; consider the payload to be a current representation of 793 793 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!"). 799 802 This allows authoring applications to update their local copies without 800 803 the need for a subsequent GET request.
Note: See TracChangeset
for help on using the changeset viewer.
