426961 - Misleading error message "File Not Found" when an HTTP server returns 500 and an unknown Content-Type

Status: NEW

(Core :: DOM: Navigation, defect)

Description

[Jesse Ruderman]

Steps to reproduce:
1. Load http://members.ii.net/~syskin/500.php in a trunk build of Firefox.

Result:

File Not Found
Firefox can't find the file at http://members.ii.net/~syskin/500.php.
    * Could the item have been renamed, removed, or relocated?
    * Is there a spelling, capitalization, or other typographical error in the address?
    * Do you have sufficient access permissions to the requested item?

Expected:

"Unexpected response from server", perhaps?

Comment 1

[Andrew Furey]

This seems to happen with any sort of HTTP 500 code (which previously showed as "internal server error" which makes much more sense to me)... At this rate I'll have to use IE7 for my CGI testing :(

Comment 2

[Lapo Luchini]

HTTP 500 is much different from 404, one means "this address is ok, except is currently giving an error", telling the user that it has probably been relocated or removed is very misleading… they might delete their bookmark to a still very valid page, thinking it gone for good.

Comment 3

[Boris Zbarsky [:bzbarsky]]

So the key ingredient here is that the response be a 4xx or 5xx response and have a type that we can't handle internally.  In that case, we fall back to NS_ERROR_FILE_NOT_FOUND; see bug 312727.

We could do different fallback for different status codes if someone really cares; I'm happy to review patches.

Comment 5

[Atul Jangra [:atuljangra]]

Any work on this one?

Comment 6

[replicator.snail]

The original example URL is dead. Here's one that exhibits the problem currently: http://www.ssa.gov/framework/images/icons/png/.

Interestingly, Chromium seems to have the same issue.

I asked about this on Stack Exchange: http://superuser.com/questions/719626/what-does-file-not-found-mean-on-a-web-page.

Comment 7

[Boris Zbarsky [:bzbarsky]]

Docshell gets an OnStopRequest for the pageload, checks the loadgroup's GetStatus, and gets ... NS_ERROR_FILE_NOT_FOUND.  Which it then dutifully reports.

Why's the loadgroup claiming NS_ERROR_FILE_NOT_FOUND?  That's happening because mozilla::net::nsHttpChannel::OnStopRequest is called with the "status" arg set to NS_ERROR_FILE_NOT_FOUND.  

And that happens because in nsInputStreamPump::OnStateStart the mListener->OnStartRequest call returns NS_ERROR_FILE_NOT_FOUND.

Where did _that_ come from?  Well, when we got an OnStartRequest from necko over in uriloader, it came with a Content-Type of "magnus-internal/directory".  We tried to send that to some listener, but none of them recognized it, so then (still over nsDocumentOpenInfo::DispatchContent) we checked GetRequestSucceeded() before handing it over to a helper app, discovered it did not, and returned NS_ERROR_FILE_NOT_FOUND.

That dates back to bug 312727.  Like I said then (and had forgotten by now, apparently; I plead that it's been a while), we could make up another error code for this case, but it's rare enough that it's not clear that it's worth it.

Anyway, clearly not DOM.

Comment 8

[u580221]

This also happens on Linux. It's not limited to Mac OS X at all. Seeing this in Firefox 63.0a1 (2018-08-07) (64-bit) on GNU/Linux Fedora 28.