• (nodebb)

    you'll be shocked to learn that the JavaScript client-side code depended on this returning a 500 for its own error handling.

    No, not at all. I'd be disappointed, sure, but not shocked.

  • (nodebb)

    Yeah, people seem to have really, really picks when it comes to HTTP Status codes; the amount of badly used ones still surprises me. Usually the context ranges are ignored and some devs just pick a random one sounding right. So you end up with server-errors that are reported as client errors and the other way around or 200er messages are not treated as success but only 200 OK specifically. Kinda odd honestly, it's not like it's the most complex issue a backend developer faces on a daily routine.

  • Hanzito (unregistered)

    It's not complex, but it's also not a problem: HTTP status codes don't mean much. Redirect, that's a real one, but the rest? Detail for the heck of it. It might just as well be ok, error and page_not_found.

  • (nodebb)

    Not only the status codes are got wrong, also the URL schema is a mess. /users/unique/email - that should return email addresses, the other one should return user names. But why is "unique" in the path? That would imply that there are other email addresses and user names which are NOT unique.

  • (nodebb)

    I am shocked, SHOCKED.

  • Brian (unregistered)

    I have to deal with this occasionally from no less than AWS. Using the API Gateway, sometimes a client request will return a 403, which then leads us down the path of troubleshooting the authorization - did you use the right login, do we have the right role on our lambda, is there something broken in our auth module, etc. Nope, most of the time the client just had an incorrect URL, which in a sane world would return 404.

  • (nodebb)

    I like herring, but it should be "under a fur coat" and not be the red one.

  • (nodebb)

    If you're using status codes for application-level status, you can essentially choose your own meanings. Yeah, you may get some confusion if the server really does screw up and returns a 500 code.

    Of course, if we're returning JSON, we could just put the status in the JSON object, there's no need to overload the HTTP status codes for this.

  • Sauron (unregistered)

    I totally agree, many devs (and sometimes clever and experienced ones, not just noobs or stupid people) don't use HTTP status code that well.

    Other basic concepts of the web (like having a proper routing rather than god-routes, referencing resources by URLs rather than ecoding any arbitrary file format as a base64 string and serializing that in a JSON, having a reasonable database structure, etc) are also less understood than they should (or well-understood by too neglected).

    But is it the devs' fault in the end? Yes and no. Even when the devs are good, society values money (specifically money made in the short term), companies are slave to money, so money decides, independently of what sanity, rational logic or even physical reality say.

    Reality always wins in the end (even if it takes a long time), the big question is always how much damage gets caused by madness before the ultimate outcome.

  • ZZartin (unregistered)

    And this is why it's better if developers don't play games http response codes and leave them at the protocol level.

  • WTFGuy (unregistered)

    @Brian ref

    Nope, most of the time the client just had an incorrect URL, which in a sane world would return 404.

    No, no, no! The security "best practices" audit team demands that there be no information disclosure. Telling an attacker that endpoint /blah/blah/blah/abc123 doesn't exist is a vulnerability. Just return 403 for all errors of any kind.

  • Your Name (unregistered) in reply to ZZartin

    This, this, and so much this. Do NOT mix transport with transported content.

  • guest (unregistered) in reply to Brian
    Comment held for moderation.
  • Grvs (unregistered)
    Comment held for moderation.
  • (nodebb)

    Well someone recently posted a link to a RFC for standardized error info in webmethods...

    https://datatracker.ietf.org/doc/html/rfc7807

  • (nodebb)

    I've had recently to deal with a service that works return 200 for everything and then one would have to parse the JSON for an "error". 0 meant ok, 1 was the generic error for an invalid request, and >1 was for any cryptic internal error they decided needed more details, on some arguably critic rationale.

    Much later I found out the numbers matched a Java enum.

    Seriously, at least a 400 would have been nicer.

  • (nodebb)

    in these Rails routes, the method name is the last portion of the URL- it should be /users/user_name/unique?value=foo.

    I have a feeling the rail route really is /user/unique/{id}?value={value}

    So really the method name is really "unique" and one of the query params just happens to look like a segment because having 2 query params probably didn't look as "fluent", i.e. "cool".

Leave a comment on “Status Games”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article