Closed Bug 369192 Opened 16 years ago Closed 13 years ago
.0 .0 .1long redirect delay with https and gzip
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:184.108.40.206) Gecko/20061208 Firefox/220.127.116.11 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:18.104.22.168) Gecko/20061208 Firefox/22.214.171.124 Location header (301/302) makes firefox hang for 1-12 seconds before going to the redirected page. This only occurs when using gzip content encoding on ssl encrypted pages (https). This is very annoying since many systems issue a redirect after each POST. Using live headers, I can clearly see that the delay is on the client side. Firefox receives the following headers (example from ssh encrypted squirrelmail login page): HTTP/1.x 302 Found Date: Sat, 03 Feb 2007 14:18:44 GMT Server: Apache/2.2.4 (Unix) mod_ssl/2.2.4 OpenSSL/0.9.7e PHP/4.4.4 X-Powered-By: PHP/4.4.4 Location: src/login.php Vary: User-Agent,Accept-Encoding Content-Encoding: gzip Content-Length: 20 Keep-Alive: timeout=5, max=100 Connection: Keep-Alive Content-Type: text/html After this the delay 1 up to 12 seconds occur before firefox issues " GET /src/login.php HTTP/1.1". If I disable gzip (mod_deflate) on the webserver the problem disappears. The certificate is issued by our own certificate authority, and the CA-certificate is installed in the browser. The problem is not present in firefox 1.0 or 1.5, or other mozilla based browsers like epiphany and galeon. On windows, firefox 2 does not have this problem. I have observed this behaviour on debian sarge and debian etch (clean firefox installation with new profile and no extensions). The is also an observation from ubuntu at https://launchpad.net/ubuntu/+source/firefox/+bug/76262. Reproducible: Always
I reported very similar bug. See Bug 368179. I am using mod_deflate too. But when I this module disable this bug for me exist still.
I have noticed the same issue in Firefox 126.96.36.199 and 188.8.131.52, but it works fine in 184.108.40.206. When I monitor my logs, I notice that when I sign in to my page, Firefox makes a request to /signin.php and receives a 302 response immediately. It then waits 1 to 15 seconds before issuing an HTTP request for the /index.php page that it was redirected to. I also am using mod_deflate over SSL. I've had this happen on my Mac Firefox, Windows Firefox, and Linux Firefox (Ubuntu and Gentoo). Currently as a workaround, I'm using version 220.127.116.11. Man, I'm so happy somebody else noticed this problem too. I thought I was going crazy for a while there.
I'm also seeing this on Gentoo Linux with the binary (official) Firefox. I put a testcase up at https://secureservicesonline.com/bugzilla-369192/ Firefox 18.104.22.168 still displays this behavior on Linux; 1.0.8/22.214.171.124 on Linux, and a 2.0.0.x on Windows does not.
Firefox 3beta5 Linux is ok.
I'm having this problem on Win XP with Firefox 3.0.10 (without any add-ons), against Apache2 without mod_deflate/gzip. It does not matter whether I use 301, 302 or 303 redirects. It happens only with Firefox and https (20-40% of the redirects hang for 6-12s). Without https and with other browsers (IE, Safari, Opera, Chrome) I don't see this happening.
Interestingly, I do *not* have this problem if I run Firefox 3.0.10 on an Ubuntu 8.10 VM on the same Win XP computer.
Another observation: If I set the priority of the Firefox process to high on Windows, I can make the problem go away, and if I use renice to lower the priority of the Firefox process on Ubuntu, I can provoke the problem here, too.
I have opened a new Bug 399981 for this problem happening on Windows XP and without gzip.
Sorry - the issue on Windows XP one is Bug 491153.
This is a long standing issue, reported by me on Launchpad: https://bugs.launchpad.net/ubuntu/+bug/76262 as reported there, it seems to have become more severe with FF3.5. Anyone interested in working on this with me?
This bug was reported on Firefox 2.x or older, which is no longer supported and will not be receiving any more updates. I strongly suggest that you update to Firefox 3.6.3 or later, update your plugins (flash, adobe, etc.), and retest in a new profile. If you still see the issue with the updated Firefox, please post here. Otherwise, please close as RESOLVED > WORKSFORME http://www.mozilla.com http://support.mozilla.com/kb/Managing+profiles http://support.mozilla.com/kb/Safe+mode
Whiteboard: [CLOSEME 5-15-2010]
Version: unspecified → 2.0 Branch
just retested with FF3.6.3 Kubuntu 10.04 lighttpd 1.4.26 and php 5.2.10. I CANNOT redproduce this currently. Hoping finally fixed in FF3.6 (since it was still occurring in FF3.5).
Status: UNCONFIRMED → RESOLVED
Closed: 13 years ago
Resolution: --- → WORKSFORME
I can confirm that the similar Bug 491153 still exists in FF 3.6.3, so I fear this one isn't really fixed either. It's just hard to reproduce since it seems to be a multitasking timing issue depending on the OS, hardware and what's currently running on the machine. I have set up a test page for Bug 491153 on my webserver so you can easily check if it happens on different machines.
we'll dupe to bug 491153 then, more recent
Resolution: WORKSFORME → DUPLICATE
You need to log in before you can comment on or make changes to this bug.