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

https://utcc.utoronto.ca/~cks/space/blog/web/BrowsersAndHTTPStatusCodes

by pabs3 • 3 years ago

142 207 3 years ago

utcc.utoronto.ca

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 adblocker, many sub-resources fail to load (GET or POST) with a network error (TCP RST). Unless a blocked domain corresponds to the front page I visit in a URL, the unavailable resource represents a silent failure, and I have foolishly contacted Support desks multiple times because my own use of the adblocker caused a silent failure that was difficult to diagnose.

In fact, I now have no way of knowing what web apps are like without an adblocker. Because all my devices use the same configuration, and it's non-trivial to disable it, I simply don't know what I am missing. Indeed, in the case of one web app which I've used as a PWA, it was simply missing features that I knew should have been there, and whitelisting enough domain names caused those features to re-appear.

I will just leave you with the most adorable 404 page anyone has ever seen: https://diopitt.org/pray/amen

oneeyedpigeon2• 3 years ago

You'd like to think that the owners of those sites would fix them. A site shouldn't just not work if it can't access a certain JavaScript file - it should at least warn you of the problem.

mjan22640• 3 years ago

What dns adblock do you use?

namtab00• 3 years ago

not OP

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

NoZebra120vClip3• 3 years ago

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.

bhelkey• 3 years ago

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?

sclu1034• 3 years ago

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.

radicalism• 3 years ago

I will just leave you with the most adorable 404 page anyone has ever seen: https://diopitt.org/pray/amen

In the context of your comment, I was amused by how my own ad-blocker failed to properly show the (image on the) 404 page, since it is loaded from a different domain :D

daveidol• 3 years ago

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

IggleSniggle2• 3 years ago

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.

jondwillis• 3 years ago

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.

kaoD2• 3 years ago

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.

In what way? Do you mean not feasible or just lazily coded?

methodical• 3 years ago

Also was confused by this sentence. I have worked on several Node, React, and even PHP (albeit a long time ago!) applications, and every single one of them caught and surfaced internal server errors. Never was aware there were actually people out there regardless of language who weren't catching and surfacing 500s in a straightforward fashion to the user.

account42• 3 years ago

Browsers used to display an icon and beveled borders to indicate broken images. Not sure when they stopped but I wish they hadn't.

nullindividual3• 3 years ago

They still do. The problem is, as always, JavaScript and how the assets are loaded and images rendered on pages.

dredmorbius3• 3 years ago

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

lcnPylGDnU4H9OF3• 3 years ago

The first one is a 404. I love the irony of there being an error condition in this case of a missing redirect.

https://deirdre.net/2014/programming-sucks-why-i-quit/

janosdebugs• 3 years ago

Does anyone still remember the days when a certain browser would ignore what the server sent with a 404 page unless it was larger than 512 bytes? Yeah, I'm happy with the browser just showing what I send it without trying to second guess the content.

Dylan168072• 3 years ago

Oh yeah, I still have a 404 page that's padded with comments because its only contents are a title and an image.

oneeyedpigeon2• 3 years ago

I hope that image has good alt text...

Jiocus3• 3 years ago

base64 inline your image with the HTML and you should be well past that threshold.

It's preferable to not make additional requests (like for an image) on an error page - in case the requested server is at fault - breaking the error page.

eastbound• 3 years ago

Do you remember when the AskBar would intercept 404 pages and display suggestions for pages you might really be looking for, “just to help you”?

And then Oracle shipped the AskBar into the Java installers.

adtac• 3 years ago

Do you remember when ISPs would redirect unresolved DNS A record queries to their “search engine”?

nullindividual3• 3 years ago

Yep! Blasted IE.

https://stackoverflow.com/questions/8338427/i-created-a-cust...

asplake• 3 years ago

To me, none of this is surprising or undesirable - ie the browsers are doing the right thing. Content is there to be rendered, not hidden. Status codes are not there for the average end user.

makeitdouble• 3 years ago

This feels surprising for a minute until comes to mind all the little things that would be broken if browsers didn't behave that way.

