Closed Bug 491153 Opened 16 years ago Closed 10 years ago

Redirect with https can sometimes be very slow

Categories

(Core :: Networking, defect)

Product:
Core
Component:
Networking
Version:
2.0 Branch
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED INCOMPLETE

People

(Reporter: cito, Unassigned)

References

(
URL
)

Details

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.0.10) Gecko/2009042316 Firefox/3.0.10 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.0.10) Gecko/2009042316 Firefox/3.0.10 The test page does a very simple and commonplace thing: It posts a value to a page and then the post response redirects to the same page via get (using http code 302; http code 303 would be more correct here but shows the same behavior). What I experience is that sometimes the redirection (the time between the receipt of the response and the sending out of the get request) takes a very long time; up to 15 seconds. The test page shows the time for the redirect and repeats every 2 seconds. This effect seems to depend on the priority of the Firefox process. I can see it with the normal priority on Windows XP, suppress it by setting the priority to high and enforce it by setting the priority to low. If you access the same page with http instead of https, the problem disappears. I could not reproduce the problem with any other browser on the same PC. This is similar to 368179, 369192 and 399981, but I experience this with Firefox 3.0.10 on Windows and without compression. Reproducible: Sometimes Steps to Reproduce: rowse to https://www.cwa-web.de/testing/RedirectTest and watch the maximum redirect time. Actual Results: After a while, you should see unusually long redirects (up to 15s). Expected Results: The redirects should always be fast.
I was able to reproduce the effect on 3 different 32bit PCs with WinXP now, but not on all PCs I tested. Maybe it affects only a small percentage of PCs, since I did not see anybody else reporting this issue (only a similar one on Linux). Also, when it happens, it does not happen on every redirect, but only sometimes. I do not think it is caused by firewall or background services since I got this effect even after stopping/uninstalling the firewall and nearly all services. Nor do I think it's a networking issue, since it does not seem to matter where the webserver is running - it even happens when the webserver runs on the same PC. I was also able to reproduce the effect on OpenSUSE and Ubuntu running as VM on a WinXP PC that showed this effect. Increasing the priority of the Firefox process extenuates the effect, decreasing the priority enforces it (on the Linux VMs I was only able to see it after renice -20).
Just repeated the above test with my old Win XP PC and still could reproduce the maximum redirect of 15s. On my new Win 7 PC I was not able to reproduce it.
Forgot to mentioned that I tested with the new Firefox 3.6 version on both Win XP and Win 7.
Firefox 3.6.3 on my Win XP PC is still showing this problem.
Nice test page Christoph. Despite having been able to reproduce this bug in the past and being one the main reporters of it, I am not able to reproduce it now. Even with with Christoph's test page. Christoph: I use to have to use gzip compression on the page to reproduce this problem. Can you add that to your test? Tested with: Firefox 3.6.3 under Kubuntu 10.04
Thanks for the feedback, Oliver. If you replace "testing" with "testing-deflate", you get the page delivered with gzip compression: https://www.cwa-web.de/testing-deflate/RedirectTest By replacing "RedirectTest" with "RedirectTestLong" you can check with extra long page content: https://www.cwa-web.de/testing-deflate/RedirectTestLong But both does not seem to enforce the problem for me (on Windows).
Thanks for the super quick update christoph.. I am afraid i still can't reproduce it anymore...this is in line with my own tests which I made recently and reported on several bugs on Launchpad. Tested in 2 machines with FF3.6.3 & Kubuntu 10.04 Results below... https://www.cwa-web.de/testing-deflate/RedirectTest Redirect Time Test Test 58: Time 0.05s, Avg 0.053s, Max 0.15s https://www.cwa-web.de/testing-deflate/RedirectTestLong Redirect Time Test Test 108: Time 0.051s, Avg 0.052s, Max 0.15s
Ok, then it seems Bug 369192 was somewhat similar, but not the same. I hope some people can check if they can reproduce this on Win XP machines.
Reporter, please retest with Firefox 3.6.12 or later in a fresh profile (http://support.mozilla.com/kb/Managing+profiles). Also update your plugins (flash, adobe reader, java, quicktime, silverlight, etc.) Go to the developer's website and download the latest version from there. If you no longer see this issue, please close this bug as RESOLVED, WORKSFORME. If you do see the bug, please post a comment.
Whiteboard: [CLOSEME 2010-12-01]
Yes, I can still reproduce this problem with a fresh FF 3.6.12 installed on a virtual machine that never had FF installed before. Since my old Win XP PC is not available any more, this time I tried it on a Windows XP Virtual PC running on my new fast Win 7 as host. If FF runs directly on the Win 7 host, everything is fine, but if it runs on the Win XP guest, I see these same delays of up to 15 seconds again (not every time, so let the test app at https://www.cwa-web.de/testing/RedirectTest run for a while, e.g. let it do 100 redirects). Note that this problem only showed up under Windows XP, not under Win 7 (did not test under Win Vista). As I wrote earlier, it does not seem to have anything to do with service, firewall or network, but maybe with the scheduling algorithm of the OS. I think it was modified in Win Vista and 7.
Whiteboard: [CLOSEME 2010-12-01]
Version: unspecified → 3.6 Branch
Reporter, Firefox 4.0.1 has been released, and it features significant improvements over previous releases. Can you please update to Firefox 4.0.1 or later, and retest your bug? Please also create a fresh profile ( http://support.mozilla.com/kb/Managing+profiles), update your plugins (Flash, Java, Quicktime, Reader, etc) and update your graphics driver and Operating system to the latest versions available. If you still continue to see this issue, please comment. If you do not, please close this bug as RESOLVED > WORKSFORME filter: prefirefox4uncobugs
I have checked again using the same test app at https://www.cwa-web.de/testing/RedirectTest (sorry, the certificate has just expired, it will be replaced, but that should not matter for the test anyway). I was able to reproduce the problems reported earlier for FF 3.6.12 with FF 3.6.17 under Windows XP SP3, both on a dedicated machine and a virtual host on a different machine. I'm, still getting delays of up to 15 seconds after about 100 redirects. I have also checked with FF 4.0.1 and found that the problem persists, but the behavior has somewhat changed. Now, the delays seem to happen less frequently, only after about 200-400 redirects, but *when* they happen they are extremely long - I experienced delays of 20 minutes several times on both machines. I never experienced such long delays with FF 3.x, only up to 15 seconds. Again, I can only reproduce this under Win XP, not under Win 7.
Version: 3.6 Branch → 4.0 Branch
Windows XP SP2, running inside VBox with Mozilla/5.0 (Windows NT 5.1; rv:12.0a2) Gecko/20120307 Firefox/12.0a2 short test version: Test 87: Time 0.06s, Avg 0.061s, Max 0.14s Test 107: Time 0.08s, Avg 0.061s, Max 0.2s long test version: Test 139: Time 0.065s, Avg 0.062s, Max 0.22s I did not experienced long redirect times.
I have tried again with FF 10.0.2 on Win XP SP3. I have seen the problem again 2 or 3 times, but could not reliably reproduce it any more even in one session with thousands of repetitions. However, I still can reproduce the problem when I set the priority of the firefox process to "low" using the task manager. It's the same as with FF4: After about 200-400 repetitions, suddenly a redirect would take 7 minutes. The number of repetitions and the time of the delay varies, but it's about this order of magnitude. It seems the problem is still not fixed completely, but its incidence rate has decreased further.
Is this issue still reproducible with the latest Firefox version? https://www.mozilla.org/de/firefox/new/
Flags: needinfo?(cito)
Good day, The test link is not working anymore, personally i did not noticed any slow load times via HTTPS. The situation could be related to internet connection / hosting provider of the visited site.
Component: General → Networking
Product: Firefox → Core
Version: 4.0 Branch → 2.0 Branch
Status: UNCONFIRMED → RESOLVED
Closed: 10 years ago
Resolution: --- → INCOMPLETE
@Jan: Yes, I can still reproduce it even with FF 43.0.1, but as before only under Windows XP. As I wrote above, I think it has something to do with the scheduling algorithm of XP. I have reactivated the link so you can try yourself. Of course XP is meanwhile not really relevant any more... @Ursan: No, this has nothing to do with the Internet connection, I have ruled that all out. I *can* reproduce it with XP on a LAN, even on the same PC. And I *can't* reproduce it with Win 7, using the Internet host. See my comments above.
Flags: needinfo?(cito)
On windows 7 looks OK: Time 0.068s, Avg 0.061s, Max 0.068s Is your XP upgraded to SP3 ? or the Lan driver is up-to-date ?
@Ursan: XP is latest version, SP3, with all patches. LAN driver is up to date, I could also reproduce it on different computers with different network cards and LAN drivers, and on a virtual machines.
Good morning, With a chance to sound a bit weird, but: - are we talking about the same hardware on those different computers ? Even apples don`t look the same, even if they come from the same tree :) - have you noticed this with both Virtual Box and Vmware ? Emulation has his drawbacks, but may show you if the situation is happening in both cases. Be aware that Windows XP is no longer supported, even if you own a license for it, its still unsupported .
@Ursan: Tested with different PCs (different hardware), and Virtualbox. The ticket was opened 7 years ago, I know that XP is unsupported and personally don't use it any more.
You need to log in before you can comment on or make changes to this bug.