Disappearing $_COOKIE question

I’m not sure that I buy that reply...

I can’t make sense of the answer I was given by yngve. I don’t know enough about browser development.

Though the issue is to do with the way caching works in Opera. It just seems to have unique effect when put together with MODx and my code for the cart summary. If I get enough time I might try 0.9.7 out of svn, I remember reading that it does not use eval(), so maybe it does things differently enough to get different results.

What he said was that the browser will often send a request to the server "is this page updated since xxx date/time?" and if the page has not been updated since that date/time the server does not actually go get the page, it just returns a simple "no" and the browser will then display its own cached version. This saves bandwidth and server resources.

However, if the server is not configured correctly, it will look at the actual php file involved, which in our case is index.php, and of course it has not changed at all. So a new copy of the page will not be sent, even if the output of the php file most certainly has changed.

He says that other browsers just send page requests instead of this "is the page updated" request, which according to him is a Bad Thing.

What, exactly, this has to do with your situation I’m not clear on.

If this is only happening on the initial start page, then since the actual page request is for "yourdomain.com/", which the server resolves to "yourdomain.com/index.php" with no query string, then the server checks for any change to the "index.php" file and of course finds it has not changed. All other pages are requested as "index.php?xxx=...." with a query string (the server resolves any friendly URLs to this via the .htaccess rewrite rules), and this triggers the server to send the page instead of just the "not changed" information.

With regards to your last paragraph, does that mean that query strings in general will cause the server to send the page or does this only work with .htaccess?

In general; however it’s quite possible that I’m wrong, and it’s the request for "mypage.html" which does not exist that causes the server to send the full page in return, while any "index.php..." request will check the index.php file itself for changes.

If Opera indeed works the way that Susan is interpreting yngve’s reply (which seems to be a reasonable interpretation to me), then that’s a pretty major and fundamental flaw in my opinion. I know that Opera does more and different caching than most other browsers, but if it checks for the last physical change to PHP/HTML files on the server then it’s never going to work right with most dynamic pages. That seems too severe a design flaw to be true, however, so I expect that the reply was confusing or we’re misunderstanding it.

I think that most browsers decide whether to retrieve new versions of PHP/HTML files depending upon the header that they received the last time they downloaded them. So if there’s a header that says not to cache that page, they request it again, and if there’s a header that says it doesn’t expire until x time, it doesn’t make any request for that page at all until that time. So I can’t see how checking the last time that a physical file was changed on the server could possibly be faster than not checking or requesting anything...

He seems to be saying that the server needs to be configured to not check the file modification time of dynamic files like PHP, but I find it hard to believe that an Apache server would execute PHP files and yet behave as he’s describing (then again, I’ve been wrong before).

Apache mod_expires: http://httpd.apache.org/docs/1.3/mod/mod_expires.html

http://my.opera.com/yngve/blog/2007/02/27/introducing-cache-contexts-or-why-the

Above is yngve’s blog link detailing Opera reasoning. I skimmed through it quickly and can understand it applying to browser history and "back buttons", but in the case of accessing the same page via a link I would prefer it being treated as a complete reload.

Since it is an Opera issue, I guess I need an older version of Wayfinder which still uses index.php?id=## for the start page as a work around the problem.

Gratitude to everyone who has helped me in this matter. I appreciate it.

I hope this helps someone else if they get into the same situation.

I’ve messaged kylej to send me a copy of an older version of Wayfinder since I do not know where to obtain it.

Do you really want to do that just because it seems as if the latest Opera may be having this problem on your server? That seems like an extreme thing to do just for a bug in a minor browser to me. I think the most that I’d do is use a script forward only Opera to a link with a query string, but if it really is the way that yngve is describing it then there ought to be a way to fix this on your server without needing to jump through so many hoops.

@sottwell : thanks for the link.

I am not sure what Apache mods are supported by the hosting service.

@ZAP : I don’t want to hardcode the link with a query string anywhere as the person I am doing the site for may make changes and then I’ll start getting support requests.

mod_expires I am interested in testing. Wayfinder would be quicker than getting changes made on the hosting service.

I have options for a solution now, which is nice.