[404] HTTP には、 HTTP/0.9、HTTP/1.0、HTTP/1.1、HTTP/2 の4つの版 (バージョン) があります。
HTTP-version
構文[2] HTTP でプロトコルの版を示すために使われる部分が
HTTP-version
で、例えば
HTTP/1.1 のように斜線で区切ってプロトコル名とプロトコル版を並べた文字列になっています。
[2] HTTP 派生プロトコルである RTSP や SIP も同様な構文である
RTSP-Version
や
SIP-Version
を定義しています。
[509] HTTPメッセージには (古の HTTP/0.9 を除いて)
必ず HTTP-Version
が最初の行に入ることになっています。
受信側はこれを見てどう返答するのかを決めることになります。
[3] 関連プロトコルでも *-Version
を使うことがあります。例えば、 CGI
で使われるメタ変数 SERVER_PROTOCOL
は受信したメッセージの *-Version
になります。
[525] これらは、他のヘッダーで使われることがある protocol
構文の特別な形となっています。
[41] CATP/1.0 chap.3, , https://catill.bitbucket.io/CATP/catp/chap3.html
[42] null, , https://catill.bitbucket.io/CATP/catp1.1/honbun.html#_Toc464618947
CATPバージョンは、リクエストで用いられるCATPのバージョンを示す。本プロトコルのCATPバージョンは、"CATP/1.0"を用いる。
[43] >>42 CATP/1.1 なのに値は CATP/1.0
?
[8] HTTP では IW:RFCErrata:2616 で大文字と小文字を区別する旨が追記されています。
ところがすべての RFC でこの点には言及されていません。 しかも ABNF の規定 (2.1) により、 この部分の大文字・小文字は区別しないことになっていました。
[9] 実装の方はといいますと、 Apache
は小文字のにも対応しています。
適当なプロトコル名を入れると 400 Bad Request
になりますが、 http/1.0
とか入れてもそうはなりません。
他の実装の中にはきっと小文字だと受け付けないものもあるのでしょう。
[10] RTSP はこの点では完全に HTTP (RFC 2068) 参照なので、 大文字・小文字も両方きっと使えるんだろうなーという状態です。
[11] SIP は RFC 3261 で大文字・小文字を区別しないが、 出力の際は必ず大文字にしないといけないといっています。 この規定が一番妥当な線ですよね。
[406] 版番号には大版 (整数部) と小版 (小数部) があります。
[512] RFC 7230 では、メジャーバージョンとマイナーバージョンはそれぞれASCII数字 1桁とされています >>508。
[513] RFC 1945、RFC 2068、RFC 2616 と RTSP では、 それぞれ1桁以上のASCII数字とされていました。
[514] SIP では、 2.0
とされています >>5。
[15] HTTP/2 での値は、明確には規定されていません。クライアント接続序文では、
HTTP/2.0
を使います。
HTTP-Version
(相当) の一覧[402] HTTP と派生プロトコルにおける HTTP-Version
(相当)
の一覧は、 protocol
の項を参照してください。
[511] HTTPメッセージにおける HTTP-version
は、
送信者がその版の HTTP 仕様に適合することを表しています >>508。
[515] メジャーバージョンは、HTTPメッセージの構文を表します >>508。
[408] HTTP-version
におけるマイナーバージョンは、
メジャーバージョン内で送信者が適合し理解できる最大のマイナーバージョンを表します
>>508。
送信者の能力を示すもので、メッセージの解釈は示しません >>405 2.。
[520] HTTPメッセージを処理する中間器 (つまりトンネル以外の中間器) は、自身のプロトコルの版を転送するメッセージに含めなければなりません。 >>508
[517] ヘッダーの解釈は、同じメジャーバージョンのマイナーバージョン間では変わりません。 ただしヘッダーが無い時の既定の動作は変わるかもしれません。 >>508
[518] 明記されていない限り、 HTTP/1.1 のヘッダーは他の HTTP/1.x に対しても定義されています >>508。
[411] 串は Connection:
ヘッダーで保護されている場合を除き、
未知のヘッダーを転送しなければなりません >>405 2.1。
[519] 新しいヘッダーを導入する場合、それを認識しない受信者が安全に無視できるなら、 プロトコルの版を変更しなくて構いません。 >>508
[409] 版番号が不明、または HTTP/1.0 の受信者に対して HTTP/1.1 のメッセージを送る時には、 HTTP/1.0 で定義されていないヘッダーをすべて削除した時に HTTP/1.0 メッセージとして妥当なものでなければなりません。 >>405 2.
[412] 送信者のマイナーバージョンより受信者のマイナーバージョンの方が小さい時であっても、 大きなマイナーバージョンの方にしかないヘッダーを含めても構いません。 しかし受信者がそれを解釈できることに依存してはなりません。 >>405 2.2
[413] 例えば HTTP/1.1 鯖は HTTP/1.0 クライアントに
(RFC 1945 で定義されていない) Cache-Control:
を送っても構いません。
しかし (同じく RFC 1945 で定義されていない) Transfer-Encoding: chunked
はメッセージの解釈自体を変えるものですから、送ってはいけません。 >>405 2.2
[414] なお串で版番号が書き換わることがありますから、 HTTP/1.1
鯖が送信する相手は HTTP/1.0 の串かもしれませんが、その先のクライアントは
HTTP/1.1 Cache-Control:
を理解できるかもしれません。
(が chunked
は HTTP/1.0 串の時点で解釈がおかしくなってしまうので、
使ってはいけません。)
[20] HTTP接続の確立時には、プロトコルの版を決定する必要があります。
[21] HTTP/1.1 以下では、クライアントが要求の開始行でプロトコルの版を指定し、 サーバーがそれを見て応答のプロトコルの版を決めます。両エンドポイント間でプロトコルの版が異なることもあります。プロトコルの版は、メジャーバージョンとマイナーバージョンで構成されます。
[22] HTTP/2 では、両エンドポイントが HTTP/2 を使う必要があります。 プロトコルの版は 2 で、マイナーバージョンはありません。
[522] 受信者は、対応しているメジャーバージョンの未対応のマイナーバージョンのメッセージを受け取った時は、 対応している最大のマイナーバージョンに従い解釈するべきです >>508。
[516] HTTP/1.1 メッセージを HTTP/1.0 受信者や版不明の受信者に送信する時には、 新機能を無視すれば妥当な HTTP/1.0 メッセージとして解釈できるように構築することになっています >>508。
[410] 版番号は末端対末端ではなくホップ毎のものです >>405 2.1 から、串は中継する時に別の HTTPの版になることがあります。
[70] 利用者エージェントのプロトコルの版の決定方法は、figerprinting vector です。
[415] クライアントは、(少なくても条件的に適合する)
最高のHTTPの版で要求を送信するべきです。
部分的にも適合しない版を送ってはなりません。 >>405 2.3, >>508
[416] ただし鯖が対応しているメジャーバージョンが分かっているときは、それ以下のメジャーバージョンとするべきです。 鯖が HTTP を正しく実装していないとわかっていて、一度は通常の要求を送ってみて実際に不具合があると判別できたときには、 より低い版で送信して構いません。 >>405 2.3, >>508
[523] HTTP/0.9 要求は勧められませんです >>14。
[23] HTTPS では、 ALPN でプロトコルの版の候補を提示することができます。 HTTP/2 over TLS では ALPN を使わなければなりません。
[51] http:
URL への接続について、
HTTP/2 は Upgrade: h2c
により HTTP/1.1 over TCP から HTTP/2 over TCP
へと移行する方法を規定しています。この方法を実装するクライアントは、
常に HTTP/1.1 で接続を開始できます。
Upgrade: h2c
参照。[67] Alt-Svc:
などで事前にサーバーが HTTP/2
に対応していると知っている場合は、 http:
URL
への接続時に、はじめから HTTP/2 を用いることができます。
クライアントは、接続序文を送信しなければなりません。
その後すぐにフレームを送信できます。サーバーは、
接続序文を送信しなければなりません。 >>47
[417] 鯖は、(少なくても条件的に適合する) 最高のHTTPの版であって、
要求のメジャーバージョン以下のものにより応答を送信するべきです。
部分的にも適合しない版を送ってはなりません。 >>405 2.3, >>508
[506] クライアントが HTTP を正しく実装していないとわかっているか、
していないと思われる時には、HTTP/1.0 で送っても構いませんが、
User-Agent:
などによりそうであると判定できる場合に限ります >>508。
[418] 鯖は、要求のメジャーバージョンで応答を送れない、送りたくない時は、
505
応答を送って構いません。 >>405 2.3, >>508
[17] HTTP/0.9 要求には HTTP/0.9 応答を返さなければなりません >>16。
[24] HTTPS では、 ALPN で http/1.1
(HTTP/1.1) や
h2
(HTTP/2) をクライアントが指定できますから、
サーバーは適当なものを選択できます。
version
引数 (MIME)[527] MIME型 message/http
, application/http
の
version
引数は、
当該HTTPメッセージの HTTP の版を表します >>526, >>531。
[528] 構文は明記されていませんが、例として 1.0
RFC 1945
や 1.1
が挙げられています >>526, >>531。
[7] RFC 2145 は HTTP の版番号の解釈についてまとめた RFC です。
[4]
SIP-Version
の定義が全く欠落しています。
[532] RFC 3507 - Internet Content Adaptation Protocol (ICAP) ( ( 版)) http://tools.ietf.org/html/rfc3507#section-4.3.2
[35] RFC 8170 - Planning for Protocol Adoption and Subsequent Transitions () https://tools.ietf.org/html/rfc8170#appendix-A.4
[37] Test HTTP parsing by annevk · Pull Request #5102 · w3c/web-platform-tests () https://github.com/w3c/web-platform-tests/pull/5102
[38] Add nextHopProtocol HTTP/0.9 and 1.0. Link to QUIC (yoavweiss著, ) https://github.com/w3c/resource-timing/commit/95339a2740a9220f548ca40ebfdb98e48cbde086
[39] Add nextHopProtocol HTTP/0.9 and 1.0. Link to QUIC by yoavweiss · Pull Request #159 · w3c/resource-timing () https://github.com/w3c/resource-timing/pull/159
[40] Changing HTTP version on a connection · Issue #127 · httpwg/http-core () https://github.com/httpwg/http-core/issues/127