メインコンテンツまでスキップ

ハイパーテキスト転送プロトコル (HTTP/1.1): メッセージ構文とルーティング

  • ステータス: Proposed Standard
  • 発行日: June 2014
  • ストリーム: IETF
  • 更新: RFC2817, RFC2818
  • 廃止: RFC2145, RFC2616
  • 廃止: RFC9110, RFC9112
  • エラッタ: エラッタなし

Document Information / 文档信息​

  • RFC Number: 7230
  • Title: HTTP/1.1: Message Syntax and Routing
  • Published: June 2014
  • Authors: R. Fielding (Adobe), J. Reschke (greenbytes)
  • Status: Standards Track
  • Obsoletes: RFC 2616, RFC 2145
  • Updates: RFC 2817, RFC 2818

Abstract / 摘要​

ハイパーテキスト転送プロトコル (HTTP) は、分散型の協調的なハイパーテキスト情報システムのための状態レスなアプリケーション層プロトコルです。

This document provides an overview of HTTP architecture and its associated terminology, defines the "http" and "https" Uniform Resource Identifier (URI) schemes, defines the HTTP/1.1 message syntax and parsing requirements, and describes related security concerns for implementations.

Table of Contents / 目录​

Main Sections / 主要章节​

  1. Introduction (简介)

    • 1.1 Requirements Notation
    • 1.2 Syntax Notation

  2. Architecture (架构)

    • 2.1 Client/Server Messaging
    • 2.2 Implementation Diversity
    • 2.3 Intermediaries
    • 2.4 Caches
    • 2.5 Conformance and Error Handling
    • 2.6 Protocol Versioning
    • 2.7 Uniform Resource Identifiers

  3. Message Format (消息格式)

    • 3.1 Start Line
    • 3.2 Header Fields
    • 3.3 Message Body

  4. Transfer Codings (传输编码)

    • 4.1 Chunked Transfer Coding
    • 4.2 Compression Codings
    • 4.3 TE Header Field
    • 4.4 Trailer Header Field

  5. Message Routing (消息路由)

    • 5.1 Identifying a Target Resource
    • 5.2 Connecting Inbound
    • 5.3 Request Target
    • 5.4 Host Header Field
    • 5.5 Effective Request URI
    • 5.6 Associating a Response to a Request
    • 5.7 Message Forwarding

  6. Connection Management (连接管理)

    • 6.1 Connection Header Field
    • 6.2 Establishment
    • 6.3 Persistence
    • 6.4 Concurrency
    • 6.5 Failures and Timeouts
    • 6.6 Tear-down
    • 6.7 Upgrade Header Field

  7. ABNF List Extension (ABNF 列表扩展)

  8. IANA Considerations (IANA 考虑事项)

  9. Security Considerations (安全考虑事项)

Appendices / 附录​

  • Appendix A - HTTP Version History
  • Appendix B - Collected ABNF
  • References (参考文献)

HTTP/1.1 Specification Series / HTTP/1.1 规范系列​

RFC 7230 is the first part of the HTTP/1.1 specification series:

  1. RFC 7230 - Message Syntax and Routing (本文档)
  2. RFC 7231 - Semantics and Content
  3. RFC 7232 - Conditional Requests
  4. RFC 7233 - Range Requests
  5. RFC 7234 - Caching
  6. RFC 7235 - Authentication

Core Concepts / 核心概念​

Key Terms / 关键术语​

  • Client: Program that establishes a connection to send HTTP requests
  • Server: Program that accepts connections to service HTTP requests
  • User Agent: Client program that initiates requests (browsers, crawlers, etc.)
  • Origin Server: Program that can originate authoritative responses
  • Intermediary: Proxy, gateway, or tunnel
  • Cache: Local storage of previous responses

HTTP Message Structure / HTTP 消息结构​

HTTP-message   = start-line
                 *( header-field CRLF )
                 CRLF
                 [ message-body ]

Request Example / 请求示例​

GET /hello.txt HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0
Accept-Language: ja

Response Example / 响应示例​

HTTP/1.1 200 OK
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache
Content-Length: 51
Content-Type: text/plain

Hello World! My payload includes a trailing CRLF.

Important Features / 重要特性​

  1. Stateless Protocol - Each request is processed independently
  2. Persistent Connections - HTTP/1.1 uses persistent connections by default
  3. Chunked Transfer Encoding - Allows sending data without knowing total length
  4. Intermediary Support - Supports proxies, gateways, and tunnels
  5. Protocol Upgrade - Supports upgrading to other protocols (e.g., WebSocket)

Security Considerations / 安全考虑​

  1. Input Validation - Always validate and sanitize user input
  2. Length Limits - Implement limits on request line and header field lengths
  3. Use HTTPS - Use TLS encryption for sensitive communications
  4. Prevent Request Smuggling - Strictly follow message parsing rules
  5. Intermediary Security - Carefully handle proxies and gateways
  6. Privacy Protection - Protect personal information in server logs

Copyright Notice / 版权声明​

Copyright © 2014 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions.

1. Introduction (はじめに)​

Hypertext Transfer Protocol (HTTP, ハイパーテキスト転送プロトコル) は、分散型で協調的なハイパーテキスト情報システムのためのステートレスなリクエスト/レスポンスプロトコルです。このドキュメントは、HTTP/1.1を定義する一連のドキュメントの最初の部分です。

このドキュメントの主な内容は次のとおりです:

  • HTTPアーキテクチャの全体的な概要とその関連用語
  • "http" および "https" Uniform Resource Identifier (URI, 統一資源識別子) スキームの定義
  • HTTP/1.1メッセージ構文と解析要件
  • 実装に関連するセキュリティ上の考慮事項

HTTP/1.1メッセージ構文と解析要件は、相互運用性を向上させ、既知の曖昧さを減らすために、RFC 2616を基に改訂されています。このドキュメントは、RFC 2616の特定の部分を置き換え、HTTP/1.1セマンティクスを定義する他のドキュメントと一緒に使用されます。

