Problem loading web pages -- http timeout

Merkwurdigliebe · Post by **Merkwurdigliebe** » June 14th, 2006, 1:47 pm

I am intermittently getting these error pages:

"The server at kb.mozillazine.org is taking too long to respond."

You can put just about any URL in there, this is just the most recent.

I have read the stickies and none of the solutions work, and none really apply. This happens when the network is busy, and that happens from time to time. The removal of the "network.http.connect.timeout" setting in recent releases, coupled with a compiled-in timeout of about 5 seconds appears to be causing this.

I am on 1.5.0.3 for Windows on this box. The other affected boxes (at home) are at 1.5.0.4 for Windows, Linux, and OS X.

This has nothing to do with firewalls, proxies, SSL, antivirus software, or any other problems on my machines.

This is almost certainly caused by a product that is hard-coded to time out too soon for some networks. Since the changes were made, Firefox has become nearly useless on my home network, which is provided by a satellite ISP. I have had to revert to using Safari on the Macs and (groan) IE on Windows.

When you have satellite Internet, you never get less than about a 2-second ping due to the fixed nature of "c". (as in e=mc^2) It is about 36,500 km from my antenna to the satellite, every packet has to traverse that distance 4 times, minimum, and there are store-and-forward delays at every point in the hop. On a good day, pings to fast remote servers take about 2.5 seconds. When the network gets a little bit busier, Firefox starts tossing those errors, rendering it unusable at network latency levels that are easily tolerated by all my other browsers.

This problem does not affect IE, Safari, or Opera browsers running on the same machine(s) as the Firefox browser. None of my other network applications are breaking due to the network latency. I have done network captures of the traffic, and they show that Firefox is simply quitting if it doesn't get a response in 5 seconds, give or take. Is does not get a FIN/ACK and then quit, it just quits on its own.

I have searched for methods to change the timeout and all I found were references to the setting that used to be there. Is there any chance they would put it back in?

