Browsers barely care what HTTP status code your web pages are served with
1–10 of 212 posts
Re: Browsers barely care what HTTP status code your web pages are served with
#2The web today is full of silent failures. I've noticed this all the time at work and in my personal business. If loading some resource runs into trouble, it's simply not feasible for the Node.js or React or PHP to surface an error to the user.
Chris says that the loading of sub-resources is a different matter. Well, the most common silent failure I have is not due to status codes per se, but because of my DNS-based adblocker, many sub-resources fail to load (GET or POST) with a network error (TCP RST). Unless a blocked domain corresponds to the front page I visit in a URL, the unavailable resource represents a silent failure, and I have foolishly contacted Support desks multiple times because my own use of the adblocker caused a silent failure that was difficult to diagnose.
In fact, I now have no way of knowing what web apps are like without an adblocker. Because all my devices use the same configuration, and it's non-trivial to disable it, I simply don't know what I am missing. Indeed, in the case of one web app which I've used as a PWA, it was simply missing features that I knew should have been there, and whitelisting enough domain names caused those features to re-appear.
I will just leave you with the most adorable 404 page anyone has ever seen: https://diopitt.org/pray/amen
Re: Browsers barely care what HTTP status code your web pages are served with
#3Does anyone still remember the days when a certain browser would ignore what the server sent with a 404 page unless it was larger than 512 bytes? Yeah, I'm happy with the browser just showing what I send it without trying to second guess the content.
Re: Browsers barely care what HTTP status code your web pages are served with
#4To me, none of this is surprising or undesirable - ie the browsers are doing the right thing. Content is there to be rendered, not hidden. Status codes are not there for the average end user.
Re: Browsers barely care what HTTP status code your web pages are served with
#5Does anyone still remember the days when a certain browser would ignore what the server sent with a 404 page unless it was larger than 512 bytes? Yeah, I'm happy with the browser just showing what I send it without trying to second guess the content.
Oh yeah, I still have a 404 page that's padded with comments because its only contents are a title and an image.
Re: Browsers barely care what HTTP status code your web pages are served with
#6This feels surprising for a minute until comes to mind all the little things that would be broken if browsers didn't behave that way.
Custom 404 pages to give the user a friendly explaination and further directions, 500 pages with the exception stack trace in our frameworks to debug the errors etc.
A status different from 200 rarely means there's nothing that could be displayed to the user.
Re: Browsers barely care what HTTP status code your web pages are served with
#7This feels surprising for a minute until comes to mind all the little things that would be broken if browsers didn't behave that way. Custom 404 pages to give the user a friendly explaination and further directions, 500 pages with the exception stack trace in our frameworks to debug the errors etc. A status different from 200 rarely means there's nothing that could be displayed to the user.
I agree. The way I see it is that browser is more of an HTTP response viewer than a REST client.
Re: Browsers barely care what HTTP status code your web pages are served with
#8Does anyone still remember the days when a certain browser would ignore what the server sent with a 404 page unless it was larger than 512 bytes? Yeah, I'm happy with the browser just showing what I send it without trying to second guess the content.
Do you remember when the AskBar would intercept 404 pages and display suggestions for pages you might really be looking for, “just to help you”?
And then Oracle shipped the AskBar into the Java installers.
Re: Browsers barely care what HTTP status code your web pages are served with
#9I remember a talk years ago where someone had written an Nginx plugin that returned a random status code (from a list) for every request.
Normal users would never notice and could browse the site fine - but bots (and particularly vulnerability scanning tools) couldn't cope with it and would show all kinds of weird results and false positives/negatives.
Re: Browsers barely care what HTTP status code your web pages are served with
#10This is the cause of a split in failure situations.
Failures fall into two often very distinct cases:
1. Failures the end-user is able to understand and in some circumstandes to fix themselves. Examples: (HTML) page not found, no connection, etc.
2. Failures the end-user is in no case able to fix; it's up to the programmer. Examples: Server misconfigured, missing media files on server, etc.
It never makes sense to display the full error messages in case 2. It suffices to hide the error and perhaps make it available in DevTools. Often a good way is: give a generic message, and because some failures are transient, tell the user to retry. Also it can make sense to add an error number so that the end-user can give support the error number.
So it is useful to let the browser be lenient with HTTP status codes except in some specific cases which the article does mention (HTTP status code 500 for JavaScript files, for example).