Public bug reported:
Under kubuntu edgy (suspect also ubuntu edgy) firefox 2.0 will seemingly
hang for about 3-5s seconds when performing an http 302 redirect only
when:
a) the connection is https
b) the page uses gzip compression (mod_deflate apache 2.0.59)
The redirect eventually works but the delay is very annoying and makes
many applications which redirect after form submits quite unusuable.
issue does not occur if:
a) connection is http (no 's')
b) connection does not use gzip content compression
c) the http reponse is a "200 OK" rather than a "302 temporarily moved"
d) browser you use is not FF
e) browser is FF < 2.0 (eg under dapper FF 1.5 works ok)
e) OS you use is not ubuntu (ie FF 2.0 under M$ works ok)
a work around if you have control of the server is to put this in the
apache ssl.conf in the ssl virtual host block:
# dodgy redirect delay bug for FF2.0 under ubuntu
BrowserMatch "Firefox/2.0 \(Ubuntu-edgy\)" no-gzip
result is no more delay on redirect (although the following page loads more
slowly due to no gzip of course)
The above work around also semi proves that the issue is "ssl + gzip + FF2.0 +
ubuntu + 302"
If you use LiveHttpHeaders the 3-5s delay can be clearly observed after
the 302 response is received. Almost seems like FF does not realise that
the "headers only" response is finished and that it should now
redirect...until something times out.
Does this occur on Debian also?
** Affects: firefox (Ubuntu)
Importance: Undecided
Status: Unconfirmed
** Changed in: Ubuntu
Sourcepackagename: None => firefox
** Description changed:
Under kubuntu edgy (suspect also ubuntu edgy) firefox 2.0 will seemingly
- hang for about 3-5s seconds when performing an http 301 redirect only
+ hang for about 3-5s seconds when performing an http 302 redirect only
when:
a) the connection is https
b) the page uses gzip compression (mod_deflate apache 2.0.59)
The redirect eventually works but the delay is very annoying and makes
many applications which redirect after form submits quite unusuable.
issue does not occur if:
a) connection is http (no 's')
b) connection does not use gzip content compression
- c) the http reponse is a "200 OK" rather than a "301 temporarily moved"
+ c) the http reponse is a "200 OK" rather than a "302 temporarily moved"
d) browser you use is not FF
e) browser is FF < 2.0 (eg under dapper FF 1.5 works ok)
e) OS you use is not ubuntu (ie FF 2.0 under M$ works ok)
a work around if you have control of the server is to put this in the
apache ssl.conf in the ssl virtual host block:
# dodgy redirect delay bug for FF2.0 under ubuntu
BrowserMatch "Firefox/2.0 \(Ubuntu-edgy\)" no-gzip
result is no more delay on redirect (although the following page loads more
slowly due to no gzip of course)
- The above work around also semi proves that the issue is "ssl + gzip + FF2.0
+ ubuntu + 301"
+ The above work around also semi proves that the issue is "ssl + gzip + FF2.0
+ ubuntu + 302"
If you use LiveHttpHeaders the 3-5s delay can be clearly observed after
- the 301 response is received. Almost seems like FF does not realise that
+ the 302 response is received. Almost seems like FF does not realise that
the "headers only" response is finished and that it should now
redirect...until something times out.
Does this occur on Debian also?
** Tags added: edgy firefox
--
firefix 2.0 slow redirect under ssl with gzip
https://launchpad.net/bugs/76262
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
