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

41–50 of 212 posts

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

#41

Post by kaoD »

jiggawatts wrote: post #40

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

Also: search engines. I spent a good chunk of a month fixing an app initially developed with this mindset. Immense value delivered just by making things work as they should've from the beginning.

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

#42

Post by bmacho »

Raed667 wrote: post #20
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?

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

It is not working in Firefox or in Edge though, only if you already had your dev tools open before you navigated to the website.

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

#43

Post by kaoD »

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…

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

In what way? Do you mean not feasible or just lazily coded?

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

#44

Post by reportgunner »

falcor84 wrote: post #19
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…

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?

The moment they(i mean we) started blocking ads I think.

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

#45

Post by funcDropShadow »

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.

No, most software today is designed for the use case that you have never seen the software before. That is implicitly enforced by the way most companies do A/B testing. The experiments show a new part of the UI to an unsuspecting user without any upfront knowledge that they are part of an experiment. Therefore the variant that has the lowest hurdle for the most common case of the most common user is optimized. So it is basically ignored that people tend to learn how to use their tools.

Learning to learn your tools is even made harder by constantly changing UIs. Reading documentation, following tutorial, watching introduction videos is basically useless for a software that will change whenever a product manager needs to complete an increment for his KPIs.

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

#46

Post by justsomehnguy »

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…

> Users have no business seeing error codes

Ah, yes, I love remote troubleshooting.

"What does the site says?"

"Hell I know but there are funny badgers singing about mushrooms!"

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

#47

Post by Am4TIfIsER0ppos »

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…

> users have no business seeing anything

People like you are the reason users cannot work a file system, download an image, or even read a short text message. You retard the users' progress.

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

#48

Post by rvba »

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…

> Users have no business seeing error codes. Those are for devs.

This is an Anti-pattern called mushroom management (keeping users in the dark).

Not telling users what went wrong is just plain wrong. Breaking the termomether to hide fever.

When you get an error message you can at least google it, or make a ticket.

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

#49

Post by theginger »

Just because they rendered the text doesn't mean they've ignored the status code. There can be a lot of other stuff going on behind the scenes that are happening differently due to this code. A 503 with a Retry-After header is a good example, although it has limited browser support, but in theory it will reload the page after the timeout. There are different caching/storing rules with different status codes, they may also disable certain features, eg if you have been loading a page with an error you might find the auto complete feature in the URL bar doesn't work. I often find this is really annoying when building something new and haven't got it quite working, I keep needing the full URL, where as if it had just once given me a 200 I could just type a few letters and it would come up, but it probably far more useful that auto complete doesn't get polluted with mistyped URLs and broken websites.

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

#50

Post by mekoka »

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…

Right. To which category belongs the user that is curious enough to open "Page Info", but destabilized when they see a status code there?
Post reply on HN