Live data from Hacker News

Browsers barely care what HTTP status code your web pages are served with

utcc.utoronto.ca

11–20 of 212 posts

Re: Browsers barely care what HTTP status code your web pages are served with

#11
I think, this is a general design feature. The specs explicitly allow a possible document body. If the status doesn't affect the process of retrieving the requested document (like a redirect), a client is free and even expected to display the document body.

Having said that, if the status code is in the 4xx client error range, I'd wish that any document.title would be strictly ignored and browsers would always display the status code (together with the human readable error title) as the page title.

Re: Browsers barely care what HTTP status code your web pages are served with

#12

Does 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.

I hope that image has good alt text...

Re: Browsers barely care what HTTP status code your web pages are served with

#13

The 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…

You'd like to think that the owners of those sites would fix them. A site shouldn't just not work if it can't access a certain JavaScript file - it should at least warn you of the problem.

Re: Browsers barely care what HTTP status code your web pages are served with

#14
(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.)

I'm old enough to remember times before browsers showed 'friendly' error messages, and a 500 response from a server would display a '500 Server Error' message to the user. Users hated it. They'd panic and think they'd broken the website somehow. It was horrible from a support perspective, and if the user was new to the web it sometimes made them very anxious about using the web in the future.

Users have no business seeing error codes. Those are for devs. Hiding them away in devtools is a very good thing.

Re: Browsers barely care what HTTP status code your web pages are served with

#15

The 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…

What dns adblock do you use?

Re: Browsers barely care what HTTP status code your web pages are served with

#16

The 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…

> Unless a blocked domain corresponds to the front page I visit in a URL, the unavailable resource represents a silent failure

Is this not intended behavior? Were you not expecting ads to be silently removed?

Re: Browsers barely care what HTTP status code your web pages are served with

#18
post #16

The 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…

> Unless a blocked domain corresponds to the front page I visit in a URL, the unavailable resource represents a silent failure Is this not intended behavior? Were you not expecting ads to be silently removed?

From the user's point of view, yes, that is intended behavior. But the browser can't know that, all it sees is a dropped connection. For all it knows, there could be an actual issue with the network.

But unless you open the dev tools' network tab, you don't know about that request failing.

Re: Browsers barely care what HTTP status code your web pages are served with

#19
post #14

(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.) I'm old enough to remember times before browsers showed 'friendly' error messages, and a 500 response from a server would display a '500 Server Error' message to the user. Users hated it. They'd panic and think they'd broken the websit…

When did we stop building software for the "Power User" persona? I don't disagree that there are some (many?) people who start screaming and running in circles when they see an error code, but not every user is like that. You don't have to be a dev to care any the distinction between a system doing its job and silently failing. Why not have some indication that there's smoke coming out from the engine?

Re: Browsers barely care what HTTP status code your web pages are served with

#20
post #14

(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.) I'm old enough to remember times before browsers showed 'friendly' error messages, and a 500 response from a server would display a '500 Server Error' message to the user. Users hated it. They'd panic and think they'd broken the websit…

When did we stop building software for the "Power User" persona? I don't disagree that there are some (many?) people who start screaming and running in circles when they see an error code, but not every user is like that. You don't have to be a dev to care any the distinction between a system doing its job and silently failing. Why not have some indication that there's smoke coming out from the engine?

Opening the dev tools and looking at the network tab is easy enough for power users.
Post reply on HN