Changeset 2052 for draft-ietf-httpbis


Ignore:
Timestamp:
16/12/12 03:46:23 (10 years ago)
Author:
fielding@…
Message:

editorial fixes in methods; use send instead of return, sent instead of returned; partly addresses #419

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

Legend:

Unmodified
Added
Removed

  • draft-ietf-httpbis/latest/p1-messaging.html

    r2049 r2052  
    449449  }
    450450  @bottom-center {
    451        content: "Expires June 14, 2013";
     451       content: "Expires June 18, 2013";
    452452  }
    453453  @bottom-right {
    … …  
    491491      <meta name="dct.creator" content="Reschke, J. F.">
    492492      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p1-messaging-latest">
    493       <meta name="dct.issued" scheme="ISO8601" content="2012-12-11">
     493      <meta name="dct.issued" scheme="ISO8601" content="2012-12-15">
    494494      <meta name="dct.replaces" content="urn:ietf:rfc:2145">
    495495      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    … …  
    520520            <tr>
    521521               <td class="left">Intended status: Standards Track</td>
    522                <td class="right">December 11, 2012</td>
     522               <td class="right">December 15, 2012</td>
    523523            </tr>
    524524            <tr>
    525                <td class="left">Expires: June 14, 2013</td>
     525               <td class="left">Expires: June 18, 2013</td>
    526526               <td class="right"></td>
    527527            </tr>
    … …  
    551551         in progress”.
    552552      </p>
    553       <p>This Internet-Draft will expire on June 14, 2013.</p>
     553      <p>This Internet-Draft will expire on June 18, 2013.</p>
    554554      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    555555      <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
    … …  
    884884         or an intranet-to-Internet privacy filter. Such transformations are presumed to be desired by the client (or client organization)
    885885         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.
    887887      </p>
    888888      <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
    … …  
    10541054      </p>
    10551055      <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&nbsp;3</a>) containing the URI's identifying data (<a href="#message.routing" title="Message Routing">Section&nbsp;5</a>) to the server. If the server responds to that request with a non-interim HTTP response message, as described in <a href="p2-semantics.html#status.codes" title="Response Status Codes">Section 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&nbsp;3</a>) containing the URI's identifying data (<a href="#message.routing" title="Message Routing">Section&nbsp;5</a>) to the server. If the server responds to that request with a non-interim HTTP response message, as described in <a href="p2-semantics.html#status.codes" title="Response Status Codes">Section 6</a> of <a href="#Part2" id="rfc.xref.Part2.5"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>, then that response is considered an authoritative answer to the client's request.
    10571057      </p>
    10581058      <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
    … …  
    11541154      </div>
    11551155      <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.
    11571157      </p>
    11581158      <div id="rfc.iref.r.6"></div>
    … …  
    11671167      </p>
    11681168      <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>).
    11701170      </p>
    11711171      <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.
    … …  
    11781178</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
    11791179         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),
    11811181         the status codes defined by this specification, considerations for the definition of new status codes, and the IANA registry.
    11821182      </p>
    … …  
    11991199                 ; see <a href="#field.parsing" title="Field Parsing">Section&nbsp;3.2.4</a>
    12001200</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.
    12021202      </p>
    12031203      <h3 id="rfc.section.3.2.1"><a href="#rfc.section.3.2.1">3.2.1</a>&nbsp;<a id="field.extensibility" href="#field.extensibility">Field Extensibility</a></h3>
    … …  
    12071207         the protocol version if their defined semantics allow them to be safely ignored by recipients that do not recognize them.
    12081208      </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&nbsp;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&nbsp;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.
    12101210      </p>
    12111211      <h3 id="rfc.section.3.2.2"><a href="#rfc.section.3.2.2">3.2.2</a>&nbsp;<a id="field.order" href="#field.order">Field Order</a></h3>
    … …  
    13401340      </p>
    13411341      <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&nbsp;3.1.2</a>). Responses to the HEAD request method never include a message body because the associated response header fields (e.g., <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a>, <a href="#header.content-length" class="smpl">Content-Length</a>, etc.), if present, indicate only what their values would have been if the request method had been GET (<a href="p2-semantics.html#HEAD" title="HEAD">Section 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&nbsp;3.1.2</a>). Responses to the HEAD request method never include a message body because the associated response header fields (e.g., <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a>, <a href="#header.content-length" class="smpl">Content-Length</a>, etc.), if present, indicate only what their values would have been if the request method had been GET (<a href="p2-semantics.html#HEAD" title="HEAD">Section 4.3.2</a> of <a href="#Part2" id="rfc.xref.Part2.11"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). <a href="p2-semantics.html#status.2xx" class="smpl">2xx (Successful)</a> responses to CONNECT switch to tunnel mode instead of having a message body (<a href="p2-semantics.html#CONNECT" title="CONNECT">Section 4.3.6</a> of <a href="#Part2" id="rfc.xref.Part2.12"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). All <a href="p2-semantics.html#status.1xx" class="smpl">1xx (Informational)</a>, <a href="p2-semantics.html#status.204" class="smpl">204 (No Content)</a>, and <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a> responses <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.
    13431343      </p>
    13441344      <div id="rfc.iref.t.4"></div>
    … …  
    13821382         payload body. For messages that do include a payload body, the Content-Length field-value provides the framing information
    13831383         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>).
    13851385      </p>
    13861386      <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>
    … …  
    13931393         anticipate such a body.
    13941394      </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 sent
     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 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
    13961396         in the payload body of a response if the same request had used the GET method.
    13971397      </p>
    … …  
    13991399         in the payload body of a <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> response to the same request.
    14001400      </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>).
    14021402      </p>
    14031403      <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
    … …  
    16601660      </p>
    16611661      <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;
    16631663         a value of 0 means "not acceptable".
    16641664      </p>
    … …  
    17401740      </p>
    17411741      <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,
    17431743         </p>
    17441744      </div>
    17451745      <div id="rfc.figure.u.41"></div><pre class="text2">CONNECT www.example.com:80 HTTP/1.1
    17461746</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,
    17481748            the client <em class="bcp14">MUST</em> send only "*" (%x2A) as the request-target. For example,
    17491749         </p>
    … …  
    18271827      <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
    18281828         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.
    18301830      </p>
    18311831      <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
    … …  
    19971997      <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.
    19981998      </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 to
     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 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
    20002000         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.
    20012001      </p>
    … …  
    20032003      <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
    20042004         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 understanding
     2005         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
    20062006         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.
    20072007      </p>
    … …  
    20962096      </p>
    20972097      <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>).
    20992099      </p>
    21002100      <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
    … …  
    24792479      </p>
    24802480      <h2 id="rfc.section.8.3"><a href="#rfc.section.8.3">8.3</a>&nbsp;<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 returned by 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.
    24822482         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
    24832483         Windows, and other operating systems use ".." as a path component to indicate a directory level above the current one. On
    … …  
    25122512         that most implementations will choose substantially higher limits.
    25132513      </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>).
    25152515      </p>
    25162516      <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
    … …  
    32773277                        <li><em>Section 3.1.2.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.13">3.3.1</a>, <a href="#rfc.xref.Part2.26">7.4</a></li>
    32783278                        <li><em>Section 3.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.22">5.7.2</a></li>
    3279                         <li><em>Section 5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.6">3.1.1</a></li>
    3280                         <li><em>Section 5.2.2</em>&nbsp;&nbsp;<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>&nbsp;&nbsp;<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>&nbsp;&nbsp;<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>&nbsp;&nbsp;<a href="#rfc.xref.Part2.20">5.3</a></li>
    3284                         <li><em>Section 6.3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.17">4.3</a></li>
    3285                         <li><em>Section 7</em>&nbsp;&nbsp;<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>&nbsp;&nbsp;<a href="#rfc.xref.Part2.21">5.6</a></li>
    3287                         <li><em>Section 7.3.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.3">2.3</a></li>
    3288                         <li><em>Section 7.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.25">6.7</a></li>
    3289                         <li><em>Section 7.5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.28">8.6</a></li>
    3290                         <li><em>Section 7.5.12</em>&nbsp;&nbsp;<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>&nbsp;&nbsp;<a href="#rfc.xref.Part2.9">3.2</a></li>
    3292                         <li><em>Section 8.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.14">3.3.2</a></li>
    3293                         <li><em>Section 9.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.10">3.2.1</a></li>
     3279                        <li><em>Section 4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.6">3.1.1</a></li>
     3280                        <li><em>Section 4.2.2</em>&nbsp;&nbsp;<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>&nbsp;&nbsp;<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>&nbsp;&nbsp;<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>&nbsp;&nbsp;<a href="#rfc.xref.Part2.20">5.3</a></li>
     3284                        <li><em>Section 5.3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.17">4.3</a></li>
     3285                        <li><em>Section 6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.5">2.7.1</a>, <a href="#rfc.xref.Part2.8">3.1.2</a></li>
     3286                        <li><em>Section 6.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.21">5.6</a></li>
     3287                        <li><em>Section 6.3.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.3">2.3</a></li>
     3288                        <li><em>Section 6.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.25">6.7</a></li>
     3289                        <li><em>Section 6.5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.28">8.6</a></li>
     3290                        <li><em>Section 6.5.12</em>&nbsp;&nbsp;<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>&nbsp;&nbsp;<a href="#rfc.xref.Part2.9">3.2</a></li>
     3292                        <li><em>Section 7.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.14">3.3.2</a></li>
     3293                        <li><em>Section 8.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.10">3.2.1</a></li>
    32943294                        <li><em>Appendix A</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.2">2.1</a></li>
    32953295                     </ul>

  • draft-ietf-httpbis/latest/p1-messaging.xml

    r2048 r2052  
    35383538<t>
    35393539   Origin servers &SHOULD; be careful to restrict
    3540    the documents returned by HTTP requests to be only those that were
     3540   the documents sent by HTTP requests to be only those that were
    35413541   intended by the server administrators. If an HTTP server translates
    35423542   HTTP URIs directly into file system calls, the server &MUST; take

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

    r2051 r2052  
    12571257      <h2 id="rfc.section.4.1"><a href="#rfc.section.4.1">4.1</a>&nbsp;<a id="method.overview" href="#method.overview">Overview</a></h2>
    12581258      <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&nbsp;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&nbsp;5</a>) if those additional semantics do not conflict with the method.
    12601261      </p>
    12611262      <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>
    … …  
    12661267      </p>
    12671268      <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 are
    1269          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.
    12701271      </p>
    12711272      <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.
    … …  
    13261327         </table>
    13271328      </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&nbsp;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 within
    1331          the HTTP Method Registry maintained by IANA, as defined in <a href="#method.registry" title="Method Registry">Section&nbsp;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&nbsp;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&nbsp;8.1</a>.
    13321333      </p>
    13331334      <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&nbsp;7.4.1</a>). However, the set of allowed methods can change dynamically. When a request message is received that is unrecognized or
    … …  
    13491350         the Web will often have the side-effect of charging an advertising account.
    13501351      </p>
    1351       <p id="rfc.section.4.2.1.p.3">The GET, HEAD, OPTIONS, and TRACE request methods 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>
    13521353      <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
    13531354         performance optimization (pre-fetching) to work without fear of causing harm. In addition, it allows a user agent to apply
    … …  
    13661367      <div id="rfc.iref.i.1"></div>
    13671368      <h3 id="rfc.section.4.2.2"><a href="#rfc.section.4.2.2">4.2.2</a>&nbsp;<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 request
    1369          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.
    13701371      </p>
    13711372      <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
    … …  
    13901391      <div id="rfc.iref.g.16"></div>
    13911392      <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 representation
    1393          in the response and not the source text of 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.
    13941395      </p>
    13951396      <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
    … …  
    14091410      <h3 id="rfc.section.4.3.2"><a href="#rfc.section.4.3.2">4.3.2</a>&nbsp;<a id="HEAD" href="#HEAD">HEAD</a></h3>
    14101411      <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> return a message body in the response. The metadata contained in the HTTP header fields in response to a HEAD request <em class="bcp14">SHOULD</em> be identical to the information sent in response to a GET request. This method can be used for obtaining metadata about the
     1412      <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
    14121413         representation implied by the request without transferring the representation data. This method is often used for testing
    14131414         hypertext links for validity, accessibility, and recent modification.
    … …  
    14211422      <h3 id="rfc.section.4.3.3"><a href="#rfc.section.4.3.3">4.3.3</a>&nbsp;<a id="POST" href="#POST">POST</a></h3>
    14221423      <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):
    14241425      </p>
    14251426      <ul>
    … …  
    14291430         <li>Extending a database through an append operation.</li>
    14301431      </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 request
    1432          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.
    14331434      </p>
    14341435      <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
    14351436         the result.
    14361437      </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&nbsp;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&nbsp;7.1.2</a>).
    14381439      </p>
    14391440      <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&nbsp;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.
    … …  
    14451446      <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
    14461447         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 returned 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         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
    14481449         upon by other user agents in parallel, or might be subject to dynamic processing by the origin server, before any subsequent
    14491450         GET is received. A successful response only implies that the user agent's intent was achieved at the time of its processing
    … …  
    14531454         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.
    14541455      </p>
    1455       <p id="rfc.section.4.3.4.p.3">Unrecognized header fields <em class="bcp14">SHOULD</em> be ignored (i.e., not saved as 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).
    14561457      </p>
    14571458      <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
    … …  
    15061507      <h3 id="rfc.section.4.3.5"><a href="#rfc.section.4.3.5">4.3.5</a>&nbsp;<a id="DELETE" href="#DELETE">DELETE</a></h3>
    15071508      <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
    15161524         some existing implementations to reject the request.
    15171525      </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 responses
     1526      <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
    15191527         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>).
    15201528      </p>
    15211529      <div id="rfc.iref.c.9"></div>
    15221530      <h3 id="rfc.section.4.3.6"><a href="#rfc.section.4.3.6">4.3.6</a>&nbsp;<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.
    15271536         For example,
    15281537      </p>
    … …  
    15301539Host: server.example.com:80
    15311540
    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.
    15351545      </p>
    15361546      <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.
    … …  
    15391549         governed by HTTP.
    15401550      </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>
    15421552      <div id="rfc.figure.u.19"></div><pre class="text2">CONNECT server.example.com:80 HTTP/1.1
    15431553Host: server.example.com:80
    … …  
    15471557         some existing implementations to reject the request.
    15481558      </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.
    15601564      </p>
    15611565      <h3 id="rfc.section.4.3.7"><a href="#rfc.section.4.3.7">4.3.7</a>&nbsp;<a id="OPTIONS" href="#OPTIONS">OPTIONS</a></h3>
    … …  
    16831687      <p id="rfc.section.5.1.2.1.p.4">Requirements for HTTP/1.1 origin servers: </p>
    16841688      <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.
    16861690         </li>
    16871691         <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
    … …  
    23822386      <div id="rfc.iref.72"></div>
    23832387      <h3 id="rfc.section.6.3.1"><a href="#rfc.section.6.3.1">6.3.1</a>&nbsp;<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 with the 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>
    23852389      <dl>
    23862390         <dt>GET</dt>
    … …  
    24022406         (e.g., in the case of a response to a PUT request).
    24032407      </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.
    24052409      </p>
    24062410      <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
    … …  
    24152419      <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
    24162420         (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 returned 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
     2421         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
    24182422         user can expect the request to be fulfilled.
    24192423      </p>
    … …  
    24292433      <h3 id="rfc.section.6.3.5"><a href="#rfc.section.6.3.5">6.3.5</a>&nbsp;<a id="status.204" href="#status.204">204 No Content</a></h3>
    24302434      <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 return in the response payload body. Metadata in the response header fields refer to the target resource and its
     2435         content to send in the response payload body. Metadata in the response header fields refer to the target resource and its
    24322436         current representation after the requested action.
    24332437      </p>
    … …  
    25142518      <div id="rfc.iref.73"></div>
    25152519      <h3 id="rfc.section.6.4.2"><a href="#rfc.section.6.4.2">6.4.2</a>&nbsp;<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 effective
    2517          request URI to one or more of the new references returned by 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.
    25182522      </p>
    25192523      <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.
    … …  
    26172621      </p>
    26182622      <div class="note" id="rfc.section.6.5.6.p.3">
    2619          <p> <b>Note:</b> HTTP/1.1 servers are allowed to return responses which are not acceptable according to the accept header fields sent in the
     2623         <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
    26202624            request. In some cases, this might even be preferable to sending a 406 response. User agents are encouraged to inspect the
    26212625            header fields of an incoming response to determine if it is acceptable.
    … …  
    27372741      </p>
    27382742      <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 Server
     2743         <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
    27402744               Error)</a> when DNS lookups time out.
    27412745         </p>

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

    r2051 r2052  
    10461046   it indicates the purpose for which the client has made this request
    10471047   and what is expected by the client as a successful result.  The request
    1048    semantics &MAY; be further specialized by the semantics of some header
     1048   semantics might be further specialized by the semantics of some header
    10491049   fields when present in a request (<xref target="request.header.fields"/>)
    10501050   if those additional semantics do not conflict with the method.
    … …  
    10651065   not resource-specific, since uniform interfaces provide for better
    10661066   visibility and reuse in network-based systems <xref target="REST"/>.
    1067    Once defined, a standardized method &MUST; have the same semantics when
     1067   Once defined, a standardized method ought to have the same semantics when
    10681068   applied to any resource, though each resource determines for itself
    10691069   whether those semantics are implemented or allowed.
    … …  
    11051105</texttable>
    11061106<t>
    1107    The methods GET and HEAD &MUST; be supported by all general-purpose
    1108    servers. All other methods are &OPTIONAL;.
    1109    When implemented, a server &MUST; implement the above methods according
    1110    to the semantics defined for them in <xref target="method.definitions"/>.
    1111 </t>
    1112 <t>
    1113    Additional methods &MAY; be used in HTTP; many have already been
    1114    standardized outside the scope of this specification and ought to be
    1115    registered within the HTTP Method Registry maintained by IANA, as defined
    1116    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"/>.
    11171117</t>
    11181118<t>
    … …  
    11551155</t>
    11561156<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.
    11581159</t>
    11591160<t>
    … …  
    11921193   "<x:dfn anchor="idempotent">idempotent</x:dfn>" if the intended effect
    11931194   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.
    11951197</t>
    11961198<t>
    … …  
    12401242</t>
    12411243<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.
    12461247</t>
    12471248<t>
    … …  
    12871288<t>
    12881289   The HEAD method is identical to GET except that the server &MUST-NOT;
    1289    return a message body in the response. The metadata contained
     1290   send a message body in the response. The metadata contained
    12901291   in the HTTP header fields in response to a HEAD request &SHOULD; be identical
    12911292   to the information sent in response to a GET request. This method can
    … …  
    13121313   The POST method requests that the origin server accept the
    13131314   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 the
    1315    following functions:
     1315   target resource. For example, POST is frequently used for the following
     1316   functions (among others):
    13161317  <list style="symbols">
    13171318    <t>
    … …  
    13331334<t>
    13341335   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.
    13361337</t>
    13371338<t>
    … …  
    13431344</t>
    13441345<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"/>).
    13491351</t>
    13501352<t>
    … …  
    13721374   enclosed in the request message payload.  A successful PUT of a given
    13731375   representation would suggest that a subsequent GET on that same target
    1374    resource will result in an equivalent representation being returned in
     1376   resource will result in an equivalent representation being sent in
    13751377   a <x:ref>200 (OK)</x:ref> response.  However, there is no guarantee that
    13761378   such a state change will be observable, since the target resource might be
    … …  
    13901392</t>
    13911393<t>
    1392    Unrecognized header fields &SHOULD; be ignored (i.e., not saved
    1393    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).
    13941396</t>
    13951397<t>
    … …  
    14951497  <iref primary="true" item="DELETE method" x:for-anchor=""/>
    14961498<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 &mdash; 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.
    15121529</t>
    15131530<t>
    … …  
    15271544  <iref primary="true" item="CONNECT method" x:for-anchor=""/>
    15281545<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,
    15381557</t>
    15391558<figure><artwork type="message/http; msgtype=&#34;request&#34;" x:indent-with="  ">
    … …  
    15431562</artwork></figure>
    15441563<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.
    15511572</t>
    15521573<t>
    … …  
    15621583<t>
    15631584   Proxy authentication might be used to establish the
    1564    authority to create a tunnel:
     1585   authority to create a tunnel.  For example,
    15651586</t>
    15661587<figure><artwork type="message/http; msgtype=&#34;request&#34;" x:indent-with="  ">
    … …  
    15761597</t>
    15771598<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,
    15981603   that data will be discarded.
    15991604</t>
    16001605<t>
    16011606   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 is
    1603    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.
    16041609</t>
    16051610</section>
    … …  
    18491854    <t> Upon receiving a request which includes an <x:ref>Expect</x:ref> header
    18501855        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 read
    1852         from the input stream, or respond with a final status code. The
    1853         origin server &MUST-NOT; wait for the payload body before sending
    1854         the <x:ref>100 (Continue)</x:ref> response. If it responds with a final status
    1855         code, it &MAY; close the transport connection or it &MAY; continue
    1856         to 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.
    18581863    </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.
    18721878    </t>
    1873     <t> An origin server &MAY; omit a <x:ref>100 (Continue)</x:ref> response if it has
    1874         already received some or all of the payload body for the
     1879    <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
    18751881        corresponding request.
    18761882    </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 is
    1879         received and processed, unless it terminates the transport
    1880         connection prematurely.
     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.
    18811887    </t>
    18821888    <t> If an origin server receives a request that does not include an
    … …  
    26582664  <x:anchor-alias value="200 (OK)"/>
    26592665<t>
    2660    The request has succeeded. The payload returned with the response
     2666   The request has succeeded. The payload sent in the response
    26612667   is dependent on the method used in the request, for example:
    26622668  <list style="hanging">
    … …  
    26972703</t>
    26982704<t>
    2699    The origin server &MUST; create the resource(s) before returning the 201 status
     2705   The origin server &MUST; create the resource(s) before sending the 201 status
    27002706   code. If the action cannot be carried out immediately, the server &SHOULD;
    27012707   respond with a <x:ref>202 (Accepted)</x:ref> response instead.
    … …  
    27252731   batch-oriented process that is only run once per day) without
    27262732   requiring that the user agent's connection to the server persist
    2727    until the process is completed. The representation returned with this
     2733   until the process is completed. The representation sent with this
    27282734   response &SHOULD; include an indication of the request's current status
    27292735   and either a pointer to a status monitor or some estimate of when the
    … …  
    27572763   The 204 (No Content) status code indicates that the server has
    27582764   successfully fulfilled the request and that there is no additional
    2759    content to return in the response payload body.  Metadata in the
     2765   content to send in the response payload body.  Metadata in the
    27602766   response header fields refer to the target resource and its current
    27612767   representation after the requested action.
    … …  
    29292935<t>
    29302936   The target resource has been assigned a new permanent URI and any
    2931    future references to this resource &SHOULD; use one of the returned
     2937   future references to this resource &SHOULD; use one of the enclosed
    29322938   URIs.  Clients with link editing capabilities ought to automatically
    29332939   re-link references to the effective request URI to one or more of the new
    2934    references returned by the server, where possible.
     2940   references sent by the server, where possible.
    29352941</t>
    29362942<t>
    … …  
    31553161<x:note>
    31563162  <t>
    3157     &Note; HTTP/1.1 servers are allowed to return responses which are
     3163    &Note; HTTP/1.1 servers are allowed to send responses which are
    31583164    not acceptable according to the accept header fields sent in the
    31593165    request. In some cases, this might even be preferable to sending a
    … …  
    34053411  <t>
    34063412    <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 Server
     3413    send <x:ref>400 (Bad Request)</x:ref> or <x:ref>500 (Internal Server
    34083414    Error)</x:ref> when DNS lookups time out.
    34093415  </t>

  • draft-ietf-httpbis/latest/p4-conditional.html

    r2049 r2052  
    449449  }
    450450  @bottom-center {
    451        content: "Expires June 14, 2013";
     451       content: "Expires June 18, 2013";
    452452  }
    453453  @bottom-right {
    … …  
    491491      <meta name="dct.creator" content="Reschke, J. F.">
    492492      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p4-conditional-latest">
    493       <meta name="dct.issued" scheme="ISO8601" content="2012-12-11">
     493      <meta name="dct.issued" scheme="ISO8601" content="2012-12-15">
    494494      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    495495      <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.">
    … …  
    517517            </tr>
    518518            <tr>
    519                <td class="left">Expires: June 14, 2013</td>
    520                <td class="right">December 11, 2012</td>
     519               <td class="left">Expires: June 18, 2013</td>
     520               <td class="right">December 15, 2012</td>
    521521            </tr>
    522522         </tbody>
    … …  
    545545         in progress”.
    546546      </p>
    547       <p>This Internet-Draft will expire on June 14, 2013.</p>
     547      <p>This Internet-Draft will expire on June 18, 2013.</p>
    548548      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    549549      <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
    … …  
    857857      </div>
    858858      <h3 id="rfc.section.2.3.3"><a href="#rfc.section.2.3.3">2.3.3</a>&nbsp;<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>):
    860860      </p>
    861861      <div id="rfc.figure.u.5"></div>
    … …  
    921921         </li>
    922922      </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> return 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.
     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.
    924924      </p>
    925925      <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> return a locally cached response to the client unless that cached response is consistent with all of the conditional header
     926         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
    927927         fields in the request.
    928928      </p>
    … …  
    987987            Failed)</a> status code.
    988988      </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> return a <a href="#status.304" class="smpl">304
     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> send a <a href="#status.304" class="smpl">304
    990990            (Not Modified)</a> response.
    991991      </p>
    … …  
    10171017            a normal GET.
    10181018         </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> return a <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.
    10201020         </li>
    10211021      </ol>
    … …  
    10631063      <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.
    10641064      </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">200
     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 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
    10661066            (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.
    10671067      </p>
    … …  
    13171317  <a href="#imported.abnf" class="smpl">obs-text</a>      = &lt;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>&gt;
    13181318</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>     = &lt;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>&gt;
     1319      <div id="rfc.figure.u.17"></div><pre class="inline">  <a href="#imported.abnf" class="smpl">HTTP-date</a>     = &lt;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>&gt;
    13201320</pre><h1 id="rfc.section.C"><a href="#rfc.section.C">C.</a>&nbsp;<a id="collected.abnf" href="#collected.abnf">Collected ABNF</a></h1>
    13211321      <div id="rfc.figure.u.18"></div> <pre class="inline"><a href="#header.etag" class="smpl">ETag</a> = entity-tag
    13221322
    1323 <a href="#imported.abnf" class="smpl">HTTP-date</a> = &lt;HTTP-date, defined in [Part2], Section 8.1.1.1&gt;
     1323<a href="#imported.abnf" class="smpl">HTTP-date</a> = &lt;HTTP-date, defined in [Part2], Section 7.1.1.1&gt;
    13241324
    13251325<a href="#header.if-match" class="smpl">If-Match</a> = "*" / ( *( "," OWS ) entity-tag *( OWS "," [ OWS
    … …  
    14431443                  <li><em>Part2</em>&nbsp;&nbsp;<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>
    14441444                        <li><em>Section 3.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.2">2.3.3</a></li>
    1445                         <li><em>Section 6.3.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.3">2.3.3</a></li>
    1446                         <li><em>Section 8.1.1.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.5">B</a></li>
    1447                         <li><em>Section 8.1.1.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.4">4.1</a></li>
     1445                        <li><em>Section 5.3.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.3">2.3.3</a></li>
     1446                        <li><em>Section 7.1.1.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.5">B</a></li>
     1447                        <li><em>Section 7.1.1.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.4">4.1</a></li>
    14481448                     </ul>
    14491449                  </li>

  • draft-ietf-httpbis/latest/p4-conditional.xml

    r2046 r2052  
    533533<section title="Example: Entity-tags varying on Content-Negotiated Resources" anchor="example.entity.tag.vs.conneg">
    534534<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 on
    537    the <x:ref>Accept-Encoding</x:ref> request header field
    538    (&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;):
    539539</t>
    540540<figure><preamble>>> Request:</preamble><artwork type="message/http; msgtype=&#34;request&#34;"  x:indent-with="  ">
    … …  
    640640   entity-tags (e.g., in an <x:ref>If-Match</x:ref>, <x:ref>If-None-Match</x:ref>,
    641641   or <x:ref>If-Range</x:ref> header field) as cache validators, &MUST-NOT;
    642    return a response status code of <x:ref>304 (Not Modified)</x:ref> unless
     642   send a response status code of <x:ref>304 (Not Modified)</x:ref> unless
    643643   doing so is consistent with all of the conditional header fields in the
    644644   request.
    … …  
    647647   An HTTP/1.1 caching proxy, upon receiving a conditional request that
    648648   includes both a Last-Modified date and one or more entity-tags as
    649    cache validators, &MUST-NOT; return a locally cached response to the
     649   cache validators, &MUST-NOT; send a locally cached response to the
    650650   client unless that cached response is consistent with all of the
    651651   conditional header fields in the request.
    … …  
    777777   as if the If-None-Match header field did not exist, but &MUST; also ignore
    778778   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; return a <x:ref>304
     779   is, if no entity-tags match, then the server &MUST-NOT; send a <x:ref>304
    780780   (Not Modified)</x:ref> response.
    781781</t>
    … …  
    837837
    838838      <t>If the selected representation has not been modified since a valid
    839          If-Modified-Since date, the server &SHOULD; return a
     839         If-Modified-Since date, the server &SHOULD; send a
    840840         <x:ref>304 (Not Modified)</x:ref> response.</t>
    841841  </list>
    … …  
    14371437<x:ref>ETag</x:ref> = entity-tag
    14381438
    1439 <x:ref>HTTP-date</x:ref> = &lt;HTTP-date, defined in [Part2], Section 8.1.1.1&gt;
     1439<x:ref>HTTP-date</x:ref> = &lt;HTTP-date, defined in [Part2], Section 7.1.1.1&gt;
    14401440
    14411441<x:ref>If-Match</x:ref> = "*" / ( *( "," OWS ) entity-tag *( OWS "," [ OWS

  • draft-ietf-httpbis/latest/p5-range.html

    r2049 r2052  
    449449  }
    450450  @bottom-center {
    451        content: "Expires June 14, 2013";
     451       content: "Expires June 18, 2013";
    452452  }
    453453  @bottom-right {
    … …  
    493493      <meta name="dct.creator" content="Reschke, J. F.">
    494494      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p5-range-latest">
    495       <meta name="dct.issued" scheme="ISO8601" content="2012-12-11">
     495      <meta name="dct.issued" scheme="ISO8601" content="2012-12-15">
    496496      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    497497      <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.">
    … …  
    519519            </tr>
    520520            <tr>
    521                <td class="left">Expires: June 14, 2013</td>
     521               <td class="left">Expires: June 18, 2013</td>
    522522               <td class="right">J. Reschke, Editor</td>
    523523            </tr>
    … …  
    528528            <tr>
    529529               <td class="left"></td>
    530                <td class="right">December 11, 2012</td>
     530               <td class="right">December 15, 2012</td>
    531531            </tr>
    532532         </tbody>
    … …  
    553553         in progress”.
    554554      </p>
    555       <p>This Internet-Draft will expire on June 14, 2013.</p>
     555      <p>This Internet-Draft will expire on June 18, 2013.</p>
    556556      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    557557      <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
    … …  
    693693         </li>
    694694      </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 returned with 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.
    696696      </p>
    697697      <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.
    … …  
    699699      <div id="rfc.iref.3"></div>
    700700      <h2 id="rfc.section.3.2"><a href="#rfc.section.3.2">3.2</a>&nbsp;<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> return 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&nbsp;5.4</a>), and none of the ranges-specifier values in this field overlap the current extent of the selected resource, and the request
     701      <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&nbsp;5.4</a>), and none of the ranges-specifier values in this field overlap the current extent of the selected resource, and the request
    702702         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&nbsp;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
    703703         length of the selected resource.)
    704704      </p>
    705       <p id="rfc.section.3.2.p.2">When this status code is returned 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&nbsp;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&nbsp;5.2</a>). This response <em class="bcp14">MUST NOT</em> use the multipart/byteranges content-type.
    706706      </p>
    707707      <div id="rfc.figure.u.2"></div>
    … …  
    736736      <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.
    737737      </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> return them 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.
    739739      </p>
    740740      <h2 id="rfc.section.4.2"><a href="#rfc.section.4.2">4.2</a>&nbsp;<a id="combining.byte.ranges" href="#combining.byte.ranges">Combining Ranges</a></h2>
    … …  
    828828      </ul>
    829829      <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 return a <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).
    831831      </p>
    832832      <div id="rfc.iref.i.1"></div>
    … …  
    888888      <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
    889889         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> return a 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.
    891891      </p>
    892892      <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.
    … …  
    925925      <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>
    926926      <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             In 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 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 returned if 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.
    931931         </li>
    932932      </ul>
    … …  
    934934      </p>
    935935      <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 return the requested range to its client.
     936         representation in reply, it <em class="bcp14">MAY</em> only send the requested range to its client.
    937937      </p>
    938938      <h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a>&nbsp;<a id="IANA.considerations" href="#IANA.considerations">IANA Considerations</a></h1>
    … …  
    12331233      <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&nbsp;5.2</a>)
    12341234      </p>
    1235       <p id="rfc.section.B.p.3">Servers are given more leeway in what they return to 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>
    12361236      <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&nbsp;A</a>)
    12371237      </p>
    … …  
    12501250  <a href="#imported.abnf" class="smpl">token</a>      = &lt;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>&gt;
    12511251</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>  = &lt;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>&gt;
     1252      <div id="rfc.figure.u.25"></div><pre class="inline">  <a href="#imported.abnf" class="smpl">HTTP-date</a>  = &lt;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>&gt;
    12531253  <a href="#imported.abnf" class="smpl">entity-tag</a> = &lt;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>&gt;
    12541254</pre><h1 id="rfc.section.D"><a href="#rfc.section.D">D.</a>&nbsp;<a id="collected.abnf" href="#collected.abnf">Collected ABNF</a></h1>
    … …  
    12571257<a href="#header.content-range" class="smpl">Content-Range</a> = byte-content-range-spec / other-content-range-spec
    12581258
    1259 <a href="#imported.abnf" class="smpl">HTTP-date</a> = &lt;HTTP-date, defined in [Part2], Section 8.1.1.1&gt;
     1259<a href="#imported.abnf" class="smpl">HTTP-date</a> = &lt;HTTP-date, defined in [Part2], Section 7.1.1.1&gt;
    12601260
    12611261<a href="#header.if-range" class="smpl">If-Range</a> = entity-tag / HTTP-date
    … …  
    13991399                  </li>
    14001400                  <li><em>Part2</em>&nbsp;&nbsp;<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>&nbsp;&nbsp;<a href="#rfc.xref.Part2.1">C</a></li>
     1401                        <li><em>Section 7.1.1.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.1">C</a></li>
    14021402                     </ul>
    14031403                  </li>

  • draft-ietf-httpbis/latest/p5-range.xml

    r2046 r2052  
    273273   header field, it &SHOULD-NOT; include other representation header fields.
    274274   Otherwise, the response &MUST; include all of the representation header
    275    fields that would have been returned with a <x:ref>200 (OK)</x:ref> response
     275   fields that would have been sent with a <x:ref>200 (OK)</x:ref> response
    276276   to the same request.
    277277</t>
    … …  
    286286  <x:anchor-alias value="416 (Requested Range Not Satisfiable)"/>
    287287<t>
    288    A server &SHOULD; return a response with this status code if a request
     288   A server &SHOULD; send a response with this status code if a request
    289289   included a <x:ref>Range</x:ref> header field (<xref target="header.range"/>),
    290290   and none of the ranges-specifier values in this field overlap the current
    … …  
    296296</t>
    297297<t>
    298    When this status code is returned for a byte-range request, the
     298   When this status code is sent for a byte-range request, the
    299299   response &SHOULD; include a <x:ref>Content-Range</x:ref> header field
    300300   specifying the current length of the representation (see <xref target="header.content-range"/>).
    … …  
    359359<t>
    360360   When a client asks for multiple ranges in one request, the
    361    server &SHOULD; return them in the order that they appeared in the
     361   server &SHOULD; send them in the order that they appeared in the
    362362   request.
    363363</t>
    … …  
    558558   syntactically invalid, or if it might be seen as a denial-of-service
    559559   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 return a <x:ref>200 (OK)</x:ref>
     560   header field did not exist. (Normally, this means send a <x:ref>200 (OK)</x:ref>
    561561   response containing the full representation).
    562562</t>
    … …  
    690690   suffix-length, then the byte-range-set is satisfiable.
    691691   Otherwise, the byte-range-set is unsatisfiable. If the byte-range-set
    692    is unsatisfiable, the server &SHOULD; return a response with a
     692   is unsatisfiable, the server &SHOULD; send a response with a
    693693   <x:ref>416 (Requested Range Not Satisfiable)</x:ref> status code. Otherwise, the server
    694    &SHOULD; return a response with a <x:ref>206 (Partial Content)</x:ref> status code
     694   &SHOULD; send a response with a <x:ref>206 (Partial Content)</x:ref> status code
    695695   containing the satisfiable ranges of the representation.
    696696</t>
    … …  
    768768  <list style="symbols">
    769769     <t>The presence of a Range header field in an unconditional GET modifies
    770         what is returned if the GET is otherwise successful. In other
     770        what is sent if the GET is otherwise successful. In other
    771771        words, the response carries a status code of <x:ref>206 (Partial Content)</x:ref>
    772772        instead of <x:ref>200 (OK)</x:ref>.</t>
    … …  
    776776        <x:ref>If-None-Match</x:ref>, or one or both of
    777777        <x:ref>If-Unmodified-Since</x:ref> and <x:ref>If-Match</x:ref>) modifies
    778         what is returned if the GET is otherwise successful and the
     778        what is sent if the GET is otherwise successful and the
    779779        condition is true. It does not affect the <x:ref>304 (Not Modified)</x:ref>
    780         response returned if the conditional is false.</t>
     780        response sent if the conditional is false.</t>
    781781  </list>
    782782</t>
    … …  
    789789   If a proxy that supports ranges receives a Range request, forwards
    790790   the request to an inbound server, and receives an entire representation in
    791    reply, it &MAY; only return the requested range to its client.
     791   reply, it &MAY; only send the requested range to its client.
    792792</t>
    793793</section>
    … …  
    13071307</t>
    13081308<t>
    1309   Servers are given more leeway in what they return to a range request,
     1309  Servers are given more leeway in what they send to a range request,
    13101310  in order to mitigate malicious (or just greedy) clients.
    13111311</t>
    … …  
    13711371<x:ref>Content-Range</x:ref> = byte-content-range-spec / other-content-range-spec
    13721372
    1373 <x:ref>HTTP-date</x:ref> = &lt;HTTP-date, defined in [Part2], Section 8.1.1.1&gt;
     1373<x:ref>HTTP-date</x:ref> = &lt;HTTP-date, defined in [Part2], Section 7.1.1.1&gt;
    13741374
    13751375<x:ref>If-Range</x:ref> = entity-tag / HTTP-date

  • draft-ietf-httpbis/latest/p6-cache.html

    r2049 r2052  
    452452  }
    453453  @bottom-center {
    454        content: "Expires June 14, 2013";
     454       content: "Expires June 18, 2013";
    455455  }
    456456  @bottom-right {
    … …  
    498498      <meta name="dct.creator" content="Reschke, J. F.">
    499499      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p6-cache-latest">
    500       <meta name="dct.issued" scheme="ISO8601" content="2012-12-11">
     500      <meta name="dct.issued" scheme="ISO8601" content="2012-12-15">
    501501      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    502502      <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.">
    … …  
    524524            </tr>
    525525            <tr>
    526                <td class="left">Expires: June 14, 2013</td>
     526               <td class="left">Expires: June 18, 2013</td>
    527527               <td class="right">J. Reschke, Editor</td>
    528528            </tr>
    … …  
    533533            <tr>
    534534               <td class="left"></td>
    535                <td class="right">December 11, 2012</td>
     535               <td class="right">December 15, 2012</td>
    536536            </tr>
    537537         </tbody>
    … …  
    559559         in progress”.
    560560      </p>
    561       <p>This Internet-Draft will expire on June 14, 2013.</p>
     561      <p>This Internet-Draft will expire on June 18, 2013.</p>
    562562      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    563563      <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
    … …  
    727727      </p>
    728728      <ul class="empty">
    729          <li>The time at which the origin server intends that a representation no longer be returned by 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>
    730730      </ul>
    731731      <p id="rfc.section.1.2.p.7"> <span id="rfc.iref.h.1"></span>  <dfn>heuristic expiration time</dfn> 
    … …  
    859859      </p>
    860860      <h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a>&nbsp;<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> return a 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:
    862862      </p>
    863863      <ul>
    … …  
    886886      <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&nbsp;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&nbsp;4.1.3</a>.
    887887      </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 request
     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 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
    889889         and having received a corresponding response.
    890890      </p>
    … …  
    940940      <h3 id="rfc.section.4.1.2"><a href="#rfc.section.4.1.2">4.1.2</a>&nbsp;<a id="heuristic.freshness" href="#heuristic.freshness">Calculating Heuristic Freshness</a></h3>
    941941      <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 (Partial
     942         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
    943943            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
    944944            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.
    … …  
    973973      <ul class="empty">
    974974         <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.
    976976         </li>
    977977      </ul>
    … …  
    10331033         is not fresh according to the calculations in <a href="#expiration.model" title="Freshness Model">Section&nbsp;4.1</a>.
    10341034      </p>
    1035       <p id="rfc.section.4.1.4.p.2">A cache <em class="bcp14">MUST NOT</em> return a stale response if it is prohibited by an explicit in-protocol directive (e.g., by a "no-store" or "no-cache" cache
     1035      <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
    10361036         directive, a "must-revalidate" cache-response-directive, or an applicable "s-maxage" or "proxy-revalidate" cache-response-directive;
    10371037         see <a href="#cache-response-directive" title="Response Cache-Control Directives">Section&nbsp;7.2.2</a>).
    10381038      </p>
    1039       <p id="rfc.section.4.1.4.p.3">A cache <em class="bcp14">MUST NOT</em> return stale 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)
    10401040         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&nbsp;7.2.1</a>).
    10411041      </p>
    … …  
    10661066         </li>
    10671067         <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 return a previously stored response (see <a href="#serving.stale.responses" title="Serving Stale Responses">Section&nbsp;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&nbsp;4.1.4</a>).
    10691069         </li>
    10701070      </ul>
    … …  
    10961096      </ul>
    10971097      <h2 id="rfc.section.4.3"><a href="#rfc.section.4.3">4.3</a>&nbsp;<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 original
     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 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
    10991099         request (i.e., that associated with the stored response), and the presented request.
    11001100      </p>
    … …  
    11551155      </ul>
    11561156      <h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a>&nbsp;<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 them
     1157      <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
    11581158         to keep their contents up-to-date.
    11591159      </p>
    … …  
    11651165      </p>
    11661166      <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 returned in response to a subsequent
     1167         or will mark these as "invalid" and in need of a mandatory validation before they can be sent in response to a subsequent
    11681168         request.
    11691169      </p>
    … …  
    13071307      </ul>
    13081308      <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 return
     1309         prevent a cache from using it to satisfy a request without contacting it, even by caches that have been configured to send
    13101310         stale responses.
    13111311      </p>
    … …  
    14231423         that time.
    14241424      </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.
    14261426      </p>
    14271427      <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>
    … …  
    15101510         </li>
    15111511         <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.
    15131513         </li>
    15141514      </ul>
    … …  
    15241524      <div id="rfc.iref.52"></div>
    15251525      <h3 id="rfc.section.7.5.1"><a href="#rfc.section.7.5.1">7.5.1</a>&nbsp;<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 returned response 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.
    15271527      </p>
    15281528      <div id="rfc.iref.52"></div>
    15291529      <h3 id="rfc.section.7.5.2"><a href="#rfc.section.7.5.2">7.5.2</a>&nbsp;<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 reach
     1530      <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
    15311531         the server.
    15321532      </p>
    … …  
    19551955  <a href="#imported.abnf" class="smpl">uri-host</a>      = &lt;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>&gt;
    19561956</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>     = &lt;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>&gt;
     1957      <div id="rfc.figure.u.15"></div><pre class="inline">  <a href="#imported.abnf" class="smpl">HTTP-date</a>     = &lt;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>&gt;
    19581958</pre><h1 id="rfc.section.C"><a href="#rfc.section.C">C.</a>&nbsp;<a id="collected.abnf" href="#collected.abnf">Collected ABNF</a></h1>
    19591959      <div id="rfc.figure.u.16"></div> <pre class="inline"><a href="#header.age" class="smpl">Age</a> = delta-seconds
    … …  
    19641964<a href="#header.expires" class="smpl">Expires</a> = HTTP-date
    19651965
    1966 <a href="#imported.abnf" class="smpl">HTTP-date</a> = &lt;HTTP-date, defined in [Part2], Section 8.1.1.1&gt;
     1966<a href="#imported.abnf" class="smpl">HTTP-date</a> = &lt;HTTP-date, defined in [Part2], Section 7.1.1.1&gt;
    19671967
    19681968<a href="#imported.abnf" class="smpl">OWS</a> = &lt;OWS, defined in [Part1], Section 3.2.3&gt;
    … …  
    21422142                  </li>
    21432143                  <li><em>Part2</em>&nbsp;&nbsp;<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>&nbsp;&nbsp;<a href="#rfc.xref.Part2.2">4</a>, <a href="#rfc.xref.Part2.6">6</a></li>
    2145                         <li><em>Section 7</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.3">4.1.2</a></li>
    2146                         <li><em>Section 8.1.1.1</em>&nbsp;&nbsp;<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>&nbsp;&nbsp;<a href="#rfc.xref.Part2.4">4.1.3</a></li>
    2148                         <li><em>Section 8.2.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.5">4.3</a></li>
     2144                        <li><em>Section 4.2.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.2">4</a>, <a href="#rfc.xref.Part2.6">6</a></li>
     2145                        <li><em>Section 6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.3">4.1.2</a></li>
     2146                        <li><em>Section 7.1.1.1</em>&nbsp;&nbsp;<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>&nbsp;&nbsp;<a href="#rfc.xref.Part2.4">4.1.3</a></li>
     2148                        <li><em>Section 7.2.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.5">4.3</a></li>
    21492149                     </ul>
    21502150                  </li>

  • draft-ietf-httpbis/latest/p6-cache.xml

    r2046 r2052  
    211211   <list>
    212212      <t>The time at which the origin server intends that a representation
    213       no longer be returned by a cache without further validation.</t>
     213      no longer be sent by a cache without further validation.</t>
    214214   </list>
    215215</t>
    … …  
    471471   title="Constructing Responses from Caches">
    472472<t>
    473    For a presented request, a cache &MUST-NOT; return a stored response,
     473   For a presented request, a cache &MUST-NOT; send a stored response,
    474474   unless:
    475475   <list style="symbols">
    … …  
    796796</t>
    797797<t>
    798    A cache &MUST-NOT; return a stale response if it is prohibited by an
     798   A cache &MUST-NOT; send a stale response if it is prohibited by an
    799799   explicit in-protocol directive (e.g., by a "no-store" or "no-cache" cache
    800800   directive, a "must-revalidate" cache-response-directive, or an applicable
    … …  
    803803</t>
    804804<t>
    805    A cache &MUST-NOT; return stale responses unless it is disconnected
     805   A cache &MUST-NOT; send stale responses unless it is disconnected
    806806   (i.e., it cannot contact the origin server or otherwise find a forward
    807807   path) or doing so is explicitly allowed (e.g., by the max-stale request
    … …  
    872872         response while attempting to validate a response, it can either
    873873         forward this response to the requesting client, or act as if the
    874          server failed to respond. In the latter case, it can return a
     874         server failed to respond. In the latter case, it can send a
    875875         previously stored response (see <xref
    876876         target="serving.stale.responses" />).
    … …  
    10731073   the cache will either remove all stored responses related to the effective
    10741074   request URI, or will mark these as "invalid" and in need of a mandatory
    1075    validation before they can be returned in response to a subsequent request.
     1075   validation before they can be sent in response to a subsequent request.
    10761076</t>
    10771077<t>
    … …  
    13621362   the origin server. This allows an origin server to prevent a cache from
    13631363   using it to satisfy a request without contacting it, even by caches that
    1364    have been configured to return stale responses.
     1364   have been configured to send stale responses.
    13651365</t>
    13661366<t>
    … …  
    17571757      rectified by a validation (for example, a lossy compression of the
    17581758      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>
    17601760   </list>
    17611761</t>
    … …  
    17831783  <iref primary="true" item="110 Response is Stale (warn code)" x:for-anchor=""/>
    17841784<t>
    1785    A cache &SHOULD; include this whenever the returned response is stale.
     1785   A cache &SHOULD; include this whenever the sent response is stale.
    17861786</t>
    17871787</section>
    … …  
    17901790  <iref primary="true" item="111 Revalidation Failed (warn code)" x:for-anchor=""/>
    17911791<t>
    1792    A cache &SHOULD; include this when returning a stale response because an
     1792   A cache &SHOULD; include this when sending a stale response because an
    17931793   attempt to validate the response failed, due to an inability to reach
    17941794   the server.
    … …  
    25592559<x:ref>Expires</x:ref> = HTTP-date
    25602560
    2561 <x:ref>HTTP-date</x:ref> = &lt;HTTP-date, defined in [Part2], Section 8.1.1.1&gt;
     2561<x:ref>HTTP-date</x:ref> = &lt;HTTP-date, defined in [Part2], Section 7.1.1.1&gt;
    25622562
    25632563<x:ref>OWS</x:ref> = &lt;OWS, defined in [Part1], Section 3.2.3&gt;

  • draft-ietf-httpbis/latest/p7-auth.html

    r2049 r2052  
    449449  }
    450450  @bottom-center {
    451        content: "Expires June 14, 2013";
     451       content: "Expires June 18, 2013";
    452452  }
    453453  @bottom-right {
    … …  
    489489      <meta name="dct.creator" content="Reschke, J. F.">
    490490      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p7-auth-latest">
    491       <meta name="dct.issued" scheme="ISO8601" content="2012-12-11">
     491      <meta name="dct.issued" scheme="ISO8601" content="2012-12-15">
    492492      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    493493      <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.">
    … …  
    517517            <tr>
    518518               <td class="left">Intended status: Standards Track</td>
    519                <td class="right">December 11, 2012</td>
     519               <td class="right">December 15, 2012</td>
    520520            </tr>
    521521            <tr>
    522                <td class="left">Expires: June 14, 2013</td>
     522               <td class="left">Expires: June 18, 2013</td>
    523523               <td class="right"></td>
    524524            </tr>
    … …  
    546546         in progress”.
    547547      </p>
    548       <p>This Internet-Draft will expire on June 14, 2013.</p>
     548      <p>This Internet-Draft will expire on June 18, 2013.</p>
    549549      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    550550      <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
    … …  
    679679      <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> ) ]
    680680</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> return 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.
     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.
    682682      </p>
    683683      <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> return 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 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>).
    687687      </p>
    688688      <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
    … …  
    785785      <div id="rfc.iref.8"></div>
    786786      <h2 id="rfc.section.3.2"><a href="#rfc.section.3.2">3.2</a>&nbsp;<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> return 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&nbsp;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&nbsp;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&nbsp;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&nbsp;4.3</a>).
    788788      </p>
    789789      <h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a>&nbsp;<a id="header.field.definitions" href="#header.field.definitions">Header Field Definitions</a></h1>
    … …  
    11761176                  </li>
    11771177                  <li><em>Part2</em>&nbsp;&nbsp;<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>&nbsp;&nbsp;<a href="#rfc.xref.Part2.1">2.1</a></li>
     1178                        <li><em>Section 6.5.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.1">2.1</a></li>
    11791179                     </ul>
    11801180                  </li>

  • draft-ietf-httpbis/latest/p7-auth.xml

    r2046 r2052  
    242242   invalid credentials (e.g., a bad password) or partial credentials (e.g.,
    243243   when the authentication scheme requires more than one round trip), an origin
    244    server &SHOULD; return a <x:ref>401 (Unauthorized)</x:ref> response. Such
     244   server &SHOULD; send a <x:ref>401 (Unauthorized)</x:ref> response. Such
    245245   responses &MUST; include a <x:ref>WWW-Authenticate</x:ref> header field
    246246   containing at least one (possibly new) challenge applicable to the
    … …  
    250250   Likewise, upon a request that requires authentication by proxies that omit
    251251   credentials or contain invalid or partial credentials, a proxy &SHOULD;
    252    return a <x:ref>407 (Proxy Authentication Required)</x:ref> response. Such responses
     252   send a <x:ref>407 (Proxy Authentication Required)</x:ref> response. Such responses
    253253   &MUST; include a <x:ref>Proxy-Authenticate</x:ref> header field containing a (possibly
    254254   new) challenge applicable to the proxy.
    … …  
    446446   This code is similar to <x:ref>401 (Unauthorized)</x:ref>, but indicates that the
    447447   client ought to first authenticate itself with the proxy. The proxy &MUST;
    448    return a <x:ref>Proxy-Authenticate</x:ref> header field (<xref target="header.proxy-authenticate"/>) containing a
     448   send a <x:ref>Proxy-Authenticate</x:ref> header field (<xref target="header.proxy-authenticate"/>) containing a
    449449   challenge applicable to the proxy for the target resource. The
    450450   client &MAY; repeat the request with a suitable <x:ref>Proxy-Authorization</x:ref>
Note: See TracChangeset for help on using the changeset viewer.