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

111–120 of 212 posts

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

#111

Post by isodnhionio »

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

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

#112

Post by Jiocus »

Dylan16807 wrote: post #5
janosdebugs wrote: post #3

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.

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

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.

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

#113

Post by HideousKojima »

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

>Once you have this realization, what's the advantage of showing the proper error code to the user?

Have you ever done end user support? Having a moderate amount of detail like an HTTP response code saves tons of time and headaches when a user calls in.

And some of the specific codes you mentioned (401, 403, and 429 for example) actually do give a power user actionable information. They can know that there's something wrong with their login credentials or permissions, or that they are making too many requests too quickly and need to slow down or wait to stop being rate limited. And knowing that it's some kind of 500 error lets a power user know "Ok, this probably isn't an issue on my end" which helps them stop worrying that it's something they're doing wrong or something wrong with their system.

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

#114

Post by Jiocus »

richardwhiuk wrote: post #77
theginger wrote: post #49

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…

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

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.

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

#115

Post by ramesh31 »

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

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

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

#116

Post by jeroenhd »

bawolff wrote: post #37
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…

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

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.

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

#117

Post by javajosh »

jiggawatts wrote: post #83
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…

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.

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

#118

Post by javajosh »

Jiocus wrote: post #112
Dylan16807 wrote: post #5

Earlier quoted context omitted.

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

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.

Fun fact: did you know you can inline an image without base64 encoding it? Use svg you can inline the markup using a data url without base64 encoding. This is how I do my favicons at simpatico[0]:

  
        
    "
  >
What's nice is that this opens up the possibility to generate dynamic favicons really easily using only string interpolation.

0 - https://simpatico.io/svg.md

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

#119

Post by methodical »

kaoD wrote: post #43
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…

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

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.

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

#120

Post by falcor84 »

thrashh wrote: post #94
funcDropShadow wrote: post #87

Earlier quoted context omitted.

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.

So could we maybe have them not get any privileges by default, but still work?
Post reply on HN