Changeset 567

Timestamp:

30/03/09 11:29:42 (13 years ago)

Author:

julian.reschke@…

Message:

expand header canon. issue and link to newly raised issue

Location:

draft-ietf-httpbis/latest

Files:

• p6-cache.html (modified) (6 diffs)
• p6-cache.xml (modified) (1 diff)

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

@@ -468 +468 @@
          <tr>
             <td class="header left"></td>
-            <td class="header right">March 27, 2009</td>
+            <td class="header right">March 30, 2009</td>
          </tr>
       </table>
@@ -912 +912 @@
       <p id="rfc.section.2.6.p.3">The selecting request-headers from two requests are defined to match if and only if the selecting request-headers in the first
          request can be transformed to the selecting request-headers in the second request by adding or removing linear white space <span class="comment" id="rfc.comment.8">[<a href="#rfc.comment.8" class="smpl">rfc.comment.8</a>: [ref]]</span> at places where this is allowed by the corresponding ABNF, and/or combining multiple message-header fields with the same field
-         name following the rules about message headers in <a href="p1-messaging.html#message.headers" title="Message Headers">Section 4.2</a> of <a href="#Part1" id="rfc.xref.Part1.12"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. <span class="comment" id="rfc.comment.9">[<a href="#rfc.comment.9" class="smpl">rfc.comment.9</a>: DISCUSS: header-specific canonicalisation]</span> 
+         name following the rules about message headers in <a href="p1-messaging.html#message.headers" title="Message Headers">Section 4.2</a> of <a href="#Part1" id="rfc.xref.Part1.12"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. <span class="comment" id="DISCUSS-header-specific-canonicalization">[<a href="#DISCUSS-header-specific-canonicalization" class="smpl">DISCUSS-header-specific-canonicalization</a>: Should the matching requirement be relaxed so that it would be ok to use a cached response if the selecting request headers
+            match after header-specific canonicalization? (see <a href="http://trac.tools.ietf.org/wg/httpbis/trac/ticket/147">Issue 147</a>)]</span> 
       </p>
       <p id="rfc.section.2.6.p.4">A Vary header field-value of "*" always fails to match, and subsequent requests to that resource can only be properly interpreted
@@ -925 +926 @@
       <p id="rfc.section.2.6.p.7">If a cache receives a successful response whose Content-Location field matches that of an existing stored response for the
          same Request-URI, whose entity-tag differs from that of the existing stored response, and whose Date is more recent than that
-         of the existing response, the existing response <em class="bcp14">SHOULD NOT</em> be returned in response to future requests and <em class="bcp14">SHOULD</em> be deleted from the cache.<span class="comment" id="rfc.comment.10">[<a href="#rfc.comment.10" class="smpl">rfc.comment.10</a>: DISCUSS: Not sure if this is necessary.]</span> 
+         of the existing response, the existing response <em class="bcp14">SHOULD NOT</em> be returned in response to future requests and <em class="bcp14">SHOULD</em> be deleted from the cache.<span class="comment" id="rfc.comment.9">[<a href="#rfc.comment.9" class="smpl">rfc.comment.9</a>: DISCUSS: Not sure if this is necessary.]</span> 
       </p>
       <h2 id="rfc.section.2.7"><a href="#rfc.section.2.7">2.7</a>&nbsp;<a id="combining.headers" href="#combining.headers">Combining Responses</a></h2>
@@ -948 +949 @@
          all such old headers <em class="bcp14">MUST</em> be replaced. It <em class="bcp14">MAY</em> store the combined entity-body.
       </p>
-      <p id="rfc.section.2.7.p.5"> <span class="comment" id="rfc.comment.11">[<a href="#rfc.comment.11" class="smpl">rfc.comment.11</a>: ISSUE: discuss how to handle HEAD updates]</span> 
+      <p id="rfc.section.2.7.p.5"> <span class="comment" id="rfc.comment.10">[<a href="#rfc.comment.10" class="smpl">rfc.comment.10</a>: ISSUE: discuss how to handle HEAD updates]</span> 
       </p>
       <h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a>&nbsp;<a id="header.fields" href="#header.fields">Header Field Definitions</a></h1>
@@ -1034 +1035 @@
             time. If max-stale is assigned a value, then the client is willing to accept a response that has exceeded its expiration time
             by no more than the specified number of seconds. If no value is assigned to max-stale, then the client is willing to accept
-            a stale response of any age. <span class="comment" id="rfc.comment.12">[<a href="#rfc.comment.12" class="smpl">rfc.comment.12</a>: of any staleness? --mnot]</span></dd>
+            a stale response of any age. <span class="comment" id="rfc.comment.11">[<a href="#rfc.comment.11" class="smpl">rfc.comment.11</a>: of any staleness? --mnot]</span></dd>
       </dl>
       <p id="rfc.section.3.2.1.p.6"> <span id="rfc.iref.c.8"></span>  <span id="rfc.iref.m.3"></span> min-fresh 
@@ -1535 +1536 @@
       <p id="rfc.section.A.1.p.2">Transfer-coding and message lengths all interact in ways that required fixing exactly when chunked encoding is used (to allow
          for transfer encoding that may not be self delimiting); it was important to straighten out exactly how message lengths are
-         computed. (see also <a href="#Part1" id="rfc.xref.Part1.14"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="#Part3" id="rfc.xref.Part3.2"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a> and <a href="#Part5" id="rfc.xref.Part5.4"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>) <span class="comment" id="rfc.comment.13">[<a href="#rfc.comment.13" class="smpl">rfc.comment.13</a>: This used to refer to the text about non-modifiable headers, and will have to be updated later on. --jre]</span> 
-      </p>
-      <p id="rfc.section.A.1.p.3">Proxies should be able to add Content-Length when appropriate. <span class="comment" id="rfc.comment.14">[<a href="#rfc.comment.14" class="smpl">rfc.comment.14</a>: This used to refer to the text about non-modifiable headers, and will have to be updated later on. --jre]</span> 
+         computed. (see also <a href="#Part1" id="rfc.xref.Part1.14"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="#Part3" id="rfc.xref.Part3.2"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a> and <a href="#Part5" id="rfc.xref.Part5.4"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>) <span class="comment" id="rfc.comment.12">[<a href="#rfc.comment.12" class="smpl">rfc.comment.12</a>: This used to refer to the text about non-modifiable headers, and will have to be updated later on. --jre]</span> 
+      </p>
+      <p id="rfc.section.A.1.p.3">Proxies should be able to add Content-Length when appropriate. <span class="comment" id="rfc.comment.13">[<a href="#rfc.comment.13" class="smpl">rfc.comment.13</a>: This used to refer to the text about non-modifiable headers, and will have to be updated later on. --jre]</span> 
       </p>
       <p id="rfc.section.A.1.p.4">Range request responses would become very verbose if all meta-data were always returned; by allowing the server to only send

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

@@ -797 +797 @@
   <cref>[ref]</cref> at places where this is allowed by the corresponding ABNF, and/or
   combining multiple message-header fields with the same field name following the rules
-  about message headers in &message-headers;. <cref>DISCUSS: header-specific canonicalisation</cref>
+  about message headers in &message-headers;. <cref anchor="DISCUSS-header-specific-canonicalization">
+  Should the matching requirement be relaxed so that it would be ok to use a cached response
+  if the selecting request headers match after header-specific canonicalization?
+  (see <eref target="http://trac.tools.ietf.org/wg/httpbis/trac/ticket/147">Issue 147</eref>)
+  </cref>
 </t>
 <t>