これは、私、渡辺 が個人的に興味を持 って訳した物であり、訳の正しさについては保証しません。 原文と照らし会わせて 御覧ください RFC 2145: HTTPのバージョン番号の使い方と解釈について。 この文章の位置付け。 この文章はインターネットコミュニティーに対して情報を提供する物である。 この文章は如何なる意味においてもインターネットの規格を規定する物ではない。 この文章の配布は無制限である。 この文章の配布は無制限である。コメントは HTTP working groupに送って頂きたい。 HTTP working group での議論は に納められている。一般的な HTTP や HTTP を使うアプリケーションについては メーリング リストで行われるべきである。 概要 HTTP要求と返答のメッセージはHTTPのプロトコルのバージョンを含んでいる。 HTTP バージョン番号の適切な使用と解釈の考え方や、違ったバージョン間で のHTTPの相 互運用の実装についてはいくらか混乱がある。この文書は この状況を明確にする事 を目的にしている。これは既存のHTTP/1.0とHTTP/1.1の 文書の意図する意味を変更 する物ではなく、これらの文書を描いた作者の意図を 記述し、全てのバージョンの HTTPにおいて、これらHTTP/1.0とHTTP/1.1の HTTPバージョン番号についての曖昧な 点を考える時の最終的なものと 考えても良い。 目次 * 導入 o ロバスト性の原則 * HTTPのバージョン番号 o プロキシのふるまい o 同じメジャーバージョンの違ったマイナーバージョン間の互換性 o メッセージの中ではどのバージョンを送るべきか * セキュリティーについて * 参考文献 * 作者のアドレス 導入 HTTP要求と返答のメッセージはHTTPのプロトコルバージョン番号を含んでいる。 HTTP/1.1仕様書の3.1節によると[2] HTTPはプロトコルのバージョンを示す時"." といった番号 づけのやり方をする。このプロトコルのバージョンの付け方の方針は 送 り手にメッセージの形式や今の通信で得られたものの特徴を伝えるよりも むしろそれ以降の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バージョン番号 我々は上で引用した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