HTTPの他の部分は、以下の独立したドキュメントで定義されています:

  1. "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content" [RFC7231] - リクエストメソッド、ステータスコード、およびプロトコルセマンティクスに関連するその他の要素を定義します
  2. "Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests" [RFC7232] - 条件付きリクエストのメカニズムを定義します
  3. "Hypertext Transfer Protocol (HTTP/1.1): Range Requests" [RFC7233] - 部分的なリクエストとレスポンスを定義します
  4. "Hypertext Transfer Protocol (HTTP/1.1): Caching" [RFC7234] - キャッシュの要件と制御を定義します
  5. "Hypertext Transfer Protocol (HTTP/1.1): Authentication" [RFC7235] - ユーザー認証フレームワークを定義します

1.1. Requirements Notation (要件表記)​

このドキュメントのキーワード "MUST" (しなければならない)、"MUST NOT" (してはならない)、"REQUIRED" (必須)、"SHALL" (するものとする)、"SHALL NOT" (しないものとする)、"SHOULD" (すべきである)、"SHOULD NOT" (すべきではない)、"RECOMMENDED" (推奨される)、"MAY" (してもよい)、および "OPTIONAL" (オプション) は、[RFC2119] に記載されているとおりに解釈されるものとします。

適合性基準と考慮事項は、Section 2.5 で説明されています。

1.2. Syntax Notation (構文表記)​

この仕様は、[RFC5234] の Augmented Backus-Naur Form (ABNF, 拡張バッカス・ナウア記法) 表記法を使用し、Section 7 で定義されているリスト拡張を使用して、# 演算子を使用してコンマ区切りリストのコンパクトな定義を可能にします。Appendix B は、他のドキュメントからインポートされたルールを説明しています。

次のコアルールは、[RFC5234] の Appendix B.1 で定義されているとおり、参照によって含まれています: ALPHA (文字)、CR (キャリッジリターン)、CRLF (CR LF)、CTL (制御文字)、DIGIT (10進数 0-9)、DQUOTE (二重引用符)、HEXDIG (16進数 0-9/A-F/a-f)、HTAB (水平タブ)、LF (ラインフィード)、OCTET (8ビットのデータシーケンス)、SP (スペース)、および VCHAR (可視US-ASCII文字)。

慣例として、"obs-" で始まる ABNF ルール名は、歴史的な理由で表示される "obsolete" (廃止された) 文法ルールを示します。

2. Architecture (アーキテクチャ)​

HTTPは当初、文書指向の情報システム用のアプリケーション層プロトコルとして設計されました。HTTPのアーキテクチャはこの設計を反映しており、シンプルなリクエスト/レスポンスプロトコルとして定義されています。クライアントはリクエストメソッド、URI、プロトコルバージョンを含むリクエストメッセージをサーバーに送信し、続いてリクエスト修飾子、クライアント情報、および可能な表現内容を含むMIME風のメッセージを送信します。サーバーは、メッセージプロトコルバージョン、成功またはエラーコードを含むステータス行で応答し、続いてサーバー情報、エンティティメタ情報、および可能なエンティティコンテンツを含むMIME風のメッセージで応答します。

HTTPは基盤となるトランスポート層またはセッション層接続プロトコルから独立しています。HTTPは、リクエストとレスポンスの順序配信を保証できる信頼性の高いトランスポートのみを前提としています。HTTP/1.1メッセージの基盤となるトランスポートデータユニットへのマッピングは、本仕様の範囲外です。

HTTPは、閉鎖的な企業ネットワークからオープンなインターネット、組み込みデバイスから大規模なマルチプロセッサシステム、自動化されたエージェントから一般ユーザーのWebブラウザ、物理的にサーバーに近いクライアントから複数の仲介者とネットワークを横断するクライアントまで、さまざまな環境で使用されてきました。これらすべての環境において、実装はHTTPセマンティクスに関連する攻撃を回避または軽減するために慎重に設計する必要があります。

2.1. Client/Server Messaging (クライアント/サーバーメッセージング)​

HTTPは、クライアントとサーバー間でメッセージを交換することによって動作するステートレスなリクエスト/レスポンスプロトコルです。

HTTP-message   = start-line
                 *( header-field CRLF )
                 CRLF
                 [ message-body ]

クライアント (client) は、リクエストメソッド、URI、プロトコルバージョンの形式でHTTPリクエスト (request) をサーバーに送信し、続いてリクエスト修飾子、クライアント情報、および可能な表現内容を含むMIME風のメッセージを送信します。サーバー (server) は、メッセージプロトコルバージョンと成功またはエラーコードを含むステータス行の形式で1つ以上のHTTPレスポンス (response) で応答し、続いてサーバー情報、エンティティメタ情報、および可能な表現内容を含むMIME風のメッセージで応答します。

クライアントとサーバー間の接続はいずれの側からも閉じることができます。たとえば、クライアントは完全なレスポンスを受信した後に接続を閉じることができ、またはサーバーはタイムアウト期限が切れたときに接続を閉じることができます。

通常、HTTP通信は、クライアントが特定のサーバー上の特定のポートとのTCP/IP接続を確立することによって開始されます。HTTP/1.1では、接続の確立はURIスキームによって暗黙的に示されます。"http"スキーム (Section 2.7.1) は、TCP/IP接続を介してネットワークリソースを特定するために使用され、デフォルトでTCPポート80を使用しますが、他のポートも使用できます。

接続が確立されると、クライアントはHTTPリクエストメッセージをサーバーに送信します。

リクエストを受信して解釈した後、サーバーは1つ以上のHTTPレスポンスメッセージで応答します。

2.2. Implementation Diversity (実装の多様性)​

HTTPの"クライアント"または"サーバー"について話すとき、私たちはプログラムが一般的にできることのラベルではなく、特定の接続でそのプログラムが果たす役割を指しています。ユーザーエージェント (user agent) という用語は、リクエストを開始する任意のプログラムを指します。オリジンサーバー (origin server) という用語は、特定のターゲットリソースに対して権威ある応答を提供できるプログラムを指します。

HTTPは、Uniform Resource Identifiers (URI, 統一資源識別子) 標準 [RFC3986] に依存して、ターゲットリソース (Section 5.1) とリソース間の関係を示します。

メッセージは、インターネットメール [RFC5322] および Multipurpose Internet Mail Extensions (MIME, 多目的インターネットメール拡張) [RFC2045] で使用される形式に類似した形式で伝送されます。

