Bug in My Little Forum (Bugs)

by danielb987, Wednesday, March 15, 2017, 15:18 (251 days ago)
edited by Auge, Thursday, March 16, 2017, 07:25

Hi,

I have now installed My Little Forum version 2.4.2 and I have found a bug related to Internet Explorer.

In the file index.php at lines 209 to 214 there is an IF-statement that checks if the web browser is Internet Explorer and if not, sends the header 'Cache-Control: public, max-age=300'.

The problem is that Internet Explorer no longer declare itself with the header HTTP_USER_AGENT as "MSIE" but instead as "Mozilla/5.0 (Windows NT 6.3; WOW64; Trident/7.0; rv:11.0) like Gecko".

See this page on why:
http://stackoverflow.com/questions/5125438/why-do-chrome-and-ie-put-mozilla-5-0-in-the-user-agent...

This results in that Internet Explorer caches the web page and therefore doesn't update the web page as it should. For example, if I go to the admin page and setting for spam protection and then change a setting and click "save" and then returns to the admin menu page and then go back to the page for spam protection settings, the settings has not been changed. If I reload the page, the settings is correct.

I have the same problem when I log out from the forum.

The solution on this problem is to change line 213 in index.php from:

header('Cache-Control: public, max-age=300');

to:

header('Cache-Control: private, no-cache="set-cookie"');

since as far as I know, there is no easy way to detect Internet Explorer. I have run a PHP script with phpinfo() from Internet Explorer and I cannot see any useful PHP variable to detect Internet Explorer.

I have another forum with the forum software phpBB3 and that forum sends the header 'Cache-Control: private, no-cache="set-cookie"' so that seems the best way to handle the problem.

Best regards,
Daniel Bergqvist

Avatar

Bug in My Little Forum

by Magma, Wednesday, March 15, 2017, 15:50 (251 days ago) @ danielb987

This is probably the reason why IE keeps logging me out and not going back to the right page as in the thread I created http://mylittleforum.net/forum/index.php?id=8505

I've found My Little Forum has never worked right in IE since using MLF.

Bug in My Little Forum

by danielb987, Wednesday, March 15, 2017, 16:20 (251 days ago) @ Magma

This is probably the reason why IE keeps logging me out and not going back to the right page as in the thread I created http://mylittleforum.net/forum/index.php?id=8505

I've found My Little Forum has never worked right in IE since using MLF.

I'm using Internet Explorer 11 in desktop version on Windows 8.1. I never uses Metro style in Windows 8.1.

But you are probably having the same problem as me.

Best regards,
Daniel

Avatar

Bug in My Little Forum

by Auge ⌂ @, Wednesday, March 15, 2017, 15:56 (251 days ago) @ danielb987

Hello

Thank you for the report.

In the file index.php at lines 209 to 214 there is an IF-statement that checks if the web browser is Internet Explorer and if not, sends the header 'Cache-Control: public, max-age=300'.

The problem is that Internet Explorer no longer declare itself with the header HTTP_USER_AGENT as "MSIE" but instead as "Mozilla/5.0 (Windows NT 6.3; WOW64; Trident/7.0; rv:11.0) like Gecko".

Not only, that the IE does not declare itself as "MSIE", the "Microsoft Internet Explorer" was renamed to "Internet Explorer" ("IE") and was succeeded by "Edge".

This results in that Internet Explorer caches the web page and therefore doesn't update the web page as it should.

The solution on this problem is to change line 213 in index.php from:
header('Cache-Control: public, max-age=300');
to:
header('Cache-Control: private, no-cache="set-cookie"');

I'm not convinced. With the code the browsers should cache the pages (for 300 seconds (5 minutes)). The IE was excluded from this solution because of problems as stated in the comment in front of the line #213 (#211 f.).

I have another forum with the forum software phpBB3 and that forum sends the header 'Cache-Control: private, no-cache="set-cookie"' so that seems the best way to handle the problem.

We will investigate and discuss this. Thank you.

Tschö, Auge

--
further development of mlf1

Bug in My Little Forum

by danielb987, Wednesday, March 15, 2017, 16:15 (251 days ago) @ Auge

The solution on this problem is to change line 213 in index.php from:
header('Cache-Control: public, max-age=300');
to:
header('Cache-Control: private, no-cache="set-cookie"');


I'm not convinced. With the code the browsers should cache the pages (for 300 seconds (5 minutes)). The IE was excluded from this solution because of problems as stated in the comment in front of the line #213 (#211 f.).

What the web browser SHOULD DO and what the web browser ACTUALLY DOES is two complete different things. :-D

