Requests: 第418章 我是茶壶

顺便说一句，我知道这是一个重大变化； 弃用和推迟到下一个主要版本是可以的。

有问题的代码行： https :

请注意 200 OK 的替代版本： https :

呵呵。 唯一让我担心的是 unicode 和反斜杠的使用； requests 不会发出那些，是吗？

不，这仅用于反向查找 - 与我是茶壶相同。

好的，那很好。 问题是实现被用作证据来排除状态代码的实际使用，这将_最终_成为一个问题。

有关类似更改的讨论，请参阅https://github.com/nodejs/node/issues/14644和https://github.com/golang/go/issues/21326 。

我可以删除它，除非我们想添加其他状态代码，如 420 和朋友。

不过 HTTPbin.org 会保留它:)

个人服务器，我不太关心:)

发送公关！

不过，让它针对 3.0.0 分支，这将是一个突破性的变化。

坚持，稍等！ 我是http://save418.com (https://github.com/WhataShane/save418) 的幕后和许多其他人一样，喜欢偶然发现（几乎完全是）像 418 这样的无伤大雅的噱头。即使当你迫不及待地赶上项目截止日期而你的老板对你大吼大叫时，这种事情也会让你脸上露出微笑一个办公室过去。 看到它消失真是太可惜了。

引用 Go 线程中的@romellem ，他非常雄辩地总结了 418 的论点：

需要明确的是，您的论点是当/如果 400 块用完时，我们是否需要一个额外的代码来进一步扩展 400 块的有用性？

除非我读错了，否则 400 个 HTTP 状态代码块有 50 多个可用代码。 由于 400 块的可用“空间”超过 50%，这可能是对可能永远不会发生的问题（即 400 块用完可用代码）的过早优化。

不想听起来刺耳，但我喜欢在整个编程生涯中都能找到的有趣的小复活节彩蛋。 对我来说，它表明让计算机真正工作的一切仍然是由人类制造的，保留人类元素的一小部分很好（在我看来）。 您的论点是合理且合乎逻辑的，但是本着工程稳健性的精神，这种要求的更改稍微降低了 Go（以及可能的 NodeJS）的“乐趣”。 归根结底，我不得不说我认为这种权衡不值得。

（不过我很欣赏历史课！我一直认为 418 是 HTTP/1.x 规范的一部分；不知道“HTCPCP/1.0”规范。🙂）

我同意这是一个有趣的复活节彩蛋。

Requests 把自己当回事，但不要太当真。 :)

这可能是“太认真”的说法。

通过从新的 RFC 开始使其成为规范的一部分，这不是显而易见的答案吗？

@tSavo 很明显！

虽然我认识到 418 不是 RFC 7231 中 HTTP 状态代码规范的一部分，但它确实存在于野外。 甚至谷歌也在这里实现了它。 万一 IETF 决定实现 418 的真正用途，我们将有大量预警来解决这个问题。 我赞成保持原样，除非有更令人信服的理由需要删除它。

把你的钥匙给我。

明确地说，我同意请求团队的其他成员：我们应该在这里保留 418 映射。 但我同意的原因纯粹是务实的，不是因为复活节彩蛋好玩（虽然它很有趣）： codes.py用于构建从原因短语到代码的映射。 出于这个原因，它应该包括任何可能出现在给定代码中的原因短语。 就目前而言，我是茶壶。 如果这发生变化，我们将添加 IANA 分配的任何其他短语。

@mnot ，请随意使用此回复作为承诺，表示 IETF/IANA 应该随意重用 418，而不是代表我们阻止它。 😉我认为理由短语无论如何都很愚蠢。

注册 418 的请求已提交给 IANA ，编号为 979050。

行; 这不是一个讨论 418 优点的论坛。 @mnot如果你想跟进这个，请给我发电子邮件。 对于其他所有人：我们感谢您的意见，但我对我们做出的决定感到非常满意。