Re: Session variable not persisting

From: Date: Mon, 18 Mar 2013 20:14:32 +0000
Subject: Re: Session variable not persisting
References: 1 2 3 4 5 6 7 8  Groups: php.general php.general 
Request: Send a blank email to php-general+get-320644@lists.php.net to get a copy of this message
Le 2013-03-18 à 15:41, Éric Oliver Paquette a écrit : > > Le 2013-03-18 à 15:37, Matijn Woudt a écrit : > >> >> >> >> On Mon, Mar 18, 2013 at 8:35 PM, Éric Oliver Paquette <eopaquette@gmail.com> wrote: >> >> Le 2013-03-18 à 15:24, Éric Oliver Paquette a écrit : >> >>> >>> Le 2013-03-18 à 15:20, Matijn Woudt a écrit : >>> >>>> >>>> >>>> >>>> On Mon, Mar 18, 2013 at 8:13 PM, Éric Oliver Paquette <eopaquette@gmail.com> >>>> wrote: >>>> >>>>> >>>>> On Mon, Mar 18, 2013 at 7:46 PM, Éric Oliver Paquette >>>>> <eopaquette@gmail.com> wrote: >>>>> Hi all, >>>>> >>>>> I'll be swift in my explanation as I can't find in any way the source >>>>> of the problem; it seems to be installation-related. >>>>> >>>>> At execution, sometimes (randomly it seems at first), variable session >>>>> aren't properly stored. >>>>> >>>>> >>>>> In fact, when I run this on my server I randomly have empty entries in the >>>>> $_SESSION array. Any thoughts on this? Is this a known bug (haven't found it…) >>>>> >>>>> Thanks! >>>>> >>>>> What does phpinfo() show about session stuff? Especially things like >>>>> save_handler and cookie_lifetime settings. >>>> >>>> Note that this seems to occur 3 times out of 1000 on average. >>>> >>>> Now, about your request : >>>> >>>> session >>>> >>>> Session Support enabled >>>> Registered save handlers files user >>>> Registered serializer handlers php php_binary wddx >>>> >>>> Directive Local Value Master Value >>>> session.auto_start Off Off >>>> session.bug_compat_42 Off Off >>>> session.bug_compat_warn Off Off >>>> session.cache_expire 180 180 >>>> session.cache_limiter nocache nocache >>>> session.cookie_domain no value no value >>>> session.cookie_httponly Off Off >>>> session.cookie_lifetime 0 0 >>>> session.cookie_path / / >>>> session.cookie_secure Off Off >>>> session.entropy_file no value no value >>>> session.entropy_length 0 0 >>>> session.gc_divisor 1000 1000 >>>> session.gc_maxlifetime 1440 1440 >>>> session.gc_probability 1 1 >>>> session.hash_bits_per_character 5 5 >>>> session.hash_function 0 0 >>>> session.name PHPSESSID PHPSESSID >>>> session.referer_check no value no value >>>> session.save_handler files files >>>> session.save_path /var/lib/php/session /var/lib/php/session >>>> session.serialize_handler php php >>>> session.use_cookies On On >>>> session.use_only_cookies On On >>>> session.use_trans_sid 0 0 >>>> >>>> >>>> Your settings seem to be fine. My best guess would be hardware failure, though it >>>> seems unlikely. Did you check apache (or whatever webserver you're using) logs for any errors >>>> or warnings? >>> >>> Yes I did. Everyhting seems normal there too. >> >> Hm… Just noticed something new in fact; was looking a last time before considering >> reinstallation on a new server: it seems that the $_GET['push'] is undefined. In the other >> scripts I use where I have this problem, I'm using $_POST variables though but still don't >> get stored in $_SESSION. If I'm correct, this may implies that it is apache that is faulty >> right? >> >> >> >> $_GET['push'] will be undefined if you still have your session stored, but >> accessing the script directly. It should have nothing to do with faulty Apache. > > Okay, let me paraphrase: when I run the ping pong scripts written up there, I have a blank in > var_dump($_SESSION) if and only if I have > > [Mon Mar 18 13:25:37 2013] [error] [client 184.151.114.111] PHP Notice: Undefined index: push > in /home/www/www.ngenioconnect.com/Modules/MPOSurveyTest/pong.php on line 8 > > on apache log. So my question really is, it is apache that handles the posts and gets requests, > as I use both and it seems that the non-persistence of data occurs before the storage in $_SESSION, > is it possible that it is Apache that is faulty? Er… I looked where it caused a problem, it seems that $_GET, $_POST and $_SESSION are indeed all affected. Any clue of a faulty installation that would cause problem for many surperglobals?

« previous php.general (#320644) next »