Closed Bug 142326 Opened 23 years ago Closed 9 years ago

Conn: configurable http timeout in UI

Categories

(Core :: Networking: HTTP, enhancement)

Product:
Core
Component:
Networking: HTTP
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WORKSFORME
Milestone:
Future

People

(Reporter: ryan_clemens, Unassigned)

References

(Depends on 1 open bug)

Details

any chance of having a user specified http timeout setting in the preferences
and having an Http connection retry after another user specified time?
This would need backend support...
Assignee: blaker → darin
Status: UNCONFIRMED → NEW
Component: Download Manager → Networking: HTTP
Ever confirmed: true
OS: Windows XP → All
QA Contact: sairuh → tever
Hardware: PC → All
-> future
Status: NEW → ASSIGNED
Summary: configurable http timeout → [RFE] configurable http timeout
Target Milestone: --- → Future
Was going to implement UI for this, since under advanced there is now HTTP
networking but seems even though there's a pref, it's not used:

http://lxr.mozilla.org/seamonkey/source/modules/libpref/src/init/all.js#449

// http specific network timeouts (XXX currently unused)
pref("network.http.connect.timeout",  30);      // in seconds
pref("network.http.request.timeout", 120);      // in seconds

Configable timeouts are fairly important. POP/IMAP/etc need some too. As an
example, a client of ours recently had their T1 die. So the backup 56.6 modem
kicked in, and, well, 25 users going though a modem, nothing was working. If I
wasn't able to give the users instructions on increasing POP timeouts in
Microsoft Outlook, they would not have been able to get mail at all.

The code that touches this pref in nsHttpHandler.cpp is commented out... Darin,
is this fairly difficult to (re?)implement? "Future" is a long way away.
it's futured because i don't seeing it being as important as other bugs :-/

the current timeout design is this: the socket transport will try for 30 seconds
to establish a connection.  if no connection after 30 seconds, then it'll error
out with NS_ERROR_NET_TIMEOUT.  once a connection is established, however, there
are no timeouts.  HTTP doesn't care how long the socket transport waits for
data.  the assumption being that the user could always cancel the request if it
was taking too long.  i think this behavior is reasonable, so this bug gets low
priority in my mind.
Summary: [RFE] configurable http timeout → [RFE] configurable http timeout in UI
darin: were these prefs ever used, in netlib or Comm 4, or were these just
unimplemented prefs that were left in the code?

ryan: to clarify a concept, there is no need to "retry" a connection. The
application asks TCP to establish a connection. TCP will tell IP to transmit
connection attempts (SYN) on a regular schedule, until a timeout period. The
timeout varies by OS, but the value lives in the stack. TCP waits for any of
these requests to come back w/ a reply (SYN-ACK). If nothing comes back by the
timeout, the attempt is treated as a failure.
QA Contact: tever → httpqa
Summary: [RFE] configurable http timeout in UI → Conn: configurable http timeout in UI
these timeout prefs are currently not honored.
bug 205140 requests the removal of these old prefs.

The old 30 second timeout did work for the 1.0.x branch. Darin has said that we
now use the system-level connection establishment timeout.

Jeremy, it sounds like you are more interested in user-configurable
application-level timeouts...

I've summarized some aspects of various timeouts here:

http://www.packetgram.com/pktg/docs/net/tcptimeout.html
Quite frankly, I find the general attitude about this to be totally irresponsible.  The impact of removing the network.http.connect.timeout variable has been tremendous.  The new method of "computing" how long the timeout will be is fallacious and changes based on the installation of the network and the operating system.  Under the "documentation" for the reasons for removing this variable, it states I should have a "60 second" window for loading HTTP requests before a timeout happens.  That is not so.  I have a 22 second timeout before I get the error message.  We are dealing with real-world situations here.  In the real world, not every website in the universe connects at blazingly fast speeds, and not every website in the world loads at blazingly fast speeds.  In the past, I have kept my network.http.connect.timeout set at 360 seconds.  That was adequate enough to connect to the slowest of the slow websites out there.  Now, my computer acts as if 1/3 or more of the whole Internet is not available.  The resolution of this problem should be addressed with much more aplomb that it is now.  I am sure the developers are just relying upon the bugzilla messages regarding these issues, however if you search around the internet, you will find an increasing number of web posts out there asking how they can "fix" the "bug" in Firefox 1.5 with regards to the page load timeout issues.  MANY people are finding they cannot reach many sites anymore.  I cannot even reach more than HALF the pages on YAHOO alone because of this.  Hopefully someone will come along and rectify this very soon - like within the next week or so.  It has taken me since the Beta release came out just to be able to track down what had happened with the timeout issues.  This is really a top priority issue.  It has essentially "broken" Firefox in the eyes of the user with not having this available as a UI setable option.
I whole-heartedly agree with comment #8. Well put kokuryu! I've been hitting timeouts on approx. 20% of pages since upgrading to version 1.5.
*** Bug 302901 has been marked as a duplicate of this bug. ***
Assignee: darin → nobody
Status: ASSIGNED → NEW
This means you can't - backend or frontend - increase the timeout time. 

