11.03 KB, text/plain
I first go to http://www.mozilla.org/. Then I enter the (sample) URL http://another.server. 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 mozilla.org and the URL of another.server. If this was a temporary problem and I press reload, the page from www.mozilla.org is reloaded.
this is a matter of error reporting mainly. i suspect docshell is not handling this error case correctly.
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 NS_ERROR_UNKNOWN_HOST, NS_ERROR_CONNECTION_REFUSED, NS_ERROR_UNKNOWN_PROXY_HOST, NS_ERROR_PROXY_CONNECTION_REFUSED, NS_ERROR_NET_TIMEOUT, NS_ERROR_REDIRECT_LOOP, NS_ERROR_UNKNOWN_SOCKET_TYPE, NS_ERROR_NET_INTERRUPT, and NS_ERROR_NET_RESET. Reporter, could you possibly post a url to a page that shows this bug? That would make testing fixes possible...
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 ;)
Upon special request, I could start a program on my PC which drops the connection after a GET request. You would reach it at http://j-m-s.dyndns.org:7070/ But I just found that connecting to localhost:777 or http://www.mozilla.org:8001/ causes the same problem.
> localhost:777 or http://www.mozilla.org:8001/ 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...
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?
Is this the condition that used to result in "document contains no data" in Communicator?
*** Bug 286086 has been marked as a duplicate of this bug. ***
*** Bug 286087 has been marked as a duplicate of this bug. ***
Jens, do you still see this problem?
bz, do we still need this?
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.
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?
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)?
Yes! That change almost certainly fixed this bug.