1. Introduzione (Introduction)
La RFC 2616 definisce il campo di intestazione di risposta (Response Header Field) Content-Disposition (Sezione 19.5.1 di [RFC2616]) ma sottolinea che non fa parte dello standard HTTP/1.1 (Sezione 15.5):
Content-Disposition non fa parte dello standard HTTP, ma poiché è ampiamente implementato, stiamo documentando il suo utilizzo e i rischi per gli implementatori.
Questa specifica assume la definizione e la registrazione di Content-Disposition, come utilizzato in HTTP. Basandosi su test di interoperabilità con agenti utente (User Agent, UA) esistenti, definisce completamente un profilo (Profile) delle funzionalità definite nella variante Multipurpose Internet Mail Extensions (MIME) ([RFC2183]) del campo di intestazione, e chiarisce anche gli aspetti di internazionalizzazione.
Nota: Questo documento non si applica ai campi di intestazione Content-Disposition che appaiono nei corpi di payload (Payload Body) trasmessi tramite HTTP, come quando si utilizza il tipo di media (Media Type) "multipart/form-data" ([RFC2388]).
2. Convenzioni di notazione (Notational Conventions)
Le parole chiave "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" e "OPTIONAL" in questo documento devono essere interpretate come descritto in [RFC2119].
- MUST / MUST NOT: deve / non deve
- REQUIRED: richiesto / obbligatorio
- SHALL / SHALL NOT: deve / non deve
- SHOULD / SHOULD NOT: dovrebbe / non dovrebbe
- RECOMMENDED: raccomandato
- MAY: può
- OPTIONAL: opzionale
Questa specifica utilizza la notazione BNF aumentata (Augmented BNF, ABNF) definita nella Sezione 2.1 di [RFC2616], incluse le sue regole per lo spazio bianco lineare implicito (Linear Whitespace, LWS).
3. Conformità e gestione degli errori (Conformance and Error Handling)
Questa specifica definisce criteri di conformità sia per i mittenti (solitamente, server di origine HTTP (HTTP Origin Server)) che per i destinatari (solitamente, agenti utente HTTP (HTTP User Agent)) del campo di intestazione Content-Disposition. Un'implementazione è considerata conforme se rispetta tutti i requisiti associati al suo ruolo.
Questa specifica definisce anche certe forme del valore del campo di intestazione come non valide, utilizzando sia requisiti ABNF che in prosa (Sezione 4), ma non definisce una gestione speciale di questi valori di campo non validi.
I mittenti non devono generare campi di intestazione Content-Disposition non validi (MUST NOT).
I destinatari possono adottare misure per recuperare un valore di campo utilizzabile da un campo di intestazione non valido (MAY), ma non dovrebbero rifiutare completamente il messaggio (SHOULD NOT), a meno che questo non sia esplicitamente un comportamento desiderabile (ad esempio, l'implementazione è un validatore (Validator)). Pertanto, la gestione predefinita dei campi non validi è di ignorarli.