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

51–60 of 212 posts

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

#51

Post by Sebb767 »

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?

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.

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

#52

Post by PascalPixel »

With my browser I naively implemented that anything but (200) would result in an error page

Boy the reports that my browser “wasn’t ready for prime-time” as a result…

It now only shows if the domain can’t be resolved, people are happy

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

#53

Post by OJFord »

namtab00 wrote: post #34
mjan22640 wrote: post #15

Earlier quoted context omitted.

What dns adblock do you use?

not OP pihole as cache, with the router as its upstream, with NextDNS as the router's dns server

What's the point of the PiHole in that setup? If the router doesn't have the storage for as large a cache you're still only using the dnsmasq part of PiHole by the sounds of it? (Not to mention most consumer routers support USB mass storage?)

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

#54

Post by yonatan8070 »

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…

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

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

#55

Post by OJFord »

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?

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

#56

Post by wmidwestranger »

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…

Absolutely true. Especially now that the server is more likely than ever to have an in-browser application as the actual client. That client is the interface to the user and it should be responsible for communication the issue.

I draw the line at nice urls though, I think that's valuable to the client app and the user. At the very least, bookmarks work. Even with all the other state than can exist, it's a solid and useful reference point.

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

#57

Post by brabel »

Sebb767 wrote: post #51
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?

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

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

#58

Post by NoZebra120vClip »

sclu1034 wrote: post #18
bhelkey wrote: post #16

Earlier quoted context omitted.

> Unless a blocked domain corresponds to the front page I visit in a URL, the unavailable resource represents a silent failure Is this not intended behavior? Were you not expecting ads to be silently removed?

From the user's point of view, yes, that is intended behavior. But the browser can't know that, all it sees is a dropped connection. For all it knows, there could be an actual issue with the network. But unless you open the dev tools' network tab, you don't know about that request failing.

TCP RST is indeed considered a transient failure, and the RFCs specify that it should be retried several times before giving up.

My ad blocker returns "0.0.0.0" for A records, which in practice means attempts to connect to 127.0.0.1, which isn't running a server of any kind on port 443/tcp or 80/tcp. So a standards-compliant client would really hang awhile, or hold rendering, until several connects have been attempted and they all failed.

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

#59

Post by rhaway84773 »

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?

Every user, with a single KB shortcut or a click in the main hamburger menu, can access dev tools.

That’s pretty power user friendly.

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

#60

Post by rhaway84773 »

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

Dev tools in every browser is a 1 level menu in the main hamburger menu deep or available via 2 possible KB shortcuts (at least in Windows).
Post reply on HN