Ignore:
Timestamp:
Mar 3, 2010, 8:14:02 AM (10 years ago)
Author:
julian.reschke@…
Message:

assign stable anchors to all <cref> elements

File:
1 edited

Legend:

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

    r766 r767  
    781781      <p id="rfc.section.2.2.p.2"> <span class="comment" id="TODO-method-cacheability">[<a href="#TODO-method-cacheability" class="smpl">TODO-method-cacheability</a>: define method cacheability for GET, HEAD and POST in p2-semantics.]</span>
    782782      </p>
    783       <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.1">[<a href="#rfc.comment.1" class="smpl">rfc.comment.1</a>: DISCUSS: this currently includes successfully validated responses.]</span>
     783      <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="DISCUSS-includes-validated">[<a href="#DISCUSS-includes-validated" class="smpl">DISCUSS-includes-validated</a>: this currently includes successfully validated responses.]</span>
    784784      </p>
    785785      <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
     
    802802      </p>
    803803      <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.
    804          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.2">[<a href="#rfc.comment.2" class="smpl">rfc.comment.2</a>: This wording may cause confusion, because the response may still be served stale.]</span>
     804         This means that the response is always stale, so that caches should validate it before using it for subsequent requests. <span class="comment" id="TODO-response-stale">[<a href="#TODO-response-stale" class="smpl">TODO-response-stale</a>: This wording may cause confusion, because the response may still be served stale.]</span>
    805805      </p>
    806806      <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
     
    816816         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>.
    817817      </p>
    818       <p id="rfc.section.2.3.p.8"> <span class="comment" id="rfc.comment.3">[<a href="#rfc.comment.3" class="smpl">rfc.comment.3</a>: ISSUE: there are not requirements directly applying to cache-request-directives and freshness.]</span>
     818      <p id="rfc.section.2.3.p.8"> <span class="comment" id="ISSUE-no-req-for-directives">[<a href="#ISSUE-no-req-for-directives" class="smpl">ISSUE-no-req-for-directives</a>: there are not requirements directly applying to cache-request-directives and freshness.]</span>
    819819      </p>
    820820      <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
     
    843843      <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%.
    844844      </p>
    845       <p id="rfc.section.2.3.1.1.p.4"> <span class="comment" id="rfc.comment.4">[<a href="#rfc.comment.4" class="smpl">rfc.comment.4</a>: REVIEW: took away HTTP/1.0 query string heuristic uncacheability.]</span>
     845      <p id="rfc.section.2.3.1.1.p.4"> <span class="comment" id="REVIEW-query-string-heuristics">[<a href="#REVIEW-query-string-heuristics" class="smpl">REVIEW-query-string-heuristics</a>: took away HTTP/1.0 query string heuristic uncacheability.]</span>
    846846      </p>
    847847      <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>
     
    919919      </p>
    920920      <p id="rfc.section.2.4.p.5">A full response (i.e., one with a response body) indicates that none of the stored responses nominated in the conditional
    921          request is suitable. Instead, the full response is used both to satisfy the request and replace the stored response. <span class="comment" id="rfc.comment.5">[<a href="#rfc.comment.5" class="smpl">rfc.comment.5</a>: Should there be a requirement here?]</span>
     921         request is suitable. Instead, the full response is used both to satisfy the request and replace the stored response. <span class="comment" id="TODO-req-missing">[<a href="#TODO-req-missing" class="smpl">TODO-req-missing</a>: Should there be a requirement here?]</span>
    922922      </p>
    923923      <p id="rfc.section.2.4.p.6">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 (see <a href="#serving.stale.responses" title="Serving Stale Responses">Section&nbsp;2.3.3</a>).
     
    936936         attacks.
    937937      </p>
    938       <p id="rfc.section.2.5.p.4"> <span class="comment" id="rfc.comment.6">[<a href="#rfc.comment.6" class="smpl">rfc.comment.6</a>: TODO: "host part" needs to be specified better.]</span>
     938      <p id="rfc.section.2.5.p.4"> <span class="comment" id="TODO-def-host-part">[<a href="#TODO-def-host-part" class="smpl">TODO-def-host-part</a>: "host part" needs to be specified better.]</span>
    939939      </p>
    940940      <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.
     
    946946         change at the origin server might not have gone through the cache where a response is stored.
    947947      </p>
    948       <p id="rfc.section.2.5.p.8"> <span class="comment" id="rfc.comment.7">[<a href="#rfc.comment.7" class="smpl">rfc.comment.7</a>: TODO: specify that only successful (2xx, 3xx?) responses invalidate.]</span>
     948      <p id="rfc.section.2.5.p.8"> <span class="comment" id="TODO-spec-success-invalidate">[<a href="#TODO-spec-success-invalidate" class="smpl">TODO-spec-success-invalidate</a>: specify that only successful (2xx, 3xx?) responses invalidate.]</span>
    949949      </p>
    950950      <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>
     
    953953      </p>
    954954      <p id="rfc.section.2.6.p.2">The selecting request-headers from two requests are defined to match if and only if the selecting request-headers in the first
    955          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
     955         request can be transformed to the selecting request-headers in the second request by adding or removing linear white space <span class="comment" id="TODO-missing-ref">[<a href="#TODO-missing-ref" class="smpl">TODO-missing-ref</a>: [ref]]</span> at places where this is allowed by the corresponding ABNF, and/or combining multiple message-header fields with the same field
    956956         name following the rules about header fields in <a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.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>.
    957957      </p>
     
    968968         be used to satisfy the request.
    969969      </p>
    970       <p id="rfc.section.2.7.p.2">If the new response contains an ETag, it identifies the stored response to use. <span class="comment" id="rfc.comment.9">[<a href="#rfc.comment.9" class="smpl">rfc.comment.9</a>: may need language about Content-Location here]</span><span class="comment" id="rfc.comment.10">[<a href="#rfc.comment.10" class="smpl">rfc.comment.10</a>: cover case where INM with multiple etags was sent]</span>
     970      <p id="rfc.section.2.7.p.2">If the new response contains an ETag, it identifies the stored response to use. <span class="comment" id="TODO-mention-CL">[<a href="#TODO-mention-CL" class="smpl">TODO-mention-CL</a>: may need language about Content-Location here]</span><span class="comment" id="TODO-inm-mult-etags">[<a href="#TODO-inm-mult-etags" class="smpl">TODO-inm-mult-etags</a>: cover case where INM with multiple etags was sent]</span>
    971971      </p>
    972972      <p id="rfc.section.2.7.p.3">If the status code is 206 (partial content), both the stored and new responses <em class="bcp14">MUST</em> have validators, and those validators <em class="bcp14">MUST</em> match using the strong comparison function (see <a href="p4-conditional.html#weak.and.strong.validators" title="Weak and Strong Validators">Section 4</a> of <a href="#Part4" id="rfc.xref.Part4.3"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>). Otherwise, the responses <em class="bcp14">MUST NOT</em> be combined.
     
    983983      <p id="rfc.section.2.7.p.5">If a header field-name in the new response matches more than one header in the stored response, all such stored headers <em class="bcp14">MUST</em> be replaced.
    984984      </p>
    985       <p id="rfc.section.2.7.p.6">The updated response can [[<span class="comment" id="rfc.comment.11">[<a href="#rfc.comment.11" class="smpl">rfc.comment.11</a>: requirement?]</span>]] be used to replace the stored response in cache. In the case of a 206 response, the combined entity-body <em class="bcp14">MAY</em> be stored.
    986       </p>
    987       <p id="rfc.section.2.7.p.7"> <span class="comment" id="rfc.comment.12">[<a href="#rfc.comment.12" class="smpl">rfc.comment.12</a>: ISSUE: discuss how to handle HEAD updates]</span>
     985      <p id="rfc.section.2.7.p.6">The updated response can <span class="comment" id="TODO-is-req">[<a href="#TODO-is-req" class="smpl">TODO-is-req</a>: requirement?]</span> be used to replace the stored response in cache. In the case of a 206 response, the combined entity-body <em class="bcp14">MAY</em> be stored.
     986      </p>
     987      <p id="rfc.section.2.7.p.7"> <span class="comment" id="ISSUE-how-head">[<a href="#ISSUE-how-head" class="smpl">ISSUE-how-head</a>: discuss how to handle HEAD updates]</span>
    988988      </p>
    989989      <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>
     
    10701070            time. If max-stale is assigned a value, then the client is willing to accept a response that has exceeded its expiration time
    10711071            by no more than the specified number of seconds. If no value is assigned to max-stale, then the client is willing to accept
    1072             a stale response of any age. <span class="comment" id="rfc.comment.13">[<a href="#rfc.comment.13" class="smpl">rfc.comment.13</a>: of any staleness? --mnot]</span></li>
     1072            a stale response of any age. <span class="comment" id="TODO-staleness">[<a href="#TODO-staleness" class="smpl">TODO-staleness</a>: of any staleness? --mnot]</span></li>
    10731073      </ul>
    10741074      <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
     
    15471547      <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
    15481548         for transfer encoding that may not be self delimiting); it was important to straighten out exactly how message lengths are
    1549          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.1"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a> and <a href="#Part5" id="rfc.xref.Part5.3"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>) <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>
    1550       </p>
    1551       <p id="rfc.section.A.1.p.3">Proxies should be able to add Content-Length when appropriate. <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>
     1549         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.1"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a> and <a href="#Part5" id="rfc.xref.Part5.3"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>) <span class="comment" id="TODO-nonmod">[<a href="#TODO-nonmod" class="smpl">TODO-nonmod</a>: This used to refer to the text about non-modifiable headers, and will have to be updated later on. --jre]</span>
     1550      </p>
     1551      <p id="rfc.section.A.1.p.3">Proxies should be able to add Content-Length when appropriate. <span class="comment" id="TODO-nonmod2">[<a href="#TODO-nonmod2" class="smpl">TODO-nonmod2</a>: This used to refer to the text about non-modifiable headers, and will have to be updated later on. --jre]</span>
    15521552      </p>
    15531553      <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
Note: See TracChangeset for help on using the changeset viewer.