Passa al contenuto principale

5. Campo di Intestazione Content-Type (Content-Type Header Field)

Lo scopo del campo Content-Type è descrivere i dati contenuti nel corpo in modo sufficientemente completo affinché l'agente utente ricevente (User Agent) possa scegliere un agente o un meccanismo appropriato per presentare i dati all'utente, o altrimenti trattare i dati in modo appropriato. Il valore in questo campo è chiamato tipo di media (Media Type).

NOTA STORICA: Il campo di intestazione Content-Type è stato definito per la prima volta nella RFC 1049. La RFC 1049 utilizzava una sintassi più semplice e meno potente, ma che è in gran parte compatibile con il meccanismo fornito qui.

Il campo di intestazione Content-Type specifica la natura dei dati nel corpo di un'entità fornendo identificatori di tipo e sottotipo di media, e fornendo informazioni ausiliarie che possono essere richieste per determinati tipi di media. Dopo i nomi di tipo e sottotipo di media, il resto del campo di intestazione è semplicemente un insieme di parametri, specificati in notazione attribute=value. L'ordine dei parametri non è significativo.

In generale, il tipo di media di livello superiore viene utilizzato per dichiarare il tipo generale di dati, mentre il sottotipo specifica un formato specifico per quel tipo di dati. Quindi, un tipo di media di "image/xyz" è sufficiente per dire a un agente utente che i dati sono un'immagine, anche se l'agente utente non ha conoscenza del formato di immagine specifico "xyz". Tali informazioni possono essere utilizzate, ad esempio, per decidere se mostrare o meno a un utente i dati grezzi da un sottotipo non riconosciuto - tale azione potrebbe essere ragionevole per sottotipi non riconosciuti di testo, ma non per sottotipi non riconosciuti di immagine o audio. Per questo motivo, i sottotipi registrati di testo, immagine, audio e video non dovrebbero (SHOULD NOT) contenere informazioni incorporate che sono realmente di un tipo diverso. Tali formati composti dovrebbero (SHOULD) essere rappresentati utilizzando i tipi "multipart" o "application".

I parametri sono modificatori del sottotipo di media e, come tali, non alterano fondamentalmente la natura del contenuto. L'insieme dei parametri significativi dipende dal tipo e dal sottotipo di media. La maggior parte dei parametri è associata a un singolo sottotipo specifico. Tuttavia, un dato tipo di media di livello superiore può definire parametri che sono applicabili a qualsiasi sottotipo di quel tipo. I parametri possono essere richiesti dal loro tipo di contenuto o sottotipo definente o possono essere opzionali. Le implementazioni MIME devono (MUST) ignorare tutti i parametri i cui nomi non riconoscono.

Ad esempio, il parametro "charset" è applicabile a qualsiasi sottotipo di "text", mentre il parametro "boundary" è richiesto per qualsiasi sottotipo del tipo di media "multipart".

NON ci sono (NO) parametri globalmente significativi che si applicano a tutti i tipi di media. I meccanismi che potrebbero essere considerati globali in MIME sono meglio affrontati nel modello MIME definendo campi di intestazione Content-* aggiuntivi.

Un insieme iniziale di sette tipi di media di livello superiore è definito nella RFC 2046. Cinque di questi sono tipi discreti (Discrete Types) il cui contenuto è opaco per quanto riguarda l'elaborazione MIME. I restanti due sono tipi compositi (Composite Types) il cui contenuto richiede un'elaborazione MIME aggiuntiva.

Questo insieme di tipi di media di livello superiore è inteso come sostanzialmente completo. Si prevede che le aggiunte all'insieme più ampio di tipi supportati possano generalmente essere realizzate mediante la creazione di nuovi sottotipi di questi tipi iniziali. In futuro, più tipi di livello superiore possono essere definiti solo da un'estensione standards-track a questo standard. Se un altro tipo di livello superiore deve essere utilizzato per qualsiasi motivo, deve (MUST) ricevere un nome che inizia con "X-" per indicare il suo stato non standard e per evitare un potenziale conflitto con un nome ufficiale futuro.

5.1. Sintassi del Campo di Intestazione Content-Type (Syntax of the Content-Type Header Field)

Nella notazione BNF aumentata di RFC 822, un valore del campo di intestazione Content-Type è definito come segue:

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

type := discrete-type / composite-type

discrete-type := "text" / "image" / "audio" / "video" /
"application" / extension-token

composite-type := "message" / "multipart" / extension-token

extension-token := ietf-token / x-token

ietf-token := <An extension token defined by a
standards-track RFC and registered
with IANA.>

x-token := <The two characters "X-" or "x-" followed, with
no intervening white space, by any token>

subtype := extension-token / iana-token

iana-token := <A publicly-defined extension token. Tokens
of this form must be registered with IANA
as specified in RFC 2048.>

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>

tspecials := "(" / ")" / "<" / ">" / "@" /
"," / ";" / ":" / "\" / <">
"/" / "[" / "]" / "?" / "="
; Must be in quoted-string,
; to use within parameter values

5.2. Valori Predefiniti di Content-Type (Content-Type Defaults)

Se un campo di intestazione Content-Type non è presente in un'entità, il Content-Type predefinito dipende dal contesto:

  • Al livello superiore di un messaggio MIME, il valore predefinito è text/plain; charset=us-ascii
  • All'interno di una parte del corpo di un'entità multipart, il Content-Type predefinito è text/plain; charset=us-ascii
  • All'interno di un'entità "message/rfc822", il Content-Type predefinito è text/plain; charset=us-ascii

Punti Chiave:

  • Formato Content-Type: type/subtype; parameter=value
  • Il tipo e il sottotipo sono insensibili al maiuscolo/minuscolo
  • I nomi dei parametri sono insensibili al maiuscolo/minuscolo, ma i valori sono solitamente sensibili
  • Valore predefinito: text/plain; charset=us-ascii

Sette Tipi di Media di Livello Superiore:

Tipi Discreti (Discrete Types)

  1. text: Dati testuali
  2. image: Dati di immagine
  3. audio: Dati audio
  4. video: Dati video
  5. application: Dati di applicazione

Tipi Compositi (Composite Types)

  1. message: Messaggio incapsulato
  2. multipart: Più parti