Ad:

PHP Discussion Thread
Marked Solved
Views: 61889

Page 1
2
3
4
Next

You are currently viewing page 1 of this multi-page discussion thread

May 18th, 2007

IE6/IE7 unexpectedly drops the PHP Session ID cookie (PHPSESSID)

Expand Post »

I've written a moderately-sized Web application that utilizes MySQL and PHP5.

I have an on-going problem where Microsoft Internet Explorer 6 (IE6) and Microsoft Internet Explorer 7 (IE7) lose the PHP Session ID cookie (PHPSESSID). Of course, when this happens, the application loses track of the current user and the user is forced off the system and required to sign on again. As you can imagine, it's especially annoying to users.

I must be doing something wrong because if this problem were wide spread, I'm sure there would be a lot of grumbling by users and developers of PHP-driven Web applications.

Here's what I know about the issue. I've carefully monitored the HTTP traffic taking place between the Web application and the client browser using Fiddler2 and Live HTTP headers. Here's is what I've found:

Only in IE6 and IE7...

1. The browser accepts the PHPSESSID cookie just fine and users are able to sign on just fine and use the application for some undetermined period of time.

2. At some point, the browser loses or deletes the PHPSESSID cookie prematurely/unexpectedly. This is evidenced by the fact that the browser does not send the cookie back with the HTTP requests as it should even though the cookie was sent with subsequent requests. All of sudden, the PHPSESSID cookie is no more. I presume it is dropped or deleted by the browser, but I'm not sure why.

3. Mozilla Firefox works perfectly. I've not once had this problem in Firefox. This leads me to believe this issue is something browser specific or something about the PHPSESSID cookie that IE6 and IE7 do not like. I've tested this on many computers running IE6 and IE7 with various security and privacy settings and the results are no different. IE6 and IE7 drop the cookie unexpectedly while the session is still active.

Anyone have an leads on this issue? I've "googled" this issue it to death and there's nothing else out there that I can find.

Sincerely,

Ben Roberts
Azalea Technology

P.S. I do not want to go to including the session ID in URLs as I do not prefer that method of session tracking for a number of reasons.

brob5000

Reputation Points: 12

Solved Threads: 0

Newbie Poster

Offline

22 posts
since Jul 2004

Permalink

May 19th, 2007

Re: IE6/IE7 unexpectedly drops the PHP Session ID cookie (PHPSESSID)

Although I have not come across this problem before I can think of a couple of things that might be happening.

First of I would look in your code at any items that uses the session_start() function, as you could be accidently regenerating the existing session which would oviously reset the session_id().

On a side note if you are not checking whether a session exists before you create on the you can use

PHP Syntax (Toggle Plain Text)
if(session_id()!=="")
        {
            //Session is not started try to start one
            @session_start();
            //Check to see if we successfully started are session
            if(session_id()!=="")
            {
                           //session didn't start raise and error trigger_error(E_USER_ERROR,SESSION_START_ERROR);
            }
        }
if(session_id()!=="")
        {
            //Session is not started try to start one
            @session_start();
            //Check to see if we successfully started are session
            if(session_id()!=="")
            {
                           //session didn't start raise and error trigger_error(E_USER_ERROR,SESSION_START_ERROR);
            }
        }

I did think of another reason but I have forgotten it, I wil post again later when I can remeber it (Sorry only on my second coffee of the day).

Urban

UrbanSky

Reputation Points: 10

Solved Threads: 4

Light Poster

Offline

42 posts
since Oct 2006

Permalink

May 19th, 2007

Re: IE6/IE7 unexpectedly drops the PHP Session ID cookie (PHPSESSID)

Click to Expand / Collapse Quote originally posted by UrbanSky ...

...I would look in your code at any items that uses the session_start() function, as you could be accidently regenerating the existing session which would oviously reset the session_id().
Urban

Thanks so much for your reply. You're the first.

One thing I've observed when looking at the HTTP activity is that my PHP Web application is not sending a new session ID until the browser makes a HTTP request that does not include the session ID.

I double checked this using fiddler2. Here is what I found. On the first response, the Web server sets the PHP session ID cookie when it sends the following as a part of it's HTTP response:

Set-Cookie: PHPSESSID=224c839dc3aab608a87d79897a67cec8; path=/

----------------- BEGIN HTTP TRAFFIC -----------------

Now fast forward in the HTTP exchange...the browser makes this good request which includes the PHP session cookie:

