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:

1. 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
   

2. If the string is the first disposition-type considered:
   1. 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.
3. If the string is a name-value-pair:
   1. 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.
   2. 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:

1. If the encoded-string contains non-ASCII characters, emit the encoded-string (decoded as ISO-8859-1) and abort these steps.
2. Let the url-unescaped-string be the encoded-string %-unescaped.
3. 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.