Ignore:
Timestamp:
Jul 6, 2012, 7:48:51 AM (7 years ago)
Author:
julian.reschke@…
Message:

Work-in-progress: hyperlink status codes definitions (P2)

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

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpbis/latest/p0-introduction.html

    r1725 r1735  
    393393  }
    394394  @bottom-center {
    395        content: "Expires January 6, 2013";
     395       content: "Expires January 7, 2013";
    396396  }
    397397  @bottom-right {
     
    426426      <meta name="dct.creator" content="Reschke, J. F.">
    427427      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p0-introduction-latest">
    428       <meta name="dct.issued" scheme="ISO8601" content="2012-07-05">
     428      <meta name="dct.issued" scheme="ISO8601" content="2012-07-06">
    429429      <meta name="dct.abstract" content="This document is the first in a series that, collectively, define the HyperText Transfer Protocol, version 1.1; otherwise known as HTTP/1.1.">
    430430      <meta name="description" content="This document is the first in a series that, collectively, define the HyperText Transfer Protocol, version 1.1; otherwise known as HTTP/1.1.">
     
    446446            </tr>
    447447            <tr>
    448                <td class="left">Expires: January 6, 2013</td>
     448               <td class="left">Expires: January 7, 2013</td>
    449449               <td class="right">W3C</td>
    450450            </tr>
     
    467467            <tr>
    468468               <td class="left"></td>
    469                <td class="right">July 5, 2012</td>
     469               <td class="right">July 6, 2012</td>
    470470            </tr>
    471471         </tbody>
     
    491491         in progress”.
    492492      </p>
    493       <p>This Internet-Draft will expire on January 6, 2013.</p>
     493      <p>This Internet-Draft will expire on January 7, 2013.</p>
    494494      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    495495      <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
  • draft-ietf-httpbis/latest/p1-messaging.html

    r1734 r1735  
    13761376      <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
    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.,
    1378          Transfer-Encoding, Content-Length, etc.) only indicate what their values would have been if the request method had been GET. <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. 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
    1379             (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, Payload and Content Negotiation">[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>.)
     1378         Transfer-Encoding, Content-Length, etc.) only indicate what their values would have been if the request method had been GET. <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. 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. (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, Payload and Content Negotiation">[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>.)
    13801379      </p>
    13811380      <div id="rfc.iref.t.4"></div>
     
    14451444      <ol>
    14461445         <li>
    1447             <p>Any response to a HEAD request and any response with a status code of 100-199, 204, or <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a> is always terminated by the first empty line after the header fields, regardless of the header fields present in the message,
    1448                and thus cannot contain a message body.
     1446            <p>Any response to a HEAD request and any response with a <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>, or <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a> status code is always terminated by the first empty line after the header fields, regardless of the header fields present
     1447               in the message, and thus cannot contain a message body.
    14491448            </p>
    14501449         </li>
     
    19711970      <p id="rfc.section.5.7.p.1">HTTP does not include a request identifier for associating a given request message with its corresponding one or more response
    19721971         messages. Hence, it relies on the order of response arrival to correspond exactly to the order in which requests are made
    1973          on the same connection. More than one response message per request only occurs when one or more informational responses (1xx,
    1974          see <a href="p2-semantics.html#status.1xx" title="Informational 1xx">Section 4.3</a> of <a href="#Part2" id="rfc.xref.Part2.16"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>) precede a final response to the same request.
     1972         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 4.3</a> of <a href="#Part2" id="rfc.xref.Part2.16"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>) precede a final response to the same request.
    19751973      </p>
    19761974      <p id="rfc.section.5.7.p.2">A client that uses persistent connections and sends more than one request per connection <em class="bcp14">MUST</em> maintain a list of outstanding requests in the order sent on that connection and <em class="bcp14">MUST</em> associate each received response message to the highest ordered request that has not yet received a final (non-<a href="p2-semantics.html#status.1xx" class="smpl">1xx</a>) response.
  • draft-ietf-httpbis/latest/p1-messaging.xml

    r1734 r1735  
    14841484   <x:ref>2xx (Successful)</x:ref> responses to CONNECT switch to tunnel mode instead of
    14851485   having a message body.
    1486    All <x:ref>1xx (Informational)</x:ref>, <x:ref>204 (No Content)</x:ref>, and <x:ref>304
    1487    (Not Modified)</x:ref> responses &MUST-NOT; include a message body.
     1486   All <x:ref>1xx (Informational)</x:ref>, <x:ref>204 (No Content)</x:ref>, and
     1487   <x:ref>304 (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;.)
     
    16431643  <list style="numbers">
    16441644    <x:lt><t>
    1645      Any response to a HEAD request and any response with a status
    1646      code of 100-199, 204, or <x:ref>304 (Not Modified)</x:ref> is always
     1645     Any response to a HEAD request and any response with a
     1646     <x:ref>1xx (Informational)</x:ref>, <x:ref>204 (No Content)</x:ref>, or
     1647     <x:ref>304 (Not Modified)</x:ref> status code is always
    16471648     terminated by the first empty line after the header fields, regardless of
    16481649     the header fields present in the message, and thus cannot contain a
     
    26622663   to the order in which requests are made on the same connection.
    26632664   More than one response message per request only occurs when one or more
    2664    informational responses (1xx, see &status-1xx;) precede a final response
     2665   informational responses (<x:ref>1xx</x:ref>, see &status-1xx;) precede a final response
    26652666   to the same request.
    26662667</t>
  • draft-ietf-httpbis/latest/p2-semantics.html

    r1734 r1735  
    966966         with that resource.
    967967      </p>
    968       <p id="rfc.section.2.3.1.p.6">A 200 response <em class="bcp14">SHOULD</em> include any header fields that indicate optional features implemented by the server and applicable to that resource (e.g.,
     968      <p id="rfc.section.2.3.1.p.6">A <a href="#status.200" class="smpl">200 (OK)</a> response <em class="bcp14">SHOULD</em> include any header fields that indicate optional features implemented by the server and applicable to that resource (e.g.,
    969969         Allow), possibly including extensions not defined by this specification. The response body, if any, <em class="bcp14">SHOULD</em> also include information about the communication options. The format for such a body is not defined by this specification,
    970970         but might be defined by future extensions to HTTP. Content negotiation <em class="bcp14">MAY</em> be used to select the appropriate response format. If no response body is included, the response <em class="bcp14">MUST</em> include a Content-Length field with a field-value of "0".
     
    18011801         <p> <b>Note:</b> In HTTP/1.0, only the status codes <a href="#status.301" class="smpl">301 (Moved Permanently)</a> and <a href="#status.302" class="smpl">302 (Found)</a> were defined for the first type of redirect, and the second type did not exist at all (<a href="#RFC1945" id="rfc.xref.RFC1945.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.0">[RFC1945]</cite></a>, <a href="http://tools.ietf.org/html/rfc1945#section-9.3">Section 9.3</a>). However it turned out that web forms using POST expected redirects to change the operation for the subsequent request to
    18021802            retrieval (GET). To address this use case, HTTP/1.1 introduced the second type of redirect with the status code <a href="#status.303" class="smpl">303 (See Other)</a> (<a href="#RFC2068" id="rfc.xref.RFC2068.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>, <a href="http://tools.ietf.org/html/rfc2068#section-10.3.4">Section 10.3.4</a>). As user agents did not change their behavior to maintain backwards compatibility, the first revision of HTTP/1.1 added
    1803             yet another status code, <a href="#status.307" class="smpl">307 (Temporary Redirect)</a>, for which the backwards compatibility problems did not apply (<a href="#RFC2616" id="rfc.xref.RFC2616.2"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>, <a href="http://tools.ietf.org/html/rfc2616#section-10.3.8">Section 10.3.8</a>). Over 10 years later, most user agents still do method rewriting for status codes 301 and 302, therefore this specification
    1804             makes that behavior conformant in case the original request was POST.
     1803            yet another status code, <a href="#status.307" class="smpl">307 (Temporary Redirect)</a>, for which the backwards compatibility problems did not apply (<a href="#RFC2616" id="rfc.xref.RFC2616.2"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>, <a href="http://tools.ietf.org/html/rfc2616#section-10.3.8">Section 10.3.8</a>). Over 10 years later, most user agents still do method rewriting for status codes <a href="#status.301" class="smpl">301</a> and <a href="#status.302" class="smpl">302</a>, therefore this specification makes that behavior conformant in case the original request was POST.
    18051804         </p>
    18061805      </div>
     
    20842083      </p>
    20852084      <div class="note" id="rfc.section.4.7.5.p.2">
    2086          <p> <b>Note</b> to implementors: some deployed proxies are known to return 400 or 500 when DNS lookups time out.
     2085         <p> <b>Note</b> to implementors: 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
     2086               Error)</a> when DNS lookups time out.
    20872087         </p>
    20882088      </div>
     
    23912391               (Non-Authoritative Information)</a> and the request method was GET, the response payload is a representation of the target resource.
    23922392         </li>
    2393          <li>If the response status code is <a href="#status.204" class="smpl">204 (No Content)</a>, 206 (Partial Content, or <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a> and the request method was GET or HEAD, the response payload is a partial representation of the target resource.
     2393         <li>If the response status code is <a href="#status.204" class="smpl">204 (No Content)</a>, <a href="p5-range.html#status.206" class="smpl">206 (Partial Content)</a>, or <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a> and the request method was GET or HEAD, the response payload is a partial representation of the target resource.
    23942394         </li>
    23952395         <li>If the response has a Content-Location header field, and that URI is the same as the effective request URI, the response payload
     
    24072407      <h2 id="rfc.section.7.2"><a href="#rfc.section.7.2">7.2</a>&nbsp;<a id="representation.header.fields" href="#representation.header.fields">Representation Header Fields</a></h2>
    24082408      <p id="rfc.section.7.2.p.1">Representation header fields define metadata about the representation data enclosed in the message body or, if no message
    2409          body is present, about the representation that would have been transferred in a 200 response to a simultaneous GET request
    2410          with the same effective request URI.
     2409         body is present, about the representation that would have been transferred in a <a href="#status.200" class="smpl">200 (OK)</a> response to a simultaneous GET request with the same effective request URI.
    24112410      </p>
    24122411      <p id="rfc.section.7.2.p.2">The following header fields are defined as representation metadata:</p>
     
    28502849      <h2 id="rfc.section.9.8"><a href="#rfc.section.9.8">9.8</a>&nbsp;<a id="header.content-location" href="#header.content-location">Content-Location</a></h2>
    28512850      <p id="rfc.section.9.8.p.1">The "Content-Location" header field supplies a URI that can be used as a specific identifier for the representation in this
    2852          message. In other words, if one were to perform a GET on this URI at the time of this message's generation, then a 200 response
    2853          would contain the same representation that is enclosed as payload in this message.
     2851         message. In other words, if one were to perform a GET on this URI at the time of this message's generation, then a <a href="#status.200" class="smpl">200 (OK)</a> response would contain the same representation that is enclosed as payload in this message.
    28542852      </p>
    28552853      <div id="rfc.figure.u.42"></div><pre class="inline"><span id="rfc.iref.g.43"></span>  <a href="#header.content-location" class="smpl">Content-Location</a> = <a href="#abnf.dependencies" class="smpl">absolute-URI</a> / <a href="#abnf.dependencies" class="smpl">partial-URI</a>
     
    28702868         indicates that this representation contains a report on the action's status and the same report is available (for future access
    28712869         with GET) at the given URI. For example, a purchase transaction made via a POST request might include a receipt document as
    2872          the payload of the 200 response; the Content-Location value provides an identifier for retrieving a copy of that same receipt
    2873          in the future.
     2870         the payload of the <a href="#status.200" class="smpl">200 (OK)</a> response; the Content-Location value provides an identifier for retrieving a copy of that same receipt in the future.
    28742871      </p>
    28752872      <p id="rfc.section.9.8.p.6">If Content-Location is included in a request message, then it <em class="bcp14">MAY</em> be interpreted by the origin server as an indication of where the user agent originally obtained the content of the enclosed
     
    29842981      </p>
    29852982      <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>
    2986 </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 <a href="#status.3xx" class="smpl">3xx</a> responses, the location <em class="bcp14">SHOULD</em> indicate the server's preferred URI for automatic redirection to the resource.
     2983</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 <a href="#status.3xx" class="smpl">3xx (Redirection)</a> responses, the location <em class="bcp14">SHOULD</em> indicate the server's preferred URI for automatic redirection to the resource.
    29872984      </p>
    29882985      <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,
     
    39703967      <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>)
    39713968      </p>
    3972       <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" id="rfc.xref.status.3xx.1" title="Redirection 3xx">Section&nbsp;4.5</a>)
     3969      <p id="rfc.section.C.p.6">Status codes <a href="#status.301" class="smpl">301</a>, <a href="#status.302" class="smpl">302</a>, and <a href="#status.307" class="smpl">307</a>: removed the normative requirements on both response payloads and user interaction. (<a href="#status.3xx" id="rfc.xref.status.3xx.1" title="Redirection 3xx">Section&nbsp;4.5</a>)
    39733970      </p>
    39743971      <p id="rfc.section.C.p.7">Failed to consider that there are many other request methods that are safe to automatically redirect, and further that the
    39753972         user agent is able to make that determination based on the request method semantics. Furthermore, allow user agents to rewrite
    3976          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>)
     3973         the method from POST to GET for status codes <a href="#status.301" class="smpl">301</a> and <a href="#status.302" class="smpl">302</a>. (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>)
    39773974      </p>
    39783975      <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
  • draft-ietf-httpbis/latest/p2-semantics.xml

    r1734 r1735  
    542542</t>
    543543<t>
    544    A 200 response &SHOULD; include any header fields that indicate
    545    optional features implemented by the server and applicable to that
     544   A <x:ref>200 (OK)</x:ref> response &SHOULD; include any header fields that
     545   indicate optional features implemented by the server and applicable to that
    546546   resource (e.g., Allow), possibly including extensions not defined by
    547547   this specification. The response body, if any, &SHOULD; also include
     
    15871587    <x:ref>307 (Temporary Redirect)</x:ref>, for which the backwards
    15881588    compatibility problems did not apply (<xref target="RFC2616" x:fmt="," x:sec="10.3.8"/>).
    1589     Over 10 years later, most user agents still do method rewriting for
    1590     status codes 301 and 302, therefore this specification makes that behavior
     1589    Over 10 years later, most user agents still do method rewriting for status codes
     1590    <x:ref>301</x:ref> and <x:ref>302</x:ref>, therefore this specification makes that behavior
    15911591    conformant in case the original request was POST.
    15921592  </t>
     
    16501650  <iref primary="true" item="301 Moved Permanently (status code)" x:for-anchor=""/>
    16511651  <iref primary="true" item="Status Codes" subitem="301 Moved Permanently" x:for-anchor=""/>
     1652  <x:anchor-alias value="301"/>
    16521653  <x:anchor-alias value="301 (Moved Permanently)"/>
    16531654<t>
     
    16801681  <iref primary="true" item="302 Found (status code)" x:for-anchor=""/>
    16811682  <iref primary="true" item="Status Codes" subitem="302 Found" x:for-anchor=""/>
     1683  <x:anchor-alias value="302"/>
    16821684  <x:anchor-alias value="302 (Found)"/>
    16831685<t>
     
    17661768  <iref primary="true" item="307 Temporary Redirect (status code)" x:for-anchor=""/>
    17671769  <iref primary="true" item="Status Codes" subitem="307 Temporary Redirect" x:for-anchor=""/>
     1770  <x:anchor-alias value="307"/>
    17681771  <x:anchor-alias value="307 (Temporary Redirect)"/>
    17691772<t>
     
    21472150  <t>
    21482151    <x:h>Note</x:h> to implementors: some deployed proxies are known to
    2149     return 400 or 500 when DNS lookups time out.
     2152    return <x:ref>400 (Bad Request)</x:ref> or <x:ref>500 (Internal Server
     2153    Error)</x:ref> when DNS lookups time out.
    21502154  </t>
    21512155</x:note>
     
    27082712   the response payload is a representation of the target resource.</t>
    27092713   <t>If the response status code is <x:ref>204 (No Content)</x:ref>,
    2710    <x:ref>206 (Partial Content</x:ref>, or <x:ref>304 (Not Modified)</x:ref>
     2714   <x:ref>206 (Partial Content)</x:ref>, or <x:ref>304 (Not Modified)</x:ref>
    27112715   and the request method was GET or HEAD, the response payload is a partial
    27122716   representation of the target resource.</t>
     
    27342738   Representation header fields define metadata about the representation data
    27352739   enclosed in the message body or, if no message body is present, about
    2736    the representation that would have been transferred in a 200 response
    2737    to a simultaneous GET request with the same effective request URI.
     2740   the representation that would have been transferred in a <x:ref>200 (OK)</x:ref>
     2741   response to a simultaneous GET request with the same effective request URI.
    27382742</t>
    27392743<t>
     
    34543458   as a specific identifier for the representation in this message.
    34553459   In other words, if one were to perform a GET on this URI at the time
    3456    of this message's generation, then a 200 response would contain the
    3457    same representation that is enclosed as payload in this message.
     3460   of this message's generation, then a <x:ref>200 (OK)</x:ref> response would
     3461   contain the same representation that is enclosed as payload in this message.
    34583462</t>
    34593463<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Content-Location"/>
     
    34923496   available (for future access with GET) at the given URI.  For
    34933497   example, a purchase transaction made via a POST request might
    3494    include a receipt document as the payload of the 200 response;
    3495    the Content-Location value provides an identifier for retrieving
     3498   include a receipt document as the payload of the <x:ref>200 (OK)</x:ref>
     3499   response; the Content-Location value provides an identifier for retrieving
    34963500   a copy of that same receipt in the future.
    34973501</t>
     
    37323736<t>
    37333737   For <x:ref>201 (Created)</x:ref> responses, the Location is the URI of the
    3734    new resource which was created by the request. For <x:ref>3xx</x:ref> responses, the
    3735    location &SHOULD; indicate the server's preferred URI for automatic
    3736    redirection to the resource.
     3738   new resource which was created by the request. For <x:ref>3xx (Redirection)</x:ref>
     3739   responses, the location &SHOULD; indicate the server's preferred URI for
     3740   automatic redirection to the resource.
    37373741</t>
    37383742<t>
     
    54705474</t>
    54715475<t>
    5472   Status codes 301, 302, and 307: removed the normative requirements on both
    5473   response payloads and user interaction.
     5476  Status codes <x:ref>301</x:ref>, <x:ref>302</x:ref>, and <x:ref>307</x:ref>:
     5477  removed the normative requirements on both response payloads and user interaction.
    54745478  (<xref target="status.3xx"/>)
    54755479</t>
     
    54795483  that determination based on the request method semantics.
    54805484  Furthermore, allow user agents to rewrite the method from POST to GET
    5481   for status codes 301 and 302.
     5485  for status codes <x:ref>301</x:ref> and <x:ref>302</x:ref>.
    54825486  (Sections <xref format="counter" target="status.301"/>,
    54835487  <xref format="counter" target="status.302"/> and
  • draft-ietf-httpbis/latest/p3-payload.html

    r1697 r1735  
    374374  }
    375375  @bottom-center {
    376        content: "Expires January 2, 2013";
     376       content: "Expires January 7, 2013";
    377377  }
    378378  @bottom-right {
     
    404404      <meta name="dct.creator" content="Reschke, J. F.">
    405405      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p3-payload-latest">
    406       <meta name="dct.issued" scheme="ISO8601" content="2012-07-01">
     406      <meta name="dct.issued" scheme="ISO8601" content="2012-07-06">
    407407      <meta name="dct.abstract" content="This part is now obsolete. Please see HTTPbis, Part 2.">
    408408      <meta name="description" content="This part is now obsolete. Please see HTTPbis, Part 2.">
     
    424424            </tr>
    425425            <tr>
    426                <td class="left">Expires: January 2, 2013</td>
     426               <td class="left">Expires: January 7, 2013</td>
    427427               <td class="right">W3C</td>
    428428            </tr>
     
    437437            <tr>
    438438               <td class="left"></td>
    439                <td class="right">July 1, 2012</td>
     439               <td class="right">July 6, 2012</td>
    440440            </tr>
    441441         </tbody>
     
    453453         in progress”.
    454454      </p>
    455       <p>This Internet-Draft will expire on January 2, 2013.</p>
     455      <p>This Internet-Draft will expire on January 7, 2013.</p>
    456456      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    457457      <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
  • draft-ietf-httpbis/latest/p5-range.html

    r1734 r1735  
    805805      </p>
    806806      <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 <a href="#status.206" class="smpl">206</a> responses, then the stored response with the most header fields is used as the source of header fields for the combined response,
    808          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
     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
    809809         header fields in the stored response.
    810810      </p>
  • draft-ietf-httpbis/latest/p5-range.xml

    r1734 r1735  
    462462   of the matching stored responses is a <x:ref>200 (OK)</x:ref>, then the combined response
    463463   header fields consist of the most recent 200 response's header fields.
    464    If all of the matching stored responses are <x:ref>206</x:ref> responses, then the
     464   If all of the matching stored responses are 206 responses, then the
    465465   stored response with the most header fields is used as the source of
    466466   header fields for the combined response, except that the client &MUST;
     
    10231023  <x:source href="p2-semantics.xml" basename="p2-semantics">
    10241024    <x:defines>200 (OK)</x:defines>
     1025    <x:defines>410 (Gone)</x:defines>
    10251026  </x:source>
    10261027</reference>
  • draft-ietf-httpbis/latest/p6-cache.html

    r1734 r1735  
    965965      <h4 id="rfc.section.2.3.1.1"><a href="#rfc.section.2.3.1.1">2.3.1.1</a>&nbsp;<a id="heuristic.freshness" href="#heuristic.freshness">Calculating Heuristic Freshness</a></h4>
    966966      <p id="rfc.section.2.3.1.1.p.1">If no explicit expiration time is present in a stored response that has a status code whose definition allows heuristic freshness
    967          to be used (including the following in <a href="p2-semantics.html#status.codes" title="Status Codes">Section 4</a> of <a href="#Part2" id="rfc.xref.Part2.4"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>: 200, 203, <a href="p5-range.html#status.206" class="smpl">206</a>, 300, 301 and 410), 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.
     967         to be used (including the following in <a href="p2-semantics.html#status.codes" title="Status Codes">Section 4</a> of <a href="#Part2" id="rfc.xref.Part2.4"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[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
     968            (Non-Authoritative Information)</a>, <a href="p5-range.html#status.206" class="smpl">206 (Partial 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 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.
    968969      </p>
    969970      <p id="rfc.section.2.3.1.1.p.2">When a heuristic is used to calculate freshness lifetime, a cache <em class="bcp14">SHOULD</em> attach a Warning header field with a 113 warn-code to the response if its current_age is more than 24 hours and such a warning
     
    10921093            request is suitable. Instead, the cache can use the full response to satisfy the request and <em class="bcp14">MAY</em> replace the stored response(s).
    10931094         </li>
    1094          <li>However, if a cache receives a 5xx response while attempting to validate a response, it can either forward this response to
    1095             the requesting client, or act as if the server failed to respond. In the latter case, it can return a previously stored response
    1096             (see <a href="#serving.stale.responses" title="Serving Stale Responses">Section&nbsp;2.3.3</a>).
     1095         <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
     1096            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;2.3.3</a>).
    10971097         </li>
    10981098      </ul>
     
    11521152      <p id="rfc.section.2.6.p.4">A cache <em class="bcp14">MUST</em> invalidate the effective request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 5.5</a> of <a href="#Part1" id="rfc.xref.Part1.15"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) when it receives a non-error response to a request with a method whose safety is unknown.
    11531153      </p>
    1154       <p id="rfc.section.2.6.p.5">Here, a "non-error response" is one with a <a href="p2-semantics.html#status.2xx" class="smpl">2xx</a> or <a href="p2-semantics.html#status.3xx" class="smpl">3xx</a> status code. "Invalidate" means that the cache will either remove all stored responses related to the effective request URI,
     1154      <p id="rfc.section.2.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,
    11551155         or will mark these as "invalid" and in need of a mandatory validation before they can be returned in response to a subsequent
    11561156         request.
  • draft-ietf-httpbis/latest/p6-cache.xml

    r1734 r1735  
    683683   If no explicit expiration time is present in a stored response that has a
    684684   status code whose definition allows heuristic freshness to be used
    685    (including the following in &status-codes;: 200, 203, <x:ref>206</x:ref>, 300, 301 and
    686    410), a cache &MAY; calculate a heuristic expiration time. A cache &MUST-NOT;
     685   (including the following in &status-codes;: <x:ref>200 (OK)</x:ref>, <x:ref>203
     686   (Non-Authoritative Information)</x:ref>, <x:ref>206 (Partial Content)</x:ref>,
     687   <x:ref>300 (Multiple Choices)</x:ref>, <x:ref>301 (Moved Permanently)</x:ref> and
     688   <x:ref>410 (Gone)</x:ref>), a cache &MAY; calculate a heuristic expiration time. A cache &MUST-NOT;
    687689   use heuristics to determine freshness for responses with status codes that do
    688690   not explicitly allow it.
     
    923925      </t>
    924926      <t>
    925          However, if a cache receives a 5xx response while attempting to
    926          validate a response, it can either forward this response to the
    927          requesting client, or act as if the server failed to respond. In the
    928          latter case, it can return a previously stored response (see <xref
    929          target="serving.stale.responses" />).
     927         However, if a cache receives a <x:ref>5xx (Server Error)</x:ref>
     928         response while attempting to validate a response, it can either
     929         forward this response to the requesting client, or act as if the
     930         server failed to respond. In the latter case, it can return a
     931         previously stored response (see <xref target="serving.stale.responses" />).
    930932      </t>
    931933   </list>
     
    10331035</t>
    10341036<t>
    1035    Here, a "non-error response" is one with a <x:ref>2xx</x:ref> or <x:ref>3xx</x:ref> status code.
     1037   Here, a "non-error response" is one with a <x:ref>2xx (Successful)</x:ref> or
     1038   <x:ref>3xx (Redirection)</x:ref> status code.
    10361039   "Invalidate" means that the cache will either remove all stored
    10371040   responses related to the effective request URI, or will mark these as
     
    22942297    <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p2-semantics-&ID-VERSION;" />
    22952298    <x:source basename="p2-semantics" href="p2-semantics.xml">
    2296       <x:defines>2xx</x:defines>
     2299      <x:defines>2xx (Successful)</x:defines>
    22972300      <x:defines>200 (OK)</x:defines>
    2298       <x:defines>3xx</x:defines>
     2301      <x:defines>203 (Non-Authoritative Information)</x:defines>
     2302      <x:defines>3xx (Redirection)</x:defines>
     2303      <x:defines>300 (Multiple Choices)</x:defines>
     2304      <x:defines>301 (Moved Permanently)</x:defines>
    22992305      <x:defines>404 (Not Found)</x:defines>
     2306      <x:defines>410 (Gone)</x:defines>
     2307      <x:defines>5xx (Server Error)</x:defines>
    23002308      <x:defines>504 (Gateway Timeout)</x:defines>
    23012309    </x:source>
     
    23452353    <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p5-range-&ID-VERSION;" />
    23462354    <x:source basename="p5-range" href="p5-range.xml">
    2347       <x:defines>206</x:defines>
    23482355      <x:defines>206 (Partial Content)</x:defines>
    23492356    </x:source>
  • draft-ietf-httpbis/latest/p7-auth.html

    r1725 r1735  
    449449  }
    450450  @bottom-center {
    451        content: "Expires January 6, 2013";
     451       content: "Expires January 7, 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-07-05">
     491      <meta name="dct.issued" scheme="ISO8601" content="2012-07-06">
    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. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 7 of the seven-part specification that defines the protocol referred to as &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 7 defines the HTTP Authentication framework.">
     
    520520            </tr>
    521521            <tr>
    522                <td class="left">Expires: January 6, 2013</td>
     522               <td class="left">Expires: January 7, 2013</td>
    523523               <td class="right">greenbytes</td>
    524524            </tr>
    525525            <tr>
    526526               <td class="left"></td>
    527                <td class="right">July 5, 2012</td>
     527               <td class="right">July 6, 2012</td>
    528528            </tr>
    529529         </tbody>
     
    553553         in progress”.
    554554      </p>
    555       <p>This Internet-Draft will expire on January 6, 2013.</p>
     555      <p>This Internet-Draft will expire on January 7, 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>
Note: See TracChangeset for help on using the changeset viewer.