Forum Moderators: phranque
What I mean is, if I jump from one to the next to the next, and back, over and over, eventually Apache stops serving up the new page, and just keeps resending the same page. Even if I switch browsers. Even if I telnet localhost 80 and GET it directly, it still serves teh stuck page, not the requested page, so it's not on the browser side. access.log shows the right page being requested, and there's nothing in error.log. It seems to think it's sending the right page, but it sends the wrong page. If I reload the stuck page, then try a different page, it starts working again.
I tried commenting out of httpd.conf:
LoadModule cache_module modules/mod_cache.so
LoadModule mem_cache_module modules/mod_mem_cache.so
But it didn't help. I've tried it with and without in php include to header.inc.php, and it's not happening on the browser end. Anyone have any experience with this?
Jim
URL's like:
http://host.ip.addr/db/add.php
http://host.ip.addr/db/update.php
http://host.ip.addr/db/search.php
Add and update have cookies. Search doesn't. All that gets cookied is username. This happens without any GETs to dynamic query strings. They all use a PHP include for a "header.inc.php" page, but it happens even if I disable that.
[edited by: jdMorgan at 2:47 pm (utc) on Jan. 4, 2010]
[edit reason] de-linked. [/edit]
What I mean is, if I jump from one to the next to the next...
So that's still not clear.
However, in addition to that line of thought, another has popped up since you last posted: Try firing up the "Live HTTP Headers" add-on for FireFox/Mozilla and look at your server responses with an eye toward "What do public (network) caching proxies see as regards Cache-Control, Expires, Etag, Last-Modified, and server status response headers in your server responses?" If Firefox also shows this 'stuck pages' behavior, then the results reported by the LHH add-on should be valid.
The point here is that you may be looking at your server through a network proxy that caches pages. Since network caches use the 'public' Cache-Control scope while browsers use the 'private' scope, and since you've reported that forcing a page reload clears the problem but switching browsers does not, *and* that you've disabled server-side caching to no avail, the only place left to look is at the in-between space, which would include caching proxies in the public network -- for example, ISP-edge and corporate-network caching proxies.
There are a few inconsistencies here but rather than focus on them, it would be worth checking out the HTTP headers view of things, if for no other reason than to get a view of the problem from a different angle.
Jim
I think you're right that it's happening in a network proxy. But I looked at the Live HTTP Headers add-on and it didn't give me anything. When I include the PHP header() for cache control, it shows up.
http://server.ip.addr/db/index.php
GET /db/index.php HTTP/1.1
Host: server.ip.addr
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.6) Gecko/20091201 Firefox/3.5.6
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: http://server.ip.addr/db/index.php
Cookie: dbusername=USERNAME; navigator_sections=status.alerts.reporting; opsview_web_session=LONG NUMERIC STRING; PHPSESSID=LONG NUMERIC STRING; JSESSIONID=LONG NUMERIC STRING.node1
HTTP/1.x 200 OK
Date: Mon, 04 Jan 2010 14:38:32 GMT
Server: Apache/2.2.9 (Unix) mod_ssl/2.2.9 OpenSSL/0.9.7d DAV/2 PHP/5.2.6
X-Powered-By: PHP/5.2.6
Cache-Control: no-cache, must-revalidate
Pragma: no-cache
Content-Length: 1704
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: text/html
[edited by: jdMorgan at 2:47 pm (utc) on Jan. 4, 2010]
[edit reason] de-linked [/edit]
What I meant about "next page" is just jumping from one to the next. I have links in the top of the page to "add.php" "index.php" and "search.php". If I click from one to the next for a while, it eventually happens.
Try modifying the PHP header configuration (keep a back-up, as this is only a temporary change for testing) to specify "private, must-revalidate" or even "no-store". After deleting your browser cache, testing should then make clear whether the caching is in the network or is still being done server-side (for some reason).
Jim
<a href='search.php'>Search Page</a>
-
<a href='add.php'>Add Page</a>
-
<a href='index.php'>Full Index</a><br><br>
And I tried the headers:
header( "Cache-Control: no-cache, must-revalidate, no-store" );
header( "Pragma: no-cache" );
To no avail.
However, keep in mind that plain-old Apache without a bunch of extra modules bolted on is just a HTTP server: You ask it for a URL, it serves you the content of a file (or runs a script to generate content). As HTTP is a stateless protocol, HTTP servers have no 'memory' whatsoever of any previously-handled HTTP requests aside from the fact that these requests are logged (However, the server makes no use of these logs). Therefore the current state of the server itself does not depend on previous requests.
Adding sessions and cookie-based scripts and add-on caching modules into the mix complicates things, and the problem is most likely to be found in one of these functions. These functions *do* introduce dependencies on previous requests into the pure-HTTP-server environment. So, it was wise to disable your server-side caching as a first step, and I suggest you continue down that path for now, investigating all functions which involve previous-request and client-state dependencies. Make double-sure all server-side caching is off, and then start looking at sessions and cookies. The headers checker is useful in this regard as well.
Jim
