[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互換とはいえません。
[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。
[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 となります。
[64]
HTTP/0.9要求に対応できないHTTPサーバーもあるようです。
[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。
[23] MIME型は Content-Type: ヘッダーが無い場合のように
Content-Type sniffing によって決定されるものと思われます。
元々は HTML のみが使われることが想定されていました。
[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 を知ることができません。
[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
ライブドア・データホテル・パトロールというサービスを使っている.これはなかなかのすぐれもので,ウェブサーバの監視をはじめ証明書の期限切れ検知などにも使えるのだが,最近lighttpdを使っているウェブサービスの死活監視に使ってみてHTTP/0.9のリクエストになっているのかなと思った.
というのはlighttpdにtelnetで接続して「GET / 」と打つと400 Bad Requestになるのだが,データホテル・パトロールでも確かに400を検出して異常が検知されたことになる.
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.
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
[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
[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
200扱いになっているようです。