Reserve the 418 status code
tools.ietf.org
Reserve the 418 status code
1–10 of 124 posts
Re: Reserve the 418 status code
#2Why is 418 the particular target? Just because of RFC2324?
> IANA should also typographically distinguish “Unassigned” and “Reserved” in the registry descriptions, to prevent confusion.
This I can get onboard with. Honestly, I've never seen a 418 easter egg, but I'd think it would be an HTTP spec violation if it didn't at least conform to the higher level 4xx definition (Client Error) :)
Re: Reserve the 418 status code
#3Why is 418 the particular target? Just because of RFC2324? > IANA should also typographically distinguish “Unassigned” and “Reserved” in the registry descriptions, to prevent confusion. This I can get onboard with. Honestly, I've never seen a 418 easter egg, but I'd think it would be an HTTP spec violation if it didn't at least conform to the higher level 4xx definition (Client Error) :)
It's a response to this story (https://news.ycombinator.com/item?id=14987460), where a contributor has been going to many different projects and attempting to remove language support for the 418 error code.
EDIT: Ah, so it's the same person. In which case it's more of a continuation, and I anticipate that the intention is to make implementations that allow 418 non-compliant.
Re: Reserve the 418 status code
#4Why is 418 the particular target? Just because of RFC2324? > IANA should also typographically distinguish “Unassigned” and “Reserved” in the registry descriptions, to prevent confusion. This I can get onboard with. Honestly, I've never seen a 418 easter egg, but I'd think it would be an HTTP spec violation if it didn't at least conform to the higher level 4xx definition (Client Error) :)
Because:
1st: RFC2324 mentioned it
and
2nd: too many people then implemented it.
Re: Reserve the 418 status code
#5Why is 418 the particular target? Just because of RFC2324? > IANA should also typographically distinguish “Unassigned” and “Reserved” in the registry descriptions, to prevent confusion. This I can get onboard with. Honestly, I've never seen a 418 easter egg, but I'd think it would be an HTTP spec violation if it didn't at least conform to the higher level 4xx definition (Client Error) :)
An example of an existing easter egg (for reference): https://www.google.com/teapot
Re: Reserve the 418 status code
#6Why is 418 the particular target? Just because of RFC2324? > IANA should also typographically distinguish “Unassigned” and “Reserved” in the registry descriptions, to prevent confusion. This I can get onboard with. Honestly, I've never seen a 418 easter egg, but I'd think it would be an HTTP spec violation if it didn't at least conform to the higher level 4xx definition (Client Error) :)
[deleted]
Re: Reserve the 418 status code
#7Why is 418 the particular target? Just because of RFC2324? > IANA should also typographically distinguish “Unassigned” and “Reserved” in the registry descriptions, to prevent confusion. This I can get onboard with. Honestly, I've never seen a 418 easter egg, but I'd think it would be an HTTP spec violation if it didn't at least conform to the higher level 4xx definition (Client Error) :)
It's a response to this story ( https://news.ycombinator.com/item?id=14987460 ), where a contributor has been going to many different projects and attempting to remove language support for the 418 error code. EDIT: Ah, so it's the same person. In which case it's more of a continuation, and I anticipate that the intention is to make implementations that allow 418 non-compliant.
Note that the "contributor" (Mark Nottingham) is also the author of the document in OP, and deserves a lot of credit for taking this approach. Given that his area of work is HTTP standards, I think he initially started removing 418 to tidy up and make things compliant and isn't just some bore who hates fun. Now he's managed to make everyone happy in a standards-compliant way.
Re: Reserve the 418 status code
#8Why is 418 the particular target? Just because of RFC2324? > IANA should also typographically distinguish “Unassigned” and “Reserved” in the registry descriptions, to prevent confusion. This I can get onboard with. Honestly, I've never seen a 418 easter egg, but I'd think it would be an HTTP spec violation if it didn't at least conform to the higher level 4xx definition (Client Error) :)
It's a response to this story ( https://news.ycombinator.com/item?id=14987460 ), where a contributor has been going to many different projects and attempting to remove language support for the 418 error code. EDIT: Ah, so it's the same person. In which case it's more of a continuation, and I anticipate that the intention is to make implementations that allow 418 non-compliant.
The contributor trying to remove 418 and the author of this RFC are the same person (Mark Nottingham[1])
Re: Reserve the 418 status code
#9Earlier quoted context omitted.
It's a response to this story ( https://news.ycombinator.com/item?id=14987460 ), where a contributor has been going to many different projects and attempting to remove language support for the 418 error code. EDIT: Ah, so it's the same person. In which case it's more of a continuation, and I anticipate that the intention is to make implementations that allow 418 non-compliant.
Note that the "contributor" (Mark Nottingham) is also the author of the document in OP, and deserves a lot of credit for taking this approach. Given that his area of work is HTTP standards, I think he initially started removing 418 to tidy up and make things compliant and isn't just some bore who hates fun. Now he's managed to make everyone happy in a standards-compliant way.
For those that may not know, Mark is also co-chair of the HTTP Working Group on the IETF[1].
Re: Reserve the 418 status code
#10Earlier quoted context omitted.
It's a response to this story ( https://news.ycombinator.com/item?id=14987460 ), where a contributor has been going to many different projects and attempting to remove language support for the 418 error code. EDIT: Ah, so it's the same person. In which case it's more of a continuation, and I anticipate that the intention is to make implementations that allow 418 non-compliant.
Note that the "contributor" (Mark Nottingham) is also the author of the document in OP, and deserves a lot of credit for taking this approach. Given that his area of work is HTTP standards, I think he initially started removing 418 to tidy up and make things compliant and isn't just some bore who hates fun. Now he's managed to make everyone happy in a standards-compliant way.
It's weird though. The origin spec is specifically a discrete protocol called HTCPCP, not HTTP, so it has nothing to do with HTTP standards. They can do whatever they want with 418 in HTTP.