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

2. メッセージ (Message)

HTTP/1.1 クライアントとサーバーは、メッセージを送信することで通信します。HTTP の一般的な用語とコア概念については、[HTTP] の第 3 節を参照してください。

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

HTTP/1.1 メッセージは、開始行の後に CRLF が続き、その後にインターネットメッセージフォーマット [RFC5322] に類似した形式のオクテットシーケンスで構成されます: 0 個以上のヘッダーフィールド行 (まとめて「ヘッダー」または「ヘッダーセクション」と呼ばれます)、ヘッダーセクションの終わりを示す空行、およびオプションのメッセージ本文。

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

メッセージは、クライアントからサーバーへのリクエスト、またはサーバーからクライアントへのレスポンスのいずれかです。構文的には、2 つのタイプのメッセージは開始行のみが異なります。開始行は、リクエストの場合はリクエスト行、レスポンスの場合はステータス行です。また、メッセージ本文の長さを決定するアルゴリズムも異なります (第 6 節参照)。

start-line     = request-line / status-line

理論的には、クライアントはリクエストを受信でき、サーバーはレスポンスを受信できます。両者は異なる開始行形式で区別されます。実際には、サーバーはリクエストのみを期待するように実装され (レスポンスは未知または無効なリクエストメソッドとして解釈されます)、クライアントはレスポンスのみを期待するように実装されています。

HTTP は、多目的インターネットメール拡張 (MIME: Multipurpose Internet Mail Extensions) [RFC2045] に類似したいくつかのプロトコル要素を使用します。HTTP と MIME メッセージの違いについては、付録 B を参照してください。

2.2. メッセージ解析 (Message Parsing)​

HTTP メッセージを解析する通常の手順は、開始行を構造体に読み込み、各ヘッダーフィールド行を空行が現れるまでフィールド名ごとにハッシュテーブルに読み込み、次に解析されたデータを使用してメッセージ本文が期待されるかどうかを判断することです。メッセージ本文が示されている場合、メッセージ本文の長さに等しいオクテット数が読み取られるか、接続が閉じられるまで、ストリームとして読み取られます。

受信者は、US-ASCII [USASCII] のスーパーセットであるエンコーディングでオクテットシーケンスとして HTTP メッセージを解析しなければなりません (MUST)。特定のエンコーディングを考慮せずに HTTP メッセージを Unicode 文字のストリームとして解析すると、オクテット LF (%x0A) を含む無効なマルチバイト文字シーケンスを文字列処理ライブラリがさまざまな方法で処理するため、セキュリティ脆弱性が発生します。文字列ベースのパーサーは、メッセージから要素が抽出された後、プロトコル要素内でのみ安全に使用できます。例えば、メッセージ解析が個々のフィールド行を区切った後のヘッダーフィールド行の値内などです。

開始行とフィールドの行終端子は CRLF シーケンスですが、受信者は単一の LF を行終端子として認識し、先行する CR を無視してもかまいません (MAY)。

送信者は、コンテンツ以外のプロトコル要素内で裸の CR (LF が直後に続かない CR 文字) を生成してはなりません (MUST NOT)。そのような裸の CR の受信者は、その要素を無効と見なすか、要素を処理またはメッセージを転送する前に各裸の CR を SP で置き換えなければなりません (MUST)。

古い HTTP/1.0 ユーザーエージェント実装は、行末で終了しないメッセージ本文コンテンツの読み取りに失敗した初期のサーバーアプリケーションへの回避策として、POST リクエストの後に余分な CRLF を送信する場合があります。HTTP/1.1 ユーザーエージェントは、リクエストの前後に余分な CRLF を付けてはなりません (MUST NOT)。リクエストメッセージ本文を行末で終了させたい場合、ユーザーエージェントは終了する CRLF オクテットをメッセージ本文の長さの一部としてカウントしなければなりません (MUST)。

