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

121–130 of 212 posts

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

#121

Post by nullindividual »

ElectricalUnion wrote: post #108
yonatan8070 wrote: post #54

Earlier quoted context omitted.

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

Those are usually structured HRESULT values, Win32 error codes, and NTSTATUS values. So in a way, they are already "elaborating" the type of error - as well as a single 32-bit integer in C can "elaborate" over an error, that is, not a lot. For all their faults dotnet and java make it really easy to not mangle up the stack trace.

You want err.exe [0].

[0] https://www.microsoft.com/download/details.aspx?id=100432

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

#122

Post by nullindividual »

account42 wrote: post #66
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.

They still do. The problem is, as always, JavaScript and how the assets are loaded and images rendered on pages.

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

#123

Post by nullindividual »

janosdebugs wrote: post #3

Does anyone still remember the days when a certain browser would ignore what the server sent with a 404 page unless it was larger than 512 bytes? Yeah, I'm happy with the browser just showing what I send it without trying to second guess the content.

Yep! Blasted IE.

https://stackoverflow.com/questions/8338427/i-created-a-cust...

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

#124

Post by erikerikson »

brabel wrote: post #57
Sebb767 wrote: post #51

Earlier quoted context omitted.

I don't see how this is related to an error code. Most of the time, if you get a non-200, the website is broken in some way and it's not your problem to fix. If it is (because you develop an extension, for example), it's easy enough to open dev tools. But for the most part, status codes aren't relevant even for power users, as you have no idea whether the page handles the error or is silently failing.

> Most of the time, if you get a non-200, the website is broken in some way That's completely wrong. 1xx codes are all INFORMATIONAL (usually used for switching protocols). 2xx codes are all SUCCESS. 3xx codes are all REDIRECTs. 4xx codes are all CLIENT ERROR. Only 5xx codes are SERVER ERROR. See https://datatracker.ietf.org/doc/html/rfc7231#section-6

OPs assertion checks out. Users won't see a 1X or a 3X. 2Xs are the success case. 4Xs are usually caused by an error in the website that the user didn't define but was served them. The exception is bad data formatting that the UI has probably flagged to them so they never send it to get the 4X. 5Xs are clearly a break in the website.

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

#125

Post by wwweston »

funcDropShadow wrote: post #45
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. 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 lo…

So. Much. This.

I'm pretty sure A/B testing has become a cult whose rituals are often practiced in a way that leads people away from meaningful or productive outcomes.

Is there anywhere else you've found where people are talking about this (either from a perspective of how to do it better or what else to do instead)?

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

#127

Post by david422 »

ramesh31 wrote: post #115
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…

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

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

#128

Post by david422 »

jeroenhd wrote: post #116
bawolff wrote: post #37

Earlier quoted context omitted.

Tbf, 500 is the appropriate error message for user has broken the server.

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.

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

#129

Post by SoftTalker »

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…

Yes, the user should see the former, and the application should log the latter.

The user probably can't do anything about a null reference, so there's not a lot of benefit in providing this level of detail, and for most users it obscures the bigger point that "something went wrong."

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

#130

Post by isodnhionio »

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.

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.

Post reply on HN