HTTP Response Headers, Caching and MODx

Here’s my solution to a little problem I had when viewing my MODx site with Firefox (1.5). If I use the back-button or click an already visited link, FF refreshes the page from the server. Since I rely on a dodgy wireless connection with plenty of latency, this has a big impact on the responsiveness of what is a small static site. Anyone with a dail-up connection would also notice this. So I put on my Inspector Clouseau hat and started googling!
The culprit seems to be the default HTTP response headers generated by PHP when session_start() is used:

Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache

My guess is that Cache-Control: no-store should take the blame for what is perhaps FF’s valid but mistaken interpretation of some equivocal HTTP specs. With IE the back-button always fetches pages from the local cache, no matter what the header says. (At least in IE7; Bill didn’t tell me his beta was going to overwrite IE6...)
I went on to test a few sites - BBC, Delicious, Wikipedia, Slashdot etc - and whilst some re-validated, none of them churned with the back-button like MODx. In fact, the only sites I could find that used the Cache-Control headers above, apart from some obscure PHP fan-clubs, were sites built with MODx/Etomite and ...... Joomla/Mambo.
My solution was to insert the line:
session_cache_limiter(’private’);
at the beginning of (modx root)/index.php.
By modifying 1 of 2 identical MODx installations on the same server and testing a lot of different stuff - manager, quick edit, session id cookie etc, I’m pretty sure the only result of this fix to increase page load times by a factor of ten for visited links and back-button navigation. Additionally, we solve the problem of disappearing form/textarea content as mentioned in heliotrope’s post here et sur le meme sujet ici, en francais.
One could also disable the default headers with session_cache_limiter(’’); and customise your expires,cache-control, cookie settings and whatever else tickles your fancy, I’m just not qualified to advise.
Anybody else noticed the curse of the Firefox back-button? And what does the team think?
Cheers for now

I have no idea what the headers SHOULD be, but I’m very open to changing things for the next release. But you better hurry with suggestions!

Quote from: abbeyroad at Mar 21, 2006, 11:03 PM

Here’s my solution to a little problem I had when viewing my MODx site with Firefox (1.5). If I use the back-button or click an already visited link, FF refreshes the page from the server. Since I rely on a dodgy wireless connection with plenty of latency, this has a big impact on the responsiveness of what is a small static site. Anyone with a dail-up connection would also notice this. So I put on my Inspector Clouseau hat and started googling!
The culprit seems to be the default HTTP response headers generated by PHP when session_start() is used:

Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache

My guess is that Cache-Control: no-store should take the blame for what is perhaps FF’s valid but mistaken interpretation of some equivocal HTTP specs. With IE the back-button always fetches pages from the local cache, no matter what the header says. (At least in IE7; Bill didn’t tell me his beta was going to overwrite IE6...)
I went on to test a few sites - BBC, Delicious, Wikipedia, Slashdot etc - and whilst some re-validated, none of them churned with the back-button like MODx. In fact, the only sites I could find that used the Cache-Control headers above, apart from some obscure PHP fan-clubs, were sites built with MODx/Etomite and ...... Joomla/Mambo.
My solution was to insert the line:
session_cache_limiter(’private’);
at the beginning of (modx root)/index.php.
By modifying 1 of 2 identical MODx installations on the same server and testing a lot of different stuff - manager, quick edit, session id cookie etc, I’m pretty sure the only result of this fix to increase page load times by a factor of ten for visited links and back-button navigation. Additionally, we solve the problem of disappearing form/textarea content as mentioned in heliotrope’s post here et sur le meme sujet ici, en francais.
One could also disable the default headers with session_cache_limiter(’’); and customise your expires,cache-control, cookie settings and whatever else tickles your fancy, I’m just not qualified to advise.
Anybody else noticed the curse of the Firefox back-button? And what does the team think?
Cheers for now

Can someone log this in the bug tracker and I’ll pick it up and try and find a proper solution as quickly as possible? I’m researching it already. Feel free to continue sharing any information you find on the subject as it will only help speed up the process.

abbeyroad , can you share more about your finding? It will save a lot of time for our core coder Jason to solve the problem in the next release. I would also want to know more about this issue. Any information sharing or knowledge impartation will be awesome. I do notice this header information had been causing too much problem in performance and accesibility issue, considering when you’re online, and suddenly you got disconnected. With the header stating not to allow cache, your browser is basically being rendered useless, with no ability to use the back button of your precious web browser. I believe this is causing most of browsers not to cache the previous visited page.

Any clarification to this subject will be nice.

hi,


@abbeyroad:
Thanks for sharing your fix I was getting crazy with this issue that I was considering like critical because it goes against users behavior. People are used to go back by pressing back button.

I’m also happy to read the core team focus on a way to solve this limitation.

Thanks for everything you did, do and will.

I couldn’t find this in the bugtracker (http://modxcms.com/bugs/)

Anyone filed this ? Abbeyroad ? Would be best if you entered this one since you have the best knowledge of what could be improved there...

I tried adding the session_cache_limiter(’private’); code and it seemed to work OK. Only thing I did not realize was that my pages are now cached and not re-validated, so when I changed a page in tte managerI did not see the changed page in my browser. Even after a normal refresh I did not get the new page. I had to use the CTRL+Refresh to force the browser to reload the page. This happend in IE and FF. So currently I removed the code again. I guess this can be solved by sending other headers, but I didn’t have time to look at what headers would be needed.

@davidm: re-reading this thread, I just realised that the onus seems to be on me to post to bugtracker. But the fact of the matter is that I am far from being an expert on the subject and expected one of the dev team to take up the baton. The little knowledge I have of HTTP headers was the result of looking for a solution to what seems a very obvious MOD/Firefox-backbutton issue. I’m just surprised almost no one else has picked up on this. I’ll post some links and stuff in a few days. In the meantime,

/* start off-topic

here’s the site of someone yet to discover MODx http://www.desordre.net/ (tag: sont fous, ces francais)

end off-topic*/

Cheers!

Hi,

Thanks for sharing this information. I would suggest that the headers be customized and loaded based on the type of content being delivered. For cacheable pages then something like this can be used otherwise your dynamic pages will become useless.

Still couldn’t find this from the bugtracker, so I add it there with information from the posts. Task #457. I think this is quite nasty bug, generates much "unneeded" traffic on servers.