[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
を使います。
[27] 状態行のプロトコルの版は、次のように解釈されます。
HTTP
(大文字または小文字)
/
先導0 整数 .
先導0 整数
が開始行にあれば、1つ目の整数が 2
以上か、
1つ目の整数が 1
で2つ目の整数が 1
以上なら、 HTTP/1.1。
HTTP
(大文字または小文字)
/
先導0 整数 .
が開始行にあれば、
整数が 2
以上なら、HTTP/1.1。
それ以外なら HTTP/1.0。HTTP
(大文字または小文字)
/1.
先導0 整数 が開始行にあれば、
整数が 1
以上なら、HTTP/1.1。それ以外なら HTTP/1.0。HTTP
(大文字または小文字) /
整数 .
整数 が開始行にあれば、
最初の整数の先頭1桁、.
、2つ目の整数を十進数の小数として解釈した時、 1.1
以上なら、
HTTP/1.1。それ以外なら、 HTTP/1.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) をクライアントが指定できますから、
サーバーは適当なものを選択できます。
[19] 次のプロトコル要素の構文や動作や適合性は、HTTPの版によって変わります。
version
引数 (MIME)#✎[527] MIME型 message/http
, application/http
の
version
引数は、
当該HTTPメッセージの HTTP の版を表します >>526, >>531。
[528] 構文は明記されていませんが、例として 1.0
RFC 1945
や 1.1
が挙げられています >>526, >>531。
HTTP uses a "<major>.<minor>" numbering scheme to indicate versions of the protocol. The protocol versioning policy is intended to allow the sender to indicate the format of a message and its capacity for understanding further HTTP communication, rather than the features obtained via that communication. No change is made to the version number for the addition of message components which do not affect communication behavior or which only add to extensible field values. The <minor> number is incremented when the changes made to the protocol add features which do not change the general message parsing algorithm, but which may add to the message semantics and imply additional capabilities of the sender. The <major> number is incremented when the format of a message within the protocol is changed. {2616} See RFC 2145 [36] for a fuller explanation.
HTTP はプロトコルの判を示すために <major>.<minor>
という番号付け方式を使います。プロトコル版付け方針は、
その通信を通して得られる特徴を示すものというよりは、
送信者がメッセージの書式と以降の HTTP 通信を理解する能力を示すことができるようにするものです。
通信動作に影響しないメッセージ部品や拡張可能な欄値を追加するだけのメッセージ部品の追加によっては版番号は変わりません。
<minor> 番号は、プロトコルに行われた変更がメッセージの意味を追加し、送信者の追加の能力を暗示しても、
一般メッセージ解析算法は変更しない特徴を加える時に増やします。
<major> 番号はプロトコル中のメッセージの書式が変更された時に増やします。 より完全な説明は RFC2145 を見て下さい。
The version of an HTTP message is indicated by an HTTP-Version field in the first line of the message.
{1945} If the protocol version is not specified, the recipient must assume that the message is in the simple HTTP/0.9 format.{errata} HTTP-Version is case-sensitive.
HTTP メッセージの版はメッセージの最初の行の HTTP-Version
欄で示します。 プロトコルの版が示されていない時は、受信者はそのメッセージが単純 HTTP/0.9 書式であると仮定しなければなりません。 HTTP-Version
は大文字・小文字を区別しません。
- HTTP-Version = "HTTP" "/" 1*DIGIT "." 1*DIGIT
Note that the major and minor numbers
{1945} shouldMUST be treated as separate integers and that eachmay{2616} MAY be incremented higher than a single digit. Thus, HTTP/2.4 is a lower version than HTTP/2.13, which in turn is lower than HTTP/12.3. Leading zeros{1945} shouldMUST be ignored by recipients and{1945} never generated by sendersMUST NOT be sent.
大番号と小番号は別の整数として扱うべきですわなければなりませんし、
それぞれの番号は単一の数字よりも大きく増やしても構いません。
従って、 HTTP/2.4
は HTTP/2.13
よりも小さな版で、 HTTP/2.13
は
HTTP/12.3
よりも小さな版です。受信者は先行する零を無視するべきですしなければなりませんし、
送信者は送信してはなりません。
{1945} This document defines both the 0.9 and 1.0 versions of the HTTP protocol.{1945,2068} Applications sendingAn application that sends a request or response message that includes HTTP-Version of "HTTP/1.1" MUST be at least conditionally compliant with this specification. Applications that are at least conditionally compliant with this specification SHOULD use an HTTP-Version of "HTTP/1.1" in their messages, and MUST do so for any message that is not compatible with HTTP/1.0. For more details on when to send specific HTTP-Version values, see RFC 2145 [36].{1945} Full-Request or{1945} Full-Response messages, as defined by this specification,{1945} mustMUST include an HTTP-Version of"HTTP/1.0""HTTP/1.1". {2068} Use of this version number indicates that the sending application is at least conditionally compliant with this specification.
;この文書は HTTP プロトコルの 0.9 と 1.0 の2つの版を定義します。 この仕様書で定義する通り Request
メッセージや Response
メッセージを送信する応用は、 HTTP/1.0
HTTP/1.1
の HTTP-Version
を含めなければなりません。 この版番号を使用することは、送信する応用がこの仕様書に少なくても条件的には適合することを示します。HTTP/1.1
の HTTP-Version
を含んだ要求メッセージまたは応答メッセージを送信する応用は、この仕様書に少なくても条件的に適合しなければなりません。この仕様書に少なくても条件的に適用する応用は、そのメッセージで HTTP/1.1
の HTTP-Version
を使用するべきですし、 HTTP/1.0 と互換ではないメッセージにはそうしなければなりません。いつ特定の HTTP-Version
値を送信するかについてより詳しくは RFC2145 を見て下さい。
{1945} HTTP/1.0 servers must:
- o recognize the format of the Request-Line for HTTP/0.9 and HTTP/1.0 requests;
- o understand any valid request in the format of HTTP/0.9 or HTTP/1.0;
- o respond appropriately with a message in the same protocol version used by the client.
HTTP/1.0 サーバーは、
Request-Line
書式を認識しなければなりません。HTTP/1.0 clients must:
- o recognize the format of the Status-Line for HTTP/1.0 responses;
- o understand any valid response in the format of HTTP/0.9 or HTTP/1.0.
HTTP/1.0 クライアントは、
Status-Line
の書式を認識しなければなりません。{2068,2616} The HTTP version of an application is the highest HTTP version for which the application is at least conditionally compliant.
応用の HTTP 版は、その応用が少なくても条件付で適合する最高の HTTP 版です。
Proxy and gateway applications
{1945,2068} must{2616} need to be carefulinwhen forwarding{1945} requests that are receivedmessages in{1945} a formatprotocol versions different from that of the application's {1945} native HTTP version. Since the protocol version indicates the protocol capability of the sender, a proxy/gateway{1945} must{2068,2616} MUST{1945,2068} never{2616} NOT send a message with a version indicator which is greater than its{1945} nativeactual version; if. {2616} If a higher version request is received, the proxy/gateway{1945} mustMUST either downgrade the request version{1945} or, {2068,2616} {2616} or respond with an error, {2068,2616} or switch to tunnel behavior.{1945,2068} Requests with a version lower than that of the{1945} application's native format mayproxy/gateway's version MAY be upgraded before being forwarded; the proxy/gateway's response to that request{1945} must follow the server requirements listed aboveMUST be in the same major version as the request.
串応用および関門応用は、応用の HTTP 版と異なるプロトコル版のメッセージを転送するときに用心する必要があります。
プロトコル版は送信者のプロトコル能力を示しますから、串・関門はその実際の版よりも大きな版識別子を持ったメッセージを送信してはなりません。
より大きな版の要求を受信した場合は、串・関門は要求の版を降下させるか、誤りで応答するか、またはトンネル動作に切り替えるかしなければなりません。 串・関門の版より小さな版の要求は転送の前に版を向上させても構いません。その要求に対する串・関門の応答は上述のサーバーの要件に従わなければなりません要求と同じ大版でなければなりません。
{2616} Due to interoperability problems with HTTP/1.0 proxies discovered since the publication of RFC 2068[33], caching proxies MUST, gateways MAY, and tunnels MUST NOT upgrade the request to the highest version they support. The proxy/gateway's response to that request MUST be in the same major version as the request.
RFC 2068 の出版後に発見された HTTP/1.0 串との互換性の相互運用性の問題のため、 要求を対応している最高の版に向上させることを、キャッシュ串は行わなければならず、 関門はしても構いませんが、トンネルは行ってはなりません。 その要求に対する串・関門の応答は要求と同じ大版でなければなりません。
{2068,2616} Note: Converting between versions of HTTP may involve modification of header fields required or forbidden by the versions involved.
注意 : HTTP の版間の変換は、その版が必須としていたり禁止指定いたりする頭欄の編集を行うこととなるかもしれません。
[7] RFC 2145 は HTTP の版番号の解釈についてまとめた RFC です。
[H3.1] applies, with HTTP replaced by RTSP.
[4]
SIP-Version
の定義が全く欠落しています。
SIP-Version: Both request and response messages include the version of SIP in use, and follow [H3.1] (with HTTP replaced by SIP, and HTTP/1.1 replaced by SIP/2.0) regarding version ordering, compliance requirements, and upgrading of version numbers. To be compliant with this specification, applications sending SIP messages MUST include a SIP-Version of "SIP/2.0". The SIP-Version string is case-insensitive, but implementations MUST send upper-case.
Unlike HTTP/1.1, SIP treats the version number as a literal string. In practice, this should make no difference.
要求メッセージと応答メッセージは、使用する SIP
の版を含み、版順序付け、適合要件、版番号の向上について RFC 2616 3.1 節を
(HTTP
を SIP
に、 HTTP/1.1
を SIP/2.0
に置換して) 従います。
この仕様書に適合するためには、 SIP メッセージを送信する応用は
SIP-Version
として SIP/2.0
を含めなければなりません。 SIP-Version
文字列は大文字・小文字を区別しませんが、
実装は大文字で送らなければなりません。
HTTP/1.1 とは異なり、 SIP は版番号を表記文字列として扱います。 実際上、これは何の違いもありません。
[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