Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Reserve the 418 status code

tools.ietf.org

Post reply on HN
Print view View original

111–120 of 124 posts

Re: Reserve the 418 status code

#111

Post by nulagrithom »

grandalf wrote: post #109
nulagrithom wrote: post #92

Earlier quoted context omitted.

I'd go with 409 Conflict, but I'd also accept 400 Bad Request Incidentally, the RFC for 409 makes it quite clear that this touches the application layer: > Conflicts are most likely to occur in response to a PUT request. For example, if versioning were being used and the representation being PUT included changes to a resource that conflict with those made by an earlier (third-party) request, the origin server might u…

Versioning a resource, per WebDAV is a very specific application. > using 200 OK for everything that didn't fail at the transport layer is a super frustrating experience regardless of whether or not it's semantically correct The semantics of my application's protocol do not necessarily mirror the semantics of HTTP, nor are the descriptive statuses semantically similar, since most HTTP statuses are simply about transp…

There's no mention of WebDAV in that RFC.

Would it kill you to send back a 400 status code upon an error? Having to check for { isError: true } or something similar is obnoxious. I don't see the value gain of responding 200 OK when the operation was not successful.

Re: Reserve the 418 status code

#112

Post by robotmay »

steveklabnik wrote: post #110
robotmay wrote: post #60

Earlier quoted context omitted.

Honestly the main reason it works like this is that it was my first foray into Rust, and I found JSON parsing a bit of a pain, whereas matching status codes was very simple. If we expand it to return different options in the future then I'll probably rework it.

Interesting, if you happen to have some time, I'd love to hear about why parsing JSON was a pain.

Laziness :D

I think I was having trouble with string lifecycles due to how I was doing something, and at the time I didn't understand them (I'm still not super sharp on it if I'm honest) and just opted to take an easy way out. Lifecycle notation might be the one bit of Rust I find ugly, actually.

I should really revisit this little program at some point, but it's so stupidly simple and works so reliably that I haven't had the inclination to yet.

Re: Reserve the 418 status code

#113

Post by Sleeep »

grandalf wrote: post #75
akvadrako wrote: post #72

Earlier quoted context omitted.

> Suppose you make a call to an API and it returns 5xx because you provided a parameter value that is valid in the URL or payload but invalid in the app That is wrong. Client mistakes should get 400-level error codes. A 200-level code indicates the request completed successfully, which it didn't. There is no difference between an "HTTP server" and an app. They are often the same thing, like when using Apache to serve…

> Don't return a 200 code when the request failed. The request didn't fail, it simply followed application logic and returned a successful response indicating the nature of the application logic to the client. That is not an error condition, it's just application logic.

Every web server I've ever used returns a 500 server error when the transport succeeds but it encounters an exception in application level code. Are you really proposing that's incorrect behavior? I also can't imaging a use for 403 Forbidden and 401 Unauthorized that isn't "application level" logic.

If you think about it pretty much 99% of requests the server receives could be correct if the "application logic" was implemented differently. You can't really decouple the two in any meaningful way.

If you want to return 200 OK status codes all day when why are you using HTTP in the first place?

(Also, HTTP is an application protocol)

Re: Reserve the 418 status code

#114

Post by Sleeep »

eric_b wrote: post #100
caseysoftware wrote: post #94

Earlier quoted context omitted.

No. You should never, ever, ever return a 2xx status code with an error payload. The 2xx series means "Success" and you're abusing HTTP to use it to mean anything else. With regard to application layer vs transport layer, the 404 Not Found, 406 Not Acceptable, 409 Conflict, and many others errors are specifically application layer codes. If you can't get a more specific code, 400 Bad Request with an expressive payloa…

Uh what? If the request was appropriately formatted, not too large, and generally acceptable to the server from a transport perspective, why shouldn't it succeed with a 200? Error handling is an application level concern, not a transport level concern. HTTP status codes lack the nuance required to inform the end user about errors in any non-trivial application. I personally enjoy the OP's solution. I've worked on doz…

>appropriately formatted

If the server is expecting data that it doesn't receive (because the form field was left blank) then can you really consider the request "appropriately formatted"? Is it in any way meaningfully different from the case where the server receives a request on /api/invalid-url/ and doesn't have a corresponding resource on its end?

Re: Reserve the 418 status code

#115

Post by steveklabnik »

robotmay wrote: post #112
steveklabnik wrote: post #110

Earlier quoted context omitted.

Interesting, if you happen to have some time, I'd love to hear about why parsing JSON was a pain.

Laziness :D I think I was having trouble with string lifecycles due to how I was doing something, and at the time I didn't understand them (I'm still not super sharp on it if I'm honest) and just opted to take an easy way out. Lifecycle notation might be the one bit of Rust I find ugly, actually. I should really revisit this little program at some point, but it's so stupidly simple and works so reliably that I haven'…

Gotcha!

