4. HTTP Message (HTTPメッセージ)

4.1 Message Types (メッセージタイプ)

HTTPメッセージは、クライアントからサーバーへのリクエスト (request) と、サーバーからクライアントへのレスポンス (response) で構成されます。

HTTP-message   = Request | Response     ; HTTP/1.1 messages

リクエスト（第5節）とレスポンス（第6節）メッセージは、RFC 822 [9] の汎用メッセージ形式を使用してエンティティ (entity)（メッセージのペイロード）を転送します。両方のタイプのメッセージは、開始行 (start line)、0個以上のヘッダフィールド (header field)（"headers"とも呼ばれる）、ヘッダフィールドの終了を示す空行（つまり、CRLFの前に何もない行）、および可能性のあるメッセージボディ (message body) で構成されます。

generic-message = start-line
                  *(message-header CRLF)
                  CRLF
                  [ message-body ]
start-line      = Request-Line | Status-Line

堅牢性のために、サーバーは、Request-Lineが期待される位置で受信した任意の空行を無視すべき (SHOULD) です。つまり、サーバーがメッセージの開始時にプロトコルストリームを読み取り、最初にCRLFを受信した場合、そのCRLFを無視すべきです。

一部の欠陥のあるHTTP/1.0クライアント実装は、POSTリクエストの後に余分なCRLFを生成します。BNFが明示的に禁止していることを再度述べると、HTTP/1.1クライアントは、リクエストの前後に余分なCRLFを追加してはなりません (MUST NOT)。

4.2 Message Headers (メッセージヘッダ)

HTTPヘッダフィールドは、通用ヘッダ (general-header)（第4.5節）、リクエストヘッダ (request-header)（第5.3節）、レスポンスヘッダ (response-header)（第6.2節）、およびエンティティヘッダ (entity-header)（第7.1節）フィールドを含み、RFC 822 [9] 第3.1節で示されたのと同じ汎用フォーマットに従います。各ヘッダフィールドは、名前の後にコロン（":"）とフィールド値が続く形式で構成されます。フィールド名は大文字小文字を区別しません。フィールド値の前には任意の数のLWSを付けることができます (MAY) が、単一のSPが推奨されます。ヘッダフィールドは、各追加行の前に少なくとも1つのSPまたはHTを付けることで複数行に拡張できます。アプリケーションは、HTTPコンストラクトを生成する際に、既知または示されている場合は「通用形式」(common form) に従うべき (ought to) です。なぜなら、通用形式を超えるものを受け入れられない実装が存在する可能性があるためです。

message-header = field-name ":" [ field-value ]
field-name     = token
field-value    = *( field-content | LWS )
field-content  = <the OCTETs making up the field-value
                 and consisting of either *TEXT or combinations
                 of token, separators, and quoted-string>

field-contentには、先頭または末尾のLWSは含まれません。field-valueの最初の非空白文字の前または最後の非空白文字の後に現れる線形空白です。このような先頭または末尾のLWSは、フィールド値の意味を変更することなく削除できます (MAY)。field-content間に現れる任意のLWSは、フィールド値を解釈する前、またはメッセージをダウンストリームに転送する前に、単一のSPに置き換えることができます (MAY)。

異なるフィールド名を持つヘッダフィールドを受信する順序は重要ではありません。ただし、最初に通用ヘッダフィールド、次にリクエストヘッダまたはレスポンスヘッダフィールド、最後にエンティティヘッダフィールドを送信することが「良い実践」(good practice) です。

