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

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

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 $ -->

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

<!-- $Id: util.inc 14747 2008-02-15 15:25:44Z davea $ -->

...so my time approximate was pretty good :-)

Peter

Forum pages are never cached. I have noticed this problem with unread messages, but it can't be a cache problem...

---

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

cookies active?

Possibly Changeset 14735 or related?

Peter

cookies active?

Possibly Changeset 14735 or related?

Peter

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

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?

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

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.

---

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

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.

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.

---

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).

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.

...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.

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

Richard Haselgrove wrote:

...Additional information ...from CPDN Beta

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

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

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.

Nope. BOINC uses its own 'auth' cookie for login.

---

Nicolas wrote:

Nope. BOINC uses its own 'auth' cookie for login.

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

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).

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