3 ms·

I find the initiatives like this to be kind of a waste of time. And some of the reasons are kind of contrived. For example: > While we have a number of spare 4

by throwaway2016a 9y ago

I find the initiatives like this to be kind of a waste of time. And some of the reasons are kind of contrived. For example: > While we have a number of spare 4xx HTTP status codes that are unregistered now, the semantics of HTTP are something that (hopefully) are going to last for a long time, so one day we may need this code point. [1] First, you can remove it when there this problem actually happens. The backwards compatibility issue won't be any more/less of an issue then than now. Second, "we may need this code point" is disingenuous unless the user is part of the W3C there is no "we" here. The node community can't decide unilaterally to change code points. (he might be part of W3C I didn't check. My sincere apologies if he is) With that said, another part of the argument is valid. rfc2324 which defines the code is indeed not HTTP, it is HTCPCP (Hypertext Coffee Pot Control Protocol) and one could strongly argue that it doesn't belong in an HTTP library. [1] https://github.com/nodejs/node/issues/14644 https://github.com/nodejs/node/issues/14644

WorldMaker 9y ago
At the point in the distant future where you are worried about needing more HTTP error codes and considering reusing 418 it may just be easier to just add more digits to the protocol. In HTTP/1.x the status codes are plaintext and it's not like it would be that much of a change to most HTTP parsers. There's not really even a strong technical reason why they are three digit codes to begin with in plaintext HTTP, it's just an arbitrary choice. The HTCPCP argument isn't all that valid as there are several recognized (IANA) HTTP codes [1] from HTTP extensions like HTCPCP. Note for instance all the ones from rfc4918 which is the WebDAV extension to HTTP, such as 424 and 507. Not all codes are from HTTP RFCs and I also think the "bug" here is that IANA has ignored rfc2324 for too long and should recognize the RFC as a valid HTTP extension with useful [2] HTTP status codes. [1] https://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml https://www.iana.org/assignments/http-status-codes/http-stat... [2] Usefulness is a subjective measure, of course, but usefulness in jokes/play is still usefulness.

WorldMaker 9y ago

At the point in the distant future where you are worried about needing more HTTP error codes and considering reusing 418 it may just be easier to just add more digits to the protocol. In HTTP/1.x the status codes are plaintext and it's not like it would be that much of a change to most HTTP parsers. There's not really even a strong technical reason why they are three digit codes to begin with in plaintext HTTP, it's just an arbitrary choice. The HTCPCP argument isn't all that valid as there are several recognized (IANA) HTTP codes [1] from HTTP extensions like HTCPCP. Note for instance all the ones from rfc4918 which is the WebDAV extension to HTTP, such as 424 and 507. Not all codes are from HTTP RFCs and I also think the "bug" here is that IANA has ignored rfc2324 for too long and should recognize the RFC as a valid HTTP extension with useful [2] HTTP status codes. [1] https://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml https://www.iana.org/assignments/http-status-codes/http-stat... [2] Usefulness is a subjective measure, of course, but usefulness in jokes/play is still usefulness.