cache and session woes

[v.]

Hi,

I come here again with cache and session problems. Please note these are completely unrelated to my previous question.

My shared hosting account has recently been migrated to a new server. I think the problems may have started during this migration, but I am not sure.

I noticed only today that my sessions are not working anymore. Everything was working fine when I last checked in.

When I set a session variable like $this->f3->set('SESSION.VAR','flubber'), it is not remembered past a page load. The cache folder does not seem to be storing sessions.

The same problem occurs when I try to set the session variable as $_SESSION["VAR"]="flubber".

When I do this outside of f3 on the same site, it does work though.

Sessions are working fine on other sites on the same account (not using f3)

My sessions are set in the index.php as $f3->session = new Session();
My config.ini sets CACHE=true, I have tried to set it to cache=apcu (which is apparently available on the server), but that did not help.

The server is still on php5.6, setting it to 7.1 did not solve the problem. 

tmp and tmp/cache folders have been chmodded to 0766 and files are appearing there.

If I set cache to APCU I can see files appearing there as well.

I honestly have no idea how to start debugging this. The hoster is not very helpful.

What could be wrong?

[Paul Herring]

Try the following (self-contained script) as index.php, and see what happens with repeated reloads of the page. The value should increase each time if cookies are working as intended:

<?php
$f3 = require('f3/lib/base.php');
$f3->set('CACHE',TRUE);

new Session();
// echo "<pre>";
// print_r($f3->get('SESSION'));
// print_r($_SESSION);
// echo session_name()."\n";
// echo print_r($_SERVER['HTTP_COOKIE'])."\n";
// echo "</pre>";

if (($i = $f3->get('SESSION.test')) !== NULL){
    $i++;
}else{
    $i=0;
}
$f3->set('SESSION.test', $i);

$f3->route('GET /',
    function($f3) {
        global $i;
         echo "Value: $i<br />";
    });
$f3->run();

Expected behaviour, on the command line..

Without storing cookies:

$ rm /tmp/cookies -f
$ curl http://hpdesktop.dontexist.com/f3/
Value: 0<br />
$ curl http://hpdesktop.dontexist.com/f3/
Value: 0<br />

Storing them:

$ curl http://hpdesktop.dontexist.com/f3/ -b/tmp/cookies -c/tmp/cookies
Value: 0<br />
$ curl http://hpdesktop.dontexist.com/f3/ -b/tmp/cookies -c/tmp/cookies
Value: 1<br />
$ curl http://hpdesktop.dontexist.com/f3/ -b/tmp/cookies -c/tmp/cookies
Value: 2<br />
$ curl http://hpdesktop.dontexist.com/f3/ -b/tmp/cookies -c/tmp/cookies
Value: 3<br />

And the cookie:

$ cat /tmp/cookies
# Netscape HTTP Cookie File
# https://curl.haxx.se/docs/http-cookies.html
# This file was generated by libcurl! Edit at your own risk.

#HttpOnly_.hpdesktop.dontexist.com      TRUE    /f3     FALSE   0       PHPSESSID       ulce9dbvv187bjnoh34l4hm8el

--
-- You've received this message because you are subscribed to the Google Groups group. To post to this group, send an email to f3-fra...@googlegroups.com. To unsubscribe from this group, send an email to f3-framework...@googlegroups.com. For more options, visit this group at https://groups.google.com/d/forum/f3-framework?hl=en
---
You received this message because you are subscribed to the Google Groups "Fat-Free Framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email to f3-framework...@googlegroups.com.
To post to this group, send email to f3-fra...@googlegroups.com.
Visit this group at https://groups.google.com/group/f3-framework.
To view this discussion on the web visit https://groups.google.com/d/msgid/f3-framework/2d989765-da86-4a8b-a7ab-92bbc7402dc7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

PJH

[ved]

Hi,

 

When I set a session variable like $this->f3->set('SESSION.VAR','flubber'), it is not remembered past a page load. The cache folder does not seem to be storing sessions.

The  cache folder will only store sessions if you're using the CACHE engine as session storage. This is achieved by:

new \Session();

My sessions are set in the index.php as $f3->session = new Session();

There's no need to assign the session to this $f3->session property. As long as you initialize the session class, the session handler will be registered, there is no need to assign it to any variable.

 

My config.ini sets CACHE=true, I have tried to set it to cache=apcu (which is apparently available on the server), but that did not help.

Setting the CACHE to 'true' will make F3 autodetect the caching engine and use whatever is available. Unless you know it's actually using the filesystem, your sessions wouldn't be saved on your tmp folder but maybe on your APC cache or somewhere else.

 

The server is still on php5.6, setting it to 7.1 did not solve the problem. 

Probably not related with the issue, but please go with php7+ whenever possible. PHP5 is pretty much dead now.

 

tmp and tmp/cache folders have been chmodded to 0766 and files are appearing there.

If I set cache to APCU I can see files appearing there as well. 

I honestly have no idea how to start debugging this. The hoster is not very helpful.

What could be wrong?

It's probably just a minor detail or configuration issue. Do run the test provided by @PJH as it may shed some more light into the issue.

Good luck. 

[v.]

Hi,

Thanks for your help PJH and ved. I have tried the index.php and it seems to increase the counter as expected....

