New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

418 I'm a Teapot #4238

Closed
mnot opened this Issue Aug 10, 2017 · 22 comments

Comments

Projects
None yet
9 participants
@mnot

mnot commented Aug 10, 2017

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

@mnot

This comment has been minimized.

Show comment
Hide comment
@mnot

mnot Aug 10, 2017

BTW, I'm aware this is a breaking change; deprecating and delaying to the next major release is fine.

mnot commented Aug 10, 2017

BTW, I'm aware this is a breaking change; deprecating and delaying to the next major release is fine.

@kennethreitz

This comment has been minimized.

Show comment
Hide comment
@kennethreitz

This comment has been minimized.

Show comment
Hide comment
Member

kennethreitz commented Aug 10, 2017

@mnot

This comment has been minimized.

Show comment
Hide comment
@mnot

mnot Aug 10, 2017

Huh. The only thing that causes me concern there is the use of unicode and backslashes; requests doesn't emit those, does it?

mnot commented Aug 10, 2017

Huh. The only thing that causes me concern there is the use of unicode and backslashes; requests doesn't emit those, does it?

@kennethreitz

This comment has been minimized.

Show comment
Hide comment
@kennethreitz

kennethreitz Aug 10, 2017

Member

Nope, this is for reverse lookup only — same with I'm a teapot.

Member

kennethreitz commented Aug 10, 2017

Nope, this is for reverse lookup only — same with I'm a teapot.

@mnot

This comment has been minimized.

Show comment
Hide comment
@mnot

mnot Aug 10, 2017

OK, that's good. The problem is that implementation is being used as evidence to preclude actual use of the status code, which is going to eventually be a problem.

mnot commented Aug 10, 2017

OK, that's good. The problem is that implementation is being used as evidence to preclude actual use of the status code, which is going to eventually be a problem.

@tyteen4a03 tyteen4a03 referenced this issue Aug 10, 2017

Closed

Add more links #4

@tyteen4a03

This comment has been minimized.

Show comment
Hide comment
@tyteen4a03

tyteen4a03 Aug 10, 2017

Please see nodejs/node#14644 and golang/go#21326 for discussions regarding similar changes.

Please see nodejs/node#14644 and golang/go#21326 for discussions regarding similar changes.

@kennethreitz

This comment has been minimized.

Show comment
Hide comment
@kennethreitz

kennethreitz Aug 10, 2017

Member

I'm okay with removing it, unless we want to add other status codes like 420 and friends.

HTTPbin.org is keeping it though :)

Member

kennethreitz commented Aug 10, 2017

I'm okay with removing it, unless we want to add other status codes like 420 and friends.

HTTPbin.org is keeping it though :)

@mnot

This comment has been minimized.

Show comment
Hide comment
@mnot

mnot Aug 10, 2017

Individual servers, I'm less concerned about :)

mnot commented Aug 10, 2017

Individual servers, I'm less concerned about :)

@kennethreitz

This comment has been minimized.

Show comment
Hide comment
@kennethreitz

kennethreitz Aug 10, 2017

Member

Send a PR!

Member

kennethreitz commented Aug 10, 2017

Send a PR!

@kennethreitz

This comment has been minimized.

Show comment
Hide comment
@kennethreitz

kennethreitz Aug 10, 2017

Member

Make it against the 3.0.0 branch though, this will be a breaking change.

Member

kennethreitz commented Aug 10, 2017

Make it against the 3.0.0 branch though, this will be a breaking change.

@WhataShane

This comment has been minimized.

Show comment
Hide comment
@WhataShane

WhataShane Aug 10, 2017

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, is your argument that when/if the 400 block runs out, we'll want that one extra code available to stretch out the usefulness of the 400 block just a bit further?

Unless I'm reading it incorrectly, the 400 block of HTTP status codes has more than 50 codes available. With the available "space" of the 400 block at more than 50%, this might be a pre-mature optimization for a problem that may never occur (400 block running out of available codes, that is).

Not trying to sound harsh, but I for one like fun little easter eggs that you find throughout a programming career. To me, it shows that everything that goes on to make a computer actually do work is still made by humans, and keeping small slices of that human element is nice (in my opinion). Your argument is sound and logical, but this requested change ever so slightly lowers the "fun-ness" of Go (and potentially NodeJS) in the spirit of engineering robustness. At the end of the day, I have to say I don't think that tradeoff is worth it.

