Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

utcc.utoronto.ca

Post reply on HN
Print view View original

31–40 of 212 posts

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

#31

Post by falcor84 »

unmole wrote: post #22
falcor84 wrote: post #19

Earlier quoted context omitted.

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.

It's not inconsequential in my mind because as a power user I don't a-priori care about the site enough to have a reason to open the dev tools. What I'm missing is the indication that there even is a problem of some sort, and that if I wanted to see the problem details, I could open the dev tools.

In other words, as a power user, I want to know if the site has a "You problem", and the only explanation I fully accept for why the modern web doesn't notify users about website errors is that it allows companies to save on QA costs.

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

#32

Post by fruitreunion1 »

unmole wrote: post #22
falcor84 wrote: post #19

Earlier quoted context omitted.

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.

Their point I think is that often (to varying degrees), 'power user' things are less convenient to do or behind configuration options or menus and so on nowadays.

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

#33

Post by CapsAdmin »

onion2k wrote: post #25
falcor84 wrote: post #19

Earlier quoted context omitted.

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…

Interesting perspective, you could flip the parent question and ask "when did power users become so lazy?"

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

#34

Post by namtab00 »

mjan22640 wrote: post #15
NoZebra120vClip wrote: post #2

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?

not OP

pihole as cache, with the router as its upstream, with NextDNS as the router's dns server

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

#35

Post by troupo »

onion2k wrote: post #25
falcor84 wrote: post #19

Earlier quoted context omitted.

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…

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

I don't think we did. The trend in the past few years is to dumb down all tools, especially UI tools, to the lowest common denominator.

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

#36

Post by daveidol »

NoZebra120vClip wrote: post #2

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…

> Because all my devices use the same configuration, and it's non-trivial to disable it

This is exactly why I do not use a DNS-based ad blocking solution (it’s trivial to disable uBlock Origin and refresh if something feels broken).

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

#37

Post by bawolff »

onion2k wrote: 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…

Tbf, 500 is the appropriate error message for user has broken the server.

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

#38

Post by troupo »

CapsAdmin wrote: post #33
onion2k wrote: post #25

Earlier quoted context omitted.

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…

Interesting perspective, you could flip the parent question and ask "when did power users become so lazy?"

Power users haven't become lazy. The middle ground for power users has disappeared. Now it's a split between "everything is so dumbed down and hidden behind fifteen layers of clicks" and "setting up and caring for your system is a second job in addition to your regular job".

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

#40

Post by jiggawatts »

The author is wrong, browser behaviour does change significantly in one major way: errors are not cached.

Or much more importantly, errors incorrectly returned with 200/OK success codes are cached, semi-permanently breaking your site.

If you've get helpdesk staff telling customers to "clear their browser cache", this is one common reason why this "works" as a fix.

Please, I beg you: stop being "nice". Stop catching exceptions and dropping them on the floor! Let them bubble up to the web framework pipeline so that an error code is sent.

Your CDN will thank you. Browser caches will thank you. Corporate proxy servers will thank you. Application monitoring tools will thank you. Load balancers will thank you.

I kid, I kid. None of those will send you thanks in an email. Instead, they'll work tirelessly in silence to deliver your application as intended, instead of holding on to transient errors for days on end and upsetting your users.

Post reply on HN