Open Bug 1719658 Opened 5 years ago Updated 5 years ago

NetwokError after 30 seconds

Categories

(Core :: Networking, defect, P3)

Firefox 89
defect

Tracking

()

UNCONFIRMED

People

(Reporter: krzysiek.herod, Unassigned)

References

(Blocks 1 open bug)

Details

(Whiteboard: [necko-triaged])

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:89.0) Gecko/20100101 Firefox/89.0

Steps to reproduce:

Go to https://sinatra-test-u5syffpnsa-ew.a.run.app/ and open Web Developer Tools. Then click "Link 31" or "Link 45" (31 and 45 are the numbers of seconds after which the server will respond). You will see "Uncaught (in promise) TypeError: NetworkError when attempting to fetch resource." in the console. This won't happen if you click "Link 2" or if you click any of these links in Chrome.

The code operating on the server is here: https://github.com/netizer/sinatra-test If you want you can clone it and deploy it to Google Cloud run or Google App Engine. It might be reproducible in other services as well, but many of them (like Heroku or Scalingo) have a server-enforced 30 seconds timeout.

Actual results:

"Uncaught (in promise) TypeError: NetworkError when attempting to fetch resource." appears in the console. The connection with tthe server is dropped after 30 seconds.

Expected results:

Firefox should not drop the connection after 30 seconds. We should see another "everything went fine" after clicking "Link 31" or "Link 45".

Considering that "network.http.connection-timeout" is set to 90, only connections of requests that take at least 90 seconds should be dropped.

The Bugbug bot thinks this bug should belong to the 'Core::Networking' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Component: Untriaged → Networking
Product: Firefox → Core

This is happening because the server speaks HTTP3, and we have a hard-coded timeout of 30s there[1]. You can see that the request to e.g. /31 succeeds if you fetch in parallel another path e.g. /12 - because the response after 12s resets the idle timer. /12 of course is not sufficient if the longer-waiting resource is greater than 12+30=42. Disabling HTTP3 also results in success.

MT says this shouldn't be hard to make configurable, but I'm not sure whether the right option here is to do that, or to just make it clear that the http connection-timeout pref doesn't apply to H3.

[1] https://github.com/mozilla/neqo/blob/0e8279fb4a4dd665401e144c81f04aa27965973b/neqo-transport/src/connection/idle.rs#L10

Severity: -- → S3
Priority: -- → P3
Whiteboard: [necko-triaged]
Blocks: QUIC

See https://github.com/mozilla/neqo/pull/1177/commits/f02528b1a567ae4e9f8046326fc6070038822cd5 which is part of https://github.com/mozilla/neqo/pull/1177

30 seconds is a long time, but I guess not everyone can rely on concluding their business in that time. I'll let Nihanth look into plumbing the pref through.

You need to log in before you can comment on or make changes to this bug.