I'm not sure if this is your problem, but we had a similar issue awhile back.
About a year-and-a-half ago, there was an incremental release of the squid
proxy server that had a major bug in it. I can't remember the details exactly,
but I believe it had something to do with the fact that squid was completely
ignoring the following server headers:
Cache-Control: private
This tells all shared caches to not cache the page, but allows individual
browser clients to cache it.
Pragma: no-cache
HTTP 1.0
Tells both shared caches and private browser caches not to cache the
page.
So, even if the headers were set correctly, a 'set-cookie' header was getting
cached by mistake. And by the way, squid seems to be the defacto proxy
standard for many of the major ISP's out there. I deal mostly with
international customers, but almost all of the operations staff at the ISP's we
contacted, were using squid.
The only way around this situation was to have the ISP's upgrade squid fast (a
patch was released quickly), and/or the following type of method (which we
ended up implementing):
- Set a client specific cookie via HTTPS (almost all ISP's don't cache HTTPS
traffic for obvious reasons)
- Have the client create (via JavaScript) a new request header that uses the
previous cookie in a specific algorithm (that both the client and server know)
- Have the server evaluate the cookie and the new client created header to
validate client identity upon next non-HTTPS request
- Keep in mind, this was strictly used to crack the proxy caching issue, not
for storing any secret data.
Also. Many ISP's will intentionally ignore no-cache headers, just to alleviate
traffic woes on their end, especially with static content like images,
JavaScript, CSS, etc. I personally believe this happens way more than people
think. If you serve that type of content from the same domains as your dynamic
content, chances are the ISPs will be caching client cookies since all client
requests the domain the cookies belong to will have all the client cookies in
tow every time.
A combination of separating your static content onto a different domain(s), in
conjunction with the client/server cookie/header magic described above, should
probably do the trick (hopefully anyway).
Hope this helps,
- Jeff
----- Original Message ----
From: Dondi M. Stroma <[EMAIL PROTECTED]>
To: modperl@perl.apache.org
Sent: Monday, October 2, 2006 6:18:24 PM
Subject: mystery caching problem
Hi,
Before I begin, I want to let you know that I've already poured over all
mod_perl/Apache/CGI/perl related docs, porting guides, mailing list
archives, etc. I've read and re-read about the traps and pitfalls of
mod_perl. I have "use strict" on, warnings on, and I've quadrouple checked
for closures, global variables, "variable will not stay shared" warnings,
always passing variables to subroutines as parameters, etc.
Well, I've been experiencing a mysterious problem for a very long time now
with a web app that I wrote. It was written to work under either
mod_perl+Apache::Registry or mod_cgi, but obviously I'm running it under
mod_perl or I wouldn't be posting this message here. It's running on Fedora
with Apache 1.33 and mod_perl 1.29 (dso). The scripts use CGI.pm (latest
version) for sending headers, and getting and retrieving cookies which store
username and encrypted password. I'm not using any kind of reverse proxy or
caching modules or anything like that, although I am using mod_rewrite for
clean URLs (I know I could use a handler for that, but like I said
everything was written to work under both mod_perl and regular mod_cgi).
The problem: occasionally, when a user logs in, they end up logging in to
someone else's account! But it happens very, very infrequently, and I've
been unable to even reproduce the problem myself. The application averages
about 5000 logins per day, and users report this problem only about once
every two weeks. So, this problem happens only 1 in 70,000 times. I would
think that if there was a bug in my scripts, it would be happening much more
than 0.0014% of the time.
Here's where it get's interesting. CGI.pm has an undocumented method called
cache() which, if called, outputs the "Pragma: no-cache" header. I found it
confusing, so just modified my copy of CGI.pm to always print Pragma:
no-cache whenever the header() method is called. It seemed to fix the
problem! I didn't get any "wrong account" reports for several months. A
few days ago, the problem came back; but then I realized a recent automatic
update to CGI.pm had overridden my hack... which seems to confirm that the
"Pragma: no-cache" header made the problem go away.
But rather than speculating, I'd like to know what is *really* going on
here. I still can't figure out why the problem was occurring in the first
place, or why the no-cache header *seems* to fix it. Does anyone have any
ideas? I'd like to understand and fix the problem for good rather than
slapping band-aids on it.
