I keep telling you! Chrome can sometimes hide an HTTP 500 ClassNotFound error!!



  • The same guy(senior lead dev with 10+ years) who filled the database with comma separated value columns,
    calls me to his desk, showed me a 500 status error page.

    Then told me,

    "Look, you're not supposed to mix Spring form tags with a value attribute specified. It's incorrect syntax. This is causing this 500 error and the users can see this only sometimes because Chrome hides this sometimes".

    Chrome had that magical power of hiding an HTTP status 500 error and make the web app work for a while, and only do this sometimes ?!!!

    The stack trace shows a clear CNF error for the jsp file. It failed to compile the jsp file in the first place.
    I kept insisting looking at the stack trace, he dismissed and kept saying it's the Spring form tags with a value attribute with a value. He didn't have to even look at the stack trace. LOL'

    Oh of course, it was working just fine on the demonstration server, my local host and every other developer's local machine and that of the testers.



  • I, ah, guess it can replace the error page with the built-in Chrome one unless you pad yours to 512 bytes? That's about the only thing that could maybe make sense...



  • That prevents chrome from showing its stupid "friendly error," yes.

    I know nginx pads its default error pages with HTML comments that say something like <!-- workaround to prevent chrome and IE friendly error pages -->.



  • @rc4 said:

    That prevents chrome from showing its stupid "friendly error," yes.

    No. The guy was talking about the web application completely behaving normal sometimes and crashing( HTTP 500, with ClassNotFound root cause) sometimes.

    Btw, then I asked him to look at the stacktrace and he just dismissed my suggestion.
    So I told him, that without looking at the stack trace, we cannot find the cause.
    Then he said he doesn't know exactly but he knows(?) why it's happening.

    How un-engineerlike, unscientific is this?



  • Right, I wasn't referring to your case, just expounding upon Macie's reply.



  • Sorry I got confused over who you were referring to.



  • He's senile lead (as in Pb) dev, not senior lead (as in leader).



  • @rc4 said:

    I know nginx pads its default error pages with HTML comments that say something like <!-- workaround to prevent chrome and IE friendly error pages -->.

    What the fuck is wrong with open source people. WHY WOULD YOU DO THAT!

    "We're not going to make our own error pages actually friendly or useful in any way, but we WILL bypass a browser feature that attempts to do it on our behalf, because FUCK USERS!!! It's not enough that our product has shitty errors, we need to force the shitty errors on everybody else!"



  • No, you dumbass. It changes things from:

    "This page couldn't be displayed for some unknown reason. Sorry!"

    To:

    "This page couldn't be displayed because 404 File not found - here's helpful troubleshooting information."

    You fucking moron. They work around it because it's unhelpful, and the whole point of friendly errors is to replace blank pages with real error pages, but their previous error pages were so small that they got replaced by accident, you retarded fuck.



  • There is no way they are producing a friendly error message in HTML in less than 512 BYTES. It can't be done.

    If they don't like Chrome's version, the solution is to make a better version, not pointlessly disable it like a jackass.

    In any case, it's just plain WRONG for them to interfere with client software in that way. It's the browser's prerogative to render pages, putting in shit like that to SABOTAGE the browser is simply unacceptable.

    Not that anybody in open source gives a shit, as they have no concept of "usability" or "ethics" and as basically just a crowd of howling baboons who whom the entire concept of "professionalism" is alien.


  • area_deu

    The "Friendly error messages" is one of the biggest turds in the huge steaming pile of shit called Internet Explorer.

    :older_man: The site doesn't work!
    :man: Please send me a screenshot with a meaningful error message.
    :older_man: Okay, here you go:
    :shit: "The site doesn't work".
    :man: :headdesk:

    For added fun, if your App_offline.htm contains less than 512 bytes, IE will also show a "friendly message" instead of your beautifully handcrafted notice on why the application will be online again in a few minutes. So every time I do an update I now have to make sure to include a dozen lines of commented lorem ipsums.
    Defend THAT.

    TIL Chrome does this as well. Fuck you, Google.



  • @blakeyrat said:

    There is no way they are producing a friendly error message in HTML in less than 512 BYTES. It can't be done.

    Allow me:

    <html>
    <h1>404 - /home/index2.html was not found</h1>
    <address>nginx version 2.0 at test.com port 80</address>
    </html>
    

    Oh, shit, 118 bytes?!!!!!11111111111

    That tells me:

    1. The exact error that occurred
    2. The file that wasn't found
    3. The server that processed the request
    4. The protocol and port that the error occurred on

    Here's chrome's "friendly error":

    "Sorry, the page can't be displayed!"

    That tells me:

    1. There was an error

    @blakeyrat said:

    In any case, it's just plain WRONG for them to interfere with client software in that way. It's the browser's prerogative to render pages, putting in shit like that to SABOTAGE the browser is simply unacceptable.

    No, it's not. It's the server's prerogative to serve whatever content it wants.



  • @rc4 said:

    Oh, shit, 118 bytes?!!!!!11111111111

    What's friendly about that? It's gibberish to 99% of computer users.

    Look at that, I was complaining about an open source person not understanding usability and now we have a live demo of it. Congratulations! Now stop writing software forever!

    @rc4 said:

    No, it's not. It's the server's prerogative to serve whatever content it wants.

    Look, if they think Chrome's error messaging is bad, they have LOT of avenues to pursue, none of which is "bypass the browser feature by shoving bullshit on the end of their own error messages."

    For example, they could (gasp!) TALK TO the developers of Chrome and/or IE and find out the criteria for a good error message, then implement one. Or alternatively, try to convince those developers that their own error messages are sufficient and disable the feature.

    Talking to people!? But I R open sourrcezzz! I live in BASEMENT and write WEB SERVER!!! PEOPLE SCARE ME GASP!!!


  • area_deu

    @blakeyrat said:

    There is no way they are producing a friendly error message in HTML in less than 512 BYTES. It can't be done.

    <html><head><title>FUCK OFF TO BED</title></head>
    <body><p>The site is being updated and will be available again at 23:00 CET. 
    Sorry for the inconvenience.</p></body></html>
    


  • @blakeyrat said:

    Look at that, I was complaining about an open source person not understanding usability and now we have a live demo of it. Congratulations! Now stop writing software forever!

    Okay? And "The page couldn't be shown. Sorry!" In pretty text is somehow more usable by the end user?

    The point of error pages is to tell the admins and developers what went wrong, and to tell users that something went wrong. Friendly error pages are a :barrier: to debugging. Congratulations on being a complete and total idiot. Please skewer yourself on the space needle.



  • @rc4 said:

    Okay? And "The page couldn't be shown. Sorry!" In pretty text is somehow more usable by the end user?

    Did I say it was? No, I fucking didn't.

    Sorry, I can't have a debate with the little invisible elves in your head; they're like the Great Gazoo, only you can see them. Come back when you want to actually discuss things I've written.


  • area_deu

    @blakeyrat said:

    For example, they could (gasp!) TALK TO the developers of Chrome and/or IE

    :rofl:
    Have you ever tried to use Microsoft "Connect"?



  • @blakeyrat said:

    There is no way they are producing a friendly error message in HTML in less than 512 BYTES. It can't be done.

    "Friendly" doesn't imply "tons of buttons, tons of JS, tons of fancy CSS animation and an ad popup or two".


  • area_deu

    @blakeyrat said:

    find out the criteria for a good error message

    Apparently, the sole criterion is "longer than 512 bytes".

    then implement one.
    ``` html <!-- Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua. At vero eos et accusam et justo duo dolores et ea rebum. Stet clita kasd gubergren, no sea takimata sanctus est Lorem ipsum dolor sit amet. Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua. At vero eos et accusam et justo duo dolores et ea rebum. Ste --> ```


  • @blakeyrat said:

    Did I say it was? No, I fucking didn't.

    @blakeyrat said:

    What's friendly about that? It's gibberish to 99% of computer users.

    Look at that, I was complaining about an open source person not understanding usability and now we have a live demo of it. Congratulations! Now stop writing software forever!

    You're not even trying now.


  • area_deu

    FWIW, I don't do open source :smile:



  • @ChrisH said:

    Apparently, the sole criterion is "longer than 512 bytes".

    IIRC, that's 512 bytes of data in the HTTP body, so gzipping can take you down below 512 bytes.


  • I survived the hour long Uno hand

    Seriously? This is like, webpages 101 crap.

    The end user doesn't give a flying fuck what went wrong with your server. You do, and you have access to all kinds of monitoring and logging tools. So put the information there, and display something friendly to the user.


  • area_deu

    Oh well, then next time it'll have to be a bunch of GUIDs or tub girl in base64 or something.



  • @ChrisH said:

    Have you ever tried to use Microsoft "Connect"?

    If the developers of the 2nd or 3rd most popular web server don't have any contacts whatsoever on the development staff of the 1st and 2nd most popular web browsers, than they're way more incompetent than I assumed.

    @Gaska said:

    "Friendly" doesn't imply "tons of buttons, tons of JS, tons of fancy CSS animation and an ad popup or two".

    I didn't say it did.

    @ChrisH said:

    Apparently, the sole criterion is "longer than 512 bytes".

    No it's not; that's a proxy.

    Look, what we have here is a people problem. Chrome/IE think a quality error message consists of X, and nginx thinks it consists of Y. You can't solve people problems with HTML comments; you can only solve them by getting those people together to talk-out the problem.

    If nginx wants to solve the problem instead of just installing a band-aid that wastes everybody's bandwidth, they need to sit down and talk to the developers of Chrome and IE, find out why that feature was implemented in the first place (it didn't just spring into existence-- someone built it for some good reason) and determine what needs to be done to make the web browsing experience better for everybody.

    "What needs to be done" might be getting Chrome and IE to recognize the rule is outdated or no longer applies and therefore remove it. It might be Chrome and IE delivering some guidelines about what they think quality error messages look like and nginx implementing them. I don't know what the solution is; neither does anybody else until the parties get together and talk it out.

    Again: this is called "professionalism". And will never happen, because it doesn't exist in the open source world.

    @ChrisH said:

    Oh well, then next time it'll have to be a bunch of GUIDs or tub girl in base64 or something.

    You sure you don't do open source? Because that's the exact kind of thing an open source developers would do.

    Why not pad it out with "NAUGHTY PROGRAMMER SPANK SPANK. BITCH!" while you're at it.


  • Discourse touched me in a no-no place

    @blakeyrat said:

    because FUCK USERS!!! It's not enough that our product has shitty errors, we need to force the shitty errors on everybody else!

    @open source people said:

    Shit! He's onto us :cold_sweat:

    <!-- workaround to prevent shitty Discourse behaviour, i.e. this post is not empty Jeff you cunt! -->


  • @blakeyrat said:

    I didn't say it did.

    You said that it has to be over 512 bytes to be friendly. 512 characters is plenty of space to say "file not found" or "our servers are overloaded; please come back in 5 minutes"; the only way to exhaust it is to put way too much debug info, or way too much fluff.

    @blakeyrat said:

    No it's not; that's a proxy.

    Well, it's the actual criterion used by IE, at least up to version 6.



  • Why are people complaining about adding padding server-side when Microsoft explicitly offer that as a solution to not showing "Friendly Error Messages"?

    https://support.microsoft.com/en-us/kb/294807



  • @Gaska said:

    512 characters is plenty of space to say "file not found"

    Yes, but that's also not friendly you dumb fucker I've decided just now I will no longer reply to ever.

    @Gaska said:

    Well, it's the actual criterion used by IE, at least up to version 6.

    Here's a tip, dumbshit: LOOK UP THE WORD "PROXY" IN A DICTIONARY.



  • @blakeyrat said:

    Yes, but that's also not friendly

    Why? Because it has no fluff?

    @blakeyrat said:

    you dumb fucker I've decided just now I will no longer reply to ever.

    We'll see.

    @blakeyrat said:

    Here's a tip, dumbshit: LOOK UP THE WORD "PROXY" IN A DICTIONARY.

    noun, plural proxies.

    1. the agency, function, or power of a person authorized to act as the deputy or substitute for another.
    2. the person so authorized; substitute; agent.
    3. a written authorization empowering another person to vote or act for the signer, as at a meeting of stockholders.
    4. an ally or confederate who can be relied upon to speak or act in one's behalf.

  • area_deu

    @Yamikuronue said:

    The end user doesn't give a flying fuck what went wrong with your server. You do, and you have access to all kinds of monitoring and logging tools.

    We have special :snowflake: customers running our applications on their servers. With no way to access them or the logs without jumping though a million hoops. And their admins are so incompetent that a SQL Server message "couldn't grow database log, disk is full" spewn in the face of the users is the only way to get them to do something about their storage.

    For public facing web sites etc., I'm with you. Although I like to include SOME clue what technically happened so I can see it from a screwithout digging through the logs.



  • @Gaska said:

    512 characters is plenty of space to say "file not found" or "our servers are overloaded; please come back in 5 minutes"

    Which is, incidentall, not what nginx does at all. Instead all it does is bark "504 Gateway Timeout", and you go figure what that means (what's the gateway? Is it like the router? Does that mean I need to fix the router?)

    At least the friendly page includes a bunch of things you can try, and Chrome's implementation will to some extent adapt the troubleshooting steps to the status code. Nginx? Nope, you get a cryptic error message and a note that the server is powered by nginx, because of course that's what's important to the user.


  • area_deu

    @blakeyrat said:

    You sure you don't do open source?

    (Looks at paycheck)
    Yes.

    Why not pad it out with "NAUGHTY PROGRAMMER SPANK SPANK. BITCH!" while you're at it.
    Feel free to mentally insert :trolleybus: and :wink: emojis as needed. Of course I wouldn't do that.


  • You used the word FUCK therefore it's not friendly :trolleybus:


  • area_deu

    @JazzyJosh said:

    You used the word FUCK therefore it's not friendly :trolleybus:

    Fuck! You're right.


  • I survived the hour long Uno hand

    This is pretty much what I was going to rebut @ChrisH with: nginx's default "I blew up" page can't possibly assume it's someplace technical vs public facing. Better to have the sensible default assume it needs a user-friendly response, and then have it be overridable for those edge cases.



  • @Maciejasjmj said:

    Which is, incidentall, not what nginx does at all. Instead all it does is bark "504 Gateway Timeout", and you go figure what that means (what's the gateway? Is it like the router? Does that mean I need to fix the router?)

    I never said nginx isn't dumb shit with useless features. I just said that Chrome and IE are dumb shit with useless features too.

    @Maciejasjmj said:

    At least the friendly page includes a bunch of things you can try

    None of which work. Yes, I did go through every single bullet on the list that IE spew when it encountered error. Several times. This was back when I was 5, and this is how I first learned to ignore walls of text and tips coming from the software itself.



  • @Yamikuronue said:

    Five Fresh Approaches to 500 Server Error Pages

    You Won't Believe The One Simple Trick This Web Developer Used To Make 500 Server Error Pages Vanish Overnight. What Happens Next Will Make You Applaud.



  • That's if you disable some things (otherwise it spits out more info), plus for 504 errors, what do you want nginx to do? it's just a proxy. Do you want it to go ssh into the server and figure out what happened for you?



  • @rc4 said:

    plus for 504 errors, what do you want nginx to do?

    At the very least, let the user know they can't do shit about it, unlike a 4xx error, where you can do shit about it.


  • SockDev

    In all seriousness, how many users would be able to fix the cause of most of these:



  • Some versions of the error pages will provide that description, but I still think 504 is better than "Sorry!". At least I know the exact error that happened and what I need to do to fix it (or that I can't fix it).



  • @RaceProUK said:

    In all seriousness, how many users would be able to fix the cause of most of these:

    401 (you dun goofed up the password), 403 (get yourself a higher clearance level), 404/410 (you either typoed the URL or we took this down, in either case don't keep trying), 429 (please chill the fuck out)...

    Either way, you get at least two categories - user error (where it's rather important to let the user know what they're doing won't work ever) and programming/temporal errors (where it might work later). The latter category can also be separated into "please poke the admins about it" and "just wait it out", though a well-managed site would probably have some error reporting facilities by itself.

    And either way, barking out a HTTP code by itself is terrible design. That's why the friendly error pages are called friendly - in most cases, a sub-512B page will be exactly that, a HTTP code with no other information for the user, and it's on the browser to provide those.



  • @rc4 said:

    but I still think 504 is better than "Sorry!"

    504 OK



  • At least I know what a 504 is. Nobody knows what "Sorry!" means other than something bad happened. Which is totally unhelpful.

    Also, Discourse is :doing_it_wrong: with error messages. Surprise...


  • I survived the hour long Uno hand

    @rc4 said:

    At least I know the exact error that happened and what I need to do to fix it (or that I can't fix it).

    What you need to know when a site not under your control throws a 5xx:

    • Something went wrong
    • It's not something you can fix
    • (Optionally) here's how to contact tech support

    504 vs 500 vs 502 vs 510 doesn't actually matter if you don't control the server. And if you do, you have other ways of finding out which it was. We techies often like to know what exactly happened, but it's honestly none of our business.

    The one major exception is a 511, and it's still a much better UX for the browser to intercept that and treat it like a redirect.



  • @rc4 said:

    At least I know what a 504 is. Nobody knows what "Sorry!" means other than something bad happened. Which is totally unhelpful.

    Also, Discourse is :doing_it_wrong: with error messages. Surprise...

    502 OK



  • @Yamikuronue said:

    We techies often like to know what exactly happened, but it's honestly none of our business.

    Except for when it is, and when it's my server.

    And it's no skin off anyone's nose to show that to me. If the server admin is concerned about it, they can easily turn off those errors. If they don't care, the browser should not be an impediment to me knowing that, since it could be my server, or it could be my friend's server. Hell, it could even be that I typed something stupid into a server with no input sanitization and I need to fix my input, in which case, it is helpful to know the error!


  • I survived the hour long Uno hand

    I'm going to let you in on a little secret, kid: There's a magic button on your keyboard labelled "F12". If you press that, you can get all kinds of top sekret l33t hacker information about a server, including the headers and response code it served up.

    But no, it really isn't any of your business unless it's your server. Your friend can handle his own server maintenance. So can Facebook, or Walmart, or the mom and pop shop down the street who didn't pay their hosting bill this month. If you input something during normal usage that threw a 5xx error server-side, it's on them to find it in their logs or monitoring and fix the bug.

    For every nosy nancy like you or me that wants to know exactly what went wrong and itches to fix it, there's at least 100 grandmas who have no use for the information and would actively be alarmed by it.



  • Okay, but now it's my server. And I don't want friendly errors, EVER. I love bad UX. I hate users, and I want all of my users to die and my company to fail. Now what?


Log in to reply
 

Looks like your connection to What the Daily WTF? was lost, please wait while we try to reconnect.