Changeset 561


Ignore:
Timestamp:
Mar 12, 2009, 5:14:29 AM (11 years ago)
Author:
julian.reschke@…
Message:

Expand the comment about Request-URI not being defined anymore in Part 1.

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

Legend:

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

    r560 r561  
    719719      </p>
    720720      <ul>
    721          <li>The presented Request-URI and that of the stored response match (see <span class="comment" id="rfc.comment.1">[<a href="#rfc.comment.1" class="smpl">rfc.comment.1</a>: TBD]</span>), and
     721         <li>The presented Request-URI and that of the stored response match (<span class="comment" id="TODO-Request-URI">[<a href="#TODO-Request-URI" class="smpl">TODO-Request-URI</a>: Need to find a new term for this, as Part 1 doesn't define Request-URI anymore; the new term request-target does not work
     722               for this.]</span>), and
    722723         </li>
    723724         <li>the request method associated with the stored response allows it to be used for the presented request, and</li>
     
    737738         </li>
    738739      </ul>
    739       <p id="rfc.section.2.2.p.2"> <span class="comment" id="rfc.comment.2">[<a href="#rfc.comment.2" class="smpl">rfc.comment.2</a>: TODO: define method cacheability for GET, HEAD and POST in p2-semantics.]</span>
    740       </p>
    741       <p id="rfc.section.2.2.p.3">When a stored response is used to satisfy a request, caches <em class="bcp14">MUST</em> include a single Age header field <a href="#header.age" id="rfc.xref.header.age.1" title="Age">Section&nbsp;3.1</a> in the response with a value equal to the stored response's current_age; see <a href="#age.calculations" title="Calculating Age">Section&nbsp;2.3.2</a>. <span class="comment" id="rfc.comment.3">[<a href="#rfc.comment.3" class="smpl">rfc.comment.3</a>: DISCUSS: this currently includes successfully validated responses.]</span>
     740      <p id="rfc.section.2.2.p.2"> <span class="comment" id="rfc.comment.1">[<a href="#rfc.comment.1" class="smpl">rfc.comment.1</a>: TODO: define method cacheability for GET, HEAD and POST in p2-semantics.]</span>
     741      </p>
     742      <p id="rfc.section.2.2.p.3">When a stored response is used to satisfy a request, caches <em class="bcp14">MUST</em> include a single Age header field <a href="#header.age" id="rfc.xref.header.age.1" title="Age">Section&nbsp;3.1</a> in the response with a value equal to the stored response's current_age; see <a href="#age.calculations" title="Calculating Age">Section&nbsp;2.3.2</a>. <span class="comment" id="rfc.comment.2">[<a href="#rfc.comment.2" class="smpl">rfc.comment.2</a>: DISCUSS: this currently includes successfully validated responses.]</span>
    742743      </p>
    743744      <p id="rfc.section.2.2.p.4">Requests with methods that are unsafe (<a href="p2-semantics.html#safe.methods" title="Safe Methods">Section 7.1.1</a> of <a href="#Part2" id="rfc.xref.Part2.1"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) <em class="bcp14">MUST</em> be written through the cache to the origin server; i.e., A cache must not reply to such a request before having forwarded
     
    749750         forward a request with "Cache-Control: max-age=0" or "Cache-Control: no-cache" to disambiguate which response to use.
    750751      </p>
    751       <p id="rfc.section.2.2.p.7"> <span class="comment" id="rfc.comment.4">[<a href="#rfc.comment.4" class="smpl">rfc.comment.4</a>: TODO: end-to-end and hop-by-hop headers, non-modifiable headers removed; re-spec in p1]</span>
     752      <p id="rfc.section.2.2.p.7"> <span class="comment" id="rfc.comment.3">[<a href="#rfc.comment.3" class="smpl">rfc.comment.3</a>: TODO: end-to-end and hop-by-hop headers, non-modifiable headers removed; re-spec in p1]</span>
    752753      </p>
    753754      <h2 id="rfc.section.2.3"><a href="#rfc.section.2.3">2.3</a>&nbsp;<a id="expiration.model" href="#expiration.model">Freshness Model</a></h2>
     
    760761      </p>
    761762      <p id="rfc.section.2.3.p.3">If an origin server wishes to force a cache to validate every request, it can assign an explicit expiration time in the past.
    762          This means that the response is always stale, so that caches should validate it before using it for subsequent requests. <span class="comment" id="rfc.comment.5">[<a href="#rfc.comment.5" class="smpl">rfc.comment.5</a>: This wording may cause confusion, because the response may still be served stale.]</span>
     763         This means that the response is always stale, so that caches should validate it before using it for subsequent requests. <span class="comment" id="rfc.comment.4">[<a href="#rfc.comment.4" class="smpl">rfc.comment.4</a>: This wording may cause confusion, because the response may still be served stale.]</span>
    763764      </p>
    764765      <p id="rfc.section.2.3.p.4">Since origin servers do not always provide explicit expiration times, HTTP caches may also assign heuristic expiration times
     
    774775         with the effect of either increasing or loosening constraints on freshness. See <a href="#cache-request-directive" title="Request Cache-Control Directives">Section&nbsp;3.2.1</a>.
    775776      </p>
    776       <p id="rfc.section.2.3.p.8"> <span class="comment" id="rfc.comment.6">[<a href="#rfc.comment.6" class="smpl">rfc.comment.6</a>: ISSUE: there are not requirements directly applying to cache-request-directives and freshness.]</span>
     777      <p id="rfc.section.2.3.p.8"> <span class="comment" id="rfc.comment.5">[<a href="#rfc.comment.5" class="smpl">rfc.comment.5</a>: ISSUE: there are not requirements directly applying to cache-request-directives and freshness.]</span>
    777778      </p>
    778779      <p id="rfc.section.2.3.p.9">Note that freshness applies only to cache operation; it cannot be used to force a user agent to refresh its display or reload
     
    801802      <p id="rfc.section.2.3.1.1.p.3">Also, if the response has a Last-Modified header (<a href="p4-conditional.html#header.last-modified" title="Last-Modified">Section 6.6</a> of <a href="#Part4" id="rfc.xref.Part4.1"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>), the heuristic expiration value <em class="bcp14">SHOULD</em> be no more than some fraction of the interval since that time. A typical setting of this fraction might be 10%.
    802803      </p>
    803       <p id="rfc.section.2.3.1.1.p.4"> <span class="comment" id="rfc.comment.7">[<a href="#rfc.comment.7" class="smpl">rfc.comment.7</a>: REVIEW: took away HTTP/1.0 query string heuristic uncacheability.]</span>
     804      <p id="rfc.section.2.3.1.1.p.4"> <span class="comment" id="rfc.comment.6">[<a href="#rfc.comment.6" class="smpl">rfc.comment.6</a>: REVIEW: took away HTTP/1.0 query string heuristic uncacheability.]</span>
    804805      </p>
    805806      <h3 id="rfc.section.2.3.2"><a href="#rfc.section.2.3.2">2.3.2</a>&nbsp;<a id="age.calculations" href="#age.calculations">Calculating Age</a></h3>
     
    874875      </p>
    875876      <p id="rfc.section.2.4.p.4">If instead the cache receives a full response (i.e., one with a response body), it is used to satisfy the request and replace
    876          the stored response. <span class="comment" id="rfc.comment.8">[<a href="#rfc.comment.8" class="smpl">rfc.comment.8</a>: Should there be a requirement here?]</span>
     877         the stored response. <span class="comment" id="rfc.comment.7">[<a href="#rfc.comment.7" class="smpl">rfc.comment.7</a>: Should there be a requirement here?]</span>
    877878      </p>
    878879      <p id="rfc.section.2.4.p.5">If a cache receives a 5xx response while attempting to validate a response, it <em class="bcp14">MAY</em> either forward this response to the requesting client, or act as if the server failed to respond. In the latter case, it <em class="bcp14">MAY</em> return a previously stored response (which <em class="bcp14">SHOULD</em> include the 111 warn-code; see <a href="#header.warning" id="rfc.xref.header.warning.2" title="Warning">Section&nbsp;3.6</a>) unless the stored response includes the "must-revalidate" cache directive (see <a href="#serving.stale.responses" title="Serving Stale Responses">Section&nbsp;2.3.3</a>).
     
    891892         attacks.
    892893      </p>
    893       <p id="rfc.section.2.5.p.4"> <span class="comment" id="rfc.comment.9">[<a href="#rfc.comment.9" class="smpl">rfc.comment.9</a>: TODO: "host part" needs to be specified better.]</span>
     894      <p id="rfc.section.2.5.p.4"> <span class="comment" id="rfc.comment.8">[<a href="#rfc.comment.8" class="smpl">rfc.comment.8</a>: TODO: "host part" needs to be specified better.]</span>
    894895      </p>
    895896      <p id="rfc.section.2.5.p.5">A cache that passes through requests for methods it does not understand <em class="bcp14">SHOULD</em> invalidate the Request-URI.
     
    901902         change at the origin server might not have gone through the cache where a response is stored.
    902903      </p>
    903       <p id="rfc.section.2.5.p.8"> <span class="comment" id="rfc.comment.10">[<a href="#rfc.comment.10" class="smpl">rfc.comment.10</a>: TODO: specify that only successful (2xx, 3xx?) responses invalidate.]</span>
     904      <p id="rfc.section.2.5.p.8"> <span class="comment" id="rfc.comment.9">[<a href="#rfc.comment.9" class="smpl">rfc.comment.9</a>: TODO: specify that only successful (2xx, 3xx?) responses invalidate.]</span>
    904905      </p>
    905906      <h2 id="rfc.section.2.6"><a href="#rfc.section.2.6">2.6</a>&nbsp;<a id="caching.negotiated.responses" href="#caching.negotiated.responses">Caching Negotiated Responses</a></h2>
     
    910911      </p>
    911912      <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
    912          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.11">[<a href="#rfc.comment.11" class="smpl">rfc.comment.11</a>: [ref]]</span> at places where this is allowed by the corresponding ABNF, and/or combining multiple message-header fields with the same field
    913          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.12">[<a href="#rfc.comment.12" class="smpl">rfc.comment.12</a>: DISCUSS: header-specific canonicalisation]</span>
     913         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.10">[<a href="#rfc.comment.10" class="smpl">rfc.comment.10</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.11">[<a href="#rfc.comment.11" class="smpl">rfc.comment.11</a>: DISCUSS: header-specific canonicalisation]</span>
    914915      </p>
    915916      <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
     
    924925      <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
    925926         same Request-URI, whose entity-tag differs from that of the existing stored response, and whose Date is more recent than that
    926          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.13">[<a href="#rfc.comment.13" class="smpl">rfc.comment.13</a>: DISCUSS: Not sure if this is necessary.]</span>
     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.12">[<a href="#rfc.comment.12" class="smpl">rfc.comment.12</a>: DISCUSS: Not sure if this is necessary.]</span>
    927928      </p>
    928929      <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>
     
    947948         all such old headers <em class="bcp14">MUST</em> be replaced. It <em class="bcp14">MAY</em> store the combined entity-body.
    948949      </p>
    949       <p id="rfc.section.2.7.p.5"> <span class="comment" id="rfc.comment.14">[<a href="#rfc.comment.14" class="smpl">rfc.comment.14</a>: ISSUE: discuss how to handle HEAD updates]</span>
     950      <p id="rfc.section.2.7.p.5"> <span class="comment" id="rfc.comment.13">[<a href="#rfc.comment.13" class="smpl">rfc.comment.13</a>: ISSUE: discuss how to handle HEAD updates]</span>
    950951      </p>
    951952      <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>
     
    10331034            time. If max-stale is assigned a value, then the client is willing to accept a response that has exceeded its expiration time
    10341035            by no more than the specified number of seconds. If no value is assigned to max-stale, then the client is willing to accept
    1035             a stale response of any age. <span class="comment" id="rfc.comment.15">[<a href="#rfc.comment.15" class="smpl">rfc.comment.15</a>: of any staleness? --mnot]</span></dd>
     1036            a stale response of any age. <span class="comment" id="rfc.comment.14">[<a href="#rfc.comment.14" class="smpl">rfc.comment.14</a>: of any staleness? --mnot]</span></dd>
    10361037      </dl>
    10371038      <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
     
    15341535      <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
    15351536         for transfer encoding that may not be self delimiting); it was important to straighten out exactly how message lengths are
    1536          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.16">[<a href="#rfc.comment.16" class="smpl">rfc.comment.16</a>: This used to refer to the text about non-modifiable headers, and will have to be updated later on. --jre]</span>
    1537       </p>
    1538       <p id="rfc.section.A.1.p.3">Proxies should be able to add Content-Length when appropriate. <span class="comment" id="rfc.comment.17">[<a href="#rfc.comment.17" class="smpl">rfc.comment.17</a>: This used to refer to the text about non-modifiable headers, and will have to be updated later on. --jre]</span>
     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.15">[<a href="#rfc.comment.15" class="smpl">rfc.comment.15</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.16">[<a href="#rfc.comment.16" class="smpl">rfc.comment.16</a>: This used to refer to the text about non-modifiable headers, and will have to be updated later on. --jre]</span>
    15391540      </p>
    15401541      <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

    r555 r561  
    455455For a presented request, a cache &MUST-NOT; return a stored response, unless:
    456456  <list style="symbols">
    457     <t>The presented Request-URI and that of the stored response match (see
    458       <cref>TBD</cref>), and</t>
     457    <t>The presented Request-URI and that of the stored response match
     458      (<cref anchor="TODO-Request-URI">Need to find a new term for this, as Part
     459      1 doesn't define Request-URI anymore; the new term request-target does not
     460      work for this.</cref>), and</t>
    459461    <t>the request method associated with the stored response allows it to be
    460462      used for the presented request, and</t>
Note: See TracChangeset for help on using the changeset viewer.