Appendix B. Changes from RFC 2616 (RFC 2616からの変更)
このリビジョンの主な変更は編集的な性質のものです: メッセージ構文を抽出し、HTTPセマンティクスをコア機能、条件付きリクエスト、部分リクエスト、キャッシング、および認証のための個別のドキュメントに分割しました。適合性言語は要件を明確にターゲットするように改訂され、用語はペイロードと表現、および表現とリソースを区別するように改善されました。
URIに埋め込まれたセマンティクスがリクエストメソッドと矛盾する場合、それらのセマンティクスを無効にする必要があるという新しい要件が追加されました。これは相互運用性の失敗の一般的な原因であるためです。(セクション2)
ペイロードが特定の識別子に関連付けられているかどうかを判断するためのアルゴリズムが追加されました。(セクション3.1.4.1)
テキストメディアタイプのデフォルト文字セットISO-8859-1が削除されました。デフォルトは現在、メディアタイプ定義が指定する内容です。同様に、Accept-CharsetヘッダーフィールドのISO-8859-1に対する特別な扱いも削除されました。(セクション3.1.1.3およびセクション5.3.3)
Content-Locationの定義が変更され、相対URI参照を解決するためのベースURIに影響を与えなくなりました。これは、実装サポートが不十分であり、コンテンツネゴシエーションされたリソース内の相対リンクを破壊する可能性のある望ましくない効果があるためです。(セクション3.1.4.2)
[RFC7230]のメソッド中立的な解析アルゴリズムと一致させるために、GETの定義が緩和され、リクエストが本体を持つことができるようになりました。ただし、本体はGETには意味がありません。(セクション4.3.1)
サーバーはすべてのContent-*ヘッダーフィールドを処理する必要がなくなり、PUTリクエストでのContent-Rangeの使用が明示的に禁止されました。(セクション4.3.4)
CONNECTメソッドの定義が[RFC2817]からこの仕様に移動されました。(セクション4.3.6)
OPTIONSおよびTRACEリクエストメソッドが安全であると定義されました。(セクション4.3.7およびセクション4.3.8)
広く展開されている壊れた実装のため、Expectヘッダーフィールドの拡張メカニズムが削除されました。(セクション5.1.1)
Max-ForwardsヘッダーフィールドがOPTIONSおよびTRACEメソッドに制限されました。以前は、拡張メソッドもそれを使用できました。(セクション5.1.2)
参照URIが適用されない場合、Refererヘッダーフィールドの値として"about:blank" URIが提案されました。これにより、Refererフィールドが送信されないか削除された他のケースと区別されます。(セクション5.5.2)
次のステータスコードが現在キャッシュ可能です(つまり、明示的な新鮮度情報が存在しなくても、キャッシュによって保存および再利用できます): 204、404、405、414、501。(セクション6)
201 (Created) ステータスの説明が変更され、複数のリソースが作成された可能性を許可するようになりました。(セクション6.3.2)
203 (Non-Authoritative Information) の定義が拡張され、ペイロード変換のケースも含まれるようになりました。(セクション6.3.4)
自動的にリダイレクトしても安全なリクエストメソッドのセットはもはや閉じていません。ユーザーエージェントは、リクエストメソッドのセマンティクスに基づいてその判断を行うことができます。リダイレクトステータスコード301、302、および307には、レスポンスペイロードとユーザー操作に関する規範的要件がなくなりました。(セクション6.4)
ステータスコード301および302が変更され、ユーザーエージェントがメソッドをPOSTからGETに書き換えることが許可されるようになりました。(セクション6.4.2およびセクション6.4.3)
303 (See Other) ステータスコードの説明が変更され、明示的な新鮮度情報が与えられた場合にキャッシュすることが許可され、GETに対する303レスポンスの特定の定義が追加されました。(セクション6.4.4)
305 (Use Proxy) ステータスコードは、プロキシのインバンド構成に関するセキュリティ上の懸念のため、非推奨になりました。(セクション6.4.5)
400 (Bad Request) ステータスコードが緩和され、構文エラーに限定されなくなりました。(セクション6.5.1)
426 (Upgrade Required) ステータスコードが[RFC2817]から組み込まれました。(セクション6.5.15)
HTTP-dateおよびDateヘッダーフィールドに関する要件のターゲットが、日付を送信するすべてのシステムではなく、日付を生成するシステムに減少しました。(セクション7.1.1)
Locationヘッダーフィールドの構文が変更され、相対参照とフラグメントを含むすべてのURI参照が許可され、フラグメントの使用が適切でない場合についてのいくつかの明確化が行われました。(セクション7.1.2)
Allowがレスポンスヘッダーフィールドとして再分類され、PUTリクエストでそれを指定するオプションが削除されました。Allowの内容に関する要件が緩和されました。それに対応して、クライアントは常にその値を信頼する必要がありません。(セクション7.4.1)
メソッドレジストリが定義されました。(セクション8.1)
ステータスコードレジストリがこの仕様によって再定義されました。以前は、[RFC2817]のセクション7.1で定義されていました。(セクション8.2)
コンテンツコーディングの登録がIETFレビューを必要とするように変更されました。(セクション8.4)
Content-Dispositionヘッダーフィールドは、現在[RFC6266]によって定義されているため、削除されました。
Content-MD5ヘッダーフィールドは、部分レスポンスに関して実装が一貫していないため、削除されました。