1890028 - "File not found" error displayed when server returns HTTP 500 and unusual content-type

Status: NEW

(Core :: Networking: HTTP, defect, P2)

Description

[Ted Campbell [:tcampbell]]

Attachment: test.py

When an (arguably misconfigured) sends a 500 error with an unusual content-type like "application/octet-stream" the browser reports "File not found" error instead of something more reasonable about server error or malformed server response.

Comment 1

[Ted Campbell [:tcampbell]]

Attachment: error_message.png

Comment 2

[Valentin Gosu [:valentin] (he/him) {{ FYI: OOO 14 June - 4 August }}]

It seems this error is coming from here
We're trying to display the content, but because it has a content type we don't have a stream converter for, we return NS_ERROR_FILE_NOT_FOUND.
I think adding a new error code and a specific error page message would be very helpful, especially if it includes the status code.

Comment 3

[BugBot [:suhaib / :marco/ :calixte]]

:nika, since you are the author of the regressor, bug 1875248, could you take a look?

For more information, please visit BugBot documentation.

Comment 4

[Nika Layzell [:nika] (ni? for response)]

IIRC in the "regressor" (bug 1875248), I actually improved the behaviour a bit here. Before that change, we would instead have put the browser into a slightly broken state, where you continue to look at a partially unloaded page, and no error page is displayed. The situation here effectively is that the load's content-type is one which would normally be downloaded, however the response had a failed HTTP status. This is handled by showing an NS_ERROR_FILE_NOT_FOUND error page rather than downloading a potentially malformed document.

This error type is a legacy thing, and should probably match the behaviour from ~2018-era Firefox before the DocumentChannel navigation changes. The actual decision about which error is returned here is quite old, and appears to date back to bug 312727 comment 13.

I could see an argument that this behaviour could be better than it is, but I don't think there's an obvious behaviour to have here rather than returning this error. Perhaps it should be a bit more responsive to the specific error code returned by the server or something like that?

Comment 5

[Valentin Gosu [:valentin] (he/him) {{ FYI: OOO 14 June - 4 August }}]

I think it would be good to use a different error code instead, and have about:neterror say something to the tune of This resource could not be opened/downloaded because the server returned an error code - HTTP Status = 5XX

Comment 6

[:Gijs (he/him; back Aug 12)]

Ted, can you say more about how you encountered this? Obviously the minimal testcase is useful to reproduce but it's less informative in terms of "what does 'good' behaviour look like", divorced from its context. :-)

I'm also curious what other browsers do in this situation (in addition to the pre-2018 gecko behaviour, for that matter).

Comment 7

[Ted Campbell [:tcampbell]]

Attachment: Error Messages - Chrome, Edge, Firefox

Comment 8

[Ted Campbell [:tcampbell]]

The context was connecting to a server using Nginx OpenResty that was returning 500 in certain scripted cases, but the nginx default_type application/octet-stream; was set elsewhere in the config. From a web-developer perspective, I was thrown off by the bad error message and went off trying to debug the wrong thing.

I think the text around "files" is the most misleading part to me. What Chrome-like browsers do seems reasonable enough.

Comment 9

[Valentin Gosu [:valentin] (he/him) {{ FYI: OOO 14 June - 4 August }}]

Steps to fix:

• Add a new error code to ErrorList.pty and return error code here
• Add different branch here to set the error to error = "serverError";
• Add handling for new error to aboutNetError to display the error.

Comment 10

[Donal Meehan [:dmeehan]]

(In reply to Valentin Gosu [:valentin] (he/him) from comment #9)

Steps to fix:

• Add a new error code to ErrorList.pty and return error code here
• Add different branch here to set the error to error = "serverError";
• Add handling for new error to aboutNetError to display the error.

Setting Fx126 to wontfix, but wondering about Fx127?
Is there something safe in the meantime that can ship with Fx127, or should we wontfix that also and this will come in a later release?

Comment 11

[Valentin Gosu [:valentin] (he/him) {{ FYI: OOO 14 June - 4 August }}]

Not sure we can fix and uplift in time for 127.

Comment 12

[Sean Kim]

Attachment: Bug 1890028 - Display Server Error message when server returns HTTP 500 and unusual content-type r=kershaw