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

91–100 of 212 posts

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

#91

Post by orev »

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…

Those barebones ‘XXX Error’ pages are sent from the server and rendered in the browser just like the post talks about. Browsers have always handled the html returned with the error code in the same way (by showing it to the user). The only difference from the old days is that now sites show a nicer page instead of using the default barebones error pages.

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

#92

Post by dtgriscom »

notRobot wrote: post #86
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…

For anyone interested, here's a bookmarklet to view the current page's HTTP status code (makes a new request): javascript:(function()%7Bjavascript%3A(function()%20%7B%0A%20%20var%20xhr%20%3D%20new%20XMLHttpRequest()%3B%0A%20%20xhr.onreadystatechange%20%3D%20function()%20%7B%0A%20%20%20%20if%20(xhr.readyState%20%3D%3D%3D%204)%20%7B%0A%20%20%20%20%20%20alert('HTTP%20Status%20Code%3A%20'%20%2B%20xhr.status)%3B%0A%20%20%…

For suspicious types (including me):

    javascript:(function(){javascript:(function() {
      var xhr = new XMLHttpRequest();
      xhr.onreadystatechange = function() {
        if (xhr.readyState === 4) {
          alert('HTTP Status Code: ' + xhr.status);
        }
      };
      xhr.open('GET', window.location.href, true);
      xhr.send();
    })();})();

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

#93

Post by jondwillis »

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

I’m not sure if we are talking about PiHole here, but I just log into the web interface and whitelist or temporarily disable blocking. Not as trivial as a browser extension, but still quite easy and fast.

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

#94

Post by thrashh »

funcDropShadow wrote: post #87
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.

Dev tools of a browser are not what a power user focused browser would need. Think more about being able change keyboard shortcuts. Being able to execute small custom scripts that do stuff with tabs, windows, and pages. Yes I know browser plugins and bookmarklets exist. But why do bookmarklets run with the security context of the currently opened page? I have one self-written bookmarklet to capture the page title and…

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

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

#95

Post by account-5 »

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?

Isn't the power user served perfectly fine with the devtools? I mean if a website breaks a normal user is going to leave it the power user will open devtools?

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

#96

Post by babypuncher »

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?

That user is who the dev tools are for?

It's not a big deal for a power user to hit F12 then click the network tab...

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

#97

Post by DangitBobby »

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…

What if the error is a problem the user can actually address and continue using the service? I don't think we should stop trying to make useful error messages because some people are completely helpless.

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

#98

Post by misswaterfairy »

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.

This one? https://www.youtube.com/watch?v=4OztMJ4EL1s

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

#99

Post by DangitBobby »

onion2k wrote: post #89
rvba wrote: post #48

Earlier quoted context omitted.

> Users have no business seeing error codes. Those are for devs. This is an Anti-pattern called mushroom management (keeping users in the dark). Not telling users what went wrong is just plain wrong. Breaking the termomether to hide fever. When you get an error message you can at least google it, or make a ticket.

Users are told what's wrong. They get a friendly "Page not found" or "Server error" page. They're not denied access to the cryptic error code that means nothing to them.

Cryptic error codes that mean nothing to a layperson can result in online discussion in community support where users or devs can actually help each other. Or they might just glean enough information to work around the problem themselves. Zero information is not empowering.

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

#100

Post by DangitBobby »

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

There may be an issue with the application, but if you tell them what ballpark the issue is in they might just work around it.
Post reply on HN