[1] protocol は、プロトコルの名前と版を表す構文です。
仕様書
- [2] RFC 7230 - Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing ( 版) https://tools.ietf.org/html/rfc7230#section-6.7
- [9] RFC 7230 - Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing ( 版) https://tools.ietf.org/html/rfc7230#section-2.6
- [11] RFC 7230 - Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing ( 版) https://tools.ietf.org/html/rfc7230#section-5.7.1
- [20] RFC 7230 - Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing ( 版) https://tools.ietf.org/html/rfc7230#section-8.6
- [17] Hypertext Transfer Protocol (HTTP) Upgrade Token Registry ( 版) http://www.iana.org/assignments/http-upgrade-tokens/http-upgrade-tokens.xhtml
- [23] RFC 3507 - Internet Content Adaptation Protocol (ICAP) ( 版) http://tools.ietf.org/html/rfc3507#section-4.3.2
- [30] RFC 7540 - Hypertext Transfer Protocol Version 2 (HTTP/2) ( 版) https://tools.ietf.org/html/rfc7540#section-3.2
文脈
[3] protocol やそれに類する構文は、
次の場面で利用されます。
- プロトコルの版 (開始行)
Upgrade: ヘッダー >>2Via: ヘッダーのプロトコル >>2SERVER_PROTOCOL メタ変数
[4] product (User-Agent:, Server:,
Via: の注釈) も類似した構文を採用していますが、
プロトコルではなく製品を表すものとなっています。
構文
[5] protocol は、プロトコル名のみか、またはプロトコル名とプロトコル版を/ で区切ったものです
>>2。
[6] プロトコル名とプロトコル版は、いずれも字句です >>2。
- 字句
- ?
/- 字句
[7] 大文字と小文字の区別の有無は明記されておらず、区別するものとみられます。
HTTPの版では区別すると明記されています >>9。
[8] 歴史的には、区別しないという解釈もありました。HTTPの版や
SERVER_PROTOCOL の項を参照してください。
また Web Sockets は、区別しない Upgrade:
の処理を定義しています。[13] SERVER_PROTOCOL では、値に更に制限があります。
[12] HTTPの版では、プロトコル版の値に更に制限があります。
[10] Via: では、プロトコル名が HTTP
の場合、プロトコル名と / を省略できることになっています。
プロトコル版は省略できません。
- ?
- 字句
/
- 字句
プロトコルの一覧
[14] プロトコルとしては、次の値が利用されています。
| プロトコル | Upgrade: | Via: | HTTPの版 | SERVER_PROTOCOL |
|---|
CATP/1.0 | | | ○ | |
CATP/1.1 | | | ○ | |
fix | ○ |
GridHTTP/1.0 | ○ | | | |
h2 | ○ | | | |
h2c | ○ | | | |
HTTP/0.9 | × | × | △ | ○ |
HTTP/1.0 | × | ○ | ○ | ○ |
HTTP/1.1 | ? | ○ | ○ | ○ |
HTTP/2.0 | | | ○ | ○ |
HTTP/2 | | | | ○ |
ICAP/1.0 | | ○ | ○ | |
ICE | | | ○ |
ICY | | | ○ |
INCLUDED | | | | ○ |
MRCP/2.0 | | | ○ | |
PTTH/0.9 | ○ | | | |
PTTH/1.0 | ○ | | | |
Q4S/1.0 | | | ○ | |
RTSP/1.0 | | | ○ | |
Secure-HTTP/1.4 | | | ○ | |
SIP/2.0 | | ○ | ○ | ○ |
tcpUpgrade: tcp | ○ |
TLS/1.0 | ○ | | | |
TLS/1.1 | ○ | | | |
TLS/1.2 | ○ | | | |
WebSocket | ○ | | | |
WebSocket/13 | | | | ○ |
[15] この他に、 HTTP の RFC には例示として
HTTP/2.0, IRC/6.9,
SHTTP/1.3, RTA/x11
という架空の Upgrade: ヘッダーの値が登場します。
[24] この一覧は >>25 に JSON 形式で収録されています。
- [25] data-web-defs/headers.txt at master · manakai/data-web-defs ( 版) https://github.com/manakai/data-web-defs/blob/master/doc/headers.txt
IANA 登録簿
[16] Upgrade: の値については、 IANA登録簿 >>17 が用意されています
>>20。
[18] IANA登録簿は RFC 2817 により設けられました >>26, >>27。
- [26] RFC 2817 - Upgrading to TLS Within HTTP/1.1 ( 版) http://tools.ietf.org/html/rfc2817#section-7.2
- [27] RFC Errata Report ( 版) http://www.rfc-editor.org/errata_search.php?rfc=2817
[19] 2003年12月の時点で、登録簿には一つも登録されていません。
HTTP 仕様書で定義されている HTTP/* や
登録手続きを規定している RFC 2817 が定義している TLS/1.0
すら載っていないのはなんとも間抜けな話です (が、 IANAREG では良くある話です)。
[22] その後いつからか、 TLS/1.0 も登録されました。
また、 WebSocket も登録されています。
[21] RFC 7230 は新しい登録手続きを定義しています。
手続きは First Come First Served となっています >>20。
更に HTTP も登録しています >>20。
[28] 気づいたら TLS/1.0 は TLS に変わっています。
RFC 2817 は TLS/1.0 を規定していましたが、 RFC正誤表が
TLS を規定し、 TLS の版を指定できる形に改めています >>27。
[29] 現在の IANA登録簿は、 RFC 2818 (のみ) を出典に、
版は「ANY DIGIT.DIGIT (e.g.. "1.2")」と説明しています >>17。
しかも「IANA登録簿は既に修正されている」>>27 ともされています。
そんな勝手な変更をしないで素直に RFC を改訂してくれればいいのですが...[31] HTTP/2 において Upgrade: h2HTTP/2 は無視しなければならない
>>30 と規定されていますが、なぜかこの h2 という値は登録されていません。
予約状態で登録されていても良さそうなものですが。
[32] 869725 – support shoutcast streams
()
https://bugzilla.mozilla.org/show_bug.cgi?id=869725