firefox slow redirect under ssl with gzip

Is this still an issue for you? We are trying to trying sort out the older Mozilla issues and would like to know if this still happens.

I have just retested now with FF 2.0.0.1....

and I cannot reproduce the problem, even after testing the same applications/pages I was having trouble with in December. I removed the "no-gzip" workaround which I had in place, but the problem did not reoccur.

I am slightly confused by this because even quite recently I had to update the regex in the BrowserMatch workaround to match against FF2.0.0.1 because the problem had started to occur again after our various (K)Ubuntu machines updated to that FF version.

My only explanation is that one of the other (k)ubuntu edgy upgrades fixed this (ubuntu recently upgraded to: a 2.6.17-11 kernel for example). In which case the problem perhaps was on the linux/ubuntu side rather than FF?

In any case, I suggest you close this and I can re-open if it reoccurs.

Thanks

Oliver

Closing via reporters comment. Thank you.

I am afraid the same symptom does still occur under feisty now. Exactly the same work around still works as well although the regexp is slightly different of course, due to a newer version of FF:

  # dodgy redirect delay bug for FF2.0 under ubuntu
  BrowserMatch "Firefox/2.*Ubuntu" no-gzip

Can anyone else confirm this?

Oliver,

 What version of firefox are you using to reproduce this, also can you give step by step instructions on how to reproduce this?

I set up a test site:
https://www.passwd.hu/~cus/firefox/index.php

If you click on the button you will submit your form to redirector.php and it will redirect you back to index.php.
You may have to click multiple times to hit the bug and experience the delay, but after the fifth or sixth try you almost certanly will.

Tested with Firefox 2.0.0.4.

@Marton

I tested your demo with Firefox 2.0.0.6. And the problem does occur for me about 30% of the time.

Also have also retested our own internal apps and they still have the same problem, also about 30% of the time.

btw i am using

oliver@oliveramd64x2:~$ uname -a
Linux oliveramd64x2 2.6.20-16-generic #2 SMP Thu Jun 7 20:19:32 UTC 2007 i686 GNU/Linux

which, perhaps significantly is a dual core AMD64 machine running 32bit Kubuntu.

kubuntu-7.04-alternate-i386.iso

because I found the amd64 version of kubuntu to be troublesome.

Just and idea...what are you running Marton?

I will try on a normal Pentium single core machine....

@ John Vivirito
Marton's demo is a good example.

oliver@lounge3100ubuntu:~/Desktop/octoshape$ cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 15
model : 4
model name : Intel(R) Pentium(R) 4 CPU 3.00GHz
stepping : 10
cpu MHz : 2992.788

kubuntu-7.04-alternate-i386.iso

oliver@lounge3100ubuntu:~/Desktop/octoshape$ uname -a
Linux lounge3100ubuntu 2.6.20-16-generic #2 SMP Thu Jun 7 20:19:32 UTC 2007 i686 GNU/Linux

is also able to reproduce the problem under Martons demo

I definitely can reproduce this trying to access an otrs2 instance with:

"Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.6) Gecko/20061201 Firefox/2.0.0.6 (Ubuntu-feisty)"

On the same box, konqueror does not experience the delay described earlier, and neither does firefox 2.0.0.6 from a windows machine hooked up to the same network.

I looked at my apache2 config, and I'm not using mod_gzip, and there does appear to be content in the redirect (it isn't headers only). However, I am seeing the same sort of delays, and it appears to be specific to firefox on ubuntu.

In case someone else comes down this rabbit hole, we editted the template for the redirect to use a javascript redirect, and the problem does not manifest itself -- ugly, but maybe a worthwhile workaround for some until the actual problem can be fixed.

The bug is not specific to Ubuntu, I experienced it on openSuSE.

@Tom Allen

you say:

"I looked at my apache2 config, and I'm not using mod_gzip"

are you sure, because under apache2 it is actually called mod_deflate.

The problem definitely disappears for me when i disable content compression.

On Mon, Sep 10, 2007 at 03:34:29PM -0000, Oliver Schonrock wrote:
> @Tom Allen
>
> you say:
>
> "I looked at my apache2 config, and I'm not using mod_gzip"
>
> are you sure, because under apache2 it is actually called mod_deflate.
>
> The problem definitely disappears for me when i disable content
> compression.
>

Is it SSL related for you at all? Or just compression?

 - Alexander

Ah, I do have the mod_deflate module available, but it does not appear to
be enabled.

On Mon, 10 Sep 2007, Oliver Schonrock wrote:

> @Tom Allen
>
> you say:
>
> "I looked at my apache2 config, and I'm not using mod_gzip"
>
> are you sure, because under apache2 it is actually called mod_deflate.
>
> The problem definitely disappears for me when i disable content
> compression.
>
>

I've not tried with/without SSL -- its SSL only in my test case.

On Mon, 10 Sep 2007, Alexander Sack wrote:

> On Mon, Sep 10, 2007 at 03:34:29PM -0000, Oliver Schonrock wrote:
>> @Tom Allen
>>
>> you say:
>>
>> "I looked at my apache2 config, and I'm not using mod_gzip"
>>
>> are you sure, because under apache2 it is actually called mod_deflate.
>>
>> The problem definitely disappears for me when i disable content
>> compression.
>>
>
> Is it SSL related for you at all? Or just compression?
>
> - Alexander
>
>

--
Tom Allen Email: tallen@10east.com
Senior Open Systems Engineer Phone: 904-220-3627
10East Corp FAX: 904-384-1038

On Mon, Sep 10, 2007 at 04:42:00PM -0000, Tom Allen wrote:
> I've not tried with/without SSL -- its SSL only in my test case.

