Mime RFC Confusione del parametro "Content-Type"? Specifiche RFC poco chiare

Question

Sto cercando di implementare un parser MIME di base per il multipart/related In C ++/Qt.

Finora ho scritto un codice parser di base per le intestazioni e sto leggendo gli RFC per avere un'idea di come fare tutto il più vicino possibile alle specifiche. Sfortunatamente c'è una parte nella RFC che mi confonde un po ':

Da RFC882 Sezione 3.1.1:

Ogni campo di intestazione può essere visto come una singola linea logica di caratteri ASCII, che comprende un campo di campo e un campo da campo. Per comodità, la parte sul campo di campo di questa entità concettuale può essere divisa in una rappresentazione a più linee; Questo si chiama "pieghevole". La regola generale è che ovunque ci possa essere spazio bianco lineare (non semplicemente LWSP-CHARS), un CRLF immediatamente seguito da almeno un LWSP-Car può invece essere inserito. Quindi, la singola riga

Va bene, quindi analizzo semplicemente un campo di intestazione e se un CRLF segue con spazio bianco lineare, sono semplicemente concatto quelli in modo utile per provocare una singola linea di intestazione. Procediamo ...

Da RFC2045 Sezione 5.1:

Nella notazione BNF aumentata di RFC 822, un valore del campo di intestazione di tipo contenuto è definito come segue:

 content := "Content-Type" ":" type "/" subtype
            *(";" parameter)
            ; Matching of media type and subtype
            ; is ALWAYS case-insensitive.

[...]

 parameter := attribute "=" value

 attribute := token
              ; Matching of attributes
              ; is ALWAYS case-insensitive.

 value := token / quoted-string

 token := 1*<any (US-ASCII) CHAR except SPACE, CTLs,
             or tspecials>

Bene. Quindi sembra se vuoi specificare un Content-Type Intestazione con parametri, fallo semplicemente in questo modo:

Content-Type: multipart/related; foo=bar; something=else

... e una versione piegata della stessa intestazione sarebbe così:

Content-Type: multipart/related;
    foo=bar;
    something=else

Corretta? Bene. Mentre continuavo a leggere gli RFC, mi sono imbattuto in quanto segue RFC2387 Sezione 5.1 (esempi):

 Content-Type: Multipart/Related; boundary=example-1
         start="<950120.aaCC@XIson.com>";
         type="Application/X-FixedRecord"
         start-info="-o ps"

 --example-1
 Content-Type: Application/X-FixedRecord
 Content-ID: <950120.aaCC@XIson.com>

 [data]
 --example-1
 Content-Type: Application/octet-stream
 Content-Description: The fixed length records
 Content-Transfer-Encoding: base64
 Content-ID: <950120.aaCB@XIson.com>

 [data]

 --example-1--

Hmm, questo è strano. Vedi il Content-Type intestazione? Ha un numero di parametri, ma non tutti hanno un ";" come delimitatore dei parametri.

Forse non ho letto correttamente gli RFC, ma se il mio parser funziona rigorosamente come definisce la specifica, il type e start-info I parametri comporterebbero una singola stringa o peggio, un errore di parser.

Ragazzi, qual è il tuo pensiero su questo? Solo un errore di battitura negli RFC? O mi sono perso qualcosa?

Grazie!

Answer 1

È un errore di battitura negli esempi. I parametri devono sempre essere delimitati con i punti e virgole correttamente, anche se piegati. La piegatura non ha lo scopo di modificare la semantica di un'intestazione, solo per consentire la leggibilità e tenere conto dei sistemi che hanno restrizioni di lunghezza della linea.

Answer 2

Molto probabilmente un errore di battitura, ma in generale (e per esperienza) dovresti essere in grado di gestire questo tipo di cose "in natura". In particolare, i clienti di posta variano selvaggiamente Nella loro capacità di generare messaggi validi e seguire tutte le specifiche pertinenti (se non altro, è ancora peggio nel mondo e -mail/SMTP di quanto non sia il mondo del WWW!)