Last Comment Bug 223125 - Closed connection is not reported
: Closed connection is not reported
: helpwanted
Product: Core
Classification: Components
Component: Networking (show other bugs)
: Trunk
: Other Other
-- minor (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
: Patrick McManus [:mcmanus]
: 286086 286087 (view as bug list)
Depends on:
  Show dependency treegraph
Reported: 2003-10-21 12:30 PDT by Martin Sch
Modified: 2012-02-10 07:42 PST (History)
7 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

http log from simulation of scenario described by reporter (11.03 KB, text/plain)
2003-10-25 13:08 PDT, Darin Fisher
no flags Details

Description User image Martin Sch 2003-10-21 12:30:09 PDT
I first go to Then I enter the (sample) URL
If another.server accepts the GET request from my browser but closes the
connection without sending any data, the browser is left with the page content
of and the URL of another.server. If this was a temporary problem
and I press reload, the page from is reloaded.
Comment 1 User image Darin Fisher 2003-10-21 12:41:42 PDT
this is a matter of error reporting mainly.  i suspect docshell is not handling
this error case correctly.
Comment 2 User image Boris Zbarsky [:bz] (still a bit busy) 2003-10-25 12:10:17 PDT
well... even if docshell reports the error, the URI field will not change, will
it?  Just like for a DNS error, eg.

That said, what error should docshell be looking for?  NS_BINDING_ABORTED?  Or
something a little more specific?  The code currently handles

Reporter, could you possibly post a url to a page that shows this bug?  That
would make testing fixes possible...
Comment 3 User image Darin Fisher 2003-10-25 13:08:49 PDT
Created attachment 134125 [details]
http log from simulation of scenario described by reporter

notice that OnStartRequest is called, followed by OnStopRequest with status =
NS_OK.	OnDataAvailable is never called.  now, disregarding for a moment
whether or not it is correct for necko to send these callbacks with a NS_OK
status... docshell should still be throwing up a blank window for the loaded
URL.  an empty document should not be ignored, right?  it should show an empty
document ;)
Comment 4 User image Martin Sch 2003-10-25 13:12:33 PDT
Upon special request, I could start a program on my PC which drops the
connection after a GET request. You would reach it at

But I just found that connecting to localhost:777 or
causes the same problem.
Comment 5 User image Boris Zbarsky [:bz] (still a bit busy) 2003-10-25 13:23:32 PDT
> localhost:777 or

The former gives me a connection refused error; the latter spins the throbber
for a long time (I didn't wait for it to time out).

Darin, if OnStartRequest is followed immediately by OnStopRequest, then
nsParser::OnStopRequest will deal and create a new document... if the parser
ever hears about it.  In this case, it does not.  A new document should NOT be
created for all requests (eg consider requests that end up being handled by
helper apps).

What it looks like in your log is that there is absolutely nothing to work with
for the content type so content dispatch simply fails in the URILoader.  Perhaps
the URILoader should report such an error, though I don't like having the
URILoader know anything about the UI...

Comment 6 User image Boris Zbarsky [:bz] (still a bit busy) 2003-10-25 15:27:57 PDT
OK.  So I've tracked this down.  The problem is that
nsDocumentOpenInfo::OnStartRequest checks for a 204 or 205 response.  To do this
is gets the response status on the channel.  If the GetResponseStatus call
fails, it just returns NS_OK.

In this case, there is no response, so there is no mResponseHead, hence
GetResponseStatus throws NS_ERROR_NOT_AVAILABLE.  That's hardly a useful error
code.  ;)

Now there are a few options here:

1)  The http channel itself could treat this case as an error and deliver an
    error-status OnStopRequest.
2)  The http channel could return a useful error code and nsDocumentOpenInfo
    could Cancel() with that error code.
3)  The http channel could keep on as it is and nsDocumentOpenInfo could make up
    an error code for this case or something.
4)  The http channel could make up a bogus status even if there is no
    mResponseHead (at least if OnStartRequest has been called).

darin?  Thoughts?
Comment 7 User image Darin Fisher 2004-02-24 21:18:30 PST
Comment 8 User image benc 2005-01-14 08:50:28 PST
Is this the condition that used to result in "document contains no data" in
Comment 9 User image Erik Fabert 2005-03-14 08:51:34 PST
*** Bug 286086 has been marked as a duplicate of this bug. ***
Comment 10 User image Adam Hauner 2005-03-14 23:31:13 PST
*** Bug 286087 has been marked as a duplicate of this bug. ***
Comment 11 User image Wayne Mery (:wsmwk, NI for questions) 2009-01-31 11:21:26 PST
Jens, do you still see this problem?
Comment 12 User image Wayne Mery (:wsmwk, NI for questions) 2012-02-09 18:14:48 PST
bz, do we still need this?
Comment 13 User image Boris Zbarsky [:bz] (still a bit busy) 2012-02-09 18:26:46 PST
Comment 14 User image Martin Sch 2012-02-10 05:26:48 PST
I wrote a java program that opens a server socket, waits for a connection, reads the input and closes the connection. Firefox 10 now says:
"The connection was reset".

So this seems to be fixed.
Comment 15 User image Boris Zbarsky [:bz] (still a bit busy) 2012-02-10 07:14:32 PST
How did you close the connection?  Exactly what happens on the HTTP and TCP levels here is very important.  The original steps in this bug involved a connection close that looked like a normal but empty HTTP response to our HTTP stack.

Perhaps we changed things so that nothing the server does can trigger that behavior anymore?
Comment 16 User image Patrick McManus [:mcmanus] 2012-02-10 07:29:49 PST
could it be related to the fact that a 0 byte (no hdr) response used to be considered a 0 length well formed http/0.9 response and is now considered an error (like everyone else does)?
Comment 17 User image Boris Zbarsky [:bz] (still a bit busy) 2012-02-10 07:42:27 PST
Yes!  That change almost certainly fixed this bug.

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