Changeset 567


Ignore:
Timestamp:
Mar 30, 2009, 4:29:42 AM (11 years ago)
Author:
julian.reschke@…
Message:

expand header canon. issue and link to newly raised issue

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

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpbis/latest/p6-cache.html

    r566 r567  
    468468         <tr>
    469469            <td class="header left"></td>
    470             <td class="header right">March 27, 2009</td>
     470            <td class="header right">March 30, 2009</td>
    471471         </tr>
    472472      </table>
     
    912912      <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
    913913         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
    914          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>
     914         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
     915            match after header-specific canonicalization? (see <a href="http://trac.tools.ietf.org/wg/httpbis/trac/ticket/147">Issue 147</a>)]</span>
    915916      </p>
    916917      <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
     
    925926      <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
    926927         same Request-URI, whose entity-tag differs from that of the existing stored response, and whose Date is more recent than that
    927          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>
     928         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>
    928929      </p>
    929930      <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>
     
    948949         all such old headers <em class="bcp14">MUST</em> be replaced. It <em class="bcp14">MAY</em> store the combined entity-body.
    949950      </p>
    950       <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>
     951      <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>
    951952      </p>
    952953      <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>
     
    10341035            time. If max-stale is assigned a value, then the client is willing to accept a response that has exceeded its expiration time
    10351036            by no more than the specified number of seconds. If no value is assigned to max-stale, then the client is willing to accept
    1036             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>
     1037            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>
    10371038      </dl>
    10381039      <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
     
    15351536      <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
    15361537         for transfer encoding that may not be self delimiting); it was important to straighten out exactly how message lengths are
    1537          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>
    1538       </p>
    1539       <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>
     1538         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>
     1539      </p>
     1540      <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>
    15401541      </p>
    15411542      <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

    r562 r567  
    797797  <cref>[ref]</cref> at places where this is allowed by the corresponding ABNF, and/or
    798798  combining multiple message-header fields with the same field name following the rules
    799   about message headers in &message-headers;. <cref>DISCUSS: header-specific canonicalisation</cref>
     799  about message headers in &message-headers;. <cref anchor="DISCUSS-header-specific-canonicalization">
     800  Should the matching requirement be relaxed so that it would be ok to use a cached response
     801  if the selecting request headers match after header-specific canonicalization?
     802  (see <eref target="http://trac.tools.ietf.org/wg/httpbis/trac/ticket/147">Issue 147</eref>)
     803  </cref>
    800804</t>
    801805<t>
Note: See TracChangeset for help on using the changeset viewer.