Changeset 535


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

re-sync Changes from 2068: add TODOs

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

Legend:

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

    r534 r535  
    10201020            time. If max-stale is assigned a value, then the client is willing to accept a response that has exceeded its expiration time
    10211021            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? -- mnot]</span></dd>
     1022            a stale response of any age. <span class="comment">[rfc.comment.15: of any staleness? --mnot]</span></dd>
    10231023      </dl>
    10241024      <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
     
    15231523      <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
    15241524         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>
    15281529      <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
    15291530         needed headers in a 206 response, this problem can be avoided. (<a href="#combining.headers" title="Combining Responses">Section&nbsp;2.7</a>)
    15301531      </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&nbsp;3.2.2</a>)
     1533      </p>
    15321534      <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.
    15331535      </p>
  • draft-ietf-httpbis/latest-roy/p6-cache.xml

    r534 r535  
    867867                then the client is willing to accept a response that has exceeded its expiration
    868868                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>
    870870            </list>
    871871          </t>
     
    18141814          when chunked encoding is used (to allow for transfer encoding that may not be self
    18151815          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>
    18181822        <t>Range request responses would become very verbose if all meta-data were always returned;
    18191823          by allowing the server to only send needed headers in a 206 response, this problem can be
    18201824          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>
    18221826        <t>Warnings could be cached incorrectly, or not updated appropriately. (Section <xref
    18231827            format="counter" target="expiration.model" />, <xref format="counter"
Note: See TracChangeset for help on using the changeset viewer.