付録 B. HTTP と MIME の違い (Differences between HTTP and MIME)
HTTP/1.1 は、インターネットメッセージ形式 [RFC5322] と多目的インターネットメール拡張 (MIME: Multipurpose Internet Mail Extensions) [RFC2045] に定義された多くの構造を使用して、メッセージ本文をさまざまな表現で送信し、拡張可能なフィールドを使用できるようにします。ただし、これらの構造の一部は、インタラクティブな通信のニーズによりよく適合するように再解釈されており、HTTP 内で MIME 構造がどのように使用されるかにいくつかの違いが生じています。これらの違いは、バイナリ接続でのパフォーマンスを最適化し、新しいメディアタイプの使用でより大きな自由を可能にし、日付比較を容易にし、一般的な実装に対応するために慎重に選択されました。
この付録では、HTTP が MIME と異なる特定の領域について説明します。厳格な MIME 環境との間のプロキシとゲートウェイは、これらの違いを認識し、必要に応じて適切な変換を提供する必要があります。
B.1. MIME-Version
HTTP は MIME 準拠プロトコルではありません。ただし、メッセージには、メッセージの構築に使用された MIME プロトコルのバージョンを示すために、単一の MIME-Version ヘッダーフィールドを含めることができます。MIME-Version ヘッダーフィールドの使用は、メッセージが MIME プロトコル ([RFC2045] で定義) に完全に準拠していることを示します。送信者は、HTTP メッセージを厳格な MIME 環境にエクスポートする際に、(可能な場合) 完全な準拠を確保する責任があります。
B.2. 正規形式への変換 (Conversion to Canonical Form)
MIME は、[RFC2049] の第 4 節で説明されているように、インターネットメール本文部分を転送前に正規形式に変換することを要求し、"text" タイプのコンテンツは行の区切りを CRLF として表し、行の区切りシーケンス以外での CR または LF の使用を禁止します [RFC2046]。対照的に、HTTP は、コンテンツ内の行の区切りを示すために CRLF、裸の CR、または裸の LF が使用されるかどうかを気にしません。
HTTP から厳格な MIME 環境へのプロキシまたはゲートウェイは、テキストメディアタイプ内のすべての行の区切りを RFC 2049 の正規形式である CRLF に変換すべきです。ただし、Content-Encoding の存在によってこれが複雑になる可能性があり、HTTP が CR と LF をそれぞれ表すためにオクテット 13 と 10 を使用しない一部の文字セットの使用を許可しているという事実があることに注意してください。
変換は、元のコンテンツが既に正規形式でない限り、元のコンテンツに適用された暗号化チェックサムを破壊します。したがって、HTTP でそのようなチェックサムを使用する任意のコンテンツには、正規形式が推奨されます。
B.3. 日付形式の変換 (Conversion of Date Formats)
HTTP/1.1 は、日付比較のプロセスを簡素化するために、制限された日付形式のセット ([HTTP] の第 5.6.7 節) を使用します。他のプロトコルからのプロキシとゲートウェイは、メッセージに存在する任意の Date ヘッダーフィールドが HTTP/1.1 形式のいずれかに準拠していることを確認し、必要に応じて日付を書き換えるべきです。
B.4. Content-Encoding の変換 (Conversion of Content-Encoding)
MIME には、HTTP の Content-Encoding ヘッダーフィールドに相当する概念が含まれていません。これはメディアタイプの修飾子として機能するため、HTTP から MIME 準拠プロトコルへのプロキシとゲートウェイは、Content-Type ヘッダーフィールドの値を変更するか、メッセージを転送する前に表現をデコードすべきです。(インターネットメール用の Content-Type の一部の実験的アプリケーションでは、Content-Encoding に相当する機能を実行するために ";conversions=<content-coding>" というメディアタイプパラメータを使用しています。ただし、このパラメータは MIME 標準の一部ではありません。)
B.5. Content-Transfer-Encoding の変換 (Conversion of Content-Transfer-Encoding)
HTTP は MIME の Content-Transfer-Encoding フィールドを使用しません。MIME 準拠プロトコルから HTTP へのプロキシとゲートウェイは、レスポンスメッセージを HTTP クライアントに配信する前に、任意の Content-Transfer-Encoding を削除する必要があります。
HTTP から MIME 準拠プロトコルへのプロキシとゲートウェイは、メッセージがそのプロトコルでの安全な転送に適した正しい形式とエンコーディングであることを確認する責任があります。ここで "安全な転送" は、使用されるプロトコルの制限によって定義されます。そのようなプロキシまたはゲートウェイは、そうすることで宛先プロトコル上での安全な転送の可能性が向上する場合、適切な Content-Transfer-Encoding でデータを変換およびラベル付けすべきです。
B.6. MHTML と行長の制限 (MHTML and Line Length Limitations)
MHTML [RFC2557] 実装とコードを共有する HTTP 実装は、MIME の行長制限を認識する必要があります。HTTP にはこの制限がないため、HTTP は長い行を折り返しません。HTTP によって転送される MHTML メッセージは、行長制限と折り返し、正規化などを含む MHTML のすべての規則に従います。HTTP は変更なしでメッセージ本文を転送し、"multipart/byteranges" タイプ ([HTTP] の第 14.6 節) を除いて、コンテンツまたはその中に含まれる可能性のある MIME ヘッダー行を解釈しないためです。