2.3. Intermediaries (仲介者)​

HTTPでは、仲介者 (intermediaries) を使用してリクエストを満たすことができます。これは、可能な変換チェーンを通じてリクエストを渡すことによって行われます。3つの一般的なHTTP仲介者の形式があります: プロキシ (proxy)、ゲートウェイ (gateway)、およびトンネル (tunnel) です。

プロキシ (Proxy) は、クライアントによって選択されたメッセージ転送エージェントであり、通常はローカル構成ルールを介して、特定のタイプの絶対URIへのリクエストを受信し、必要に応じて変換を介してHTTPインターフェイス経由でこれらのリクエストを満たそうとします。

ゲートウェイ (Gateway) (「リバースプロキシ」とも呼ばれる) は、オリジンサーバー層の前面として機能し、オリジンサーバーの代わりにリクエストを受信する仲介者です。

トンネル (Tunnel) は、2つの接続間のブラインドリレーとして機能し、メッセージを変更せずに中継します。アクティブになると、トンネルはHTTP通信の一部とは見なされなくなります。

2.4. Caches (キャッシュ)​

キャッシュ (cache) は、以前のレスポンスメッセージのローカルストレージと、その保存、取得、および削除を制御するサブシステムです。キャッシュは、将来の同等のリクエストのレスポンス時間とネットワーク帯域幅の消費を削減するために、キャッシュ可能なレスポンスを保存します。

2.5. Conformance and Error Handling (適合性とエラー処理)​

本仕様は、送信者、受信者、クライアント、サーバー、ユーザーエージェント、仲介者、オリジンサーバー、プロキシ、ゲートウェイ、およびキャッシュの役割に対する適合性基準を定義しています。

メッセージを送信する実装 (つまり送信者) は、その送信者の役割に対するそのメッセージのプロトコル要素の構文とセマンティクスに準拠したメッセージのみを送信しなければなりません。

受信メッセージが無効であると思われる場合、またはメッセージ解析中にセマンティック無効性が検出された場合、受信者は適切なエラーステータスコードを含むレスポンスを送信するか (リクエストを受信したサーバーの場合)、またはメッセージを破棄して接続を閉じるか (すべての受信者の場合) すべきです。

2.6. Protocol Versioning (プロトコルバージョン管理)​

HTTPは、"<major>.<minor>"番号付けスキームを使用してプロトコルのバージョンを示します。本仕様はバージョン"1.1"を定義しています。

バージョン番号は、"."(ピリオドまたは小数点) で区切られた2つの小数桁で構成されます。最初の数字 ("major version", メジャーバージョン番号) は、HTTPメッセージ構文を示し、2番目の数字 ("minor version", マイナーバージョン番号) は、そのメジャーバージョン内で送信者が準拠し、将来の通信を理解できる最高のマイナーバージョンを示します。

2.7. Uniform Resource Identifiers (統一資源識別子)​

Uniform Resource Identifiers (URI, 統一資源識別子) [RFC3986] は、リソースを識別する手段としてHTTP全体で使用されます。

2.7.1. http URI Scheme (http URIスキーム)​

"http" URIスキームは、HTTPプロトコルを介してアクセス可能なリソースを識別するためにここで定義されています。

http-URI    = "http:" "//" authority path-abempty [ "?" query ]
              [ "#" fragment ]

2.7.2. https URI Scheme (https URIスキーム)​

"https" URIスキームは、暗号化された接続を介してアクセス可能なリソースを識別するためにここで定義されています。

https-URI   = "https:" "//" authority path-abempty [ "?" query ]
              [ "#" fragment ]

2.7.3. http and https URI Normalization and Comparison (httpおよびhttps URIの正規化と比較)​

"http"および"https"スキームは [RFC3986] で定義された一般的な構文に準拠しているため、そのようなURI参照の正規化と比較は、それぞれのスキームのデフォルトポート (httpの場合は80、httpsの場合は443) を使用して [RFC3986], [Section 6] で定義されたアルゴリズムの下で実行されます。

3. Message Format (メッセージ形式)​

すべてのHTTP/1.1メッセージは、インターネットメッセージ形式 [RFC5322] に類似した構造の一連のオクテットで構成されています: 起動行、ゼロ個以上のヘッダーフィールド (まとめて"headers"または"header section", ヘッダーセクションと呼ばれます)、ヘッダーセクションの終わりを示す空行、およびオプションのメッセージ本文。

HTTP-message   = start-line
                 *( header-field CRLF )
                 CRLF
                 [ message-body ]

3.1. Start Line (起動行)​

HTTPメッセージは、クライアントからサーバーへのリクエストか、サーバーからクライアントへのレスポンスのいずれかです。構文的には、2つのメッセージタイプは起動行でのみ異なります。起動行は、リクエストの場合はリクエスト行 (request-line) であり、レスポンスの場合はステータス行 (status-line) です。

start-line     = request-line / status-line

3.1.1. Request Line (リクエスト行)​

リクエスト行は、メソッドトークンで始まり、その後にスペース (SP)、リクエストターゲット、別のスペース (SP)、プロトコルバージョン、そしてCRLFで終わります。

request-line   = method SP request-target SP HTTP-version CRLF

methodトークンは、ターゲットリソースに対して実行するリクエストメソッドを示します。リクエストメソッドは大文字と小文字を区別します。

method         = token

3.1.2. Status Line (ステータス行)​

レスポンスメッセージの最初の行はステータス行で、プロトコルバージョン、スペース (SP)、ステータスコード、別のスペース、空の可能性があるテキストフレーズ (ステータスコードを説明する)、およびCRLFで構成されます。

status-line = HTTP-version SP status-code SP reason-phrase CRLF

status-code要素は、サーバーがクライアントの対応するリクエストを理解して満たそうとした試みの結果を説明する3桁の整数コードです。

status-code    = 3DIGIT
reason-phrase  = *( HTAB / SP / VCHAR / obs-text )

3.2. Header Fields (ヘッダーフィールド)​

各ヘッダーフィールドは、大文字と小文字を区別しないフィールド名、コロン (":")、オプションの先行空白、フィールド値、およびオプションの後続空白で構成されます。

header-field   = field-name ":" OWS field-value OWS

