付録 A. HTTP バージョン履歴

HTTP は 1990 年から使用されています。最初のバージョンは、後に HTTP/0.9 と呼ばれるもので、インターネットを介したハイパーテキストデータ転送のための単純なプロトコルであり、単一のリクエストメソッド (GET) のみを使用し、メタデータを持ちませんでした。HTTP/1.0 は、[RFC1945] で定義されているように、一連のリクエストメソッドと MIME 風のメッセージングを追加し、メタデータの転送と、リクエスト/レスポンスのセマンティクスに置かれる修飾子を可能にしました。しかしながら、HTTP/1.0 は、階層的プロキシの影響、キャッシュ、持続的接続の必要性、および名前ベースの仮想ホストを十分に考慮していませんでした。不完全に実装されたアプリケーションが "HTTP/1.0" を自称することが蔓延したことは、2 つの通信するアプリケーションが互いの真の能力を判断できるようにするために、プロトコルバージョンの変更をさらに必要としました。

HTTP/1.1 は、信頼性のある実装を可能にするより厳格な要件を含めることによって HTTP/1.0 との互換性を保ち、HTTP/1.0 の受信者によって安全に無視できる機能、または HTTP/1.1 への適合を通知する相手と通信するときにのみ送信できる機能のみを追加しています。

HTTP/1.1 は、以前のバージョンのサポートを容易にするように設計されています。汎用の HTTP/1.1 サーバーは、HTTP/1.0 形式の任意の有効なリクエストを理解し、HTTP/1.0 クライアントが理解する (または安全に無視する) 機能のみを使用する HTTP/1.1 メッセージで適切に応答できるべきです。同様に、HTTP/1.1 クライアントは、任意の有効な HTTP/1.0 レスポンスを理解することが期待できます。

HTTP/0.9 はリクエストでヘッダーフィールドをサポートしていなかったため、名前ベースの仮想ホスト (Host ヘッダーフィールドの検査によるリソースの選択) をサポートする機構がありません。名前ベースの仮想ホストを実装するサーバーは、HTTP/0.9 のサポートを無効にすべきです。HTTP/0.9 に見えるリクエストのほとんどは、実際には、クライアントが request-target を適切にエンコードできなかったことに起因する、誤って構築された HTTP/1.x リクエストです。

A.1. HTTP/1.0 からの変更

このセクションは、HTTP/1.0 と HTTP/1.1 のバージョン間の主な違いを要約します。

A.1.1. マルチホーム Web サーバー

クライアントとサーバーが Host ヘッダーフィールド (セクション 5.4) をサポートすること、HTTP/1.1 リクエストからそれが欠けている場合にエラーを報告すること、および絶対 URI (セクション 5.3) を受け入れることの要件は、HTTP/1.1 によって定義された最も重要な変更の 1 つです。

古い HTTP/1.0 クライアントは、IP アドレスとサーバーの 1 対 1 の関係を前提としていました。リクエストの意図されたサーバーを区別するための、そのリクエストが向けられた IP アドレス以外の確立された機構はありませんでした。Host ヘッダーフィールドは HTTP/1.1 の開発中に導入され、ほとんどの HTTP/1.0 ブラウザーによってすぐに実装されましたが、完全な採用を保証するために、すべての HTTP/1.1 リクエストに追加の要件が課されました。この文章の執筆時点では、ほとんどの HTTP ベースのサービスが、リクエストのターゲット指定のために Host ヘッダーフィールドに依存しています。

A.1.2. Keep-Alive 接続

HTTP/1.0 では、各接続はリクエストの前にクライアントによって確立され、レスポンスを送信した後にサーバーによって閉じられます。しかしながら、一部の実装は、[RFC2068] のセクション 19.7.1 で説明されている、明示的にネゴシエートされる ("Keep-Alive") バージョンの持続的接続を実装しています。

一部のクライアントとサーバーは、"Connection: keep-alive" リクエストヘッダーフィールドで明示的にネゴシエートすることによって、これらの以前の持続的接続へのアプローチと互換でありたいと望む場合があります。しかしながら、HTTP/1.0 の持続的接続の一部の実験的な実装は欠陥があります。たとえば、HTTP/1.0 のプロキシサーバーが Connection を理解しない場合、そのヘッダーフィールドを次のインバウンドサーバーに誤って転送し、その結果、接続がハングします。

1 つの試みられた解決策は、プロキシを特に対象とした Proxy-Connection ヘッダーフィールドの導入でした。実際には、これも実行不可能でした。プロキシはしばしば複数の層に配備され、上記と同じ問題をもたらすためです。

その結果、クライアントは、いかなるリクエストでも Proxy-Connection ヘッダーフィールドを送信しないことが奨励されています。

また、クライアントは、リクエストでの Connection: keep-alive の使用を注意深く検討することが奨励されています。それらは HTTP/1.0 サーバーとの持続的接続を有効にできますが、それを使用するクライアントは、"ハングした" リクエスト (クライアントがそのヘッダーフィールドの送信を停止すべきことを示します) について接続を監視する必要があり、プロキシが使用されているときはクライアントがこの機構をまったく使用すべきではありません。

A.1.3. Transfer-Encoding の導入

