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

81–90 of 212 posts

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

#81

Post by onion2k »

justsomehnguy wrote: post #46
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 error codes Ah, yes, I love remote troubleshooting. "What does the site says?" "Hell I know but there are funny badgers singing about mushrooms!"

Sentry, Rollbar, etc are your friends.

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

#82

Post by justsomehnguy »

onion2k wrote: post #81
justsomehnguy wrote: post #46

Earlier quoted context omitted.

> Users have no business seeing error codes Ah, yes, I love remote troubleshooting. "What does the site says?" "Hell I know but there are funny badgers singing about mushrooms!"

Sentry, Rollbar, etc are your friends.

If I'm on the phone with the user then Sentry et al. already failed.

More so, problem maybe somewhere else so S. wouldn't even help here

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

#83

Post by jiggawatts »

theginger wrote: post #69
jiggawatts wrote: post #40

The author is wrong, browser behaviour does change significantly in one major way: errors are not cached. Or much more importantly, errors incorrectly returned with 200/OK success codes are cached, semi-permanently breaking your site. If you've get helpdesk staff telling customers to "clear their browser cache", this is one common reason why this "works" as a fix. Please, I beg you: stop being "nice". Stop catching e…

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…

Who said anything about letting exceptions reaching the users!?

The exception needs to bubble up to the request pipeline, which will set an integer error code, and then... redirect to a generic "sorry we broke" error page.

Showing the full exception stack trace and other sensitive bits and pieces is for local debug mode, not for production.

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

#84

Post by troupo »

starttoaster wrote: post #78
troupo wrote: post #38

Earlier quoted context omitted.

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.

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" }`

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

#85

Post by entuno »

chii wrote: post #26
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.

security by obscurity only stops casual bots, and any determined bot would easily be able to ignore the status code and inspect the contents to get at what they wanted anyway. And you run the risk of having a transparent proxy fail on your real users doing this too. It's why nobody does it.

It wasn't really intended as a security feature - more a way to screw around with script kiddies.

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

#86

Post by notRobot »

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%20%20%7D%0A%20%20%7D%3B%0A%20%20xhr.open('GET'%2C%20window.location.href%2C%20true)%3B%0A%20%20xhr.send()%3B%0A%7D)()%3B%7D)()%3B

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

#87

Post by funcDropShadow »

starttoaster wrote: post #78
troupo wrote: post #38

Earlier quoted context omitted.

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.

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 url into emacs for storing it there. Firefox asks me every time I click on that bookmarklet on a new origin (domain, protocol tuple) whether I want to allow that. With no option to avoid that. I have written this piece of code myself I want to use it to enhance my workflow. There is no need to treat it like any javascript hosted on a CDN, or on a Facebook server.

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

#88

Post by NoZebra120vClip »

mjan22640 wrote: post #15
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…

What dns adblock do you use?

NextDNS.

They have a feature where if you're a free user, and you exceed your query quota for the month, they turn off all features and it acts like a normal resolver.

For some reason, there is no access to such a setting to do it manually, and I am a subscriber now, too.

There are profiles that can be configured separately, but even just to activate an alternate profile, one must reconfigure the DNS settings on the devices.

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

#89

Post by onion2k »

rvba wrote: post #48
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 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.

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

#90

Post by gbalduzzi »

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

Post reply on HN