堅牢性のために、リクエスト行を受信して解析することを期待するサーバーは、リクエスト行の前に受信した少なくとも 1 つの空行 (CRLF) を無視すべきです (SHOULD)。

送信者は、開始行と最初のヘッダーフィールドの間に空白を送信してはなりません (MUST NOT)。

開始行と最初のヘッダーフィールドの間に空白を受信する受信者は、メッセージを無効として拒否するか、各空白が先行する行をそれ以上処理せずに消費しなければなりません (MUST) (つまり、適切に形成されたヘッダーフィールドが受信されるかヘッダーセクションが終了するまで、空白が先行する後続の行とともに、行全体を無視します)。無効な空白が先行する行の拒否または削除は、リクエストスマグリング (第 11.2 節) またはレスポンス分割 (第 11.1 節) 攻撃に脆弱な可能性のある下流の受信者によるそれらの誤解釈を防ぐために必要です。

HTTP リクエストメッセージのみをリッスンしているサーバー、または開始行から HTTP リクエストメッセージであると思われるものを処理しているサーバーが、上記の堅牢性例外を除いて HTTP メッセージ文法に一致しないオクテットシーケンスを受信した場合、サーバーは 400 (Bad Request) レスポンスで応答し、接続を閉じるべきです (SHOULD)。

2.3. HTTP バージョン (HTTP Version)​

HTTP は、"<major>.<minor>" という番号付けスキームを使用してプロトコルのバージョンを示します。本仕様書はバージョン "1.1" を定義します。HTTP バージョン番号のセマンティクスは、[HTTP] の第 2.5 節で規定されています。

HTTP/1.x メッセージのバージョンは、開始行の HTTP-version フィールドで示されます。HTTP-version は大文字小文字を区別します。

HTTP-version  = HTTP-name "/" DIGIT "." DIGIT
HTTP-name     = %s"HTTP"

HTTP/1.1 メッセージが HTTP/1.0 受信者 [HTTP/1.0] またはバージョンが不明な受信者に送信される場合、HTTP/1.1 メッセージは、すべての新しい機能が無視される場合に有効な HTTP/1.0 メッセージとして解釈できるように構築されます。本仕様書は、いくつかの新機能に受信者バージョン要件を配置しており、適合する送信者は、構成またはメッセージの受信を通じて受信者が HTTP/1.1 をサポートしていると判断するまで、互換性のある機能のみを使用します。

HTTP メッセージを処理する中継装置 (つまり、トンネルとして機能するもの以外のすべての中継装置) は、上流の問題の回避策として意図的にダウングレードされない限り、転送されるメッセージで独自の HTTP バージョンを送信しなければなりません (MUST)。言い換えれば、中継装置は、そのメッセージ内のプロトコルバージョンがメッセージの受信と送信の両方について中継装置が適合しているバージョンと一致することを確認せずに、開始行を盲目的に転送することは許可されていません。HTTP バージョンを書き換えずに HTTP メッセージを転送すると、下流の受信者がメッセージ送信者のバージョンを使用してその送信者との後の通信で安全に使用できる機能を判断する場合、通信エラーが発生する可能性があります。

サーバーは、HTTP 仕様を誤って実装していて後のバージョンのレスポンスを正しく処理できないことがわかっているか疑われるクライアントに対して、HTTP/1.1 リクエストに HTTP/1.0 レスポンスを送信してもかまいません (MAY)。例えば、クライアントがバージョン番号を正しく解析できない場合や、中継装置が HTTP バージョンを盲目的に転送することがわかっており、プロトコルの特定のマイナーバージョンに準拠していない場合などです。このようなプロトコルダウングレードは、特定のクライアント属性によってトリガーされない限り実行すべきではありません (SHOULD NOT)。例えば、1 つ以上のリクエストヘッダーフィールド (User-Agent など) がエラーのあるクライアントから送信された値と一意に一致する場合などです。

に最終更新