field-name     = token
field-value    = *( field-content / obs-fold )
field-content  = field-vchar [ 1*( SP / HTAB ) field-vchar ]
field-vchar    = VCHAR / obs-text

obs-fold       = CRLF 1*( SP / HTAB )

3.2.1. Field Extensibility (フィールド拡張性)​

ヘッダーフィールドは完全に拡張可能です。フィールド名のレジストリや特定のメッセージに表示される可能性のあるフィールドセットについての事前定義された制限はありません。

3.2.2. Field Order (フィールド順序)​

受信者は、同じフィールド名を持つ複数のヘッダーフィールドを任意の順序で結合できます。各後続のフィールド値を順番に結合されたフィールド値に追加し、コンマで区切ります。

3.2.3. Whitespace (空白)​

本仕様は、線形空白の使用を表すために3つのルールを使用します: OWS (optional whitespace, オプション空白)、RWS (required whitespace, 必須空白)、およびBWS ("bad" whitespace, "悪い"空白)。

OWS            = *( SP / HTAB )
RWS            = 1*( SP / HTAB )
BWS            = OWS

3.2.4. Field Parsing (フィールド解析)​

メッセージは、行折り返し (つまり、1つのヘッダーフィールドを複数の行に分割できる) を使用して送信できます。これは、各追加行の前に少なくとも1つのSPまたはHTABを付けることによって行われます。行折り返しは [RFC2616] で定義され許可されていましたが、現在は非推奨です。

送信者は、HTTP/1.1 (またはそれ以降) メッセージで行折り返しを使用するメッセージを生成してはなりません。

サーバーは、リクエストメッセージでobs-foldを受信した場合、適切な4xx (Client Error, クライアントエラー) ステータスコードで応答してメッセージを拒否するか、各受信したobs-foldを1つ以上のSPオクテットに置き換えてから結果のメッセージを処理しなければなりません。

3.2.5. Field Limits (フィールド制限)​

HTTPは、ヘッダーフィールド名または値の長さ、またはヘッダーセクションの全体の長さに対して事前定義された制限はありません。

サーバーは、処理したいものよりも大きなヘッダーフィールド、フィールド行、またはフィールドセットを受信した場合、適切な4xx (Client Error) ステータスコードで応答しなければなりません。

3.2.6. Field Value Components (フィールド値コンポーネント)​

ほとんどのHTTPヘッダーフィールド値は、空白または特定の区切り文字で区切られた共通の構文コンポーネント (トークン、引用文字列、およびコメント) を使用して定義されています。

token:

token          = 1*tchar
tchar          = "!" / "#" / "$" / "%" / "&" / "'" / "*"
               / "+" / "-" / "." / "0-9" / "A-Z" / "^" / "_"
               / "`" / "a-z" / "|" / "~"

quoted-string:

quoted-string  = DQUOTE *( qdtext / quoted-pair ) DQUOTE
qdtext         = HTAB / SP / %x21 / %x23-5B / %x5D-7E / obs-text
quoted-pair    = "\" ( HTAB / SP / VCHAR / obs-text )

comment:

comment        = "(" *( ctext / quoted-pair / comment ) ")"
ctext          = HTAB / SP / %x21-27 / %x2A-5B / %x5D-7E / obs-text

parameter:

parameter      = token "=" ( token / quoted-string )

3.3. Message Body (メッセージ本文)​

HTTP/1.1メッセージのメッセージ本文 (存在する場合) は、ターゲットリソースの表現データ ([RFC7231]) またはリクエストのペイロードを運ぶために使用されます。

message-body = *OCTET

3.3.1. Transfer-Encoding​

Transfer-Encodingヘッダーフィールドは、メッセージ本文を形成するためにペイロード本文に適用されたエンコーディングのシーケンスに対応する転送エンコーディング名をリストします。

Transfer-Encoding = 1#transfer-coding

3.3.2. Content-Length​

Transfer-Encodingヘッダーフィールドがメッセージに存在しない場合、Content-Lengthヘッダーフィールド ([RFC7231], [Section 3.3.2]) は、メッセージ本文の予想サイズ (オクテット単位) を受信者に提供できます。

Content-Length = 1*DIGIT

3.3.3. Message Body Length (メッセージ本文の長さ)​

メッセージ本文の長さは、次のいずれかの方法で決定されます (優先順位順):

  1. HEADリクエストメソッドへの任意のレスポンスおよびすべての1xx (Informational, 情報)、204 (No Content, コンテンツなし)、304 (Not Modified, 未変更) レスポンスは、ヘッダーセクション後の最初の空行で常に終了し、メッセージにどのヘッダーフィールドが存在していても、したがってメッセージ本文を含むことはできません。

  2. CONNECTリクエストメソッドへの任意の2xx (Successful, 成功) レスポンスは、レスポンスヘッダーセクションの直後に接続がトンネルになることを意味します。

  3. Transfer-Encodingヘッダーフィールドが存在し、chunked転送エンコーディングが最終エンコーディングである場合 (Section 4 で定義)、転送エンコーディングがデータが完了したことを示すまで、チャンクされたデータを読み取ってデコードすることによってメッセージ本文の長さが決定されます。

  4. メッセージにContent-Lengthヘッダーフィールドが含まれている場合、そのフィールド値 (10進数の数字シーケンスで表される非負整数) は、オクテット単位の予想されるメッセージ本文の長さを定義します。

  5. これがリクエストメッセージであり、上記のルールのいずれも適用されない場合、メッセージ本文の長さはゼロ (メッセージ本文は存在しません) です。

  6. それ以外の場合、これはメッセージ本文の長さを宣言していないレスポンスメッセージであり、したがってメッセージ本文の長さは、サーバーが接続を閉じる前に受信したオクテット数によって決定されます。

3.4. Handling Incomplete Messages (不完全なメッセージの処理)​

サーバーが完全なレスポンスを送信する前に接続を閉じることは、通常、サーバー側でエラーまたはタイムアウトが発生したことを示します。クライアントは、リクエストを安全に再試行できるかどうかを決定できます。

3.5. Message Parsing Robustness (メッセージ解析の堅牢性)​

この仕様は送信者の動作に対して厳格な要件を定義していますが、すべてのHTTP実装が仕様に準拠しているわけではありません。

