Changeset 2052 for draft-ietf-httpbis
- Timestamp:
- 16/12/12 03:46:23 (10 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 12 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.html
r2049 r2052 449 449 } 450 450 @bottom-center { 451 content: "Expires June 1 4, 2013";451 content: "Expires June 18, 2013"; 452 452 } 453 453 @bottom-right { … … 491 491 <meta name="dct.creator" content="Reschke, J. F."> 492 492 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p1-messaging-latest"> 493 <meta name="dct.issued" scheme="ISO8601" content="2012-12-1 1">493 <meta name="dct.issued" scheme="ISO8601" content="2012-12-15"> 494 494 <meta name="dct.replaces" content="urn:ietf:rfc:2145"> 495 495 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> … … 520 520 <tr> 521 521 <td class="left">Intended status: Standards Track</td> 522 <td class="right">December 1 1, 2012</td>522 <td class="right">December 15, 2012</td> 523 523 </tr> 524 524 <tr> 525 <td class="left">Expires: June 1 4, 2013</td>525 <td class="left">Expires: June 18, 2013</td> 526 526 <td class="right"></td> 527 527 </tr> … … 551 551 in progress”. 552 552 </p> 553 <p>This Internet-Draft will expire on June 1 4, 2013.</p>553 <p>This Internet-Draft will expire on June 18, 2013.</p> 554 554 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 555 555 <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 884 884 or an intranet-to-Internet privacy filter. Such transformations are presumed to be desired by the client (or client organization) 885 885 that selected the proxy and are beyond the scope of this specification. However, when a proxy is not intended to transform 886 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 7.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 7.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.886 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 7.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. 887 887 </p> 888 888 <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 a receiving agent that acts as a layer above some other server(s) and translates the received requests to the underlying … … 1054 1054 </p> 1055 1055 <p id="rfc.section.2.7.1.p.6">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, 1056 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 7</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.1056 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. 1057 1057 </p> 1058 1058 <p id="rfc.section.2.7.1.p.7">Although HTTP is independent of the transport protocol, the "http" scheme is specific to TCP-based services because the name … … 1154 1154 </div> 1155 1155 <div id="rfc.figure.u.14"></div><pre class="inline"><span id="rfc.iref.g.29"></span> <a href="#method" class="smpl">method</a> = <a href="#rule.token.separators" class="smpl">token</a> 1156 </pre><p id="rfc.section.3.1.1.p.5">The methods defined by this specification can be found in <a href="p2-semantics.html#methods" title="Request Methods">Section 5</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.1156 </pre><p id="rfc.section.3.1.1.p.5">The 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. 1157 1157 </p> 1158 1158 <div id="rfc.iref.r.6"></div> … … 1167 1167 </p> 1168 1168 <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 1169 it implements <em class="bcp14">SHOULD</em> respond with either a <a href="p2-semantics.html#status.405" class="smpl">405 (Method Not Allowed)</a>, if it is an origin server, or a <a href="p2-semantics.html#status.501" class="smpl">501 (Not Implemented)</a> status code. A server <em class="bcp14">MUST</em> be prepared to receive URIs of unbounded length and respond with the <a href="p2-semantics.html#status.414" class="smpl">414 (URI Too Long)</a> status code if the received request-target would be longer than the server wishes to handle (see <a href="p2-semantics.html#status.414" title="414 URI Too Long">Section 7.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>).1169 it implements <em class="bcp14">SHOULD</em> respond with either a <a href="p2-semantics.html#status.405" class="smpl">405 (Method Not Allowed)</a>, if it is an origin server, or a <a href="p2-semantics.html#status.501" class="smpl">501 (Not Implemented)</a> status code. A server <em class="bcp14">MUST</em> be prepared to receive URIs of unbounded length and respond with the <a href="p2-semantics.html#status.414" class="smpl">414 (URI Too Long)</a> status code if the received request-target would be longer than the server wishes to handle (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>). 1170 1170 </p> 1171 1171 <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. … … 1178 1178 </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 1179 1179 the client's corresponding request. The rest of the response message is to be interpreted in light of the semantics defined 1180 for that status code. See <a href="p2-semantics.html#status.codes" title="Response Status Codes">Section 7</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),1180 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), 1181 1181 the status codes defined by this specification, considerations for the definition of new status codes, and the IANA registry. 1182 1182 </p> … … 1199 1199 ; see <a href="#field.parsing" title="Field Parsing">Section 3.2.4</a> 1200 1200 </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, 1201 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 8.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.1201 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. 1202 1202 </p> 1203 1203 <h3 id="rfc.section.3.2.1"><a href="#rfc.section.3.2.1">3.2.1</a> <a id="field.extensibility" href="#field.extensibility">Field Extensibility</a></h3> … … 1207 1207 the protocol version if their defined semantics allow them to be safely ignored by recipients that do not recognize them. 1208 1208 </p> 1209 <p id="rfc.section.3.2.1.p.2">New HTTP header fields ought to be 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 9.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>. A proxy <em class="bcp14">MUST</em> forward unrecognized header fields unless the field-name is listed in the <a href="#header.connection" class="smpl">Connection</a> header field (<a href="#header.connection" id="rfc.xref.header.connection.3" title="Connection">Section 6.1</a>) or the proxy is specifically configured to block, or otherwise transform, such fields. Other recipients <em class="bcp14">SHOULD</em> ignore unrecognized header fields.1209 <p id="rfc.section.3.2.1.p.2">New HTTP header fields ought to be 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>. A proxy <em class="bcp14">MUST</em> forward unrecognized header fields unless the field-name is listed in the <a href="#header.connection" class="smpl">Connection</a> header field (<a href="#header.connection" id="rfc.xref.header.connection.3" title="Connection">Section 6.1</a>) or the proxy is specifically configured to block, or otherwise transform, such fields. Other recipients <em class="bcp14">SHOULD</em> ignore unrecognized header fields. 1210 1210 </p> 1211 1211 <h3 id="rfc.section.3.2.2"><a href="#rfc.section.3.2.2">3.2.2</a> <a id="field.order" href="#field.order">Field Order</a></h3> … … 1340 1340 </p> 1341 1341 <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 1342 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 5.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 5.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 <em class="bcp14">MUST NOT</em> include a message body. All other responses do include a message body, although the body <em class="bcp14">MAY</em> be of zero length.1342 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 <em class="bcp14">MUST NOT</em> include a message body. All other responses do include a message body, although the body <em class="bcp14">MAY</em> be of zero length. 1343 1343 </p> 1344 1344 <div id="rfc.iref.t.4"></div> … … 1382 1382 payload body. For messages that do include a payload body, the Content-Length field-value provides the framing information 1383 1383 necessary for determining where the body (and message) ends. For messages that do not include a payload body, the Content-Length 1384 indicates the size of the selected representation (<a href="p2-semantics.html#selected.representation" title="Selected Representation Header Fields">Section 8.2</a> of <a href="#Part2" id="rfc.xref.Part2.14"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>).1384 indicates the size of the selected representation (<a href="p2-semantics.html#selected.representation" title="Selected Representation Header Fields">Section 7.2</a> of <a href="#Part2" id="rfc.xref.Part2.14"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). 1385 1385 </p> 1386 1386 <div id="rfc.figure.u.28"></div><pre class="inline"><span id="rfc.iref.g.54"></span> <a href="#header.content-length" class="smpl">Content-Length</a> = 1*<a href="#core.rules" class="smpl">DIGIT</a> … … 1393 1393 anticipate such a body. 1394 1394 </p> 1395 <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 5.3.2</a> of <a href="#Part2" id="rfc.xref.Part2.15"><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 sent1395 <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.15"><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 1396 1396 in the payload body of a response if the same request had used the GET method. 1397 1397 </p> … … 1399 1399 in the payload body of a <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> response to the same request. 1400 1400 </p> 1401 <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">SHOULD 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 5.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>).1401 <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">SHOULD 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.16"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). 1402 1402 </p> 1403 1403 <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 block. This will … … 1660 1660 </p> 1661 1661 <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 1662 fields, <a href="p2-semantics.html#quality.values" title="Quality Values">Section 6.3.1</a> of <a href="#Part2" id="rfc.xref.Part2.17"><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;1662 fields, <a href="p2-semantics.html#quality.values" title="Quality Values">Section 5.3.1</a> of <a href="#Part2" id="rfc.xref.Part2.17"><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; 1663 1663 a value of 0 means "not acceptable". 1664 1664 </p> … … 1740 1740 </p> 1741 1741 <div id="authority-form"> 1742 <p id="rfc.section.5.3.p.13"><span id="rfc.iref.a.3"></span> The authority-form of request-target is only used for CONNECT requests (<a href="p2-semantics.html#CONNECT" title="CONNECT">Section 5.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>). 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) as the request-target. For example,1742 <p id="rfc.section.5.3.p.13"><span id="rfc.iref.a.3"></span> The authority-form 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.19"><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) as the request-target. For example, 1743 1743 </p> 1744 1744 </div> 1745 1745 <div id="rfc.figure.u.41"></div><pre class="text2">CONNECT www.example.com:80 HTTP/1.1 1746 1746 </pre><div id="asterisk-form"> 1747 <p id="rfc.section.5.3.p.15"><span id="rfc.iref.a.4"></span> The asterisk-form of request-target is only used for a server-wide OPTIONS request (<a href="p2-semantics.html#OPTIONS" title="OPTIONS">Section 5.3.7</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 a client wishes to request OPTIONS for the server as a whole, as opposed to a specific named resource of that server,1747 <p id="rfc.section.5.3.p.15"><span id="rfc.iref.a.4"></span> The asterisk-form 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.20"><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, 1748 1748 the client <em class="bcp14">MUST</em> send only "*" (%x2A) as the request-target. For example, 1749 1749 </p> … … 1827 1827 <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 1828 1828 messages. Hence, it relies on the order of response arrival to correspond exactly to the order in which requests are made 1829 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 7.2</a> of <a href="#Part2" id="rfc.xref.Part2.21"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>) precede a final response to the same request.1829 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.21"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>) precede a final response to the same request. 1830 1830 </p> 1831 1831 <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 … … 1997 1997 <p id="rfc.section.6.3.1.p.2">Clients which assume persistent connections and pipeline immediately after connection establishment <em class="bcp14">SHOULD</em> be prepared to retry their connection if the first pipelined attempt fails. If a client does such a retry, it <em class="bcp14">MUST NOT</em> pipeline before it knows the connection is persistent. Clients <em class="bcp14">MUST</em> also be prepared to resend their requests if the server closes the connection before sending all of the corresponding responses. 1998 1998 </p> 1999 <p id="rfc.section.6.3.1.p.3">Clients <em class="bcp14">SHOULD NOT</em> pipeline requests using non-idempotent request methods or non-idempotent sequences of request methods (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 5.2.2</a> of <a href="#Part2" id="rfc.xref.Part2.23"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). Otherwise, a premature termination of the transport connection could lead to indeterminate results. A client wishing to1999 <p id="rfc.section.6.3.1.p.3">Clients <em class="bcp14">SHOULD NOT</em> pipeline requests using non-idempotent request methods or non-idempotent sequences of request methods (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 4.2.2</a> of <a href="#Part2" id="rfc.xref.Part2.23"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). Otherwise, a premature termination of the transport connection could lead to indeterminate results. A client wishing to 2000 2000 send a non-idempotent request <em class="bcp14">SHOULD</em> wait to send that request until it has received the response status line for the previous request. 2001 2001 </p> … … 2003 2003 <p id="rfc.section.6.3.2.p.1">Connections can be closed at any time, with or without intention. Implementations ought to anticipate the need to recover 2004 2004 from asynchronous close events. A client <em class="bcp14">MAY</em> open a new connection and retransmit an aborted sequence of requests without user interaction so long as the request sequence 2005 is idempotent (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 5.2.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>). A client <em class="bcp14">MUST NOT</em> automatically retry non-idempotent request sequences, although user agents <em class="bcp14">MAY</em> offer a human operator the choice of retrying the request(s). Confirmation by user agent software with semantic understanding2005 is idempotent (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 4.2.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>). A client <em class="bcp14">MUST NOT</em> automatically retry non-idempotent request sequences, although user agents <em class="bcp14">MAY</em> offer a human operator the choice of retrying the request(s). Confirmation by user agent software with semantic understanding 2006 2006 of the application <em class="bcp14">MAY</em> substitute for user confirmation. An automatic retry <em class="bcp14">SHOULD NOT</em> be repeated if a second sequence of requests fails. 2007 2007 </p> … … 2096 2096 </p> 2097 2097 <p id="rfc.section.6.7.p.9">The Upgrade header field only applies to switching application-level protocols on the existing connection; it cannot be used 2098 to switch to a protocol on a different connection. For that purpose, 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 7.4</a> of <a href="#Part2" id="rfc.xref.Part2.25"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>).2098 to switch to a protocol on a different connection. For that purpose, 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.25"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). 2099 2099 </p> 2100 2100 <p id="rfc.section.6.7.p.10">This specification only defines the protocol name "HTTP" for use by the family of Hypertext Transfer Protocols, as defined … … 2479 2479 </p> 2480 2480 <h2 id="rfc.section.8.3"><a href="#rfc.section.8.3">8.3</a> <a id="attack.pathname" href="#attack.pathname">Attacks Based On File and Path Names</a></h2> 2481 <p id="rfc.section.8.3.p.1">Origin servers <em class="bcp14">SHOULD</em> be careful to restrict the documents returnedby HTTP requests to be only those that were intended by the server administrators.2481 <p id="rfc.section.8.3.p.1">Origin servers <em class="bcp14">SHOULD</em> be careful to restrict the documents sent by HTTP requests to be only those that were intended by the server administrators. 2482 2482 If an HTTP server translates HTTP URIs directly into file system calls, the server <em class="bcp14">MUST</em> take special care not to serve files that were not intended to be delivered to HTTP clients. For example, UNIX, Microsoft 2483 2483 Windows, and other operating systems use ".." as a path component to indicate a directory level above the current one. On … … 2512 2512 that most implementations will choose substantially higher limits. 2513 2513 </p> 2514 <p id="rfc.section.8.6.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 7.5.12</a> of <a href="#Part2" id="rfc.xref.Part2.27"><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 7.5</a> of <a href="#Part2" id="rfc.xref.Part2.28"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>).2514 <p id="rfc.section.8.6.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.27"><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.28"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). 2515 2515 </p> 2516 2516 <p id="rfc.section.8.6.p.4">Recipients <em class="bcp14">SHOULD</em> carefully limit the extent to which they read other fields, including (but not limited to) request methods, response status … … 3277 3277 <li><em>Section 3.1.2.1</em> <a href="#rfc.xref.Part2.13">3.3.1</a>, <a href="#rfc.xref.Part2.26">7.4</a></li> 3278 3278 <li><em>Section 3.3</em> <a href="#rfc.xref.Part2.22">5.7.2</a></li> 3279 <li><em>Section 5</em> <a href="#rfc.xref.Part2.6">3.1.1</a></li>3280 <li><em>Section 5.2.2</em> <a href="#rfc.xref.Part2.23">6.3.1</a>, <a href="#rfc.xref.Part2.24">6.3.2</a></li>3281 <li><em>Section 5.3.2</em> <a href="#rfc.xref.Part2.11">3.3</a>, <a href="#rfc.xref.Part2.15">3.3.2</a></li>3282 <li><em>Section 5.3.6</em> <a href="#rfc.xref.Part2.12">3.3</a>, <a href="#rfc.xref.Part2.16">3.3.2</a>, <a href="#rfc.xref.Part2.19">5.3</a></li>3283 <li><em>Section 5.3.7</em> <a href="#rfc.xref.Part2.20">5.3</a></li>3284 <li><em>Section 6.3.1</em> <a href="#rfc.xref.Part2.17">4.3</a></li>3285 <li><em>Section 7</em> <a href="#rfc.xref.Part2.5">2.7.1</a>, <a href="#rfc.xref.Part2.8">3.1.2</a></li>3286 <li><em>Section 7.2</em> <a href="#rfc.xref.Part2.21">5.6</a></li>3287 <li><em>Section 7.3.4</em> <a href="#rfc.xref.Part2.3">2.3</a></li>3288 <li><em>Section 7.4</em> <a href="#rfc.xref.Part2.25">6.7</a></li>3289 <li><em>Section 7.5</em> <a href="#rfc.xref.Part2.28">8.6</a></li>3290 <li><em>Section 7.5.12</em> <a href="#rfc.xref.Part2.7">3.1.1</a>, <a href="#rfc.xref.Part2.27">8.6</a></li>3291 <li><em>Section 8.1.1.2</em> <a href="#rfc.xref.Part2.9">3.2</a></li>3292 <li><em>Section 8.2</em> <a href="#rfc.xref.Part2.14">3.3.2</a></li>3293 <li><em>Section 9.3</em> <a href="#rfc.xref.Part2.10">3.2.1</a></li>3279 <li><em>Section 4</em> <a href="#rfc.xref.Part2.6">3.1.1</a></li> 3280 <li><em>Section 4.2.2</em> <a href="#rfc.xref.Part2.23">6.3.1</a>, <a href="#rfc.xref.Part2.24">6.3.2</a></li> 3281 <li><em>Section 4.3.2</em> <a href="#rfc.xref.Part2.11">3.3</a>, <a href="#rfc.xref.Part2.15">3.3.2</a></li> 3282 <li><em>Section 4.3.6</em> <a href="#rfc.xref.Part2.12">3.3</a>, <a href="#rfc.xref.Part2.16">3.3.2</a>, <a href="#rfc.xref.Part2.19">5.3</a></li> 3283 <li><em>Section 4.3.7</em> <a href="#rfc.xref.Part2.20">5.3</a></li> 3284 <li><em>Section 5.3.1</em> <a href="#rfc.xref.Part2.17">4.3</a></li> 3285 <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> 3286 <li><em>Section 6.2</em> <a href="#rfc.xref.Part2.21">5.6</a></li> 3287 <li><em>Section 6.3.4</em> <a href="#rfc.xref.Part2.3">2.3</a></li> 3288 <li><em>Section 6.4</em> <a href="#rfc.xref.Part2.25">6.7</a></li> 3289 <li><em>Section 6.5</em> <a href="#rfc.xref.Part2.28">8.6</a></li> 3290 <li><em>Section 6.5.12</em> <a href="#rfc.xref.Part2.7">3.1.1</a>, <a href="#rfc.xref.Part2.27">8.6</a></li> 3291 <li><em>Section 7.1.1.2</em> <a href="#rfc.xref.Part2.9">3.2</a></li> 3292 <li><em>Section 7.2</em> <a href="#rfc.xref.Part2.14">3.3.2</a></li> 3293 <li><em>Section 8.3</em> <a href="#rfc.xref.Part2.10">3.2.1</a></li> 3294 3294 <li><em>Appendix A</em> <a href="#rfc.xref.Part2.2">2.1</a></li> 3295 3295 </ul> -
draft-ietf-httpbis/latest/p1-messaging.xml
r2048 r2052 3538 3538 <t> 3539 3539 Origin servers &SHOULD; be careful to restrict 3540 the documents returnedby HTTP requests to be only those that were3540 the documents sent by HTTP requests to be only those that were 3541 3541 intended by the server administrators. If an HTTP server translates 3542 3542 HTTP URIs directly into file system calls, the server &MUST; take -
draft-ietf-httpbis/latest/p2-semantics.html
r2051 r2052 1257 1257 <h2 id="rfc.section.4.1"><a href="#rfc.section.4.1">4.1</a> <a id="method.overview" href="#method.overview">Overview</a></h2> 1258 1258 <p id="rfc.section.4.1.p.1">The request method token is the primary source of request semantics; it indicates the purpose for which the client has made 1259 this request and what is expected by the client as a successful result. The request semantics <em class="bcp14">MAY</em> be further specialized by the semantics of some header fields when present in a request (<a href="#request.header.fields" title="Request Header Fields">Section 5</a>) if those additional semantics do not conflict with the method. 1259 this request and what is expected by the client as a successful result. The request semantics might be further specialized 1260 by the semantics of some header fields when present in a request (<a href="#request.header.fields" title="Request Header Fields">Section 5</a>) if those additional semantics do not conflict with the method. 1260 1261 </p> 1261 1262 <div id="rfc.figure.u.17"></div><pre class="inline"><span id="rfc.iref.g.15"></span> <a href="#method.overview" class="smpl">method</a> = <a href="#imported.abnf" class="smpl">token</a> … … 1266 1267 </p> 1267 1268 <p id="rfc.section.4.1.p.4">Unlike distributed objects, the standardized request methods in HTTP are not resource-specific, since uniform interfaces provide 1268 for better visibility and reuse in network-based systems <a href="#REST" id="rfc.xref.REST.2"><cite title="Architectural Styles and the Design of Network-based Software Architectures">[REST]</cite></a>. Once defined, a standardized method <em class="bcp14">MUST</em> have the same semantics when applied to any resource, though each resource determines for itself whether those semantics are1269 implemented or allowed.1269 for better visibility and reuse in network-based systems <a href="#REST" id="rfc.xref.REST.2"><cite title="Architectural Styles and the Design of Network-based Software Architectures">[REST]</cite></a>. Once defined, a standardized method ought to have the same semantics when applied to any resource, though each resource 1270 determines for itself whether those semantics are implemented or allowed. 1270 1271 </p> 1271 1272 <p id="rfc.section.4.1.p.5">This specification defines a number of standardized methods that are commonly used in HTTP, as outlined by the following table. … … 1326 1327 </table> 1327 1328 </div> 1328 <p id="rfc.section.4.1.p.6"> The methods GET and HEAD <em class="bcp14">MUST</em> be supported by all general-purpose servers. All other methods are <em class="bcp14">OPTIONAL</em>. When implemented, a server <em class="bcp14">MUST</em> implement the above methods according to the semantics defined for them in <a href="#method.definitions" title="Method Definitions">Section 4.3</a>.1329 </p> 1330 <p id="rfc.section.4.1.p.7">Additional methods <em class="bcp14">MAY</em> be used in HTTP; many have already been standardized outside the scope of this specification and ought to be registered within1331 t he HTTP Method Registry maintained by IANA, as defined in <a href="#method.registry" title="Method Registry">Section 8.1</a>.1329 <p id="rfc.section.4.1.p.6">All general-purpose servers <em class="bcp14">MUST</em> support the methods GET and HEAD. All other methods are <em class="bcp14">OPTIONAL</em>; when implemented, a server <em class="bcp14">MUST</em> implement the above methods according to the semantics defined for them in <a href="#method.definitions" title="Method Definitions">Section 4.3</a>. 1330 </p> 1331 <p id="rfc.section.4.1.p.7">Additional methods, outside the scope of this specification, have been standardized for use in HTTP. All such methods ought 1332 to be registered within the HTTP Method Registry maintained by IANA, as defined in <a href="#method.registry" title="Method Registry">Section 8.1</a>. 1332 1333 </p> 1333 1334 <p id="rfc.section.4.1.p.8">The set of methods allowed by a target resource can be listed in an <a href="#header.allow" class="smpl">Allow</a> header field (<a href="#header.allow" id="rfc.xref.header.allow.1" title="Allow">Section 7.4.1</a>). However, the set of allowed methods can change dynamically. When a request message is received that is unrecognized or … … 1349 1350 the Web will often have the side-effect of charging an advertising account. 1350 1351 </p> 1351 <p id="rfc.section.4.2.1.p.3"> The GET, HEAD, OPTIONS, and TRACE requestmethods are defined to be safe.</p>1352 <p id="rfc.section.4.2.1.p.3">Of the request methods defined by this specification, the GET, HEAD, OPTIONS, and TRACE methods are defined to be safe.</p> 1352 1353 <p id="rfc.section.4.2.1.p.4">The purpose of distinguishing between safe and unsafe methods is to allow automated retrieval processes (spiders) and cache 1353 1354 performance optimization (pre-fetching) to work without fear of causing harm. In addition, it allows a user agent to apply … … 1366 1367 <div id="rfc.iref.i.1"></div> 1367 1368 <h3 id="rfc.section.4.2.2"><a href="#rfc.section.4.2.2">4.2.2</a> <a id="idempotent.methods" href="#idempotent.methods">Idempotent Methods</a></h3> 1368 <p id="rfc.section.4.2.2.p.1">Request methods are considered "<dfn id="idempotent">idempotent</dfn>" if the intended effect of multiple identical requests is the same as for a single request. PUT, DELETE, and all safe request1369 methods are idempotent.1369 <p id="rfc.section.4.2.2.p.1">Request methods are considered "<dfn id="idempotent">idempotent</dfn>" if the intended effect of multiple identical requests is the same as for a single request. Of the request methods defined 1370 by this specification, the PUT, DELETE, and safe request methods are idempotent. 1370 1371 </p> 1371 1372 <p id="rfc.section.4.2.2.p.2">Like the definition of safe, the idempotent property only applies to what has been requested by the user; a server is free … … 1390 1391 <div id="rfc.iref.g.16"></div> 1391 1392 <p id="rfc.section.4.3.1.p.1">The GET method requests transfer of a current representation of the target resource.</p> 1392 <p id="rfc.section.4.3.1.p.2">If the target resource is a data-producing process, it is the produced data which shall be returned as the representation1393 in the response and not the source textof the process, unless that text happens to be the output of the process.1393 <p id="rfc.section.4.3.1.p.2">If the target resource is a data-producing process, the produced data will be sent as the representation, not the source text 1394 of the process, unless that text happens to be the output of the process. 1394 1395 </p> 1395 1396 <p id="rfc.section.4.3.1.p.3">The semantics of the GET method change to a "conditional GET" if the request message includes an <a href="p4-conditional.html#header.if-modified-since" class="smpl">If-Modified-Since</a>, <a href="p4-conditional.html#header.if-unmodified-since" class="smpl">If-Unmodified-Since</a>, <a href="p4-conditional.html#header.if-match" class="smpl">If-Match</a>, <a href="p4-conditional.html#header.if-none-match" class="smpl">If-None-Match</a>, or <a href="p5-range.html#header.if-range" class="smpl">If-Range</a> header field (<a href="#Part4" id="rfc.xref.Part4.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a>). A conditional GET requests that the representation be transferred only under the circumstances described by the conditional … … 1409 1410 <h3 id="rfc.section.4.3.2"><a href="#rfc.section.4.3.2">4.3.2</a> <a id="HEAD" href="#HEAD">HEAD</a></h3> 1410 1411 <div id="rfc.iref.h.1"></div> 1411 <p id="rfc.section.4.3.2.p.1">The HEAD method is identical to GET except that the server <em class="bcp14">MUST NOT</em> returna message body in the response. The metadata contained in the HTTP header fields in response to a HEAD request <em class="bcp14">SHOULD</em> be identical to the information sent in response to a GET request. This method can be used for obtaining metadata about the1412 <p id="rfc.section.4.3.2.p.1">The HEAD method is identical to GET except that the server <em class="bcp14">MUST NOT</em> send a message body in the response. The metadata contained in the HTTP header fields in response to a HEAD request <em class="bcp14">SHOULD</em> be identical to the information sent in response to a GET request. This method can be used for obtaining metadata about the 1412 1413 representation implied by the request without transferring the representation data. This method is often used for testing 1413 1414 hypertext links for validity, accessibility, and recent modification. … … 1421 1422 <h3 id="rfc.section.4.3.3"><a href="#rfc.section.4.3.3">4.3.3</a> <a id="POST" href="#POST">POST</a></h3> 1422 1423 <p id="rfc.section.4.3.3.p.1">The POST method requests that the origin server accept the representation enclosed in the request as data to be processed 1423 by the target resource. POST is designed to allow a uniform method to cover the following functions:1424 by the target resource. For example, POST is frequently used for the following functions (among others): 1424 1425 </p> 1425 1426 <ul> … … 1429 1430 <li>Extending a database through an append operation.</li> 1430 1431 </ul> 1431 <p id="rfc.section.4.3.3.p.2">The actual function performed by the POST method is determined by the server and is usually dependent on the effective request1432 URI.1432 <p id="rfc.section.4.3.3.p.2">The actual function performed by the POST method is determined by the origin server and is usually dependent on the effective 1433 request URI. 1433 1434 </p> 1434 1435 <p id="rfc.section.4.3.3.p.3">The action performed by the POST method might not result in a resource that can be identified by a URI. In this case, either <a href="#status.200" class="smpl">200 (OK)</a> or <a href="#status.204" class="smpl">204 (No Content)</a> is the appropriate response status code, depending on whether or not the response includes a representation that describes 1435 1436 the result. 1436 1437 </p> 1437 <p id="rfc.section.4.3.3.p.4">If a resource has been created on the origin server, the response <em class="bcp14">SHOULD</em> be <a href="#status.201" class="smpl">201 (Created)</a> and contain a representation which describes the status of the request and refers to the new resource, and a <a href="#header.location" class="smpl">Location</a> header field (see <a href="#header.location" id="rfc.xref.header.location.1" title="Location">Section 7.1.2</a>).1438 <p id="rfc.section.4.3.3.p.4">If one or more resources has been created on the origin server, the response <em class="bcp14">SHOULD</em> be <a href="#status.201" class="smpl">201 (Created)</a>, contain a representation which describes the status of the request and refers to the new resource(s), and include a <a href="#header.location" class="smpl">Location</a> header field that provides an identifier for the primary resource created (see <a href="#header.location" id="rfc.xref.header.location.1" title="Location">Section 7.1.2</a>). 1438 1439 </p> 1439 1440 <p id="rfc.section.4.3.3.p.5">Responses to POST requests are only cacheable when they include explicit freshness information (see <a href="p6-cache.html#calculating.freshness.lifetime" title="Calculating Freshness Lifetime">Section 4.1.1</a> of <a href="#Part6" id="rfc.xref.Part6.5"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>). A cached POST response with a <a href="#header.content-location" class="smpl">Content-Location</a> header field (see <a href="#header.content-location" id="rfc.xref.header.content-location.2" title="Content-Location">Section 3.1.4.2</a>) whose value is the effective Request URI <em class="bcp14">MAY</em> be used to satisfy subsequent GET and HEAD (not POST) requests. … … 1445 1446 <p id="rfc.section.4.3.4.p.1">The PUT method requests that the state of the target resource be created or replaced with the state defined by the representation 1446 1447 enclosed in the request message payload. A successful PUT of a given representation would suggest that a subsequent GET on 1447 that same target resource will result in an equivalent representation being returnedin a <a href="#status.200" class="smpl">200 (OK)</a> response. However, there is no guarantee that such a state change will be observable, since the target resource might be acted1448 that same target resource will result in an equivalent representation being sent in a <a href="#status.200" class="smpl">200 (OK)</a> response. However, there is no guarantee that such a state change will be observable, since the target resource might be acted 1448 1449 upon by other user agents in parallel, or might be subject to dynamic processing by the origin server, before any subsequent 1449 1450 GET is received. A successful response only implies that the user agent's intent was achieved at the time of its processing … … 1453 1454 with the state of the enclosed representation, then either a <a href="#status.200" class="smpl">200 (OK)</a> or <a href="#status.204" class="smpl">204 (No Content)</a> response <em class="bcp14">SHOULD</em> be sent to indicate successful completion of the request. 1454 1455 </p> 1455 <p id="rfc.section.4.3.4.p.3"> Unrecognized header fields <em class="bcp14">SHOULD</em> be ignored (i.e., not savedas part of the resource state).1456 <p id="rfc.section.4.3.4.p.3">An origin server <em class="bcp14">SHOULD</em> ignore unrecognized header fields received in a PUT request (i.e., do not save them as part of the resource state). 1456 1457 </p> 1457 1458 <p id="rfc.section.4.3.4.p.4">An origin server <em class="bcp14">SHOULD</em> verify that the PUT representation is consistent with any constraints which the server has for the target resource that cannot … … 1506 1507 <h3 id="rfc.section.4.3.5"><a href="#rfc.section.4.3.5">4.3.5</a> <a id="DELETE" href="#DELETE">DELETE</a></h3> 1507 1508 <div id="rfc.iref.d.2"></div> 1508 <p id="rfc.section.4.3.5.p.1">The DELETE method requests that the origin server delete the target resource. This method <em class="bcp14">MAY</em> be overridden by human intervention (or other means) on the origin server. The client cannot be guaranteed that the operation 1509 has been carried out, even if the status code returned from the origin server indicates that the action has been completed 1510 successfully. However, the server <em class="bcp14">SHOULD NOT</em> indicate success unless, at the time the response is given, it intends to delete the resource or move it to an inaccessible 1511 location. 1512 </p> 1513 <p id="rfc.section.4.3.5.p.2">A successful response <em class="bcp14">SHOULD</em> be <a href="#status.200" class="smpl">200 (OK)</a> if the response includes a representation describing the status, <a href="#status.202" class="smpl">202 (Accepted)</a> if the action has not yet been enacted, or <a href="#status.204" class="smpl">204 (No Content)</a> if the action has been enacted but the response does not include a representation. 1514 </p> 1515 <p id="rfc.section.4.3.5.p.3">A payload within a DELETE request message has no defined semantics; sending a payload body on a DELETE request might cause 1509 <p id="rfc.section.4.3.5.p.1">The DELETE method requests that the origin server remove the association between the target resource and its current representations 1510 or implementation. In effect, this method is similar to the rm command in UNIX: it expresses a deletion operation on the URI 1511 mapping of the origin server, rather than an expectation that the information be deleted. The representations might or might 1512 not be destroyed by the origin server, and the associated storage might or might not be reclaimed, depending entirely on the 1513 nature of the resource and its implementation by the origin server (which are beyond the scope of this specification). 1514 </p> 1515 <p id="rfc.section.4.3.5.p.2">Relatively few resources allow the DELETE method — its primary use is for remote authoring environments, where the user has 1516 some direction regarding its effect. For example, a resource that was previously created using a PUT request, or identified 1517 via the Location header field after a <a href="#status.201" class="smpl">201 (Created)</a> response to a POST request, might allow a corresponding DELETE request to undo those actions. Similarly, custom user agent 1518 implementations that implement an authoring function, such as revision control clients using HTTP for remote operations, might 1519 use DELETE based on an assumption that the server's URI space has been crafted to correspond to a version repository. 1520 </p> 1521 <p id="rfc.section.4.3.5.p.3">If a DELETE method is successfully applied, the origin server <em class="bcp14">SHOULD</em> send a <a href="#status.202" class="smpl">202 (Accepted)</a> status code if the action seems okay but has not yet been enacted, or a <a href="#status.204" class="smpl">204 (No Content)</a> status code if the action has been enacted and no further information is to be supplied, or a <a href="#status.200" class="smpl">200 (OK)</a> status code if the action has been enacted and the response message includes a representation describing the status. 1522 </p> 1523 <p id="rfc.section.4.3.5.p.4">A payload within a DELETE request message has no defined semantics; sending a payload body on a DELETE request might cause 1516 1524 some existing implementations to reject the request. 1517 1525 </p> 1518 <p id="rfc.section.4.3.5.p. 4">Responses to the DELETE method are not cacheable. If a DELETE request passes through a cache that has one or more stored responses1526 <p id="rfc.section.4.3.5.p.5">Responses to the DELETE method are not cacheable. If a DELETE request passes through a cache that has one or more stored responses 1519 1527 for the effective request URI, those stored responses will be invalidated (see <a href="p6-cache.html#invalidation.after.updates.or.deletions" title="Request Methods that Invalidate">Section 6</a> of <a href="#Part6" id="rfc.xref.Part6.7"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>). 1520 1528 </p> 1521 1529 <div id="rfc.iref.c.9"></div> 1522 1530 <h3 id="rfc.section.4.3.6"><a href="#rfc.section.4.3.6">4.3.6</a> <a id="CONNECT" href="#CONNECT">CONNECT</a></h3> 1523 <p id="rfc.section.4.3.6.p.1">The CONNECT method requests that the proxy establish a tunnel to the request-target and, if successful, thereafter restrict 1524 its behavior to blind forwarding of packets until the connection is closed. 1525 </p> 1526 <p id="rfc.section.4.3.6.p.2">When using CONNECT, the request-target <em class="bcp14">MUST</em> use the authority form (<a href="p1-messaging.html#request-target" title="Request Target">Section 5.3</a> of <a href="#Part1" id="rfc.xref.Part1.15"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>); i.e., the request-target consists of only the host name and port number of the tunnel destination, separated by a colon. 1531 <p id="rfc.section.4.3.6.p.1">The CONNECT method is only applicable as a request to a proxy. A CONNECT requests that the recipient establish a tunnel to 1532 the destination origin server identified by the request-target and, if successful, thereafter restrict its behavior to blind 1533 forwarding of packets, in both directions, until the connection is closed. 1534 </p> 1535 <p id="rfc.section.4.3.6.p.2">A client sending a CONNECT request <em class="bcp14">MUST</em> send the authority form of request-target (<a href="p1-messaging.html#request-target" title="Request Target">Section 5.3</a> of <a href="#Part1" id="rfc.xref.Part1.15"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>); i.e., the request-target consists of only the host name and port number of the tunnel destination, separated by a colon. 1527 1536 For example, 1528 1537 </p> … … 1530 1539 Host: server.example.com:80 1531 1540 1532 </pre><p id="rfc.section.4.3.6.p.4">Any <a href="#status.2xx" class="smpl">2xx (Successful)</a> response to a CONNECT request indicates that the proxy has established a connection to the requested host and port, and has 1533 switched to tunneling the current connection to that server connection. The tunneled data from the server begins immediately 1534 after the blank line that concludes the successful response's header block. 1541 </pre><p id="rfc.section.4.3.6.p.4">The recipient proxy can establish a tunnel either by directly connecting to the request-target or, if configured to use another 1542 proxy, by forwarding the CONNECT request to the next inbound proxy. Any <a href="#status.2xx" class="smpl">2xx (Successful)</a> response to a CONNECT request indicates that the sender (and any inbound proxies) will switch to tunnel mode immediately after 1543 the blank line that concludes the successful response's header block; data received after that blank line is from the server 1544 identified by the request-target. 1535 1545 </p> 1536 1546 <p id="rfc.section.4.3.6.p.5">A server <em class="bcp14">SHOULD NOT</em> send any <a href="p1-messaging.html#header.transfer-encoding" class="smpl">Transfer-Encoding</a> or <a href="p1-messaging.html#header.content-length" class="smpl">Content-Length</a> header fields in a successful response. A client <em class="bcp14">MUST</em> ignore any Content-Length or Transfer-Encoding header fields received in a successful response. … … 1539 1549 governed by HTTP. 1540 1550 </p> 1541 <p id="rfc.section.4.3.6.p.7">Proxy authentication might be used to establish the authority to create a tunnel :</p>1551 <p id="rfc.section.4.3.6.p.7">Proxy authentication might be used to establish the authority to create a tunnel. For example,</p> 1542 1552 <div id="rfc.figure.u.19"></div><pre class="text2">CONNECT server.example.com:80 HTTP/1.1 1543 1553 Host: server.example.com:80 … … 1547 1557 some existing implementations to reject the request. 1548 1558 </p> 1549 <p id="rfc.section.4.3.6.p.10">Similar to a pipelined HTTP/1.1 request, data to be tunneled from client to server <em class="bcp14">MAY</em> be sent immediately after the request (before a response is received). The usual caveats also apply: data can be discarded 1550 if the eventual response is negative, and the connection can be reset with no response if more than one TCP segment is outstanding. 1551 </p> 1552 <p id="rfc.section.4.3.6.p.11">It might be the case that the proxy itself can only reach the requested origin server through another proxy. In this case, 1553 the first proxy <em class="bcp14">SHOULD</em> make a CONNECT request of that next proxy, requesting a tunnel to the authority. A proxy <em class="bcp14">MUST NOT</em> respond with any <a href="#status.2xx" class="smpl">2xx</a> status code unless it has either a direct or tunnel connection established to the authority. 1554 </p> 1555 <p id="rfc.section.4.3.6.p.12">If at any point either one of the peers gets disconnected, any outstanding data that came from that peer will be passed to 1556 the other one, and after that also the other connection will be terminated by the proxy. If there is outstanding data to that 1557 peer undelivered, that data will be discarded. 1558 </p> 1559 <p id="rfc.section.4.3.6.p.13">An origin server which receives a CONNECT request for itself <em class="bcp14">MAY</em> respond with a <a href="#status.2xx" class="smpl">2xx</a> status code to indicate that a connection is established. However, most origin servers do not implement CONNECT. 1559 <p id="rfc.section.4.3.6.p.10">When a tunnel intermediary detects that either side has closed its connection, any outstanding data that came from that side 1560 will first be sent to the other side and then the intermediary will close both connections. If there is outstanding data left 1561 undelivered, that data will be discarded. 1562 </p> 1563 <p id="rfc.section.4.3.6.p.11">An origin server which receives a CONNECT request for itself <em class="bcp14">MAY</em> respond with a <a href="#status.2xx" class="smpl">2xx</a> status code to indicate that a connection is established. However, most origin servers do not implement CONNECT. 1560 1564 </p> 1561 1565 <h3 id="rfc.section.4.3.7"><a href="#rfc.section.4.3.7">4.3.7</a> <a id="OPTIONS" href="#OPTIONS">OPTIONS</a></h3> … … 1683 1687 <p id="rfc.section.5.1.2.1.p.4">Requirements for HTTP/1.1 origin servers: </p> 1684 1688 <ul> 1685 <li>Upon receiving a request which includes an <a href="#header.expect" class="smpl">Expect</a> header field with the "100-continue" expectation, an origin server <em class="bcp14">MUST</em> either respond with <a href="#status.100" class="smpl">100 (Continue)</a> status code and continue to read from the input stream, or respond with a final status code. The origin server <em class="bcp14">MUST NOT</em> wait for the payload body before sending the <a href="#status.100" class="smpl">100 (Continue)</a> response. If it responds with a final status code, it <em class="bcp14">MAY</em> close the transport connection or it <em class="bcp14">MAY</em> continue to read and discard the rest of the request. It <em class="bcp14">MUST NOT</em> perform the request method if it returns a final status code.1689 <li>Upon receiving a request which includes an <a href="#header.expect" class="smpl">Expect</a> header field with the "100-continue" expectation, an origin server <em class="bcp14">MUST</em> either respond with <a href="#status.100" class="smpl">100 (Continue)</a> status code and continue to read from the input stream, or respond with a final status code. The origin server <em class="bcp14">MUST NOT</em> wait for the payload body before sending the <a href="#status.100" class="smpl">100 (Continue)</a> response. If the origin server responds with a final status code, it <em class="bcp14">MUST NOT</em> have performed the request method and <em class="bcp14">MAY</em> either close the connection or continue to read and discard the rest of the request. 1686 1690 </li> 1687 1691 <li>An origin server <em class="bcp14">SHOULD NOT</em> send a <a href="#status.100" class="smpl">100 (Continue)</a> response if the request message does not include an <a href="#header.expect" class="smpl">Expect</a> header field with the "100-continue" expectation, and <em class="bcp14">MUST NOT</em> send a <a href="#status.100" class="smpl">100 (Continue)</a> response if such a request comes from an HTTP/1.0 (or earlier) client. There is an exception to this rule: for compatibility … … 2382 2386 <div id="rfc.iref.72"></div> 2383 2387 <h3 id="rfc.section.6.3.1"><a href="#rfc.section.6.3.1">6.3.1</a> <a id="status.200" href="#status.200">200 OK</a></h3> 2384 <p id="rfc.section.6.3.1.p.1">The request has succeeded. The payload returned withthe response is dependent on the method used in the request, for example: </p>2388 <p id="rfc.section.6.3.1.p.1">The request has succeeded. The payload sent in the response is dependent on the method used in the request, for example: </p> 2385 2389 <dl> 2386 2390 <dt>GET</dt> … … 2402 2406 (e.g., in the case of a response to a PUT request). 2403 2407 </p> 2404 <p id="rfc.section.6.3.2.p.3">The origin server <em class="bcp14">MUST</em> create the resource(s) before returning the 201 status code. If the action cannot be carried out immediately, the server <em class="bcp14">SHOULD</em> respond with a <a href="#status.202" class="smpl">202 (Accepted)</a> response instead.2408 <p id="rfc.section.6.3.2.p.3">The origin server <em class="bcp14">MUST</em> create the resource(s) before sending the 201 status code. If the action cannot be carried out immediately, the server <em class="bcp14">SHOULD</em> respond with a <a href="#status.202" class="smpl">202 (Accepted)</a> response instead. 2405 2409 </p> 2406 2410 <p id="rfc.section.6.3.2.p.4">A 201 response <em class="bcp14">MAY</em> contain an <a href="p4-conditional.html#header.etag" class="smpl">ETag</a> response header field indicating the current value of the entity-tag for the representation of the resource identified by … … 2415 2419 <p id="rfc.section.6.3.3.p.2">The 202 response is intentionally non-committal. Its purpose is to allow a server to accept a request for some other process 2416 2420 (perhaps a batch-oriented process that is only run once per day) without requiring that the user agent's connection to the 2417 server persist until the process is completed. The representation returnedwith this response <em class="bcp14">SHOULD</em> include an indication of the request's current status and either a pointer to a status monitor or some estimate of when the2421 server persist until the process is completed. The representation sent with this response <em class="bcp14">SHOULD</em> include an indication of the request's current status and either a pointer to a status monitor or some estimate of when the 2418 2422 user can expect the request to be fulfilled. 2419 2423 </p> … … 2429 2433 <h3 id="rfc.section.6.3.5"><a href="#rfc.section.6.3.5">6.3.5</a> <a id="status.204" href="#status.204">204 No Content</a></h3> 2430 2434 <p id="rfc.section.6.3.5.p.1">The 204 (No Content) status code indicates that the server has successfully fulfilled the request and that there is no additional 2431 content to returnin the response payload body. Metadata in the response header fields refer to the target resource and its2435 content to send in the response payload body. Metadata in the response header fields refer to the target resource and its 2432 2436 current representation after the requested action. 2433 2437 </p> … … 2514 2518 <div id="rfc.iref.73"></div> 2515 2519 <h3 id="rfc.section.6.4.2"><a href="#rfc.section.6.4.2">6.4.2</a> <a id="status.301" href="#status.301">301 Moved Permanently</a></h3> 2516 <p id="rfc.section.6.4.2.p.1">The target resource has been assigned a new permanent URI and any future references to this resource <em class="bcp14">SHOULD</em> use one of the returned URIs. Clients with link editing capabilities ought to automatically re-link references to the effective2517 request URI to one or more of the new references returnedby the server, where possible.2520 <p id="rfc.section.6.4.2.p.1">The target resource has been assigned a new permanent URI and any future references to this resource <em class="bcp14">SHOULD</em> use one of the enclosed URIs. Clients with link editing capabilities ought to automatically re-link references to the effective 2521 request URI to one or more of the new references sent by the server, where possible. 2518 2522 </p> 2519 2523 <p id="rfc.section.6.4.2.p.2">Caches <em class="bcp14">MAY</em> use a heuristic (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 4.1.2</a> of <a href="#Part6" id="rfc.xref.Part6.11"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>) to determine freshness for 301 responses. … … 2617 2621 </p> 2618 2622 <div class="note" id="rfc.section.6.5.6.p.3"> 2619 <p> <b>Note:</b> HTTP/1.1 servers are allowed to returnresponses which are not acceptable according to the accept header fields sent in the2623 <p> <b>Note:</b> HTTP/1.1 servers are allowed to send responses which are not acceptable according to the accept header fields sent in the 2620 2624 request. In some cases, this might even be preferable to sending a 406 response. User agents are encouraged to inspect the 2621 2625 header fields of an incoming response to determine if it is acceptable. … … 2737 2741 </p> 2738 2742 <div class="note" id="rfc.section.6.6.5.p.2"> 2739 <p> <b>Note</b> to implementers: some deployed proxies are known to return<a href="#status.400" class="smpl">400 (Bad Request)</a> or <a href="#status.500" class="smpl">500 (Internal Server2743 <p> <b>Note</b> to implementers: some deployed proxies are known to send <a href="#status.400" class="smpl">400 (Bad Request)</a> or <a href="#status.500" class="smpl">500 (Internal Server 2740 2744 Error)</a> when DNS lookups time out. 2741 2745 </p> -
draft-ietf-httpbis/latest/p2-semantics.xml
r2051 r2052 1046 1046 it indicates the purpose for which the client has made this request 1047 1047 and what is expected by the client as a successful result. The request 1048 semantics &MAY;be further specialized by the semantics of some header1048 semantics might be further specialized by the semantics of some header 1049 1049 fields when present in a request (<xref target="request.header.fields"/>) 1050 1050 if those additional semantics do not conflict with the method. … … 1065 1065 not resource-specific, since uniform interfaces provide for better 1066 1066 visibility and reuse in network-based systems <xref target="REST"/>. 1067 Once defined, a standardized method &MUST;have the same semantics when1067 Once defined, a standardized method ought to have the same semantics when 1068 1068 applied to any resource, though each resource determines for itself 1069 1069 whether those semantics are implemented or allowed. … … 1105 1105 </texttable> 1106 1106 <t> 1107 The methods GET and HEAD &MUST; be supported by all general-purpose1108 servers. All other methods are &OPTIONAL;.1109 When implemented, a server &MUST; implement the above methods according1110 to the semantics defined for themin <xref target="method.definitions"/>.1111 </t> 1112 <t> 1113 Additional methods &MAY; be used in HTTP; many have alreadybeen1114 standardized outside the scope of this specification and ought to be1115 registered within the HTTP Method Registry maintained by IANA, as defined1116 in<xref target="method.registry"/>.1107 All general-purpose servers &MUST; support the methods GET and HEAD. 1108 All other methods are &OPTIONAL;; when implemented, a server &MUST; 1109 implement the above methods according to the semantics defined for them 1110 in <xref target="method.definitions"/>. 1111 </t> 1112 <t> 1113 Additional methods, outside the scope of this specification, have been 1114 standardized for use in HTTP. All such methods ought to be registered 1115 within the HTTP Method Registry maintained by IANA, as defined in 1116 <xref target="method.registry"/>. 1117 1117 </t> 1118 1118 <t> … … 1155 1155 </t> 1156 1156 <t> 1157 The GET, HEAD, OPTIONS, and TRACE request methods are defined to be safe. 1157 Of the request methods defined by this specification, the 1158 GET, HEAD, OPTIONS, and TRACE methods are defined to be safe. 1158 1159 </t> 1159 1160 <t> … … 1192 1193 "<x:dfn anchor="idempotent">idempotent</x:dfn>" if the intended effect 1193 1194 of multiple identical requests is the same as for a single request. 1194 PUT, DELETE, and all safe request methods are idempotent. 1195 Of the request methods defined by this specification, the 1196 PUT, DELETE, and safe request methods are idempotent. 1195 1197 </t> 1196 1198 <t> … … 1240 1242 </t> 1241 1243 <t> 1242 If the target resource is a data-producing process, it is the 1243 produced data which shall be returned as the representation in the response and not 1244 the source text of the process, unless that text happens to be the output of 1245 the process. 1244 If the target resource is a data-producing process, the produced data will 1245 be sent as the representation, not the source text of the process, 1246 unless that text happens to be the output of the process. 1246 1247 </t> 1247 1248 <t> … … 1287 1288 <t> 1288 1289 The HEAD method is identical to GET except that the server &MUST-NOT; 1289 returna message body in the response. The metadata contained1290 send a message body in the response. The metadata contained 1290 1291 in the HTTP header fields in response to a HEAD request &SHOULD; be identical 1291 1292 to the information sent in response to a GET request. This method can … … 1312 1313 The POST method requests that the origin server accept the 1313 1314 representation enclosed in the request as data to be processed by the 1314 target resource. POST is designed to allow a uniform method to cover the1315 f ollowing functions:1315 target resource. For example, POST is frequently used for the following 1316 functions (among others): 1316 1317 <list style="symbols"> 1317 1318 <t> … … 1333 1334 <t> 1334 1335 The actual function performed by the POST method is determined by the 1335 server and is usually dependent on the effective request URI.1336 origin server and is usually dependent on the effective request URI. 1336 1337 </t> 1337 1338 <t> … … 1343 1344 </t> 1344 1345 <t> 1345 If a resource has been created on the origin server, the response 1346 &SHOULD; be <x:ref>201 (Created)</x:ref> and contain a representation which 1347 describes the status of the request and refers to the new resource, and a 1348 <x:ref>Location</x:ref> header field (see <xref target="header.location"/>). 1346 If one or more resources has been created on the origin server, the response 1347 &SHOULD; be <x:ref>201 (Created)</x:ref>, contain a representation which 1348 describes the status of the request and refers to the new resource(s), and 1349 include a <x:ref>Location</x:ref> header field that provides an identifier 1350 for the primary resource created (see <xref target="header.location"/>). 1349 1351 </t> 1350 1352 <t> … … 1372 1374 enclosed in the request message payload. A successful PUT of a given 1373 1375 representation would suggest that a subsequent GET on that same target 1374 resource will result in an equivalent representation being returnedin1376 resource will result in an equivalent representation being sent in 1375 1377 a <x:ref>200 (OK)</x:ref> response. However, there is no guarantee that 1376 1378 such a state change will be observable, since the target resource might be … … 1390 1392 </t> 1391 1393 <t> 1392 Unrecognized header fields &SHOULD; be ignored (i.e., not saved1393 as part of the resource state).1394 An origin server &SHOULD; ignore unrecognized header fields received in a 1395 PUT request (i.e., do not save them as part of the resource state). 1394 1396 </t> 1395 1397 <t> … … 1495 1497 <iref primary="true" item="DELETE method" x:for-anchor=""/> 1496 1498 <t> 1497 The DELETE method requests that the origin server delete the target 1498 resource. This method &MAY; be overridden by 1499 human intervention (or other means) on the origin server. The client cannot 1500 be guaranteed that the operation has been carried out, even if the 1501 status code returned from the origin server indicates that the action 1502 has been completed successfully. However, the server &SHOULD-NOT; 1503 indicate success unless, at the time the response is given, it 1504 intends to delete the resource or move it to an inaccessible 1505 location. 1506 </t> 1507 <t> 1508 A successful response &SHOULD; be <x:ref>200 (OK)</x:ref> if the response 1509 includes a representation describing the status, <x:ref>202 (Accepted)</x:ref> 1510 if the action has not yet been enacted, or <x:ref>204 (No Content)</x:ref> if 1511 the action has been enacted but the response does not include a representation. 1499 The DELETE method requests that the origin server remove the association 1500 between the target resource and its current representations or 1501 implementation. In effect, this method is similar to the rm command in 1502 UNIX: it expresses a deletion operation on the URI mapping of the 1503 origin server, rather than an expectation that the information be deleted. 1504 The representations might or might not be destroyed by the origin server, 1505 and the associated storage might or might not be reclaimed, depending 1506 entirely on the nature of the resource and its implementation by the 1507 origin server (which are beyond the scope of this specification). 1508 </t> 1509 <t> 1510 Relatively few resources allow the DELETE method — its primary use 1511 is for remote authoring environments, where the user has some direction 1512 regarding its effect. For example, a resource that was previously created 1513 using a PUT request, or identified via the Location header field after a 1514 <x:ref>201 (Created)</x:ref> response to a POST request, might allow a 1515 corresponding DELETE request to undo those actions. Similarly, custom 1516 user agent implementations that implement an authoring function, such as 1517 revision control clients using HTTP for remote operations, might use 1518 DELETE based on an assumption that the server's URI space has been crafted 1519 to correspond to a version repository. 1520 </t> 1521 <t> 1522 If a DELETE method is successfully applied, the origin server &SHOULD; send 1523 a <x:ref>202 (Accepted)</x:ref> status code if the action seems okay but 1524 has not yet been enacted, or 1525 a <x:ref>204 (No Content)</x:ref> status code if the action has been 1526 enacted and no further information is to be supplied, or 1527 a <x:ref>200 (OK)</x:ref> status code if the action has been enacted and 1528 the response message includes a representation describing the status. 1512 1529 </t> 1513 1530 <t> … … 1527 1544 <iref primary="true" item="CONNECT method" x:for-anchor=""/> 1528 1545 <t> 1529 The CONNECT method requests that the proxy establish a tunnel 1530 to the request-target and, if successful, thereafter restrict its behavior 1531 to blind forwarding of packets until the connection is closed. 1532 </t> 1533 <t> 1534 When using CONNECT, the request-target &MUST; use the authority form 1535 (&request-target;); i.e., the request-target consists of only the 1536 host name and port number of the tunnel destination, separated by a colon. 1537 For example, 1546 The CONNECT method is only applicable as a request to a proxy. 1547 A CONNECT requests that the recipient establish a tunnel to the destination 1548 origin server identified by the request-target and, if successful, 1549 thereafter restrict its behavior to blind forwarding of packets, in 1550 both directions, until the connection is closed. 1551 </t> 1552 <t> 1553 A client sending a CONNECT request &MUST; send the authority form of 1554 request-target (&request-target;); i.e., the request-target consists 1555 of only the host name and port number of the tunnel destination, separated 1556 by a colon. For example, 1538 1557 </t> 1539 1558 <figure><artwork type="message/http; msgtype="request"" x:indent-with=" "> … … 1543 1562 </artwork></figure> 1544 1563 <t> 1545 Any <x:ref>2xx (Successful)</x:ref> response to a CONNECT request indicates that the 1546 proxy has established a connection to the requested host and port, 1547 and has switched to tunneling the current connection to that server 1548 connection. 1549 The tunneled data from the server begins immediately after the blank line 1550 that concludes the successful response's header block. 1564 The recipient proxy can establish a tunnel either by directly connecting to 1565 the request-target or, if configured to use another proxy, by forwarding 1566 the CONNECT request to the next inbound proxy. 1567 Any <x:ref>2xx (Successful)</x:ref> response to a CONNECT request indicates 1568 that the sender (and any inbound proxies) will switch to tunnel mode 1569 immediately after the blank line that concludes the successful response's 1570 header block; data received after that blank line is from the server 1571 identified by the request-target. 1551 1572 </t> 1552 1573 <t> … … 1562 1583 <t> 1563 1584 Proxy authentication might be used to establish the 1564 authority to create a tunnel :1585 authority to create a tunnel. For example, 1565 1586 </t> 1566 1587 <figure><artwork type="message/http; msgtype="request"" x:indent-with=" "> … … 1576 1597 </t> 1577 1598 <t> 1578 Similar to a pipelined HTTP/1.1 request, data to be tunneled from client 1579 to server &MAY; be sent immediately after the request (before a response 1580 is received). The usual caveats also apply: 1581 data can be discarded if the eventual response is negative, and the 1582 connection can be reset with no response if more than one TCP segment 1583 is outstanding. 1584 </t> 1585 <t> 1586 It might be the case that the proxy itself can only reach the requested 1587 origin server through another proxy. In this case, the first proxy 1588 &SHOULD; make a CONNECT request of that next proxy, requesting a tunnel 1589 to the authority. A proxy &MUST-NOT; respond with any <x:ref>2xx</x:ref> status code 1590 unless it has either a direct or tunnel connection established to the 1591 authority. 1592 </t> 1593 <t> 1594 If at any point either one of the peers gets disconnected, any 1595 outstanding data that came from that peer will be passed to the other 1596 one, and after that also the other connection will be terminated by 1597 the proxy. If there is outstanding data to that peer undelivered, 1599 When a tunnel intermediary detects that either side has closed its 1600 connection, any outstanding data that came from that side will first be 1601 sent to the other side and then the intermediary will close both 1602 connections. If there is outstanding data left undelivered, 1598 1603 that data will be discarded. 1599 1604 </t> 1600 1605 <t> 1601 1606 An origin server which receives a CONNECT request for itself &MAY; 1602 respond with a <x:ref>2xx</x:ref> status code to indicate that a connection is1603 established. However, most origin servers do not implement CONNECT.1607 respond with a <x:ref>2xx</x:ref> status code to indicate that a connection 1608 is established. However, most origin servers do not implement CONNECT. 1604 1609 </t> 1605 1610 </section> … … 1849 1854 <t> Upon receiving a request which includes an <x:ref>Expect</x:ref> header 1850 1855 field with the "100-continue" expectation, an origin server &MUST; 1851 either respond with <x:ref>100 (Continue)</x:ref> status code and continue to read1852 from the input stream, or respond with a final status code. The1853 origin server &MUST-NOT; wait for the payload body before sending1854 the <x:ref>100 (Continue)</x:ref> response. If it responds with a final status1855 code, it &MAY; close the transport connection or it &MAY; continue1856 t o read and discard the rest of the request. It &MUST-NOT;1857 perform the request method if it returns a final status code.1856 either respond with <x:ref>100 (Continue)</x:ref> status code and 1857 continue to read from the input stream, or respond with a final status 1858 code. The origin server &MUST-NOT; wait for the payload body before 1859 sending the <x:ref>100 (Continue)</x:ref> response. If the origin 1860 server responds with a final status code, it &MUST-NOT; have performed 1861 the request method and &MAY; either close the connection or continue 1862 to read and discard the rest of the request. 1858 1863 </t> 1859 <t> An origin server &SHOULD-NOT; send a <x:ref>100 (Continue)</x:ref> response if 1860 the request message does not include an <x:ref>Expect</x:ref> header 1861 field with the "100-continue" expectation, and &MUST-NOT; send a 1862 <x:ref>100 (Continue)</x:ref> response if such a request comes from an HTTP/1.0 1863 (or earlier) client. There is an exception to this rule: for 1864 compatibility with <xref target="RFC2068"/>, a server &MAY; send a <x:ref>100 (Continue)</x:ref> 1865 status code in response to an HTTP/1.1 PUT or POST request that does 1866 not include an Expect header field with the "100-continue" 1867 expectation. This exception, the purpose of which is 1868 to minimize any client processing delays associated with an 1869 undeclared wait for <x:ref>100 (Continue)</x:ref> status code, applies only to 1870 HTTP/1.1 requests, and not to requests with any other HTTP-version 1871 value. 1864 <t> An origin server &SHOULD-NOT; send a <x:ref>100 (Continue)</x:ref> 1865 response if the request message does not include an 1866 <x:ref>Expect</x:ref> header field with the "100-continue" 1867 expectation, and &MUST-NOT; send a <x:ref>100 (Continue)</x:ref> 1868 response if such a request comes from an HTTP/1.0 (or earlier) client. 1869 There is an exception to this rule: for compatibility with 1870 <xref target="RFC2068"/>, a server &MAY; send a 1871 <x:ref>100 (Continue)</x:ref> status code in response to an HTTP/1.1 1872 PUT or POST request that does not include an Expect header field with 1873 the "100-continue" expectation. This exception, the purpose of which 1874 is to minimize any client processing delays associated with an 1875 undeclared wait for <x:ref>100 (Continue)</x:ref> status code, applies 1876 only to HTTP/1.1 requests, and not to requests with any other 1877 HTTP-version value. 1872 1878 </t> 1873 <t> An origin server &MAY; omit a <x:ref>100 (Continue)</x:ref> response if it has1874 already received some or all of the payload body for the1879 <t> An origin server &MAY; omit a <x:ref>100 (Continue)</x:ref> response 1880 if it has already received some or all of the payload body for the 1875 1881 corresponding request. 1876 1882 </t> 1877 <t> An origin server that sends a <x:ref>100 (Continue)</x:ref> response &MUST;1878 ultimately send a final status code, once the payload body is1879 received and processed, unless it terminates the transport 1880 connectionprematurely.1883 <t> An origin server that sends a <x:ref>100 (Continue)</x:ref> response 1884 &MUST; ultimately send a final status code, once the payload body is 1885 received and processed, unless it terminates the transport connection 1886 prematurely. 1881 1887 </t> 1882 1888 <t> If an origin server receives a request that does not include an … … 2658 2664 <x:anchor-alias value="200 (OK)"/> 2659 2665 <t> 2660 The request has succeeded. The payload returned withthe response2666 The request has succeeded. The payload sent in the response 2661 2667 is dependent on the method used in the request, for example: 2662 2668 <list style="hanging"> … … 2697 2703 </t> 2698 2704 <t> 2699 The origin server &MUST; create the resource(s) before returning the 201 status2705 The origin server &MUST; create the resource(s) before sending the 201 status 2700 2706 code. If the action cannot be carried out immediately, the server &SHOULD; 2701 2707 respond with a <x:ref>202 (Accepted)</x:ref> response instead. … … 2725 2731 batch-oriented process that is only run once per day) without 2726 2732 requiring that the user agent's connection to the server persist 2727 until the process is completed. The representation returnedwith this2733 until the process is completed. The representation sent with this 2728 2734 response &SHOULD; include an indication of the request's current status 2729 2735 and either a pointer to a status monitor or some estimate of when the … … 2757 2763 The 204 (No Content) status code indicates that the server has 2758 2764 successfully fulfilled the request and that there is no additional 2759 content to returnin the response payload body. Metadata in the2765 content to send in the response payload body. Metadata in the 2760 2766 response header fields refer to the target resource and its current 2761 2767 representation after the requested action. … … 2929 2935 <t> 2930 2936 The target resource has been assigned a new permanent URI and any 2931 future references to this resource &SHOULD; use one of the returned2937 future references to this resource &SHOULD; use one of the enclosed 2932 2938 URIs. Clients with link editing capabilities ought to automatically 2933 2939 re-link references to the effective request URI to one or more of the new 2934 references returnedby the server, where possible.2940 references sent by the server, where possible. 2935 2941 </t> 2936 2942 <t> … … 3155 3161 <x:note> 3156 3162 <t> 3157 &Note; HTTP/1.1 servers are allowed to returnresponses which are3163 &Note; HTTP/1.1 servers are allowed to send responses which are 3158 3164 not acceptable according to the accept header fields sent in the 3159 3165 request. In some cases, this might even be preferable to sending a … … 3405 3411 <t> 3406 3412 <x:h>Note</x:h> to implementers: some deployed proxies are known to 3407 return<x:ref>400 (Bad Request)</x:ref> or <x:ref>500 (Internal Server3413 send <x:ref>400 (Bad Request)</x:ref> or <x:ref>500 (Internal Server 3408 3414 Error)</x:ref> when DNS lookups time out. 3409 3415 </t> -
draft-ietf-httpbis/latest/p4-conditional.html
r2049 r2052 449 449 } 450 450 @bottom-center { 451 content: "Expires June 1 4, 2013";451 content: "Expires June 18, 2013"; 452 452 } 453 453 @bottom-right { … … 491 491 <meta name="dct.creator" content="Reschke, J. F."> 492 492 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p4-conditional-latest"> 493 <meta name="dct.issued" scheme="ISO8601" content="2012-12-1 1">493 <meta name="dct.issued" scheme="ISO8601" content="2012-12-15"> 494 494 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 495 495 <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines HTTP/1.1 conditional requests, including metadata header fields for indicating state changes, request header fields for making preconditions on such state, and rules for constructing the responses to a conditional request when one or more preconditions evaluate to false."> … … 517 517 </tr> 518 518 <tr> 519 <td class="left">Expires: June 1 4, 2013</td>520 <td class="right">December 1 1, 2012</td>519 <td class="left">Expires: June 18, 2013</td> 520 <td class="right">December 15, 2012</td> 521 521 </tr> 522 522 </tbody> … … 545 545 in progress”. 546 546 </p> 547 <p>This Internet-Draft will expire on June 1 4, 2013.</p>547 <p>This Internet-Draft will expire on June 18, 2013.</p> 548 548 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 549 549 <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 857 857 </div> 858 858 <h3 id="rfc.section.2.3.3"><a href="#rfc.section.2.3.3">2.3.3</a> <a id="example.entity.tag.vs.conneg" href="#example.entity.tag.vs.conneg">Example: Entity-tags varying on Content-Negotiated Resources</a></h3> 859 <p id="rfc.section.2.3.3.p.1">Consider a resource that is subject to content negotiation (<a href="p2-semantics.html#content.negotiation" title="Content Negotiation">Section 3.4</a> of <a href="#Part2" id="rfc.xref.Part2.2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>), and where the representations returned upon a GET request vary based on the <a href="p2-semantics.html#header.accept-encoding" class="smpl">Accept-Encoding</a> request header field (<a href="p2-semantics.html#header.accept-encoding" title="Accept-Encoding">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>):859 <p id="rfc.section.2.3.3.p.1">Consider a resource that is subject to content negotiation (<a href="p2-semantics.html#content.negotiation" title="Content Negotiation">Section 3.4</a> of <a href="#Part2" id="rfc.xref.Part2.2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>), and where the representations sent in response to a GET request vary based on the <a href="p2-semantics.html#header.accept-encoding" class="smpl">Accept-Encoding</a> request header field (<a href="p2-semantics.html#header.accept-encoding" title="Accept-Encoding">Section 5.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>): 860 860 </p> 861 861 <div id="rfc.figure.u.5"></div> … … 921 921 </li> 922 922 </ul> 923 <p id="rfc.section.2.4.p.5">An HTTP/1.1 origin server, upon receiving a conditional request that includes both a Last-Modified date (e.g., in an <a href="#header.if-modified-since" class="smpl">If-Modified-Since</a> or <a href="#header.if-unmodified-since" class="smpl">If-Unmodified-Since</a> header field) and one or more entity-tags (e.g., in an <a href="#header.if-match" class="smpl">If-Match</a>, <a href="#header.if-none-match" class="smpl">If-None-Match</a>, or <a href="p5-range.html#header.if-range" class="smpl">If-Range</a> header field) as cache validators, <em class="bcp14">MUST NOT</em> returna response status code of <a href="#status.304" class="smpl">304 (Not Modified)</a> unless doing so is consistent with all of the conditional header fields in the request.923 <p id="rfc.section.2.4.p.5">An HTTP/1.1 origin server, upon receiving a conditional request that includes both a Last-Modified date (e.g., in an <a href="#header.if-modified-since" class="smpl">If-Modified-Since</a> or <a href="#header.if-unmodified-since" class="smpl">If-Unmodified-Since</a> header field) and one or more entity-tags (e.g., in an <a href="#header.if-match" class="smpl">If-Match</a>, <a href="#header.if-none-match" class="smpl">If-None-Match</a>, or <a href="p5-range.html#header.if-range" class="smpl">If-Range</a> header field) as cache validators, <em class="bcp14">MUST NOT</em> send a response status code of <a href="#status.304" class="smpl">304 (Not Modified)</a> unless doing so is consistent with all of the conditional header fields in the request. 924 924 </p> 925 925 <p id="rfc.section.2.4.p.6">An HTTP/1.1 caching proxy, upon receiving a conditional request that includes both a Last-Modified date and one or more entity-tags 926 as cache validators, <em class="bcp14">MUST NOT</em> returna locally cached response to the client unless that cached response is consistent with all of the conditional header926 as cache validators, <em class="bcp14">MUST NOT</em> send a locally cached response to the client unless that cached response is consistent with all of the conditional header 927 927 fields in the request. 928 928 </p> … … 987 987 Failed)</a> status code. 988 988 </p> 989 <p id="rfc.section.3.2.p.7">If the condition is met, the server <em class="bcp14">MAY</em> perform the requested method as if the If-None-Match header field did not exist, but <em class="bcp14">MUST</em> also ignore any <a href="#header.if-modified-since" class="smpl">If-Modified-Since</a> header field(s) in the request. That is, if no entity-tags match, then the server <em class="bcp14">MUST NOT</em> returna <a href="#status.304" class="smpl">304989 <p id="rfc.section.3.2.p.7">If the condition is met, the server <em class="bcp14">MAY</em> perform the requested method as if the If-None-Match header field did not exist, but <em class="bcp14">MUST</em> also ignore any <a href="#header.if-modified-since" class="smpl">If-Modified-Since</a> header field(s) in the request. That is, if no entity-tags match, then the server <em class="bcp14">MUST NOT</em> send a <a href="#status.304" class="smpl">304 990 990 (Not Modified)</a> response. 991 991 </p> … … 1017 1017 a normal GET. 1018 1018 </li> 1019 <li>If the selected representation has not been modified since a valid If-Modified-Since date, the server <em class="bcp14">SHOULD</em> returna <a href="#status.304" class="smpl">304 (Not Modified)</a> response.1019 <li>If the selected representation has not been modified since a valid If-Modified-Since date, the server <em class="bcp14">SHOULD</em> send a <a href="#status.304" class="smpl">304 (Not Modified)</a> response. 1020 1020 </li> 1021 1021 </ol> … … 1063 1063 <p id="rfc.section.4.1.p.2">The 304 response <em class="bcp14">MUST NOT</em> contain a message-body, and thus is always terminated by the first empty line after the header fields. 1064 1064 </p> 1065 <p id="rfc.section.4.1.p.3">A 304 response <em class="bcp14">MUST</em> include a <a href="p2-semantics.html#header.date" class="smpl">Date</a> header field (<a href="p2-semantics.html#header.date" title="Date">Section 8.1.1.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>) unless the origin server does not have a clock that can provide a reasonable approximation of the current time. If a <a href="p2-semantics.html#status.200" class="smpl">2001065 <p id="rfc.section.4.1.p.3">A 304 response <em class="bcp14">MUST</em> include a <a href="p2-semantics.html#header.date" class="smpl">Date</a> header field (<a href="p2-semantics.html#header.date" title="Date">Section 7.1.1.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>) unless the origin server does not have a clock that can provide a reasonable approximation of the current time. If a <a href="p2-semantics.html#status.200" class="smpl">200 1066 1066 (OK)</a> response to the same request would have included any of the header fields <a href="p6-cache.html#header.cache-control" class="smpl">Cache-Control</a>, <a href="p2-semantics.html#header.content-location" class="smpl">Content-Location</a>, <a href="#header.etag" class="smpl">ETag</a>, <a href="p6-cache.html#header.expires" class="smpl">Expires</a>, or <a href="p2-semantics.html#header.vary" class="smpl">Vary</a>, then those same header fields <em class="bcp14">MUST</em> be sent in a 304 response. 1067 1067 </p> … … 1317 1317 <a href="#imported.abnf" class="smpl">obs-text</a> = <obs-text, defined in <a href="#Part1" id="rfc.xref.Part1.9"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.6</a>> 1318 1318 </pre><p id="rfc.section.B.p.4">The rules below are defined in other parts:</p> 1319 <div id="rfc.figure.u.17"></div><pre class="inline"> <a href="#imported.abnf" class="smpl">HTTP-date</a> = <HTTP-date, defined in <a href="#Part2" id="rfc.xref.Part2.5"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>, <a href="p2-semantics.html#http.date" title="Date/Time Formats">Section 8.1.1.1</a>>1319 <div id="rfc.figure.u.17"></div><pre class="inline"> <a href="#imported.abnf" class="smpl">HTTP-date</a> = <HTTP-date, defined in <a href="#Part2" id="rfc.xref.Part2.5"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>, <a href="p2-semantics.html#http.date" title="Date/Time Formats">Section 7.1.1.1</a>> 1320 1320 </pre><h1 id="rfc.section.C"><a href="#rfc.section.C">C.</a> <a id="collected.abnf" href="#collected.abnf">Collected ABNF</a></h1> 1321 1321 <div id="rfc.figure.u.18"></div> <pre class="inline"><a href="#header.etag" class="smpl">ETag</a> = entity-tag 1322 1322 1323 <a href="#imported.abnf" class="smpl">HTTP-date</a> = <HTTP-date, defined in [Part2], Section 8.1.1.1>1323 <a href="#imported.abnf" class="smpl">HTTP-date</a> = <HTTP-date, defined in [Part2], Section 7.1.1.1> 1324 1324 1325 1325 <a href="#header.if-match" class="smpl">If-Match</a> = "*" / ( *( "," OWS ) entity-tag *( OWS "," [ OWS … … 1443 1443 <li><em>Part2</em> <a href="#rfc.xref.Part2.1">1</a>, <a href="#rfc.xref.Part2.2">2.3.3</a>, <a href="#rfc.xref.Part2.3">2.3.3</a>, <a href="#rfc.xref.Part2.4">4.1</a>, <a href="#Part2"><b>9.1</b></a>, <a href="#rfc.xref.Part2.5">B</a><ul> 1444 1444 <li><em>Section 3.4</em> <a href="#rfc.xref.Part2.2">2.3.3</a></li> 1445 <li><em>Section 6.3.4</em> <a href="#rfc.xref.Part2.3">2.3.3</a></li>1446 <li><em>Section 8.1.1.1</em> <a href="#rfc.xref.Part2.5">B</a></li>1447 <li><em>Section 8.1.1.2</em> <a href="#rfc.xref.Part2.4">4.1</a></li>1445 <li><em>Section 5.3.4</em> <a href="#rfc.xref.Part2.3">2.3.3</a></li> 1446 <li><em>Section 7.1.1.1</em> <a href="#rfc.xref.Part2.5">B</a></li> 1447 <li><em>Section 7.1.1.2</em> <a href="#rfc.xref.Part2.4">4.1</a></li> 1448 1448 </ul> 1449 1449 </li> -
draft-ietf-httpbis/latest/p4-conditional.xml
r2046 r2052 533 533 <section title="Example: Entity-tags varying on Content-Negotiated Resources" anchor="example.entity.tag.vs.conneg"> 534 534 <t> 535 Consider a resource that is subject to content negotiation (&content-negotiation;),536 and where the representations returned upon a GET request vary based on537 the <x:ref>Accept-Encoding</x:ref> request header field538 (&header-accept-encoding;):535 Consider a resource that is subject to content negotiation 536 (&content-negotiation;), and where the representations sent in response to 537 a GET request vary based on the <x:ref>Accept-Encoding</x:ref> request 538 header field (&header-accept-encoding;): 539 539 </t> 540 540 <figure><preamble>>> Request:</preamble><artwork type="message/http; msgtype="request"" x:indent-with=" "> … … 640 640 entity-tags (e.g., in an <x:ref>If-Match</x:ref>, <x:ref>If-None-Match</x:ref>, 641 641 or <x:ref>If-Range</x:ref> header field) as cache validators, &MUST-NOT; 642 returna response status code of <x:ref>304 (Not Modified)</x:ref> unless642 send a response status code of <x:ref>304 (Not Modified)</x:ref> unless 643 643 doing so is consistent with all of the conditional header fields in the 644 644 request. … … 647 647 An HTTP/1.1 caching proxy, upon receiving a conditional request that 648 648 includes both a Last-Modified date and one or more entity-tags as 649 cache validators, &MUST-NOT; returna locally cached response to the649 cache validators, &MUST-NOT; send a locally cached response to the 650 650 client unless that cached response is consistent with all of the 651 651 conditional header fields in the request. … … 777 777 as if the If-None-Match header field did not exist, but &MUST; also ignore 778 778 any <x:ref>If-Modified-Since</x:ref> header field(s) in the request. That 779 is, if no entity-tags match, then the server &MUST-NOT; returna <x:ref>304779 is, if no entity-tags match, then the server &MUST-NOT; send a <x:ref>304 780 780 (Not Modified)</x:ref> response. 781 781 </t> … … 837 837 838 838 <t>If the selected representation has not been modified since a valid 839 If-Modified-Since date, the server &SHOULD; returna839 If-Modified-Since date, the server &SHOULD; send a 840 840 <x:ref>304 (Not Modified)</x:ref> response.</t> 841 841 </list> … … 1437 1437 <x:ref>ETag</x:ref> = entity-tag 1438 1438 1439 <x:ref>HTTP-date</x:ref> = <HTTP-date, defined in [Part2], Section 8.1.1.1>1439 <x:ref>HTTP-date</x:ref> = <HTTP-date, defined in [Part2], Section 7.1.1.1> 1440 1440 1441 1441 <x:ref>If-Match</x:ref> = "*" / ( *( "," OWS ) entity-tag *( OWS "," [ OWS -
draft-ietf-httpbis/latest/p5-range.html
r2049 r2052 449 449 } 450 450 @bottom-center { 451 content: "Expires June 1 4, 2013";451 content: "Expires June 18, 2013"; 452 452 } 453 453 @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-p5-range-latest"> 495 <meta name="dct.issued" scheme="ISO8601" content="2012-12-1 1">495 <meta name="dct.issued" scheme="ISO8601" content="2012-12-15"> 496 496 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 497 497 <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines range requests and the rules for constructing and combining responses to those requests."> … … 519 519 </tr> 520 520 <tr> 521 <td class="left">Expires: June 1 4, 2013</td>521 <td class="left">Expires: June 18, 2013</td> 522 522 <td class="right">J. Reschke, Editor</td> 523 523 </tr> … … 528 528 <tr> 529 529 <td class="left"></td> 530 <td class="right">December 1 1, 2012</td>530 <td class="right">December 15, 2012</td> 531 531 </tr> 532 532 </tbody> … … 553 553 in progress”. 554 554 </p> 555 <p>This Internet-Draft will expire on June 1 4, 2013.</p>555 <p>This Internet-Draft will expire on June 18, 2013.</p> 556 556 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 557 557 <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 693 693 </li> 694 694 </ul> 695 <p id="rfc.section.3.1.p.3">If a 206 is sent in response to a request with an <a href="#header.if-range" class="smpl">If-Range</a> header field, it <em class="bcp14">SHOULD NOT</em> include other representation header fields. Otherwise, the response <em class="bcp14">MUST</em> include all of the representation header fields that would have been returnedwith a <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> response to the same request.695 <p id="rfc.section.3.1.p.3">If a 206 is sent in response to a request with an <a href="#header.if-range" class="smpl">If-Range</a> header field, it <em class="bcp14">SHOULD NOT</em> include other representation header fields. Otherwise, the response <em class="bcp14">MUST</em> include all of the representation header fields that would have been sent with a <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> response to the same request. 696 696 </p> 697 697 <p id="rfc.section.3.1.p.4">Caches <em class="bcp14">MAY</em> use a heuristic (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 4.1.2</a> of <a href="#Part6" id="rfc.xref.Part6.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>) to determine freshness for 206 responses. … … 699 699 <div id="rfc.iref.3"></div> 700 700 <h2 id="rfc.section.3.2"><a href="#rfc.section.3.2">3.2</a> <a id="status.416" href="#status.416">416 Requested Range Not Satisfiable</a></h2> 701 <p id="rfc.section.3.2.p.1">A server <em class="bcp14">SHOULD</em> returna response with this status code if a request included a <a href="#range.retrieval.requests" class="smpl">Range</a> header field (<a href="#header.range" id="rfc.xref.header.range.4" title="Range">Section 5.4</a>), and none of the ranges-specifier values in this field overlap the current extent of the selected resource, and the request701 <p id="rfc.section.3.2.p.1">A server <em class="bcp14">SHOULD</em> send a response with this status code if a request included a <a href="#range.retrieval.requests" class="smpl">Range</a> header field (<a href="#header.range" id="rfc.xref.header.range.4" title="Range">Section 5.4</a>), and none of the ranges-specifier values in this field overlap the current extent of the selected resource, and the request 702 702 did not include an <a href="#header.if-range" class="smpl">If-Range</a> header field (<a href="#header.if-range" id="rfc.xref.header.if-range.2" title="If-Range">Section 5.3</a>). (For byte-ranges, this means that the first-byte-pos of all of the byte-range-spec values were greater than the current 703 703 length of the selected resource.) 704 704 </p> 705 <p id="rfc.section.3.2.p.2">When this status code is returnedfor a byte-range request, the response <em class="bcp14">SHOULD</em> include a <a href="#header.content-range" class="smpl">Content-Range</a> header field specifying the current length of the representation (see <a href="#header.content-range" id="rfc.xref.header.content-range.3" title="Content-Range">Section 5.2</a>). This response <em class="bcp14">MUST NOT</em> use the multipart/byteranges content-type.705 <p id="rfc.section.3.2.p.2">When this status code is sent for a byte-range request, the response <em class="bcp14">SHOULD</em> include a <a href="#header.content-range" class="smpl">Content-Range</a> header field specifying the current length of the representation (see <a href="#header.content-range" id="rfc.xref.header.content-range.3" title="Content-Range">Section 5.2</a>). This response <em class="bcp14">MUST NOT</em> use the multipart/byteranges content-type. 706 706 </p> 707 707 <div id="rfc.figure.u.2"></div> … … 736 736 <p id="rfc.section.4.1.p.5">A response to a request for a single range <em class="bcp14">MUST NOT</em> be sent using the multipart/byteranges media type. A response to a request for multiple ranges, whose result is a single range, <em class="bcp14">MAY</em> be sent as a multipart/byteranges media type with one part. A client that cannot decode a multipart/byteranges message <em class="bcp14">MUST NOT</em> ask for multiple ranges in a single request. 737 737 </p> 738 <p id="rfc.section.4.1.p.6">When a client asks for multiple ranges in one request, the server <em class="bcp14">SHOULD</em> returnthem in the order that they appeared in the request.738 <p id="rfc.section.4.1.p.6">When a client asks for multiple ranges in one request, the server <em class="bcp14">SHOULD</em> send them in the order that they appeared in the request. 739 739 </p> 740 740 <h2 id="rfc.section.4.2"><a href="#rfc.section.4.2">4.2</a> <a id="combining.byte.ranges" href="#combining.byte.ranges">Combining Ranges</a></h2> … … 828 828 </ul> 829 829 <p id="rfc.section.5.2.p.10">If the server ignores a byte-range-spec (for example if it is syntactically invalid, or if it might be seen as a denial-of-service 830 attack), the server <em class="bcp14">SHOULD</em> treat the request as if the invalid <a href="#range.retrieval.requests" class="smpl">Range</a> header field did not exist. (Normally, this means returna <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> response containing the full representation).830 attack), the server <em class="bcp14">SHOULD</em> treat the request as if the invalid <a href="#range.retrieval.requests" class="smpl">Range</a> header field did not exist. (Normally, this means send a <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> response containing the full representation). 831 831 </p> 832 832 <div id="rfc.iref.i.1"></div> … … 888 888 <p id="rfc.section.5.4.1.p.11">If a syntactically valid byte-range-set includes at least one byte-range-spec whose first-byte-pos is less than the current 889 889 length of the representation, or at least one suffix-byte-range-spec with a non-zero suffix-length, then the byte-range-set 890 is satisfiable. Otherwise, the byte-range-set is unsatisfiable. If the byte-range-set is unsatisfiable, the server <em class="bcp14">SHOULD</em> return a response with a <a href="#status.416" class="smpl">416 (Requested Range Not Satisfiable)</a> status code. Otherwise, the server <em class="bcp14">SHOULD</em> returna response with a <a href="#status.206" class="smpl">206 (Partial Content)</a> status code containing the satisfiable ranges of the representation.890 is satisfiable. Otherwise, the byte-range-set is unsatisfiable. If the byte-range-set is unsatisfiable, the server <em class="bcp14">SHOULD</em> send a response with a <a href="#status.416" class="smpl">416 (Requested Range Not Satisfiable)</a> status code. Otherwise, the server <em class="bcp14">SHOULD</em> send a response with a <a href="#status.206" class="smpl">206 (Partial Content)</a> status code containing the satisfiable ranges of the representation. 891 891 </p> 892 892 <p id="rfc.section.5.4.1.p.12">In the byte range syntax, <a href="#rule.ranges-specifier" class="smpl">first-byte-pos</a>, <a href="#rule.ranges-specifier" class="smpl">last-byte-pos</a>, and <a href="#rule.ranges-specifier" class="smpl">suffix-length</a> are expressed as decimal number of octets. Since there is no predefined limit to the length of an HTTP payload, recipients <em class="bcp14">SHOULD</em> anticipate potentially large decimal numerals and prevent parsing errors due to integer conversion overflows. … … 925 925 <p id="rfc.section.5.4.2.p.4">If the server supports the Range header field and the specified range or ranges are appropriate for the representation: </p> 926 926 <ul> 927 <li>The presence of a Range header field in an unconditional GET modifies what is returned if the GET is otherwise successful.928 Inother words, the response carries a status code of <a href="#status.206" class="smpl">206 (Partial Content)</a> instead of <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a>.929 </li> 930 <li>The presence of a Range header field in a conditional GET (a request using one or both of <a href="p4-conditional.html#header.if-modified-since" class="smpl">If-Modified-Since</a> and <a href="p4-conditional.html#header.if-none-match" class="smpl">If-None-Match</a>, or one or both of <a href="p4-conditional.html#header.if-unmodified-since" class="smpl">If-Unmodified-Since</a> and <a href="p4-conditional.html#header.if-match" class="smpl">If-Match</a>) modifies what is returned if the GET is otherwise successful and the condition is true. It does not affect the <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a> response returnedif the conditional is false.927 <li>The presence of a Range header field in an unconditional GET modifies what is sent if the GET is otherwise successful. In 928 other words, the response carries a status code of <a href="#status.206" class="smpl">206 (Partial Content)</a> instead of <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a>. 929 </li> 930 <li>The presence of a Range header field in a conditional GET (a request using one or both of <a href="p4-conditional.html#header.if-modified-since" class="smpl">If-Modified-Since</a> and <a href="p4-conditional.html#header.if-none-match" class="smpl">If-None-Match</a>, or one or both of <a href="p4-conditional.html#header.if-unmodified-since" class="smpl">If-Unmodified-Since</a> and <a href="p4-conditional.html#header.if-match" class="smpl">If-Match</a>) modifies what is sent if the GET is otherwise successful and the condition is true. It does not affect the <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a> response sent if the conditional is false. 931 931 </li> 932 932 </ul> … … 934 934 </p> 935 935 <p id="rfc.section.5.4.2.p.6">If a proxy that supports ranges receives a Range request, forwards the request to an inbound server, and receives an entire 936 representation in reply, it <em class="bcp14">MAY</em> only returnthe requested range to its client.936 representation in reply, it <em class="bcp14">MAY</em> only send the requested range to its client. 937 937 </p> 938 938 <h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a> <a id="IANA.considerations" href="#IANA.considerations">IANA Considerations</a></h1> … … 1233 1233 <p id="rfc.section.B.p.2">The Content-Range header field only has meaning when the status code explicitly defines its use. (<a href="#header.content-range" id="rfc.xref.header.content-range.5" title="Content-Range">Section 5.2</a>) 1234 1234 </p> 1235 <p id="rfc.section.B.p.3">Servers are given more leeway in what they returnto a range request, in order to mitigate malicious (or just greedy) clients.</p>1235 <p id="rfc.section.B.p.3">Servers are given more leeway in what they send to a range request, in order to mitigate malicious (or just greedy) clients.</p> 1236 1236 <p id="rfc.section.B.p.4">multipart/byteranges can consist of a single part. (<a href="#internet.media.type.multipart.byteranges" title="Internet Media Type multipart/byteranges">Appendix A</a>) 1237 1237 </p> … … 1250 1250 <a href="#imported.abnf" class="smpl">token</a> = <token, defined in <a href="#Part1" id="rfc.xref.Part1.6"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.6</a>> 1251 1251 </pre><p id="rfc.section.C.p.5">The rules below are defined in other parts:</p> 1252 <div id="rfc.figure.u.25"></div><pre class="inline"> <a href="#imported.abnf" class="smpl">HTTP-date</a> = <HTTP-date, defined in <a href="#Part2" id="rfc.xref.Part2.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>, <a href="p2-semantics.html#http.date" title="Date/Time Formats">Section 8.1.1.1</a>>1252 <div id="rfc.figure.u.25"></div><pre class="inline"> <a href="#imported.abnf" class="smpl">HTTP-date</a> = <HTTP-date, defined in <a href="#Part2" id="rfc.xref.Part2.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>, <a href="p2-semantics.html#http.date" title="Date/Time Formats">Section 7.1.1.1</a>> 1253 1253 <a href="#imported.abnf" class="smpl">entity-tag</a> = <entity-tag, defined in <a href="#Part4" id="rfc.xref.Part4.5"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a>, <a href="p4-conditional.html#header.etag" title="ETag">Section 2.3</a>> 1254 1254 </pre><h1 id="rfc.section.D"><a href="#rfc.section.D">D.</a> <a id="collected.abnf" href="#collected.abnf">Collected ABNF</a></h1> … … 1257 1257 <a href="#header.content-range" class="smpl">Content-Range</a> = byte-content-range-spec / other-content-range-spec 1258 1258 1259 <a href="#imported.abnf" class="smpl">HTTP-date</a> = <HTTP-date, defined in [Part2], Section 8.1.1.1>1259 <a href="#imported.abnf" class="smpl">HTTP-date</a> = <HTTP-date, defined in [Part2], Section 7.1.1.1> 1260 1260 1261 1261 <a href="#header.if-range" class="smpl">If-Range</a> = entity-tag / HTTP-date … … 1399 1399 </li> 1400 1400 <li><em>Part2</em> <a href="#Part2"><b>9.1</b></a>, <a href="#rfc.xref.Part2.1">C</a><ul> 1401 <li><em>Section 8.1.1.1</em> <a href="#rfc.xref.Part2.1">C</a></li>1401 <li><em>Section 7.1.1.1</em> <a href="#rfc.xref.Part2.1">C</a></li> 1402 1402 </ul> 1403 1403 </li> -
draft-ietf-httpbis/latest/p5-range.xml
r2046 r2052 273 273 header field, it &SHOULD-NOT; include other representation header fields. 274 274 Otherwise, the response &MUST; include all of the representation header 275 fields that would have been returnedwith a <x:ref>200 (OK)</x:ref> response275 fields that would have been sent with a <x:ref>200 (OK)</x:ref> response 276 276 to the same request. 277 277 </t> … … 286 286 <x:anchor-alias value="416 (Requested Range Not Satisfiable)"/> 287 287 <t> 288 A server &SHOULD; returna response with this status code if a request288 A server &SHOULD; send a response with this status code if a request 289 289 included a <x:ref>Range</x:ref> header field (<xref target="header.range"/>), 290 290 and none of the ranges-specifier values in this field overlap the current … … 296 296 </t> 297 297 <t> 298 When this status code is returnedfor a byte-range request, the298 When this status code is sent for a byte-range request, the 299 299 response &SHOULD; include a <x:ref>Content-Range</x:ref> header field 300 300 specifying the current length of the representation (see <xref target="header.content-range"/>). … … 359 359 <t> 360 360 When a client asks for multiple ranges in one request, the 361 server &SHOULD; returnthem in the order that they appeared in the361 server &SHOULD; send them in the order that they appeared in the 362 362 request. 363 363 </t> … … 558 558 syntactically invalid, or if it might be seen as a denial-of-service 559 559 attack), the server &SHOULD; treat the request as if the invalid <x:ref>Range</x:ref> 560 header field did not exist. (Normally, this means returna <x:ref>200 (OK)</x:ref>560 header field did not exist. (Normally, this means send a <x:ref>200 (OK)</x:ref> 561 561 response containing the full representation). 562 562 </t> … … 690 690 suffix-length, then the byte-range-set is satisfiable. 691 691 Otherwise, the byte-range-set is unsatisfiable. If the byte-range-set 692 is unsatisfiable, the server &SHOULD; returna response with a692 is unsatisfiable, the server &SHOULD; send a response with a 693 693 <x:ref>416 (Requested Range Not Satisfiable)</x:ref> status code. Otherwise, the server 694 &SHOULD; returna response with a <x:ref>206 (Partial Content)</x:ref> status code694 &SHOULD; send a response with a <x:ref>206 (Partial Content)</x:ref> status code 695 695 containing the satisfiable ranges of the representation. 696 696 </t> … … 768 768 <list style="symbols"> 769 769 <t>The presence of a Range header field in an unconditional GET modifies 770 what is returnedif the GET is otherwise successful. In other770 what is sent if the GET is otherwise successful. In other 771 771 words, the response carries a status code of <x:ref>206 (Partial Content)</x:ref> 772 772 instead of <x:ref>200 (OK)</x:ref>.</t> … … 776 776 <x:ref>If-None-Match</x:ref>, or one or both of 777 777 <x:ref>If-Unmodified-Since</x:ref> and <x:ref>If-Match</x:ref>) modifies 778 what is returnedif the GET is otherwise successful and the778 what is sent if the GET is otherwise successful and the 779 779 condition is true. It does not affect the <x:ref>304 (Not Modified)</x:ref> 780 response returnedif the conditional is false.</t>780 response sent if the conditional is false.</t> 781 781 </list> 782 782 </t> … … 789 789 If a proxy that supports ranges receives a Range request, forwards 790 790 the request to an inbound server, and receives an entire representation in 791 reply, it &MAY; only returnthe requested range to its client.791 reply, it &MAY; only send the requested range to its client. 792 792 </t> 793 793 </section> … … 1307 1307 </t> 1308 1308 <t> 1309 Servers are given more leeway in what they returnto a range request,1309 Servers are given more leeway in what they send to a range request, 1310 1310 in order to mitigate malicious (or just greedy) clients. 1311 1311 </t> … … 1371 1371 <x:ref>Content-Range</x:ref> = byte-content-range-spec / other-content-range-spec 1372 1372 1373 <x:ref>HTTP-date</x:ref> = <HTTP-date, defined in [Part2], Section 8.1.1.1>1373 <x:ref>HTTP-date</x:ref> = <HTTP-date, defined in [Part2], Section 7.1.1.1> 1374 1374 1375 1375 <x:ref>If-Range</x:ref> = entity-tag / HTTP-date -
draft-ietf-httpbis/latest/p6-cache.html
r2049 r2052 452 452 } 453 453 @bottom-center { 454 content: "Expires June 1 4, 2013";454 content: "Expires June 18, 2013"; 455 455 } 456 456 @bottom-right { … … 498 498 <meta name="dct.creator" content="Reschke, J. F."> 499 499 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p6-cache-latest"> 500 <meta name="dct.issued" scheme="ISO8601" content="2012-12-1 1">500 <meta name="dct.issued" scheme="ISO8601" content="2012-12-15"> 501 501 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 502 502 <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines requirements on HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages."> … … 524 524 </tr> 525 525 <tr> 526 <td class="left">Expires: June 1 4, 2013</td>526 <td class="left">Expires: June 18, 2013</td> 527 527 <td class="right">J. Reschke, Editor</td> 528 528 </tr> … … 533 533 <tr> 534 534 <td class="left"></td> 535 <td class="right">December 1 1, 2012</td>535 <td class="right">December 15, 2012</td> 536 536 </tr> 537 537 </tbody> … … 559 559 in progress”. 560 560 </p> 561 <p>This Internet-Draft will expire on June 1 4, 2013.</p>561 <p>This Internet-Draft will expire on June 18, 2013.</p> 562 562 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 563 563 <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 727 727 </p> 728 728 <ul class="empty"> 729 <li>The time at which the origin server intends that a representation no longer be returnedby a cache without further validation.</li>729 <li>The time at which the origin server intends that a representation no longer be sent by a cache without further validation.</li> 730 730 </ul> 731 731 <p id="rfc.section.1.2.p.7"> <span id="rfc.iref.h.1"></span> <dfn>heuristic expiration time</dfn> … … 859 859 </p> 860 860 <h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a> <a id="constructing.responses.from.caches" href="#constructing.responses.from.caches">Constructing Responses from Caches</a></h1> 861 <p id="rfc.section.4.p.1">For a presented request, a cache <em class="bcp14">MUST NOT</em> returna stored response, unless:861 <p id="rfc.section.4.p.1">For a presented request, a cache <em class="bcp14">MUST NOT</em> send a stored response, unless: 862 862 </p> 863 863 <ul> … … 886 886 <p id="rfc.section.4.p.3">When a stored response is used to satisfy a request without validation, a cache <em class="bcp14">MUST</em> include a single <a href="#header.age" class="smpl">Age</a> header field (<a href="#header.age" id="rfc.xref.header.age.1" title="Age">Section 7.1</a>) in the response with a value equal to the stored response's current_age; see <a href="#age.calculations" title="Calculating Age">Section 4.1.3</a>. 887 887 </p> 888 <p id="rfc.section.4.p.4">A cache <em class="bcp14">MUST</em> write through requests with methods that are unsafe (<a href="p2-semantics.html#safe.methods" title="Safe Methods">Section 5.2.1</a> of <a href="#Part2" id="rfc.xref.Part2.2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>) to the origin server; i.e., a cache is not allowed to generate a reply to such a request before having forwarded the request888 <p id="rfc.section.4.p.4">A cache <em class="bcp14">MUST</em> write through requests with methods that are unsafe (<a href="p2-semantics.html#safe.methods" title="Safe Methods">Section 4.2.1</a> of <a href="#Part2" id="rfc.xref.Part2.2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>) to the origin server; i.e., a cache is not allowed to generate a reply to such a request before having forwarded the request 889 889 and having received a corresponding response. 890 890 </p> … … 940 940 <h3 id="rfc.section.4.1.2"><a href="#rfc.section.4.1.2">4.1.2</a> <a id="heuristic.freshness" href="#heuristic.freshness">Calculating Heuristic Freshness</a></h3> 941 941 <p id="rfc.section.4.1.2.p.1">If no explicit expiration time is present in a stored response that has a status code whose definition allows heuristic freshness 942 to be used (including the following in <a href="p2-semantics.html#status.codes" title="Response Status Codes">Section 7</a> of <a href="#Part2" id="rfc.xref.Part2.3"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>: <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a>, <a href="p2-semantics.html#status.203" class="smpl">203 (Non-Authoritative Information)</a>, <a href="p5-range.html#status.206" class="smpl">206 (Partial942 to be used (including the following in <a href="p2-semantics.html#status.codes" title="Response Status Codes">Section 6</a> of <a href="#Part2" id="rfc.xref.Part2.3"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>: <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a>, <a href="p2-semantics.html#status.203" class="smpl">203 (Non-Authoritative Information)</a>, <a href="p5-range.html#status.206" class="smpl">206 (Partial 943 943 Content)</a>, <a href="p2-semantics.html#status.300" class="smpl">300 (Multiple Choices)</a>, <a href="p2-semantics.html#status.301" class="smpl">301 (Moved 944 944 Permanently)</a> and <a href="p2-semantics.html#status.410" class="smpl">410 (Gone)</a>), a cache <em class="bcp14">MAY</em> calculate a heuristic expiration time. A cache <em class="bcp14">MUST NOT</em> use heuristics to determine freshness for responses with status codes that do not explicitly allow it. … … 973 973 <ul class="empty"> 974 974 <li>HTTP/1.1 requires origin servers to send a <a href="p2-semantics.html#header.date" class="smpl">Date</a> header field, if possible, with every response, giving the time at which the response was generated. The term "date_value" 975 denotes the value of the Date header field, in a form appropriate for arithmetic operations. See <a href="p2-semantics.html#header.date" title="Date">Section 8.1.1.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> for the definition of the Date header field, and for requirements regarding responses without it.975 denotes the value of the Date header field, in a form appropriate for arithmetic operations. See <a href="p2-semantics.html#header.date" title="Date">Section 7.1.1.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> for the definition of the Date header field, and for requirements regarding responses without it. 976 976 </li> 977 977 </ul> … … 1033 1033 is not fresh according to the calculations in <a href="#expiration.model" title="Freshness Model">Section 4.1</a>. 1034 1034 </p> 1035 <p id="rfc.section.4.1.4.p.2">A cache <em class="bcp14">MUST NOT</em> returna stale response if it is prohibited by an explicit in-protocol directive (e.g., by a "no-store" or "no-cache" cache1035 <p id="rfc.section.4.1.4.p.2">A cache <em class="bcp14">MUST NOT</em> send a stale response if it is prohibited by an explicit in-protocol directive (e.g., by a "no-store" or "no-cache" cache 1036 1036 directive, a "must-revalidate" cache-response-directive, or an applicable "s-maxage" or "proxy-revalidate" cache-response-directive; 1037 1037 see <a href="#cache-response-directive" title="Response Cache-Control Directives">Section 7.2.2</a>). 1038 1038 </p> 1039 <p id="rfc.section.4.1.4.p.3">A cache <em class="bcp14">MUST NOT</em> returnstale responses unless it is disconnected (i.e., it cannot contact the origin server or otherwise find a forward path)1039 <p id="rfc.section.4.1.4.p.3">A cache <em class="bcp14">MUST NOT</em> send stale responses unless it is disconnected (i.e., it cannot contact the origin server or otherwise find a forward path) 1040 1040 or doing so is explicitly allowed (e.g., by the max-stale request directive; see <a href="#cache-request-directive" title="Request Cache-Control Directives">Section 7.2.1</a>). 1041 1041 </p> … … 1066 1066 </li> 1067 1067 <li>However, if a cache receives a <a href="p2-semantics.html#status.5xx" class="smpl">5xx (Server Error)</a> response while attempting to validate a response, it can either forward this response to the requesting client, or act as 1068 if the server failed to respond. In the latter case, it can returna previously stored response (see <a href="#serving.stale.responses" title="Serving Stale Responses">Section 4.1.4</a>).1068 if the server failed to respond. In the latter case, it can send a previously stored response (see <a href="#serving.stale.responses" title="Serving Stale Responses">Section 4.1.4</a>). 1069 1069 </li> 1070 1070 </ul> … … 1096 1096 </ul> 1097 1097 <h2 id="rfc.section.4.3"><a href="#rfc.section.4.3">4.3</a> <a id="caching.negotiated.responses" href="#caching.negotiated.responses">Using Negotiated Responses</a></h2> 1098 <p id="rfc.section.4.3.p.1">When a cache receives a request that can be satisfied by a stored response that has a <a href="p2-semantics.html#header.vary" class="smpl">Vary</a> header field (<a href="p2-semantics.html#header.vary" title="Vary">Section 8.2.1</a> of <a href="#Part2" id="rfc.xref.Part2.5"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>), it <em class="bcp14">MUST NOT</em> use that response unless all of the selecting header fields nominated by the Vary header field match in both the original1098 <p id="rfc.section.4.3.p.1">When a cache receives a request that can be satisfied by a stored response that has a <a href="p2-semantics.html#header.vary" class="smpl">Vary</a> header field (<a href="p2-semantics.html#header.vary" title="Vary">Section 7.2.1</a> of <a href="#Part2" id="rfc.xref.Part2.5"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>), it <em class="bcp14">MUST NOT</em> use that response unless all of the selecting header fields nominated by the Vary header field match in both the original 1099 1099 request (i.e., that associated with the stored response), and the presented request. 1100 1100 </p> … … 1155 1155 </ul> 1156 1156 <h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a> <a id="invalidation.after.updates.or.deletions" href="#invalidation.after.updates.or.deletions">Request Methods that Invalidate</a></h1> 1157 <p id="rfc.section.6.p.1">Because unsafe request methods (<a href="p2-semantics.html#safe.methods" title="Safe Methods">Section 5.2.1</a> of <a href="#Part2" id="rfc.xref.Part2.6"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>) such as PUT, POST or DELETE have the potential for changing state on the origin server, intervening caches can use them1157 <p id="rfc.section.6.p.1">Because unsafe request methods (<a href="p2-semantics.html#safe.methods" title="Safe Methods">Section 4.2.1</a> of <a href="#Part2" id="rfc.xref.Part2.6"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>) such as PUT, POST or DELETE have the potential for changing state on the origin server, intervening caches can use them 1158 1158 to keep their contents up-to-date. 1159 1159 </p> … … 1165 1165 </p> 1166 1166 <p id="rfc.section.6.p.5">Here, a "non-error response" is one with a <a href="p2-semantics.html#status.2xx" class="smpl">2xx (Successful)</a> or <a href="p2-semantics.html#status.3xx" class="smpl">3xx (Redirection)</a> status code. "Invalidate" means that the cache will either remove all stored responses related to the effective request URI, 1167 or will mark these as "invalid" and in need of a mandatory validation before they can be returnedin response to a subsequent1167 or will mark these as "invalid" and in need of a mandatory validation before they can be sent in response to a subsequent 1168 1168 request. 1169 1169 </p> … … 1307 1307 </ul> 1308 1308 <p id="rfc.section.7.2.2.3.p.2">The "no-cache" response directive indicates that the response <em class="bcp14">MUST NOT</em> be used to satisfy a subsequent request without successful validation on the origin server. This allows an origin server to 1309 prevent a cache from using it to satisfy a request without contacting it, even by caches that have been configured to return1309 prevent a cache from using it to satisfy a request without contacting it, even by caches that have been configured to send 1310 1310 stale responses. 1311 1311 </p> … … 1423 1423 that time. 1424 1424 </p> 1425 <p id="rfc.section.7.3.p.3">The field-value is an absolute date and time as defined by HTTP-date in <a href="p2-semantics.html#http.date" title="Date/Time Formats">Section 8.1.1.1</a> of <a href="#Part2" id="rfc.xref.Part2.7"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>; a sender <em class="bcp14">MUST</em> use the rfc1123-date format.1425 <p id="rfc.section.7.3.p.3">The field-value is an absolute date and time as defined by HTTP-date in <a href="p2-semantics.html#http.date" title="Date/Time Formats">Section 7.1.1.1</a> of <a href="#Part2" id="rfc.xref.Part2.7"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>; a sender <em class="bcp14">MUST</em> use the rfc1123-date format. 1426 1426 </p> 1427 1427 <div id="rfc.figure.u.9"></div><pre class="inline"><span id="rfc.iref.g.5"></span> <a href="#header.expires" class="smpl">Expires</a> = <a href="#imported.abnf" class="smpl">HTTP-date</a> … … 1510 1510 </li> 1511 1511 <li>2xx Warnings describe some aspect of the representation that is not rectified by a validation (for example, a lossy compression 1512 of the representation) and <em class="bcp14">MUST NOT</em> be deleted by a cache after validation, unless a full response is returned, in which case they <em class="bcp14">MUST</em> be.1512 of the representation) and <em class="bcp14">MUST NOT</em> be deleted by a cache after validation, unless a full response is sent, in which case they <em class="bcp14">MUST</em> be. 1513 1513 </li> 1514 1514 </ul> … … 1524 1524 <div id="rfc.iref.52"></div> 1525 1525 <h3 id="rfc.section.7.5.1"><a href="#rfc.section.7.5.1">7.5.1</a> <a id="warn.110" href="#warn.110">110 Response is Stale</a></h3> 1526 <p id="rfc.section.7.5.1.p.1">A cache <em class="bcp14">SHOULD</em> include this whenever the returnedresponse is stale.1526 <p id="rfc.section.7.5.1.p.1">A cache <em class="bcp14">SHOULD</em> include this whenever the sent response is stale. 1527 1527 </p> 1528 1528 <div id="rfc.iref.52"></div> 1529 1529 <h3 id="rfc.section.7.5.2"><a href="#rfc.section.7.5.2">7.5.2</a> <a id="warn.111" href="#warn.111">111 Revalidation Failed</a></h3> 1530 <p id="rfc.section.7.5.2.p.1">A cache <em class="bcp14">SHOULD</em> include this when returning a stale response because an attempt to validate the response failed, due to an inability to reach1530 <p id="rfc.section.7.5.2.p.1">A cache <em class="bcp14">SHOULD</em> include this when sending a stale response because an attempt to validate the response failed, due to an inability to reach 1531 1531 the server. 1532 1532 </p> … … 1955 1955 <a href="#imported.abnf" class="smpl">uri-host</a> = <uri-host, defined in <a href="#Part1" id="rfc.xref.Part1.19"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.7</a>> 1956 1956 </pre><p id="rfc.section.B.p.4">The rules below are defined in other parts:</p> 1957 <div id="rfc.figure.u.15"></div><pre class="inline"> <a href="#imported.abnf" class="smpl">HTTP-date</a> = <HTTP-date, defined in <a href="#Part2" id="rfc.xref.Part2.8"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>, <a href="p2-semantics.html#http.date" title="Date/Time Formats">Section 8.1.1.1</a>>1957 <div id="rfc.figure.u.15"></div><pre class="inline"> <a href="#imported.abnf" class="smpl">HTTP-date</a> = <HTTP-date, defined in <a href="#Part2" id="rfc.xref.Part2.8"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>, <a href="p2-semantics.html#http.date" title="Date/Time Formats">Section 7.1.1.1</a>> 1958 1958 </pre><h1 id="rfc.section.C"><a href="#rfc.section.C">C.</a> <a id="collected.abnf" href="#collected.abnf">Collected ABNF</a></h1> 1959 1959 <div id="rfc.figure.u.16"></div> <pre class="inline"><a href="#header.age" class="smpl">Age</a> = delta-seconds … … 1964 1964 <a href="#header.expires" class="smpl">Expires</a> = HTTP-date 1965 1965 1966 <a href="#imported.abnf" class="smpl">HTTP-date</a> = <HTTP-date, defined in [Part2], Section 8.1.1.1>1966 <a href="#imported.abnf" class="smpl">HTTP-date</a> = <HTTP-date, defined in [Part2], Section 7.1.1.1> 1967 1967 1968 1968 <a href="#imported.abnf" class="smpl">OWS</a> = <OWS, defined in [Part1], Section 3.2.3> … … 2142 2142 </li> 2143 2143 <li><em>Part2</em> <a href="#rfc.xref.Part2.1">2</a>, <a href="#rfc.xref.Part2.2">4</a>, <a href="#rfc.xref.Part2.3">4.1.2</a>, <a href="#rfc.xref.Part2.4">4.1.3</a>, <a href="#rfc.xref.Part2.5">4.3</a>, <a href="#rfc.xref.Part2.6">6</a>, <a href="#rfc.xref.Part2.7">7.3</a>, <a href="#Part2"><b>12.1</b></a>, <a href="#rfc.xref.Part2.8">B</a><ul> 2144 <li><em>Section 5.2.1</em> <a href="#rfc.xref.Part2.2">4</a>, <a href="#rfc.xref.Part2.6">6</a></li>2145 <li><em>Section 7</em> <a href="#rfc.xref.Part2.3">4.1.2</a></li>2146 <li><em>Section 8.1.1.1</em> <a href="#rfc.xref.Part2.7">7.3</a>, <a href="#rfc.xref.Part2.8">B</a></li>2147 <li><em>Section 8.1.1.2</em> <a href="#rfc.xref.Part2.4">4.1.3</a></li>2148 <li><em>Section 8.2.1</em> <a href="#rfc.xref.Part2.5">4.3</a></li>2144 <li><em>Section 4.2.1</em> <a href="#rfc.xref.Part2.2">4</a>, <a href="#rfc.xref.Part2.6">6</a></li> 2145 <li><em>Section 6</em> <a href="#rfc.xref.Part2.3">4.1.2</a></li> 2146 <li><em>Section 7.1.1.1</em> <a href="#rfc.xref.Part2.7">7.3</a>, <a href="#rfc.xref.Part2.8">B</a></li> 2147 <li><em>Section 7.1.1.2</em> <a href="#rfc.xref.Part2.4">4.1.3</a></li> 2148 <li><em>Section 7.2.1</em> <a href="#rfc.xref.Part2.5">4.3</a></li> 2149 2149 </ul> 2150 2150 </li> -
draft-ietf-httpbis/latest/p6-cache.xml
r2046 r2052 211 211 <list> 212 212 <t>The time at which the origin server intends that a representation 213 no longer be returnedby a cache without further validation.</t>213 no longer be sent by a cache without further validation.</t> 214 214 </list> 215 215 </t> … … 471 471 title="Constructing Responses from Caches"> 472 472 <t> 473 For a presented request, a cache &MUST-NOT; returna stored response,473 For a presented request, a cache &MUST-NOT; send a stored response, 474 474 unless: 475 475 <list style="symbols"> … … 796 796 </t> 797 797 <t> 798 A cache &MUST-NOT; returna stale response if it is prohibited by an798 A cache &MUST-NOT; send a stale response if it is prohibited by an 799 799 explicit in-protocol directive (e.g., by a "no-store" or "no-cache" cache 800 800 directive, a "must-revalidate" cache-response-directive, or an applicable … … 803 803 </t> 804 804 <t> 805 A cache &MUST-NOT; returnstale responses unless it is disconnected805 A cache &MUST-NOT; send stale responses unless it is disconnected 806 806 (i.e., it cannot contact the origin server or otherwise find a forward 807 807 path) or doing so is explicitly allowed (e.g., by the max-stale request … … 872 872 response while attempting to validate a response, it can either 873 873 forward this response to the requesting client, or act as if the 874 server failed to respond. In the latter case, it can returna874 server failed to respond. In the latter case, it can send a 875 875 previously stored response (see <xref 876 876 target="serving.stale.responses" />). … … 1073 1073 the cache will either remove all stored responses related to the effective 1074 1074 request URI, or will mark these as "invalid" and in need of a mandatory 1075 validation before they can be returnedin response to a subsequent request.1075 validation before they can be sent in response to a subsequent request. 1076 1076 </t> 1077 1077 <t> … … 1362 1362 the origin server. This allows an origin server to prevent a cache from 1363 1363 using it to satisfy a request without contacting it, even by caches that 1364 have been configured to returnstale responses.1364 have been configured to send stale responses. 1365 1365 </t> 1366 1366 <t> … … 1757 1757 rectified by a validation (for example, a lossy compression of the 1758 1758 representation) and &MUST-NOT; be deleted by a cache after validation, 1759 unless a full response is returned, in which case they &MUST; be.</t>1759 unless a full response is sent, in which case they &MUST; be.</t> 1760 1760 </list> 1761 1761 </t> … … 1783 1783 <iref primary="true" item="110 Response is Stale (warn code)" x:for-anchor=""/> 1784 1784 <t> 1785 A cache &SHOULD; include this whenever the returnedresponse is stale.1785 A cache &SHOULD; include this whenever the sent response is stale. 1786 1786 </t> 1787 1787 </section> … … 1790 1790 <iref primary="true" item="111 Revalidation Failed (warn code)" x:for-anchor=""/> 1791 1791 <t> 1792 A cache &SHOULD; include this when returning a stale response because an1792 A cache &SHOULD; include this when sending a stale response because an 1793 1793 attempt to validate the response failed, due to an inability to reach 1794 1794 the server. … … 2559 2559 <x:ref>Expires</x:ref> = HTTP-date 2560 2560 2561 <x:ref>HTTP-date</x:ref> = <HTTP-date, defined in [Part2], Section 8.1.1.1>2561 <x:ref>HTTP-date</x:ref> = <HTTP-date, defined in [Part2], Section 7.1.1.1> 2562 2562 2563 2563 <x:ref>OWS</x:ref> = <OWS, defined in [Part1], Section 3.2.3> -
draft-ietf-httpbis/latest/p7-auth.html
r2049 r2052 449 449 } 450 450 @bottom-center { 451 content: "Expires June 1 4, 2013";451 content: "Expires June 18, 2013"; 452 452 } 453 453 @bottom-right { … … 489 489 <meta name="dct.creator" content="Reschke, J. F."> 490 490 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p7-auth-latest"> 491 <meta name="dct.issued" scheme="ISO8601" content="2012-12-1 1">491 <meta name="dct.issued" scheme="ISO8601" content="2012-12-15"> 492 492 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 493 493 <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. This document defines the HTTP Authentication framework."> … … 517 517 <tr> 518 518 <td class="left">Intended status: Standards Track</td> 519 <td class="right">December 1 1, 2012</td>519 <td class="right">December 15, 2012</td> 520 520 </tr> 521 521 <tr> 522 <td class="left">Expires: June 1 4, 2013</td>522 <td class="left">Expires: June 18, 2013</td> 523 523 <td class="right"></td> 524 524 </tr> … … 546 546 in progress”. 547 547 </p> 548 <p>This Internet-Draft will expire on June 1 4, 2013.</p>548 <p>This Internet-Draft will expire on June 18, 2013.</p> 549 549 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 550 550 <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 679 679 <div id="rfc.figure.u.3"></div><pre class="inline"><span id="rfc.iref.g.5"></span> <a href="#challenge.and.response" class="smpl">credentials</a> = <a href="#challenge.and.response" class="smpl">auth-scheme</a> [ 1*<a href="#imported.abnf" class="smpl">SP</a> ( <a href="#challenge.and.response" class="smpl">token68</a> / #<a href="#challenge.and.response" class="smpl">auth-param</a> ) ] 680 680 </pre><p id="rfc.section.2.1.p.14">Upon a request for a protected resource that omits credentials, contains invalid credentials (e.g., a bad password) or partial 681 credentials (e.g., when the authentication scheme requires more than one round trip), an origin server <em class="bcp14">SHOULD</em> returna <a href="#status.401" class="smpl">401 (Unauthorized)</a> response. Such responses <em class="bcp14">MUST</em> include a <a href="#header.www-authenticate" class="smpl">WWW-Authenticate</a> header field containing at least one (possibly new) challenge applicable to the requested resource.681 credentials (e.g., when the authentication scheme requires more than one round trip), an origin server <em class="bcp14">SHOULD</em> send a <a href="#status.401" class="smpl">401 (Unauthorized)</a> response. Such responses <em class="bcp14">MUST</em> include a <a href="#header.www-authenticate" class="smpl">WWW-Authenticate</a> header field containing at least one (possibly new) challenge applicable to the requested resource. 682 682 </p> 683 683 <p id="rfc.section.2.1.p.15">Likewise, upon a request that requires authentication by proxies that omit credentials or contain invalid or partial credentials, 684 a proxy <em class="bcp14">SHOULD</em> returna <a href="#status.407" class="smpl">407 (Proxy Authentication Required)</a> response. Such responses <em class="bcp14">MUST</em> include a <a href="#header.proxy-authenticate" class="smpl">Proxy-Authenticate</a> header field containing a (possibly new) challenge applicable to the proxy.685 </p> 686 <p id="rfc.section.2.1.p.16">A server receiving credentials that are valid, but not adequate to gain access, ought to respond with the <a href="p2-semantics.html#status.403" class="smpl">403 (Forbidden)</a> status code (<a href="p2-semantics.html#status.403" title="403 Forbidden">Section 7.5.3</a> of <a href="#Part2" id="rfc.xref.Part2.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>).684 a proxy <em class="bcp14">SHOULD</em> send a <a href="#status.407" class="smpl">407 (Proxy Authentication Required)</a> response. Such responses <em class="bcp14">MUST</em> include a <a href="#header.proxy-authenticate" class="smpl">Proxy-Authenticate</a> header field containing a (possibly new) challenge applicable to the proxy. 685 </p> 686 <p id="rfc.section.2.1.p.16">A server receiving credentials that are valid, but not adequate to gain access, ought to respond with the <a href="p2-semantics.html#status.403" class="smpl">403 (Forbidden)</a> status code (<a href="p2-semantics.html#status.403" title="403 Forbidden">Section 6.5.3</a> of <a href="#Part2" id="rfc.xref.Part2.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). 687 687 </p> 688 688 <p id="rfc.section.2.1.p.17">The HTTP protocol does not restrict applications to this simple challenge-response mechanism for access authentication. Additional … … 785 785 <div id="rfc.iref.8"></div> 786 786 <h2 id="rfc.section.3.2"><a href="#rfc.section.3.2">3.2</a> <a id="status.407" href="#status.407">407 Proxy Authentication Required</a></h2> 787 <p id="rfc.section.3.2.p.1">This code is similar to <a href="#status.401" class="smpl">401 (Unauthorized)</a>, but indicates that the client ought to first authenticate itself with the proxy. The proxy <em class="bcp14">MUST</em> returna <a href="#header.proxy-authenticate" class="smpl">Proxy-Authenticate</a> header field (<a href="#header.proxy-authenticate" id="rfc.xref.header.proxy-authenticate.1" title="Proxy-Authenticate">Section 4.2</a>) containing a challenge applicable to the proxy for the target resource. The client <em class="bcp14">MAY</em> repeat the request with a suitable <a href="#header.proxy-authorization" class="smpl">Proxy-Authorization</a> header field (<a href="#header.proxy-authorization" id="rfc.xref.header.proxy-authorization.1" title="Proxy-Authorization">Section 4.3</a>).787 <p id="rfc.section.3.2.p.1">This code is similar to <a href="#status.401" class="smpl">401 (Unauthorized)</a>, but indicates that the client ought to first authenticate itself with the proxy. The proxy <em class="bcp14">MUST</em> send a <a href="#header.proxy-authenticate" class="smpl">Proxy-Authenticate</a> header field (<a href="#header.proxy-authenticate" id="rfc.xref.header.proxy-authenticate.1" title="Proxy-Authenticate">Section 4.2</a>) containing a challenge applicable to the proxy for the target resource. The client <em class="bcp14">MAY</em> repeat the request with a suitable <a href="#header.proxy-authorization" class="smpl">Proxy-Authorization</a> header field (<a href="#header.proxy-authorization" id="rfc.xref.header.proxy-authorization.1" title="Proxy-Authorization">Section 4.3</a>). 788 788 </p> 789 789 <h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a> <a id="header.field.definitions" href="#header.field.definitions">Header Field Definitions</a></h1> … … 1176 1176 </li> 1177 1177 <li><em>Part2</em> <a href="#rfc.xref.Part2.1">2.1</a>, <a href="#Part2"><b>8.1</b></a><ul> 1178 <li><em>Section 7.5.3</em> <a href="#rfc.xref.Part2.1">2.1</a></li>1178 <li><em>Section 6.5.3</em> <a href="#rfc.xref.Part2.1">2.1</a></li> 1179 1179 </ul> 1180 1180 </li> -
draft-ietf-httpbis/latest/p7-auth.xml
r2046 r2052 242 242 invalid credentials (e.g., a bad password) or partial credentials (e.g., 243 243 when the authentication scheme requires more than one round trip), an origin 244 server &SHOULD; returna <x:ref>401 (Unauthorized)</x:ref> response. Such244 server &SHOULD; send a <x:ref>401 (Unauthorized)</x:ref> response. Such 245 245 responses &MUST; include a <x:ref>WWW-Authenticate</x:ref> header field 246 246 containing at least one (possibly new) challenge applicable to the … … 250 250 Likewise, upon a request that requires authentication by proxies that omit 251 251 credentials or contain invalid or partial credentials, a proxy &SHOULD; 252 returna <x:ref>407 (Proxy Authentication Required)</x:ref> response. Such responses252 send a <x:ref>407 (Proxy Authentication Required)</x:ref> response. Such responses 253 253 &MUST; include a <x:ref>Proxy-Authenticate</x:ref> header field containing a (possibly 254 254 new) challenge applicable to the proxy. … … 446 446 This code is similar to <x:ref>401 (Unauthorized)</x:ref>, but indicates that the 447 447 client ought to first authenticate itself with the proxy. The proxy &MUST; 448 returna <x:ref>Proxy-Authenticate</x:ref> header field (<xref target="header.proxy-authenticate"/>) containing a448 send a <x:ref>Proxy-Authenticate</x:ref> header field (<xref target="header.proxy-authenticate"/>) containing a 449 449 challenge applicable to the proxy for the target resource. The 450 450 client &MAY; repeat the request with a suitable <x:ref>Proxy-Authorization</x:ref>
Note: See TracChangeset
for help on using the changeset viewer.