I managed to finally find out what the problem was, and it was quite unexpected....

In my config file:

LOCALES="dict/"

There are 2 files in my dict folder. One of them was causing the problem (it was not even being used, since the other language was set).

It appeared that the encoding of this particular file was set to UTF-8-BOM. Changing this to UTF-8 solved it!

I do not understand why this would cause this kind of issue.

It does not seem to have anything to do with the sessions and it does not generate an error.

Again: before, this worked fine. The problem probably appeared with a server migration.

Why is f3 being broken by this?

[Paul Herring]

Cannot reproduce:

Dict files, one with BOM.

$ for file in dict/*; do echo $file; hexdump -C $file | head -n1; done
dict/de.php
00000000  3c 3f 70 68 70 0a 72 65  74 75 72 6e 20 61 72 72  |<?php.return arr|
dict/en.php
00000000  ef bb bf 3c 3f 70 68 70  0a 72 65 74 75 72 6e 20  |...<?php.return |

Inclusion of said files:

$ cat index.php

<?php
$f3 = require('f3/lib/base.php');
$f3->set('CACHE',TRUE);

$f3->set('LOCALES','dict/');

new Session();

if (($i = $f3->get('SESSION.test')) !== NULL){
        $i++;
}else{
        $i=0;
}
$f3->set('SESSION.test', $i);

$f3->route('GET /',
    function($f3) {
                global $i;

                 echo "Value: $i<br />\n";
        });
$f3->run();

Rerunning test merely outputs the BOM to output with no other ill effects.:

$ curl http://hpdesktop.dontexist.com/f3/ -b/tmp/cookies -c/tmp/cookies

Value: 14<br />

$ curl http://hpdesktop.dontexist.com/f3/ -b/tmp/cookies -c/tmp/cookies

Value: 15<br />

[v.]

Hi,

I also can not reproduce this on another server. The problem only happens on this particular server and possibly only after the migration.

[Paul Herring]

On Tue, Mar 26, 2019 at 3:39 PM v. via Fat-Free Framework <f3-framework+APn2wQfsu8MCcWHUosn...@googlegroups.com> wrote:

Hi,

I also can not reproduce this on another server. The problem only happens on this particular server and possibly only after the migration.

Unlikely to be BOM related then.

Beyond turning all error reporting up to 11, checking everywhere that such may be logged, and adding the (commented out) debugging above around the relevant parts of the misbehaving code, I'm not sure what else to suggest.

 

--

PJH

[ved]

Hi, that is strange,

Were both servers using the same operating system?

Is your new server using an UTF-8 aware locale? (if it's linux see command: locale)

If you save the file back with BOM, does the issue return?

If you run (on linux) "dos2unix affectedfile" instead or removing the BOM, does it fix the issue?

Maybe the issue was some sort of corruption during migration/transfer and saving it again was what fixed it and not the BOM change?

Anyway, if you did manage to fix it then that's your problem solved. Would be nice to figure out the cause though.

Cheers

[v.]

On Tuesday, March 26, 2019 at 4:57:40 PM UTC+1, ved wrote:

Hi, that is strange,

Were both servers using the same operating system?

good question, it was a shared linux hosting account, I never bothered to look into it, but I assume they were both the same linux flavor

Is your new server using an UTF-8 aware locale? (if it's linux see command: locale)

LANG=
LC_CTYPE="POSIX"
LC_NUMERIC="POSIX"
LC_TIME="POSIX"
LC_COLLATE="POSIX"
LC_MONETARY="POSIX"
LC_MESSAGES="POSIX"
LC_PAPER="POSIX"
LC_NAME="POSIX"
LC_ADDRESS="POSIX"
LC_TELEPHONE="POSIX"
LC_MEASUREMENT="POSIX"
LC_IDENTIFICATION="POSIX"
LC_ALL=
 

If you save the file back with BOM, does the issue return?

yes, regardless of the content of the file, it comes back, even if the file only contains

<?php
return;

If you run (on linux) "dos2unix affectedfile" instead or removing the BOM, does it fix the issue?

"dos2unix: command not found"
 

Maybe the issue was some sort of corruption during migration/transfer and saving it again was what fixed it and not the BOM change?

I do not think so, since it comes back when resetting to utf-8-bom

Anyway, if you did manage to fix it then that's your problem solved. Would be nice to figure out the cause though.

 

indeed, this is the kind of thing that takes hours to figure out

[ved]

Hi again, 

Did some more research and apparently this is a known issue with php, sessions (headers really) and files saved with BOM.

See:

https://www.php.net/manual/en/function.session-start.php#95377

https://stackoverflow.com/questions/35114000/php-session-with-utf-8-bom-encoding

https://www.memorylack.com/solving-bom-of-utf-8-file-encoding-problem-with-php-session-and-header/

https://stackoverflow.com/questions/5098454/session-start-error

And many many more (just search google for "php sessions utf bom").

Apparently the BOM causes some premature output, which then triggers the "headers already sent" which should be enough to mess up the sessions.

So, for future reference, always use utf-8 without BOM.

[v.]

 that is quite amazing, I was not aware of this and have never experienced problems of this kind before.

Thanks for helping out once again ved, I owe you 2 beers