• Meep (unregistered) in reply to faoileag
    faoileag:
    [+1] for the complete absence of unnecessary embellishment in the story.

    [+1] for making the effort of explaining that Ruby on Rails code snippet.

    And another [+1] for the fact that the explanation is good enough so that someone not familiar with Ruby on Rails can understand the code and the wtfs presented in the article.

    Yeah, the story was not TRWTF, nor is Fails.

    What's TRWTF is that this code is following the convention, as established by 99% of web devs, to return HTTP error codes based on however the guy who wrote the code they copied and pasted did it.

  • gnasher729 (unregistered) in reply to noland

    [quote user="noland"][quote user="Tyler"]In case you want to distinguish this from the other 404-case: What about 406 "Not Acceptable"?[/quote] 406 should be returned if the client told the server which formats it accepts, and the response that the server wants to return doesn't fit those formats. For example, if the client requested response with a charset that the server doesn't support, or with a mime type that the server doesn't support.

    The "Not acceptable" refers to the client. The server could give a reply, but the reply wouldn't be acceptable to the client.

    But really, anyone writing this kind of code should learn about what they are doing (entering "error 406" into Google is all you need), and think about what a client would do depending on the error code. If I write client code and get an error 406, I'd send an "Accept: /" header and then be very confused if it still doesn't work.

  • Dr. Ruby Fails (unregistered)

    Ruby on Rails blows. Plain and simple. Most RoR programmers are hacks that couldn't code their way out of a wet paper bag.

  • Dumb Knut (unregistered) in reply to cellocgw
    cellocgw:
    Rasmus:
    Error 418 is the most appropriate error code for all situations.

    And yet the most stolen Colorado Road Mile Marker is 420. (for obvious but rather different reasons...)

    tho' one wonders whether a bunch of nerds wouldn't steal the 404 mile marker, which then, of course would be in a tautological situation!

    Spring Method Failure?

  • JAiwo erg; (unregistered) in reply to Dr. Ruby Fails
    Dr. Ruby Fails:
    Ruby on Rails blows. Plain and simple. Most RoR programmers are hacks that couldn't code their way out of a wet paper bag.
    That could only be written by someone who doesn't understand Ruby, can't use it, and therefore assumes it's somehow below him (or her)
  • bambam (unregistered) in reply to Smug Unix User
    Smug Unix User:
    These types of articles were the reason I came to this site.
    But now you come for the Hanzo articles.
  • Spewin Coffee (unregistered)

    TRWTF is not indenting code.

  • noland (unregistered) in reply to gnasher729
    gnasher729:
    noland:
    In case you want to distinguish this from the other 404-case: What about 406 "Not Acceptable"?
    406 should be returned if the client told the server which formats it accepts, and the response that the server wants to return doesn't fit those formats. For example, if the client requested response with a charset that the server doesn't support, or with a mime type that the server doesn't support.

    The "Not acceptable" refers to the client. The server could give a reply, but the reply wouldn't be acceptable to the client.

    But really, anyone writing this kind of code should learn about what they are doing (entering "error 406" into Google is all you need), and think about what a client would do depending on the error code. If I write client code and get an error 406, I'd send an "Accept: /" header and then be very confused if it still doesn't work.

    This was just a suggestion for another misuse of status codes ;-) In fact, if you're using a path-like resource address, there's only 404 left as a valid option (imagine the user-id as a directory and it's quite clear that it's an address fault).

  • noland (unregistered) in reply to gnasher729
    gnasher729:
    noland:
    In case you want to distinguish this from the other 404-case: What about 406 "Not Acceptable"?
    But really, anyone writing this kind of code should learn about what they are doing (entering "error 406" into Google is all you need), and think about what a client would do depending on the error code. If I write client code and get an error 406, I'd send an "Accept: */*" header and then be very confused if it still doesn't work.
    The point I was trying to make was: Do not misuse any protocol-based semantics for your own. Not at any rate.

    Do not return "oops, my service broke down, retry later" (500), if a parameter was empty.

    Do not return "please supply a valid HTTP-user" (401), if your request for "http://example.com/users/user1/unique" doesn't match with an ID "user1" in your DB, but you would have a valid ID "user2" and would accept "http://user2:@example.com/users/user1/unique" as a valid request.

    Rather return a JSON object (or alike) with your own status-property. Suggesting 406 was just another example in goofiness.

  • (cs) in reply to HardwareGeek
    HardwareGeek:
    chubertdev:
    Thank you. I am sure I am not the only one to whom the reference to 420 was very much not obvious.

    [Citation needed]

    (hey! that works on more than one level!)

  • Norman Diamond (unregistered) in reply to faoileag
    faoileag:
    faoileag:
    That's Akismet for you. Hoping...
    Oh, ok. Akismet allows a link to itself.
    It has to. In order to let spammers of fake passports post comment spams while blocking legitimate posts, it has to get itself into web sites, so it serves itself by letting metaspammers of fake spam tools post comment metaspams while blocking legitimate metaposts.
  • Error 316 (unregistered)

    Convention, configuration, it don't matter one bit to me son. All you need to know is that Error 316 says I just whooped your ass.

  • Jeff Grigg (unregistered)

    Actually, returning error numbers when things go wrong and data when things work fine is just a convention. You don't really have to do things that way.

    ;->

  • eros (unregistered) in reply to faoileag
    faoileag:
    [+1] for the complete absence of unnecessary embellishment in the story.

    [+1] for making the effort of explaining that Ruby on Rails code snippet.

    And another [+1] for the fact that the explanation is good enough so that someone not familiar with Ruby on Rails can understand the code and the wtfs presented in the article.

    I'll throw in a -1 since the author treats Ruby and Ruby on Rails as synonyms. Every instance of 'Ruby' after the string 'local Ruby expert' should be replaced with 'Rails'.

    But I did enjoy the explanation.

  • (cs)

    Conventions should only be used if they happen to be in Vegas and are looking for a good time. Otherwise, let the intern deal with it.

  • (cs) in reply to Damien
    Damien:
    article:
    A 400 - Bad Request is more appropriate.

    Except request.format is presumably derived from the Accept headers, in which case 406 is more more appropriate.

    +1

    It amazes me how people who work with a particular protocol every day aren't even familiar with it's basic standards.

  • (cs) in reply to Tyler
    Tyler:
    15 comments no defense yet? I'll give it a shot (keeping in mind I have never read Ruby or similar looking language before).
    1. Request.format != application/json return unauthorized. Makes perfect sense, if this particular module is reached by some method other than the expected interface, the user is "url hacking" and should be denied. A 400 would be more appropriate if an impossible email address/username had been provided and the script was setup to detect this.

    2. the note on :id struck me as odd for a language, quick google gives a stackoverflow msg with hammar posting that :id would correspond to user_name in the /users/unique/user_name path. Anyone want to give the doc?

    3. 404 means "not found". 404 Not Found The requested resource could not be found but may be available again in the future

    The resource was in fact found so 404 is inappropriate, 500, internal error is more appropriate when you take into account that this is supposed to be referenced only by an application. Quick google says 420/449 may be more appropriate for detail but 500 should be sufficient.

    1. You clearly don't know what "authorization" means.

    2. You don't know what "resource" means, either. It refers to the user object, not the Ruby function that handles it.

  • YellowOnline (unregistered) in reply to steenbergh
    $Quote = @{
    faoileag:
    [+1] for the complete absence of unnecessary embellishment in the story. [+1] for making the effort of explaining that Ruby on Rails code snippet. And another [+1] for the fact that the explanation is good enough so that someone not familiar with Ruby on Rails can understand the code and the wtfs presented in the article.
    }@ $i = 0 Do {$Quote; $i++} Until ($i -EQ -1)
  • Paul M (unregistered)

    If you don't like the content type, I believe the correct code is 406. Returning a 401 when the content type is not json would mean "you have asked for a word document, but before I can do anything for you I need you to log in".

  • (cs) in reply to savar
    savar:
    +1

    It amazes me how people who work with a particular protocol every day aren't even familiar with it's basic standards.

    Such as its/it's?

  • lolwtfbbq (unregistered) in reply to chubertdev

    Replying to [Citation needed] with a wikipedia link just might make the internet explode, but let's give it a go.

    http://en.wikipedia.org/wiki/420_%28cannabis_culture%29

    420, 4:20, or 4/20 (pronounced four-twenty) is a code-term used primarily in North America that refers to the consumption of cannabis and by extension, as a way to identify oneself with cannabis subculture or simply cannabis itself.

    Origins

    A widely discussed story says that a group of teenagers in San Rafael, California, calling themselves the Waldos, because, "their chosen hang-out spot was a wall outside the school", used the term in connection with a fall 1971 plan to search for an abandoned cannabis crop that they had learned about. The Waldos designated the Louis Pasteur statue on the grounds of San Rafael High School as their meeting place, and 4:20 p.m. as their meeting time.

  • (cs) in reply to lolwtfbbq
    lolwtfbbq:
    Replying to [Citation needed] with a wikipedia link just might make the internet explode, but let's give it a go.

    http://en.wikipedia.org/wiki/420_%28cannabis_culture%29

    420, 4:20, or 4/20 (pronounced four-twenty) is a code-term used primarily in North America that refers to the consumption of cannabis and by extension, as a way to identify oneself with cannabis subculture or simply cannabis itself.

    Origins

    A widely discussed story says that a group of teenagers in San Rafael, California, calling themselves the Waldos, because, "their chosen hang-out spot was a wall outside the school", used the term in connection with a fall 1971 plan to search for an abandoned cannabis crop that they had learned about. The Waldos designated the Louis Pasteur statue on the grounds of San Rafael High School as their meeting place, and 4:20 p.m. as their meeting time.

    You misunderstood my comment. I was saying that in reference to the fact that I wanted to back up what was said about the sign post with an article showing that it did indeed happen in Colorado.

  • Bill C. (unregistered)

    It happened in Washington.

    It's even written in the Bible: Adulterers should be stoned.

  • Neil (unregistered)

    Since 500 isn't an application error, I was going to suggest that it should be an error for the application to attempt to return a 500 error, but I'm worried that the correct error for the server to return for "application erroneously attempting to return 500 error" is 500...

Leave a comment on “Just Because It's Ruby, Doesn't Mean It's a Gem”

Log In or post as a guest

Replying to comment #:

« Return to Article