受信メッセージのヘッダーフィールド値に、そのフィールド定義のABNF外の1つ以上のオクテットが含まれている場合 (ヘッダーフィールド行の開始または終了の空白を含む)、またはそのABNF外で観察される折り返しのオクテットが含まれている場合、メッセージは無効として解析される可能性があります。

受信者は、区切りオクテット (CR、LF、またはNULなど) をヘッダーフィールド値の一部として解釈してはなりません。

4. Transfer Codings (転送エンコーディング)​

転送エンコーディング (Transfer codings) 名は、ネットワーク経由での"安全な転送"を確保するために、ペイロード本文に適用された、適用できる、または適用する必要がある可能性のあるエンコーディング変換を示すために使用されます。

transfer-coding    = "chunked"
                   / "compress"
                   / "deflate"
                   / "gzip"
                   / transfer-extension
transfer-extension = token *( OWS ";" OWS transfer-parameter )
transfer-parameter = token BWS "=" BWS ( token / quoted-string )

4.1. Chunked Transfer Coding (チャンク転送エンコーディング)​

チャンク転送エンコーディング (chunked transfer coding) は、ペイロード本文を一連のチャンクにラップし、各チャンクには独自のサイズインジケータがあり、その後にオプションでトレーラーフィールドを含むトレーラーセクションが続きます。

chunked-body   = *chunk
                 last-chunk
                 trailer-part
                 CRLF

chunk          = chunk-size [ chunk-ext ] CRLF
                 chunk-data CRLF
chunk-size     = 1*HEXDIG
last-chunk     = 1*("0") [ chunk-ext ] CRLF
chunk-data     = 1*OCTET

chunk-size (チャンクサイズ) フィールドは、チャンクデータのサイズ (オクテット単位) を示す16進数の文字列です。

受信者は、チャンク転送エンコーディングを解析およびデコードできなければなりません。

4.1.1. Chunk Extensions (チャンク拡張)​

チャンク転送エンコーディングでは、各チャンクにゼロ個以上のチャンク拡張 (chunk extensions) を含めることができます。

chunk-ext      = *( ";" chunk-ext-name [ "=" chunk-ext-val ] )
chunk-ext-name = token
chunk-ext-val  = token / quoted-string

4.1.2. Chunked Trailer Part (チャンクトレーラーパート)​

トレーラー (trailer) により、送信者は、メッセージ本文の送信中に動的に生成される可能性のあるメタデータを提供するために、チャンクメッセージの最後に追加のヘッダーフィールドを含めることができます。

trailer-part   = *( header-field CRLF )

送信者は、トレーラーに Transfer-Encoding、Content-Length、または Trailer フィールドを生成してはなりません。

4.1.3. Decoding Chunked (チャンクのデコード)​

チャンク転送エンコーディングをデコードするプロセスは、次のように実装できます (疑似コードを使用):

length := 0
read chunk-size, chunk-ext (if any), and CRLF
while (chunk-size > 0) {
   read chunk-data and CRLF
   append chunk-data to decoded-body
   length := length + chunk-size
   read chunk-size, chunk-ext (if any), and CRLF
}
read trailer field
while (trailer field is not empty) {
   if (trailer field is allowed to be sent in a trailer) {
      append trailer field to existing header fields
   }
   read trailer-field
}
Content-Length := length
Remove "chunked" from Transfer-Encoding

4.2. Compression Codings (圧縮エンコーディング)​

次の3つの圧縮エンコーディング名は、HTTP/1.0との互換性のために定義されています。

4.2.1. Compress Coding (Compress エンコーディング)​

"compress"エンコーディングは、適応型Lempel-Ziv-Welch (LZW) エンコーディング [Welch] であり、通常はUNIXファイル圧縮プログラム"compress"によって生成されます。

4.2.2. Deflate Coding (Deflate エンコーディング)​

"deflate"エンコーディングは、Lempel-Ziv (LZ77) 圧縮アルゴリズムとHuffmanエンコーディングの組み合わせを使用する"deflate"圧縮データストリーム [RFC1951] を含む"zlib"データ形式 [RFC1950] です。

4.2.3. Gzip Coding (Gzip エンコーディング)​

"gzip"エンコーディングは、32ビット巡回冗長検査 (CRC) を備えたLZ77エンコーディングであり、通常はgzipファイル圧縮プログラム [RFC1952] によって生成されます。

4.3. TE​

"TE"ヘッダーフィールドは、chunked以外にクライアントがレスポンスの一部として受け入れる転送エンコーディングと、クライアントがトレーラーフィールドを受け入れるかどうかを示します。

TE        = #t-codings
t-codings = "trailers" / ( transfer-coding [ t-ranking ] )
t-ranking = OWS ";" OWS "q=" rank
rank      = ( "0" [ "." 0*3DIGIT ] )
          / ( "1" [ "." 0*3("0") ] )

4.4. Trailer​

送信者が最後のチャンクのトレーラーセクションに送信するヘッダーフィールドを知っている場合、送信者はこれらのヘッダーフィールド名のリストを含む Trailer ヘッダーフィールドを送信すべきです。

Trailer = 1#field-name

5. Message Routing (メッセージルーティング)​

HTTPリクエストメッセージのルーティングは、ターゲットリソース、プロキシ構成、およびネットワーク接続の確立または再利用に基づいて、クライアントによって決定されます。

5.1. Identifying a Target Resource (ターゲットリソースの識別)​

HTTPは、単一のオリジンサーバーがいくつの異なるリソースに対して権威ある応答を提供できるか、単一のリソースの権限の範囲、または単一のリソースを参照する可能性のあるURI空間を制限しません。

5.2. Connecting Inbound (インバウンド接続)​

クライアントがURIまたはその構成を調べることによってターゲットURIとオリジンサーバーまたはプロキシを決定すると、クライアントはどこに接続するかを決定します。

5.3. Request Target (リクエストターゲット)​

ターゲットへのインバウンド接続が確立されると、クライアントはHTTPリクエストメッセージ (Section 3) を送信します。その起動行 (start-line) には、リクエストを適用すべきターゲットリソースを識別するリクエストターゲット (request-target) が含まれます。

