[20] HTTP/1.1 は、3つ目のHTTPの版です。多くのサーバーとクライアントにより広く実装されています。

仕様書

HTTP/1.0 との差異

[23] HTTP/1.0 と HTTP/1.1 には次のような差異があります。

[36] HTTP/1.1 を実装せずに HTTP/1.0 を実装するとしたら、その理由は chunked を実装したくないか、 1xx を実装したくないか、 またはその両方が理由でしょう。持続的接続を含めその他の HTTP/1.1 のみの機能は、クライアントも鯖も必要がなければ使わなくて済みます。

[41] WebDAV は HTTP/1.1 (の当時の仕様書である RFC 2616) に適合することを求めています >>40。 ただし HTTP/1.0 を使うことを明示的に禁止してはいません。 RFC 2616 に違反せずに HTTP/1.0 を使うことは可能ではあります。

[42] HTTP/1.0 の串におけるキャッシュを無効化し、 HTTP/1.1 の串にはキャッシュさせるために Expires: と Cache-Control: max-age を組み合わせる手法が用いられることがあります。ただし厳密にはプロトコルの版によって動作を変えているのではなく、 串が作られた時期による分岐となっています。(HTTP/1.0 の串は Cache-Control: を実装していないことを前提としていますが、 必ずしもそうとは言えないようです。また本来意図しているのは HTTP/1.0 かどうかの分岐ではなく、比較的新しい機能を正しく取り扱えるかどうかの分岐のようです。)

Expires: も参照。

HTTP/2 との差異

[46] HTTP/2 を参照。

プロトコルの版 HTTP/1.1

[37] 開始行などで用いられるプロトコルの版 HTTP/1.1 は、 HTTP/1.1 を表します。

[38] SSDP でも HTTP/1.1 を使いますが、後方互換性のためで、 HTTP/1.1 ではないとされています >>39。

プロトコル http/1.1

[44] TLS ALPN のプロトコル 0x68 0x74 0x74 0x70 0x2f 0x31 0x2e 0x31 (http/1.1) は、 RFC 7230 HTTP/1.1 を表します >>43。

[50] 代替サービスのプロトコル名 http/1.1 は、 HTTP/1.1 over TLS を表します >>49。

歴史

[22] HTTP/1.1 は、 RFC 1945 によって規定される HTTP/0.9 や HTTP/1.0 と並行する第3の HTTP の版として IETF によって定義されました。

HTTP/1.1 は HTTP/1.0 の改訂版ではありますが、実際上も手続き上も HTTP/0.9 および HTTP/1.1 を置き換えるものとはなっていません。 HTTP/1.1 の開発開始から20年経った後も HTTP/0.9 は実装されています。

第1次仕様 (RFC 2068, RFC 2069)

  • [7] RFC 2068
  • [8] RFC 2069

[28] 後に補足的な内容を含む RFC 2145 が発行されています。

第2次仕様 (RFC 2616, RFC 2617)

  • [5] RFC 2616
  • [6] RFC 2617
  • [3] HTTP/1.1 Specification Errata http://world.std.com/~lawrence/http_errata.html

第3次仕様 (RFC 7230-7237)

[52] 第3次仕様 RFC 723x は、十数年ぶりにに出版されました。

  • [1] Revising RFC2616 - what's happening from Mark Nottingham on 2006-10-18 (ietf-http-wg@w3.org from October to December 2006) http://lists.w3.org/Archives/Public/ietf-http-wg/2006OctDec/0046.html (名無しさん 2006-10-21 12:19:38 +00:00)
  • [2] RFC2616bis Issues http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/ (名無しさん 2006-11-12 10:25:01 +00:00)

[4] に RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235, RFC 7236, RFC 7237 が発行されました。関連仕様として RFC 7238, RFC 7239, RFC 7240 も発行されています。

[21] これらの RFC は RFC 2616 と RFC 2145 を廃止して置き換える他、 RFC 2617 と RFC 2817 と RFC 2818 の一部を更新するものとされています。

  • [15] RFC 7236 - Initial Hypertext Transfer Protocol (HTTP) Authentication Scheme Registrations ( 版) https://tools.ietf.org/html/rfc7236
  • [16] RFC 7237 - Initial Hypertext Transfer Protocol (HTTP) Method Registrations ( 版) https://tools.ietf.org/html/rfc7237
  • [17] RFC 7238 - The Hypertext Transfer Protocol Status Code 308 (Permanent Redirect) ( 版) https://tools.ietf.org/html/rfc7238
  • [18] RFC 7239 - Forwarded HTTP Extension ( 版) https://tools.ietf.org/html/rfc7239
  • [19] RFC 7240 - Prefer Header for HTTP ( 版) https://tools.ietf.org/html/rfc7240

[30] 従来の RFC を全面改訂して再編しており、以前の版よりは大幅に記述が改善され、 比較的詳細になっています。

[31] とはいえ所詮は IETF 品質で、同時代の他の Web標準 (WHATWG の HTML Standard や TC39 の ECMAScript など) と比較すると遥かに簡易的で曖昧です。

[32] 本体仕様だけでも6分割もされているため、RFC の境界部分で若干の曖昧性や規定の重複が起こっています。 また古くからの要件を非網羅的に適宜列挙する形の仕様書となっていますから、 境界条件が曖昧だったり、複数の規定の条件が重複してかつ若干異なっていたり、 起こり得るケースの一部のみしか規定されていなかったりします。 誤り処理に関する規定も前の版に比べるとかなり増えていますが、それでもほとんどの部分では (意図的に) 規定されていません。

[29] RFC 723x は SHOULD を避けるためか、 ought to という表現をかなり頻繁に用いています。しかしその意図するところは説明されておらず、 どの程度の温度感で勧めているのかはよくわからなくなっています。

[51] 元々1つの文書にまとまっていたのがたくさんの RFC に分割され、 何がどこに書かれているのかは高度な訓練を経ないとわからなくなりました。

HTTP/2

[47] 2015年には HTTP/2 が RFC として出版されています。 HTTP/2 はヘッダーや状態符号などの語彙の部分は HTTP/1.1 の規定をほぼそのまま参照しており、 HTTP/1.1 を完全に置き換えるものとはなっていません。 また、 (少なくても現時点では) HTTP/2 のプロトコルは HTTP/1.1 のプロトコルと選択的に利用するものとなっており、 HTTP/1.1 を廃止するものではありません。

[48] 手続き上も HTTP/1.1 の RFC は廃止されていません。
[53] RFC 8006 - Content Delivery Network Interconnection (CDNI) Metadata () https://tools.ietf.org/html/rfc8006#section-7.3

| http/1.1 | Hypertext Transfer | RFC 8006 | RFC 7230 |

| | Protocol -- HTTP/1.1 | | |