(I appreciate the history lesson though! I always thought 418 was a part of the HTTP/1.x spec; didn't know about the "HTCPCP/1.0" spec. 🙂)

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, is your argument that when/if the 400 block runs out, we'll want that one extra code available to stretch out the usefulness of the 400 block just a bit further?

Unless I'm reading it incorrectly, the 400 block of HTTP status codes has more than 50 codes available. With the available "space" of the 400 block at more than 50%, this might be a pre-mature optimization for a problem that may never occur (400 block running out of available codes, that is).

Not trying to sound harsh, but I for one like fun little easter eggs that you find throughout a programming career. To me, it shows that everything that goes on to make a computer actually do work is still made by humans, and keeping small slices of that human element is nice (in my opinion). Your argument is sound and logical, but this requested change ever so slightly lowers the "fun-ness" of Go (and potentially NodeJS) in the spirit of engineering robustness. At the end of the day, I have to say I don't think that tradeoff is worth it.

(I appreciate the history lesson though! I always thought 418 was a part of the HTTP/1.x spec; didn't know about the "HTCPCP/1.0" spec. 🙂)

@kennethreitz

This comment has been minimized.

Show comment
Hide comment
@kennethreitz

kennethreitz Aug 10, 2017

Member

I agree that it's a fun easter egg.

Member

kennethreitz commented Aug 10, 2017

I agree that it's a fun easter egg.

@kennethreitz

This comment has been minimized.

Show comment
Hide comment
@kennethreitz

kennethreitz Aug 10, 2017

Member

Requests takes itself seriously, but not too seriously. :)

Member

kennethreitz commented Aug 10, 2017

Requests takes itself seriously, but not too seriously. :)

@kennethreitz

This comment has been minimized.

Show comment
Hide comment
@kennethreitz

kennethreitz Aug 10, 2017

Member

This might be the line of "too seriously".

Member

kennethreitz commented Aug 10, 2017

This might be the line of "too seriously".

@TSavo

This comment has been minimized.

Show comment
Hide comment
@TSavo

TSavo Aug 10, 2017

Isn't the obvious answer here to make it part of the spec by starting with a new RFC?

TSavo commented Aug 10, 2017

Isn't the obvious answer here to make it part of the spec by starting with a new RFC?

@kennethreitz

This comment has been minimized.

Show comment
Hide comment
@kennethreitz

kennethreitz Aug 10, 2017

Member

@TSavo Clearly!

Member

kennethreitz commented Aug 10, 2017

@TSavo Clearly!

@nateprewitt

This comment has been minimized.

Show comment
Hide comment
@nateprewitt

nateprewitt Aug 11, 2017

Member

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.

Member

nateprewitt commented Aug 11, 2017

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.

@geeves

This comment has been minimized.

Show comment
Hide comment
@geeves

geeves Aug 11, 2017

Give me your keys.

geeves commented Aug 11, 2017

Give me your keys.

@Lukasa

This comment has been minimized.

Show comment
Hide comment
@Lukasa

Lukasa Aug 11, 2017

Member

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.py is 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.

Member

Lukasa commented Aug 11, 2017

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.py is 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.

@daenney

This comment has been minimized.

Show comment
Hide comment

daenney commented Aug 11, 2017

A request to register 418 has been submitted to IANA, under number 979050.

@Lukasa

This comment has been minimized.

Show comment
Hide comment
@Lukasa

Lukasa Aug 11, 2017

Member

Ok; this is not a discussion forum for the merits of 418. @mnot if you want to follow up on this please drop me an email. For everyone else: we appreciate your input, but I feel pretty good about the decision we've made.

Member

Lukasa commented Aug 11, 2017

Ok; this is not a discussion forum for the merits of 418. @mnot if you want to follow up on this please drop me an email. For everyone else: we appreciate your input, but I feel pretty good about the decision we've made.

@requests requests locked and limited conversation to collaborators Aug 11, 2017

@requests requests deleted a comment from cheery Aug 11, 2017

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.