この文章はインターネットコミュニティーに対して情報を提供する物である。この文章は如何なる意味においてもインターネットの規格を規定する物ではない。この文章の配布は無制限である。
この文章の配布は無制限である。コメントは<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はプロトコルのバージョンを示す時"<major>.<minor>" といった番号づけのやり方をする。このプロトコルのバージョンの付け方の方針は送り手にメッセージの形式や今の通信で得られたものの特徴を伝えるよりもむしろそれ以降のHTTP通信において理解できる能力を伝える事を目的としている。通信の振舞を変えないメッセージの中身の追加やフィールドの追加だけのような変更のときはバージョン番号は変更されない。マイナーバージョン番号は一般的なメッセージの構成要素の解析アルゴリズムに変更は無いが、メッセージの意味を付け加えるかもしれず、送った側のさらなる能力を伝えることを意図する時上がる。メジャーバージョン番号はプロトコル内でのメッセージの書式が変更された時上がる。同様な文言はHTTP/1.0[1]の記述にも現れる。
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]をサポートする時に要求されるであろう
これらの規則の結果としてHTTP/1.0の受け取り手に送られたHTTP/1.1のメッセージはHTTP/1.0の規格[1]に規定されていないヘッダを全て取り除いたとき、正しいHTTP/1.0のメッセージであるように構築されなければならない。
プロキシは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のバージョン番号の解釈に依存するような事の無い限り全く問題は無い