Appendice A. Modifiche rispetto alla definizione RFC 2616 (Changes from the RFC 2616 Definition)

Rispetto alla Sezione 19.5.1 di [RFC2616], sono state apportate le seguenti modifiche normative che riflettono le implementazioni effettive:

• Secondo RFC 2616, il tipo di disposizione (Disposition Type) "attachment" si applica solo al contenuto di tipo "application/octet-stream". Questa restrizione è stata rimossa, perché i destinatari in pratica non verificano il tipo di contenuto (Content Type), e inoltre scoraggia la dichiarazione corretta del tipo di media (Media Type).

• RFC 2616 consente solo "quoted-string" per il parametro filename. Questa sarebbe una sintassi di parametro eccezionale, e inoltre non riflette l'uso effettivo.

• La definizione per il tipo di disposizione "inline" ([RFC2183], Sezione 2.1) è stata riaggiunta con un suggerimento per la sua elaborazione.

• Questa specifica richiede (REQUIRED) il supporto per la codifica dei parametri estesa (Extended Parameter Encoding) definita in [RFC5987].

Appendice B. Differenze rispetto a RFC 2183 (Differences Compared to RFC 2183)

La Sezione 2 di [RFC2183] definisce diversi parametri di disposizione (Disposition Parameter) aggiuntivi: "creation-date", "modification-date", "quoted-date-time" e "size". La maggior parte degli agenti utente (User Agent) non li implementa; pertanto, sono stati omessi da questa specifica.

Appendice C. Approcci alternativi per l'internazionalizzazione (Alternative Approaches to Internationalization)

Per impostazione predefinita, i parametri del campo di intestazione HTTP (HTTP Header Field Parameter) non possono trasportare caratteri al di fuori della codifica di caratteri (Character Encoding) ISO-8859-1 ([ISO-8859-1]) (vedi [RFC2616], Sezione 2.2). Per il parametro "filename", questa è ovviamente una restrizione inaccettabile.

Sfortunatamente, gli implementatori di agenti utente non sono riusciti a trovare un approccio interoperabile, sebbene il percorso degli standard IETF (IETF Standards Track) specifichi esattamente una soluzione ([RFC2231], chiarita e profilata per HTTP in [RFC5987]).

Per completezza, le sezioni seguenti descrivono i vari approcci che sono stati tentati, e spiegano come sono inferiori alla codifica (Encoding) RFC 5987 utilizzata in questa specifica.

C.1. Codifica RFC 2047 (RFC 2047 Encoding)

RFC 2047 definisce un meccanismo di codifica (Encoding Mechanism) per i campi di intestazione (Header Field), ma questa codifica non dovrebbe essere utilizzata per i parametri del campo di intestazione -- vedi Sezione 5 di [RFC2047]:

Un 'encoded-word' non deve apparire all'interno di un 'quoted-string' (MUST NOT).

...

Un 'encoded-word' non deve essere utilizzato in un parametro di un campo MIME Content-Type o Content-Disposition, o in qualsiasi corpo di campo strutturato tranne all'interno di un 'comment' o di una 'phrase' (MUST NOT).

In pratica, alcuni agenti utente implementano la codifica, alcuni non lo fanno (esponendo la stringa codificata all'utente), e alcuni vengono confusi da essa.

C.2. Codifica percentuale (Percent Encoding)

Alcuni agenti utente accettano sequenze di caratteri (Character Sequence) codificate in percentuale ([RFC3986], Sezione 2.1). La codifica dei caratteri utilizzata per la decodifica dipende da vari fattori, inclusa la codifica della pagina di riferimento, la locale (Locale) dell'agente utente, la sua configurazione, e anche il valore effettivo del parametro.

In pratica, questo è difficile da utilizzare perché gli agenti utente che non lo supportano mostreranno la sequenza di caratteri escapati all'utente. Per quelli che lo implementano, è difficile prevedere quale codifica dei caratteri si aspettino effettivamente.

C.3. Rilevamento della codifica (Encoding Sniffing)

Alcuni agenti utente ispezionano il valore (che per impostazione predefinita è ISO-8859-1 per la forma quoted-string) e passano a UTF-8 quando sembra più probabile che sia l'interpretazione corretta.

Come con gli approcci precedenti, questo non è interoperabile e, inoltre, rischia di interpretare erroneamente il valore effettivo.

Appendice D. Consigli per generare campi di intestazione Content-Disposition (Advice on Generating Content-Disposition Header Fields)

Per interoperare con successo con gli agenti utente (User Agent) esistenti e futuri, si consiglia ai mittenti del campo di intestazione (Header Field) Content-Disposition di:

• Includere un parametro "filename" quando US-ASCII ([US-ASCII]) è sufficientemente espressivo.

• Utilizzare la forma 'token' del parametro filename solo quando non contiene caratteri non consentiti (ad esempio, spazi); in tali casi, dovrebbe essere utilizzata la forma quoted-string.

• Evitare di includere il carattere percentuale seguito da due caratteri esadecimali (ad esempio, %A9) nel parametro filename, poiché alcune implementazioni esistenti lo considerano un carattere di escape (Escape Character), mentre altre lo lasciano passare invariato.

• Evitare di includere il carattere "\" nella forma quoted-string del parametro filename, poiché l'escape non è implementato da alcuni agenti utente, e "\" può essere considerato un carattere di percorso (Path Character) illegale.

• Evitare di utilizzare caratteri non-ASCII nel parametro filename. Sebbene la maggior parte delle implementazioni esistenti li decodifichi come ISO-8859-1, alcune applicheranno euristiche (Heuristic) per rilevare UTF-8, e quindi potrebbero fallire su certi nomi.

• Includere un parametro "filename*" quando il nome file desiderato non può essere espresso fedelmente utilizzando la forma "filename". Si noti che gli agenti utente legacy (Legacy User Agent) non elaboreranno questo, e si affideranno all'utilizzo del contenuto del parametro "filename".

• Quando viene inviato un parametro "filename*", generare anche un parametro "filename" come fallback (Fallback) per gli agenti utente che non supportano la forma "filename*", se possibile. Questo può essere fatto sostituendo i caratteri con sequenze US-ASCII (ad esempio, il punto di codice Unicode (Unicode Character Point) U+00E4 (LETTERA MINUSCOLA LATINA A CON DIERESI) con "ae"). Si noti che questo potrebbe non essere possibile in alcune localizzazioni.

• Quando un parametro "filename" è incluso come fallback (come sopra), "filename" dovrebbe apparire per primo, a causa di problemi di analisi in alcune implementazioni esistenti.

• Utilizzare UTF-8 come codifica del parametro "filename*", quando presente, perché almeno un'implementazione esistente implementa solo quella codifica.

Nota: Questo consiglio si basa sul comportamento degli agenti utente (UA) al momento della scrittura e potrebbe essere sostituito. Al momento della pubblicazione di questo documento, http://purl.org/NET/http/content-disposition-tests fornisce una panoramica dei livelli di supporto attuali in varie implementazioni.