Hacker News Reader

Comment by Typhon | Hacker News Reader

This seems yet another example of web professionals not understanding HTTP.

Much like webpages that say "404 not found" with a "200 OK" header.

In their defense that is probably the case of their MVC framework or CMS returning a 200 after not being able to match the route and not really them doing it on purpose.

But yeah, I agree- (though I've missed them I'm sure) I pretty voraciously make sure my HTTP status matches my intended response- and sometimes that means you've got to write the code in the controller that tells the request to specifically return a certain status.

That just pushes "web professionals not understanding HTTP" one level down the stack, except this "web professional" is not the user doing the clicky, but whoever made the framework; the problem remains unchanged.

Sometimes it's a disagreement over what it's reasonable to expect from a framework user. Framework developers expect the users to read their docs and use their API only the way that's documented. Users expect any given API method to do what it says.

I would say this falls under web professionals not understanding their framework, which is at least as common a problem as not understanding HTTP.

Heck, it might even be more common. Especially when you talk about huge frameworks like Spring for Java. Also, with CMSes like Wordpress I imagine you can't really change the status that easily if it's not returning what you'd expect. I'm not saying a WP 404 page DOESN'T return 404, but if it returned 200, how far would you have to dig to change that? If my CMS wasn't doing it exactly right, I would probably just shrug and move on unless it was critically important to something I was writing against it.

Is the status line technically a header?

No.

Request (section 5) and Response (section 6) messages use the generic message format of RFC 822 [9] for transferring entities (the payload of the message). Both types of message consist of a start-line, zero or more header fields (also known as "headers"), an empty line (i.e., a line with nothing preceding the CRLF) indicating the end of the header fields, and possibly a message-body.

/quote RFC2616 (So, the status line is an entity of its own, which is followed by headers.)

That's what I thought.

Stupid protocol decisions are still stupid protocol decisions no matter how much you condescendingly try and blame the user.

Nope. "200 Not Found" or "404 OK" are stupid implementations, no matter how much you condescendingly try and blame the protocol.

What's stupid about differentiating between errors and success?

Reply on news.ycombinator.com