php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #18082 Session Problems with IE6 after installation of Patch Q321232
Submitted: 2002-07-01 02:15 UTC Modified: 2002-07-03 13:00 UTC
From: lance at metaldog dot co dot za Assigned: derick (profile)
Status: Not a bug Package: Session related
PHP Version: 4.1.2 OS: RedHat 7
Private report: No CVE-ID: None
View Add Comment Developer Edit
 [2002-07-01 02:15 UTC] lance at metaldog dot co dot za 
Hey, 

Anyone having problems with session variables not being passed or IE resetting session cookies AFTER the installation of the IE6 Q321232 patch? It is the cumulative security patch released May 15 from Microsoft.

I am using Virtual Hosts on standalone Apache 1.3.24 (RedHat), Apache/1.3.12 (FreeBSD) and PHP 4.1.2 or PHP 4.2.1. PHP.ini on both systems identical, httpd.conf identical... 

I am using the example session scripts from the PHP manual - the ones that do a simple page count - before the IE patch, everything works on any system. 

(track_vars always on, register_globals on or off makes no difference)

After the patch IE6 only works on some installations of the exact code and I have not been able to trace the problem. 

Interestingly, on one server where it does not work - Redhat on a local network, IE now seems to be requesting or auto receiving a new session cookie each time the page loads.

The exact same example scripts work from a totally different server to the same IE browsers.

All other browsers work fine - even pre patch IE6 and previous versions.. This includes Netscape 4, 6, 6.1, Opera 4,6, IE 4,5, 5.5 and even IE6 before the patch.

I have tested this on 3 different installations of IE6 on different systems... The moment the patch is installed it goes belly up... before the patch everything works perfectly...

Any ideas? 

Thanx 

Lance

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2002-07-01 02:30 UTC] derick@php.net 
Hmm... it's easy to say that this is an IE problem (which it is :), but that's not going to help. It would be helpfull if you could make a network trace, to see how IE6 recieves and sends the headers. For instance you could use cold (http://www.ipv4.it/cold/) to do this.
With cold --ascii > /tmp/log you start the tool, and when you're done requesting the sessionized pages with both a working and a non-working browser, you can stop it with Ctrl-C.
If you then would be able to put the log file somewhere for us to see, we might be able to fix the problem.

Derick
 [2002-07-01 07:09 UTC] lance at metaldog dot co dot za 
Derick - Thanks for the response..

I have put together a webpage (or three) which shows all the details, your network capture and what I have been up to.

At this moment the issue is so frustrating that I wish that the problem was as simple as configuration issue and that I would have the proverbial "egg in my face" for doing something stupid. In fact, I would gladly accept my fault if the problem would just be resolved.

ANY - get that ANY - suggestions would really help resolve this because its driving me mad and a browser patch usually resolves things not causes them.

Right now, my conclusion is that there is something between my specific server and the new patched IE security features which is no longer kosher - the problem is that I have no idea what and I am not a hard-core low level developer who can hack and track this any more than I already have.

Full details etc available here:

http://www.metaldog.co.za/php.net/index.html

(some network packet items still uploading at time of this submission - give it 15 minutes to be sure)

Thank you

Lance
 [2002-07-01 07:11 UTC] derick@php.net 
assigning so that I dont forget about it
 [2002-07-03 12:31 UTC] lance at metaldog dot co dot za 
New information:

I managed to do some reinstallaitons and started comparing the cookies and headers which the patch affected..

I have managed to resolve the problem myself... I was using an underscore character to differentiate my dev_.domain.com servers from my live.domain.com servers... 

Before the patch everything works fine... after the patch, the domain in the cookies is truncated to dev instead of the entire dev_.domain.com etc. So of course the cookie security wrecks havok and IE keeps getting a new session cookie etc.

I have always used the "_" underscore character and never had problems ever before so I did not even notice it... 

Anyway... my conclusion is that the fault is partly mine for using the special char in the server name and the increased security in the IE patch realised and prevented it working when all other browsers simply ignored the _ char

So - it was quite an exercise but I am happy it has been resolved... 

Hope it did not cause you too many nightmares as it has nothing to do with PHP that I can see. And all my reinstallations and various version updating was the wrong approach..

Close this as resolved.
 [2002-07-03 13:00 UTC] derick@php.net 
Not a bug in PHP -> Bogus
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Mon May 13 21:01:31 2024 UTC