HTTP/1.1 は、Transfer-Encoding ヘッダーフィールド (セクション 3.3.1) を導入します。転送コーディングは、HTTP メッセージを MIME 準拠のプロトコル上で転送する前にデコードされる必要があります。

A.2. RFC 2616 からの変更

HTTP のエラー処理へのアプローチが説明されました。(セクション 2.5)

HTTP-version の ABNF 生成規則は、大文字と小文字を区別することが明確化されました。さらに、実装が複数桁のバージョン番号を誤って処理することが知られているため、バージョン番号は 1 桁に制限されました。(セクション 2.6)

Userinfo (すなわち、ユーザー名とパスワード) は、ワイヤー上での送信に関連するセキュリティ上の問題のため、HTTP および HTTPS の URI で許可されなくなりました。(セクション 2.7.1)

HTTPS URI スキームは、本仕様によって定義されるようになりました。以前は、それは [RFC2818] のセクション 2.4 で行われていました。さらに、それはエンドツーエンドのセキュリティを意味します。(セクション 2.7.2)

HTTP メッセージは、実装によってバッファリングされ得ます (そしてしばしばそうされます)。ストリームとして利用可能な場合もありますが、HTTP は根本的にメッセージ指向のプロトコルです。相互運用性を向上させるために、さまざまなプロトコル要素の最小サポートサイズが提案されています。(セクション 3)

フィールド名の周囲の無効な空白は、それを受け入れることがセキュリティ脆弱性を表すため、拒否されることが要求されるようになりました。ヘッダーフィールドを定義する ABNF 生成規則は、フィールド値のみを列挙するようになりました。(セクション 3.2)

特定の文法生成規則間の暗黙の線形空白に関するルールが削除されました。現在では、空白は ABNF で明確に定義されている場所でのみ許可されます。(セクション 3.2.3)

複数行にまたがるヘッダーフィールド ("行折り返し") は非推奨です。(セクション 3.2.4)

NUL オクテットは、コメントおよび quoted-string のテキストで許可されなくなり、それらにおけるバックスラッシュエスケープの扱いが明確化されました。quoted-pair ルールは、HTAB 以外の制御文字のエスケープを許可しなくなりました。ヘッダーフィールドおよび reason phrase 内の非 US-ASCII の内容は廃止され、不透明にされました (TEXT ルールは削除されました)。(セクション 3.2.6)

不正な Content-Length ヘッダーフィールドは、受信者によってエラーとして扱われることが要求されるようになりました。(セクション 3.3.2)

メッセージ本文の長さを決定するアルゴリズムは、それに影響するすべての特殊なケース (例えば、メソッドまたはステータスコードによって駆動されるもの) を示すように明確化され、また、新しいプロトコル要素がそのような特殊なケースを定義できないことが明確化されました。CONNECT は、メッセージ本文の長さの決定における新しい特殊なケースです。"multipart/byteranges" は、メッセージ本文の長さの検出方法ではなくなりました。(セクション 3.3.3)

"identity" 転送コーディングトークンは削除されました。(セクション 3.3 および 4)

チャンク長には、チャンクヘッダーおよびトレーラー内のオクテット数は含まれません。チャンク拡張での行折り返しは許可されません。(セクション 4.1)

"deflate" コンテンツコーディングの意味が明確化されました。(セクション 4.2.2)

request-target を定義するために、RFC 1808 の abs_path ではなく、RFC 3986 の segment + query 構成要素が使用されました。request-target の asterisk-form は、OPTIONS メソッドでのみ許可されます。(セクション 5.3)

"Effective Request URI" という用語が導入されました。(セクション 5.5)

ゲートウェイは、もはや Via ヘッダーフィールドを生成する必要はありません。(セクション 5.7.1)

"close" 接続オプションをいつ送信しなければならないかが明確化されました。また、"hop-by-hop" ヘッダーフィールドは Connection ヘッダーフィールドに現れることが要求されます。本仕様で hop-by-hop として定義されているからといって、それらが免除されるわけではありません。(セクション 6.1)

サーバーあたり 2 つの接続という制限が削除されました。べき等なリクエストの系列を再試行することはもはや要求されません。サーバーが接続を時期尚早に閉じたときの特定の状況下でリクエストを再試行するという要件が削除されました。また、サーバーが接続を時期尚早に閉じることが許可される場合に関するいくつかの余分な要件が削除されました。(セクション 6.3)

Upgrade ヘッダーフィールドのセマンティクスは、101 以外のレスポンスでも定義されるようになりました (これは [RFC2817] から取り込まれました)。さらに、フィールド値の順序が重要になりました。(セクション 6.7)

リスト生成規則内の空のリスト要素 (例えば ", ," を含むリストヘッダーフィールド) は非推奨です。(セクション 7)

Transfer Coding の登録は、IETF Review を必要とするようになりました (セクション 8.4)

本仕様は、以前に [RFC2817] のセクション 7.2 で定義された Upgrade Token Registry を定義するようになりました。(セクション 8.6)

HTTP/0.9 リクエストをサポートするという期待が削除されました。(付録 A)

リクエスト内の Keep-Alive および Proxy-Connection ヘッダーフィールドの問題が指摘され、後者の使用は全面的に推奨されません。(付録 A.1.2)