request-target = origin-form
               / absolute-form
               / authority-form
               / asterisk-form

5.3.1. origin-form​

最も一般的なリクエストターゲット形式は"origin-form"です。

origin-form    = absolute-path [ "?" query ]

5.3.2. absolute-form​

プロキシへのリクエストを行う場合、CONNECTまたはサーバー全体のOPTIONSリクエスト (以下で説明) を除いて、クライアントはリクエストターゲットとしてターゲットURIのabsolute-formを送信しなければなりません。

absolute-form  = absolute-URI

5.3.3. authority-form​

authority-formリクエストターゲットは、CONNECTリクエスト ([RFC7231], [Section 4.3.6]) にのみ使用されます。

authority-form = authority

5.3.4. asterisk-form​

asterisk-formリクエストターゲットは、サーバー全体のOPTIONSリクエスト ([RFC7231], [Section 4.3.7]) にのみ使用されます。

asterisk-form  = "*"

5.4. Host​

"Host"ヘッダーフィールドは、リクエストでターゲットURIのホストとポート情報を提供し、オリジンサーバーが単一のIPアドレスで提供されるリソースを区別できるようにします。

Host = uri-host [ ":" port ]

クライアントは、すべてのHTTP/1.1リクエストメッセージで Host ヘッダーフィールドを送信しなければなりません。

5.5. Effective Request URI (有効リクエストURI)​

リクエストターゲットがabsolute-formの場合、有効リクエストURI (effective request URI) はリクエストターゲットです。

5.6. Associating a Response to a Request (レスポンスのリクエストへの関連付け)​

HTTPは、レスポンスに識別子を含めて特定のリクエストに明示的に関連付けることはありません。したがって、レスポンスがどのリクエストに関連付けられているかを識別するために基盤となる接続に依存します。

5.7. Message Forwarding (メッセージ転送)​

Section 2.3 で説明されているように、仲介者は、出力サーバーのプロキシとして機能したり、オリジンサーバーの表現として機能するゲートウェイとして機能したり、接続トンネルとして機能したりできます。

5.7.1. Via​

"Via"ヘッダーフィールドは、リクエストメッセージとレスポンスメッセージ間の仲介プロトコルと受信者の存在を示します。

Via = 1#( received-protocol RWS received-by [ RWS comment ] )

received-protocol = [ protocol-name "/" ] protocol-version
received-by       = ( uri-host [ ":" port ] ) / pseudonym
pseudonym         = token

各仲介者は、メッセージを転送する前に Via ヘッダーフィールドを追加しなければなりません。

5.7.2. Transformations (変換)​

一部の仲介者には、ペイロードまたはメッセージセマンティクスの変換機能が含まれており、これは一部のHTTPアプリケーションにとって有用です。

プロキシは、明示的に要求されない限り、リクエストの意図内容 (intent content) を変更すべきではありません。

6. Connection Management (接続管理)​

HTTPメッセージ伝送は、基盤となるトランスポートまたはセッション層接続プロトコルから独立しています。HTTPは、リクエストとレスポンスの順序配信を提供できる信頼性の高いトランスポートのみを前提としています。

6.1. Connection​

"Connection"ヘッダーフィールドにより、送信者は特定の接続に対して望ましい制御オプションを指定できます。

Connection        = 1#connection-option
connection-option = token

6.2. Establishment (確立)​

クライアントは、サーバーへの接続を確立する責任があります。HTTPには、接続自体を確立または識別するためのメッセージフレーミングの要件はありません。

6.3. Persistence (持続性)​

HTTP/1.1は、デフォルトで"持続的接続" (persistent connections) を使用し、単一の接続を介して複数のリクエストとレスポンスを送信できるようにします。HTTP実装は持続的接続をサポートすべきです。

6.3.1. Retrying Requests (リクエストの再試行)​

リクエストを自動的に再試行する場合、接続はリクエストメッセージの送信中 (またはレスポンスメッセージの待機中) に失敗する可能性があります。クライアントは、リクエストがべき等である ([RFC7231], [Section 4.2.2]) ことを確認できない限り、またはオリジンサーバーからメッセージを受信してサーバーが接続失敗前にリクエストを処理しなかったことを示す場合を除き、リクエストを自動的に再試行すべきではありません。

6.3.2. Pipelining (パイプライン化)​

持続的接続をサポートするクライアントは、リクエストを"パイプライン化" (pipeline) できます (つまり、各レスポンスを待たずに複数のリクエストを送信できます)。サーバーは、これらのパイプライン化されたリクエストに対するレスポンスを、リクエストを受信したのと同じ順序で送信しなければなりません。

6.4. Concurrency (並行性)​

クライアントは、サーバーへの並行接続の数を制限すべきです。

6.5. Failures and Timeouts (障害とタイムアウト)​

サーバーは通常、非アクティブな接続を維持しなくなるタイムアウト値を持っています。プロキシサーバーは、リソースを節約するために短いタイムアウト値を使用する場合があります。

6.6. Tear-down (切断)​

Connectionヘッダーフィールド (Section 6.1) は、"close"接続オプションを提供します。送信者はこれを使用して、現在のリクエスト/レスポンスの完了後に接続が閉じられることを通知します。

6.6.1. Retrying Requests (リクエストの再試行)​

クライアントは、リクエストの送信後に接続が閉じられた場合、べき等リクエストを再試行すべきです (クライアントがその接続で以前にリクエストを送信していた場合でも)。

6.6.2. Closure (クローズ)​

サーバーがTCP接続の即時クローズを実行する場合、クライアントが最後のHTTPレスポンスを読み取れないという重大なリスクがあります。

6.7. Upgrade (アップグレード)​

"Upgrade"ヘッダーフィールドは、HTTP/1.1から他の互換性のないプロトコルへの変換のためのシンプルなメカニズムを提供します。

Upgrade          = 1#protocol
protocol         = protocol-name ["/" protocol-version]
protocol-name    = token
protocol-version = token

サーバーは、101 (Switching Protocols, プロトコル切り替え) レスポンスを送信することによってプロトコルを切り替えることができます。

7. ABNF List Extension: #rule (ABNFリスト拡張: #ルール)​

