[20] HTTP/0.9 は、 以来使われている HTTP の最初の版です。 極めて単純ですが、あまりに低機能なので、現在ではほとんど使われなくなっています。 それでも HTTP プロトコルの一部として依然として広く実装されています。

仕様書

呼称

[47] 元々は単に「HTTP」と呼んでいましたが、新しい版 (HTTP2 と呼ばれたり、HTTP/1.0 と呼ばれたりしたもの。後の HTTP/2 とは別。) が開発された時、区別するために HTTP/0.9 と呼ばれるようになりました。 (新しい版が当初 HTTP2 と呼ばれていたということは、その当時は HTTP/0.9 が HTTP「1」だという意識があったのでしょう。)

[48] 0.9 は 1.0 より前という程度の意味なので、 0.8 や 0.5 や 0.1 はありません。

プロトコル

[22] HTTP/0.9 の詳細については HTTP や、各プロトコル要素の項を参照してください。

[14] HTTP/0.9 応答は MIME型を示せないため、 HTTP/0.9 要求は非推奨 >>13 とされています。

[25] HTTP/0.9 にはヘッダーはありません。 Host: ヘッダーも含められないため、 (要求URLに絶対URLを指定して無理に明示するのでなければ) 仮想ホストに対応できません。この意味で HTTP/0.9 は最早 Web互換とはいえません。

[24] 状態符号はありません。

[30] Chrome で XHR で取得すると、 200 扱いになっているようです。

[26] HTTP/0.9 応答はキャッシュ不可能なものとして処理するべきと思われます。

[38] IE はキャッシュするようです。

HTTP/1.0 との関係

[12] HTTP/1.0 鯖は HTTP/0.9 要求を処理できなければなりません >>10。 HTTP/1.0 鯖は HTTP/0.9 要求を受信したら、 HTTP/0.9 応答を返さなければなりません >>10, >>15。

[11] HTTP/1.0 クライアントは HTTP/0.9 応答を処理できなければなりません >>10。

[17] HTTP/0.9 鯖だった場合、 HTTP/1.0 要求に HTTP/0.9 応答が返されることとなります >>18 から、 HTTP/0.9 要求でなくても HTTP/0.9 応答に対応できる必要があるようです。

[16] HTTP/1.0 応答を処理できるクライアントは HTTP/0.9 要求を送信するべきではありません >>15。

要求の解釈

[32] nginx は、GET、1文字以上の空白、 絶対パスか絶対URL、改行となっていなければ、 400 応答に相当する応答本体を返します。要求メソッドは大文字でなければなりません。

[49] nginx は、 HEAD や POST や未知の要求メソッドのときも、 400 を返します。

