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

121–124 of 124 posts

Re: Reserve the 418 status code

#121

Post by grandalf »

Sleeep wrote: post #114
eric_b wrote: post #100

Earlier quoted context omitted.

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?

By that logic nearly all errors are formatting errors.

Re: Reserve the 418 status code

#122

Post by quuquuquu »

peterwwillis wrote: post #77
quuquuquu wrote: post #57

Earlier quoted context omitted.

As frivolous as you think 418 is, people use it. You honestly can't, in this situation, be the judge of what is "frivolous use" and what is not.

It's literally an error designed to tell a client that an operation occurred on a teapot and not a coffee machine. It is the definition of frivolous.

I appreciate your view point.

Olive oil was used as lantern fuel before it was ingested.

Some swear by it, some want it banned.

Only the user can judge!

Re: Reserve the 418 status code

#124

Post by marrs »

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…

Transport layer to me means TCP/IP. HTTP sits above that, in the application domain. If a user sends an invalid request then the response should be in the 400 band. If the server failed in some way to deal with the request (e.g. the database is unavailable), then the response should be in the 500 band.

I would typically decide what my response code should be depending on what I think the response should be.

If a user tries to register a new account then a successful outcome would probably be a new user resource. If the user tries to register a username that already exists, I'd also probably go with 409 Conflict as the user is trying to create a resource that already exists.

Post reply on HN