GET /lib/php/view.php?page=/viewer/reports HTTP/1.1
Accept: */*
Referer: http://www.resourcemethods.com/lib/php/controlpanel.php
Accept-Language: en-us
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.0.3705; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30)
Host: www.resourcemethods.com
Proxy-Connection: Keep-Alive
Cookie: PHPSESSID=224c839dc3aab608a87d79897a67cec8;
active_user=59d6dc3f586b0151682d1515e46a536b846fd86475b62a69ab89fc986ef0ffd7; previous_session[y]=ca6399dc2db5b50066a887bfc10f987eee6a20c98aa144c5a6d087a4b9a7dce6; previous_session[x]=3ecdf277d4c8fd059b75be30575cbc9b9e4050803f972aad3539e73cc032b0d7; searchfield[usermanager]=b4ebdc4a94c01bce03e1e8eaffd2e8da6782ec9b8d8304c84f3396fb5ccfe923; searchtext[usermanager]=b4ebdc4a94c01bce03e1e8eaffd2e8da6782ec9b8d8304c84f3396fb5ccfe923; sort[usermanager]=3ecdf277d4c8fd059b75be30575cbc9b9e4050803f972aad3539e73cc032b0d7; direction[usermanager]=69d233d07bd8ffb9e38f82a9b663d1736603b6245b4f5ccc425be696e928b8c9; ipp[usermanager]=e13761bfad302b78d4a9d2c77aa65258d290e621611dd8685bfbc4d3cac17e14; pn[usermanager]=3ecdf277d4c8fd059b75be30575cbc9b9e4050803f972aad3539e73cc032b0d7; searchfield[onlinelog]=b4ebdc4a94c01bce03e1e8eaffd2e8da6782ec9b8d8304c84f3396fb5ccfe923; searchtext[onlinelog]=b4ebdc4a94c01bce03e1e8eaffd2e8da6782ec9b8d8304c84f3396fb5ccfe923; sort[onlinelog]=50517731758448b018f473c2fe0945a05a9e8486ac6a67865fa4339a8201ede3; direction[onlinelog]=359cef6e51a1cd8b7c23a3b9ce129c2d57be213ab48dcd3835c8c2a61610ff97; ipp[onlinelog]=a744dd4fd8d11bac2fefe88c784128f13c3e409d33a3e56950defe127c83246b; pn[onlinelog]=3ecdf277d4c8fd059b75be30575cbc9b9e4050803f972aad3539e73cc032b0d7

Then, the server issues this good response:

HTTP/1.1 200 OK
Date: Sat, 19 May 2007 15:00:21 GMT
Server: Apache/2.0.54 (Debian GNU/Linux)
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Set-Cookie: previous_session[y]=71f37695bb37b0c84290becc231cbbf0f4b4616b48308db62a6170193cc23e4c; expires=Sun, 20-May-2007 15:00:24 GMT; path=/
Set-Cookie: previous_session[x]=3ecdf277d4c8fd059b75be30575cbc9b9e4050803f972aad3539e73cc032b0d7; expires=Sun, 20-May-2007 15:00:24 GMT; path=/
Set-Cookie: searchfield[myreports]=b4ebdc4a94c01bce03e1e8eaffd2e8da6782ec9b8d8304c84f3396fb5ccfe923; expires=Sun, 20-May-2007 15:00:24 GMT; path=/
Set-Cookie: searchtext[myreports]=b4ebdc4a94c01bce03e1e8eaffd2e8da6782ec9b8d8304c84f3396fb5ccfe923; expires=Sun, 20-May-2007 15:00:24 GMT; path=/
Set-Cookie: sort[myreports]=6556d5b49cc04459a5c9a24b5cb1b32e18f4ba8311aeebbc580a29427557334c; expires=Sun, 20-May-2007 15:00:24 GMT; path=/
Set-Cookie: direction[myreports]=359cef6e51a1cd8b7c23a3b9ce129c2d57be213ab48dcd3835c8c2a61610ff97; expires=Sun, 20-May-2007 15:00:24 GMT; path=/
Set-Cookie: ipp[myreports]=70a52a59fb0d332e94e8dbe061836dac5875cb98b5abd2668123f6e2235db25a; expires=Sun, 20-May-2007 15:00:24 GMT; path=/
Set-Cookie: pn[myreports]=3ecdf277d4c8fd059b75be30575cbc9b9e4050803f972aad3539e73cc032b0d7; expires=Sun, 20-May-2007 15:00:24 GMT; path=/
Connection: close
Transfer-Encoding: chunked
Content-Type: text/html

Then, an undetermined number of other requests and responses take place. All the responses contain the PHP session ID cookie. Here's the GOOD request and the response right before the issue takes place:

GET /lib/php/view.php?page=/viewer/reports HTTP/1.1
Accept: */*
Referer: http://www.resourcemethods.com/lib/php/controlpanel.php
Accept-Language: en-us
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.0.3705; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30)
Host: www.resourcemethods.com
Proxy-Connection: Keep-Alive
Cookie: PHPSESSID=224c839dc3aab608a87d79897a67cec8; active_user=59d6dc3f586b0151682d1515e46a536b846fd86475b62a69ab89fc986ef0ffd7; previous_session[y]=ca6399dc2db5b50066a887bfc10f987eee6a20c98aa144c5a6d087a4b9a7dce6; previous_session[x]=3ecdf277d4c8fd059b75be30575cbc9b9e4050803f972aad3539e73cc032b0d7; searchfield[usermanager]=b4ebdc4a94c01bce03e1e8eaffd2e8da6782ec9b8d8304c84f3396fb5ccfe923; searchtext[usermanager]=b4ebdc4a94c01bce03e1e8eaffd2e8da6782ec9b8d8304c84f3396fb5ccfe923; sort[usermanager]=3ecdf277d4c8fd059b75be30575cbc9b9e4050803f972aad3539e73cc032b0d7; direction[usermanager]=69d233d07bd8ffb9e38f82a9b663d1736603b6245b4f5ccc425be696e928b8c9; ipp[usermanager]=e13761bfad302b78d4a9d2c77aa65258d290e621611dd8685bfbc4d3cac17e14; pn[usermanager]=3ecdf277d4c8fd059b75be30575cbc9b9e4050803f972aad3539e73cc032b0d7; searchfield[onlinelog]=b4ebdc4a94c01bce03e1e8eaffd2e8da6782ec9b8d8304c84f3396fb5ccfe923; searchtext[onlinelog]=b4ebdc4a94c01bce03e1e8eaffd2e8da6782ec9b8d8304c84f3396fb5ccfe923; sort[onlinelog]=50517731758448b018f473c2fe0945a05a9e8486ac6a67865fa4339a8201ede3; direction[onlinelog]=359cef6e51a1cd8b7c23a3b9ce129c2d57be213ab48dcd3835c8c2a61610ff97; ipp[onlinelog]=a744dd4fd8d11bac2fefe88c784128f13c3e409d33a3e56950defe127c83246b; pn[onlinelog]=3ecdf277d4c8fd059b75be30575cbc9b9e4050803f972aad3539e73cc032b0d7