Custom 404 pages to give the user a friendly explaination and further directions, 500 pages with the exception stack trace in our frameworks to debug the errors etc.

A status different from 200 rarely means there's nothing that could be displayed to the user.

acumenical• 3 years ago

I agree. The way I see it is that browser is more of an HTTP response viewer than a REST client.

entuno3• 3 years ago

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.

chii• 3 years ago

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.

entuno3• 3 years ago

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

tredre3• 3 years ago

security by obscurity only stops casual bots

Casual bots is what 95% of website operators have to deal with, blocking them is still a win.

Same reason people move ssh ports around. Of course it doesn't add security if you're targeted, but it makes casual bruteforce bots go away.

Call that log hygiene if you really object to the security aspect.

misswaterfairy• 3 years ago

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

entuno3• 3 years ago

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

_nalply• 3 years ago

This is the cause of a split in failure situations.

Failures fall into two often very distinct cases:

1. Failures the end-user is able to understand and in some circumstandes to fix themselves. Examples: (HTML) page not found, no connection, etc.

2. Failures the end-user is in no case able to fix; it's up to the programmer. Examples: Server misconfigured, missing media files on server, etc.

It never makes sense to display the full error messages in case 2. It suffices to hide the error and perhaps make it available in DevTools. Often a good way is: give a generic message, and because some failures are transient, tell the user to retry. Also it can make sense to add an error number so that the end-user can give support the error number.

So it is useful to let the browser be lenient with HTTP status codes except in some specific cases which the article does mention (HTTP status code 500 for JavaScript files, for example).

masswerk• 3 years ago

I think, this is a general design feature. The specs explicitly allow a possible document body. If the status doesn't affect the process of retrieving the requested document (like a redirect), a client is free and even expected to display the document body.

Having said that, if the status code is in the 4xx client error range, I'd wish that any document.title would be strictly ignored and browsers would always display the status code (together with the human readable error title) as the page title.

onion2k5• 3 years ago

