Why isn't it possible to download a file for status code 4XX and 5XX

I'm not aware of any specification for that topic.The behavior should be as user friendly as possible.

4XX:Why would you assume a file download if your client did something wrong? Furthermore, the client software could not differ between the case of wrong usage(e.g. invalid url) and handling a file download.

5xx:As you stated most api provide error information, but you could also not differ the case of downloading and for example an internal error providing the file.

You can use such behavior with wget and curl as you mentioned, but its not user friendly nor practical for using such an API programmatically.

The above info in mind, Chrome and firefox just try to be user friendly.

I hope I could somehow answer your question or challenge the idea behind it. :)

Looking at chromium handle download and not 2xx we see:

  // The response code indicates that this is an error page, but we don't  // know how to display the content.  We follow Firefox here and show our  // own error page instead of intercepting the request as a stream or a  // download.

So Chrome followed Firefox, and both are entirely consistent with the RFCs, the browser knows this payload is unidentified data relating to an error condition, so saving it as the file in question is not an option. Since it is being downloaded, presumably the browser can't display the payload, but in either case has been instructed not to, so displaying it in the error context is not a safe option. Since it is an error there is also a high likelihood that the sender has combined a partial response with an error code meaning that the payload contents may be an incomplete or corrupt representation of data from a 2xx response/etc.

If you look back at wget, --content-on-error is a specific option because it is the wrong thing to do as a general browser. A client side that works with the payload type could examine the errors when it is directly interacting with a server and wget is only providing options to help you debug such an interaction. A normal browser has less features to help emulate other clients for debugging than a text CLI, since a text CLI exists primarily to emulate some other client while debugging.

I was wondering if there is a specification that defines the correct behavior in this case? Are there good reasons why the request can't be processed by Chrome and Firefox? Also, it seems strange that they don't provide proper feedback.

There is no such specification for this, but the chromium project member finds this as a trivial issue and unlikely to be fixed in near future. Instead of they fixing in the chromium they suggest that it should be fixed on the server by sending proper HTTP status.

Response from Chromium Project Member: "This issue has been Available for over a year. If it's no longerimportant or seems unlikely to be fixed, please consider closing itout. If it is important, please re-triage the issue."

Sorry for the inconvenience if the bug really should have been left asAvailable.

You can check more details here Issue 479265

What's happening beneath the surface?

I further checked the source code of the chromium to find what actually happening and found that for any non 200 status for downloads, they are simply throwing ERR_INVALID_RESPONSE (Invalid Server Response) error.

To cut a long story short, you have to live with this behaviour of the browser, it is not going to be improved.