By doing this change, and this change only, the problem was solved.

Unless the web server is very busy, there is not much need for cache. For the web sites I'm responsible for, web cache is not needed at all.

Best regards,
Daniel

Avatar

Bug in My Little Forum

by Auge ⌂ @, Thursday, March 16, 2017, 08:29 (250 days ago) @ danielb987
edited by Auge, Thursday, March 16, 2017, 08:55

Hello

The solution on this problem is to change line 213 in index.php from:
header('Cache-Control: public, max-age=300');
to:
header('Cache-Control: private, no-cache="set-cookie"');


I'm not convinced. With the code the browsers should cache the pages (for 300 seconds (5 minutes)). The IE was excluded from this solution because of problems as stated in the comment in front of the line #213 (#211 f.).


What the web browser SHOULD DO and what the web browser ACTUALLY DOES is two complete different things. :-D

???

By doing this change, and this change only, the problem was solved.

We will see. The header was introduced, because the Firefox jumped not to the scroll position of the prior page when using the browsers back button without the header. On the other hand the MSIE stored not the folding state of the threads on the main page with this header. Thatswhy this browser was excluded from the header.

We have to check, if your solution is not only the solution for the IE but also not the introduction of a misbehavior in other browsers.

Unless the web server is very busy, there is not much need for cache. For the web sites I'm responsible for, web cache is not needed at all.

I strongly disagree [edit]with this generalised form[/edit]. There is not only the more or less busy server, there is on the visitors side also the device(s) with internet connections with restrictions in speed or in the available monthly data volume. It's i.e. simply unnecessary to serve the background images and the images of the icons on every request. The HTML with the perhaps changed content on the other hand should be actualised (at least) within a short time without loosing the information about the state of the pages.

