Live data from Hacker News

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

utcc.utoronto.ca

21–30 of 212 posts

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

#21
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?

Why not use extensions for this like (quickly searching firefox add-ons): https://addons.mozilla.org/de/firefox/addon/http-status-code... ?

I think we just have fight for poweruser options to be available via APIs and support the add-on ecosystem.

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

#22
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?

This sounds like inconsequential quibbling over terminology. There's nothing stopping a browser power user from opening up dev tools to look at error codes.

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

#24

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…

> I will just leave you with the most adorable 404 page anyone has ever seen: https://diopitt.org/pray/amen

In the context of your comment, I was amused by how my own ad-blocker failed to properly show the (image on the) 404 page, since it is loaded from a different domain :D

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

#25
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?

When did we stop building software for the "Power User" persona?

I think the change was very simple - we stopped bothering with middleground. "Power Users" were treated like "users, but a bit more", so we had 'users', 'power users', and 'developers'. All that happened is that we just accepted that power user can have the same access to tools as developers.

We didn't stop giving power users extra power. We gave power users more power.

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

#26
post #9

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

security by obscurity only stops casual bots, and any determined bot would easily be able to ignore the status code and inspect the contents to get at what they wanted anyway.

And you run the risk of having a transparent proxy fail on your real users doing this too. It's why nobody does it.

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

#27
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?

At first we agreed; having a future with primarily "Power Users" in mind would be pretty empowering. Then,

At second; it would likely mean many folks lacking in other skills, unbalancing what little we have in the society of work.

At third: include all the error detail you like, simply put it behind a "click here for more details" side door.

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

#28
> 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 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).

A malicious server can just as easily send the wrong status code, as well as listing the wrong status code in the accompanying html - so if the browser did show the real status code more prominently to the user, that wouldn't actually help in such a case, or would it?

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

#29
This is the web equivalent of “no user serviceable parts inside”. Watch Joe Average use a computer. If he’s shown an error either he recoils as if he’s physically broken it (or the website) or repeatedly just performs the same action again and again like a chicken pecking at a corn dispenser, or finally mashes the keyboard with his fists and slams the laptop shut in frustration.

The days of a bespectacled web user, thoughtfully musing over an error message, while fiddling with a self-propelling pencil, sat at a Sun/SGI/HP/IBM X11 session are long gone.

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

#30
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…

There must be a middle ground between "Something went wrong, please try again later :)" and "TypeError: Cannot read property 'submit' of null" when performing an action.

I sometimes hear the "best of both worlds" is something like logging all errors while showing optimistic errors to the users on frontend. This is somewhat fine for errors that happen on the backend, but catching browser errors is tricky because extensions can throw errors. On top of that a user might not be comfortable with you collecting errors that happen in their browser.

Post reply on HN