[PHP5] Sessie variabelen geven verkeerde waardes terug

[Verwijderd]

Heeft iemand hier dit wel eens meegemaakt? Ik zit er al de hele avond naar te kijken en ik kom er niet echt uit...

Ik heb een webapplicatie gemaakt waarin mensen zich in kunnen tekenen voor bardiensten op een dag. Ik hou in een sessie variabele bij welke dag mensen aan het bekijken zijn ($_SESSION['day']). Als iemand in de kalender klikt dan verschijnt er naast de kalender een overzicht van te vullen uren op die dag, dat is het idee. Nu zijn de dagen van kalender gewoon links van het type foo.php?param=x waarbij x het ID van de betreffende dag is.

Nu doet mijn code slechts dit:

PHP:

$_SESSION['day']=$_GET['param'];
header("Location: ". $_SERVER['PHP_SELF']);

Waarna het zelfde bestand geladen wordt maar nu kan het script uit de $_SESSION['day'] variabele zien welke dag het moet weergeven naast de kalender. So far, so good.

Maar, als ik maar vaak genoeg wat rondklik door mijn kalender dan wordt opeens een andere dag weergegeven dan waar ik op klikte. En ook als ik in de inteken procedure zit en ik kom via de header operatie weer terug dan is na een paar keer de dag anders. Als debug heb ik toen gewoon

PHP:

print_r($_SESSION);

boven mijn pagina gezet en ik zie dan gewoon dat er af en toe (met name na wat langer gebruik) een oude versie van de sessie data wordt ingelezen. Bijvoorbeeld: de 2e keer wordt op de dag met ID 10 geklikt en de 8e keer op de dag met ID 17, dan wordt (compleet willekeurig) toch de 2e dag weergegeven en alle sessie variabelen zijn de oude variabelen als toen ze bij de 2e klik waren. Ik heb niet echt een idee wanneer het nu wel en wanneer het nu niet optreedt, soms moet je een paar keer doro de kalender klikken en je links en rechts eens wat in- en uitschrijven, soms gebeurt het sneller.

Ik doe netjes een session_start(); bovenaan elke pagina en het is niet zo dat de pagina's clientside gecashed worden.

Voor de mensen die het zelf willen zien: www.plan-e.nl/hoogerheide en kies dan het eerste lidnummer met geboortedatum 12-7-1969. Voor debug doeleinde staat bovenaan de pagina een print_r van de hele $_SESSION.

Als iemand mij een tip zou kunnen geven waar deze soms oude sessie variabelen van daan komen dan ben ik erg dankbaar!

VlAtY

[Rotjeknor]

Ik krijg het ook op het moment dat ik meerdere keren dezelfde dag aanklikte. Ik kon er zo 123 niks van zien waardoor het wel of niet goed gaat. Er lijkt geen relatie te zitten in hoevaak je klikt en wanneer het voorkomt.

Je hebt overigens erbij staan wat er nu in zit en wat je verwacht, maar op het moment dat het foutgaat, zijn die consequent fout.

Erg vreemd, wat je zou kunnen proberen is achterhalen of het aan de $_GET variabele ligt of aan de $_SESSION var. Heb je het ook al eens op een andere server geprobeerd? Misschien heeft de huidige server problemen met de afhandeling. Ik zie trouwens dat je ook nog iets doet met de url, een of andere rewrite actie? Want de $_GET parameters komen niet terug in de link (behalve met shift-klik, new window).

[LuCarD]

Verwijderd schreef op woensdag 02 maart 2005 @ 01:44:

Ik doe netjes een session_start(); bovenaan elke pagina en het is niet zo dat de pagina's clientside gecashed worden.

Hoe weet je dit zo zeker?

[offtopic]
cashen van een pagina doe je pas nadat het opgeleverd is
Waarschijnlijk bedoel je chachen

[beetle71]

Vreemd, ik krijg het probleem niet, En ik heb VAAK geklikt

Maar goed ik begrijp ook iets niet.

Waarom doe je dit?

PHP:

$_SESSION['day']=$_GET['param']; 
header("Location: ". $_SERVER['PHP_SELF']);

Wat voor nut heeft die header redirect?
Als je op regel 1 de $_SESSION['day'] set kun je die toch in de rest van je script ook weer gewoon aanroepen?

Nu 'truuk' je op deze manier je request variabelen achter je index.php weg en denk ik toch echt dat je een caching probleem hebt.
Hou anders je apache (?) acces log er eens bij en kijk welke code de server terug geeft op het moment dat het fout gaat (een 304 ?)
zie evt Hier voor de betekenis

Probeer anders een geforceerd de caching te voorkomen:

PHP:

// Date in the past
header("Expires: Mon, 26 Jul 1997 05:00:00 GMT");

// always modified
header("Last-Modified: " . gmdate("D, d M Y H:i:s") . " GMT");
 
// HTTP/1.1
header("Cache-Control: no-store, no-cache, must-revalidate");
header("Cache-Control: post-check=0, pre-check=0", false);

// HTTP/1.0
header("Pragma: no-cache");

[Verwijderd]

Oké mensen bedankt voor de tips.

Ik heb een eigengemaakte session handler geschreven en toen was het probleem opgelost. Dat zette me aan het denken en vvolgens mij betekende dat dat het dus aan de host (ww.pcextreme.nl) haar configuratie ligt.

Bovendien zag ik dat als ik php_info(); onder php5 uitvoerde op de host dat de session.directory "/" is.

Dus ik bel de helpdesk en met dit verhaal gingen ze eens goed nadenken hoe het kwam dat de standaard php 5 (in php4 ging het goed) sessie handlers niet werken. En wat denk je: door de loadbalancing kwam je af en toe op een andere server bij hun uit en de sessie bestanden waren niet onderling gesynchroniseerd in het cluster.

Ze gingen het oplossen en tot die tijd maak ik mooi gebruik van een eigen session handler.

VlAtY