[RFC5234] のABNF表記法で定義された構文ルールは、HTTPヘッダーフィールドの一般的な構造です。このセクションでは、コンマ区切りのリスト要素を定義するために使用される # 構造を定義します。

# 演算子を使用した構文構造は、* 演算子を使用するのと同じですが、少なくとも1つのリスト要素が必要であり、リスト要素は1つ以上のコンマ (",") とオプションの空白 (OWS) で区切られる必要があります。

#element => [ ( "," / element ) *( OWS "," [ OWS element ] ) ]
1#element => *( "," OWS ) element *( OWS "," [ OWS element ] )

送信者は、空のリスト要素を生成すべきではありません。送信者は、少なくとも1つの非空要素を持つリストを生成しなければなりません。

8. IANA Considerations (IANAに関する考慮事項)​

8.1. Header Field Registration (ヘッダーフィールド登録)​

HTTPヘッダーフィールドは、http://www.iana.org/assignments/message-headers/ で維持されている"Message Headers"レジストリに登録されています。

このドキュメントは次のHTTPヘッダーフィールドを定義しているため、"Permanent Message Header Field Names"レジストリは [RFC3864] に従って更新されています:

Header Field NameProtocolStatusReference
ConnectionhttpstandardSection 6.1
Content-LengthhttpstandardSection 3.3.2
HosthttpstandardSection 5.4
TEhttpstandardSection 4.3
TrailerhttpstandardSection 4.4
Transfer-EncodinghttpstandardSection 3.3.1
UpgradehttpstandardSection 6.7
ViahttpstandardSection 5.7.1

8.2. URI Scheme Registration (URIスキーム登録)​

IANAは、"http"および"https" URIスキームの登録 (最初は [RFC2617] および [RFC2818] で定義) を更新して、この仕様を参照するようにしました。

8.3. Internet Media Type application/http​

IANAは、"application/http"メディアタイプ登録 (最初は [RFC2616] で定義) を更新して、この仕様を参照するようにしました。

8.4. Transfer Coding Registry (転送エンコーディングレジストリ)​

転送エンコーディング名レジストリは、http://www.iana.org/assignments/http-parameters/ で維持されています。

このドキュメントは次の転送エンコーディングを登録します:

NameDescriptionReference
chunkedチャンク転送エンコーディングSection 4.1
compressUNIX "compress"データ形式Section 4.2.1
deflate"deflate"圧縮データ形式Section 4.2.2
gzipGZIPファイル形式Section 4.2.3

8.5. Content Coding Registry (コンテンツエンコーディングレジストリ)​

コンテンツエンコーディング名レジストリは、http://www.iana.org/assignments/http-parameters/ で維持されています。

8.6. Upgrade Token Registry (アップグレードトークンレジストリ)​

HTTPアップグレードトークンレジストリは、Upgradeヘッダーフィールド (Section 6.7) に使用される名前空間を定義します。

9. Security Considerations (セキュリティに関する考慮事項)​

このセクションは、HTTP/1.1を展開する際に知られているセキュリティ上の制限について、開発者、情報提供者、およびユーザーに通知することを目的としています。

9.1. Establishing Authority (権限の確立)​

HTTPは、URI authority (権限) コンポーネントの概念に依存しています。これには、オリジンサーバーのIPアドレスまたはホスト名、およびTCPポート番号が含まれます。

HTTP内でサーバー権限を確立するための信頼できるメカニズムの必要性により、HTTPSの開発が行われました (TLSを使用するHTTP)、[RFC2818] で定義されているとおりです。

9.2. Risks of Intermediaries (仲介者のリスク)​

デフォルトでは、HTTPは基盤となるトランスポートプロトコルのセキュリティ属性に依存しています。TLSを使用することにより、HTTPはTLSに依存してIDを検証し、機密性と整合性保護を提供します。

ただし、TLSはトランスポート層でのみ保護を提供します。HTTPメッセージは、通信パスのエンドポイントではない仲介者によって読み取られたり、変更されたりする可能性があります。

9.3. Attacks Based on File and Path Names (ファイル名とパス名に基づく攻撃)​

オリジンサーバーは、リソースの表現を保存するためにファイルシステムの階層構造を使用することが多く、その階層を提供するURI空間に反映させます。

実装は、URIをファイルシステムにマッピングする方法に注意する必要があります。

9.4. Attacks Based on Command, Code, or Query Injection (コマンド、コード、またはクエリインジェクションに基づく攻撃)​

オリジンサーバーは、クライアントが提供する情報の一部として (URIまたはメッセージ本文で) パラメータを使用することが多く、これらのパラメータは内部クエリ、コマンド、またはコードを構築するために使用されることがあります。

実装は、すべての入力を検証およびサニタイズしなければなりません。

9.5. Attacks via Protocol Element Length (プロトコル要素の長さによる攻撃)​

HTTPは、リクエスト行、ステータス行、ヘッダーフィールド、およびメッセージ本文の境界を含む、さまざまなプロトコル要素の境界をマークするために長さベースの区切り文字を使用するため、実装は、過度に大きなプロトコル要素を送信することによって攻撃者が過度なリソースを消費するのを防ぐ必要があります。

9.5.1. Request Smuggling (リクエストスマグリング)​

リクエストスマグリング攻撃は、HTTPメッセージフレーミングの不一致または曖昧性を悪用します。

リクエストスマグリング攻撃を防ぐために、実装は次のことをしなければなりません:

  • 特に Section 3.3.3 で定義されているメッセージ本文の長さ決定ルールに従い、メッセージフレーミングルールを厳格に遵守する
  • 一貫性のない、または曖昧なフレーミング情報を含むメッセージを拒否する

9.5.2. Response Splitting (レスポンス分割)​

レスポンス分割攻撃は、HTTPレスポンスを生成する際にアプリケーションが入力を適切に検証しないという脆弱性を悪用します。

実装は、すべての入力を検証しなければなりません。

9.6. Disclosure of Sensitive Information in URIs (URIでの機密情報の開示)​

URIは、さまざまなシステムログ、ブラウザ履歴、およびリファラーヘッダーフィールドに記録されることが多いです。したがって、機密情報は、特にクエリ文字列でURIで送信すべきではありません。

9.7. Disclosure of Fragment after Redirects (リダイレクト後のフラグメントの開示)​

