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

Question

I have noticed that many http clients including Firefox and Chrome don't allow file downloads for http response codes with 4XX and 5XX. However, some clients allow these downloads, like curl and wget (with --content-on-error option).

Both Chrome and Firefox don't provide nice exception messages. Chrome fails with ERR_INVALID_RESPONSE. Firefox fails with File not found. As stated above for the curly and wget work for the same URL.

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.

I think for most cases a download for failing requests makes no sense, but for some cases it would be helpful. One good example where downloading a file even in the error case would be if there is a client that only communicates with the server using some 3rd party format. The client would have to download a generated file for the request. In the case of an error, the client should download a file containing the error description.

For example the RFC7231 states

Response messages with an error status code usually contain a payload that represents the error condition, such that it describes the error state and what next steps are suggested for resolving it.

---

The 4xx (Client Error) class of status code indicates that the client seems to have erred. Except when responding to a HEAD request, the server SHOULD send a representation containing an explanation of the error situation, and whether it is a temporary or permanent condition. These status codes are applicable to any request method. User agents SHOULD display any included representation to the user.

This doesn't forbid downloading in the case of an error.

---

Edit because of the first answer:

I don't think that this behavior is user friendly and I don't think that user friendliness is really the reason behind this. For example it would make way more sense to show the error code and error message (provided in the header) to the user. Or least indicate the error with an error message like "cannot download the file, because the server responded with an error". There might be servers that can only respond with XML or any other random file format.

What bugs me the most is that both browsers respond with different but arbitrary errors that don't hint any information about the underlying issue.

It might be that this is an undocumented edge case and both Chrome and Firefox just fall back to a default error, but this seems unlikely, especially because this is an edge case that has a special flag in wget.

4XX: Why would you assume a file download if your client did something wrong?

If we assume that an API has an endpoint that replies with a certain file format, it is fair to assume that also the error message including a hint what the client did wrong is provided in that format. So the file can help to fix the client error.

Answer 1

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. :)

Answer 2

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.

Answer 3

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 longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue."

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

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.