The response looks great...no reset of the PHP session ID cookie...

HTTP/1.1 200 OK
Date: Sat, 19 May 2007 15:00:21 GMT
Server: Apache/2.0.54 (Debian GNU/Linux)
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Set-Cookie: previous_session[y]=71f37695bb37b0c84290becc231cbbf0f4b4616b48308db62a6170193cc23e4c; expires=Sun, 20-May-2007 15:00:24 GMT; path=/
Set-Cookie: previous_session[x]=3ecdf277d4c8fd059b75be30575cbc9b9e4050803f972aad3539e73cc032b0d7; expires=Sun, 20-May-2007 15:00:24 GMT; path=/
Set-Cookie: searchfield[myreports]=b4ebdc4a94c01bce03e1e8eaffd2e8da6782ec9b8d8304c84f3396fb5ccfe923; expires=Sun, 20-May-2007 15:00:24 GMT; path=/
Set-Cookie: searchtext[myreports]=b4ebdc4a94c01bce03e1e8eaffd2e8da6782ec9b8d8304c84f3396fb5ccfe923; expires=Sun, 20-May-2007 15:00:24 GMT; path=/
Set-Cookie: sort[myreports]=6556d5b49cc04459a5c9a24b5cb1b32e18f4ba8311aeebbc580a29427557334c; expires=Sun, 20-May-2007 15:00:24 GMT; path=/
Set-Cookie: direction[myreports]=359cef6e51a1cd8b7c23a3b9ce129c2d57be213ab48dcd3835c8c2a61610ff97; expires=Sun, 20-May-2007 15:00:24 GMT; path=/
Set-Cookie: ipp[myreports]=70a52a59fb0d332e94e8dbe061836dac5875cb98b5abd2668123f6e2235db25a; expires=Sun, 20-May-2007 15:00:24 GMT; path=/
Set-Cookie: pn[myreports]=3ecdf277d4c8fd059b75be30575cbc9b9e4050803f972aad3539e73cc032b0d7; expires=Sun, 20-May-2007 15:00:24 GMT; path=/
Connection: close
Transfer-Encoding: chunked
Content-Type: text/html

