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

141–150 of 212 posts

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

#141

Post by vel0city »

thrashh wrote: post #105
theginger wrote: post #69

Earlier quoted context omitted.

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

I think it’s cute you think most developers let exceptions rise. Most developers I notice just catch the error right away and make the function return something non-sensible like a 0 for a string value function. Slightly better developers just let the exceptions bubble. The rare breed looks at what exceptions are being thrown, decides which ones to handle at which stack level, and repackages them as needed when the e…

Gotta love these though:

  catch {};

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

#142

Post by matt-attack »

isodnhionio wrote: post #111
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. Hiding them away in devtools is a very good thing. I can't say I agree. That would be a good idea in a world where users never encountered errors in normal circumstances, but in fact computers don't work very well and users encounter errors on a regular basis. Using computers is a skill. It takes study. You can either pretend that it doesn't, giving user…

It seems you're advocating for error messages which I think many would agree with, but the comment you're responding to was proposing that error codes have no place being shown to users. I would generally agree with hiding codes. They're generally meaningless and really intended for devs or automation.

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

#143

Post by mrweasel »

22c wrote: post #23

Servers barely care what HTTP status code their users are served with. 500 / 503 seems to fit any and every error these days, or the classic 200 OK for a page not found.

Or you can take the route that a former client took: Return 200 OK http status code and just print "500" in the response body. Took me a few minutes to figure out why the monitoring kept insisting that everything was OK when my browser kept showing me "500".

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

#144

Post by skissane »

isodnhionio wrote: post #130
david422 wrote: post #127

Earlier quoted context omitted.

I mean ... cars have had different error lights for decades. Doesn't seem like that much of a stretch that people would be able to use a little critical thinking when looking at computer error messages too.

In my experience, people hate when cars just flash a "check engine" light. It is impossible to tell the difference between "probably OK but get it looked at", "might leave you stranded", and "might literally explode". Cars show error codes every few months or years and there's nothing the average driver can do to fix them. Computers show errors on a daily basis and most of them are trivially fixable.

> In my experience, people hate when cars just flash a "check engine" light. It is impossible to tell the difference between "probably OK but get it looked at", "might leave you stranded", and "might literally explode".

This is why I bought one of those OBD reader things so I can have more of an idea of what is actually going on. Not that I really understand anything that it says, I’m pretty clueless when it comes to car stuff, but it sure makes me feel better

The only time I ever got a check engine warning, the problem was obvious from the physical symptoms: cylinder misfiring. Well, I didn’t know what that was when it started happening, but now I do. Drove it to the mechanic and they replaced the spark plugs

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

#145

Post by recursive »

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.

You also have to hit the reload button.

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

#146

Post by recursive »

notRobot wrote: post #86
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…

For anyone interested, here's a bookmarklet to view the current page's HTTP status code (makes a new request): javascript:(function()%7Bjavascript%3A(function()%20%7B%0A%20%20var%20xhr%20%3D%20new%20XMLHttpRequest()%3B%0A%20%20xhr.onreadystatechange%20%3D%20function()%20%7B%0A%20%20%20%20if%20(xhr.readyState%20%3D%3D%3D%204)%20%7B%0A%20%20%20%20%20%20alert('HTTP%20Status%20Code%3A%20'%20%2B%20xhr.status)%3B%0A%20%20%…

This assumes a GET.

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

#147

Post by jeroenhd »

david422 wrote: post #128
jeroenhd wrote: post #116

Earlier quoted context omitted.

5xx means the server messed up, if the user should've done something different you'd see a 4xx error. A good web server validates the user input, throws a 4xx error if the input is bad for the current state, and if something still goes wrong (which is a server bug) the 5xx range becomes appropriate.

That's what he just said though. User breaks the server is a 500. Server prevents the user from breaking the server is a 400.

But a 500 isn't the user breaking the server, it's the server being broken before the user ever came in.

Users and client software cannot (or rather, should never) be held responsible for 500 error codes, which "user breaks the server" implies.

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

#148

Post by mcronce »

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?

My current pet example for the trend of hiding more and more details from users is an issue I recently had with Doordash.

I was trying to place an order, and it kept failing with a red banner stating "something went wrong" (I'm paraphrasing as I don't recall the exact verbage, but it was one of those completely worthless error messages)

Pop open dev tools ... the server is returning something about a graphql error.

Support had no idea what was wrong.

The problem ended up being that my saved credit card had expired. For fuck's sake, that is a user-actionable error; tell me what the problem is. At least tell me it was a payment problem, since that's probably all the payment processor told you.

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

#149

Post by CapsAdmin »

delecti wrote: post #110
CapsAdmin wrote: post #30

Earlier quoted context omitted.

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…

Those are two ends of the spectrum of how to handle unknown errors, but ignore the other axis: known errors. The UI displaying a red text field saying "field whatever is required to continue" is just as much an error message, but it's clearly actionable. There are lots of reasonably actionable error messages in all varieties of UIs for expected error cases. I don't know that there's a lot of useful middle ground betw…

Yeah this problem is a little more complicated than what I mentioned. By all means map known errors, but does the fallback really need to be "something went wrong?"

It was a bit of a rhetorical statement (or at least in my mind it was). Like how about "Something went wrong (see details)" or something to that effect?

In my work experience some people are really dogmatic about the idea of not showing any sort of error messages to users whatsoever.

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

#150

Post by adamsb6 »

isodnhionio wrote: post #111
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. Hiding them away in devtools is a very good thing. I can't say I agree. That would be a good idea in a world where users never encountered errors in normal circumstances, but in fact computers don't work very well and users encounter errors on a regular basis. Using computers is a skill. It takes study. You can either pretend that it doesn't, giving user…

Even more terrifying for the uninitiated back in the day: fatal error
Post reply on HN