[33] Apache は、任意の要求メソッドを認めています。 (もちろん当該資源で対応していなければ、 405 や 501 が返されたり (ただし応答本体のみ)、 GET にフォールバックしたりします。 HEAD では 400 となります。

[34] Apache は TRACE にも対応しているので、 TRACE CRLF と書くと TRACE が帰ってきます。

[64] HTTP/0.9要求に対応できないHTTPサーバーもあるようです。 426

応答の解釈

[19] HTTP/1.0 や HTTP/1.1 の要求であっても、応答の先頭を状態行として解釈できなければ、 HTTP/0.9 応答と解釈することとなります。

[28] 応答の最初の行に、 Chrome と IE は HTTP、 Firefox は HTTP/1. が含まれていれば、 HTTP/0.9 では無いとみなすようです。 HTTP は大文字でも小文字でも構いません。行頭でなくても構いません。 行は、 LF までです。

[39] 正確には、 Chrome と Firefox は最初の8バイトに HTTP が含まれていなければなりません。 (Firefox はその後に更に /1. が必要ですが、 そこまで最初の8バイトに無くても良いようです。) その8バイトに改行が含まれていても構いません。 IE はもっと緩くて十数バイトあっても良いようですが (どこまでいけるかは不明)、 HTTP の直後が改行であってはならないようです。

[7] Firefox と Chrome は PUT への応答が HTTP/0.9 だと、エラーとみなすようです。 IE は通常の応答として扱うようです。 それ以外の要求メソッドは通常の応答として扱うようです。

[45] Firefox と Chrome は CONNECT への応答が HTTP/0.9 だと、エラーとみなすようです。 IE は正しく扱えず応答を待つように見えます。

[31] 応答として何も返さないと (長さが0だと) ネットワークエラーとみなされるようです。 Firefox と Chrome では (XHR の) 状態符号 0、 理由句が空文字列となります。 IE では 12152、 Unknown となります。

[43] Chrome も Firefox も IE も、 プロキシとして指定されたサーバーが HTTP/0.9 応答を返すと、それを通常通り応答として使います。

[44] Chrome は HTTP/0.9 over TLS をネットワークエラーとみなすようです。 Firefox と IE では通常通り扱われます。

[69] curl はあるときから HTTP/0.9 応答を受け取った時 Received HTTP/0.9 when not allowed というエラーメッセージを表示するように非互換変更されました。

[70] それまでちゃんと動いていたものが突然動かなくなったと困っている人がままいるっぽいです。 >>65, >>66, >>67 それだけ HTTP/0.9 の挙動に依存したシステムが存在しているということでしょう。 (意図したものか、たまたま動いていたのかはともかく。)

[71] コマンドラインオプションに --http0.9 を付けると、 HTTP/0.9 を扱えるようになります。 PHP には CURLOPT_HTTP09_ALLOWED というオプションがあります >>68。

応答の MIME 型

[23] MIME型は Content-Type: ヘッダーが無い場合のように Content-Type sniffing によって決定されるものと思われます。 元々は HTML のみが使われることが想定されていました。

[37] 平文の転送のために HTML の plaintext タグが用意されています。[29] Chrome と IE は sniffing しているようですが、 Firefox は text/plain として扱っているようです。

歴史

[59] HTTP/0.9 は HTTP の最初の版であり、当初は単に HTTP と呼ばれていました。

[60] 当時は TimBL が配布していた文書 (テキストファイル) や CERN の Webサイトにあった HTML文書という形の仕様書が存在していました。

[61] 後に、 HTTP/1.0 を定義する RFC 1945 の一部として、 改めて仕様書の形にまとめられました。

[2] HTTP0.9 Summary -- /DesignIssues ( 版) http://www.w3.org/DesignIssues/HTTP0.9Summary.html

[73] (No title), , https://www.w3.org/History/19921103-hypertext/hypertext/WWW/Protocols/HTTP.html

[36] The HTTP Protocol As Implemented In W3 ( 版) http://www.w3.org/Protocols/HTTP/AsImplemented.html

[40] HTTP0.9 Summary -- /DesignIssues ( 版) http://www.w3.org/DesignIssues/HTTP0.9Summary.html

[41] ProtocolVersions -- Design Issues ( 版) http://www.w3.org/DesignIssues/ProtocolVersions.html

[42] CompatibleProof -- /DesignIssues ( 版) http://www.w3.org/DesignIssues/CompatibleProof

[1] Apache に GET / HTTP/0.9 とかやってみたら、ほんとに HTTP/0.9 になりましたよ:−)

[8] >>1 現在の Apache はプロトコルの版に HTTP/0.9 を指定しても、 HTTP/1.0 のように処理するようです。

[9] nginx はプロトコルの版に HTTP/0.9 を指定すると、 要求行を受信した段階で 400 を返します。

[27] nginx は HTTP/0.9 応答に対して状態符号によらず応答本体のみ返しますが、 リダイレクトの場合 URL を応答本体には含めないため、 HTTP/0.9 クライアントはリダイレクト先 URL を知ることができません。

[79] 728236 - HTML Pages are shown as text when served on nonstandard port with an HTTP status line starting "HTTP/0.9", https://bugzilla.mozilla.org/show_bug.cgi?id=728236

[3] IRC logs: freenode / #whatwg / 20140107 ( ( 版)) http://krijnhoetmer.nl/irc-logs/whatwg/20140107#l-537

[4] RFC 7230 - Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing ( ( 版)) https://tools.ietf.org/html/rfc7230#page-82

[35] HTTP/0.9にハマル | Livingdeadの日記 | スラド ( 版) http://srad.jp/~Livingdead/journal/492941/

ライブドア・データホテル・パトロールというサービスを使っている.これはなかなかのすぐれもので,ウェブサーバの監視をはじめ証明書の期限切れ検知などにも使えるのだが,最近lighttpdを使っているウェブサービスの死活監視に使ってみてHTTP/0.9のリクエストになっているのかなと思った.

