2023-08-10
Browsers barely care what HTTP status code your web pages are served with
Back when I wrote an entry on issues around the HTTP status code for a web server's default front page, I said in passing that the HTTP status code mostly doesn't matter to browsers. More exactly, the status code for a web page mostly doesn't matter to people looking at web pages in a browser (this has come up before). This is well known in some circles and probably surprising in others.
Certain HTTP status codes cause web browsers to do specific things; there are the HTTP 3xx redirections, HTTP 401 Unauthorized, and some others. However, in general if you respond to a request for a web page with a HTTP 200, 4xx, or 5xx code outside of these specific ones and some HTML, almost all browsers will display the HTML to the user and not expose the actual HTTP status code to them in any obvious way. If the HTML says 'HTTP 500 internal failure', they'll assume one thing; if the HTML says 'welcome to the default server page', they'll assume another thing.
(I'm not sure there's any way to find the HTTP status code in a modern Firefox environment short of using web developer tools. It's not in places like 'Page Info' as far as I can see.)
This is not so true in other browser contexts. If a web page is trying to fetch CSS, JavaScript, or images as sub-resources, I believe that browsers will react very differently to a HTTP 200 response than to the exact same content with the exact same Content-Type but with a HTTP 4xx or 5xx status code; only the successful HTTP 200 response will work. Similarly if there's JavaScript running to fetch HTML chunks and stuff them into the page, it's likely to care (and not work) if you return the same HTML with a HTTP 404 instead of a HTTP 200.
It's a convention (and a useful one) that the HTML served for a web server's error pages will include the HTTP status code in the text (and often the <title> as well). But it's only a convention and it can be violated, both accidentally and deliberately (both in omitting the status code and listing the wrong one). If it is violated, you probably won't notice for a while (if ever).
PS: It turns out that our Django based web application doesn't actually list the HTTP status codes on its various custom error pages, although it does have appropriate text that says you've hit a nonexistent page or an internal error. I probably should at least add a footer saying '(This is a HTTP status 404 error)' (with the correct code for the specific error page).