Message boards : Web interfaces : Cached project forum pages?
Message board moderation
Author | Message |
---|---|
![]() Send message Joined: 3 Apr 06 Posts: 547 ![]() |
Since maybe a month or so ago, as some projects open up or others upgrade their server SW, I'm very often noticing one annoying problem - I see a list of threads, some of them marked unread, then open few one after another, read through, go back and forth to another ones... After reading 5-6 threads (and loosing an overview, which ones), I can still see them marked as unread and when opening them, the same (previously unread) posts are still marked as such. Just explicitly refreshing any page 'repairs' the particular page and the unread marks disappear. First I wanted to blame my browsers' caching settings, but it is still happening on one group of projects and never on other group (with obviously older forum SW). Did anyone else notice it too? Were there any related changes in the server SW, which could be 'repaired', if the behavior is not intentional (I could imagine e.g. to spare some access to DB here and there)? Peter |
Send message Joined: 5 Oct 06 Posts: 5111 ![]() |
Since maybe a month or so ago, as some projects open up or others upgrade their server SW, I'm very often noticing one annoying problem - I see a list of threads, some of them marked unread, then open few one after another, read through, go back and forth to another ones... After reading 5-6 threads (and loosing an overview, which ones), I can still see them marked as unread and when opening them, the same (previously unread) posts are still marked as such. Just explicitly refreshing any page 'repairs' the particular page and the unread marks disappear. Quite an active discussion about this at SETI: Yellow pages still here! (someone coined the term "Yellow Pages" for the yellow 'unread' marker). The general consensus seems to be that people would prefer the old (uncached) version, where the page is re-loaded (and hence a new, updated set of yellow pages shown) when the browser 'back' button is clicked. It's cross-platform, and cross-browser, so it's clearly a change in the way the pages are being sent out by the new versions of the forum software. Edit - the change has been tracked down to <!-- $Id: util.inc 14747 2008-02-15 15:25:44Z davea $ --> |
![]() Send message Joined: 3 Apr 06 Posts: 547 ![]() |
Quite an active discussion about this at SETI: Yellow pages still here! [...] It's cross-platform, and cross-browser, so it's clearly a change in the way the pages are being sent out by the new versions of the forum software. Thanks for the heads-up, Richard. At least I do not feel so unsure anymore. Edit - the change has been tracked down to ...so my time approximate was pretty good :-) Peter |
Send message Joined: 19 Jan 07 Posts: 1179 ![]() |
Forum pages are never cached. I have noticed this problem with unread messages, but it can't be a cache problem... |
![]() Send message Joined: 3 Apr 06 Posts: 547 ![]() |
Forum pages are never cached. I have noticed this problem with unread messages, but it can't be a cache problem... Well, I'm not able to express it technically correct, but maybe a better expression would be "not reread from server upon pressing 'Page Back' buton"? Peter |
![]() Send message Joined: 3 Apr 06 Posts: 547 ![]() |
|
![]() Send message Joined: 12 Feb 06 Posts: 232 ![]() |
cookies active? Oh god, that's going to screw up a lot of things. -- Eric Myers "Education is not the filling of a pail, but the lighting of a fire." -- William Butler Yeats |
Send message Joined: 5 Oct 06 Posts: 5111 ![]() |
Forum pages are never cached. I have noticed this problem with unread messages, but it can't be a cache problem... Well, anything which can be cleared by pressing F5 feels like a cached page to me. Are you thinking server-side cache, or client-side (browser) cache? |
![]() Send message Joined: 12 Feb 06 Posts: 232 ![]() |
So I just saw this problem on these forums. After reading a thread I pressed the browser back button and got the list of threads, and the one I had read was still marked as unread (the "yellow" marker). Clicking on the URL in the address bar and hitting Enter reloaded the page and cleared the marker. This is the browser caching the page because it thinks it has a current copy. I wonder if the PHP session mechanism turns off such caching? I'm actually going to be digging into some code which will let me look at the headers in such an exchange, so I'll keep my eye out for it. If so, then we'll need to convince David to put PHP session support back in, or else put the right headers in himself for the forum pages. But let me see what I can see from the headers first... -- Eric Myers "Education is not the filling of a pail, but the lighting of a fire." -- William Butler Yeats |
Send message Joined: 19 Jan 07 Posts: 1179 ![]() |
If so, then we'll need to convince David to put PHP session support back in, or else put the right headers in himself for the forum pages. But let me see what I can see from the headers first... Well, all the session stuff could do is send appropriate caching headers, so it would be easier to just send the same without using sessions. |
![]() Send message Joined: 12 Feb 06 Posts: 232 ![]() |
Well, all the session stuff could do is send appropriate caching headers, so it would be easier to just send the same without using sessions. The relevant headers appear to be: Expires: Thu, 19 Nov 1981 08:52:00 GMT Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0 I'd guess that the date changes -- the point is that it's a long time in the past. Sure, you can re-invent this wheel, but PHP sessions already work just fine, and it's not that complicated. Why pull it out and break stuff like this? -- Eric Myers "Education is not the filling of a pail, but the lighting of a fire." -- William Butler Yeats |
Send message Joined: 25 Nov 05 Posts: 1654 ![]() |
I've been trying to test this since the original post, but often forget. None of the cpdn sites has this problem; you click on a topic, then on a thread, and the 2 markers are yellow. When you click the back button, the markers have gone to a 'read' status. Here, though, when you click the back button, the markers are still yellow. Going back and forwards leaves it yellow. Clicking on the topic again will set the thread as read, and now, going back will show the topic as read also. I've only noticed this change in behavour in the last couple of weeks. |
Send message Joined: 19 Jan 07 Posts: 1179 ![]() |
Sure, you can re-invent this wheel, but PHP sessions already work just fine, and it's not that complicated. Why pull it out and break stuff like this? PHP sessions add a session ID cookie. If nothing is stored in the session, why send a cookie. And caching could be greatly improved. Don't send no-store, no-cache, must-revalidate, post-check=0, pre-check=0. Let it store, let it cache, but make sure it updates when the page changes. One advantage is that when browsing offline, you can still see threads on your browser cache. You can't do that if the server makes it expire immediately. It's tricky to use Last-Modified and If-Modified-Since for this, because it has to take care of last post to any thread, unread status, thread view count (or maybe just ignore this part?), sort order, language, login status, etc etc. For pages with so much dynamic data that could change, I found it's best to use an ETag instead of a modification date. Build a string with the last post date and view count of every single thread shown on that page, sort order, a bitmask of read threads, and any other relevant informatin. Hash it, use it as a ETag. Compare it when the client sends If-Match. If it matches, 304 Not Modified. If it doesn't, send the page as usual. |
Send message Joined: 5 Oct 06 Posts: 5111 ![]() |
Additional information from the SETI thread: SETI has: <!-- SVN VERSIONS --> <!-- $Id: translation.inc 14562 2008-01-15 22:22:08Z davea $ --> <!-- $Id: pm.inc 14019 2007-11-01 23:04:39Z davea $ --> <!-- $Id: team.inc 14394 2007-12-18 20:28:08Z davea $ --> <!-- $Id: text_transform.inc 14264 2007-11-20 00:55:35Z davea $ --> <!-- $Id: stats_sites.inc 14562 2008-01-15 22:22:08Z davea $ --> <!-- $Id: user.inc 14626 2008-01-28 16:12:28Z boincadm $ --> <!-- $Id: profile.inc 14562 2008-01-15 22:22:08Z davea $ --> <!-- $Id: util.inc 14747 2008-02-15 15:25:44Z davea $ --> sending HTTP/1.x 200 OK Date: Fri, 14 Mar 2008 07:34:45 GMT Server: Apache/2.2.6 (Fedora) X-Powered-By: PHP/5.2.4 Connection: close Transfer-Encoding: chunked Content-Type: text/html; charset=UTF-8 CPDN Beta has: <!-- SVN VERSIONS --> <!-- $Id: translation.inc 14562 2008-01-15 22:22:08Z davea $ --> <!-- $Id: pm.inc 14019 2007-11-01 23:04:39Z davea $ --> <!-- $Id: team.inc 14394 2007-12-18 20:28:08Z davea $ --> <!-- $Id: text_transform.inc 14264 2007-11-20 00:55:35Z davea $ --> <!-- $Id: stats_sites.inc 14562 2008-01-15 22:22:08Z davea $ --> <!-- $Id: user.inc 14546 2008-01-14 16:32:34Z davea $ --> <!-- $Id: profile.inc 14562 2008-01-15 22:22:08Z davea $ --> <!-- $Id: util.inc 14474 2008-01-06 18:09:23Z boincadm $ --> sending HTTP/1.x 200 OK Date: Fri, 14 Mar 2008 12:51:31 GMT Server: Apache/2.2.6 (Fedora) X-Powered-By: PHP/5.2.4 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 Connection: close Transfer-Encoding: chunked Content-Type: text/html; charset=UTF-8 The only SVN changes are user.inc (SETI's is 14 days newer) and util.inc (40 days newer). |
![]() Send message Joined: 12 Feb 06 Posts: 232 ![]() |
PHP sessions add a session ID cookie. If nothing is stored in the session, why send a cookie. There is at least one thing stored for the "session", some kind of authentication token. And if you start a PHP session you can visit pages which don't use stored info, but then come back to those that do and everything is still as it was. And it's a single cookie containing a short (32 character?) string. Not a big deal.
It's not clear to me that all browsers will do the right thing (think IE6). But if they do, then cutting back on these may be fine. This may be configurable in PHP (I have not checked). I checked an older version of the forum code for use of $_SESSION and find that it's only really used to store the authenticator, to allow someone to authenticate and then move around the site at will and we know who you are (and could even restrict access to some pages based on who you are). So replacing that single token with a cookie is quite reasonable. I therefore retract my earlier statement about it screwing up a lot of other things. For the I2U2 project I'm working on I have a set of pages which require saving a lot more state between pages, so PHP session has been very useful there. That lead me to expect it would be necessary for the BOINC forums, and it turns out it's not. Still, sessions are not all that complex, and can be quite useful. In any case, perhaps someone should open a Trac ticket suggesting that pages which should not be cached be given the appropriate HTTP headers directing that this be so? Then someone has to do this to each page to which it applies. -- Eric Myers "Education is not the filling of a pail, but the lighting of a fire." -- William Butler Yeats |
![]() Send message Joined: 12 Feb 06 Posts: 232 ![]() |
Richard Haselgrove wrote: ...Additional information ...from CPDN Beta The expiration date is exactly the same as what I found, on completely different pages (code I'm still working on, but same PHP version). So PHP just sends that 26 year old date. I wonder who's birthday it is? -- Eric Myers "Education is not the filling of a pail, but the lighting of a fire." -- William Butler Yeats |
Send message Joined: 19 Jan 07 Posts: 1179 ![]() |
PHP sessions add a session ID cookie. If nothing is stored in the session, why send a cookie. Nope. BOINC uses its own 'auth' cookie for login. |
![]() Send message Joined: 12 Feb 06 Posts: 232 ![]() |
Nicolas wrote:
And then stored it in $_SESSION (at least until last month). -- Eric Myers "Education is not the filling of a pail, but the lighting of a fire." -- William Butler Yeats |
Send message Joined: 10 Mar 08 Posts: 7 ![]() |
Quick crosspost - I believe that using either session_cache_limiter() or session.cache_limiter would solve the problem (to be extra clear - that has to be done on the server side in the PHP code or configuration). |
![]() Send message Joined: 12 Feb 06 Posts: 232 ![]() |
Zeev wrote: Quick crosspost - I believe that using either session_cache_limiter() or session.cache_limiter would solve the problem (to be extra clear - that has to be done on the server side in the PHP code or configuration). Thanks! -- Eric Myers "Education is not the filling of a pail, but the lighting of a fire." -- William Butler Yeats |
Copyright © 2024 University of California.
Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License,
Version 1.2 or any later version published by the Free Software Foundation.