付録 C. 以前の RFC からの変更点 (Changes from Previous RFCs)
C.1. HTTP/0.9 からの変更 (Changes from HTTP/0.9)
HTTP/0.9 はリクエストでヘッダーフィールドをサポートしていなかったため、名前ベースの仮想ホスト (Host ヘッダーフィールドの検査によるリソースの選択) をサポートするメカニズムがありません。名前ベースの仮想ホストを実装するサーバーは、HTTP/0.9 のサポートを無効にすべきです。HTTP/0.9 のように見えるほとんどのリクエストは、実際には、クライアントがリクエストターゲットを適切にエンコードできなかったことによって引き起こされた、不適切に構築された HTTP/1.x リクエストです。
C.2. HTTP/1.0 からの変更 (Changes from HTTP/1.0)
C.2.1. マルチホーム Web サーバー (Multihomed Web Servers)
クライアントとサーバーが Host ヘッダーフィールド ([HTTP] の第 7.2 節) をサポートし、HTTP/1.1 リクエストから欠落している場合はエラーを報告し、絶対 URI (第 3.2 節) を受け入れるという要件は、HTTP/1.1 によって定義された最も重要な変更の 1 つです。
古い HTTP/1.0 クライアントは、IP アドレスとサーバーの一対一の関係を想定していました。リクエストが向けられた IP アドレス以外に、リクエストの意図されたサーバーを区別するための確立されたメカニズムはありませんでした。Host ヘッダーフィールドは、HTTP/1.1 の開発中に導入され、ほとんどの HTTP/1.0 ブラウザによって迅速に実装されましたが、完全な採用を確保するために、すべての HTTP/1.1 リクエストに追加の要件が課されました。この執筆時点で、ほとんどの HTTP ベースのサービスは、リクエストをターゲティングするために Host ヘッダーフィールドに依存しています。
C.2.2. Keep-Alive 接続 (Keep-Alive Connections)
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 サーバーとの持続的接続を有効にできますが、それらを使用するクライアントは、"hung" リクエスト (クライアントがヘッダーフィールドの送信を停止すべきであることを示す) のために接続を監視する必要があり、このメカニズムはプロキシが使用されている場合、クライアントによってまったく使用されるべきではありません。
C.2.3. Transfer-Encoding の導入 (Introduction of Transfer-Encoding)
HTTP/1.1 は、Transfer-Encoding ヘッダーフィールド (第 6.1 節) を導入しました。転送コーディングは、MIME 準拠プロトコル上で HTTP メッセージを転送する前にデコードする必要があります。
C.3. RFC 7230 からの変更 (Changes from RFC 7230)
HTTP の設計目標、履歴、アーキテクチャ、適合性基準、プロトコルのバージョン管理、URI、メッセージルーティング、およびヘッダーフィールドを紹介するセクションのほとんどは、[HTTP] に移動されました。この文書は、HTTP/1.1 に固有のメッセージング構文と接続管理要件のみに縮小されました。
裸の CR は、コンテンツの外側では禁止されています。(第 2.2 節)
authority-form の ABNF 定義は、URI のより一般的な authority コンポーネント (ポートがオプション) から、CONNECT によって要求される特定の host:port 形式に変更されました。(第 3.2.3 節)
受信者は、曖昧なメッセージフレーミングを処理する際に、スマグリング/分割攻撃を回避する必要があります。(第 6.1 節)
チャンク拡張の ABNF では、";" と "=" の周りの (悪い) 空白が再導入されました。空白は [RFC7230] で削除されましたが、その変更が既存の実装を破壊することがわかりました。(第 7.1.1 節)
トレーラーフィールドのセマンティクスは、チャンク転送コーディングの詳細を超越するようになりました。チャンクのデコードアルゴリズム (第 7.1.3 節) は、トレーラーフィールドをヘッダーフィールドとは別に保存/転送するか、受信者が対応するフィールド定義がマージを許可し、マージ方法を定義していることを知っている場合にのみヘッダーセクションにマージすることを奨励するように更新されました。そうでない場合は、マージする代わりにトレーラーフィールドを破棄します。トレーラー部分は、ヘッダーセクションとより一貫性を持たせ、本文部分とより区別するために、トレーラーセクションと呼ばれるようになりました。(第 7.1.2 節)
"q" と呼ばれる転送コーディングパラメータは、TE ヘッダーフィールドでのランクの使用との競合を避けるために禁止されています。(第 7.3 節)