It might be a part of the solution to store a few more informations about the state in the users browser on the server and in the browser (JavaScript's localStorage and sessionStorage).

Tschö, Auge

--
further development of mlf1

Bug in My Little Forum

by danielb987, Thursday, March 16, 2017, 10:12 (250 days ago) @ Auge

What the web browser SHOULD DO and what the web browser ACTUALLY DOES is two complete different things. :-D


???

What I mean is that there has been a lot of frustration among web developers that different web browsers doesn't behave as they should. And Internet Explorer is a great sinner in this case.

Unless the web server is very busy, there is not much need for cache. For the web sites I'm responsible for, web cache is not needed at all.


I strongly disagree [edit]with this generalised form[/edit]. There is not only the more or less busy server, there is on the visitors side also the device(s) with internet connections with restrictions in speed or in the available monthly data volume. It's i.e. simply unnecessary to serve the background images and the images of the icons on every request. The HTML with the perhaps changed content on the other hand should be actualised (at least) within a short time without loosing the information about the state of the pages.

I live in a country there most people has an Internet connection of 100 Mbit/s and there an Internet connection of 10 Mbit/s is considered as slow. And there the problem with monthly data volume is that people are watching movies on their cell phones.

But I do understand what you are saying and that people in other countries than Sweden has a lot slower Internet connections.

However, the amount of data of a page from web forum like My Little Forum is very small in comparison to most other web pages, like news papers and Facebook. So for most visitors I still belive that it's not necessary to cache the pages from My Little Forum in the web browser.

And I got the solution to the problem from phpBB3, maybe the biggest software for web forums.

best regards,
Daniel

Avatar

Bug in My Little Forum

by Auge ⌂ @, Thursday, March 16, 2017, 10:51 (250 days ago) @ danielb987

Hello

Unless the web server is very busy, there is not much need for cache. For the web sites I'm responsible for, web cache is not needed at all.


I strongly disagree [edit]with this generalised form[/edit].


I live in a country there most people has an Internet connection of 100 Mbit/s and there an Internet connection of 10 Mbit/s is considered as slow.

That's fine for you. :-)

In Germany many people have connections with 6 or 16 MBit/s (gross). Faster connections (50 up to 400 MBit/s (gross)) are available mostly in towns. But that's not the problem I meant. The problem is the form of contracts for connection on mobile phones. There are limits from a few hundred megabytes to a few gigabytes per month. There are contracts, where you'll pay for more volume without ordering, with other contracts you can pay for more volume after ordering it and, last but not least, there are contracts, where your speed gets reduced to a few kilobits per second. Finally you don't want to reach the limit.

With LTE you can have a lot of month left, when your data volume is void.

And there the problem with monthly data volume is that people are watching movies on their cell phones.

That's not a "problem", that's one of the normal use cases.

However, the amount of data of a page from web forum like My Little Forum is very small in comparison to most other web pages, like news papers and Facebook.

Yes, it is. But the visits in a MLF-driven forum are normally not the only accesses to the internet.

And I got the solution to the problem from phpBB3, maybe the biggest software for web forums.

As said before, we will investigate and test it. Thank you so far.

Tschö, Auge

--
further development of mlf1

Bug in My Little Forum

by danielb987, Wednesday, March 15, 2017, 16:27 (251 days ago) @ danielb987

Here is a perfect illustration of the problem. I took this screen dump AFTER I had replied to the entry of Magma. As you can clearly see, my reply to the entry of Magma is not visible. This is a HUGE problem.

Best regards,
Daniel

[image]

Avatar

Bug in My Little Forum

by Magma, Wednesday, March 15, 2017, 23:10 (251 days ago) @ danielb987

Daniel I implemented your solution and it fixed my problem so thanks.

Avatar

Bug in My Little Forum

by Auge ⌂ @, Thursday, March 16, 2017, 07:32 (250 days ago) @ danielb987

Hello

The solution on this problem is to change line 213 in index.php from:

header('Cache-Control: public, max-age=300');

to:

header('Cache-Control: private, no-cache="set-cookie"');

Because of your and magmas reports, that your solution works with IE (what's with Edge?), I will test your solution in other browsers. There it has to work too.

Tschö, Auge

--
further development of mlf1

Avatar

Bug in My Little Forum

by Auge ⌂ @, Tuesday, April 11, 2017, 13:25 (224 days ago) @ danielb987

Hello

After reading a few articles about the issue, I'm a bit confused. The IE is not safely identifiable with it's user-agent-string. That causes the IE to use and misinterpret a caching directive, that should stay hidden from this browser (because of an issue from the year 2007 (wow!)).

Because we can't identify the IE, we have to use a caching header, that works in all browsers and we have to remove the switch to distinguish between IE and all other browsers.

I found a nice article about the possible values of the caching header from the year 2008 on archive.org. The no-cache-directive says that the browser can cache the page but should (but not must) request a revalidation of the page by the web server. But the IE and the FF act on this directive as it would be no-store (no caching of the requested page ever!). That's in opposition to your report of unwanted caching in the IE.

Changing the cache-control from public to private seems to be reasonable. The value public let public proxy servers store the requested page. When set to private only the browser stores the page in it's own cache. But when we decide to change to no caching (Cache-control: no-store;) we wouldn't need a setting for public or private caching at all.

My problem is the validation of the changes because I haven't a IE on my systems. So I request for help. Please test the following caching headers for their behaviour in different browsers.

header('Cache-Control: private, max-age=300'); // only browser cache, must re-validate after 5 minutes
 
header('Cache-Control: private, must-revalidate'); // only browser cache, must re-validate on every request (my favourite)
 
header('Cache-Control: no-cache, no-store'); // no cache at all, no-cache as fallback as suggested in the linked article (from 2008!)

Tschö, Auge

--
further development of mlf1

Bug in My Little Forum

by danielb987, Wednesday, April 12, 2017, 03:21 (223 days ago) @ Auge

Hello

I found a nice article about the possible values of the caching header from the year 2008 on archive.org.

Very interesting article. It has given me new insight about how the cache works.

My Little Forum uses the header: Cache-Control: public, max-age=300

This header allows cache and that the page may be stored in the cache for 300 seconds. Both the web browser itself and proxies in between the web server and the web browser are allowed to store the page in their cache.

The header I suggest, based on how the forum software phpBB3 handles it, is the header: Cache-Control: private, no-cache="set-cookie".

This header tells that no proxies should cache the page but that the browser may. Also it tells the browser not to cache the "set-cookie" header.

The problem with MLF and IE is not that the page gets in the cache, but that IE does not check with the server if the page has changed. By setting the cache control to Cache-Control: public, max-age=300, I think that IE thinks that this page probably won't change in the next 300 seconds. Think of a news article for example. In the HTTP 1.1 standard I don't see a requirement for the web browser to check with the server if the page has changed, unless max-age has expired. In other words, I think IE is following the HTTP 1.1 standard about cache.

The header Cache-Control: private, no-cache="set-cookie" allows cache, except of the set-cookie header. I'm not entirely sure, but I think that the use of no-cache="set-cookie" forces IE to do a request to the web server in order to get the new set-cookie header, and when doing that it also sees if the page has been changed.

The header Cache Control: No-cache tells the web browser to not use the cache at all. It means that it always have to load the entire page from the server. Therefore, the use of Cache Control: No-cache uses more bandwidth than the use of Cache-Control: private, no-cache="set-cookie" since the web browser in the later case only needs to load the headers of the page from the server and not the entire page, unless the page has changed.

The header Cache Control: No-store tells the web browser to not store the web page in the cache at all. This is useful for sensitive data like bank transactions. If the web server allows you to do bank transactions and that the web page shows the latest bank transactions, you don't want that information to be stored in the cache on the client's hard drive where other people may be able to access the data. In this case, there is no reason to deny the web client to store the page in the cache since there is no sensitive data on the page (like bank transactions).

The header Cache-Control: private, max-age=300 may give the same result as Cache-Control: public, max-age=300, in the meaning that the web browser may interpret it that the page will probably not change in the next 300 seconds. And we don't want that. It's important that the browser checks on every request if the page has changed. It don't need to reload the entire page on each request, but the browser needs to ask the web server if the page is changed.

The header Cache-Control: private, must-revalidate is for special cases. You can read the HTTP 1.1 standard about must-revalidate for more information.

The header Cache-Control: no-cache, no-store tells the browser to not cache the page and to not store the page in the cache. I don't think this is nessesary.

----------------------------------

One of the largest web forum software, phpBB, is using the header: Cache-Control: private, no-cache="set-cookie".

In my forum, with 2000 users, everything works fine since I changed to the code:
header('Cache-Control: private, no-cache="set-cookie"');

My users uses different web browsers, like IE, Firefox, Chrome, Android and iPhone/iPad. If something doesn't work, they tell me. And I haven't heard anything that would indicate that the forum would have problems with cache.

Best regards,
Daniel

Avatar

Bug in My Little Forum

by Auge ⌂ @, Wednesday, April 19, 2017, 20:26 (216 days ago) @ danielb987

Hello

The header Cache-Control: private, no-cache="set-cookie" allows cache, except of the set-cookie header. I'm not entirely sure, but I think that the use of no-cache="set-cookie" forces IE to do a request to the web server in order to get the new set-cookie header, and when doing that it also sees if the page has been changed.

The header Cache Control: No-cache tells the web browser to not use the cache at all. It means that it always have to load the entire page from the server.

No, that's not correct. The header tells the browser that he CAN use the cache. But he should request the server for changes. At that point it's the same behaviour like must-revalidate.

The header Cache-Control: private, must-revalidate is for special cases. You can read the HTTP 1.1 standard about must-revalidate for more information.

There is no "special case" at all. The header "must-revalidate" means, that the browser MUST request the source server for changes every time, he requests the page.

In the case of MLF the main page might be changed often. The mandatory additional request might be answered with status 304 (no change, load the page from the cache), but more often with status 200, what leads to loading the page from the server. That's what we want.

The pages of the entries itself are changing more or less seldom. The threaded and the linear view of a thread may change often in a very active forum, the pages of entries in the single-entry-view will only change when an entry was edited or if the thread got new entries (the thread tree below the entry changes in that case). When nothing changed, we want the users browser to load the page from the cache.

In my forum, with 2000 users, everything works fine since I changed to the code:
header('Cache-Control: private, no-cache="set-cookie"');

My users uses different web browsers, like IE, Firefox, Chrome, Android and iPhone/iPad. If something doesn't work, they tell me. And I haven't heard anything that would indicate that the forum would have problems with cache.

Because of the different behaviour of the browsers on one hand and my inability to test them all on the other hand I have to believe what you say. Additionally I don't believe, that the team of phpBB, which has much more resources, would use a header a long time, when it's misbehaving is noticed. But my gut instinct tells me to enforce the revalidation of a page at request. The correct way to do it is the directive "must-revalidate" as – away from the browsers behaviour – the standard points out.

If the phpBB-solution solves this issue in practice too, there would be no need to ignore this probably well proven solution. To check, wich solution would fit at best, I was calling for tests. Because I can't execute them alone (I've no access to all relevant browsers) and obviously no one else is willing to support my request, I will put the phpBB-solution into the code without further checks.

Tschö, Auge

--
further development of mlf1

Avatar

Bug in My Little Forum, solved in the repo

by Auge ⌂ @, Friday, April 21, 2017, 16:32 (214 days ago) @ danielb987

Hello

Notice for me to keep the track over the processed reports.

Bug is solved with commit de27ceb6c4.

--
further development of mlf1

Tags:
bug, 2.4

Bug in My Little Forum, solved in the repo

by danielb987, Monday, May 01, 2017, 14:03 (204 days ago) @ Auge

Hello

Notice for me to keep the track over the processed reports.

Bug is solved with commit de27ceb6c4.

Thanks

Best regards
Daniel

RSS Feed of thread
powered by my little forum