FWIW, serde_json makes it very easy; if you were doing it yourself, I can see how it'd be harder :)

The second edition of the book's ownership and borrowing chapters go into String vs &str in great detail, if you want to become super sharp :)

(and yeah, we agree that the lifetime annotation isn't very nice looking, but every alternative we tried looked worse.)

Re: Reserve the 418 status code

#116

Post by robotmay »

steveklabnik wrote: post #115
robotmay wrote: post #112

Earlier quoted context omitted.

Laziness :D I think I was having trouble with string lifecycles due to how I was doing something, and at the time I didn't understand them (I'm still not super sharp on it if I'm honest) and just opted to take an easy way out. Lifecycle notation might be the one bit of Rust I find ugly, actually. I should really revisit this little program at some point, but it's so stupidly simple and works so reliably that I haven'…

Gotcha! FWIW, serde_json makes it very easy; if you were doing it yourself, I can see how it'd be harder :) The second edition of the book's ownership and borrowing chapters go into String vs &str in great detail, if you want to become super sharp :) (and yeah, we agree that the lifetime annotation isn't very nice looking, but every alternative we tried looked worse.)

Awesome, thanks for the tips Steve :D Hopefully we'll have a few other projects coming up that I can use as an excuse to do more Rust!

Re: Reserve the 418 status code

#117

Post by LukeShu »

mystrman111 wrote: post #38
LukeShu wrote: post #32

Earlier quoted context omitted.

Often reddit threads read more respectful after-the-fact; the less respectful comments either get downvoted enough that they aren't displayed unless you look for them, or are moderated away. Often they are much harsher early in the thread. I'm not sure if that ways the case here, but it is common enough that I wouldn't doubt it.

When comments are removed by mods on Reddit, they're replaced with the text "[REMOVED]", which doesn't appear once in the referenced thread (insults would not be removed in the first place though, they break no /r/webdev rules). And you can scroll to the bottom of the thread to see all the downvoted comments, none of which are are condescending towards Mark. So no, that isn't the case here.

In the default sort mode ("best"), sufficiently downvoted comments won't be displayed at all, even if you do scroll all the way to the bottom.

Re: Reserve the 418 status code

#118

Post by grandalf »

nulagrithom wrote: post #111
grandalf wrote: post #109

Earlier quoted context omitted.

Versioning a resource, per WebDAV is a very specific application. > using 200 OK for everything that didn't fail at the transport layer is a super frustrating experience regardless of whether or not it's semantically correct The semantics of my application's protocol do not necessarily mirror the semantics of HTTP, nor are the descriptive statuses semantically similar, since most HTTP statuses are simply about transp…

There's no mention of WebDAV in that RFC. Would it kill you to send back a 400 status code upon an error? Having to check for { isError: true } or something similar is obnoxious. I don't see the value gain of responding 200 OK when the operation was not successful.

> when the operation was not successful.

Well, do you care about all the successful and unsuccessful aspects of TCP that underlie the connection? No, you just care that it was successful, allowing the HTTP request. Assuming that is successful, then your API "operation" can occur and return its result.

Re: Reserve the 418 status code

#119

Post by grandalf »

vfaronov wrote: post #91
grandalf wrote: post #90

Earlier quoted context omitted.

There will be cases where an HTTP status code matches perfectly with an application specific scenario, and in those cases using an HTTP status code is not confusing. The confusion comes when the API developer tries to shoehorn all application specific errors into pre-existing HTTP status codes. In most cases it is clearer to simply adopt a payload format that includes application specific error codes, so that the cla…

> In most cases it is clearer to simply adopt a payload format that includes application specific error codes Absolutely. This is a common practice and there’s even a proposed standard for it (RFC 7807). But such a payload need not be sent with 200 (OK). It can refine the status code instead of overriding it.

> It can refine the status code instead of overriding it.

True, this is sometimes possible when (coincidentally) one of the HTTP specs or extensions defines one of the codes in a way that feels similar enough.

The mistake is to assume that there is already a code for everything and that one does not need to define application specific error codes, which is what many API developers do.

Re: Reserve the 418 status code

#120

Post by throwahey »

jacquesm wrote: post #35
HappyTypist wrote: post #31

Earlier quoted context omitted.

Nope. Actually, there was a paper published recently on using a phone's gyro / accelerometer (through the HTML5 APIs) in order to keylog users; because the API is precise enough for you to detect subtle motion of the phone as you press on the software keyboard. Apparently in some mobile browsers, you can continue to poll the API even when your tab is not on focus.

Oh, that's really nice. So if you have a fix (and even if you don't) you can use dead reckoning and tie any points where the GPS is accessible and then re-create the path the phone took. That's a bit of a leak. Wonder how long after or before a GPS fix this would be effective, those phone accelerometers probably aren't all that accurate but you might be able to calibrate the one in a specific phone if you have data a…

More proof that Javascript and HTML5 are cancer for privacy on the internet
Post reply on HN