Changeset 575


Ignore:
Timestamp:
May 5, 2009, 11:34:04 PM (11 years ago)
Author:
julian.reschke@…
Message:

source code cleanup

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

Legend:

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

    r573 r575  
    468468         <tr>
    469469            <td class="header left"></td>
    470             <td class="header right">May 1, 2009</td>
     470            <td class="header right">May 6, 2009</td>
    471471         </tr>
    472472      </table>
     
    13581358         documents.
    13591359      </p>
    1360       <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>
    1361       <dl class="empty">
    1362          <dd> <b>Note:</b> if history list mechanisms unnecessarily prevent users from viewing stale resources, this will tend to force service authors
     1360      <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>
     1361      <div class="note">
     1362         <p> <b>Note:</b> if history list mechanisms unnecessarily prevent users from viewing stale resources, this will tend to force service authors
    13631363            to avoid using HTTP expiration controls and cache controls when they would otherwise like to. Service authors may consider
    13641364            it important that users not be presented with error messages or warning messages when they use navigation controls (such as
     
    13661366            user interface considerations may force service authors to resort to other means of preventing caching (e.g. "once-only" URLs)
    13671367            in order not to suffer the effects of improperly functioning history mechanisms.
    1368          </dd>
    1369       </dl>
     1368         </p>
     1369      </div>
    13701370      <h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a>&nbsp;<a id="IANA.considerations" href="#IANA.considerations">IANA Considerations</a></h1>
    13711371      <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

    r573 r575  
    245245
    246246<section anchor="intro.terminology" title="Terminology">
    247 <t
    248   >This specification uses a number of terms to refer to the roles played by participants
     247<t>
     248  This specification uses a number of terms to refer to the roles played by participants
    249249  in, and objects of, HTTP caching.
    250250</t>
     
    453453<section anchor="constructing.responses.from.caches" title="Constructing Responses from Caches">
    454454<t>
    455 For a presented request, a cache &MUST-NOT; return a stored response, unless:
     455  For a presented request, a cache &MUST-NOT; return a stored response, unless:
    456456  <list style="symbols">
    457457    <t>The presented Request-URI and that of the stored response match
     
    532532<figure>
    533533<preamble>
    534 The calculation to determine if a response is fresh is:
     534  The calculation to determine if a response is fresh is:
    535535</preamble>
    536536<artwork type="code">
     
    625625  synchronize their clocks to a globally accurate time standard.
    626626</t>
    627 <t>A response's age can be calculated in two entirely independent ways:
     627<t>
     628  A response's age can be calculated in two entirely independent ways:
    628629  <list style="numbers">
    629630    <t>now minus date_value, if the local clock is reasonably well synchronized to the
     
    868869
    869870<section anchor="header.fields" title="Header Field Definitions">
    870 <t>This section defines the syntax and semantics of HTTP/1.1 header fields related to caching.</t>
    871 <t>For entity-header fields, both sender and recipient refer to either the client or the
    872 server, depending on who sends and who receives the entity.</t>
     871<t>
     872  This section defines the syntax and semantics of HTTP/1.1 header fields
     873  related to caching.
     874</t>
     875<t>
     876  For entity-header fields, both sender and recipient refer to either the client or the
     877  server, depending on who sends and who receives the entity.
     878</t>
    873879
    874880<section anchor="header.age" title="Age">
     
    924930</t>
    925931<x:note>
    926   <t>Note that HTTP/1.0 caches might not implement Cache-Control and might only implement
    927   Pragma: no-cache (see <xref target="header.pragma" />).</t>
     932  <t>
     933    Note that HTTP/1.0 caches might not implement Cache-Control and might only implement
     934    Pragma: no-cache (see <xref target="header.pragma" />).
     935  </t>
    928936</x:note>
    929937<t>
     
    12531261</artwork></figure>
    12541262<x:note>
    1255     <t>
    1256       <x:h>Note:</x:h> if a response includes a Cache-Control field with the max-age
    1257       directive (see <xref target="cache-response-directive" />), that directive overrides
    1258       the Expires field. Likewise, the s-maxage directive overrides Expires in shared caches.</t>
     1263  <t>
     1264    <x:h>Note:</x:h> if a response includes a Cache-Control field with the max-age
     1265    directive (see <xref target="cache-response-directive" />), that directive overrides
     1266    the Expires field. Likewise, the s-maxage directive overrides Expires in shared caches.
     1267  </t>
    12591268</x:note>
    12601269<t>
     
    12741283  <x:anchor-alias value="Pragma-v"/>
    12751284  <x:anchor-alias value="pragma-directive"/>
    1276 <t
    1277   >The general-header field "Pragma" is used to include implementation-specific directives
     1285<t>
     1286  The general-header field "Pragma" is used to include implementation-specific directives
    12781287  that might apply to any recipient along the request/response chain. All pragma directives
    12791288  specify optional behavior from the viewpoint of the protocol; however, some systems
     
    12991308    <x:h>Note:</x:h> because the meaning of "Pragma: no-cache" as a response-header field
    13001309    is not actually specified, it does not provide a reliable replacement for
    1301     "Cache-Control: no-cache" in a response.</t>
     1310    "Cache-Control: no-cache" in a response.
     1311  </t>
    13021312</x:note>
    13031313<t>
     
    15181528  history mechanism is meant to show exactly what the user saw at the time when the resource
    15191529  was retrieved.
    1520   </t>
     1530</t>
    15211531<t>
    15221532  By default, an expiration time does not apply to history mechanisms. If the entity is still
     
    15271537  This is not to be construed to prohibit the history mechanism from telling the user that a
    15281538  view might be stale.
    1529   <list>
    1530     <t>
    1531       <x:h>Note:</x:h> if history list mechanisms unnecessarily prevent users from viewing
    1532       stale resources, this will tend to force service authors to avoid using HTTP expiration
    1533       controls and cache controls when they would otherwise like to. Service authors may
    1534       consider it important that users not be presented with error messages or warning
    1535       messages when they use navigation controls (such as BACK) to view previously fetched
    1536       resources. Even though sometimes such resources ought not be cached, or ought to expire
    1537       quickly, user interface considerations may force service authors to resort to other
    1538       means of preventing caching (e.g. "once-only" URLs) in order not to suffer the effects
    1539       of improperly functioning history mechanisms.</t>
    1540   </list>
    1541 </t>
     1539</t>
     1540<x:note>
     1541  <t>
     1542    <x:h>Note:</x:h> if history list mechanisms unnecessarily prevent users from viewing
     1543    stale resources, this will tend to force service authors to avoid using HTTP expiration
     1544    controls and cache controls when they would otherwise like to. Service authors may
     1545    consider it important that users not be presented with error messages or warning
     1546    messages when they use navigation controls (such as BACK) to view previously fetched
     1547    resources. Even though sometimes such resources ought not be cached, or ought to expire
     1548    quickly, user interface considerations may force service authors to resort to other
     1549    means of preventing caching (e.g. "once-only" URLs) in order not to suffer the effects
     1550    of improperly functioning history mechanisms.
     1551  </t>
     1552</x:note>
    15421553</section>
    15431554
Note: See TracChangeset for help on using the changeset viewer.