[intarweb] [PATCH] Full list of HTTP status codes

[RvdH]

I took the liberty of creating a patch for the HTTP status codes, based on ​http://www.iana.org/assignments/http-status-codes/http-status-codes.xml, as suggested.

[RvdH]

Some more clarification: I took the conservative approach and did not add status code 308 (no RFC number yet) and status code 506 (experimental).

[sjamaan]

Thank you for this patch. Since the original list was already 40 entries, and completing the list adds only about 15 I think it's acceptable to add it at this point. I think there are many silly status codes that nobody uses, so we should be cautious and prevent just blindly adding all of them in the future (this list will grow without end, I'm sure. That's the nature of all these crazy HTTP specs). But for now it's okay :)

Now that this list is added, I think Spiffy should probably be changed to signal request-header-fields-too-large when it receives (exn http line-limit-exceeded), so I've created ticket 1073 for that.

[RvdH]

Thanks!

I think most HTTP statuses are actually quite useful, they are just hardly used. :) Most often because developers do not know in what situations they should use them. Just returning a 403 or 404 in many cases, doesn't make it right. ;)

e.g.

We use 422 Unprocessable Entity a lot when the request is syntactically correct, but semantically not. For example, in form fields when an email address is required, but a regular string is entered, you can return a 422.

429 is often useful if you have a web service with a rate limit. Often done based on IP address: the free version is rate limited, while the paid version is not.

I think in general an HTTP server should support all valid HTTP status codes. It is up to the application developers to choose the right ones.

[sjamaan]

Yeah, you're right, but then the server (and intarweb itself) already support every code you can think of (even undefined/reserved ones), it just didn't have the symbolic shortcuts for them.

Some codes are so specific it doesn't make sense to burden all users of the library with the extra size and performance impact just for the 2% of users that might find these useful. Anyway, just wanted to make clear how I stand on it. I'm glad we have a full set now!