Appendix A. Differences between HTTP and MIME (Unterschiede zwischen HTTP und MIME)
HTTP/1.1 verwendet viele der Konstrukte, die für das Internet Message Format [RFC5322] und die Multipurpose Internet Mail Extensions (MIME) [RFC2045] definiert wurden, um die Übertragung eines Nachrichtenkörpers in einer offenen Vielfalt von Darstellungen und mit erweiterbaren Header-Feldern zu ermöglichen. RFC 2045 konzentriert sich jedoch nur auf E-Mail; HTTP-Anwendungen haben viele Eigenschaften, die sich von E-Mail unterscheiden; daher hat HTTP Funktionen, die sich von MIME unterscheiden. Diese Unterschiede wurden sorgfältig ausgewählt, um die Leistung über binäre Verbindungen zu optimieren, größere Freiheit bei der Verwendung neuer Medientypen zu ermöglichen, Datumsvergleiche zu erleichtern und die Praxis einiger früher HTTP-Server und -Clients anzuerkennen.
Dieser Anhang beschreibt spezifische Bereiche, in denen HTTP sich von MIME unterscheidet. Proxys und Gateways zu und von strikten MIME-Umgebungen müssen sich dieser Unterschiede bewusst sein und gegebenenfalls angemessene Konvertierungen bereitstellen.
A.1. MIME-Version
HTTP ist kein MIME-konformes Protokoll. Nachrichten können jedoch ein einzelnes MIME-Version-Header-Feld enthalten, um anzugeben, welche Version des MIME-Protokolls zum Erstellen der Nachricht verwendet wurde. Die Verwendung des MIME-Version-Header-Felds zeigt an, dass die Nachricht vollständig mit dem MIME-Protokoll übereinstimmt (wie in [RFC2045] definiert). Sender sind dafür verantwortlich, beim Export von HTTP-Nachrichten in strikte MIME-Umgebungen vollständige Konformität sicherzustellen (wo möglich).
A.2. Conversion to Canonical Form (Konvertierung in kanonische Form)
MIME erfordert, dass ein Internet-Mail-Body-Teil vor der Übertragung in kanonische Form konvertiert wird, wie in Abschnitt 4 von [RFC2049] beschrieben. Abschnitt 3.1.1.3 dieses Dokuments beschreibt die zulässigen Formen für Untertypen des Medientyps "text" bei der Übertragung über HTTP. [RFC2046] erfordert, dass Inhalte vom Typ "text" Zeilenumbrüche als CRLF darstellen und die Verwendung von CR oder LF außerhalb von Zeilenumbruchsequenzen verbietet. HTTP erlaubt CRLF, einzelnes CR und einzelnes LF, um einen Zeilenumbruch im Textinhalt anzuzeigen.
Ein Proxy oder Gateway von HTTP zu einer strikten MIME-Umgebung sollte alle Zeilenumbrüche innerhalb der in Abschnitt 3.1.1.3 dieses Dokuments beschriebenen Textmedientypen in die RFC 2049 kanonische Form von CRLF übersetzen. Beachten Sie jedoch, dass dies durch das Vorhandensein eines Content-Encoding und durch die Tatsache erschwert werden kann, dass HTTP die Verwendung einiger Zeichensätze erlaubt, die die Oktette 13 und 10 nicht zur Darstellung von CR bzw. LF verwenden.
Die Konvertierung bricht alle auf den ursprünglichen Inhalt angewendeten kryptografischen Prüfsummen, es sei denn, der ursprüngliche Inhalt liegt bereits in kanonischer Form vor. Daher wird die kanonische Form für alle Inhalte empfohlen, die solche Prüfsummen in HTTP verwenden.
A.3. Conversion of Date Formats (Konvertierung von Datumsformaten)
HTTP/1.1 verwendet einen eingeschränkten Satz von Datumsformaten (Abschnitt 7.1.1.1), um den Prozess des Datumsvergleichs zu vereinfachen. Proxys und Gateways von anderen Protokollen sollten sicherstellen, dass jedes in einer Nachricht vorhandene Date-Header-Feld einem der HTTP/1.1-Formate entspricht und das Datum bei Bedarf umschreiben.
A.4. Conversion of Content-Encoding (Konvertierung von Content-Encoding)
MIME enthält kein Konzept, das dem Content-Encoding-Header-Feld von HTTP/1.1 entspricht. Da dies als Modifikator für den Medientyp wirkt, sollten Proxys und Gateways von HTTP zu MIME-konformen Protokollen entweder den Wert des Content-Type-Header-Felds ändern oder die Darstellung vor dem Weiterleiten der Nachricht dekodieren. (Einige experimentelle Anwendungen von Content-Type für Internet-Mail haben einen Medientyp-Parameter von ";conversions=<content-coding>" verwendet, um eine Funktion auszuführen, die Content-Encoding entspricht. Dieser Parameter ist jedoch nicht Teil der MIME-Standards).
A.5. Conversion of Content-Transfer-Encoding (Konvertierung von Content-Transfer-Encoding)
HTTP verwendet das Content-Transfer-Encoding-Feld von MIME nicht. Proxys und Gateways von MIME-konformen Protokollen zu HTTP müssen jedes Content-Transfer-Encoding entfernen, bevor sie die Antwortnachricht an einen HTTP-Client übergeben.
Proxys und Gateways von HTTP zu MIME-konformen Protokollen sind dafür verantwortlich sicherzustellen, dass die Nachricht im richtigen Format und in der richtigen Kodierung für eine sichere Übertragung über dieses Protokoll vorliegt, wobei "sichere Übertragung" durch die Einschränkungen des verwendeten Protokolls definiert wird. Solche Proxys oder Gateways sollten Daten mit einem geeigneten Content-Transfer-Encoding transformieren und kennzeichnen, wenn dies die Wahrscheinlichkeit einer sicheren Übertragung über das Zielprotokoll erhöht.
A.6. MHTML and Line Length Limitations (MHTML und Zeilenlängenbeschränkungen)
HTTP-Implementierungen, die Code mit MHTML-Implementierungen [RFC2557] teilen, müssen sich der MIME-Zeilenlängenbeschränkungen bewusst sein. Da HTTP diese Beschränkung nicht hat, faltet HTTP keine langen Zeilen. MHTML-Nachrichten, die über HTTP transportiert werden, folgen allen Konventionen von MHTML, einschließlich Zeilenlängenbeschränkungen und Faltung, Kanonisierung usw., da HTTP alle Nachrichtenkörper als Nutzlast transportiert und, abgesehen vom Typ "multipart/byteranges" (Anhang A von [RFC7233]), den Inhalt oder irgendwelche darin enthaltenen MIME-Header-Zeilen nicht interpretiert.