Erratic Session Behavior Windows Server 2000

[sera]

Hello,
I have a really weird problem. I have been googleing for hours. We have a website with multiple pages accessing one session. We use session_start() on every page. Everything works fine on Windows Server 2003, however when we migrate it to our Windows Server 2000 box the session stops working. On the Windows Server 2000 box, each page creates a new session.

The even weirder part is that last night we had it working, then this morning when we came in, it was no longer working.

Does anyone have any ideas that I could try.....


Sera

 

[jpadie]

check the directory that the sessions are saved in (cf php.ini) and make sure that the relevant server process has read/write access to the sessions directory.

i believe that the temp directory (often where session files are stored) is different between win 2000 and 2003.

 

[sera]

The permissions are the same.

The key point here is that

SOMETIMES it works - hence it can read and write
SOMETIMES it doesn't

I know that doesn't make sense but I promise that is what is going on.


Sera

 

[jpadie]

it never is. things don't work like that. there will always be a logical disparity between the two states.

 

[sera]

Well there is another key point. It works all of the time on IIS 6.0 and doesn't really work on 5.0

Does anyone know if/how sessions are handled differently between the two....?

My intern built the application that I am trying to fix, we have decided that he is going to have to re-architect it....
We can get simple scripts to behave correctly on the 2000 Server but not his scripts. I suspect he has too many session_starts() going on...

However, Server 2003 does not have any problems with the way that he wrote his code...oddly enough.



Sera

 

[jpadie]

there is no difference in session handling. this extends to *nix machines too (other than innate file handling differences between various different file storage systems.

the differences to watch out for are mainly that the systemroot (and thus the temp directory) is different between win 2000 an 2k3.

i use identical sites with identical configs without problems between IIS 5,6 and 7.

other pitfalls with app migrations are permissions. you need to make sure that the permissions match on not just the application and data directories, but also the temp (or session storage) directory.

 

[sera]

Hmm, well I dunno what to think.

The permissions match across all of the directories. The temp directories and the data directories. I can reproduce the erratic behavior on the Server 2000 box. The Server 2003 box just doesn't care.

The website uses .shtml pages so that it can conform to the company template. The initial .shtml page includes two php files. Both php files call session_start(). At load, two sessions are created. Then when he loads the login page, it creates two more sessions. When they login, it creates two more sessions, one with data. Once the data is in the session, it still will not persist with the pages.

To confuse the issue even more, I set up a 2 test php files with a simple session setup so that I could prove that sessions would work on the server. When we run those test files, the session persists just fine. After running the test php app, I can go to the interns application and for some reason his application attaches to the session that the test php app used.

It really is strange, and I am assuming his code is calling session_start too many times....

Sera

Sera

 

[jpadie]

i am a bit confused by all the session_starts(). are you changing the session_name() between session_starts()?

if not, then, so long as you are using a recent version of php (> 4.3.3) subsequent session_starts() are ignored (although an E_NOTICE will be raised).

 

[sera]

Well I know you are saying it should be ignoring them, but its not. I watch the sessions get created in the sessions folder each time we load the page. I know the way php sessions are supposed to behave, due to my two days of searching the internet trying to find someone else who has had this problem.

We are using PHP Version 5.2.2

We are not trying to change the session_name. We make no calls to session_name. Unless that is happening behind the scenes somehow....

I am a bit confused by all of them as well, which is why he is re architecting his application.

Sera

Sera

 

[jpadie]

certainly my experience and the manual reports that second and subsequent calls to session_start are ignored. if your experience is otherwise then the community would benefit from you reporting it to php as a bug.

for the time being, why not change every call to session_start to the following:

if (session_id() === '') session_start();

this will prevent subsequent calls to session_start being effective, provided that no interim call to regenerate the session_id has been made.

as for session persistence, your report seems to be the correct behaviour, assuming both you and the intern were using the same box as the server and the same computer as the client. this is because session information propagates to the client through a cookie and the name of the cookie will be the session_name. assuming you are not changing the session_name it will be PHPSESSID. if the cookie is on the computer that you are both using and the domain is the same, then the session data will be available to both sessions.

If you consider that your intern's code is malformed, why not post the code here?

 

[sleipnir214]

It works under IIS 6, but not under IIS 5...

Are you using HTTP "Location" headers in your code? If so, you could be running afoul of Microsoft's unique interpretation of the HTTP spec, which was not corrected until IIS 6. See

http://support.microsoft.com/kb/176113

Want the best answers? Ask the best questions! TANSTAAFL!

 

[sera]

Now that sounds promising. He is using header(Location: "someurl.php"). We are not using cookies tho, and I am not really sure how to apply that particular link to our problem. But it does give me somewhere to look.

Jpadie: The code is numerous pages connected to each other. Way too much code to paste and really too much code for someone to casually look at. I tried your suggestion and it still creates two cookies.

I will look into sleipnir214's answer and see if I cannot find a solution, if I do, I will post the answer





Sera

 

[sera]

I would like to show everyone that numerous people have had this problem....

http://bugs.php.net/bug.php?id=14636

Sera

 

[sleipnir214]

We are not using cookies tho,

How are you transmitting your session IDs from script run to script run?

PHP, by default, transmits that information back and forth via a cookie.



Want the best answers? Ask the best questions! TANSTAAFL!

 

[jpadie]

personally, i dont think this bug reports are applicable to this scenario.

and it is vanishingly unlikely that the same script is generating more than one session cookie without a change in session_name().

if you would like to upload the scripts to me i would be happy to look at them. you can upload a zip file please include a sql dump too.

http://www.adieandco.com/upload.php

 

[sera]

Well if it transmits the cookies by default then yes. We are not explicitly using set_cookie(). We are setting the value inside the session.

Sera

 

[sleipnir214]

Unless you have taken pains in your PHP configuration to not use cookies in sessions, you are.

Take a look. Do all the scripts exhibiting erratic session behavior also use the "Location" header?



Want the best answers? Ask the best questions! TANSTAAFL!

 

[jpadie]

just a thought - but are you by any chance testing the application on the same box as the server (i.e. localhost)?

if so the erratic behaviour may be that you are sometimes hitting a race condition on the session file. this may be more obvious on the win2000 box as, quite simply, it may be older with a less rapid processor and hard disk etc etc.

race conditions can be avoided easily by calling session_write_close() immediately prior to the header('Location:...') line.

this would still not cause multiple session files to be created within a single script however. since session files are created with the file name equivalent to the session id I still can't see how this can occur without a regeneration of the session_id.

 

[sera]

slepnir214 : Yes they do all use "Location" header.

jpadie: interesting idea. It is true that the two machines are vastly different. The 2003 server is most definitely faster than the 2000 server. A race condition is probably occuring. I am sorry if I haven't said it clearly or at all, but it is obviously creating new session id's ....
The session_write_close() is not working.

I really need to figure out how to reproduce the behavior with a simple example. I am a bit too busy working on something else right now. I will try to provide an example soon. This will help us all.

Jpadie: I will post the example to the site you listed above.


Sera