/***************************************************************************

If I missed an existing answer somewhere n the forums, it is because the search engine is returning this error instead of search results:

Could not insert search results

DEBUG MODE

SQL Error : 1062 Duplicate entry '1638081802' for key 1

Post by **trolly** » June 14th, 2006, 2:00 pm

Do you have full satellite or only downstream? If you have only downstream the request goes the normal way over your cable or phone line.

Merkwurdigliebe · Post by **Merkwurdigliebe** » June 14th, 2006, 2:07 pm

SATCOM provider is WildBlue. Uplink and downlink are both via the dish.

Post by **trolly** » June 14th, 2006, 2:14 pm

Is there an option to compress the data stream? This may add an additional delay.
I have seen situation that it takes 40 seconds and more until the error appears. It is possible that the data is highly fragmented and and is reblocked for better bandwidth usage. This also leads to higher response times.

Merkwurdigliebe · Post by **Merkwurdigliebe** » June 14th, 2006, 2:49 pm

There are no settings available to users to do that, but I am sure that since this is SATCOM, the provider (Hughes) is compressing the data to get as much out of their multi-billion $ bird as they possibly can. Having said that, the problem today was with a saturated T1 at work. Network congestion is just somethig that happens from time to time, and every network application needs to be able to deal with it. IE handled it OK today.

The default setting for network.http.connect.timeout was 5 seconds. There must have been a reason to have the setting in the first place, and I am pretty sure that the new hard-coded limit is not working out for a lot of people. Maybe they should take another look at the issue and see if it should be put back into the product. Alternatively, they could code an adaptive, latency-driven adjustment algorithm, but it would probably be a lot easier to "un-fix" what they "fixed" by simply giving us back this configfuration option.

Merkwurdigliebe · Post by **Merkwurdigliebe** » June 14th, 2006, 2:55 pm

I should add that this seems to happen not on the initial connection to a website, but on subsequent connection attempts to a site it has already connected to during the span of its current session. If I hit the "retry" button, it invariably connects as a result, and there appears to be a much longer delay allowed. It is certainly more than the five second timeout that spawns the error page.

Post by **trolly** » June 14th, 2006, 2:59 pm

I do not know exactly what network.http.connect.timeout means in his context but using normal terminology this is the time the server has to answer a connection request. The error message here would be "Server not found". Your problem seems more at another point. The message is probably about the answer time from the server after the connection is established.

Merkwurdigliebe · Post by **Merkwurdigliebe** » June 14th, 2006, 3:04 pm

I should add that this seems to happen not on the initial connection to a website, but on subsequent connection attempts to a site it has already connected to during the span of its current session. If I hit the "retry" button, it invariably connects as a result, and there appears to be a much longer delay allowed. It is certainly more than the five second timeout that spawns the error page.

Merkwurdigliebe · Post by **Merkwurdigliebe** » June 14th, 2006, 3:22 pm

Oops, that repost was an error.

This is what I think happens: When I open a connection to a particular URL for the first time in a session, Firefox gives me maybe 30 seconds to get a response. If I get one, it then marks that server as active. If I don't get a response, Firefox issues a server unavailable message and does not mark the server as active.

When a server that it considers active fails to respond within 5 seconds to a subsequent request, Firefox pops up the "... taking to long..." error page.

This behavior, if I have noted it accurately, is not a correct intepretation of HTTP network activity. Every HTTP request and response exist atomically - that is, once it completes, the HTTP server no longer knows you, and the next time you push a button you are starting from scratch (almost), maybe on another server which may well be in a different country than the previous server due to load balancing and fault tolerance procedures. There are no continous, straming connections in an HTTP session, and Firefox seems to assume that there is, as there would be in an FTP connection. HTTP is not very strongly connection-oriented. A web session can involve hundred of separate connections to the web server, and each one of them has the same probability of delay as the first.

If, as it seems, Firefox is assuming that once it sees a server it should drop the timeout to 5 seconds, it is not allowing for the nature of the beast. Every connection attempt of a session, first, middle, or last, needs the same timeout setting, because in reality every connection IS the first (and last) of its session.

geoffreycpeck · Post by **geoffreycpeck** » June 14th, 2006, 4:15 pm

I have the same issue, except its not related to a sat-link.

Since the compulsory upgrade to 1.5.0.4, Firefox has become very noticably slower to the point where I get regular time-outs from many diverse sites. Running 'informal' comparison with the dreaded IE, shows that it is now substantially faster and never returns a time-out. I'm doing head to head comparisons which seem pretty meaningful to me.

From an external point of view, FF progress bar zips to 50% and sits there...often 30-40 seconds...even on sites that do eventually return. When the site starts to load the page, its very slow to paint the screen...also taking 10-20 seconds. With IE running at the same time, typical load time is less than 5s, with effectively instant screen paint.

doing pings to the sites shows no obvious problems.

Running on XP with what seems to be the latest MS upgrades.

I've looked for a cause in the FAQ....

Post by **trolly** » June 14th, 2006, 4:18 pm

Take into account that IE uses cached content if the server can not be reached. So you will seldom see a load error in IE.

geoffreycpeck · Post by **geoffreycpeck** » June 14th, 2006, 4:40 pm

Thanks...good point, but I have tried to get around this by forcing a reload in both FF and IE. I assume that this will get around the IE cache?

I admit that its a very hard thing to compare definitively. I guess as a long time FF user I really did suddenly notice that the new release was a LOT slower and that has prompted the informal tests. Of course it could all be coincidental that something else occured at the same time...I see no big postings from others about this, so I'm happy to assume its just me, but FF is sooo much better than IE that I really want to keep using it.

Post by **trolly** » June 15th, 2006, 6:16 am

You can still try a new profile to check if something has not survived the update.

DavidSpector · Post by **DavidSpector** » March 14th, 2009, 10:04 am

This is the best description of this Firefox bug that I have ever found. Why does no one at Mozilla notice that Firefox's initial timeout is too low as compared with other browsers? There have been many revisions of Firefox, but this bug remains. (Note: all attempts at solutions are incorrect--it really does seem to be a bug.)

David Spector
Springtime Software

Post by **LoudNoise** » March 14th, 2009, 10:07 am

You are replying to an elderly thread (2006). Locking.

Problem loading web pages -- http timeout

Problem loading web pages -- http timeout

Re: Problem loading web pages -- http timeout

Re: Problem loading web pages -- http timeout