Could you please test?

 - Alexander

have upgraded to kubuntu 7.10 (gutsy)

with

Firefox 2.0.0.6

same issue, i am afraid.

i had to add an additional BrowserMatch directive in the workaround for our internal apps, because the user-agent changed. correct lines for ssl.conf virtual host containers now are:

  BrowserMatch "Firefox/2.*Ubuntu" no-gzip
  BrowserMatch "Ubuntu.*Firefox/2" no-gzip

hope we can get to the bottom of this.

This is still a problem with 2.6.20-16-generic (ubuntu feisty) and firefox 2.0.0.6...
Try the dev.java.net sites if you want to see it ~really~ bad.
E.g. https://jax-ws-commons.dev.java.net/spring/

It is worth mentioning that this problem only shows up under some networks. Running from "home" on charter.net this is not a problem running from work and accessing the internet through the corporate network it is a huge problem, rendering the sites nearly unusable.

Thanks guys, for bringing this topic up.

I got edgy trying to find the source of the problem when it occurred in my develpment.
I'm using:
      Debian Etch on amd64 ( 2.6.18-5-amd64 #1 SMP Sat Sep 29 08:51:57 UTC 2007 x86_64 GNU/Linux )

      Apache https with gzip, (Server: Apache/2.2.3 (Debian) WebGUI/7.3.22 DAV/2 SVN/1.4.2 mod_python/3.2.10 Python/2.4.4 PHP/4.4.4-8+etch4 mod_ssl/2.2.3 OpenSSL/0.9.8c mod_apreq2-20051231/2.6.0 mod_perl/2.0.2 Perl/v5.8.8
  X-Powered-By: PHP/4.4.4-8+etch4)

      Browsers are
            IceWeasel 2.0.06 (is firefox) on debian and
            Firefox 2.0.0.7 on wndowsXP

     ServerApp:
             PHP4 with the header('Location: some-uri); command

     Network situtation:
             Occurs when browser and apache are on localhost
             Occurs when browser on WindowsXP in LAN and apache on server

And I can confirm that the combination https and Firefox with gzip causes these problems, I suspect that it does not depend on the platform at all.

The workaround as stated above works well, though with it, we loose gzip . For now it's fine, but I'd like a better one.

still happening with kubuntu gusty and FF3b3 (installed from backports repository).

Further information:

I am now testing with

server
--------
lighttpd-1.4.18_1 (not apache!)

PHP 5.2.5 (cgi-fcgi) (built: Dec 4 2007 20:05:21)
Copyright (c) 1997-2007 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2007 Zend Technologies

The compression is done by php (not lighttpd, which doesn't do that for dynamic content) using

zlib.output_compression = On

in php.ini

user-agent
--------------
firefox-3.0 3.0~b3~cvs20080101t1000+nobinonly-0ubuntu1~gutsy1 lightweight web browser based on Mozilla (De
on
Kubuntu Gutsy (7.10)
Linux lounge3100ubuntu 2.6.22-14-generic #1 SMP Fri Feb 1 04:59:50 UTC 2008 i686 GNU/Linux

The symtoms are exactlty the same, so that rules out apache and mod_deflate as possible causes.

For the workaround I am now using this php code, right at the top of each page:

# work around for the ubunu firefox redirect bug
if (isset($_SERVER['HTTPS']) &&
    isset($_SERVER['HTTP_USER_AGENT']) &&
    preg_match('~Firefox~', $_SERVER['HTTP_USER_AGENT']) &&
    preg_match('~Linux~', $_SERVER['HTTP_USER_AGENT']))
{
  ini_set('zlib.output_compression', 0);
}

Closing this bug, since it seems abandoned.

this is not abandoned. I have just rested this as above with lighttpd php zlib.output_compression and firefox 3.0.3 under kubuntu 8.10 x86 intrepid.

confirmed that bug still exists (30-50% of 302 redirects under https hang for 3-5s)

and confirmed that workaround (ie disabling gzip compression) solves this issue.

Unfortunatly I do not have the required skills to test further with this without the input of a FF/ubuntu dev. I am more than happy to invest time in testing etc...to get this fixed however.

If this is still a problem in firefox 3.0.7.
Please file this bug upstream at: https://bugzilla.mozilla.org and add the link to this bug report so we can track upstream progress.

Strangely, I'm experiencing the same problem with Firefox 3.0.10 (without any add-ons), but on Windows XP and without gzip.
It happens only with Firefox and https (20-40% of the redirects hang for 6-12s).
It does not matter whether I use 301, 302 or 303 redirects.
Without https and with other browsers (IE, Safari, Opera, Chrome) I have no problems.

Even more strangely, I do *not* have the problem if I run the same Firefox version on a Ununtu 8.10 VM on the same Win PC.

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.

see also https://bugzilla.mozilla.org/show_bug.cgi?id=369192

This problem still exists and appears to have become more severe (ie longer delays occurring more frequently) since FF 3.5. Now running FF3.5.7, lighttpd/1.4.22 and PHP 5.2.10.

my work around from above to disable gzip for FF under Linux still works:

# work around for the ubunu firefox redirect bug
if (isset($_SERVER['HTTPS']) &&
    isset($_SERVER['HTTP_USER_AGENT']) &&
    preg_match('~Firefox~', $_SERVER['HTTP_USER_AGENT']) &&
    preg_match('~Linux~', $_SERVER['HTTP_USER_AGENT']))
{
  ini_set('zlib.output_compression', 0);
}

anyone interested in working with me on this?

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).

making ad invalid since I cannot reproduce it anymore currently (see last comment). Will re-open if it reoccurs.