requests: 418 I'm a Teapot
Requests implements the 418 I’m a Teapot status code in status_codes.py.
Its source is RFC2324, Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0). Note the title - HTCPCP/1.0 is not HTTP/1.x.
HTCPCP was an April 1 joke by Larry to illustrate how people were abusing HTTP in various ways. Ironically, it’s not being used to abuse HTTP itself – people are implementing parts of HTCPCP in their HTTP stacks.
In particular, Node’s support for the HTCPCP 418 I’m a Teapot status code has been used as an argument in the HTTP Working Group to preclude use of 418 in HTTP for real-world purposes.
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.
Please consider removing support for 418 from Requests, since it’s not a HTTP status code (even by its own definition). I know it’s amusing, I know that a few people have knocked up implementations for fun, but it shouldn’t pollute the core protocol; folks can extend Node easily enough if they want to play with non-standard semantics.
Thanks,
/cc @Lukasa
About this issue
- Original URL
- State: closed
- Created 7 years ago
- Reactions: 96
- Comments: 22 (13 by maintainers)
While I recognize 418 isn’t part of the HTTP status code spec in RFC 7231, it does exist in the wild. Even google has it implemented here. In the unlikely event the IETF decides to implement a real use for 418, we’ll have plenty of forewarning to address this. I’m in favor of leaving this as it is unless there’s a more compelling reason it needs to be removed.
Hold on! I’m the guy behind http://save418.com (https://github.com/WhataShane/save418). I, like many others, enjoy stumbling upon (almost entirely) innocuous gags like 418. It’s the sort of thing that’ll put a smile on your face even when you’re pressed to meet a project deadline and your boss is yapping at you one office over. It’d be a real shame to see it go.
To quote @romellem from the Go thread, who quite eloquently sums up the argument for 418:
Just to be clear, I agree with the rest of the Requests team: we should keep the 418 mapping here. But the reason I agree is purely pragmatic, not because of the fun Easter egg (though it is fun):
codes.pyis used to build a mapping from reason phrase to code. For this reason it should include any reason phrase that is somewhat likely to appear for a given code. For the moment that is I’m A Teapot. If this changes, we’ll add any other phrase the IANA assigns.@mnot, feel free to use this response as a commitment that says that the IETF/IANA should feel free to re-use 418, and not to block it on our behalf. 😉 I think reason phrases are stupid anyhow.
Requests takes itself seriously, but not too seriously. 😃
@tSavo Clearly!
This might be the line of “too seriously”.
Isn’t the obvious answer here to make it part of the spec by starting with a new RFC?
A request to register 418 has been submitted to IANA, under number 979050.
Give me your keys.