Changeset 767 for draft-ietf-httpbis/latest/p6-cache.xml
- Timestamp:
- 03/03/10 16:14:02 (12 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p6-cache.xml
r766 r767 506 506 single Age header field (<xref target="header.age" />) in the response with a value equal to the stored response's 507 507 current_age; see <xref target="age.calculations" />. 508 <cref >DISCUSS:this currently includes successfully validated responses.</cref>508 <cref anchor="DISCUSS-includes-validated">this currently includes successfully validated responses.</cref> 509 509 </t> 510 510 <t> … … 545 545 assign an explicit expiration time in the past. This means that the response is always 546 546 stale, so that caches should validate it before using it for subsequent requests. 547 <cref >This wording may cause confusion, because the response may still be served stale.</cref>547 <cref anchor="TODO-response-stale">This wording may cause confusion, because the response may still be served stale.</cref> 548 548 </t> 549 549 <t> … … 573 573 </t> 574 574 <t> 575 <cref >ISSUE:there are not requirements directly applying to cache-request-directives and575 <cref anchor="ISSUE-no-req-for-directives">there are not requirements directly applying to cache-request-directives and 576 576 freshness.</cref> 577 577 </t> … … 619 619 </t> 620 620 <t> 621 <cref >REVIEW:took away HTTP/1.0 query string heuristic uncacheability.</cref>621 <cref anchor="REVIEW-query-string-heuristics">took away HTTP/1.0 query string heuristic uncacheability.</cref> 622 622 </t> 623 623 </section> … … 763 763 of the stored responses nominated in the conditional request is 764 764 suitable. Instead, the full response is used both to satisfy the 765 request and replace the stored response. <cref >Should there be a requirement here?</cref>765 request and replace the stored response. <cref anchor="TODO-req-missing">Should there be a requirement here?</cref> 766 766 </t> 767 767 <t> … … 794 794 </t> 795 795 <t> 796 <cref >TODO:"host part" needs to be specified better.</cref>796 <cref anchor="TODO-def-host-part">"host part" needs to be specified better.</cref> 797 797 </t> 798 798 <t> … … 811 811 </t> 812 812 <t> 813 <cref >TODO:specify that only successful (2xx, 3xx?) responses invalidate.</cref>813 <cref anchor="TODO-spec-success-invalidate">specify that only successful (2xx, 3xx?) responses invalidate.</cref> 814 814 </t> 815 815 </section> … … 827 827 selecting request-headers in the first request can be transformed to the selecting 828 828 request-headers in the second request by adding or removing linear white space 829 <cref >[ref]</cref> at places where this is allowed by the corresponding ABNF, and/or829 <cref anchor="TODO-missing-ref">[ref]</cref> at places where this is allowed by the corresponding ABNF, and/or 830 830 combining multiple message-header fields with the same field name following the rules 831 831 about header fields in &header-fields;. … … 857 857 <t> 858 858 If the new response contains an ETag, it identifies the stored 859 response to use. <cref >may need language about Content-Location860 here</cref><cref >cover case where INM with multiple etags was sent</cref>859 response to use. <cref anchor="TODO-mention-CL">may need language about Content-Location 860 here</cref><cref anchor="TODO-inm-mult-etags">cover case where INM with multiple etags was sent</cref> 861 861 </t> 862 862 <t> … … 882 882 </t> 883 883 <t> 884 The updated response can [[<cref>requirement?</cref>]]be used to replace the884 The updated response can <cref anchor="TODO-is-req">requirement?</cref> be used to replace the 885 885 stored response in cache. In the case of a 206 response, the combined 886 886 entity-body &MAY; be stored. 887 887 </t> 888 888 <t> 889 <cref >ISSUE:discuss how to handle HEAD updates</cref>889 <cref anchor="ISSUE-how-head">discuss how to handle HEAD updates</cref> 890 890 </t> 891 891 </section> … … 1037 1037 then the client is willing to accept a response that has exceeded its expiration 1038 1038 time by no more than the specified number of seconds. If no value is assigned to 1039 max-stale, then the client is willing to accept a stale response of any age. <cref source="mnot">of any staleness?</cref></t>1039 max-stale, then the client is willing to accept a stale response of any age. <cref anchor="TODO-staleness" source="mnot">of any staleness?</cref></t> 1040 1040 </list> 1041 1041 </t> … … 2032 2032 delimiting); it was important to straighten out exactly how message lengths are computed. 2033 2033 (see also <xref target="Part1" />, <xref target="Part3" /> and <xref target="Part5" />) 2034 <cref source="jre">This used to refer to the text about non-modifiable headers, and will have to be updated later on.</cref>2034 <cref anchor="TODO-nonmod" source="jre">This used to refer to the text about non-modifiable headers, and will have to be updated later on.</cref> 2035 2035 </t> 2036 2036 <t> 2037 2037 Proxies should be able to add Content-Length when appropriate. 2038 <cref source="jre">This used to refer to the text about non-modifiable headers, and will have to be updated later on.</cref>2038 <cref anchor="TODO-nonmod2" source="jre">This used to refer to the text about non-modifiable headers, and will have to be updated later on.</cref> 2039 2039 </t> 2040 2040 <t
Note: See TracChangeset
for help on using the changeset viewer.