 |  |  |  |  |  |  |  |
IE6/IE7 unexpectedly drops the PHP Session ID cookie (PHPSESSID)
Please support our PHP advertiser: PostgreSQL or MySQL? Compare and contrast the two most popular open source databases
Thread Solved |
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.
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.
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
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
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)
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
•
•
•
•
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
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.
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
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
•
•
Join Date: Sep 2005
Posts: 1,075
Reputation: 
Solved Threads: 66
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.
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.
www.fijiwebdesign.com - web design and development and fun
Cpanel Email - Let users Register email accounts on your website upon registration
Ajax Chat - Fully browser based chat!
Cpanel Email - Let users Register email accounts on your website upon registration
Ajax Chat - Fully browser based chat!
•
•
•
•
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.
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.
•
•
•
•
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.
Sincerely,
Ben Roberts
Azalea Technology
•
•
•
•
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
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.
•
•
•
•
Originally Posted by brob5000
Yeah, I don't think IE is not going through a proxy like you are thinking.
Yeah, I don't think IE is going through a proxy like you are thinking.
Ben Roberts
Azalea Technology
Azalea Technology
•
•
Join Date: Sep 2005
Posts: 1,075
Reputation:
Solved Threads: 66
•
•
•
•
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
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.
www.fijiwebdesign.com - web design and development and fun
Cpanel Email - Let users Register email accounts on your website upon registration
Ajax Chat - Fully browser based chat!
Cpanel Email - Let users Register email accounts on your website upon registration
Ajax Chat - Fully browser based chat!
•
•
Join Date: Sep 2005
Posts: 1,075
Reputation:
Solved Threads: 66
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..
www.fijiwebdesign.com - web design and development and fun
Cpanel Email - Let users Register email accounts on your website upon registration
Ajax Chat - Fully browser based chat!
Cpanel Email - Let users Register email accounts on your website upon registration
Ajax Chat - Fully browser based chat!
 |
Other Threads in the PHP Forum
- Previous Thread: Need a 301 redirect script for php to html
- Next Thread: Php script accessing the default table..?
| Thread Tools | Search this Thread |
You need to join our community in order to build your list of favorite forums. You can visit the forum index for a listing of all forums.
Related Forum Features
Latest PHP Posts
- Today's Posts
- Unanswered Threads
apache api array beginner binary body broken buttons cakephp checkbox class cms code cron curl database date date/time display dynamic ebooks echo email error file files folder form forms function functions global google href htaccess html image include insert ip javascript joomla limit link list login mail mediawiki menu mlm msqli_multi_query multiple mycodeisbad mysql number oop parameter paypal pdf php phpincludeissue problem query radio random recourse recursion regex remote script search seo server sessions sms source sp space speed sql static subdomain syntax system table tag tutorial update upload url validator variable vbulletin video web webdesign white wordpress xml youtube
