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

71–80 of 212 posts

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

#71

Post by AniseAbyss »

Am4TIfIsER0ppos wrote: post #47
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 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.

[dead]

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

#72

Post by pseudalopex »

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

I didn't agree with their conclusion. But the quoted part seemed correct. Some response codes are much more common than others. Redirects are followed by some other code unless the web site is broken in some way. 410 means the web site removed something. Most of the time 404 means the same. Or a link was generated incorrectly.

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

#74

Post by IggleSniggle »

pseudalopex wrote: post #68
reportgunner wrote: post #44

Earlier quoted context omitted.

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

Much of my web experience is broken by default due to blocking Google or occasionally Microsoft ad analytic data. Many flows expect these to load even if it is not necessary for the functioning of the site. Many other sites break just due to strict enforcement of anti-cross-site tracking.

I'm not just talking about ad supported sites, although I guess you could say that Google Drive is indirectly ad supported.

Since I do most of my ad blocking at the network layer rather than in my browser, it's not always obvious to me as the user whether it was a "my blocking broke the site" error or a "The site is broken" error.

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

#75

Post by IggleSniggle »

daveidol wrote: post #36
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…

> Because all my devices use the same configuration, and it's non-trivial to disable it This is exactly why I do not use a DNS-based ad blocking solution (it’s trivial to disable uBlock Origin and refresh if something feels broken).

This is why I run my DNS-based ad blocking solution through a VPS. It's trivial to toggle the VPN on/off on desktop or mobile. On desktop I have a single key to swap my network. On mobile, a gesture followed by two taps does the same.

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

#76

Post by dredmorbius »

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…

"The Web is an error condition": http://deirdre.net/programming-sucks-why-i-quit/>

See also Richard I. Cook's "How Complex Systems Fail": https://how.complexsystems.fail/>

(Latter is an HN perennial, with 55 sumbissions presently: https://hn.algolia.com/?q=how%20complex%20systems%20fail>. Most recent 10 months ago, so not quite ready for a re-up: https://news.ycombinator.com/item?id=32895812>.)

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

#77

Post by richardwhiuk »

theginger wrote: post #49

Just because they rendered the text doesn't mean they've ignored the status code. There can be a lot of other stuff going on behind the scenes that are happening differently due to this code. A 503 with a Retry-After header is a good example, although it has limited browser support, but in theory it will reload the page after the timeout. There are different caching/storing rules with different status codes, they may…

"but in theory it will reload the page after the timeout" - does any browser actually implement this?

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

#78

Post by starttoaster »

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

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.

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

#79

Post by bawolff »

OJFord wrote: post #55
bawolff wrote: post #39

This is silly. Web browsers handle the status code correctly by displaying the error in the response body. 500 isn't for end users - it is for web crawlers and caching proxies.

What's silly? The article just describes the way it is, there's no judgement or call to action?

It implies (especially the headline) that there is something wrong with that or it is at least unexpected.

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

#80

Post by onion2k »

Am4TIfIsER0ppos wrote: post #47
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 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 I wield that much power then I really ought to be paid more.
Post reply on HN