To LUGNET HomepageTo LUGNET News HomepageTo LUGNET Guide Homepage
 Help on Searching
 
Post new message to lugnet.publishOpen lugnet.publish in your NNTP NewsreaderTo LUGNET News Traffic PageSign In (Members)
 Publishing / 2275
2274  |  2276
Subject: 
Re: Forced refresh of html pages instead of getting them from browser cache
Newsgroups: 
lugnet.publish, lugnet.off-topic.geek
Date: 
Wed, 9 Aug 2000 23:54:05 GMT
Viewed: 
889 times
  
In lugnet.publish, Todd Lehman writes:
In lugnet.publish, Kevin Loch writes:
Here's what I do to guarantee no caching:

void printCGIheader(){
  printf("Content-type: text/html\n");
  printf("Expires: 0\n");
  printf("Cache-control: no-cache\n");
  printf("Pragma: no-cache\n");
  printf("\n");

}

void printCookieHeader(char *token) {
  printf("Content-type: text/html\n");
  printf("Expires: 0\n");
  printf("Cache-control: no-cache\n");
  printf("Pragma: no-cache\n");
  printf("Set-cookie: token=%s\n",token);
  printf("\n");
}

I basically threw in everything and the kitchen sink.
This should work for both HTTP 1.0 and 1.1 and those pesky proxy caches.
(although @home's proxy server kills the cookies for some reason, but
there is no need to use @home's proxy servers).  Squid proxy server
passes the cookies just fine and does not cache anything.

Wicked excellent.  I'm going to try that.  So the cookie rationale there is
to avoid having cookies accidentally set twice, yes?  In case one of the
caching entities isn't smart enough to automatically not cache pages
containing set-cookie requests?

--Todd

I'm not sure what you mean by cookies being set twice.  The two functions above
are used for non-logged in state and logged-in state respectively.  Every page
access while logged in causes the cookie to be set (notice they are not
persistent/saved to disk).  Depending on how old it is it sets
the same cookie or a new one, either way the correct unexpired cookie must be
returned from the correct ip address to retain logged-in state.

In this mode of operation, it is perfectly ok to set the same cookie several
times, it simply overwrites the existing value, and the user is identified
through authentication before any cookie is set. If you were generating a new
unique id for every non-cookie-producing user every time I can see where
that would be undesirable.

In my case, forcing no cache is a requirement independent of setting cookies,
but it should work for that too.

KL



Message is in Reply To:
  Re: Forced refresh of html pages instead of getting them from browser cache
 
(...) Wicked excellent. I'm going to try that. So the cookie rationale there is to avoid having cookies accidentally set twice, yes? In case one of the caching entities isn't smart enough to automatically not cache pages containing set-cookie (...) (24 years ago, 9-Aug-00, to lugnet.publish, lugnet.off-topic.geek)

18 Messages in This Thread:






Entire Thread on One Page:
Nested:  All | Brief | Compact | Dots
Linear:  All | Brief | Compact
    

Custom Search

©2005 LUGNET. All rights reserved. - hosted by steinbruch.info GbR