Appendix A. Differences between HTTP and MIME (Differenze tra HTTP e MIME)
HTTP/1.1 utilizza molte delle costruzioni definite per il formato dei messaggi Internet [RFC5322] e le estensioni di posta Internet multi-scopo (MIME) [RFC2045] per consentire la trasmissione di un corpo di messaggio in una varietà aperta di rappresentazioni e con campi di intestazione estensibili. Tuttavia, RFC 2045 si concentra solo sulla posta elettronica; le applicazioni HTTP hanno molte caratteristiche che differiscono dalla posta elettronica; quindi, HTTP ha funzionalità che differiscono da MIME. Queste differenze sono state attentamente scelte per ottimizzare le prestazioni su connessioni binarie, consentire maggiore libertà nell'uso di nuovi tipi di media, rendere più semplici i confronti di date e riconoscere la pratica di alcuni primi server e client HTTP.
Questa appendice descrive aree specifiche in cui HTTP differisce da MIME. I proxy e i gateway da e verso ambienti MIME rigorosi devono essere consapevoli di queste differenze e fornire le conversioni appropriate quando necessario.
A.1. MIME-Version
HTTP non è un protocollo conforme a MIME. Tuttavia, i messaggi possono includere un singolo campo di intestazione MIME-Version per indicare quale versione del protocollo MIME è stata utilizzata per costruire il messaggio. L'uso del campo di intestazione MIME-Version indica che il messaggio è in piena conformità con il protocollo MIME (come definito in [RFC2045]). I mittenti sono responsabili di garantire la piena conformità (ove possibile) durante l'esportazione di messaggi HTTP in ambienti MIME rigorosi.
A.2. Conversion to Canonical Form (Conversione in forma canonica)
MIME richiede che una parte del corpo del messaggio Internet venga convertita in forma canonica prima di essere trasferita, come descritto nella sezione 4 di [RFC2049]. La sezione 3.1.1.3 di questo documento descrive le forme consentite per i sottotipi del tipo di media "text" quando trasmessi tramite HTTP. [RFC2046] richiede che il contenuto di tipo "text" rappresenti le interruzioni di riga come CRLF e vieta l'uso di CR o LF al di fuori delle sequenze di interruzione di riga. HTTP consente CRLF, CR singolo e LF singolo per indicare un'interruzione di riga nel contenuto testuale.
Un proxy o gateway da HTTP a un ambiente MIME rigoroso dovrebbe tradurre tutte le interruzioni di riga all'interno dei tipi di media di testo descritti nella sezione 3.1.1.3 di questo documento nella forma canonica RFC 2049 di CRLF. Si noti tuttavia che ciò potrebbe essere complicato dalla presenza di un Content-Encoding e dal fatto che HTTP consente l'uso di alcuni set di caratteri che non utilizzano gli ottetti 13 e 10 per rappresentare rispettivamente CR e LF.
La conversione interromperà qualsiasi checksum crittografico applicato al contenuto originale a meno che il contenuto originale non sia già in forma canonica. Pertanto, la forma canonica è consigliata per qualsiasi contenuto che utilizza tali checksum in HTTP.
A.3. Conversion of Date Formats (Conversione dei formati di data)
HTTP/1.1 utilizza un insieme limitato di formati di data (sezione 7.1.1.1) per semplificare il processo di confronto delle date. I proxy e i gateway da altri protocolli dovrebbero garantire che qualsiasi campo di intestazione Date presente in un messaggio sia conforme a uno dei formati HTTP/1.1 e riscrivere la data se necessario.
A.4. Conversion of Content-Encoding (Conversione di Content-Encoding)
MIME non include alcun concetto equivalente al campo di intestazione Content-Encoding di HTTP/1.1. Poiché questo agisce come un modificatore del tipo di media, i proxy e i gateway da HTTP a protocolli conformi a MIME dovrebbero modificare il valore del campo di intestazione Content-Type o decodificare la rappresentazione prima di inoltrare il messaggio. (Alcune applicazioni sperimentali di Content-Type per la posta Internet hanno utilizzato un parametro di tipo di media di ";conversions=<content-coding>" per eseguire una funzione equivalente a Content-Encoding. Tuttavia, questo parametro non fa parte degli standard MIME).
A.5. Conversion of Content-Transfer-Encoding (Conversione di Content-Transfer-Encoding)
HTTP non utilizza il campo Content-Transfer-Encoding di MIME. I proxy e i gateway da protocolli conformi a MIME a HTTP devono rimuovere qualsiasi Content-Transfer-Encoding prima di consegnare il messaggio di risposta a un client HTTP.
I proxy e i gateway da HTTP a protocolli conformi a MIME sono responsabili di garantire che il messaggio sia nel formato e nella codifica corretti per un trasporto sicuro su quel protocollo, dove "trasporto sicuro" è definito dalle limitazioni del protocollo utilizzato. Tali proxy o gateway dovrebbero trasformare ed etichettare i dati con un Content-Transfer-Encoding appropriato se ciò migliora la probabilità di trasporto sicuro sul protocollo di destinazione.
A.6. MHTML and Line Length Limitations (MHTML e limitazioni di lunghezza della riga)
Le implementazioni HTTP che condividono codice con implementazioni MHTML [RFC2557] devono essere consapevoli delle limitazioni di lunghezza della riga MIME. Poiché HTTP non ha questa limitazione, HTTP non piega le righe lunghe. I messaggi MHTML trasportati tramite HTTP seguono tutte le convenzioni di MHTML, incluse le limitazioni di lunghezza della riga e la piegatura, la canonizzazione, ecc., poiché HTTP trasporta tutti i corpi dei messaggi come payload e, a parte il tipo "multipart/byteranges" (Appendice A di [RFC7233]), non interpreta il contenuto o le righe di intestazione MIME che potrebbero esservi contenute.