Changeset 1715


Ignore:
Timestamp:
Jul 4, 2012, 12:54:55 PM (7 years ago)
Author:
julian.reschke@…
Message:

Work-in-progress: hyperlink status codes definitions (2xx range)

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

Legend:

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

    r1714 r1715  
    13771377         status code (<a href="#status-code">Paragraph&nbsp;3</a>). Responses to the HEAD request method never include a message body because the associated response header fields (e.g.,
    13781378         Transfer-Encoding, Content-Length, etc.) only indicate what their values would have been if the request method had been GET.
    1379          Successful (2xx) responses to CONNECT switch to tunnel mode instead of having a message body. All 1xx (Informational), 204
    1380          (No Content), 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. (See <a href="p2-semantics.html#status.codes" title="Status Codes">Section 4</a> of <a href="#Part2" id="rfc.xref.Part2.9"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a> and <a href="p4-conditional.html#status.304" title="304 Not Modified">Section 4.1</a> of <a href="#Part4" id="rfc.xref.Part4.1"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>.)
     1379         Successful (2xx) responses to CONNECT switch to tunnel mode instead of having a message body. All 1xx (Informational), <a href="p2-semantics.html#status.204" class="smpl">204 (No Content)</a>, and <a href="p4-conditional.html#status.304" class="smpl">304
     1380           (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. (See <a href="p2-semantics.html#status.codes" title="Status Codes">Section 4</a> of <a href="#Part2" id="rfc.xref.Part2.9"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a> and <a href="p4-conditional.html#status.304" title="304 Not Modified">Section 4.1</a> of <a href="#Part4" id="rfc.xref.Part4.1"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>.)
    13811381      </p>
    13821382      <div id="rfc.iref.t.4"></div>
     
    14291429</pre><p id="rfc.section.3.3.2.p.5">In the case of a response to a HEAD request, Content-Length indicates the size of the payload body (without any potential
    14301430         transfer-coding) that would have been sent had the request been a GET. In the case of a <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a> response (<a href="p4-conditional.html#status.304" title="304 Not Modified">Section 4.1</a> of <a href="#Part4" id="rfc.xref.Part4.3"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>) to a GET request, Content-Length indicates the size of the payload body (without any potential transfer-coding) that would
    1431          have been sent in a 200 (OK) response.
     1431         have been sent in a <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> response.
    14321432      </p>
    14331433      <p id="rfc.section.3.3.2.p.6">HTTP's use of Content-Length is significantly different from how it is used in MIME, where it is an optional field used only
  • draft-ietf-httpbis/latest/p1-messaging.xml

    r1714 r1715  
    14841484   Successful (2xx) responses to CONNECT switch to tunnel mode instead of
    14851485   having a message body.
    1486    All 1xx (Informational), 204 (No Content), and <x:ref>304 (Not Modified)</x:ref>
    1487    responses &MUST-NOT; include a message body.
     1486   All 1xx (Informational), <x:ref>204 (No Content)</x:ref>, and <x:ref>304
     1487   (Not Modified)</x:ref> responses &MUST-NOT; include a message body.
    14881488   All other responses do include a message body, although the body
    14891489   &MAY; be of zero length. (See &status-codes; and &status-304;.)
     
    16061606   In the case of a <x:ref>304 (Not Modified)</x:ref> response (&status-304;)
    16071607   to a GET request, Content-Length indicates the size of the payload body (without
    1608    any potential transfer-coding) that would have been sent in a 200 (OK)
     1608   any potential transfer-coding) that would have been sent in a <x:ref>200 (OK)</x:ref>
    16091609   response.
    16101610</t>
     
    41094109  <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p2-semantics-&ID-VERSION;"/>
    41104110  <x:source href="p2-semantics.xml" basename="p2-semantics">
     4111    <x:defines>200 (OK)</x:defines>
     4112    <x:defines>204 (No Content)</x:defines>
    41114113    <x:defines>301 (Moved Permanently)</x:defines>
    41124114    <x:defines>400 (Bad Request)</x:defines>
  • draft-ietf-httpbis/latest/p2-semantics.html

    r1714 r1715  
    10211021         URI.
    10221022      </p>
    1023       <p id="rfc.section.2.3.4.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
    1024          200 (OK) or 204 (No Content) is the appropriate response status code, depending on whether or not the response includes a
    1025          representation that describes the result.
    1026       </p>
    1027       <p id="rfc.section.2.3.4.p.4">If a resource has been created on the origin server, the response <em class="bcp14">SHOULD</em> be 201 (Created) and contain a representation which describes the status of the request and refers to the new resource, and
    1028          a Location header field (see <a href="#header.location" id="rfc.xref.header.location.1" title="Location">Section&nbsp;9.13</a>).
     1023      <p id="rfc.section.2.3.4.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
     1024         the result.
     1025      </p>
     1026      <p id="rfc.section.2.3.4.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 Location header
     1027         field (see <a href="#header.location" id="rfc.xref.header.location.1" title="Location">Section&nbsp;9.13</a>).
    10291028      </p>
    10301029      <p id="rfc.section.2.3.4.p.5">Responses to POST requests are only cacheable when they include explicit freshness information (see <a href="p6-cache.html#calculating.freshness.lifetime" title="Calculating Freshness Lifetime">Section 2.3.1</a> of <a href="#Part6" id="rfc.xref.Part6.4"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>). A cached POST response with a Content-Location header field (see <a href="#header.content-location" id="rfc.xref.header.content-location.1" title="Content-Location">Section&nbsp;9.8</a>) whose value is the effective Request URI <em class="bcp14">MAY</em> be used to satisfy subsequent GET and HEAD requests.
     
    10371036      <p id="rfc.section.2.3.5.p.1">The PUT method requests that the state of the target resource be created or replaced with the state defined by the representation
    10381037         enclosed in the request message payload. A successful PUT of a given representation would suggest that a subsequent GET on
    1039          that same target resource will result in an equivalent representation being returned in a 200 (OK) response. However, there
    1040          is no guarantee that such a state change will be observable, since the target resource might be acted upon by other user agents
    1041          in parallel, or might be subject to dynamic processing by the origin server, before any subsequent GET is received. A successful
    1042          response only implies that the user agent's intent was achieved at the time of its processing by the origin server.
    1043       </p>
    1044       <p id="rfc.section.2.3.5.p.2">If the target resource does not have a current representation and the PUT successfully creates one, then the origin server <em class="bcp14">MUST</em> inform the user agent by sending a 201 (Created) response. If the target resource does have a current representation and that
    1045          representation is successfully modified in accordance with the state of the enclosed representation, then either a 200 (OK)
    1046          or 204 (No Content) response <em class="bcp14">SHOULD</em> be sent to indicate successful completion of the request.
     1038         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
     1039         upon by other user agents in parallel, or might be subject to dynamic processing by the origin server, before any subsequent
     1040         GET is received. A successful response only implies that the user agent's intent was achieved at the time of its processing
     1041         by the origin server.
     1042      </p>
     1043      <p id="rfc.section.2.3.5.p.2">If the target resource does not have a current representation and the PUT successfully creates one, then the origin server <em class="bcp14">MUST</em> inform the user agent by sending a <a href="#status.201" class="smpl">201 (Created)</a> response. If the target resource does have a current representation and that representation is successfully modified in accordance
     1044         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.
    10471045      </p>
    10481046      <p id="rfc.section.2.3.5.p.3">Unrecognized header fields <em class="bcp14">SHOULD</em> be ignored (i.e., not saved as part of the resource state).
     
    11001098         location.
    11011099      </p>
    1102       <p id="rfc.section.2.3.6.p.2">A successful response <em class="bcp14">SHOULD</em> be 200 (OK) if the response includes an representation describing the status, 202 (Accepted) if the action has not yet been
    1103          enacted, or 204 (No Content) if the action has been enacted but the response does not include a representation.
     1100      <p id="rfc.section.2.3.6.p.2">A successful response <em class="bcp14">SHOULD</em> be <a href="#status.200" class="smpl">200 (OK)</a> if the response includes an 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.
    11041101      </p>
    11051102      <p id="rfc.section.2.3.6.p.3">Bodies on DELETE requests have no defined semantics. Note that sending a body on a DELETE request might cause some existing
     
    11121109      <div id="rfc.iref.t.1"></div>
    11131110      <div id="rfc.iref.m.7"></div>
    1114       <p id="rfc.section.2.3.7.p.1">The TRACE method requests a remote, application-layer loop-back of the request message. The final recipient of the request <em class="bcp14">SHOULD</em> reflect the message received back to the client as the message body of a 200 (OK) response. The final recipient is either
    1115          the origin server or the first proxy to receive a Max-Forwards value of zero (0) in the request (see <a href="#header.max-forwards" id="rfc.xref.header.max-forwards.2" title="Max-Forwards">Section&nbsp;9.14</a>). A TRACE request <em class="bcp14">MUST NOT</em> include a message body.
     1111      <p id="rfc.section.2.3.7.p.1">The TRACE method requests a remote, application-layer loop-back of the request message. The final recipient of the request <em class="bcp14">SHOULD</em> reflect the message received back to the client as the message body of a <a href="#status.200" class="smpl">200 (OK)</a> response. The final recipient is either the origin server or the first proxy to receive a Max-Forwards value of zero (0) in
     1112         the request (see <a href="#header.max-forwards" id="rfc.xref.header.max-forwards.2" title="Max-Forwards">Section&nbsp;9.14</a>). A TRACE request <em class="bcp14">MUST NOT</em> include a message body.
    11161113      </p>
    11171114      <p id="rfc.section.2.3.7.p.2">TRACE allows the client to see what is being received at the other end of the request chain and use that data for testing
     
    17041701         can be omitted (e.g., in the case of a response to a PUT request).
    17051702      </p>
    1706       <p id="rfc.section.4.4.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 202 (Accepted) response instead.
     1703      <p id="rfc.section.4.4.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 href="#status.202" class="smpl">202 (Accepted)</a> response instead.
    17071704      </p>
    17081705      <p id="rfc.section.4.4.2.p.4">A 201 response <em class="bcp14">MAY</em> contain an ETag response header field indicating the current value of the entity-tag for the representation of the resource
     
    17261723      <p id="rfc.section.4.4.4.p.1">The representation in the response has been transformed or otherwise modified by a transforming proxy (<a href="p1-messaging.html#intermediaries" title="Intermediaries">Section 2.3</a> of <a href="#Part1" id="rfc.xref.Part1.34"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). Note that the behavior of transforming intermediaries is controlled by the no-transform Cache-Control directive (<a href="p6-cache.html#header.cache-control" title="Cache-Control">Section 3.2</a> of <a href="#Part6" id="rfc.xref.Part6.12"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>).
    17271724      </p>
    1728       <p id="rfc.section.4.4.4.p.2">This status code is only appropriate when the response status code would have been 200 (OK) otherwise. When the status code
    1729          before transformation would have been different, the 214 Transformation Applied warn-code (<a href="p6-cache.html#header.warning" title="Warning">Section 3.6</a> of <a href="#Part6" id="rfc.xref.Part6.13"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) is appropriate.
     1725      <p id="rfc.section.4.4.4.p.2">This status code is only appropriate when the response status code would have been <a href="#status.200" class="smpl">200 (OK)</a> otherwise. When the status code before transformation would have been different, the 214 Transformation Applied warn-code
     1726         (<a href="p6-cache.html#header.warning" title="Warning">Section 3.6</a> of <a href="#Part6" id="rfc.xref.Part6.13"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) is appropriate.
    17301727      </p>
    17311728      <p id="rfc.section.4.4.4.p.3">Caches <em class="bcp14">MAY</em> use a heuristic (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 2.3.1.1</a> of <a href="#Part6" id="rfc.xref.Part6.14"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) to determine freshness for 203 responses.
     
    23562353         identified by the effective request URI). The precise semantics of a representation are determined by the type of message
    23572354         (request or response), the request method, the response status code, and the representation metadata. For example, the above
    2358          semantic is true for the representation in any 200 (OK) response to GET and for the representation in any PUT request. A 200
    2359          response to PUT, in contrast, contains either a representation that describes the successful action or a representation of
    2360          the target resource, with the latter indicated by a Content-Location header field with the same value as the effective request
    2361          URI. Likewise, response messages with an error status code usually contain a representation that describes the error and what
    2362          next steps are suggested for resolving it.
     2355         semantic is true for the representation in any <a href="#status.200" class="smpl">200 (OK)</a> response to GET and for the representation in any PUT request. A 200 response to PUT, in contrast, contains either a representation
     2356         that describes the successful action or a representation of the target resource, with the latter indicated by a Content-Location
     2357         header field with the same value as the effective request URI. Likewise, response messages with an error status code usually
     2358         contain a representation that describes the error and what next steps are suggested for resolving it.
    23632359      </p>
    23642360      <p id="rfc.section.7.p.3">Request and Response messages <em class="bcp14">MAY</em> transfer a representation if not otherwise restricted by the request method or response status code. A representation consists
     
    29722968      </p>
    29732969      <div id="rfc.figure.u.50"></div><pre class="inline"><span id="rfc.iref.g.52"></span>  <a href="#header.location" class="smpl">Location</a> = <a href="#abnf.dependencies" class="smpl">URI-reference</a>
    2974 </pre><p id="rfc.section.9.13.p.3">For 201 (Created) responses, the Location is the URI of the new resource which was created by the request. For 3xx responses,
    2975          the location <em class="bcp14">SHOULD</em> indicate the server's preferred URI for automatic redirection to the resource.
     2970</pre><p id="rfc.section.9.13.p.3">For <a href="#status.201" class="smpl">201 (Created)</a> responses, the Location is the URI of the new resource which was created by the request. For 3xx responses, the location <em class="bcp14">SHOULD</em> indicate the server's preferred URI for automatic redirection to the resource.
    29762971      </p>
    29772972      <p id="rfc.section.9.13.p.4">The field value consists of a single URI-reference. When it has the form of a relative reference (<a href="#RFC3986" id="rfc.xref.RFC3986.1"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-4.2">Section 4.2</a>), the final value is computed by resolving it against the effective request URI (<a href="#RFC3986" id="rfc.xref.RFC3986.2"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-5">Section 5</a>). If the original URI, as navigated to by the user agent, did contain a fragment identifier, and the final value does not,
     
    29902985      </div>
    29912986      <p id="rfc.section.9.13.p.8">There are circumstances in which a fragment identifier in a Location URI would not be appropriate. For instance, when it appears
    2992          in a 201 Created response, where the Location header field specifies the URI for the entire created resource.
     2987         in a <a href="#status.201" class="smpl">201
     2988            (Created)</a> response, where the Location header field specifies the URI for the entire created resource.
    29932989      </p>
    29942990      <div class="note" id="rfc.section.9.13.p.9">
     
    39483944      <p id="rfc.section.C.p.4">This document takes over the Status Code Registry, previously defined in <a href="http://tools.ietf.org/html/rfc2817#section-7.1">Section 7.1</a> of <a href="#RFC2817" id="rfc.xref.RFC2817.3"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a>. (<a href="#status.code.registry" title="Status Code Registry">Section&nbsp;4.2</a>)
    39493945      </p>
    3950       <p id="rfc.section.C.p.5">Broadened the definition of 203 (Non-Authoritative Information) to include cases of payload transformations as well. (<a href="#status.203" id="rfc.xref.status.203.3" title="203 Non-Authoritative Information">Section&nbsp;4.4.4</a>)
     3946      <p id="rfc.section.C.p.5">Broadened the definition of <a href="#status.203" class="smpl">203 (Non-Authoritative Information)</a> to include cases of payload transformations as well. (<a href="#status.203" id="rfc.xref.status.203.3" title="203 Non-Authoritative Information">Section&nbsp;4.4.4</a>)
    39513947      </p>
    39523948      <p id="rfc.section.C.p.6">Status codes 301, 302, and 307: removed the normative requirements on both response payloads and user interaction. (<a href="#status.3xx" title="Redirection 3xx">Section&nbsp;4.5</a>)
     
    39563952         the method from POST to GET for status codes 301 and 302. (Sections <a href="#status.301" id="rfc.xref.status.301.3" title="301 Moved Permanently">4.5.2</a>, <a href="#status.302" id="rfc.xref.status.302.3" title="302 Found">4.5.3</a> and <a href="#status.307" id="rfc.xref.status.307.3" title="307 Temporary Redirect">4.5.7</a>)
    39573953      </p>
    3958       <p id="rfc.section.C.p.8">Deprecate 305 Use Proxy status code, because user agents did not implement it. It used to indicate that the target resource
    3959          needs to be accessed through the proxy given by the Location field. The Location field gave the URI of the proxy. The recipient
    3960          was expected to repeat this single request via the proxy. (<a href="#status.305" id="rfc.xref.status.305.3" title="305 Use Proxy">Section&nbsp;4.5.5</a>)
    3961       </p>
    3962       <p id="rfc.section.C.p.9">Define status 426 (Upgrade Required) (this was incorporated from <a href="#RFC2817" id="rfc.xref.RFC2817.4"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a>). (<a href="#status.426" id="rfc.xref.status.426.3" title="426 Upgrade Required">Section&nbsp;4.6.15</a>)
     3954      <p id="rfc.section.C.p.8">Deprecate <a href="#status.305" class="smpl">305 (Use Proxy)</a> status code, because user agents did not implement it. It used to indicate that the target resource needs to be accessed through
     3955         the proxy given by the Location field. The Location field gave the URI of the proxy. The recipient was expected to repeat
     3956         this single request via the proxy. (<a href="#status.305" id="rfc.xref.status.305.3" title="305 Use Proxy">Section&nbsp;4.5.5</a>)
     3957      </p>
     3958      <p id="rfc.section.C.p.9">Define status <a href="#status.426" class="smpl">426 (Upgrade Required)</a> (this was incorporated from <a href="#RFC2817" id="rfc.xref.RFC2817.4"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a>). (<a href="#status.426" id="rfc.xref.status.426.3" title="426 Upgrade Required">Section&nbsp;4.6.15</a>)
    39633959      </p>
    39643960      <p id="rfc.section.C.p.10">Change ABNF productions for header fields to only define the field value. (<a href="#header.field.definitions" title="Header Field Definitions">Section&nbsp;9</a>)
  • draft-ietf-httpbis/latest/p2-semantics.xml

    r1714 r1715  
    665665</t>
    666666<t>
    667    The action performed by the POST method might not result in a
    668    resource that can be identified by a URI. In this case, either 200
    669    (OK) or 204 (No Content) is the appropriate response status code,
    670    depending on whether or not the response includes a representation that
    671    describes the result.
     667   The action performed by the POST method might not result in a resource that
     668   can be identified by a URI. In this case, either <x:ref>200 (OK)</x:ref> or
     669   <x:ref>204 (No Content)</x:ref> is the appropriate response status
     670   code, depending on whether or not the response includes a representation
     671   that describes the result.
    672672</t>
    673673<t>
    674674   If a resource has been created on the origin server, the response
    675    &SHOULD; be 201 (Created) and contain a representation which describes the
    676    status of the request and refers to the new resource, and a Location
    677    header field (see <xref target="header.location"/>).
     675   &SHOULD; be <x:ref>201 (Created)</x:ref> and contain a representation which
     676   describes the status of the request and refers to the new resource, and a
     677   Location header field (see <xref target="header.location"/>).
    678678</t>
    679679<t>
     
    700700   representation would suggest that a subsequent GET on that same target
    701701   resource will result in an equivalent representation being returned in
    702    a 200 (OK) response.  However, there is no guarantee that such a state
    703    change will be observable, since the target resource might be acted
    704    upon by other user agents in parallel, or might be subject to dynamic
     702   a <x:ref>200 (OK)</x:ref> response.  However, there is no guarantee that
     703   such a state change will be observable, since the target resource might be
     704   acted upon by other user agents in parallel, or might be subject to dynamic
    705705   processing by the origin server, before any subsequent GET is received.
    706706   A successful response only implies that the user agent's intent was
     
    710710   If the target resource does not have a current representation and
    711711   the PUT successfully creates one, then the origin server &MUST; inform
    712    the user agent by sending a 201 (Created) response.  If the target
    713    resource does have a current representation and that representation is
     712   the user agent by sending a <x:ref>201 (Created)</x:ref> response.  If the
     713   target resource does have a current representation and that representation is
    714714   successfully modified in accordance with the state of the enclosed
    715    representation, then either a 200 (OK) or 204 (No Content) response
    716    &SHOULD; be sent to indicate successful completion of the request.
     715   representation, then either a <x:ref>200 (OK)</x:ref> or <x:ref>204 (No Content)</x:ref>
     716   response &SHOULD; be sent to indicate successful completion of the request.
    717717</t>
    718718<t>
     
    828828</t>
    829829<t>
    830    A successful response &SHOULD; be 200 (OK) if the response includes an
    831    representation describing the status, 202 (Accepted) if the action has not
    832    yet been enacted, or 204 (No Content) if the action has been enacted
    833    but the response does not include a representation.
     830   A successful response &SHOULD; be <x:ref>200 (OK)</x:ref> if the response
     831   includes an representation describing the status, <x:ref>202 (Accepted)</x:ref>
     832   if the action has not yet been enacted, or <x:ref>204 (No Content)</x:ref> if
     833   the action has been enacted but the response does not include a representation.
    834834</t>
    835835<t>
     
    855855   The TRACE method requests a remote, application-layer loop-back
    856856   of the request message. The final recipient of the request
    857    &SHOULD; reflect the message received back to the client as the
    858    message body of a 200 (OK) response. The final recipient is either the
     857   &SHOULD; reflect the message received back to the client as the message body
     858   of a <x:ref>200 (OK)</x:ref> response. The final recipient is either the
    859859   origin server or the first proxy to receive a Max-Forwards
    860860   value of zero (0) in the request (see <xref target="header.max-forwards"/>).
     
    13491349  <iref primary="true" item="200 OK (status code)" x:for-anchor=""/>
    13501350  <iref primary="true" item="Status Codes" subitem="200 OK" x:for-anchor=""/>
     1351  <x:anchor-alias value="200 (OK)"/>
    13511352<t>
    13521353   The request has succeeded. The payload returned with the response
     
    13771378  <iref primary="true" item="201 Created (status code)" x:for-anchor=""/>
    13781379  <iref primary="true" item="Status Codes" subitem="201 Created" x:for-anchor=""/>
     1380  <x:anchor-alias value="201 (Created)"/>
    13791381<t>
    13801382   The request has been fulfilled and has resulted in one or more new resources
     
    13911393   The origin server &MUST; create the resource(s) before returning the 201 status
    13921394   code. If the action cannot be carried out immediately, the server &SHOULD;
    1393    respond with 202 (Accepted) response instead.
     1395   respond with <x:ref>202 (Accepted)</x:ref> response instead.
    13941396</t>
    13951397<t>
     
    14041406  <iref primary="true" item="202 Accepted (status code)" x:for-anchor=""/>
    14051407  <iref primary="true" item="Status Codes" subitem="202 Accepted" x:for-anchor=""/>
     1408  <x:anchor-alias value="202 (Accepted)"/>
    14061409<t>
    14071410   The request has been accepted for processing, but the processing has
     
    14261429  <iref primary="true" item="203 Non-Authoritative Information (status code)" x:for-anchor=""/>
    14271430  <iref primary="true" item="Status Codes" subitem="203 Non-Authoritative Information" x:for-anchor=""/>
     1431  <x:anchor-alias value="203 (Non-Authoritative Information)"/>
    14281432<t>
    14291433   The representation in the response has been transformed or otherwise
     
    14341438<t>
    14351439   This status code is only appropriate when the response status code would
    1436    have been 200 (OK) otherwise. When the status code before transformation
    1437    would have been different, the 214 Transformation Applied warn-code
    1438    (&header-warning;) is appropriate.
     1440   have been <x:ref>200 (OK)</x:ref> otherwise. When the status code before
     1441   transformation would have been different, the 214 Transformation Applied
     1442   warn-code (&header-warning;) is appropriate.
    14391443</t>
    14401444<t>
     
    14471451  <iref primary="true" item="204 No Content (status code)" x:for-anchor=""/>
    14481452  <iref primary="true" item="Status Codes" subitem="204 No Content" x:for-anchor=""/>
     1453  <x:anchor-alias value="204 (No Content)"/>
    14491454<t>
    14501455   The 204 (No Content) status code indicates that the server has
     
    17171722  <iref primary="true" item="305 Use Proxy (status code)" x:for-anchor=""/>
    17181723  <iref primary="true" item="Status Codes" subitem="305 Use Proxy" x:for-anchor=""/>
     1724  <x:anchor-alias value="305 (Use Proxy)"/>
    17191725<t>
    17201726   The 305 status code was defined in a previous version of this specification
     
    26232629   by the effective request URI).  The precise semantics of a representation
    26242630   are determined by the type of message (request or response), the request
    2625    method, the response status code, and the representation metadata.
    2626    For example, the above semantic is true for the representation in any
    2627    200 (OK) response to GET and for the representation in any PUT request.
     2631   method, the response status code, and the representation metadata. For
     2632   example, the above semantic is true for the representation in any
     2633   <x:ref>200 (OK)</x:ref> response to GET and for the representation in any PUT request.
    26282634   A 200 response to PUT, in contrast, contains either a representation
    26292635   that describes the successful action or a representation of the target
     
    36883694</artwork></figure>
    36893695<t>
    3690    For 201 (Created) responses, the Location is the URI of the new resource
    3691    which was created by the request. For 3xx responses, the location &SHOULD;
    3692    indicate the server's preferred URI for automatic redirection to the
    3693    resource.
     3696   For <x:ref>201 (Created)</x:ref> responses, the Location is the URI of the
     3697   new resource which was created by the request. For 3xx responses, the
     3698   location &SHOULD; indicate the server's preferred URI for automatic
     3699   redirection to the resource.
    36943700</t>
    36953701<t>
     
    37253731<t>
    37263732   There are circumstances in which a fragment identifier in a Location URI
    3727    would not be appropriate. For instance, when it appears in a 201 Created
    3728    response, where the Location header field specifies the URI for the entire
    3729    created resource.
     3733   would not be appropriate. For instance, when it appears in a <x:ref>201
     3734   (Created)</x:ref> response, where the Location header field specifies the
     3735   URI for the entire created resource.
    37303736</t>
    37313737<x:note>
     
    54105416</t>
    54115417<t>
    5412   Broadened the definition of 203 (Non-Authoritative Information) to include
    5413   cases of payload transformations as well.
     5418  Broadened the definition of <x:ref>203 (Non-Authoritative Information)</x:ref>
     5419  to include cases of payload transformations as well.
    54145420  (<xref target="status.203"/>)
    54155421</t>
     
    54305436</t>
    54315437<t>
    5432   Deprecate 305 Use Proxy status code, because user agents did not implement it.
    5433   It used to indicate that the target resource needs to be accessed through the
    5434   proxy given by the Location field. The Location field gave the URI of the
    5435   proxy. The recipient was expected to repeat this single request via the proxy.
     5438  Deprecate <x:ref>305 (Use Proxy)</x:ref> status code, because user agents did
     5439  not implement it. It used to indicate that the target resource needs to be
     5440  accessed through the proxy given by the Location field. The Location field
     5441  gave the URI of the proxy. The recipient was expected to repeat this single
     5442  request via the proxy.
    54365443  (<xref target="status.305"/>)
    54375444</t>
    54385445<t>
    5439   Define status 426 (Upgrade Required) (this was incorporated from
    5440   <xref target="RFC2817"/>).
     5446  Define status <x:ref>426 (Upgrade Required)</x:ref> (this was incorporated
     5447  from <xref target="RFC2817"/>).
    54415448  (<xref target="status.426"/>)
    54425449</t>
  • draft-ietf-httpbis/latest/p4-conditional.html

    r1708 r1715  
    449449  }
    450450  @bottom-center {
    451        content: "Expires January 4, 2013";
     451       content: "Expires January 5, 2013";
    452452  }
    453453  @bottom-right {
     
    490490      <meta name="dct.creator" content="Reschke, J. F.">
    491491      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p4-conditional-latest">
    492       <meta name="dct.issued" scheme="ISO8601" content="2012-07-03">
     492      <meta name="dct.issued" scheme="ISO8601" content="2012-07-04">
    493493      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    494494      <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 4 of the seven-part specification that defines the protocol referred to as &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 4 defines request header fields for indicating conditional requests and the rules for constructing responses to those requests.">
     
    516516            </tr>
    517517            <tr>
    518                <td class="left">Expires: January 4, 2013</td>
     518               <td class="left">Expires: January 5, 2013</td>
    519519               <td class="right">J. Reschke, Editor</td>
    520520            </tr>
     
    525525            <tr>
    526526               <td class="left"></td>
    527                <td class="right">July 3, 2012</td>
     527               <td class="right">July 4, 2012</td>
    528528            </tr>
    529529         </tbody>
     
    555555         in progress”.
    556556      </p>
    557       <p>This Internet-Draft will expire on January 4, 2013.</p>
     557      <p>This Internet-Draft will expire on January 5, 2013.</p>
    558558      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    559559      <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
     
    692692      </p>
    693693      <p id="rfc.section.2.1.p.2">A "strong validator" is a representation metadata value that <em class="bcp14">MUST</em> be changed to a new, previously unused or guaranteed unique, value whenever a change occurs to the representation data such
    694          that a change would be observable in the payload body of a 200 response to GET. A strong validator <em class="bcp14">MAY</em> be changed for other reasons, such as when a semantically significant part of the representation metadata is changed (e.g.,
     694         that a change would be observable in the payload body of a <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> response to GET. A strong validator <em class="bcp14">MAY</em> be changed for other reasons, such as when a semantically significant part of the representation metadata is changed (e.g.,
    695695         Content-Type), but it is in the best interests of the origin server to only change the value when it is necessary to invalidate
    696696         the stored responses held by remote caches and authoring tools. A strong validator <em class="bcp14">MUST</em> be unique across all representations of a given resource, such that no two representations of that resource share the same
     
    10501050      </p>
    10511051      <ol>
    1052          <li>If the request would normally result in anything other than a 200 (OK) status code, or if the passed If-Modified-Since date
    1053             is invalid, the response is exactly the same as for a normal GET. A date which is later than the server's current time is
    1054             invalid.
     1052         <li>If the request would normally result in anything other than a <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> status code, or if the passed If-Modified-Since date is invalid, the response is exactly the same as for a normal GET. A date
     1053            which is later than the server's current time is invalid.
    10551054         </li>
    10561055         <li>If the selected representation has been modified since the If-Modified-Since date, the response is exactly the same as for
     
    11071106      <div id="rfc.iref.s.2"></div>
    11081107      <h2 id="rfc.section.4.1"><a href="#rfc.section.4.1">4.1</a>&nbsp;<a id="status.304" href="#status.304">304 Not Modified</a></h2>
    1109       <p id="rfc.section.4.1.p.1">The 304 status code indicates that a conditional GET request has been received and would have resulted in a 200 (OK) response
    1110          if it were not for the fact that the condition has evaluated to false. In other words, there is no need for the server to
    1111          transfer a representation of the target resource because the client's request indicates that it already has a valid representation,
     1108      <p id="rfc.section.4.1.p.1">The 304 status code indicates that a conditional GET request has been received and would have resulted in a <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> response if it were not for the fact that the condition has evaluated to false. In other words, there is no need for the server
     1109         to transfer a representation of the target resource because the client's request indicates that it already has a valid representation,
    11121110         as indicated by the 304 response header fields, and is therefore redirecting the client to make use of that stored representation
    11131111         as if it were the payload of a 200 response. 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.
  • draft-ietf-httpbis/latest/p4-conditional.xml

    r1708 r1715  
    271271   changed to a new, previously unused or guaranteed unique, value whenever
    272272   a change occurs to the representation data such that a change would be
    273    observable in the payload body of a 200 response to GET.  A strong
    274    validator &MAY; be changed for other reasons, such as when a semantically
     273   observable in the payload body of a <x:ref>200 (OK)</x:ref> response to GET.
     274   A strong validator &MAY; be changed for other reasons, such as when a semantically
    275275   significant part of the representation metadata is changed (e.g.,
    276276   Content-Type), but it is in the best interests of the origin server to only
     
    883883  <list style="numbers">
    884884      <t>If the request would normally result in anything other than a
    885          200 (OK) status code, or if the passed If-Modified-Since date is
     885         <x:ref>200 (OK)</x:ref> status code, or if the passed If-Modified-Since date is
    886886         invalid, the response is exactly the same as for a normal GET.
    887887         A date which is later than the server's current time is
     
    994994<t>
    995995   The 304 status code indicates that a conditional GET request has been
    996    received and would have resulted in a 200 (OK) response if it were not
     996   received and would have resulted in a <x:ref>200 (OK)</x:ref> response if it were not
    997997   for the fact that the condition has evaluated to false.  In other words,
    998998   there is no need for the server to transfer a representation of the
     
    11931193  </front>
    11941194  <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p2-semantics-&ID-VERSION;"/>
    1195   <x:source href="p2-semantics.xml" basename="p2-semantics"/>
     1195  <x:source href="p2-semantics.xml" basename="p2-semantics">
     1196    <x:defines>200 (OK)</x:defines>
     1197  </x:source>
    11961198</reference>
    11971199
  • draft-ietf-httpbis/latest/p5-range.html

    r1708 r1715  
    449449  }
    450450  @bottom-center {
    451        content: "Expires January 4, 2013";
     451       content: "Expires January 5, 2013";
    452452  }
    453453  @bottom-right {
     
    492492      <meta name="dct.creator" content="Reschke, J. F.">
    493493      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p5-range-latest">
    494       <meta name="dct.issued" scheme="ISO8601" content="2012-07-03">
     494      <meta name="dct.issued" scheme="ISO8601" content="2012-07-04">
    495495      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    496496      <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 5 of the seven-part specification that defines the protocol referred to as &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 5 defines range requests and the rules for constructing and combining responses to those requests.">
     
    518518            </tr>
    519519            <tr>
    520                <td class="left">Expires: January 4, 2013</td>
     520               <td class="left">Expires: January 5, 2013</td>
    521521               <td class="right">J. Reschke, Editor</td>
    522522            </tr>
     
    527527            <tr>
    528528               <td class="left"></td>
    529                <td class="right">July 3, 2012</td>
     529               <td class="right">July 4, 2012</td>
    530530            </tr>
    531531         </tbody>
     
    555555         in progress”.
    556556      </p>
    557       <p>This Internet-Draft will expire on January 4, 2013.</p>
     557      <p>This Internet-Draft will expire on January 5, 2013.</p>
    558558      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    559559      <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
     
    742742         </li>
    743743         <li>Date</li>
    744          <li>Cache-Control, ETag, Expires, Content-Location and/or Vary, if the header field would have been sent in a 200 response to
    745             the same request
    746          </li>
    747       </ul>
    748       <p id="rfc.section.3.1.p.3">If a 206 is sent in response to a request with an If-Range 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 200 (OK) response to the same request.
     744         <li>Cache-Control, ETag, Expires, Content-Location and/or Vary, if the header field would have been sent in a <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> response to the same request
     745         </li>
     746      </ul>
     747      <p id="rfc.section.3.1.p.3">If a 206 is sent in response to a request with an If-Range 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.
    749748      </p>
    750749      <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 2.3.1.1</a> of <a href="#Part6" id="rfc.xref.Part6.1"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) to determine freshness for 206 responses.
     
    765764</pre><div class="note" id="rfc.section.3.2.p.4">
    766765         <p> <b>Note:</b> Clients cannot depend on servers to send a <a href="#status.416" class="smpl">416 (Requested
    767                Range Not Satisfiable)</a> response instead of a 200 (OK) response for an unsatisfiable Range header field, since not all servers implement this header
    768             field.
     766               Range Not Satisfiable)</a> response instead of a <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> response for an unsatisfiable Range header field, since not all servers implement this header field.
    769767         </p>
    770768      </div>
     
    799797         defined to be either an entity-tag that is not marked as weak (<a href="p4-conditional.html#header.etag" title="ETag">Section 2.3</a> of <a href="#Part4" id="rfc.xref.Part4.2"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>) or, if no entity-tag is provided, a Last-Modified value that is strong in the sense defined by <a href="p4-conditional.html#lastmod.comparison" title="Comparison">Section 2.2.2</a> of <a href="#Part4" id="rfc.xref.Part4.3"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>.
    800798      </p>
    801       <p id="rfc.section.4.2.p.2">When a client receives an incomplete 200 (OK) or <a href="#status.206" class="smpl">206 (Partial Content)</a> response and already has one or more stored responses for the same method and effective request URI, all of the stored responses
     799      <p id="rfc.section.4.2.p.2">When a client receives an incomplete <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> or <a href="#status.206" class="smpl">206 (Partial Content)</a> response and already has one or more stored responses for the same method and effective request URI, all of the stored responses
    802800         with the same strong validator <em class="bcp14">MAY</em> be combined with the partial content in this new response. If none of the stored responses contain the same strong validator,
    803801         then this new response corresponds to a new representation and <em class="bcp14">MUST NOT</em> be combined with the existing stored responses.
    804802      </p>
    805       <p id="rfc.section.4.2.p.3">If the new response is an incomplete 200 (OK) response, then the header fields of that new response are used for any combined
    806          response and replace those of the matching stored responses.
    807       </p>
    808       <p id="rfc.section.4.2.p.4">If the new response is a <a href="#status.206" class="smpl">206 (Partial Content)</a> response and at least one of the matching stored responses is a 200 (OK), then the combined response header fields consist
    809          of the most recent 200 response's header fields. If all of the matching stored responses are 206 responses, then the stored
    810          response with the most header fields is used as the source of header fields for the combined response, except that the client <em class="bcp14">MUST</em> use other header fields provided in the new response, aside from Content-Range, to replace all instances of the corresponding
     803      <p id="rfc.section.4.2.p.3">If the new response is an incomplete <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> response, then the header fields of that new response are used for any combined response and replace those of the matching
     804         stored responses.
     805      </p>
     806      <p id="rfc.section.4.2.p.4">If the new response is a <a href="#status.206" class="smpl">206 (Partial Content)</a> response and at least one of the matching stored responses is a <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a>, then the combined response header fields consist of the most recent 200 response's header fields. If all of the matching
     807         stored responses are 206 responses, then the stored response with the most header fields is used as the source of header fields
     808         for the combined response, except that the client <em class="bcp14">MUST</em> use other header fields provided in the new response, aside from Content-Range, to replace all instances of the corresponding
    811809         header fields in the stored response.
    812810      </p>
    813811      <p id="rfc.section.4.2.p.5">The combined response message body consists of the union of partial content ranges in the new response and each of the selected
    814          responses. If the union consists of the entire range of the representation, then the combined response <em class="bcp14">MUST</em> be recorded as a complete 200 (OK) response with a Content-Length header field that reflects the complete length. Otherwise,
    815          the combined response(s) <em class="bcp14">MUST</em> include a Content-Range header field describing the included range(s) and be recorded as incomplete. If the union consists
     812         responses. If the union consists of the entire range of the representation, then the combined response <em class="bcp14">MUST</em> be recorded as a complete <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> response with a Content-Length header field that reflects the complete length. Otherwise, the combined response(s) <em class="bcp14">MUST</em> include a Content-Range header field describing the included range(s) and be recorded as incomplete. If the union consists
    816813         of a discontinuous range of the representation, then the client <em class="bcp14">MAY</em> store it as either a multipart range response or as multiple 206 responses with one continuous range each.
    817814      </p>
     
    887884      </ul>
    888885      <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
    889          attack), the server <em class="bcp14">SHOULD</em> treat the request as if the invalid Range header field did not exist. (Normally, this means return a 200 response containing
    890          the full representation).
     886         attack), the server <em class="bcp14">SHOULD</em> treat the request as if the invalid Range 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).
    891887      </p>
    892888      <div id="rfc.iref.i.1"></div>
     
    911907      </p>
    912908      <p id="rfc.section.5.3.p.7">If the validator given in the If-Range header field matches the current validator for the selected representation of the target
    913          resource, then the server <em class="bcp14">SHOULD</em> send the specified sub-range of the representation using a <a href="#status.206" class="smpl">206 (Partial Content)</a> response. If the validator does not match, then the server <em class="bcp14">SHOULD</em> send the entire representation using a 200 (OK) response.
     909         resource, then the server <em class="bcp14">SHOULD</em> send the specified sub-range of the representation using a <a href="#status.206" class="smpl">206 (Partial Content)</a> response. If the validator does not match, then the server <em class="bcp14">SHOULD</em> send the entire representation using a <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> response.
    914910      </p>
    915911      <div id="rfc.iref.r.1"></div>
     
    987983      <ul>
    988984         <li>The presence of a Range header field in an unconditional GET modifies what is returned if the GET is otherwise successful.
    989             In other words, the response carries a status code of <a href="#status.206" class="smpl">206 (Partial Content)</a> instead of 200 (OK).
     985            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>.
    990986         </li>
    991987         <li>The presence of a Range header field in a conditional GET (a request using one or both of If-Modified-Since and If-None-Match,
  • draft-ietf-httpbis/latest/p5-range.xml

    r1708 r1715  
    335335    <t>
    336336        Cache-Control, ETag, Expires, Content-Location and/or Vary, if
    337         the header field would have been sent in a 200 response to the
     337        the header field would have been sent in a <x:ref>200 (OK)</x:ref> response to the
    338338        same request
    339339    </t>
     
    344344   &SHOULD-NOT; include other representation header fields. Otherwise, the response
    345345   &MUST; include all of the representation header fields that would have been returned
    346    with a 200 (OK) response to the same request.
     346   with a <x:ref>200 (OK)</x:ref> response to the same request.
    347347</t>
    348348<t>
     
    380380  <t>
    381381    &Note; Clients cannot depend on servers to send a <x:ref>416 (Requested
    382     Range Not Satisfiable)</x:ref> response instead of a 200 (OK) response for
    383     an unsatisfiable Range header field, since not all servers
     382    Range Not Satisfiable)</x:ref> response instead of a <x:ref>200 (OK)</x:ref>
     383    response for an unsatisfiable Range header field, since not all servers
    384384    implement this header field.
    385385  </t>
     
    444444</t>
    445445<t>
    446    When a client receives an incomplete 200 (OK) or <x:ref>206 (Partial Content)</x:ref>
     446   When a client receives an incomplete <x:ref>200 (OK)</x:ref> or <x:ref>206 (Partial Content)</x:ref>
    447447   response and already has one or more stored responses for the same method
    448448   and effective request URI, all of the stored responses with the same
     
    453453</t>
    454454<t>
    455    If the new response is an incomplete 200 (OK) response, then the header
     455   If the new response is an incomplete <x:ref>200 (OK)</x:ref> response, then the header
    456456   fields of that new response are used for any combined response and replace
    457457   those of the matching stored responses.
     
    459459<t>
    460460   If the new response is a <x:ref>206 (Partial Content)</x:ref> response and at least one
    461    of the matching stored responses is a 200 (OK), then the combined response
     461   of the matching stored responses is a <x:ref>200 (OK)</x:ref>, then the combined response
    462462   header fields consist of the most recent 200 response's header fields.
    463463   If all of the matching stored responses are 206 responses, then the
     
    472472   content ranges in the new response and each of the selected responses.
    473473   If the union consists of the entire range of the representation, then the
    474    combined response &MUST; be recorded as a complete 200 (OK) response
     474   combined response &MUST; be recorded as a complete <x:ref>200 (OK)</x:ref> response
    475475   with a Content-Length header field that reflects the complete length.
    476476   Otherwise, the combined response(s) &MUST; include a Content-Range
     
    626626   syntactically invalid, or if it might be seen as a denial-of-service
    627627   attack), the server &SHOULD; treat the request as if the invalid Range
    628    header field did not exist. (Normally, this means return a 200
     628   header field did not exist. (Normally, this means return a <x:ref>200 (OK)</x:ref>
    629629   response containing the full representation).
    630630</t>
     
    681681   the server &SHOULD; send the specified sub-range of the representation
    682682   using a <x:ref>206 (Partial Content)</x:ref> response. If the validator does not match,
    683    then the server &SHOULD; send the entire representation using a 200 (OK)
     683   then the server &SHOULD; send the entire representation using a <x:ref>200 (OK)</x:ref>
    684684   response.
    685685</t>
     
    833833        what is returned if the GET is otherwise successful. In other
    834834        words, the response carries a status code of <x:ref>206 (Partial Content)</x:ref>
    835         instead of 200 (OK).</t>
     835        instead of <x:ref>200 (OK)</x:ref>.</t>
    836836
    837837     <t>The presence of a Range header field in a conditional GET (a request
     
    10201020  </front>
    10211021  <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p2-semantics-&ID-VERSION;"/>
    1022   <x:source href="p2-semantics.xml" basename="p2-semantics"/>
     1022  <x:source href="p2-semantics.xml" basename="p2-semantics">
     1023    <x:defines>200 (OK)</x:defines>
     1024  </x:source>
    10231025</reference>
    10241026
  • draft-ietf-httpbis/latest/p6-cache.html

    r1713 r1715  
    832832      </p>
    833833      <p id="rfc.section.2.p.2">Each <dfn>cache entry</dfn> consists of a cache key and one or more HTTP responses corresponding to prior requests that used the same key. The most common
    834          form of cache entry is a successful result of a retrieval request: i.e., a 200 (OK) response containing a representation of
    835          the resource identified by the request target. However, it is also possible to cache negative results (e.g., <a href="p2-semantics.html#status.404" class="smpl">404 (Not Found)</a>, incomplete results (e.g., <a href="p5-range.html#status.206" class="smpl">206 (Partial Content)</a>), and responses to safe methods other than GET if the method's definition allows such caching and defines something suitable
     834         form of cache entry is a successful result of a retrieval request: i.e., a <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> response containing a representation of the resource identified by the request target. However, it is also possible to cache
     835         negative results (e.g., <a href="p2-semantics.html#status.404" class="smpl">404 (Not Found)</a>, incomplete results (e.g., <a href="p5-range.html#status.206" class="smpl">206 (Partial Content)</a>), and responses to safe methods other than GET if the method's definition allows such caching and defines something suitable
    836836         for use as a cache key.
    837837      </p>
     
    876876         time, as such responses are not usually useful to store. However, caches are not prohibited from storing such responses.
    877877      </p>
    878       <p id="rfc.section.2.1.p.5">A response message is considered complete when all of the octets indicated by the message framing (<a href="#Part1" id="rfc.xref.Part1.11"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) are received prior to the connection being closed. If the request is GET, the response status is 200 (OK), and the entire
    879          response header block has been received, a cache <em class="bcp14">MAY</em> store an incomplete response message body if the cache entry is recorded as incomplete. Likewise, a <a href="p5-range.html#status.206" class="smpl">206 (Partial Content)</a> response <em class="bcp14">MAY</em> be stored as if it were an incomplete 200 (OK) cache entry. However, a cache <em class="bcp14">MUST NOT</em> store incomplete or partial content responses if it does not support the Range and Content-Range header fields or if it does
     878      <p id="rfc.section.2.1.p.5">A response message is considered complete when all of the octets indicated by the message framing (<a href="#Part1" id="rfc.xref.Part1.11"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) are received prior to the connection being closed. If the request is GET, the response status is <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a>, and the entire response header block has been received, a cache <em class="bcp14">MAY</em> store an incomplete response message body if the cache entry is recorded as incomplete. Likewise, a <a href="p5-range.html#status.206" class="smpl">206 (Partial Content)</a> response <em class="bcp14">MAY</em> be stored as if it were an incomplete <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> cache entry. However, a cache <em class="bcp14">MUST NOT</em> store incomplete or partial content responses if it does not support the Range and Content-Range header fields or if it does
    880879         not understand the range units used in those fields.
    881880      </p>
     
    10951094      </ul>
    10961095      <h3 id="rfc.section.2.4.1"><a href="#rfc.section.2.4.1">2.4.1</a>&nbsp;<a id="freshening.responses" href="#freshening.responses">Freshening Responses with 304 Not Modified</a></h3>
    1097       <p id="rfc.section.2.4.1.p.1">When a cache receives a <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a> response and already has one or more stored 200 (OK) responses for the same cache key, the cache needs to identify which of
    1098          the stored responses are updated by this new response and then update the stored response(s) with the new information provided
    1099          in the 304 response.
     1096      <p id="rfc.section.2.4.1.p.1">When a cache receives a <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a> response and already has one or more stored <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> responses for the same cache key, the cache needs to identify which of the stored responses are updated by this new response
     1097         and then update the stored response(s) with the new information provided in the 304 response.
    11001098      </p>
    11011099      <ul>
  • draft-ietf-httpbis/latest/p6-cache.xml

    r1713 r1715  
    432432   HTTP responses corresponding to prior requests that used the same key.
    433433   The most common form of cache entry is a successful result of a retrieval
    434    request: i.e., a 200 (OK) response containing a representation of the
    435    resource identified by the request target.  However, it is also possible
     434   request: i.e., a <x:ref>200 (OK)</x:ref> response containing a representation
     435   of the resource identified by the request target.  However, it is also possible
    436436   to cache negative results (e.g., <x:ref>404 (Not Found)</x:ref>, incomplete results
    437437   (e.g., <x:ref>206 (Partial Content)</x:ref>), and responses to safe methods other than
     
    504504   A response message is considered complete when all of the octets
    505505   indicated by the message framing (&messaging;) are received
    506    prior to the connection being closed.
    507    If the request is GET, the response status is 200 (OK), and the entire
     506   prior to the connection being closed. If the request is GET, the response
     507   status is <x:ref>200 (OK)</x:ref>, and the entire
    508508   response header block has been received, a cache &MAY; store an incomplete
    509509   response message body if the cache entry is recorded as incomplete.
    510510   Likewise, a <x:ref>206 (Partial Content)</x:ref> response &MAY; be stored as if it were
    511    an incomplete 200 (OK) cache entry.  However, a cache &MUST-NOT; store
     511   an incomplete <x:ref>200 (OK)</x:ref> cache entry.  However, a cache &MUST-NOT; store
    512512   incomplete or partial content responses if it does not support the Range
    513513   and Content-Range header fields or if it does not understand the
     
    929929<t>
    930930   When a cache receives a <x:ref>304 (Not Modified)</x:ref> response and already has one
    931    or more stored 200 (OK) responses for the same cache key, the cache needs
     931   or more stored <x:ref>200 (OK)</x:ref> responses for the same cache key, the cache needs
    932932   to identify which of the stored responses are updated by this new response
    933933   and then update the stored response(s) with the new information provided in
     
    22882288    <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p2-semantics-&ID-VERSION;" />
    22892289    <x:source basename="p2-semantics" href="p2-semantics.xml">
     2290      <x:defines>200 (OK)</x:defines>
    22902291      <x:defines>404 (Not Found)</x:defines>
    22912292      <x:defines>504 (Gateway Timeout)</x:defines>
Note: See TracChangeset for help on using the changeset viewer.