Browsers barely care what HTTP status code your web pages are served with • Hacker News Board

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

#171

Post by sopooneo » Fri, Aug 11, 2023, 7:47 PM UTC

zlg_codes wrote: post #165

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…

I disagree. I think users should be aware of any breakage up front, and center. We encourage drivers to recognize warning signs in the operation of their vehicles; we should do the same with browsers. Hiding information from the user is not ethical. Then again, I also think people should be taught better than to hop on the Web without any training or knowledge. Computers and illiteracy go together about as well as bo…

My personal inclinations agree with yours, I think. I prefer as much detail as possible up front. Which is why I hate the vagueness of my dashboard's "check engine" light*. However, I bet automakers do that not just so the display is cheaper/simpler, but because most drivers are not interested in anything more detailed (or scary).

* Which for me has almost always just meant some oil change "timer" was up, not even that any meter detected my oil was wearing out.

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

#172

Post by rurcliped » Fri, Aug 11, 2023, 8:05 PM UTC

sopooneo wrote: post #171

zlg_codes wrote: post #165

Earlier quoted context omitted.

I disagree. I think users should be aware of any breakage up front, and center. We encourage drivers to recognize warning signs in the operation of their vehicles; we should do the same with browsers. Hiding information from the user is not ethical. Then again, I also think people should be taught better than to hop on the Web without any training or knowledge. Computers and illiteracy go together about as well as bo…

My personal inclinations agree with yours, I think. I prefer as much detail as possible up front. Which is why I hate the vagueness of my dashboard's "check engine" light*. However, I bet automakers do that not just so the display is cheaper/simpler, but because most drivers are not interested in anything more detailed (or scary). * Which for me has almost always just meant some oil change "timer" was up, not even th…

Years ago, many decisions to hide error details were a cargo cult reaction to CVE-2012-4929. To review, CVE-2012-4929 works like this:

1. the attacker can see (but not decrypt) the victim's TLS traffic to example.com

2. an attacker-controlled website makes the victim send many different invalid requests to example.com, each of which gets an error message

3. some data in each request is attacker-controlled, but authentication data in headers is filled in by the victim's browser

4. example.com compresses response data before encrypting it

5. because repetitions affect compression, the response size is smallest when the authentication data matches part of the attacker-controlled data

6. after enough requests, the attacker knows the authentication data to login to example.com as the victim

One workaround for CVE-2012-4929 was to set up the server so that an error message never depended on the request data. Before CVE-2012-4929 was announced, people thought it was sufficient to sanitize the error message (i.e., avoid XSS) but CVE-2012-4929 prompted a shift toward producing exactly the same error message for all invalid requests. (Not sure, but I think this was the original motivation for Google's famous "That's an error. That's all we know." messages.)

There were better CVE-2012-4929 defenses later, but the cargo cult had already formed. (Some subset of) a generation of developers believed that customized error messages were Very Bad because they enabled account takeover.

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

#173

Post by Nereuxofficial » Fri, Aug 11, 2023, 8:28 PM UTC

isodnhionio wrote: post #111

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

That icon looks straight lime out of one of those webcam horror movies filmed during the pandemic

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

#174

Post by entuno » Fri, Aug 11, 2023, 8:55 PM UTC

misswaterfairy wrote: post #98

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

Yes - that's the one. I remember the slides showing the very variable results for the vuln scanners running against it.

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

#175

Post by mrpippy » Fri, Aug 11, 2023, 8:58 PM UTC

isodnhionio wrote: post #111

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

That error is the boot firmware telling you it can’t find a bootable OS. It doesn’t know what language you speak, and would an error code really be helpful? If you’re knowledgeable enough to know what the error codes mean, you would know that cmd-V gives you verbose logging.

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

#176

Post by zlg_codes » Fri, Aug 11, 2023, 9:11 PM UTC

sopooneo wrote: post #171

zlg_codes wrote: post #165

Earlier quoted context omitted.

I disagree. I think users should be aware of any breakage up front, and center. We encourage drivers to recognize warning signs in the operation of their vehicles; we should do the same with browsers. Hiding information from the user is not ethical. Then again, I also think people should be taught better than to hop on the Web without any training or knowledge. Computers and illiteracy go together about as well as bo…

My personal inclinations agree with yours, I think. I prefer as much detail as possible up front. Which is why I hate the vagueness of my dashboard's "check engine" light*. However, I bet automakers do that not just so the display is cheaper/simpler, but because most drivers are not interested in anything more detailed (or scary). * Which for me has almost always just meant some oil change "timer" was up, not even th…

I've thought about alternative dashboards as an option, that show rpm, piston firing stats, or other small details that, when looked at in aggregate, can diagnose a lot of consumer-serviceable issues.

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

#177

Post by delecti » Fri, Aug 11, 2023, 9:17 PM UTC

CapsAdmin wrote: post #149

delecti wrote: post #110

Earlier quoted context omitted.

Those are two ends of the spectrum of how to handle unknown errors, but ignore the other axis: known errors. The UI displaying a red text field saying "field whatever is required to continue" is just as much an error message, but it's clearly actionable. There are lots of reasonably actionable error messages in all varieties of UIs for expected error cases. I don't know that there's a lot of useful middle ground betw…

Yeah this problem is a little more complicated than what I mentioned. By all means map known errors, but does the fallback really need to be "something went wrong?" It was a bit of a rhetorical statement (or at least in my mind it was). Like how about "Something went wrong (see details)" or something to that effect? In my work experience some people are really dogmatic about the idea of not showing any sort of error…

In my work experience, users will complain about any sort of message. We recently got a request to change a message of "OK" to something more detailed. What more do you want than a message telling you that the thing you were trying to do succeeded?

So I'm very sympathetic to people arguing against showing error messages.

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

#178

Post by sopooneo » Fri, Aug 11, 2023, 9:18 PM UTC

dtgriscom wrote: post #92

notRobot wrote: post #86

Earlier quoted context omitted.

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(); })();})();

And to recurse on more level: https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequ...

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

#179

Post by jiggawatts » Fri, Aug 11, 2023, 9:20 PM UTC

javajosh wrote: post #117

jiggawatts wrote: post #83

Earlier quoted context omitted.

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.

...and there should be a guid assigned to the problem, in the logs, and possibly visible to the end user.

The APM does that for you.

Open Telemetry, Application Insights, New Relic, etc… will all stamp the request with a unique id and associate any errors with it.

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

#180

Post by hu3 » Fri, Aug 11, 2023, 9:26 PM UTC

thrashh wrote: post #105

theginger wrote: post #69

Earlier quoted context omitted.

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…

I think it’s cute you think most developers let exceptions rise. Most developers I notice just catch the error right away and make the function return something non-sensible like a 0 for a string value function. Slightly better developers just let the exceptions bubble. The rare breed looks at what exceptions are being thrown, decides which ones to handle at which stack level, and repackages them as needed when the e…

Ahhh the Visual Basic days of:

On Error Resume Next

In the first line of every function. It's tells the Interpreter:

"Shhhh, it's fine. Just ignore errors. Division by zero? No worries. It's Fiiiiine. Try to access inexistent index of an array? Who cares, it's Friday!"