Changeset 575 for draft-ietf-httpbis

Timestamp:

06/05/09 06:34:04 (13 years ago)

Author:

julian.reschke@…

Message:

source code cleanup

Location:

draft-ietf-httpbis/latest

Files:

• p6-cache.html (modified) (3 diffs)
• p6-cache.xml (modified) (11 diffs)

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

@@ -468 +468 @@
          <tr>
             <td class="header left"></td>
-            <td class="header right">May 1, 2009</td>
+            <td class="header right">May 6, 2009</td>
          </tr>
       </table>
@@ -1358 +1358 @@
          documents.
       </p>
-      <p id="rfc.section.4.p.4">This is not to be construed to prohibit the history mechanism from telling the user that a view might be stale. </p>
-      <dl class="empty">
-         <dd> <b>Note:</b> if history list mechanisms unnecessarily prevent users from viewing stale resources, this will tend to force service authors
+      <p id="rfc.section.4.p.4">This is not to be construed to prohibit the history mechanism from telling the user that a view might be stale.</p>
+      <div class="note"> 
+         <p> <b>Note:</b> if history list mechanisms unnecessarily prevent users from viewing stale resources, this will tend to force service authors
             to avoid using HTTP expiration controls and cache controls when they would otherwise like to. Service authors may consider
             it important that users not be presented with error messages or warning messages when they use navigation controls (such as
@@ -1366 +1366 @@
             user interface considerations may force service authors to resort to other means of preventing caching (e.g. "once-only" URLs)
             in order not to suffer the effects of improperly functioning history mechanisms.
-         </dd>
-      </dl>
+         </p> 
+      </div>
       <h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a>&nbsp;<a id="IANA.considerations" href="#IANA.considerations">IANA Considerations</a></h1>
       <h2 id="rfc.section.5.1"><a href="#rfc.section.5.1">5.1</a>&nbsp;<a id="message.header.registration" href="#message.header.registration">Message Header Registration</a></h2>

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

@@ -245 +245 @@
 
 <section anchor="intro.terminology" title="Terminology">
-<t
-  >This specification uses a number of terms to refer to the roles played by participants
+<t>
+  This specification uses a number of terms to refer to the roles played by participants
   in, and objects of, HTTP caching.
 </t>
@@ -453 +453 @@
 <section anchor="constructing.responses.from.caches" title="Constructing Responses from Caches">
 <t>
-For a presented request, a cache &MUST-NOT; return a stored response, unless: 
+  For a presented request, a cache &MUST-NOT; return a stored response, unless: 
   <list style="symbols">
     <t>The presented Request-URI and that of the stored response match
@@ -532 +532 @@
 <figure>
 <preamble>
-The calculation to determine if a response is fresh is:
+  The calculation to determine if a response is fresh is:
 </preamble>
 <artwork type="code">
@@ -625 +625 @@
   synchronize their clocks to a globally accurate time standard.
 </t>
-<t>A response's age can be calculated in two entirely independent ways:
+<t>
+  A response's age can be calculated in two entirely independent ways:
   <list style="numbers">
     <t>now minus date_value, if the local clock is reasonably well synchronized to the
@@ -868 +869 @@
 
 <section anchor="header.fields" title="Header Field Definitions">
-<t>This section defines the syntax and semantics of HTTP/1.1 header fields related to caching.</t>
-<t>For entity-header fields, both sender and recipient refer to either the client or the
-server, depending on who sends and who receives the entity.</t>
+<t>
+  This section defines the syntax and semantics of HTTP/1.1 header fields
+  related to caching.
+</t>
+<t>
+  For entity-header fields, both sender and recipient refer to either the client or the
+  server, depending on who sends and who receives the entity.
+</t>
 
 <section anchor="header.age" title="Age">
@@ -924 +930 @@
 </t>
 <x:note>
-  <t>Note that HTTP/1.0 caches might not implement Cache-Control and might only implement
-  Pragma: no-cache (see <xref target="header.pragma" />).</t>
+  <t>
+    Note that HTTP/1.0 caches might not implement Cache-Control and might only implement
+    Pragma: no-cache (see <xref target="header.pragma" />).
+  </t>
 </x:note>
 <t>
@@ -1253 +1261 @@
 </artwork></figure>
 <x:note>
-    <t>
-      <x:h>Note:</x:h> if a response includes a Cache-Control field with the max-age
-      directive (see <xref target="cache-response-directive" />), that directive overrides
-      the Expires field. Likewise, the s-maxage directive overrides Expires in shared caches.</t>
+  <t>
+    <x:h>Note:</x:h> if a response includes a Cache-Control field with the max-age
+    directive (see <xref target="cache-response-directive" />), that directive overrides
+    the Expires field. Likewise, the s-maxage directive overrides Expires in shared caches.
+  </t>
 </x:note>
 <t>
@@ -1274 +1283 @@
   <x:anchor-alias value="Pragma-v"/>
   <x:anchor-alias value="pragma-directive"/>
-<t
-  >The general-header field "Pragma" is used to include implementation-specific directives
+<t>
+  The general-header field "Pragma" is used to include implementation-specific directives
   that might apply to any recipient along the request/response chain. All pragma directives
   specify optional behavior from the viewpoint of the protocol; however, some systems
@@ -1299 +1308 @@
     <x:h>Note:</x:h> because the meaning of "Pragma: no-cache" as a response-header field
     is not actually specified, it does not provide a reliable replacement for
-    "Cache-Control: no-cache" in a response.</t>
+    "Cache-Control: no-cache" in a response.
+  </t>
 </x:note>
 <t>
@@ -1518 +1528 @@
   history mechanism is meant to show exactly what the user saw at the time when the resource
   was retrieved.
-  </t>
+</t>
 <t>
   By default, an expiration time does not apply to history mechanisms. If the entity is still
@@ -1527 +1537 @@
   This is not to be construed to prohibit the history mechanism from telling the user that a
   view might be stale.
-  <list>
-    <t>
-      <x:h>Note:</x:h> if history list mechanisms unnecessarily prevent users from viewing
-      stale resources, this will tend to force service authors to avoid using HTTP expiration
-      controls and cache controls when they would otherwise like to. Service authors may
-      consider it important that users not be presented with error messages or warning
-      messages when they use navigation controls (such as BACK) to view previously fetched
-      resources. Even though sometimes such resources ought not be cached, or ought to expire
-      quickly, user interface considerations may force service authors to resort to other
-      means of preventing caching (e.g. "once-only" URLs) in order not to suffer the effects
-      of improperly functioning history mechanisms.</t>
-  </list>
-</t>
+</t>
+<x:note>
+  <t>
+    <x:h>Note:</x:h> if history list mechanisms unnecessarily prevent users from viewing
+    stale resources, this will tend to force service authors to avoid using HTTP expiration
+    controls and cache controls when they would otherwise like to. Service authors may
+    consider it important that users not be presented with error messages or warning
+    messages when they use navigation controls (such as BACK) to view previously fetched
+    resources. Even though sometimes such resources ought not be cached, or ought to expire
+    quickly, user interface considerations may force service authors to resort to other
+    means of preventing caching (e.g. "once-only" URLs) in order not to suffer the effects
+    of improperly functioning history mechanisms.
+  </t>
+</x:note>
 </section>