top page > computer > web > rfc > rfc7230 > 2_6_protocol_versioning.html
更新日:
文責: 重城良国

RFC 7230 2.6. プロトコルバージョン

参照: RFC 7230 2.6

HTTP-versionの構造

リクエスト行やステータス行にはHTTP-versionが含まれる。HTTP-versionは以下のような構造をしている。

HTTP-version = HTTP-name "/" DIGIT "." DIGIT
HTTP-name = %x48.54.54.50; "HTTP", case-sensitive

HTTP/<major>.<minor>ということ。注意するべきことは"HTTP"の部分が大文字のみということと、バージョン番号には1桁のみが許されるということだ(RFC 2616からの変更点)。

メジャー番号とマイナー番号

RFC 7230ではバージョンは1.1である。

バージョンはメジャー番号とマイナー番号とから成る。メジャー番号はその通信で使われるバージョン番号を示すのに対して、マイナー番号はその通信で使えるバージョンの「最大値」を示す。

機能の追加のみで後方互換性を保った変更ではマイナー番号のみを上げるのに対して、後方互換性のない変更ではメジャー番号を上げるということで上のような仕様となっている。

無視されても意味論的に問題ないヘッダであれば、バージョン番号を変化させずに追加することができる。

接続を仲介する場合

HTTPの接続を単なるトンネルではなく仲介する場合には、バージョン番号をそのソフトウェアに合うように修正する必要がある。そうしないとそのソフトウェアが実装していない機能を使用されて接続エラーが生じる可能性がある。

クライアント

クライアントは、そのクライアントが準拠しているバージョンでメジャー番号がサーバのサポートしている最大のメジャー番号以下であるもののうちの最大のバージョンを送信するべきだ。

クライアントは以下の場合に限ってより低いバージョンを送信しても良い。すくなくとも1回は普通のバージョン番号を送信し、ステータスコードまたはヘッダからそのバージョン番号では、サーバの実装が不適切なために、通信ができないことを確認した場合。

サーバ

サーバは実装しているバージョンでメジャー番号がリクエスト行で指定されたバージョン以下であるバージョンのうち最大のバージョンを送信するべきだ。何らかの理由でクライアントのメジャーバージョンでのサービスを提供したくない場合、505エラーを返しても良い。

クライアントがより新しいバージョン番号を適切に処理できないことがわかっている場合には、サーバはバージョンとしてHTTP/1.0を送信しても良い。ただし、User-Agentフィールド等で不適切な実装を持つクライアントであることを確認した場合のみ、そうすることが望ましい。

個人的には

管理人の個人的なやりかたを書くと以下のようになるだろう。後方互換性は基本的に気にしないことにする。現在の最新の仕様に合わせることに労力を注ぐことにする。

クライアント

はじめのリクエスト行は"HTTP/1.1"ということになるだろう。応答のメジャーバージョンが0または2以上であったら、多分505エラーを返せば良いのだと思う(あとで調べる必要がある)。応答のマイナーバージョンが0だった場合には、その範囲内で要求していく必要がある。

サーバ

まずはメジャー番号0での接続は505エラーとする。メジャー番号2以上での接続も505エラーだ。メジャー番号が1の場合のみ応答することにする。この場合応答のバージョンは常に"HTTP/1.1"としておけば良い。ただし、リクエスト行のバージョンが"HTTP/1.0"の場合には、その範囲内で応答する必要がある。

HTTP/1.2以上は受け入れる必要がある

接続の相手がHTTP/1.xでxが2以上だった場合、HTTP/1.1の範囲内での接続にはなるが、接続できる必要がある。つまり、xの値のチェックの際に(x == 1)ではなく(x >= 1)とする必要がある。そうでないとRFC 7230の仕様に準拠していることにはならないと思われる。

HTTP/1.0を拒否することはできるか

HTTP/1.0での接続を拒否することはRFC 7230の仕様に準拠しているのか。その場合、505エラーを返せば良いのか。そこらへんはこの部分からは明らかではない。他を調べる必要がある。

正当なCSSです! HTML5 Powered with CSS3 / styling, and Semantics