Changeset 535

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:

• p6-cache.html (modified) (2 diffs)
• p6-cache.xml (modified) (2 diffs)

draft-ietf-httpbis/latest-roy/p6-cache.html

@@ -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
             by no more than the specified number of seconds. If no value is assigned to max-stale, then the client is willing to accept
-            a stale response of any age. <span class="comment">[rfc.comment.15: of any staleness? -- mnot]</span></dd>
+            a stale response of any age. <span class="comment">[rfc.comment.15: of any staleness? --mnot]</span></dd>
       </dl>
       <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
          for transfer encoding that may not be self delimiting); it was important to straighten out exactly how message lengths are
-         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>)
-      </p>
-      <p id="rfc.section.A.1.p.3">Proxies should be able to add Content-Length when appropriate.</p>
+         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> 
+      </p>
+      <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> 
+      </p>
       <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
          needed headers in a 206 response, this problem can be avoided. (<a href="#combining.headers" title="Combining Responses">Section&nbsp;2.7</a>)
       </p>
-      <p id="rfc.section.A.1.p.5">The Cache-Control: max-age directive was not properly defined for responses.</p>
+      <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>)
+      </p>
       <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.
       </p>

draft-ietf-httpbis/latest-roy/p6-cache.xml

@@ -867 +867 @@
                 then the client is willing to accept a response that has exceeded its expiration
                 time by no more than the specified number of seconds. If no value is assigned to
-                max-stale, then the client is willing to accept a stale response of any age. <cref>of any staleness? -- mnot </cref></t>
+                max-stale, then the client is willing to accept a stale response of any age. <cref source="mnot">of any staleness?</cref></t>
             </list>
           </t>
@@ -1814 +1814 @@
           when chunked encoding is used (to allow for transfer encoding that may not be self
           delimiting); it was important to straighten out exactly how message lengths are computed.
-          (see also <xref target="Part1" />, <xref target="Part3" /> and <xref target="Part5" />)</t>
-        <t>Proxies should be able to add Content-Length when appropriate.</t>
+          (see also <xref target="Part1" />, <xref target="Part3" /> and <xref target="Part5" />)
+          <cref source="jre">This used to refer to the text about non-modifiable headers, and will have to be updated later on.</cref>
+          </t>
+        <t>Proxies should be able to add Content-Length when appropriate.
+          <cref source="jre">This used to refer to the text about non-modifiable headers, and will have to be updated later on.</cref>
+        </t>
         <t>Range request responses would become very verbose if all meta-data were always returned;
           by allowing the server to only send needed headers in a 206 response, this problem can be
           avoided. (<xref target="combining.headers" />)</t>
-        <t>The Cache-Control: max-age directive was not properly defined for responses.</t>
+        <t>The Cache-Control: max-age directive was not properly defined for responses. (<xref target="cache-response-directive"/>)</t>
         <t>Warnings could be cached incorrectly, or not updated appropriately. (Section <xref
             format="counter" target="expiration.model" />, <xref format="counter"