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

201–210 of 212 posts

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

#201

Post by janderland »

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…

Just a reminder that you don’t need to be patronizing to get your point across. Calling someone “cute” is a bit much.

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

#202

Post by lcnPylGDnU4H9OF »

dredmorbius wrote: post #193
lcnPylGDnU4H9OF wrote: post #140

Earlier quoted context omitted.

The first one is a 404. I love the irony of there being an error condition in this case of a missing redirect. https://deirdre.net/2014/programming-sucks-why-i-quit/

I was being lazy and had copied the URL from an earlier comment of mine mentioning it. The Internet Archive has a copy as well: https://web.archive.org/web/20200922230737/https://deirdre.n... >

Even their blog has such dead links. I just happened to notice that other URLs included the year, so I tracked that one down to see if that’s all what was needed.

Of course, forgetting about that little backwards compatibility is easy, especially considering it’s a personal blog and they likely have other personal things to worry about. I was just amused by the irony in context. I otherwise appreciated the read. :)

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

#203

Post by rcxdude »

gbalduzzi wrote: post #90
Am4TIfIsER0ppos wrote: post #47

Earlier quoted context omitted.

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

If a user is using your web application normally and ends up with an error, it is an application error. Be it a 401, 403, validation error, 500, 429, whatever, it is not an actual user fault but it is a problem within the application. Once you have this realization, what's the advantage of showing the proper error code to the user? Whatever it is, it's not in his power to fix it

Again, you are underestimating users. They will work around errors and can use some quite hideously broken systems to get what they need done, without any support at all sometimes. Hiding error messages just makes that a much more frustrating process. (put another way, the user probably can't fix the error occurring if they just do the exact same thing again, but they can often find another way to do what they want without triggering the error, and for this it helps to know what the error actually is)

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

#204

Post by notRobot »

mike503 wrote: post #195
recursive wrote: post #146

Earlier quoted context omitted.

This assumes a GET.

Also firing a second request would break restful behavior and could wind up really messing stuff up worse. Maybe it places an order twice? Who knows. Not a good idea.

If reloading a page (which is what this is identical to) breaks your website, that's not on the user.

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

#205

Post by dredmorbius »

lcnPylGDnU4H9OF wrote: post #202
dredmorbius wrote: post #193

Earlier quoted context omitted.

I was being lazy and had copied the URL from an earlier comment of mine mentioning it. The Internet Archive has a copy as well: https://web.archive.org/web/20200922230737/https://deirdre.n... >

Even their blog has such dead links. I just happened to notice that other URLs included the year, so I tracked that one down to see if that’s all what was needed. Of course, forgetting about that little backwards compatibility is easy, especially considering it’s a personal blog and they likely have other personal things to worry about. I was just amused by the irony in context. I otherwise appreciated the read. :)

If you happen to remember any of those, drop her a line. I'm pretty sure Deirdre's fairly meticulous about that sort of thing.

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

#206

Post by notRobot »

notRobot wrote: post #204
mike503 wrote: post #195

Earlier quoted context omitted.

Also firing a second request would break restful behavior and could wind up really messing stuff up worse. Maybe it places an order twice? Who knows. Not a good idea.

If reloading a page (which is what this is identical to) breaks your website, that's not on the user.

GET requests are not supposed to modify server state.

https://stackoverflow.com/questions/45016234/what-is-idempot...

https://en.wikipedia.org/wiki/HTTP#Request_methods

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

#207

Post by dwaite »

david422 wrote: post #127
ramesh31 wrote: post #115

Earlier quoted context omitted.

>Somehow the people at Apple thought an error code and a brief description would be scary, so they opted for this absolutely terrifying icon instead This is why interfaces made by programmers tend to be impossible to use. Our minds simply work differently than normal people. In the 99% case, that icon will tell a user precisely the same information as any kind of detailed error log, which is "Oh no, something is brok…

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.

Cars are actually a good example of how errors should work. Errors should give appropriate information to diagnose and solve the problem to the stakeholders.

So a car may have different lights/states from "low fuel", "tire pressure", "door ajar" - to "service soon" to "failure imminent". These are all meant as calls to action by a typical driver, including potentially having them escalate to a mechanic/service center.

It is the mechanic can read off the status codes of the car computer to help further diagnose the issue.

A 401 in a browser indicates how the _browser_ can react to insufficient authentication, via the instructions in WWW-Authenticate headers.

The majority of status codes provide very little instruction to the browser, and provide even less to the end user. "400 Bad request" doesn't include instructions on how the browser can fix the query or form data being submitted, nor is there a process to inform the originator that they are linking to a location incorrectly. To the end user, a 400 error is even more worthless - there is nothing about a 400 that gives instructions on how to get the problem repaired.

The trend for development is to define errors which describe each failure case and to delegate those errors up. A robust system however needs to think about failure cases holistically and along with their recovery steps. Once you do this you typically have significantly fewer errors, because you have identified the appropriate recovery steps.

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

#208

Post by dwaite »

ryandrake wrote: post #133
troupo wrote: post #84

Earlier quoted context omitted.

The problem is, now I have to do this every time for shitty dumbed down apps. Prime example: Twitter always responds "oops, something went wrong" even if the backend returns `{ error: "Video aspect ration is not allowed. Try 16:9" }`

Those "oopsie-doopsie, website made a poopsie" infantilizing error messages are just awful. Tell the user 1. specifically what went wrong, 2. what, if anything, they can do to correct, and 3. a token (like an error message) that could be useful for tech support or reporting a bug. People's heads aren't going to explode if you treat them like functioning adults.

The meta conversation here is whether there was a decision to NOT give the user information on how to correct the problem - or if it was a process maturity, developer skill, or limited resources that caused the development to focus on the "happy path" only.

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

#209

Post by dwaite »

somat wrote: post #64
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?

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

The boot scroll was/is actively harmful in that it requires process-of-elimination troubleshooting to recognize deviations from a "normal" boot process.

The individual subsystems should be able to recognize their correct state and output a clear diagnostic when they are not in that state. I shouldn't have to step back through e.g. several broken services to find out my second ethernet port didn't initialize.

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

#210

Post by kragen »

matt-attack wrote: post #142
isodnhionio wrote: post #111

Earlier quoted context omitted.

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

how are users going to write a reasonable bug report, or level up to developing, if they don't have access to the error code
Post reply on HN