Version 27 (modified by ietf@…, 10 years ago) (diff) |
---|
A proposal for optional error handling in processing the Content-Disposition header field
This document does not require any specific handling of invalid header field values. With this in mind, the text below describes a simple strategy for parsing the header field and detecting problems in general, or in specific parameters.
Combine Multiple Instances of Content-Disposition
If the HTTP message contains multiple instances of the Content- Disposition header field, combine all field values into a single one as specified in Section 4.2 of [RFC2616].
Parsing for Disposition Type and Parameters
Parse the field value using the state machine below (starting in the INITIAL state):
INITIAL: <"> => Buffer the current character and switch to the QUOTED state. ";" => Emit the buffered characters. EOF => Emit the buffered characters. OTHER => Buffer the current character. QUOTED: <"> => Buffer the current character and switch to the INITIAL state. EOF => Emit the buffered characters. OTHER => Buffer the current character.
Consider each emitted string of characters in turn:
- If the string matches the grammar below, the string is a name-value-pair. Otherwise, the string is a disposition-type.
name-value-pair = name "=" value name = <OCTET, except "="> value = OCTET
- If the string is the first disposition-type considered:
- The nominal disposition type of the header field is the string with any ACII upper-case characters replaced with their lower-case equivalents and with all leading and trailing LWS removed.
- If the string is a name-value-pair:
- Let the canonicalized-name be the name with any ASCII upper-case characters replaced with their lower-case equivalents and with all leading and trailing LWS removed.
- This is the first name-value-pair with this canonicalized-name, then the canonicalized-name parameter of the header field is value.
Extracting the Disposition Type
If the header field has a nominal disposition type of "inline" or the header field does not have a nominal disposition type, then the header field's disposition type is "inline". Otherwise, the header field's disposition type is "attachment".
Determining the File Name
If the header field has a "filename*" parameter and the value of the "filename*" parameter is an RFC5987-value, then the header field's file name is the the RFC5987-decoding of the value of the "filename*" parameter.
Otherwise, if the header field has a "filename" parameter, then the header field's file name is the filename-decoding (defined below) of the value of the "filename" parameter.
Decoding Filename Parameter Values
To filename-decode an encoded-string, use the following algorithm:
- If the encoded-string contains non-ASCII characters, emit the encoded-string (decoded as ISO-8859-1) and abort these steps.
- Let the url-unescaped-string be the encoded-string %-unescaped.
- Emit the url-unescaped-string (decoded as UTF-8).
Note that this algorithm starts with a sequence of octets obtained from the HTTP message, and results in a sequence of Unicode characters.