Changeset 535
- Timestamp:
- 05/03/09 13:21:09 (13 years ago)
- Location:
- draft-ietf-httpbis/latest-roy
- Files:
-
- 2 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest-roy/p6-cache.html
r534 r535 1020 1020 time. If max-stale is assigned a value, then the client is willing to accept a response that has exceeded its expiration time 1021 1021 by no more than the specified number of seconds. If no value is assigned to max-stale, then the client is willing to accept 1022 a stale response of any age. <span class="comment">[rfc.comment.15: of any staleness? -- 1022 a stale response of any age. <span class="comment">[rfc.comment.15: of any staleness? --mnot]</span></dd> 1023 1023 </dl> 1024 1024 <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 … … 1523 1523 <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 1524 1524 for transfer encoding that may not be self delimiting); it was important to straighten out exactly how message lengths are 1525 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>) 1526 </p> 1527 <p id="rfc.section.A.1.p.3">Proxies should be able to add Content-Length when appropriate.</p> 1525 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">[rfc.comment.16: This used to refer to the text about non-modifiable headers, and will have to be updated later on. --jre]</span> 1526 </p> 1527 <p id="rfc.section.A.1.p.3">Proxies should be able to add Content-Length when appropriate. <span class="comment">[rfc.comment.17: This used to refer to the text about non-modifiable headers, and will have to be updated later on. --jre]</span> 1528 </p> 1528 1529 <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 1529 1530 needed headers in a 206 response, this problem can be avoided. (<a href="#combining.headers" title="Combining Responses">Section 2.7</a>) 1530 1531 </p> 1531 <p id="rfc.section.A.1.p.5">The Cache-Control: max-age directive was not properly defined for responses.</p> 1532 <p id="rfc.section.A.1.p.5">The Cache-Control: max-age directive was not properly defined for responses. (<a href="#cache-response-directive" title="Response Cache-Control Directives">Section 3.2.2</a>) 1533 </p> 1532 1534 <p id="rfc.section.A.1.p.6">Warnings could be cached incorrectly, or not updated appropriately. (Section <a href="#expiration.model" title="Freshness Model">2.3</a>, <a href="#combining.headers" title="Combining Responses">2.7</a>, <a href="#header.cache-control" id="rfc.xref.header.cache-control.7" title="Cache-Control">3.2</a>, and <a href="#header.warning" id="rfc.xref.header.warning.5" title="Warning">3.6</a>) Warning also needed to be a general header, as PUT or other methods may have need for it in requests. 1533 1535 </p> -
draft-ietf-httpbis/latest-roy/p6-cache.xml
r534 r535 867 867 then the client is willing to accept a response that has exceeded its expiration 868 868 time by no more than the specified number of seconds. If no value is assigned to 869 max-stale, then the client is willing to accept a stale response of any age. <cref >of any staleness? -- mnot</cref></t>869 max-stale, then the client is willing to accept a stale response of any age. <cref source="mnot">of any staleness?</cref></t> 870 870 </list> 871 871 </t> … … 1814 1814 when chunked encoding is used (to allow for transfer encoding that may not be self 1815 1815 delimiting); it was important to straighten out exactly how message lengths are computed. 1816 (see also <xref target="Part1" />, <xref target="Part3" /> and <xref target="Part5" />)</t> 1817 <t>Proxies should be able to add Content-Length when appropriate.</t> 1816 (see also <xref target="Part1" />, <xref target="Part3" /> and <xref target="Part5" />) 1817 <cref source="jre">This used to refer to the text about non-modifiable headers, and will have to be updated later on.</cref> 1818 </t> 1819 <t>Proxies should be able to add Content-Length when appropriate. 1820 <cref source="jre">This used to refer to the text about non-modifiable headers, and will have to be updated later on.</cref> 1821 </t> 1818 1822 <t>Range request responses would become very verbose if all meta-data were always returned; 1819 1823 by allowing the server to only send needed headers in a 206 response, this problem can be 1820 1824 avoided. (<xref target="combining.headers" />)</t> 1821 <t>The Cache-Control: max-age directive was not properly defined for responses. </t>1825 <t>The Cache-Control: max-age directive was not properly defined for responses. (<xref target="cache-response-directive"/>)</t> 1822 1826 <t>Warnings could be cached incorrectly, or not updated appropriately. (Section <xref 1823 1827 format="counter" target="expiration.model" />, <xref format="counter"
Note: See TracChangeset
for help on using the changeset viewer.