Ignore:
Timestamp:
06/03/09 14:08:48 (13 years ago)
Author:
julian.reschke@…
Message:

reverted back P6's indentation to match the one used in the other parts; also minor xml2rfc syntax cleanup

File:
1 edited

Legend:

Unmodified
Added
Removed

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

    r539 r540  
    2929cite {
    3030  font-style: normal;
     31}
     32div.note {
     33  margin-left: 2em;
    3134}
    3235dd {
    … …  
    465468         <tr>
    466469            <td class="header left"></td>
    467             <td class="header right">March 5, 2009</td>
     470            <td class="header right">March 6, 2009</td>
    468471         </tr>
    469472      </table>
    … …  
    728731               <li>successfully validated (see <a href="#validation.model" title="Validation Model">Section&nbsp;2.4</a>).
    729732               </li>
    730             </ul>
     733            </ul> 
    731734         </li>
    732735      </ul>
    733       <p id="rfc.section.2.2.p.2"><span class="comment">[rfc.comment.2: TODO: define method cacheability for GET, HEAD and POST in p2-semantics.]</span></p>
    734       <p id="rfc.section.2.2.p.3">When a stored response is used to satisfy a request, caches <em class="bcp14">MUST</em> include a single Age header field <a href="#header.age" id="rfc.xref.header.age.1" title="Age">Section&nbsp;3.1</a> in the response with a value equal to the stored response's current_age; see <a href="#age.calculations" title="Calculating Age">Section&nbsp;2.3.2</a>. <span class="comment">[rfc.comment.3: DISCUSS: this currently includes successfully validated responses.]</span></p>
     736      <p id="rfc.section.2.2.p.2"> <span class="comment">[rfc.comment.2: TODO: define method cacheability for GET, HEAD and POST in p2-semantics.]</span>
     737      </p>
     738      <p id="rfc.section.2.2.p.3">When a stored response is used to satisfy a request, caches <em class="bcp14">MUST</em> include a single Age header field <a href="#header.age" id="rfc.xref.header.age.1" title="Age">Section&nbsp;3.1</a> in the response with a value equal to the stored response's current_age; see <a href="#age.calculations" title="Calculating Age">Section&nbsp;2.3.2</a>. <span class="comment">[rfc.comment.3: DISCUSS: this currently includes successfully validated responses.]</span>
     739      </p>
    735740      <p id="rfc.section.2.2.p.4">Requests with methods that are unsafe (<a href="p2-semantics.html#safe.methods" title="Safe Methods">Section 7.1.1</a> of <a href="#Part2" id="rfc.xref.Part2.1"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) <em class="bcp14">MUST</em> be written through the cache to the origin server; i.e., A cache must not reply to such a request before having forwarded
    736741         the request and having received a corresponding response.
    … …  
    752757      </p>
    753758      <p id="rfc.section.2.3.p.3">If an origin server wishes to force a cache to validate every request, it can assign an explicit expiration time in the past.
    754          This means that the response is always stale, so that caches should validate it before using it for subsequent requests. <span class="comment">[rfc.comment.5: This wording may cause confusion, because the response may still be served stale.]</span></p>
     759         This means that the response is always stale, so that caches should validate it before using it for subsequent requests. <span class="comment">[rfc.comment.5: This wording may cause confusion, because the response may still be served stale.]</span>
     760      </p>
    755761      <p id="rfc.section.2.3.p.4">Since origin servers do not always provide explicit expiration times, HTTP caches may also assign heuristic expiration times
    756762         when they are not specified, employing algorithms that use other header values (such as the Last-Modified time) to estimate
    … …  
    758764         on their results.
    759765      </p>
    760       <p id="rfc.section.2.3.p.5">The calculation to determine if a response is fresh is:</p>
    761       <div id="rfc.figure.u.3"></div> <pre class="text">   response_is_fresh = (freshness_lifetime &gt; current_age)
    762 </pre> <p id="rfc.section.2.3.p.7">The freshness_lifetime is defined in <a href="#calculating.freshness.lifetime" title="Calculating Freshness Lifetime">Section&nbsp;2.3.1</a>; the current_age is defined in <a href="#age.calculations" title="Calculating Age">Section&nbsp;2.3.2</a>.
    763       </p>
    764       <p id="rfc.section.2.3.p.8">Additionally, clients may need to influence freshness calculation. They can do this using several request cache directives,
     766      <div id="rfc.figure.u.3"></div>
     767      <p>The calculation to determine if a response is fresh is:</p> <pre class="text">   response_is_fresh = (freshness_lifetime &gt; current_age)
     768</pre> <p id="rfc.section.2.3.p.6">The freshness_lifetime is defined in <a href="#calculating.freshness.lifetime" title="Calculating Freshness Lifetime">Section&nbsp;2.3.1</a>; the current_age is defined in <a href="#age.calculations" title="Calculating Age">Section&nbsp;2.3.2</a>.
     769      </p>
     770      <p id="rfc.section.2.3.p.7">Additionally, clients may need to influence freshness calculation. They can do this using several request cache directives,
    765771         with the effect of either increasing or loosening constraints on freshness. See <a href="#cache-request-directive" title="Request Cache-Control Directives">Section&nbsp;3.2.1</a>.
    766772      </p>
    767       <p id="rfc.section.2.3.p.9"> <span class="comment">[rfc.comment.6: ISSUE: there are not requirements directly applying to cache-request-directives and freshness.]</span>
    768       </p>
    769       <p id="rfc.section.2.3.p.10">Note that freshness applies only to cache operation; it cannot be used to force a user agent to refresh its display or reload
     773      <p id="rfc.section.2.3.p.8"> <span class="comment">[rfc.comment.6: ISSUE: there are not requirements directly applying to cache-request-directives and freshness.]</span>
     774      </p>
     775      <p id="rfc.section.2.3.p.9">Note that freshness applies only to cache operation; it cannot be used to force a user agent to refresh its display or reload
    770776         a resource. See <a href="#history.lists" title="History Lists">Section&nbsp;4</a> for an explanation of the difference between caches and history mechanisms.
    771777      </p>
    … …  
    814820         <li>age_value, if all of the caches along the response path implement HTTP/1.1.</li>
    815821      </ol>
    816       <p id="rfc.section.2.3.2.p.6">These are combined as</p>
    817       <div id="rfc.figure.u.4"></div> <pre class="text">    corrected_received_age = max(now - date_value, age_value)
    818 </pre> <p id="rfc.section.2.3.2.p.8">When an Age value is received, it <em class="bcp14">MUST</em> be interpreted relative to the time the request was initiated, not the time that the response was received.
    819       </p>
    820       <div id="rfc.figure.u.5"></div> <pre class="text">   corrected_initial_age = corrected_received_age
     822      <div id="rfc.figure.u.4"></div>
     823      <p>These are combined as</p> <pre class="text">    corrected_received_age = max(now - date_value, age_value)
     824</pre><p id="rfc.section.2.3.2.p.7">When an Age value is received, it <em class="bcp14">MUST</em> be interpreted relative to the time the request was initiated, not the time that the response was received.
     825      </p>
     826      <div id="rfc.figure.u.5"></div><pre class="text">   corrected_initial_age = corrected_received_age
    821827                         + (now - request_time)
    822 </pre> <p id="rfc.section.2.3.2.p.10">where "request_time" is the time (according to the local clock) when the request that elicited this response was sent.</p>
    823       <p id="rfc.section.2.3.2.p.11">The current_age of a stored response can then be calculated by adding the amount of time (in seconds) since the stored response
     828</pre><p id="rfc.section.2.3.2.p.9">where "request_time" is the time (according to the local clock) when the request that elicited this response was sent.</p>
     829      <p id="rfc.section.2.3.2.p.10">The current_age of a stored response can then be calculated by adding the amount of time (in seconds) since the stored response
    824830         was last validated by the origin server to the corrected_initial_age.
    825831      </p>
    826       <p id="rfc.section.2.3.2.p.12">In summary:</p>
    827       <div id="rfc.figure.u.6"></div> <pre class="text">   age_value     - Age header field-value received with the response
    828    date_value    - Date header field-value received with the response
    829    request_time  - local time when the cache made the request
    830                    resulting in the stored response
    831    response_time - local time when the cache received the response
    832    now           - current local time
    833 
    834    apparent_age = max(0, response_time - date_value);
    835    corrected_received_age = max(apparent_age, age_value);
    836    response_delay = response_time - request_time;
    837    corrected_initial_age = corrected_received_age + response_delay;
    838    resident_time = now - response_time;
    839    current_age   = corrected_initial_age + resident_time;
    840 </pre> <h3 id="rfc.section.2.3.3"><a href="#rfc.section.2.3.3">2.3.3</a>&nbsp;<a id="serving.stale.responses" href="#serving.stale.responses">Serving Stale Responses</a></h3>
     832      <p id="rfc.section.2.3.2.p.11">In summary:</p>
     833      <div id="rfc.figure.u.6"></div><pre class="text">  age_value     - Age header field-value received with the response
     834  date_value    - Date header field-value received with the response
     835  request_time  - local time when the cache made the request
     836                 resulting in the stored response
     837  response_time - local time when the cache received the response
     838  now           - current local time
     839 
     840  apparent_age = max(0, response_time - date_value);
     841  corrected_received_age = max(apparent_age, age_value);
     842  response_delay = response_time - request_time;
     843  corrected_initial_age = corrected_received_age + response_delay;
     844  resident_time = now - response_time;
     845  current_age   = corrected_initial_age + resident_time;
     846</pre><h3 id="rfc.section.2.3.3"><a href="#rfc.section.2.3.3">2.3.3</a>&nbsp;<a id="serving.stale.responses" href="#serving.stale.responses">Serving Stale Responses</a></h3>
    841847      <p id="rfc.section.2.3.3.p.1">A "stale" response is one that either has explicit expiry information, or is allowed to have heuristic expiry calculated,
    842848         but is not fresh according to the calculations in <a href="#expiration.model" title="Freshness Model">Section&nbsp;2.3</a>.
    … …  
    847853      </p>
    848854      <p id="rfc.section.2.3.3.p.3">Caches <em class="bcp14">SHOULD NOT</em> return stale responses unless they are disconnected (i.e., it cannot contact the origin server or otherwise find a forward
    849          path) or otherwise explicitly allowed (e.g., the max-stale request directive; see <a href="#cache-request-directive" title="Request Cache-Control Directives">Section&nbsp;3.2.1</a>)..
     855         path) or otherwise explicitly allowed (e.g., the max-stale request directive; see <a href="#cache-request-directive" title="Request Cache-Control Directives">Section&nbsp;3.2.1</a>).
    850856      </p>
    851857      <p id="rfc.section.2.3.3.p.4">Stale responses <em class="bcp14">SHOULD</em> have a Warning header with the 110 warn-code (see <a href="#header.warning" id="rfc.xref.header.warning.1" title="Warning">Section&nbsp;3.6</a>). Likewise, the 112 warn-code <em class="bcp14">SHOULD</em> be sent on stale responses if the cache is disconnected.
    … …  
    865871      </p>
    866872      <p id="rfc.section.2.4.p.4">If instead the cache receives a full response (i.e., one with a response body), it is used to satisfy the request and replace
    867          the stored response. <span class="comment">[rfc.comment.8: Should there be a requirement here?]</span></p>
     873         the stored response. <span class="comment">[rfc.comment.8: Should there be a requirement here?]</span>
     874      </p>
    868875      <p id="rfc.section.2.4.p.5">If a cache receives a 5xx response while attempting to validate a response, it <em class="bcp14">MAY</em> either forward this response to the requesting client, or act as if the server failed to respond. In the latter case, it <em class="bcp14">MAY</em> return a previously stored response (which <em class="bcp14">SHOULD</em> include the 111 warn-code; see <a href="#header.warning" id="rfc.xref.header.warning.2" title="Warning">Section&nbsp;3.6</a>) unless the stored response includes the "must-revalidate" cache directive (see <a href="#serving.stale.responses" title="Serving Stale Responses">Section&nbsp;2.3.3</a>).
    869876      </p>
    … …  
    901908      <p id="rfc.section.2.6.p.3">The selecting request-headers from two requests are defined to match if and only if the selecting request-headers in the first
    902909         request can be transformed to the selecting request-headers in the second request by adding or removing linear white space <span class="comment">[rfc.comment.11: [ref]]</span> at places where this is allowed by the corresponding ABNF, and/or combining multiple message-header fields with the same field
    903          name following the rules about message headers in <a href="p1-messaging.html#message.headers" title="Message Headers">Section 4.2</a> of <a href="#Part1" id="rfc.xref.Part1.12"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. <span class="comment">[rfc.comment.12: DISCUSS: header-specific canonicalisation]</span></p>
     910         name following the rules about message headers in <a href="p1-messaging.html#message.headers" title="Message Headers">Section 4.2</a> of <a href="#Part1" id="rfc.xref.Part1.12"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. <span class="comment">[rfc.comment.12: DISCUSS: header-specific canonicalisation]</span>
     911      </p>
    904912      <p id="rfc.section.2.6.p.4">A Vary header field-value of "*" always fails to match, and subsequent requests to that resource can only be properly interpreted
    905913         by the origin server.
    … …  
    913921      <p id="rfc.section.2.6.p.7">If a cache receives a successful response whose Content-Location field matches that of an existing stored response for the
    914922         same Request-URI, whose entity-tag differs from that of the existing stored response, and whose Date is more recent than that
    915          of the existing response, the existing response <em class="bcp14">SHOULD NOT</em> be returned in response to future requests and <em class="bcp14">SHOULD</em> be deleted from the cache.<span class="comment">[rfc.comment.13: DISCUSS: Not sure if this is necessary.]</span></p>
     923         of the existing response, the existing response <em class="bcp14">SHOULD NOT</em> be returned in response to future requests and <em class="bcp14">SHOULD</em> be deleted from the cache.<span class="comment">[rfc.comment.13: DISCUSS: Not sure if this is necessary.]</span>
     924      </p>
    916925      <h2 id="rfc.section.2.7"><a href="#rfc.section.2.7">2.7</a>&nbsp;<a id="combining.headers" href="#combining.headers">Combining Responses</a></h2>
    917926      <p id="rfc.section.2.7.p.1">When a cache receives a 304 (Not Modified) response or a 206 (Partial Content) response, it needs to update the stored response
    … …  
    935944         all such old headers <em class="bcp14">MUST</em> be replaced. It <em class="bcp14">MAY</em> store the combined entity-body.
    936945      </p>
    937       <p id="rfc.section.2.7.p.5"><span class="comment">[rfc.comment.14: ISSUE: discuss how to handle HEAD updates]</span></p>
     946      <p id="rfc.section.2.7.p.5"> <span class="comment">[rfc.comment.14: ISSUE: discuss how to handle HEAD updates]</span>
     947      </p>
    938948      <h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a>&nbsp;<a id="header.fields" href="#header.fields">Header Field Definitions</a></h1>
    939949      <p id="rfc.section.3.p.1">This section defines the syntax and semantics of HTTP/1.1 header fields related to caching.</p>
    … …  
    952962         <p id="rfc.section.3.1.p.3">  Age field-values are non-negative decimal integers, representing time in seconds.</p>
    953963      </div>
    954       <div id="rfc.figure.u.8"></div> <pre class="inline"><span id="rfc.iref.g.3"></span>  <a href="#rule.delta-seconds" class="smpl">delta-seconds</a>  = 1*<a href="#notation" class="smpl">DIGIT</a>
    955 </pre> <p id="rfc.section.3.1.p.5">If a cache receives a value larger than the largest positive integer it can represent, or if any of its age calculations overflows,
     964      <div id="rfc.figure.u.8"></div><pre class="inline"><span id="rfc.iref.g.3"></span>  <a href="#rule.delta-seconds" class="smpl">delta-seconds</a>  = 1*<a href="#notation" class="smpl">DIGIT</a>
     965</pre><p id="rfc.section.3.1.p.5">If a cache receives a value larger than the largest positive integer it can represent, or if any of its age calculations overflows,
    956966         it <em class="bcp14">MUST</em> transmit an Age header with a field-value of 2147483648 (2<sup>31</sup>). Caches <em class="bcp14">SHOULD</em> use an arithmetic type of at least 31 bits of range.
    957967      </p>
    … …  
    964974      <p id="rfc.section.3.2.p.1">The general-header field "Cache-Control" is used to specify directives that <em class="bcp14">MUST</em> be obeyed by all caches along the request/response chain. The directives specify behavior intended to prevent caches from
    965975         adversely interfering with the request or response. Cache directives are unidirectional in that the presence of a directive
    966          in a request does not imply that the same directive is to be given in the response. 
    967       </p>
    968       <dl class="empty">
    969          <dd>Note that HTTP/1.0 caches might not implement Cache-Control and might only implement Pragma: no-cache (see <a href="#header.pragma" id="rfc.xref.header.pragma.2" title="Pragma">Section&nbsp;3.4</a>).
    970          </dd>
    971       </dl>
    972       <p id="rfc.section.3.2.p.2">Cache directives <em class="bcp14">MUST</em> be passed through by a proxy or gateway application, regardless of their significance to that application, since the directives
     976         in a request does not imply that the same directive is to be given in the response.
     977      </p>
     978      <div class="note">
     979         <p>Note that HTTP/1.0 caches might not implement Cache-Control and might only implement Pragma: no-cache (see <a href="#header.pragma" id="rfc.xref.header.pragma.2" title="Pragma">Section&nbsp;3.4</a>).
     980         </p>
     981      </div>
     982      <p id="rfc.section.3.2.p.3">Cache directives <em class="bcp14">MUST</em> be passed through by a proxy or gateway application, regardless of their significance to that application, since the directives
    973983         might be applicable to all recipients along the request/response chain. It is not possible to target a directive to a specific
    974984         cache.
    … …  
    982992  <a href="#header.cache-control" class="smpl">cache-extension</a> = <a href="#core.rules" class="smpl">token</a> [ "=" ( <a href="#core.rules" class="smpl">token</a> / <a href="#core.rules" class="smpl">quoted-string</a> ) ]
    983993</pre><h3 id="rfc.section.3.2.1"><a href="#rfc.section.3.2.1">3.2.1</a>&nbsp;<a id="cache-request-directive" href="#cache-request-directive">Request Cache-Control Directives</a></h3>
    984       <div id="rfc.figure.u.10"></div> <pre class="inline"><span id="rfc.iref.g.7"></span>  <a href="#header.cache-control" class="smpl">cache-request-directive</a> =
     994      <div id="rfc.figure.u.10"></div><pre class="inline"><span id="rfc.iref.g.7"></span>  <a href="#header.cache-control" class="smpl">cache-request-directive</a> =
    985995       "no-cache"
    986996     / "no-store"
    … …  
    9911001     / "only-if-cached"
    9921002     / <a href="#header.cache-control" class="smpl">cache-extension</a>
    993 </pre> <p id="rfc.section.3.2.1.p.2"> <span id="rfc.iref.c.4"></span>  <span id="rfc.iref.n.1"></span> no-cache
     1003</pre><p id="rfc.section.3.2.1.p.2"> <span id="rfc.iref.c.4"></span>  <span id="rfc.iref.n.1"></span> no-cache
    9941004      </p>
    9951005      <dl class="empty">
    … …  
    10461056      </dl>
    10471057      <h3 id="rfc.section.3.2.2"><a href="#rfc.section.3.2.2">3.2.2</a>&nbsp;<a id="cache-response-directive" href="#cache-response-directive">Response Cache-Control Directives</a></h3>
    1048       <div id="rfc.figure.u.11"></div> <pre class="inline"><span id="rfc.iref.g.8"></span>  <a href="#header.cache-control" class="smpl">cache-response-directive</a> =
     1058      <div id="rfc.figure.u.11"></div><pre class="inline"><span id="rfc.iref.g.8"></span>  <a href="#header.cache-control" class="smpl">cache-response-directive</a> =
    10491059       "public"
    10501060     / "private" [ "=" <a href="#notation" class="smpl">DQUOTE</a> 1#<a href="#abnf.dependencies" class="smpl">field-name</a> <a href="#notation" class="smpl">DQUOTE</a> ]
    … …  
    10571067     / "s-maxage" "=" <a href="#rule.delta-seconds" class="smpl">delta-seconds</a>
    10581068     / <a href="#header.cache-control" class="smpl">cache-extension</a>
    1059 </pre> <p id="rfc.section.3.2.2.p.2"> <span id="rfc.iref.c.11"></span>  <span id="rfc.iref.p.1"></span> public
     1069</pre><p id="rfc.section.3.2.2.p.2"> <span id="rfc.iref.c.11"></span>  <span id="rfc.iref.p.1"></span> public
    10601070      </p>
    10611071      <dl class="empty">
    … …  
    11541164         otherwise private response in their shared cache(s) could do so by including
    11551165      </p>
    1156       <div id="rfc.figure.u.12"></div> <pre class="text">  Cache-Control: private, community="UCI"
    1157 </pre> <p id="rfc.section.3.2.3.p.5">A cache seeing this header field will act correctly even if the cache does not understand the community cache-extension, since
     1166      <div id="rfc.figure.u.12"></div><pre class="text">  Cache-Control: private, community="UCI"
     1167</pre><p id="rfc.section.3.2.3.p.5">A cache seeing this header field will act correctly even if the cache does not understand the community cache-extension, since
    11581168         it will also see and understand the private directive and thus default to the safe behavior.
    11591169      </p>
    … …  
    11741184      <div id="rfc.figure.u.13"></div><pre class="inline"><span id="rfc.iref.g.9"></span><span id="rfc.iref.g.10"></span>  <a href="#header.expires" class="smpl">Expires</a>   = "Expires" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.expires" class="smpl">Expires-v</a>
    11751185  <a href="#header.expires" class="smpl">Expires-v</a> = <a href="#abnf.dependencies" class="smpl">HTTP-date</a>
    1176 </pre><p id="rfc.section.3.3.p.5">For example</p>
    1177       <div id="rfc.figure.u.14"></div> <pre class="text">  Expires: Thu, 01 Dec 1994 16:00:00 GMT
    1178 </pre> <p id="rfc.section.3.3.p.7"> </p>
    1179       <dl class="empty">
    1180          <dd> <b>Note:</b> if a response includes a Cache-Control field with the max-age directive (see <a href="#cache-response-directive" title="Response Cache-Control Directives">Section&nbsp;3.2.2</a>), that directive overrides the Expires field. Likewise, the s-maxage directive overrides Expires in shared caches.
    1181          </dd>
    1182       </dl>
    1183       <p id="rfc.section.3.3.p.8">HTTP/1.1 servers <em class="bcp14">SHOULD NOT</em> send Expires dates more than one year in the future.
    1184       </p>
    1185       <p id="rfc.section.3.3.p.9">HTTP/1.1 clients and caches <em class="bcp14">MUST</em> treat other invalid date formats, especially including the value "0", as in the past (i.e., "already expired").
     1186</pre><div id="rfc.figure.u.14"></div>
     1187      <p>For example</p>  <pre class="text">  Expires: Thu, 01 Dec 1994 16:00:00 GMT
     1188</pre><div class="note">
     1189         <p> <b>Note:</b> if a response includes a Cache-Control field with the max-age directive (see <a href="#cache-response-directive" title="Response Cache-Control Directives">Section&nbsp;3.2.2</a>), that directive overrides the Expires field. Likewise, the s-maxage directive overrides Expires in shared caches.
     1190         </p>
     1191      </div>
     1192      <p id="rfc.section.3.3.p.7">HTTP/1.1 servers <em class="bcp14">SHOULD NOT</em> send Expires dates more than one year in the future.
     1193      </p>
     1194      <p id="rfc.section.3.3.p.8">HTTP/1.1 clients and caches <em class="bcp14">MUST</em> treat other invalid date formats, especially including the value "0", as in the past (i.e., "already expired").
    11861195      </p>
    11871196      <div id="rfc.iref.p.4"></div>
    … …  
    11991208         has the same semantics as the no-cache response directive (see <a href="#cache-response-directive" title="Response Cache-Control Directives">Section&nbsp;3.2.2</a>) and is defined here for backward compatibility with HTTP/1.0. Clients <em class="bcp14">SHOULD</em> include both header fields when a no-cache request is sent to a server not known to be HTTP/1.1 compliant. HTTP/1.1 caches <em class="bcp14">SHOULD</em> treat "Pragma: no-cache" as if the client had sent "Cache-Control: no-cache".
    12001209      </p>
    1201       <p id="rfc.section.3.4.p.4"> </p>
    1202       <dl class="empty">
    1203          <dd> <b>Note:</b> because the meaning of "Pragma: no-cache" as a response-header field is not actually specified, it does not provide a reliable
     1210      <div class="note">
     1211         <p> <b>Note:</b> because the meaning of "Pragma: no-cache" as a response-header field is not actually specified, it does not provide a reliable
    12041212            replacement for "Cache-Control: no-cache" in a response.
    1205          </dd>
    1206       </dl>
     1213         </p>
     1214      </div>
    12071215      <p id="rfc.section.3.4.p.5">This mechanism is deprecated; no new Pragma directives will be defined in HTTP.</p>
    12081216      <div id="rfc.iref.v.3"></div>
Note: See TracChangeset for help on using the changeset viewer.