この文章はインターネットコミュニティーに対して情報を提供する物である。 この文章は如何なる意味においてもインターネットの規格を規定する物ではない。 この文章の配布は無制限である。
この文章の配布は無制限である。コメントは<http-wg@cuckoo.hpl.hp.com> HTTP working groupに送って頂きたい。HTTP working groupでの議論は <URL:http://www.ics.uci.edu/pub/ietf/http/>に納められている。 一般的なHTTPやHTTPを使うアプリケーションについては<www-talk@w3.org> メーリングリストで行われるべきである。
HTTP要求と返答のメッセージはHTTPのプロトコルのバージョンを含んでいる。 HTTPバージョン番号の適切な使用と解釈の考え方や、違ったバージョン間で のHTTPの相互運用の実装についてはいくらか混乱がある。この文書は この状況を明確にする事を目的にしている。これは既存のHTTP/1.0とHTTP/1.1の 文書の意図する意味を変更する物ではなく、これらの文書を描いた作者の意図を 記述し、全てのバージョンのHTTPにおいて、これらHTTP/1.0とHTTP/1.1の HTTPバージョン番号についての曖昧な点を考える時の最終的なものと 考えても良い。
HTTP要求と返答のメッセージはHTTPのプロトコルバージョン番号を含んでいる。 HTTP/1.1仕様書の3.1節によると[2]
HTTPはプロトコルのバージョンを示す時"<major>.<minor>" といった番号づけのやり方をする。このプロトコルのバージョンの付け方の方針は 送り手にメッセージの形式や今の通信で得られたものの特徴を伝えるよりも むしろそれ以降のHTTP通信において理解できる能力を伝える事を目的としている。 通信の振舞を変えないメッセージの中身の追加やフィールドの追加だけのような変更 のときはバージョン番号は変更されない。マイナーバージョン番号は一般的な メッセージの構成要素の解析アルゴリズムに変更は無いが、メッセージの意味 を付け加えるかもしれず、送った側のさらなる能力を伝えることを意図する時 上がる。メジャーバージョン番号はプロトコル内でのメッセージの書式が変更された 時上がる。同様な文言はHTTP/1.0[1]の記述にも現れる。
これらの文書の多くの読者はこの方針の意味する所に関する混乱を表明 している。また、RFC1945[1]の出る前にHTTPの実装を書いた人の中には HTTP/1.0のバージョン番号が導入された意図に気づかなかった人もいる。 これにより、議論がまきおこり、HTTPバージョン番号の解釈を考える時の 非一貫性が起こり、いくつかの場合相互運用において問題が起こるように なった。
この文書ではこの状況を明確にしようと意図している。それは既存のHTTP/1.0 やHTTP/1.1の文書の意図している意味に変更を加えるのではなく、それらの 著者の言わんとしている所を記述している。どちらかの文書にHTTPバージョンの 解釈に関して曖昧な点があれば、この文書はHTTPの作者の意図に関して最終的な ものと考えるべきである。
この文書に記述されている規格はHTTP/1.0やHTTP/1.1のような 個々のHTTPのバージョンの一部ではない。むしろこの文書は如何なるバージョンの HTTPのバージョン番号の使い方について記述している。(バージョン番号を 含まないHTTP/0.9は除く)。
HTTPの実装のベンダーやその他の供給者は、この文書に示された規則に 従っていないIETF HTTPの規格に従うことを要求されることはない。
RFC791[4]の3.2節にてロバスト性の原則を次のように定義している。
自分が送る時は保守的で、受け取る時には寛容でなければならないこの原則はHTTPにも同様に適用される。それはずっと曖昧であった HTTPの規格の全ての部分の解釈に関する原則的な基礎である。特に HTTPの実装では不必要にメッセージを却下したりエラーを生成 するべきではない。
我々は上で引用したHTTP/1.1[2]3.1節を言い替える所から始めようと思う
以上の事をできるだけ明確に述べると、送られたメッセージのメジャーバージョンは 他のヘッダフィールドの解釈を示してもよい。メッセージのマイナー バージョンは他のヘッダフィールドの解釈を示してはいけない。これは マイナーバージョンが送り手の能力の特徴を示し、メッセージの解釈を示すもの ではないという原則を反映している。同じメジャーバージョン間でのマイナーバージョンの変更によってHTTPメッセージ ヘッダの解釈が変わる事は無いという事は明白なHTTP規格の 意図であったし、これからもそうである。
メッセージヘッダを受け取る時解釈のできないヘッダは無視しなければならない というのは明白なHTTP規格の意図であったしこれからもそうである。(「無視」 という単語はプロキシに関しては特別な意味を持つ。以下の2.1を見よ)
将来のHTTPのバージョンでは、明示的に受け取る側の実装を要求し、 ある種のヘッダを解釈できない時メッセージを却下するメカニズムを導入 するかも知れない。たとえば、これは、受け取り手に理解できるメッセージ ヘッダの集合を列挙する形で実装されるかもしれない。将来のバージョンの HTTPに従うHTTPの実装においてはこのメカニズムが導入されるであろう。 しかし低いバージョンのHTTPに従っている実装には(とくにHTTP/1.1) これを実装されることは要求されない。
この将来の変更はプロトコル拡張プロトコル(PEP)[3]をサポートする時に 要求されるであろう
プロキシはConnectionヘッダによって保護されていない限り知らないヘッダを 転送しなければならない。HTTPバージョン1.1以降を実装している プロキシはHTTP/1.1規格[2]14.10節に規定されているようにConnectionヘッダ によって保護されている知らないヘッダを転送してはいけない。
HTTPバージョン番号はHTTPメッセージの一行程間でのHTTPメッセージの 一部であって、始点と終点間の物ではないことを念を押しておく。つまり HTTPプロキシサーバーはHTTP要求に関しても返答に関してもHTTPバージョン 番号を転送することはない。
a<bとして受け取り手がHTTP/x.aとわかっている時、HTTP/x.bの実装は HTTP/x.aで規定されていないヘッダを送ってもよい。たとえば HTTP/1.1のサーバは"Cache-control"ヘッダをHTTP/1.0クライアントに 送っても良く、これは直接の受け取り手がHTTP/1.0のプロキシでも これは有用であるが、本来の受け取り手はHTTP/1.1のクライアントである。 a<bとしてHTTP/x.aとわかっている受け取り手にメッセージを送るHTTP/x. bの実装はHTTP/x.aの規格に規定されていないヘッダを受け取り手が解釈 する事に依存してはいけない。たとえば、HTTP/1.0のクライアントは Chunked Encodingを解釈する事を期待する事はできず、それゆえHTTP/1.1の サーバは"Transfer-Encoding:chunked"をHTTP/1.0要求にたいして返すことが あってはいけない。
HTTPバージョン番号の用途に関する激しい議論がロバスト性の原則に従って いない実装の問題を中心に行われた。その様な実装は自分が実装している よりも高いマイナーバージョンのメッセージを受け取ると有用な結果を生成 するのに失敗する。我々はこの様な実装はバグを含んでいる物と認識するが 同時にロバスト性の原則は真に相互運用性のために必要な時にはメッセージの 送り手が、バグを含んだ実装を意識するべきであるということを含んでいる。
HTTPクライアントは自分が従っている一番高いバージョンで、もしサーバの 側でサポートされているバージョンが判っていれば、それよりメジャーバージョン が高くない要求を送るべきである。HTTPクライアントは自分が 従っていないバージョンを送ってはいけない。
HTTPクライアントはもし、サーバが不正確にHTTP規格を実装していることが わかれば、下位バージョンの要求を送っても良い、が、それは クライアントが相手側のサーバが本当にバグを含んでいると決定できた後に 限られる。
HTTPサーバはメジャーバージョンが要求が含んでいるバージョンよりも 小さいか、同等である自分が従っている一番高いバージョンの応答を返 すべきである。HTTPサーバは、自分が従っていないバージョンを 送ってはいけない。HTTPサーバはクライアントの要求で使われている バージョンに答える事ができない時505(HTTP Version Not Suppoted)を返し てもよい。
HTTPサーバはもし、クライアントが正しくHTTP規格をサポートしていないと 判っているか、そう予測できる時低い応答のバージョンを送っても良い 、が、それをデフォルト動作にするべきでは無く、要求がHTTP/1.1またはそれ 以降の時はそうするべきではない。
あるバージョンに導入されたセキュリティー機構が古い実装のある HTTPのバージョン番号の解釈に依存するような事の無い限り全く 問題は無い