Then, the very next request, the browser makes this problematic HTTP get request and does not include the PHP session ID cookie. No "Set-Cookie:" was issued in the previous HTTP response. This seems to indicate to me that the browser has lost or deleted the cookie, so it does not include it w/ the request:

GET /lib/php/view.php?page=/manager/reports HTTP/1.1
Accept: */*
Accept-Language: en-us
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.0.3705; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30)
Host: www.resourcemethods.com
Proxy-Connection: Keep-Alive
Cookie:
previous_session[y]=71f37695bb37b0c84290becc231cbbf0f4b4616b48308db62a6170193cc23e4c; previous_session[x]=3ecdf277d4c8fd059b75be30575cbc9b9e4050803f972aad3539e73cc032b0d7; searchfield[usermanager]=b4ebdc4a94c01bce03e1e8eaffd2e8da6782ec9b8d8304c84f3396fb5ccfe923; searchtext[usermanager]=b4ebdc4a94c01bce03e1e8eaffd2e8da6782ec9b8d8304c84f3396fb5ccfe923; sort[usermanager]=3ecdf277d4c8fd059b75be30575cbc9b9e4050803f972aad3539e73cc032b0d7; direction[usermanager]=69d233d07bd8ffb9e38f82a9b663d1736603b6245b4f5ccc425be696e928b8c9; ipp[usermanager]=e13761bfad302b78d4a9d2c77aa65258d290e621611dd8685bfbc4d3cac17e14; pn[usermanager]=3ecdf277d4c8fd059b75be30575cbc9b9e4050803f972aad3539e73cc032b0d7; searchfield[onlinelog]=b4ebdc4a94c01bce03e1e8eaffd2e8da6782ec9b8d8304c84f3396fb5ccfe923; searchtext[onlinelog]=b4ebdc4a94c01bce03e1e8eaffd2e8da6782ec9b8d8304c84f3396fb5ccfe923; sort[onlinelog]=50517731758448b018f473c2fe0945a05a9e8486ac6a67865fa4339a8201ede3; direction[onlinelog]=359cef6e51a1cd8b7c23a3b9ce129c2d57be213ab48dcd3835c8c2a61610ff97; ipp[onlinelog]=a744dd4fd8d11bac2fefe88c784128f13c3e409d33a3e56950defe127c83246b; pn[onlinelog]=3ecdf277d4c8fd059b75be30575cbc9b9e4050803f972aad3539e73cc032b0d7; searchfield[myreports]=b4ebdc4a94c01bce03e1e8eaffd2e8da6782ec9b8d8304c84f3396fb5ccfe923; searchtext[myreports]=b4ebdc4a94c01bce03e1e8eaffd2e8da6782ec9b8d8304c84f3396fb5ccfe923; sort[myreports]=6556d5b49cc04459a5c9a24b5cb1b32e18f4ba8311aeebbc580a29427557334c; direction[myreports]=359cef6e51a1cd8b7c23a3b9ce129c2d57be213ab48dcd3835c8c2a61610ff97; ipp[myreports]=70a52a59fb0d332e94e8dbe061836dac5875cb98b5abd2668123f6e2235db25a; pn[myreports]=3ecdf277d4c8fd059b75be30575cbc9b9e4050803f972aad3539e73cc032b0d7

Of course, here the server responds back as you would expect by trying to set a new PHP session ID cookie in the browser:

HTTP/1.1 302 Found
Date: Sat, 19 May 2007 15:00:29 GMT
Server: Apache/2.0.54 (Debian GNU/Linux)
Set-Cookie: PHPSESSID=3184bd3793023e473a8a353013311906; path=/
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Set-Cookie: previous_session[y]=e1c6910272766cb96a16be68145a9cc683533e640825cf1626d489e3c0aed34d; expires=Sun, 20-May-2007 15:00:29 GMT; path=/
Set-Cookie: previous_session[x]=90779e07d35318318d5cf02a33c6e7f429d172e7afd6acebb5f1392ff136edc0; expires=Sun, 20-May-2007 15:00:29 GMT; path=/
Location: login.controller.php?action=logoff&status=010018
Connection: close
Transfer-Encoding: chunked
Content-Type: text/html

----------------- END HTTP TRAFFIC -----------------

The HTTP activity above does not seem to be consistent w/ your theory about the Web application (server) regenerating/resetting the session ID because a "Cookie-Set: PHPSESSID=" command is NOT send as a part of the HTTP response before the browser sends a HTTP GET request that fails to include the PHPSESSID cookie.

After looking at the HTTP traffic, do you come to the same conclusion? Let me know.

Keep in mind that it's only IE6 and IE7 that have this behavior. Mozilla Firefox works flawlessly.

Sincerely,

Ben Roberts
Azalea Technology

Last edited by brob5000; May 19th, 2007 at 12:52 pm.

brob5000

Reputation Points: 12

Solved Threads: 0

Newbie Poster

Offline

22 posts
since Jul 2004

Permalink

May 19th, 2007

Re: IE6/IE7 unexpectedly drops the PHP Session ID cookie (PHPSESSID)

I am as stupped as you are. The only thing that comes to mind is that IE sometimes has problem finsihes off writting session data and it is subsquently lost.

I think that it is quit well documented in the manual in the session_id() chapter. Besically in certian situations ie needs the session_write_close(); function but I think this problem is more when browsers are redirected in headers (Which i can see yours isn't.

If you solve this problem please post a solution and will keep my thinking hat on.

Urban

UrbanSky

Reputation Points: 10

Solved Threads: 4

Light Poster

Offline

42 posts
since Oct 2006

Permalink

May 19th, 2007

Re: IE6/IE7 unexpectedly drops the PHP Session ID cookie (PHPSESSID)

Is IE going through a Proxy?

Proxy-Connection: Keep-Alive

There is also the:

Connection: Close

response from the server. Thats odd for HTTP 1.1 .

If there is a proxy, it may be changing the HTTP Request outside what your fiddler picks up. Try testing without a proxy to single it down to IE fi you havent.

digital-ether

Moderator

Reputation Points: 457

Solved Threads: 101

Nearly a Posting Virtuoso

Offline

1,250 posts
since Sep 2005

Permalink

May 20th, 2007

Re: IE6/IE7 unexpectedly drops the PHP Session ID cookie (PHPSESSID)

Click to Expand / Collapse Quote originally posted by digital-ether ...

Is IE going through a Proxy?

Proxy-Connection: Keep-Alive

There is also the:

Connection: Close

response from the server. Thats odd for HTTP 1.1 .

If there is a proxy, it may be changing the HTTP Request outside what your fiddler picks up. Try testing without a proxy to single it down to IE fi you havent.

Yeah, I don't think IE is not going through a proxy like you are thinking. What you are seeing in the HTTP activity is actually a result of Fiddler fiddling with things.

It sounds like you have used Fiddler before. Take a look at your IE proxy settings. Under most circumstances, you should not have any proxy settings. Now, start the Fiddler application. Now, go look at your IE proxy settings again. You should note how Fiddler has modified the settings in order to listen to all the HTTP traffic taking place within IE.

Fiddler acts "like a proxy" so that it can look at all the HTTP traffic. It modifies the proxy configuration of IE and points the HTTP traffic to the loop back address (127.0.0.1:8888). This is how it listens to everything that is going on. The program title is actually "Fiddler - HTTP Debugging Proxy".

As for the "Connection: close", this does appear to be a part of the HTTP/1.1 standard. See http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html.

Quote ...

HTTP/1.1 defines the "close" connection option for the sender to signal that the connection will be closed after completion of the response. For example,

Connection: close

in either the request or the response header fields indicates that the connection SHOULD NOT be considered 'persistent' (section 8.1) after the current request/response is complete.

HTTP/1.1 applications that do not support persistent connections MUST include the "close" connection option in every message.

Let me know what you think.

Sincerely,

Ben Roberts
Azalea Technology

brob5000

Reputation Points: 12

Solved Threads: 0

Newbie Poster

Offline

22 posts
since Jul 2004

Permalink

May 20th, 2007

Re: IE6/IE7 unexpectedly drops the PHP Session ID cookie (PHPSESSID)

Click to Expand / Collapse Quote originally posted by UrbanSky ...

I am as stupped as you are. The only thing that comes to mind is that IE sometimes has problem finsihes off writting session data and it is subsquently lost.

I think that it is quit well documented in the manual in the session_id() chapter. Besically in certian situations ie needs the session_write_close(); function but I think this problem is more when browsers are redirected in headers (Which i can see yours isn't.

If you solve this problem please post a solution and will keep my thinking hat on.

Urban

Urban, you may be on to something here...

From time to time in the my Web application, I am doing some redirection using PHP's header function (http://www.php.net/header) and the Location header. Of course, this modifies the HTTP response header and causes the browser to redirect.

Maybe, to help IE, I need to make a call to session_write_close(); right before I call the header function in order to redirect.

Drum roll please... Okay, this was a good thought. I tried adding that function call, but it had no effect on the problem.

Again, I've included another sample of the HTTP traffic except for this time, I've included it as a file attachment.

Attached Files

sample HTTP header data.txt (14.0 KB, 166 views)

brob5000

Reputation Points: 12

Solved Threads: 0

Newbie Poster

Offline

22 posts
since Jul 2004

Permalink

May 20th, 2007

Re: IE6/IE7 unexpectedly drops the PHP Session ID cookie (PHPSESSID)

Click to Expand / Collapse Quote originally posted by brob5000 ...

Yeah, I don't think IE is not going through a proxy like you are thinking.

Oops...I meant...

Yeah, I don't think IE is going through a proxy like you are thinking.

brob5000

Reputation Points: 12

Solved Threads: 0

Newbie Poster

Offline

22 posts
since Jul 2004

Permalink

May 20th, 2007

Re: IE6/IE7 unexpectedly drops the PHP Session ID cookie (PHPSESSID)

Click to Expand / Collapse Quote originally posted by brob5000 ...

Yeah, I don't think IE is not going through a proxy like you are thinking. What you are seeing in the HTTP activity is actually a result of Fiddler fiddling with things.

It sounds like you have used Fiddler before. Take a look at your IE proxy settings. Under most circumstances, you should not have any proxy settings. Now, start the Fiddler application. Now, go look at your IE proxy settings again. You should note how Fiddler has modified the settings in order to listen to all the HTTP traffic taking place within IE.

Fiddler acts "like a proxy" so that it can look at all the HTTP traffic. It modifies the proxy configuration of IE and points the HTTP traffic to the loop back address (127.0.0.1:8888). This is how it listens to everything that is going on. The program title is actually "Fiddler - HTTP Debugging Proxy".

As for the "Connection: close", this does appear to be a part of the HTTP/1.1 standard. See http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html.

Let me know what you think.

Sincerely,

Ben Roberts
Azalea Technology

I haven't used fiddler before. I recommend you use something like CAIN or Wireshark (formerly Ethereal). A "sniffer" that has to create a HTTP proxy that cannot fully implement HTTP 1.1 defeats the purpose.

Yes, Connection: close is defined in HTTP 1.1 specs. But HTTP 1.1 keeps a persistent TCP connection by default. Closing the connection means either the client or server does not support HTTP 1.1 fully.
The reason I said its odd is because both IE and Apache 2.x support HTTP 1.1 enough to keep a persistent connection. So its either a proxy that is fiddling (sorry... lame) with HTTP traffic or your application is setting the connection: close header.. (Unless you have some specific IE or Apache settings to do so, in which case you should test on other computers)

Usually, the simple cause of this problem is when you redirect to a new domain. The new domain can be www.example.com when you're on example.com, but from your HTTP dump (I haven't looked at the second) it seemed this wasn't the case. But knowing that it was from a proxy you still can't be sure...

Other than my advice to try and get a HTTP dump that isn't being altered by the application taking the dump, I'm stumped too.

digital-ether

Moderator

Reputation Points: 457

Solved Threads: 101

Nearly a Posting Virtuoso

Offline

1,250 posts
since Sep 2005

Permalink

May 20th, 2007

Re: IE6/IE7 unexpectedly drops the PHP Session ID cookie (PHPSESSID)

The cookies is getting real long. IE has a shorter limit on cookies saved for a domain, I believe. Could be you're running out of space in IE. Should look that one up..

digital-ether

Moderator

Reputation Points: 457

Solved Threads: 101

Nearly a Posting Virtuoso

Offline

1,250 posts
since Sep 2005

Page 1
2
3
4
Next

This thread is solved

Either the thread starter or a moderator has marked this thread as solved. You can most likely trust the responses and answers given. There is most likely no reason for any further responses to be posted here. If you have a related question, please start a new thread in this forum instead.

Previous Thread in PHP Forum Timeline: PHP: Javascript AlertBox

Next Thread in PHP Forum Timeline: change password

DaniWeb Message

Cancel Changes

User Name
Password