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