Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>I think you should just use</p> <pre><code>HttpContext.Current.Response.Cache.SetMaxAge (new TimeSpan (0)); </code></pre> <p>or</p> <pre><code>HttpContext.Current.Response.Headers.Set ("Cache-Control", "private, max-age=0"); </code></pre> <p>to set <code>max-age=0</code> which means nothing more as the cache re-validating (see <a href="http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9.4" rel="noreferrer">here</a>). If you would be set additionally <code>ETag</code> in the header with some your custom checksum of hash from the data, the ETag from the previous request will be sent to the server. The server are able either to return the data or, in case that the data are exactly the same as before, it can return empty body and <code>HttpStatusCode.NotModified</code> as the status code. In the case the web browser will get the data from the local browser cache.</p> <p>I recommend you to use <code>Cache-Control: private</code> which force two important things: 1) switch off caching the data on the proxy, which has sometimes very aggressive caching settings 2) it will allows the caching of the the data, but not permit sharing of the cache with another users. It can solve privacy problems because the data which you return to one user could be not allowed to read by another users. By the way the code <code>HttpContext.Current.Response.Cache.SetMaxAge (new TimeSpan (0))</code> set <code>Cache-Control: private, max-age=0</code> in the HTTP header by default. If you do want to use <code>Cache-Control: public</code> you can use <code>SetCacheability (HttpCacheability.Public);</code> to overwrite the behavior or use <code>Headers.Set</code> instead of <code>Cache.SetMaxAge</code>.</p> <p>If you have interest to study more caching options of HTTP protocol I would recommend you to read the <a href="http://www.mnot.net/cache_docs/" rel="noreferrer">caching tutorial</a>.</p> <p><strong>UPDATED</strong>: I decide to write some more information to clear my position. Corresponds to <a href="http://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol#History" rel="noreferrer">the information</a> from the Wikipedia even so old web browsers like Mosaic 2.7, Netscape 2.0 and Internet Explorer 3.0 supports March 1996, pre-standard of HTTP/1.1 described in RFC 2068. So I suppose (but not test it) that the old web browsers support <code>max-age=0</code> HTTP header. In any way Netscape 2.06 and Internet Explorer 4.0 definitively supports HTTP 1.1.</p> <p>So you should ask you first: which HTML standards you use? Do you still use HTML 2.0 instead of more late HTML 3.2 published in January 1997? I suppose you use at least HTML 4.0 published in December 1997. So if you build your application at least in HTML 4.0, your site can be oriented on the web clients which supports HTTP 1.1 and ignore (don't support) the web clients which don't support HTTP 1.1.</p> <p>Now about other "Cache-Control" headers as "private, max-age=0". Including of the headers is in my opinion is <strong>pure paranoia</strong>. As I have some caching problem myself I tried also to include different other headers, but later after reading carefully the section 14.9 of RFC2616 I use only "Cache-Control: private, max-age=0".</p> <p>The only "Cache-Control" header which can be additionally discussed is "must-revalidate" described on the section 14.9.4 which I referenced before. Here is the quote:</p> <blockquote> <p>The must-revalidate directive is necessary to support reliable operation for certain protocol features. In all circumstances an HTTP/1.1 cache MUST obey the must-revalidate directive; in particular, if the cache cannot reach the origin server for any reason, it MUST generate a 504 (Gateway Timeout) response.</p> <p>Servers SHOULD send the must-revalidate directive if and only if failure to revalidate a request on the entity could result in incorrect operation, such as a silently unexecuted financial transaction. Recipients MUST NOT take any automated action that violates this directive, and MUST NOT automatically provide an unvalidated copy of the entity if revalidation fails.</p> <p>Although this is not recommended, user agents operating under severe connectivity constraints MAY violate this directive but, if so, MUST explicitly warn the user that an unvalidated response has been provided. The warning MUST be provided on each unvalidated access, and SHOULD require explicit user confirmation.</p> </blockquote> <p>Sometime if I have problem with Internet connection I see the empty page with "Gateway Timeout" message. It come from the the usage of "must-revalidate" directive. I don't think that "Gateway Timeout" message really help the user.</p> <p>So the persons, how prefer to start self-destructive procedure if he hears "Busy" signal on the call to his boss, should additionally use "must-revalidate" directive in the "Cache-Control" header. Other persons I recommend just use "Cache-Control: private, max-age=0" and nothing more.</p>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload