HTTP 418 I'm a teapot エラーメッセージ
(developer.mozilla.org)- HTTP 418
I'm a teapotは、サーバーが恒久的にティーポットであるためコーヒーを淹れられないとして拒否する状態レスポンスコード - コーヒー/ティー兼用ポットが一時的にコーヒーを提供できない状況であれば、418 ではなく
503 Service Unavailableを返すべき - このコードは Hyper Text Coffee Pot Control Protocol に由来するエイプリルフールのジョークであり、1998年と2014年に定義されたプロトコルに結び付いている
- もともとは RFC 2324 のジョークコードだったが、広く配布された状態にあるため RFC 9110 で正式に予約された
- 一部のWebサイトは、自動化クエリのように扱いたくないリクエストに 418 を使っており、近い将来に非ジョークの意味を与えることはできない
HTTP 418が表す状況
418 I'm a teapot状態レスポンスコードは、サーバーがコーヒーを淹れることを拒否することを意味する- 拒否の理由は、サーバーが恒久的に ティーポット だからである
- コーヒー/ティー兼用ポットが一時的にコーヒーを提供できない場合は
503を返すべき
エイプリルフールのプロトコルに由来するコード
- この状態コードは Hyper Text Coffee Pot Control Protocol を参照している
- このプロトコルは、1998年と2014年の エイプリルフールのジョーク として定義された
- 418 はもともと RFC 2324 でエイプリルフールのジョークとして定義されたコードである
RFC 9110で予約された理由
- 418 状態コードはジョークとして広く配布された状態にあるため、RFC 9110 で正式に予約された
- この予約のため、近い将来に 418 に 非ジョークの意味 を割り当てることはできない
実際の使われ方
- 一部のWebサイトは、処理したくないリクエストに 418 レスポンス を使用する
- 代表的な例として 自動化クエリ のようなリクエストがある
関連仕様と参考資料
- RFC 2324 section 2.3.2: 418 状態コードの元の定義
- HTTP Semantics name-418-unused: 418 の予約状態
- HTTP response status codes: HTTP レスポンス状態コードの一覧
- Wikipedia: Hyper Text Coffee Pot Control Protocol: Hyper Text Coffee Pot Control Protocol の参考資料
1件のコメント
Hacker News のコメント
暇なら、mnot が技術的に正確ではないという理由で、複数の言語や実装から 418 ステータスコードを削除しようとしたときの議論を読む価値がある
https://github.com/nodejs/node/issues/14644
https://github.com/golang/go/issues/21326
最終的には誰かが http://save418.com/ というサイトまで作った
処理が成功したときにロケットの絵文字を入れよう、というような話で、私は反対だった。こういうものを入れ始めると、人それぞれ好みが出て、ここにはもっと入れよう、ここでは外そうという議論が延々と生まれ、まったく別の話題を議論しているときにも持ち出されるようになる
特に、ユーザー行動のトラッキングで実際に指標が改善したかを見ないのであれば、コミュニケーションコストの増加は大きな損失だと思う。専門性の問題ではなく、ある人は好きで、ある人は嫌いで、ある人は気づかない、という主観性が小さな摩擦を頻繁に生んでいた
私は正当でないボットのリクエストには 418 で応答している。面白いし、ログのフィルタリングもしやすくなる
Nginx 設定例は次のとおり
Nothing to hack around here, I’m just a teapot:
location ~* .(?:php|aspx?|jsp|dll|sql|bak)$ {
return 418;
}
error_page 418 /418.html;
例: https://FreeSolitaire.win/wp-login.php
ちなみに /wp-login.php は WordPress のログイン URL で、脆弱な WordPress インストールを探すボットがよく手当たり次第にリクエストしてくる
こういう URL をリクエストしたという理由だけで、そのアドレスを恒久的にブロックするにはどうすればよいのか気になる
リンクされている元の RFC も読みやすい: https://www.rfc-editor.org/rfc/rfc2324
TCP や TLS がどう動くのか文書を読むと、経験とビジョンを持った専門家が書いたという感じがするが、CCSDS 文書は一生コードを一行も書いたことのない官僚たちが書いたように見える
これは 2010年代に “sir, this is a wendy's” が Facebook ミームとして大きく流行る前の、ナード式の唐突なジョークだった
以前、何の理由だったか HTTP/2 RFC を読んでいて見つけた素敵な箇所をいつも思い出す
“429 Too Many Requests” が標準化される前、Twitter API はリクエストのレート制限時に非標準の 420 ステータスコードと “Enhance Your Calm” という文言を返していた。理解できる理由でやめたが、その文言だけは HTTP/2 にこっそり入り込んだ
https://datatracker.ietf.org/doc/html/rfc7540#section-7
0xb の項目を見ると、過剰な負荷による接続終了の文言が実際に ENHANCE_YOUR_CALM になっている。見るたびに笑ってしまう
実際のサービスでこのエラーコードに出くわすたびに、とても苛立った
誰かが気の利いたことをしているように見せようとして、429 や 503 のような正しいステータスコードの代わりにこれを返し、そのせいで多くの HTTP ステータスコードパーサーが壊れる
気が利いてもいないし面白くもなく、実際には退屈だ。自分が面白みのない人間だというのは分かっているが、やるべき仕事がある
Van Halen は公演契約書に、楽屋に M&M を置くが茶色はすべて取り除いてほしい、と書いていたという
ボーカルの David Lee Roth は自伝『Crazy From the Heat』で、これは子どもじみた要求ではなく、会場が安全かどうかを即座に判断するための賢いテストだったと説明している
会場が茶色の M&M を出していたなら、契約書をきちんと読んでいないという意味で、電源供給やステージの耐荷重のような、より危険な部分でもミスしている可能性があると見たわけだ
https://www.metaltalk.net/chris-dale-myth-busting-the-van-ha...
以前 Sonatype Nexus がアーティファクトのアップロード中に 418 を返したことがあったが、まったく感心しなかった
HTTP ステータスコードの誤用は見るたびに驚く。私の好きな例は、ある顧客のサービスで、“200 OK” を返したうえでレスポンス本文にテキストで “500” だけを入れていたものだ
API エラーがあるなら 200 ではなく 500 エラーを返してほしいと頼んだところ、ヘッダーではなくレスポンス内の 200 だけを変えてしまった。“200 Created” も、開発者の理解不足や奇妙なフレームワーク上の制約を示す例としてかなり強烈だ
認証サービスで 418 レスポンスコードを使っている
トークンが期限切れのために無効なのか、それとも別の理由なのかを区別するために使っている。418 ならアクセストークンを自動的に更新すればよいと判断している。かなり無害で、セキュリティ対策でもまったくない
関連する議論
2020年、153ポイント・コメント118件: https://news.ycombinator.com/item?id=24206899
2021年、193ポイント・コメント108件: https://news.ycombinator.com/item?id=28541327
2023年、206ポイント・コメント189件: https://news.ycombinator.com/item?id=36090344
こういうスレッドではたいてい誰かが iiNet coffee cam をリンクするものだ。ここにある
https://coffeecam.iinet.net.au/coffee/history/
coffeecam もかわいかったし、主に coffeecam を担当していた acb はその周辺でアメリカのお菓子も売っていた。少なくとも私が Hay Street で働いていた頃はそうだった