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

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など) をヘッダーフィールド値の一部として解釈してはなりません。

に最終更新