HTTP/0.9

HTTP/0.9

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

仕様書

呼称

[47] 元々は単に「HTTP」と呼んでいましたが、新しい版 (HTTP2 と呼ばれたり、 HTTP/1.0 と呼ばれたりしたもの) が開発された時、区別するために HTTP/0.9 と呼ばれるようになりました。

[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] ChromeXHR で取得すると、 200 扱いになっているようです。

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

HTTP/1.0 との関係

[12] HTTP/1.0 HTTP/0.9 要求を処理できなければなりません >>10HTTP/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 は、 HEADPOST や未知の要求メソッドのときも、 400 を返します。

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

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

応答の解釈

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

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

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

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

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

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

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

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

応答の MIME 型

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

[37] 平文の転送のために HTMLplaintext タグが用意されています。
[29] ChromeIEsniffing しているようですが、 Firefoxtext/plain として扱っているようです。

歴史

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

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

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

[2] HTTP0.9 Summary -- /DesignIssues ( 版) http://www.w3.org/DesignIssues/HTTP0.9Summary.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] ApacheGET / HTTP/0.9 とかやってみたら、ほんとに HTTP/0.9 になりましたよ:−)

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

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

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

[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

[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

[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