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

181–190 of 212 posts

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

#181

Post by pomstazlesa »

kube-system wrote: post #159
mcronce wrote: post #148

Earlier quoted context omitted.

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

This is probably not the result of internationally dumbing down the message, but lazy error handling.

It's probably both. Since you want to obscure it from the end user, you can also afford to be lazy and have sloppy implementation.

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

#182

Post by WirelessGigabit »

kube-system wrote: post #159
mcronce wrote: post #148

Earlier quoted context omitted.

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

This is probably not the result of internationally dumbing down the message, but lazy error handling.

This is just a general try catch. Build happy path, get VC money and deploy. We'll fix it later.

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

#183

Post by bombcar »

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…

The very same users will drive their cars with the dashboard lit up like a Christmas tree.

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

#184

Post by bombcar »

zlg_codes wrote: post #176
sopooneo wrote: post #171

Earlier quoted context omitted.

My personal inclinations agree with yours, I think. I prefer as much detail as possible up front. Which is why I hate the vagueness of my dashboard's "check engine" light*. However, I bet automakers do that not just so the display is cheaper/simpler, but because most drivers are not interested in anything more detailed (or scary). * Which for me has almost always just meant some oil change "timer" was up, not even th…

I've thought about alternative dashboards as an option, that show rpm, piston firing stats, or other small details that, when looked at in aggregate, can diagnose a lot of consumer-serviceable issues.

Most modern cars you can get this by plugging a laptop into the OBD port.

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

#185

Post by tredre3 »

chii wrote: post #26
entuno wrote: 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.

> security by obscurity only stops casual bots

Casual bots is what 95% of website operators have to deal with, blocking them is still a win.

Same reason people move ssh ports around. Of course it doesn't add security if you're targeted, but it makes casual bruteforce bots go away.

Call that log hygiene if you really object to the security aspect.

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

#186

Post by zlg_codes »

bombcar wrote: post #184
zlg_codes wrote: post #176

Earlier quoted context omitted.

I've thought about alternative dashboards as an option, that show rpm, piston firing stats, or other small details that, when looked at in aggregate, can diagnose a lot of consumer-serviceable issues.

Most modern cars you can get this by plugging a laptop into the OBD port.

Hm. I might have to look into this when I get a newer car. Still 'rocking' a 00s Honda at the moment.

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

#187

Post by bombcar »

zlg_codes wrote: post #186
bombcar wrote: post #184

Earlier quoted context omitted.

Most modern cars you can get this by plugging a laptop into the OBD port.

Hm. I might have to look into this when I get a newer car. Still 'rocking' a 00s Honda at the moment.

Everything post ‘97 should have an OBD or OBD2 port which should connect to the default laptop adapters/software.

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

#188

Post by bawolff »

jeroenhd wrote: post #147
david422 wrote: post #128

Earlier quoted context omitted.

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.

400 is a client error. 500 is server error. A server error induced by a client action (e.g. triggering an unexpected exception) is still a server error.

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

#189

Post by starttoaster »

verall wrote: post #102
starttoaster wrote: post #78

Earlier quoted context omitted.

On the flip side, how difficult is it to open dev tools, flip to the network tab, and look at your status code return(s) as a power user? As a power user, it never struck me as a high vertical.

For me personally, it's quite difficult. My day job is C++ app and driver code for rather complex systems yet when I open browser dev tools my eyes glaze over. There is plenty of middle ground of people who are technical but are not web or browser developers.

I’m not a web or browser developer, the vertical isn’t quite as high as “you need to be working in the web space to understand it.”

There’s a lot to look at in there, but there’s some usual suspects tabs that people look at the majority of the time they have dev tools open. And conversely some tabs that you probably only use in the web dev scene. I’d highly recommend perusing the network and storage tabs, for things like status codes and cookies, respectively. As I mentioned, the vertical is nowhere near as high as you’re saying, you’ll figure it out if you look at it more.

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

#190

Post by starttoaster »

falcor84 wrote: post #120
thrashh wrote: post #94

Earlier quoted context omitted.

Why? Because a lot of regular people were tricked into running malicious bookmarklets.

So could we maybe have them not get any privileges by default, but still work?

No privileges by default is often at odds with the goal of having something work, at least out of the box.
Post reply on HN