Connection is being disrupted to the browser
Categories
(Core :: Networking, defect)
Tracking
()
People
(Reporter: tony, Unassigned)
Details
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:89.0) Gecko/20100101 Firefox/89.0
Steps to reproduce:
Hi, hoping someone can help point me in the right direction....I have a web app that has lots of data, we run several scripts that can take a while to process. All was operating fine on version FF87, version 88 would just stop processing the script and the browser would not allow me to do anything else on that site. ... there were no error messages (that I can find).
I downloaded the Beta of V89 and all worked fine
Public release of V89 has the error
It works fine on all other browsers
It works fine on the local server version on my machine
The issue only occurs when using https connection
...any information would be helpful to me.. please and thank you in advance!!
Actual results:
The process does actually complete but the connect to the browser is lost.
Expected results:
At the end of the script it is supposed to redirect to a page but is doesnt.
|
||
Comment 1•5 years ago
|
||
Since this seems to be a Networking issue, moving it over to that component. Please move it to the correct one if this is not it, thanks!
I have created a test page to show what I mean:
http://grifgraf.com.au/time_test.php?time=20 ....works fine
https://grifgraf.com.au/time_test.php?time=20 ....works fine
http://grifgraf.com.au/time_test.php?time=30 ....works fine
https://grifgraf.com.au/time_test.php?time=30 ....does not work (30 seconds or more fails)
Works in other browsers fails in FF After 30 secs the loading pulse stops and the process result is not displayed. But is the process does seem to continue
|
||
Comment 3•5 years ago
|
||
Your site is served from a server that speaks HTTP/3, I suspect that difference between 89 stable and beta is use of HTTP/3, beta has it enabled by default and in release it is enabled by a rollout therefore it may not be enabled immediately on a new profile.
you can turn HTTP/3 support on/off if you type about:config into the address bar and search for network.http.http3.enabled and set it to false/true.
I cannot reproduce the problem. Can you tell me what is displayed in devtools, is there any values in "Timings" tab for a failing request.
we have 30s timeout for the TLS handshake, but from my test the TLS handshake was done in ~200ms.
(In reply to Dragana Damjanovic [:dragana] from comment #3)
Your site is served from a server that speaks HTTP/3, I suspect that difference between 89 stable and beta is use of HTTP/3, beta has it enabled by default and in release it is enabled by a rollout therefore it may not be enabled immediately on a new profile.
you can turn HTTP/3 support on/off if you type about:config into the address bar and search for network.http.http3.enabled and set it to false/true.
I cannot reproduce the problem. Can you tell me what is displayed in devtools, is there any values in "Timings" tab for a failing request.
we have 30s timeout for the TLS handshake, but from my test the TLS handshake was done in ~200ms.
thanks you so much!!! that fixed it! I set network.http.http3.enabled to false.
So what does this mean for the future? do I need to fix my site to allow http/3 to work properly? is there a server setting to alter to allow for a long
connection time? ...any/all advice is welcome!
|
|
||
Comment 5•5 years ago
|
||
Just to understand, this is working properly with HTTP/3 disabled, but it is not working properly with HTTP/3 enabled?
If that is the case this will be fixed by PR 1160. The fix will only be ready for Firefox 92.
There is a 30s timeout on a HTTP/3 connection, to mitigate the problem on your side is it possible to make response come back in less than 30s?
Yes you are correct!
It is working properly with HTTP/3 disabled, but it is not working properly with HTTP/3 enabled!
We look forward to Firefox 92, .. at this point it not a major issues as we can use other browsers for specific tasks.
Thanks so much @Dragana for you help, I really appreciate it!
|
||
Comment 7•5 years ago
|
||
This bug will be fixed by allowing a longer timeout for HTTP/3.
Description
•