20/12/11 10:40:00 (10 years ago)

Note that some recipients are lax in processing the Location header field (see #185)

1 edited


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

    r1495 r1496  
    359359  }
    360360  @bottom-center {
    361        content: "Expires June 20, 2012";
     361       content: "Expires June 22, 2012";
    362362  }
    363363  @bottom-right {
    411411      <meta name="dct.creator" content="Reschke, J. F.">
    412412      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p2-semantics-latest">
    413       <meta name="dct.issued" scheme="ISO8601" content="2011-12-18">
     413      <meta name="dct.issued" scheme="ISO8601" content="2011-12-20">
    414414      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    415415      <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 2 of the seven-part specification that defines the protocol referred to as &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 2 defines the semantics of HTTP messages as expressed by request methods, request header fields, response status codes, and response header fields.">
    442442            </tr>
    443443            <tr>
    444                <td class="left">Expires: June 20, 2012</td>
     444               <td class="left">Expires: June 22, 2012</td>
    445445               <td class="right">HP</td>
    446446            </tr>
    495495            <tr>
    496496               <td class="left"></td>
    497                <td class="right">December 18, 2011</td>
     497               <td class="right">December 20, 2011</td>
    498498            </tr>
    499499         </tbody>
    525525         in progress”.
    526526      </p>
    527       <p>This Internet-Draft will expire on June 20, 2012.</p>
     527      <p>This Internet-Draft will expire on June 22, 2012.</p>
    528528      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    529529      <p>Copyright © 2011 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
    22932293      <p>Examples are:</p>  <pre class="text">  Location: http://www.example.org/pub/WWW/People.html#tim
    22942294</pre><div id="rfc.figure.u.25"></div><pre class="text">  Location: /index.html
    2295 </pre><p id="rfc.section.9.5.p.7">There are circumstances in which a fragment identifier in a Location URI would not be appropriate. For instance, when it appears
     2295</pre><div class="note" id="rfc.section.9.5.p.7">
     2296         <p> <b>Note:</b> Some recipients attempt to recover from Location fields that are not valid URI references. This specification does not mandate
     2297            or define such processing, but does allow it (see <a href="#intro.conformance.and.error.handling" title="Conformance and Error Handling">Section&nbsp;1.1</a>).
     2298         </p>
     2299      </div>
     2300      <p id="rfc.section.9.5.p.8">There are circumstances in which a fragment identifier in a Location URI would not be appropriate. For instance, when it appears
    22962301         in a 201 Created response, where the Location header field specifies the URI for the entire created resource.
    22972302      </p>
    2298       <div class="note" id="rfc.section.9.5.p.8">
     2303      <div class="note" id="rfc.section.9.5.p.9">
    22992304         <p> <b>Note:</b> This specification does not define precedence rules for the case where the original URI, as navigated to by the user agent,
    23002305            and the Location header field value both contain fragment identifiers. Thus be aware that including fragment identifiers might
    23022307         </p>
    23032308      </div>
    2304       <div class="note" id="rfc.section.9.5.p.9">
     2309      <div class="note" id="rfc.section.9.5.p.10">
    23052310         <p> <b>Note:</b> The Content-Location header field (<a href="p3-payload.html#header.content-location" title="Content-Location">Section 6.7</a> of <a href="#Part3" id="rfc.xref.Part3.12"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>) differs from Location in that the Content-Location identifies the most specific resource corresponding to the enclosed representation.
    23062311            It is therefore possible for a response to contain header fields for both Location and Content-Location.
    34113416      <p id="rfc.section.C.19.p.1">Closed issues: </p>
    34123417      <ul>
     3418         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/185">http://tools.ietf.org/wg/httpbis/trac/ticket/185</a>&gt;: "Location header payload handling"
     3419         </li>
    34133420         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/255">http://tools.ietf.org/wg/httpbis/trac/ticket/255</a>&gt;: "Clarify status code for rate limiting" (change backed out because a new status code is being defined for this purpose)
    34143421         </li>
Note: See TracChangeset for help on using the changeset viewer.