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

61–70 of 212 posts

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

#61

Post by Hamuko »

yonatan8070 wrote: post #54
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…

Yet Windows still frequently shows Error "0x0000F001" without elaborating at all

Something happened

Something happened

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

#62

Post by rhaway84773 »

bmacho wrote: post #42
Raed667 wrote: post #20

Earlier quoted context omitted.

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.

Create a chrome shortcut that auto opens dev tools for you. You can replace your regular chrome with this instead.

https://developer.chrome.com/docs/devtools/open/#auto

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

#63

Post by richardwhiuk »

CapsAdmin wrote: post #30
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…

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

"Something went wrong, please try again later :)" is cheap (try { } catch () { print "Something went wrong" })

"TypeError: Cannot read property 'submit' of null" is cheap (just render whatever error you get).

Anything else is expensive, and probably doesn't gain you anything.

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

#64

Post by somat »

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?

Related: the boot scroll. most of the time the scroll of boot messages is harmless and when the system fails to boot it is very very useful to see where. yet the design types hated it. and now no desktop orientated OS shows a boot scroll, opting for a near useless spinner instead.

Opinion: I quite like the scroll, I think it comforting to see what the machine is doing. I think this is why sim city put a fake one in their loader(reticulating splines anyone). I wonder if the sim city messages tied into actual load events and could be used by the programmers to debug the loader. I think the later ones were random, but 2000 might of had an order to it.

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

#65

Post by CapsAdmin »

troupo wrote: post #38
CapsAdmin wrote: post #33

Earlier quoted context omitted.

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

Sometimes when I put my power user hat on I find myself thinking that the software I'm currently using is not meant for power users and instead I need to look for the alternatives. Now it's not just a few clicks away but I need to install some new type of software.

So the options for power users are still here, but they just aren't front and center as they used to as you said. This reminds me a little bit of the discussion around the iphone not being customizable and the response being that you have the option to just get an android phone instead.

At some point in the spectrum here one must become lazy when they can't be bothered to click on a few things or find an alternate product, and you become entitled when you demand power user features to become front and center when the vast majority won't ever need to use the features.

I've always had the opinion that it's possible to have a middle ground. User friendly defaults, the ability to dig deeper and the ability to make advanced features more readily accessible. It's not easy though, picking one or the other is definitely a lot easier.

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

#66

Post by account42 »

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…

Browsers used to display an icon and beveled borders to indicate broken images. Not sure when they stopped but I wish they hadn't.

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

#67

Post by pseudalopex »

imperialdrive wrote: post #27
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?

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.

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

What?

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

#68

Post by pseudalopex »

reportgunner wrote: post #44
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? The moment they(i mean we) started blocking ads I think.

Much software is not ad supported web sites.

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

#69

Post by theginger »

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…

Letting an uncaught exception error reach the user is generally bad. It risks exposing secrets / confidential information to the user and any returned client side secrets risk getting into intermediary caches. The biggest risk is the user input being returned in the response creating an XSS (cross site scripting) risk. This is a very common source of reflected XSS vulnerabilities. You should always catch exceptions like this so you can at the very least sanitize them for XSS. This is already built in to some frameworks. If you are using something that doesn't you need to do it yourself and it's probably easier to just strip it all in production, you just need to make sure you are still setting an appropriate status code.

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

#70

Post by AniseAbyss »

troupo wrote: post #35
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…

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

[dead]
Post reply on HN