メッセージ内に同じfield-nameを持つ複数のmessage-headerフィールドが存在できる (MAY) のは、そのヘッダフィールドの全体のfield-valueがカンマ区切りリスト [すなわち#(values)] として定義されている場合のみです。メッセージの意味を変更することなく、複数のヘッダフィールドを1つの「field-name: field-value」ペアに結合できなければなりません (MUST)。これは、各後続のfield-valueを最初のものに付加し、それぞれをカンマで区切ることによって行います。したがって、同じfield-nameを持つヘッダフィールドを受信する順序は、結合されたフィールド値の解釈にとって重要であり、プロキシはメッセージを転送する際にこれらのフィールド値の順序を変更してはなりません (MUST NOT)。

4.3 Message Body (メッセージボディ)

HTTPメッセージのmessage-body（存在する場合）は、リクエストまたはレスポンスに関連付けられたentity-bodyを運ぶために使用されます。message-bodyがentity-bodyと異なるのは、Transfer-Encodingヘッダフィールド（第14.41節）で示されるように、転送エンコーディング (transfer-coding) が適用された場合のみです。

message-body = entity-body
             | <entity-body encoded as per Transfer-Encoding>

Transfer-Encodingは、メッセージの安全で正確な転送を保証するためにアプリケーションによって適用された任意の転送エンコーディングを示すために使用しなければなりません (MUST)。Transfer-Encodingはメッセージのプロパティであり、エンティティのプロパティではないため、任意の中間アプリケーションによって追加または削除できます (MAY)。

message-bodyがメッセージに存在する場合、message-bodyの転送長 (transfer-length) は第4.4節で定義されたルールによって決定されます。

4.4 Message Length (メッセージ長)

メッセージの転送長は、転送中に現れるmessage-bodyの長さです。message-bodyがメッセージに存在する場合、そのボディの転送長は次のいずれかによって決定されます（優先順位順）：

1. message-bodyを含んではならない (MUST NOT) 任意のレスポンスメッセージ（例：1xx、204、304レスポンス、およびHEADリクエストへの任意のレスポンス）は、メッセージにどのようなエンティティヘッダフィールドが存在していても、常にヘッダフィールド後の最初の空行で終了します。

2. Transfer-Encodingヘッダフィールドが存在し、それが"identity"でない場合、転送長は"chunked"転送エンコーディングによって定義されます。ただし、メッセージが接続のクローズによって終了する場合を除きます。

3. Content-Lengthヘッダフィールド（第14.13節）が存在する場合、その10進数値はオクテット単位でEntity-Lengthとtransfer-lengthを表します。これら2つの長さが異なる場合（つまり、Transfer-Encodingヘッダフィールドが存在する場合）、Content-Lengthヘッダフィールドを送信してはなりません (MUST NOT)。（注：一部の古い実装は、Content-Lengthとnon-identity Transfer-Encodingを誤って送信しました。）

4. メッセージがメディアタイプ"multipart/byteranges"を使用し、transfer-lengthが他の方法で指定されていない場合、この自己区切り型 (self-delimiting) メディアタイプがtransfer-lengthを定義します。送信者が受信者がそれを解析できることを知っている場合を除き、このメディアタイプを使用してはなりません (MUST NOT)。受信者にRangeヘッダフィールドが存在することは、クライアントがmultipart/byterangesレスポンスを解析できることを示します。

   Rangeヘッダフィールドは、multipart/byterangesを理解しないHTTP/1.0プロキシによって転送される可能性があります。この場合、サーバーはContent-Rangeフィールドでメッセージを区切らなければなりません (MUST)。

5. サーバーによる接続のクローズ。（接続のクローズは、リクエストボディの終了を示すために使用できません。なぜなら、それによりサーバーがレスポンスを送り返すことができなくなるためです。）

HTTP/1.0アプリケーションとの互換性のために、message-bodyを含むHTTP/1.1リクエストは、サーバーがHTTP/1.1に準拠していることが既知でない限り、有効なContent-Lengthヘッダフィールドを含まなければなりません (MUST)。リクエストがmessage-bodyを含み、Content-Lengthを含まない場合、サーバーがメッセージの長さを判断できない場合は400（bad request）で応答すべき (SHOULD) であり、サーバーが有効なContent-Lengthを受信することを主張する場合は411（length required）で応答すべきです。

すべてのHTTP/1.1アプリケーションは、アプリケーション自体がチャンクメッセージを送信しない場合でも、リクエストメッセージ内の"chunked"transfer-codingを受け入れなければなりません (MUST)。HTTP/1.1リクエストがmessage-bodyを含むがContent-Lengthを含まない場合、サーバーはリクエストの長さを判断できない場合は400（bad request）で応答すべき (SHOULD) であり、有効なContent-Lengthを受信することを主張する場合は411（length required）で応答すべきです。

リクエストがmessage-bodyを含み、Content-Lengthが指定されていない場合、サーバーはメッセージの長さを判断できない場合は400（bad request）で応答すべき (SHOULD) であり、有効なContent-Lengthを受信することを主張する場合は411（length required）で応答すべきです。

メッセージは、Transfer-EncodingとContent-Lengthヘッダフィールドの両方を含むべきではありません (SHOULD NOT)。メッセージが両方を含む場合、Transfer-Encodingは (MUST) Content-Lengthを削除しなければなりません。

コンテンツエンコーディングされたエンティティを受信して解析した場合、コンテンツエンコーディングが既知であれば、message-body長はデコードされたデータによって決定されます。

4.5 General Header Fields (通用ヘッダフィールド)

リクエストおよびレスポンスメッセージには適用されるが、転送されるエンティティには適用されない、一般的な適用性を持ついくつかのヘッダフィールドがあります。これらのヘッダフィールドは、転送されるメッセージにのみ適用されます。

general-header = Cache-Control            ; Section 14.9
               | Connection               ; Section 14.10
               | Date                     ; Section 14.18
               | Pragma                   ; Section 14.32
               | Trailer                  ; Section 14.40
               | Transfer-Encoding        ; Section 14.41
               | Upgrade                  ; Section 14.42
               | Via                      ; Section 14.45
               | Warning                  ; Section 14.46

通用ヘッダフィールド名は、プロトコルバージョンを変更することによってのみ確実に拡張できます。ただし、プロトコルバージョンを変更することなく、フィールド値に新しいまたは実験的なヘッダフィールドを付与できます。第7.1節では、エンティティヘッダフィールドの意味を定義しています。

認識されないヘッダフィールドは、受信者によってエンティティヘッダフィールドとして扱われるべき (SHOULD) です。

---