Changeset 1496

Timestamp:

Dec 20, 2011, 2:40:00 AM (8 years ago)

Author:

julian.reschke@…

Message:

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

Location:

draft-ietf-httpbis/latest

Files:

• p2-semantics.html (modified) (8 diffs)
• p2-semantics.xml (modified) (2 diffs)

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

@@ -359 +359 @@
   } 
   @bottom-center {
-       content: "Expires June 20, 2012"; 
+       content: "Expires June 22, 2012"; 
   } 
   @bottom-right {
@@ -411 +411 @@
       <meta name="dct.creator" content="Reschke, J. F.">
       <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p2-semantics-latest">
-      <meta name="dct.issued" scheme="ISO8601" content="2011-12-18">
+      <meta name="dct.issued" scheme="ISO8601" content="2011-12-20">
       <meta name="dct.replaces" content="urn:ietf:rfc:2616">
       <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.">
@@ -442 +442 @@
             </tr>
             <tr>
-               <td class="left">Expires: June 20, 2012</td>
+               <td class="left">Expires: June 22, 2012</td>
                <td class="right">HP</td>
             </tr>
@@ -495 +495 @@
             <tr>
                <td class="left"></td>
-               <td class="right">December 18, 2011</td>
+               <td class="right">December 20, 2011</td>
             </tr>
          </tbody>
@@ -525 +525 @@
          in progress”.
       </p>
-      <p>This Internet-Draft will expire on June 20, 2012.</p>
+      <p>This Internet-Draft will expire on June 22, 2012.</p>
       <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
       <p>Copyright © 2011 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
@@ -2293 +2293 @@
       <p>Examples are:</p>  <pre class="text">  Location: http://www.example.org/pub/WWW/People.html#tim
 </pre><div id="rfc.figure.u.25"></div><pre class="text">  Location: /index.html
-</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
+</pre><div class="note" id="rfc.section.9.5.p.7"> 
+         <p> <b>Note:</b> Some recipients attempt to recover from Location fields that are not valid URI references. This specification does not mandate
+            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>).
+         </p> 
+      </div>
+      <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
          in a 201 Created response, where the Location header field specifies the URI for the entire created resource.
       </p>
-      <div class="note" id="rfc.section.9.5.p.8"> 
+      <div class="note" id="rfc.section.9.5.p.9"> 
          <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,
             and the Location header field value both contain fragment identifiers. Thus be aware that including fragment identifiers might
@@ -2302 +2307 @@
          </p> 
       </div>
-      <div class="note" id="rfc.section.9.5.p.9"> 
+      <div class="note" id="rfc.section.9.5.p.10"> 
          <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.
             It is therefore possible for a response to contain header fields for both Location and Content-Location.
@@ -3411 +3416 @@
       <p id="rfc.section.C.19.p.1">Closed issues: </p>
       <ul>
+         <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"
+         </li>
          <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)
          </li>

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

@@ -2709 +2709 @@
 </artwork></figure><figure><artwork type="example">  Location: /index.html
 </artwork></figure>
+<x:note>
+  <t>
+    <x:h>Note:</x:h> Some recipients attempt to recover from Location fields
+    that are not valid URI references. This specification does not mandate or
+    define such processing, but does allow it (see <xref target="intro.conformance.and.error.handling"/>).
+  </t>
+</x:note>
 <t>
    There are circumstances in which a fragment identifier in a Location URI
@@ -4712 +4719 @@
   <list style="symbols"> 
     <t>
+      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/185"/>:
+      "Location header payload handling"
+    </t>
+    <t>
       <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/255"/>:
       "Clarify status code for rate limiting" (change backed out because