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.
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.
TODO(abarth): Do we need to do something with "," here to make folding work properly? jre: folding isn't supported by C-D's ABNF, so it's not clear what 'properly' would mean. Do you data about whether this is used, or tests that indicate that UAs do the same ting here?
Consider each emitted string of characters in turn:
name-value-pair = name "=" value
name = <OCTET, except "=">
value = OCTET
If the header field has a nominal disposition type of "inline" or if 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".
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.
To filename-decode an encoded-string, use the following algorithm:
Note that this algorithm starts with a sequence of octets obtained from the HTTP message, and results in a sequence of Unicode characters.
The content on this page was last updated on 2010-12-13. It was migrated from the old Trac wiki on 2022-12-13.