フラグメント識別子はサーバーに送信されませんが、URIにフラグメントが含まれていて、そのURIが別のサイトにリダイレクトされた場合、元のフラグメントはリダイレクト後に新しいサイトに公開される可能性があります。

9.8. Disclosure of Product Information (製品情報の開示)​

ServerおよびUser-Agentヘッダーフィールドには、通常、送信者のソフトウェアに関する情報が含まれています。これらの情報は統計目的や相互運用性の問題の識別に役立つかもしれませんが、攻撃者がソフトウェアの脆弱性を識別するためにも使用される可能性があります。

9.9. Browser Fingerprinting (ブラウザフィンガープリンティング)​

ブラウザフィンガープリンティングは、Webサイトがさまざまな情報 (HTTPヘッダーフィールドを含む) を使用して、Cookieや他の明示的な追跡メカニズムを使用しなくても、ブラウザを一意に識別または追跡する技術です。

Acknowledgments (謝辞)​

HTTP/1.1仕様の開発に貢献したすべての人々に感謝します。

このドキュメントの作成に直接的または間接的に貢献した多くの個人に感謝します:

  • Roy T. Fielding (仕様の主要編集者)
  • Julian Reschke (仕様の共同編集者)
  • HTTPワーキンググループのすべてのメンバー

また、以前のHTTP仕様 ([RFC2616]) の著者である Roy Fielding, Jim Gettys, Jeffrey Mogul, Henrik Frystyk, Larry Masinter, Paul Leach, Tim Berners-Lee にも感謝します。

HTTP/1.1の実装とテストに貢献したすべてのベンダー、開発者、ユーザーにも感謝します。

References (参考文献)​

Normative References (規範的参考文献)​

  • [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

  • [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.

  • [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.

  • [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", RFC 7231, June 2014.

  • [RFC7232] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests", RFC 7232, June 2014.

  • [RFC7233] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Range Requests", RFC 7233, June 2014.

  • [RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", RFC 7234, June 2014.

  • [RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Authentication", RFC 7235, June 2014.

Informative References (参考情報)​

  • [BCP90] Klyne, G., Nottingham, M., and J. Mogul, "Registration Procedures for Message Header Fields", BCP 90, RFC 3864, September 2004.

  • [RFC1945] Berners-Lee, T., Fielding, R., and H. Frystyk, "Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996.

  • [RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data Format Specification version 3.3", RFC 1950, May 1996.

  • [RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Specification version 1.3", RFC 1951, May 1996.

  • [RFC1952] Deutsch, P., "GZIP file format specification version 4.3", RFC 1952, May 1996.

  • [RFC2049] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples", RFC 2049, November 1996.

  • [RFC2068] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2068, January 1997.

  • [RFC2145] Mogul, J., Fielding, R., Gettys, J., and H. Frystyk, "Use and Interpretation of HTTP Version Numbers", RFC 2145, May 1997.

  • [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.

  • [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, June 1999.

  • [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.

  • [RFC3040] Cooper, I., Melve, I., and G. Tomlinson, "Internet Web Replication and Caching Taxonomy", RFC 3040, January 2001.

  • [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration Procedures for Message Header Fields", BCP 90, RFC 3864, September 2004.

  • [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, April 2011.

  • [Welch] Welch, T., "A Technique for High Performance Data Compression", IEEE Computer 17(6), June 1984.

Appendix A. HTTP Version History (HTTPバージョン履歴)​

HTTPのバージョン管理ポリシーは、1990年にWorld-Wide Webグローバル情報イニシアチブとして初めて導入されて以来変更されていません。このバージョンポリシーは、送信者がメッセージのフォーマットと、さらなる通信を理解し、参加する能力を示すことを目的としています。

HTTP/1.1の開発には10年以上かかりました。これには、2つの異なる標準化トラック仕様 ([RFC2068] および [RFC2616])、および数十の実装と展開の経験が含まれていました。

A.1. HTTP/0.9​

HTTP/0.9は、World-Wide Webでの最初のHTTPプロトコルの実装でした。これは単純なプロトコルであり、要求は単一の行で構成され、メソッドとターゲットURIのみが含まれていました。

GET /hello.txt

A.1.1. HTTP/1.0​

HTTP/1.0は、一般的なHTTPメッセージフォーマットを文書化しました。これは、プロトコルバージョン番号、ステータスコード、要求と応答の両方のヘッダーセクションを追加しました。

HTTP/1.0の仕様は [RFC1945] で定義されています。

A.1.2. HTTP/1.1​

HTTP/1.1は、要求方法、応答ステータスコード、およびヘッダーフィールドの詳細な説明を含む、HTTP/1.0を改良したものです。

主な改善点には以下が含まれます:

  • 持続的接続: デフォルトで接続が持続的になる
  • チャンク転送エンコーディング: メッセージ本文を動的に送信できる
  • Host ヘッダー: 仮想ホスティングのサポート
  • パイプライン化: 複数のリクエストを並行して送信できる
  • キャッシュ制御: より洗練されたキャッシュメカニズム

HTTP/1.1は最初に [RFC2068] (1997年1月) で定義され、その後 [RFC2616] (1999年6月) で更新されました。

A.2. Changes from RFC 2616 (RFC 2616からの変更)​

このドキュメント ([RFC7230]) は、以前の [RFC2616] を廃止し、多くの明確化と改善を導入しています:

A.2.1. Architecture (アーキテクチャ)​

  • 仲介者 (プロキシ、ゲートウェイ、トンネル) の役割の明確化
  • ユーザーエージェントとオリジンサーバーの定義の改善

A.2.2. Message Syntax and Routing (メッセージ構文とルーティング)​

  • メッセージフレーミングの明確化
  • Transfer-Encoding と Content-Length の相互作用の明確化
  • チャンク転送エンコーディングの詳細な説明

A.2.3. Connection Management (接続管理)​

  • 持続的接続の動作の明確化
  • パイプライン化の制限の文書化
  • 接続再利用とクローズの詳細な説明

A.2.4. Security Considerations (セキュリティに関する考慮事項)​

  • リクエストスマグリング攻撃の文書化
  • レスポンス分割攻撃の文書化
  • プロトコル要素長に関するセキュリティガイダンスの追加