Requests: 418私はティーポットです

作成日 2017年08月11日  ·  22コメント  ·  ソース: psf/requests

Requestsは、 status_codes.pyの418 I'm aTeapotステータスコードを実装します。

そのソースはRFC2324、Hyper Text Coffee Pot Control Protocol(HTCPCP / 1.0)です。 タイトルに注意してください-HTCPCP / 1.0はHTTP / 1.xではありません。

HTCPCPは、人々がさまざまな方法でHTTPを悪用していることを説明するためのLarryによる4月1日のジョークでした。 皮肉なことに、HTTP自体を悪用するために使用されているわけではありません。人々はHTTPスタックにHTCPCPの一部を実装しています。

特に、HTCPCP 418 I'm a Teapotステータスコードに対するノードのサポートは、HTTPワーキンググループの引数として使用されており、実際の目的でのHTTPでの418の使用を排除しています。

現在登録されていない予備の4xxHTTPステータスコードがいくつかありますが、HTTPのセマンティクスは(願わくば)長期間続くため、いつかこのコードポイントが必要になる可能性があります。

418はHTTPステータスコードではないため(独自の定義でも)、リクエストから418のサポートを削除することを検討してください。 私はそれが面白いことを知っています、私は少数の人々が楽しみのために実装をノックアップしたことを知っています、しかしそれはコアプロトコルを汚染するべきではありません。 非標準のセマンティクスで遊びたい場合は、Nodeを簡単に拡張できます。

ありがとう、

/ cc @Lukasa

最も参考になるコメント

418はRFC7231のHTTPステータスコード仕様の一部ではないことを認識していますが、実際には存在します。 グーグルでさえここに実装されてい

全てのコメント22件

ところで、私はこれが重大な変更であることを認識しています。 非推奨にして次のメジャーリリースに遅らせることは問題ありません。

問題のコード行: https

200 OKの代替バージョンに注意してください: https

は。 私が懸念しているのは、Unicodeとバックスラッシュの使用だけです。 リクエストはそれらを放出しませんね?

いいえ、これは逆引き専用です—私がティーポットであるのと同じです。

OK]それは良いことだ。 問題は、実装がステータスコードの実際の使用を排除する証拠として使用されていることです。これは、最終的には問題になります。

同様の変更に関する議論については、 https ://github.com/nodejs/node/issues/14644およびhttps://github.com/golang/go/issues/21326を参照してください

420や友達などの他のステータスコードを追加したい場合を除いて、削除しても問題ありません。

HTTPbin.orgはそれを維持しています:)

個々のサーバー、私はあまり心配していません:)

PRを送ってください!

ただし、3.0.0ブランチに対しては、これは重大な変更になります。

持続する! 私はhttp://save418.com (https://github.com/WhataShane/save418)の背後にいる男です。 私は他の多くの人

418の議論を非常に雄弁に要約しているGoスレッドから@romellemを引用するには:

明確にするために、400ブロックがなくなった場合、または400ブロックの有用性をもう少し拡張するために、1つの追加コードを使用できるようにするというあなたの主張はありますか?

間違って読んでいない限り、HTTPステータスコードの400ブロックには50を超えるコードがあります。 400ブロックの使用可能な「スペース」が50%を超える場合、これは決して発生しない可能性のある問題(つまり、使用可能なコードが不足している400ブロック)の時期尚早な最適化である可能性があります。

耳障りな音を出そうとはしていませんが、プログラミングのキャリアを通じて見つけた楽しい小さなイースターエッグが好きです。 私にとっては、コンピューターを実際に機能させるために行われることはすべて、依然として人間によって行われていることを示しており、その人間の要素の小さなスライスを保持することは素晴らしいことです(私の意見では)。 あなたの議論は健全で論理的ですが、この要求された変更は、エンジニアリングの堅牢性の精神でGo(および場合によってはNodeJS)の「楽しさ」をわずかに低下させます。 結局のところ、トレードオフはそれだけの価値があるとは思わないと言わざるを得ません。

(しかし、歴史のレッスンに感謝します!私は常に418がHTTP / 1.x仕様の一部であると思っていました;「HTCPCP / 1.0」仕様について知りませんでした。🙂)

私はそれが楽しいイースターエッグであることに同意します。

リクエストはそれ自体を真剣に受け止めますが、それほど真剣ではありません。 :)

これは「真剣すぎる」という言葉かもしれません。

新しいRFCから始めて、それを仕様の一部にするための明白な答えはここにありませんか?

@tSavo明らかに!

418はRFC7231のHTTPステータスコード仕様の一部ではないことを認識していますが、実際には存在します。 グーグルでさえここに実装されてい

鍵をください。

明確にするために、私は他のリクエストチームに同意します。ここで418マッピングを維持する必要があります。 (それは楽しいですが)しかし、私は同意する理由はないので、楽しいイースターエッグの、純粋に実用的である: codes.pyコードに理由フレーズからマッピングを構築するために使用されます。 このため、特定のコードに表示される可能性のある理由フレーズを含める必要があります。 今のところ、私はティーポットです。 これが変更された場合は、IANAが割り当てる他のフレーズを追加します。

@ mnot 、IETF / IANAは418を自由に再利用し、私たちに代わってそれをブロックしないようにする必要があるというコミットメントとして、この応答を自由に使用してください。 😉理由フレーズはとにかく愚かだと思います。

418の登録リクエストは、番号979050で送信されました。

Ok; これは418のメリットに関するディスカッションフォーラムではありません。 @ mnotこれについてフォローアップしたい場合は、私にメールを送ってください。 他のすべての人のために:私たちはあなたの入力に感謝します、しかし私は私たちが下した決定についてかなり気分がいいです。

このページは役に立ちましたか?
0 / 5 - 0 評価