(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 website somehow. It was horrible from a support perspective, and if the user was new to the web it sometimes made them very anxious about using the web in the future.

Users have no business seeing error codes. Those are for devs. Hiding them away in devtools is a very good thing.

falcor843• 3 years ago

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?

Raed667• 3 years ago

Opening the dev tools and looking at the network tab is easy enough for power users.

riedel• 3 years ago

Why not use extensions for this like (quickly searching firefox add-ons): https://addons.mozilla.org/de/firefox/addon/http-status-code... ?

I think we just have fight for poweruser options to be available via APIs and support the add-on ecosystem.

unmole• 3 years ago

This sounds like inconsequential quibbling over terminology. There's nothing stopping a browser power user from opening up dev tools to look at error codes.

onion2k5• 3 years ago

When did we stop building software for the "Power User" persona?

I think the change was very simple - we stopped bothering with middleground. "Power Users" were treated like "users, but a bit more", so we had 'users', 'power users', and 'developers'. All that happened is that we just accepted that power user can have the same access to tools as developers.

We didn't stop giving power users extra power. We gave power users more power.

imperialdrive• 3 years ago

At first we agreed; having a future with primarily "Power Users" in mind would be pretty empowering. Then,

At second; it would likely mean many folks lacking in other skills, unbalancing what little we have in the society of work.

At third: include all the error detail you like, simply put it behind a "click here for more details" side door.

reportgunner• 3 years ago

When did we stop building software for the "Power User" persona?

The moment they(i mean we) started blocking ads I think.

Sebb767• 3 years ago

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.

rhaway847733• 3 years ago

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.

somat• 3 years ago

Related: the boot scroll. most of the time the scroll of boot messages is harmless and when the system fails to boot it is very very useful to see where. yet the design types hated it. and now no desktop orientated OS shows a boot scroll, opting for a near useless spinner instead.

Opinion: I quite like the scroll, I think it comforting to see what the machine is doing. I think this is why sim city put a fake one in their loader(reticulating splines anyone). I wonder if the sim city messages tied into actual load events and could be used by the programmers to debug the loader. I think the later ones were random, but 2000 might of had an order to it.

account-5• 3 years ago

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?

babypuncher• 3 years ago

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

NoMoreNicksLeft• 3 years ago

When did we stop building software for the "Power User" persona?

1996 or 1997. I can't narrow it down further.

Shortly after that, they actively became hostile to power users. Just play with your dumb little consumer appliance like you're supposed to.

mcronce• 3 years ago

My current pet example for the trend of hiding more and more details from users is an issue I recently had with Doordash.

I was trying to place an order, and it kept failing with a red banner stating "something went wrong" (I'm paraphrasing as I don't recall the exact verbage, but it was one of those completely worthless error messages)

Pop open dev tools ... the server is returning something about a graphql error.

Support had no idea what was wrong.

The problem ended up being that my saved credit card had expired. For fuck's sake, that is a user-actionable error; tell me what the problem is. At least tell me it was a payment problem, since that's probably all the payment processor told you.

BrandoElFollito2• 3 years ago

Probably because power users are en insignificant fraction of users for a general public application.

I drive a car and only care about the speed, how far I can drive and to be warned that I have to stop if something is wrong.

I do not care about the temperature of the oil or water, about the tension on the thffr which powers the louhguh or why zgfnkvgv failed.

I know that if something goes wrong I will call the road assistance number.

If someone wants to learn more there is the hidden bus they can plug into, aka Dev Tools For Cars

CapsAdmin4• 3 years ago

There must be a middle ground between "Something went wrong, please try again later :)" and "TypeError: Cannot read property 'submit' of null" when performing an action.

I sometimes hear the "best of both worlds" is something like logging all errors while showing optimistic errors to the users on frontend. This is somewhat fine for errors that happen on the backend, but catching browser errors is tricky because extensions can throw errors. On top of that a user might not be comfortable with you collecting errors that happen in their browser.

richardwhiuk2• 3 years ago

"Something went wrong, please try again later :)" is cheap (try { } catch () { print "Something went wrong" })

"TypeError: Cannot read property 'submit' of null" is cheap (just render whatever error you get).

Anything else is expensive, and probably doesn't gain you anything.

delecti2• 3 years ago

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 between your two examples though. By definition, a UI can't really give actionable advice on how to fix an error that it isn't programmed to expect.

SoftTalker• 3 years ago

Yes, the user should see the former, and the application should log the latter.

The user probably can't do anything about a null reference, so there's not a lot of benefit in providing this level of detail, and for most users it obscures the bigger point that "something went wrong."

bawolff4• 3 years ago

Tbf, 500 is the appropriate error message for user has broken the server.

jeroenhd2• 3 years ago

5xx means the server messed up, if the user should've done something different you'd see a 4xx error.

A good web server validates the user input, throws a 4xx error if the input is bad for the current state, and if something still goes wrong (which is a server bug) the 5xx range becomes appropriate.

justsomehnguy2• 3 years ago

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

onion2k5• 3 years ago

Sentry, Rollbar, etc are your friends.

Am4TIfIsER0ppos• 3 years ago

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.

onion2k5• 3 years ago

If I wield that much power then I really ought to be paid more.

gbalduzzi• 3 years ago

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

rvba• 3 years ago

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.

onion2k5• 3 years ago

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.

mekoka• 3 years ago

Right. To which category belongs the user that is curious enough to open "Page Info", but destabilized when they see a status code there?

yonatan8070• 3 years ago

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

Hamuko• 3 years ago

Something happened

ElectricalUnion• 3 years ago

Those are usually structured HRESULT values, Win32 error codes, and NTSTATUS values.

So in a way, they are already "elaborating" the type of error - as well as a single 32-bit integer in C can "elaborate" over an error, that is, not a lot.

For all their faults dotnet and java make it really easy to not mangle up the stack trace.

wmidwestranger• 3 years ago

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.

notRobot3• 3 years ago

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

dtgriscom• 3 years ago

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

recursive2• 3 years ago

This assumes a GET.

orev• 3 years ago

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.

DangitBobby4• 3 years ago

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.

ilyt• 3 years ago

I still remember how Chrome decided to do it if 500 message was too short...

isodnhionio3• 3 years ago

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 users something underpowered that is going to break anyway, or acknowledge that computers are complicated, and build tools and resources to help users navigate them. And users should recognize it as folly to try to use the most complicated tools on the planet today without any understanding of how they work.

This doesn't really apply to HTTP status codes. They're largely useless. It does apply to the way my Macintosh told me of a misconfiguration after I reinstalled the operating system. 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:

https://i.stack.imgur.com/Y1teY.jpg

(Not my picture, by the way.)

ramesh31• 3 years ago

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

This is why interfaces made by programmers tend to be impossible to use. Our minds simply work differently than normal people. In the 99% case, that icon will tell a user precisely the same information as any kind of detailed error log, which is "Oh no, something is broken, I should go to the Apple store."

wwweston2• 3 years ago

in fact computers don't work very well and users encounter errors on a regular basis. Using computers is a skill. It takes study.

I think what's been lost -- or perhaps never been gained -- is an art of dual tiering error condition messaging.

Highest visibility messaging should be the simple & for the most general audience: "You Gave us Bad Information, here's how to fix it" for cases where that applies, with more information available for training users if they want it.

When it's an application or systems failure: "Something went wrong on our end, not your fault" should be the high visibility message. Then maybe "here's a request ID, you can contact this support channel about it if the problem persists". Then somewhere low visibility "here's some detail about what's going on under the hood if you want to look."

This is part of a general sin in product / UX as far as I can tell: the "don't make me think" mantra became something itself people stopped thinking about and transformed effectively into "don't LET me think."

matt-attack• 3 years ago

It seems you're advocating for error messages which I think many would agree with, but the comment you're responding to was proposing that error codes have no place being shown to users. I would generally agree with hiding codes. They're generally meaningless and really intended for devs or automation.

adamsb62• 3 years ago

Even more terrifying for the uninitiated back in the day: fatal error

Nereuxofficial• 3 years ago

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

mrpippy• 3 years ago

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.

idiotsecant• 3 years ago

Using computers is a skill. It takes study.

This is an opinion that, on a personal preference level, I share. It's not, however, a universal truth. An optimally useful computer should be a human interface to information or control of something. The best computer is one that interprets a messy human command, produces the information or action that the human actually wanted, and requires no training at all to use.

Such a machine would be anathema to me, personally, but it would be objectively the best possible general purpose computing device.

zlg_codes6• 3 years ago

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 books go with illiteracy. It takes effort to be computer literate, and hiding the information will make that journey to literacy more daunting than it needs to be.

sopooneo2• 3 years ago

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.

bombcar3• 3 years ago

The very same users will drive their cars with the dashboard lit up like a Christmas tree.

voz_• 3 years ago

The internet of today is awesome, it largely just works. Mountains out of molehills people.

22c• 3 years ago

Servers barely care what HTTP status code their users are served with.

500 / 503 seems to fit any and every error these days, or the classic 200 OK for a page not found.

mrweasel• 3 years ago

Or you can take the route that a former client took: Return 200 OK http status code and just print "500" in the response body. Took me a few minutes to figure out why the monitoring kept insisting that everything was OK when my browser kept showing me "500".

hooby• 3 years ago

It's a convention (and a useful one) that the HTML served for a web server's error pages will include the HTTP status code in the text (and often the <title> as well). But it's only a convention and it can be violated, both accidentally and deliberately (both in omitting the status code and listing the wrong one). If it is violated, you probably won't notice for a while (if ever).

A malicious server can just as easily send the wrong status code, as well as listing the wrong status code in the accompanying html - so if the browser did show the real status code more prominently to the user, that wouldn't actually help in such a case, or would it?

nickdothutton• 3 years ago

This is the web equivalent of “no user serviceable parts inside”. Watch Joe Average use a computer. If he’s shown an error either he recoils as if he’s physically broken it (or the website) or repeatedly just performs the same action again and again like a chicken pecking at a corn dispenser, or finally mashes the keyboard with his fists and slams the laptop shut in frustration.

The days of a bespectacled web user, thoughtfully musing over an error message, while fiddling with a self-propelling pencil, sat at a Sun/SGI/HP/IBM X11 session are long gone.

bawolff4• 3 years ago

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.

OJFord2• 3 years ago

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

bawolff4• 3 years ago

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

jiggawatts3• 3 years ago

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 exceptions and dropping them on the floor! Let them bubble up to the web framework pipeline so that an error code is sent.

Your CDN will thank you. Browser caches will thank you. Corporate proxy servers will thank you. Application monitoring tools will thank you. Load balancers will thank you.

I kid, I kid. None of those will send you thanks in an email. Instead, they'll work tirelessly in silence to deliver your application as intended, instead of holding on to transient errors for days on end and upsetting your users.

kaoD2• 3 years ago

Also: search engines. I spent a good chunk of a month fixing an app initially developed with this mindset. Immense value delivered just by making things work as they should've from the beginning.

theginger2• 3 years ago

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 like this so you can at the very least sanitize them for XSS. This is already built in to some frameworks. If you are using something that doesn't you need to do it yourself and it's probably easier to just strip it all in production, you just need to make sure you are still setting an appropriate status code.

jiggawatts3• 3 years ago

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.

thrashh2• 3 years ago

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 error cannot be handled that deep in that stack due to a lack of context. Then they write framework-level exception handlers for errors that rise to the top because they cannot be corrected at a higher stack level to give users specific error messages with user-correctable actions without revealing anything sensitive. “Your image is too small, wanker.”

theginger2• 3 years ago

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 also disable certain features, eg if you have been loading a page with an error you might find the auto complete feature in the URL bar doesn't work. I often find this is really annoying when building something new and haven't got it quite working, I keep needing the full URL, where as if it had just once given me a 200 I could just type a few letters and it would come up, but it probably far more useful that auto complete doesn't get polluted with mistyped URLs and broken websites.

richardwhiuk2• 3 years ago

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

Jiocus3• 3 years ago

Page reloads doesn't seem to be an anticipated or suggested feature for this header, irrespective of error code. Communicating API rate-limiting (429 Too Many Requests) or temporary downtime (503 Service Unavailable) to other services and bots seems to be it's most use.

PascalPixel• 3 years ago

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

jgalt212• 3 years ago

We use "correct" status codes to communicate to spiders and scrapers that "we're on to you".

jimmaswell• 3 years ago

if you respond to a request for a web page with a HTTP 200, 4xx, or 5xx code outside of these specific ones and some HTML, almost all browsers will display the HTML to the user

Chrome outright refuses to show the HTML of a 500 response in favor of its own dinosaur animation or some garbage, or did that change?

m3047• 3 years ago

In other news, web servers barely care whether that alleged HTTP/1.1 request contains a Host: header...

javajosh3• 3 years ago

Once upon a time I wrote a feature request for the Chrome extension team to allow an extension to change the response code of a request. This would be a real boon to testers wanting to see the behavior of the browser under those conditions without having to fiddle with the server. But the Chrome team closed it as unneccessary or something.

That was a mistake.

otikik• 3 years ago

They also don’t care about the HTTP headers, or the latency. All that belongs in the developer view.

nomadspiritnet• 3 years ago

I use a budget mobile carrier and I noticed that it blocks http access to most websites, even with linux updates.

throwawaaarrgh• 3 years ago

Browsers are just shit user interfaces. They've never prioritized the user experience, nor actually integrated good solutions to common status problems. Designers even actively avoid common widgets because they're so bad.

Every once in a while they remove widely used functionality from the UI or bury it behind a lot of other crap, so someone has to invent an extension to bring it back. It's terrible.

All the alternatives have varying degrees of suckitude, and there's no way to just make an alternative browser without like $1.5 million dollars and two years of development.

bitlax• 3 years ago

https://en.m.wikipedia.org/wiki/Robustness_principle

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

Related Stories