Main Area and Open Discussion > General Software Discussion

Problem: The connection to the server was reset ...

(1/3) > >>

barney:
Folk,

Been meaning to submit this query, but keep forgetting.  The browser (FF 3.x) error message is, "The connection to the server was reset while the page was loading."

Several versions of Firefox, IE7 & 8, Google Chrome (non-beta), Opera v10.x, Comodo Dragon v?, Safari v?, all on a Win7 or WinXP SP3 box, all giving equivalent messages.  It's not consistent, but I might see it while trying to preview a post here, while trying to browse to a new Web site, or even when trying to view a page-in-work on my local version of Apache.

Many searches have garnered that it is not all that uncommon an error to encounter, and have indicated it's likely from one (1) of three (3) areas:

* the remote server disconnected, for a variety of reasons,
* the [local] DNS server interrupted the request,
* something local, such as a firewall, created the disconnect.It's really frustrating, 'cause there's no clear indication where to look for causes.

I'm reasonably certain it's not a firewall (Comodo or the new MS offering) issue, but could be persuaded otherwise.
That it could be a DNS issue is not a stretch, considering Grande's performance of late.
Remote server issues seems realistic, save for the frequency, albeit randomness, of the occurrence.

OK, the question:  does anyone know of an error/trace logging software that will annotate where/when an error occurs in a Web request? 

Ideally, it would follow an HTTP(S) request from initiation to completion, but write to a log only when some error occurred during that process.  I'm thinkin' that someone, somewhere, has done this in order to validate Web/link requests, but have had no luck findin' the thing.  (If someone hasn't built it, they damned well should have  ::).)

Any hints welcome, a resolution would be fantastic!

Shades:
Type in the command-box the following:
     tracert <url-of-your-choice>

This will give you a more precise idea where your packets take (too) long to pass. And likely also a better clue of where to begin the problem-solving.

cthorpe:
Running NOD32 as your anti-virus?

barney:
@Shades:
Yeah, tracert will work, but only after the fact.  For example, I could run tracert after I get the message only to discover that nothing is wrong.  That's because whatever caused the original issue is no longer active/effectual/extant/working/there.  Tracert is a great tool for a consistent, non-random, problem, 'specially since it can be scripted, but it'll not work on something that has already happened  ;D.

@cthorpe:
Nope.  MSE for everything but firewall, which is Comodo, free version. [Edit - added comment] Also happened with Avira A/V & two (2) other firewalls.

Shades:
You can see also the time it takes for packets to make their hop. During the worldcup, I had the same problem as you are experiencing now. After using the command I could pinpoint the problem.

A Telefonica server based in Argentina was not up for the task (or setup to serve Argentinians first, I don't know). I live in Paraguay, a neighboring country, so that was a simple case of: too bad for me. But also a reassurance that it was not my hardware or software.

Navigation

[0] Message Index

[#] Next page