というのはlighttpdにtelnetで接続して「GET / 」と打つと400 Bad Requestになるのだが,データホテル・パトロールでも確かに400を検出して異常が検知されたことになる.

[46] Issue 517106 - chromium - Chrome refuses to accept HTTP/0.9 responses over SSL that are less than 8 bytes long. - An open-source project to help move the web forward. - Google Project Hosting ( 版) https://code.google.com/p/chromium/issues/detail?id=517106

Re-disable support for HTTP/0.9 responses < 8 bytes over SSL. This allows an MITM to make the firs byte of a valid HTTP/1.x response look like a valid HTTP/0.9 reponses, so best to be safe.

[50] Chromium Blog: Chrome 53 Beta: Shadow DOM, PaymentRequest, and Android autoplay ( ()) http://blog.chromium.org/2016/08/chrome-53-beta-shadow-dom.html

HTTP/0.9 has been deprecated in favor of HTTP/1.0, which adds response header support.

[51] HTTP - WHATWG Wiki () https://wiki.whatwg.org/wiki/HTTP#HTTP_0.9_.28and_Legacy_Shoutcast_support.29

[52] Intent to implement and Ship: Shoutcast support - Google グループ () https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/qS63pYso4P0/FP6xymqNAwAJ

[82] 632524 - End support for HTTP/0.9, https://bugzilla.mozilla.org/show_bug.cgi?id=632524

[83] 1262128 - Cross-Protocol Theft from non-HTTP services via DNS rebinding + "HTTP/0.9", https://bugzilla.mozilla.org/show_bug.cgi?id=1262128

[54] Intent to Deprecate and Remove: HTTP/0.9 Support - Google グループ () https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/OdKnpLlvVUo

[55] 624462 - Reduce cases where HTTP/0.9 is supported - chromium - Monorail () https://bugs.chromium.org/p/chromium/issues/detail?id=624462

[81] Can't access router config on chromium based browser anymore [40480313] - Chromium, https://issues.chromium.org/issues/40480313

[57] Intent to implement and Ship: Shoutcast support - Google グループ () https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/qS63pYso4P0/FP6xymqNAwAJ

[53] Shoutcast

[56] 667907 – (CVE-2011-3656) Possible XSS via HTTP 0.9 errors and content-sniffing () https://bugzilla.mozilla.org/show_bug.cgi?id=667907

[58] 21467 - Cross site scripting through non-http servers - chromium - Monorail () https://bugs.chromium.org/p/chromium/issues/detail?id=21467

[62] HTTP/0.9は今でも使われている? - Qiita (@hakatashi 2017年12月10日に更新 ) https://qiita.com/hakatashi/items/7bdbcab2067406003866

[63] 669800 - Shoutcast streams on non-standard port would no longer play - chromium - Monorail () https://bugs.chromium.org/p/chromium/issues/detail?id=669800

[80] 869725 - support shoutcast streams, https://bugzilla.mozilla.org/show_bug.cgi?id=869725

[67] Make HTTP/0.9 opt-in · Issue #2873 · curl/curl · GitHub, https://github.com/curl/curl/issues/2873

[68] PHP: curl_setopt - Manual, , https://www.php.net/manual/en/function.curl-setopt.php

[72] MiyahanさんはTwitterを使っています: 「2022年に HTTP/0.9 しか喋れない謎サーバーの監視依頼が来て泡吹いて倒れてる。 現代の主要な監視システムではHTTP監視できないので、curl --http0.9 コマンドを叩くカスタム監視を実装するしかない?」 / Twitter, , https://twitter.com/miyahancom/status/1593475079069138944

[74] 最近インストールした nginx : HTTP/0.9 要求に HTTP/0.9 応答を返しました

[75] Cloudflare port 80 : Bad request とかかれた HTTP/0.9 応答を返しました。

[76] google.com port 80 : HTTP/1.0 応答を返しました。

[77] CloudFront port 80 : 505 エラー応答の HTTP/0.9 応答を返しました。

[78] AWS ALB port 80 : HTTP/0.9 応答を返しました。 (通常の応答のうち本体部分のみで状態符号やヘッダーはなし)