loss of function, one person on irc wanted to increase timeout for Tor ... and there's no way to do so? (an about:config entry would have been enough)

Is it hardcoded at the moment?
there is no timeout in mozilla code (for http requests/responses) as far as I know.
I get a connection timeout in about 9 seconds on 1.5.0.5 and Ubuntu 6.06. I regularly need to access a site that is so slow as to trigger that timeout, making me unable to use the site.

Except for some reason increasing the value of network.ftp.idleConnectionTimeout from 300 to 3000 fixes this for me.

Given that this issue makes it impossible to access some times I suggest changing the severity from Enchancement to normal or minor.
For Windows users, there is a registry entry for number of retries to connect.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\TcpMaxConnectRetransmissions

XP and 2000 default to 2 retries, NT defaults to 3. The initial timeout is 3 seconds and doubles for each retry. I've set mine to 4 retries.

For further info see:

http://support.microsoft.com/default.aspx?scid=kb;en-us;314053

The issue IMHO is not so much with loading the page itself, but with the loading of non-essential third party page dependencies that prevent rendering until they've either loaded or timed out. The "we can just let the user decide when to stop on a case by case basis" argument doesn't work in this case. Clicking stop results in a blank page, even when it has downloaded the full html and everything else it needs to display the entire page, less the missing dependency. The only way Firefox will display a page missing a <script> dependency is if it times out trying to download it, which may take several minutes. Either FF needs timeouts or it needs to be able to render a page when the user clicks stop.
AFAICT, this (or a similar) timeout affects SOCKS-based connectivity, which can be problematic for some corporate network environments, and probably for users of things like Tor as well.

The SOCKS proxy timeout (not governed by OS-default timeout values) is not represented by any current preference, as far as I know, but the "9 seconds" in an earlier comment sure seems to be what I see when connecting through a slow-start SOCKS server.

See bug 407190 - not sure whether that's what's asked for here.
(In reply to bug 407190 comment #0)
> 1. Have a server which accepts your request, but needs 2 minutes to give you
> any data

This appears to be a different issue. The problem here is that the initial connect request to an HTTP server should have a configurable timeout, to avoid premature connection failures if the server is slow to respond (comment #4).
Bug 407190 is for already established connections that do not provide any response to an HTTP request.
Correct.  This bug refers to the TCP or proxied-TCP connection timeout (which is the problem when a SOCKS proxy takes a while to respond, for instance), not the HTTP request timeout once the TCP channel is open.
The patch in attachment 291925 [details] [diff] [review] was posted while I was writing my comment.
It defines preferences for both TIMEOUT_CONNECT and TIMEOUT_READ_WRITE cases for nsHttpConnection::CreateTransport(), thus should help with HTTP timeouts. Not sure if this would cover SOCKS/proxy connections too.
I'm going to close this bug as WONTFIX, because right now, we don't implement either HTTP timeout mentioned here. 

From the discussion here, there are several points which probably need to be addressed separately:

1- Connection establishment timeout - how long does necko try to make the connection? We use the default OS value. To me, this is the best implementation, because it works right now, and users probably need to tune their entire system if they think they need to control that behavior.

If we do implement "network.http.connect.timeout", we should try to do it via an API parameter, rather than using an external timer and closing the socket.


2- Connection timeout from lack of data - how long should necko wait before killing a connection? We don't do this right now. Classic TCP says: if you send a segment and it doesn't come back, you use the <>. Otherwise, there is no timeout (a request could go to a web server that ACK's but sends not data back).

3- Layout of a partially loaded page, when canceled (or transfer times out). I don't know if a page is valid when you cancel in the middle of loading <SCRIPT>. From a web developer's standpoint, you'd hope (and assume) that the javascript arrives and is executed as the HTML page is loaded and rendered.
WONTFIX.
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → WONTFIX
> WONTFIX, because ... we don't implement either HTTP timeout mentioned here.

Bug 407190 is about implementing that and has a patch.

I think this is very much needed. The default values of 1-2 minutes are ridiculous and source of a lot of grief for users when server or Internet go down.

Generally, servers should answer in seconds, not minutes.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
REOPEN
Status: REOPENED → ASSIGNED
Is anyone still working on this? I haven't seen a comment in a long time.
Yes, this really needs to be fixed.  I'm currently stuck on a connection with high
intermittent packet loss and many dropped connections.  Firefox doesn't care,
though, it'll happily wait forever for more data from the server, even if it's
never going to come.
This depends on bug 407190, which has a patch since about a year, but is waiting for a review.
This is a mass change. Every comment has "assigned-to-new" in it.

I didn't look through the bugs, so I'm sorry if I change a bug which shouldn't be changed. But I guess these bugs are just bugs that were once assigned and people forgot to change the Status back when unassigning.
Status: ASSIGNED → NEW
network.http.connection-timeout
Status: NEW → RESOLVED
Closed: 16 years ago → 9 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.