# Test Cases for HTTP Content-Disposition header and RFC 2231/2047 Encoding

## Test Cases

### Content-Disposition: Disposition-Type Inline

Various tests relating to the "inline" disposition type, see Section 2.1 of RFC 2183.

#### inlonly [TEST]

    Content-Disposition: inline

Test Results
FF3 | pass
MSIE8 | pass
Op10 | pass
Saf4 | pass
Konq | pass
Chrome | pass

'inline' only

This should be equivalent to not including the header at all.

#### inlwithasciifilename [TEST]

    Content-Disposition: inline; filename="foo.html"

Test Results
FF3 | pass (uses the filename in subsequent 'save' operation)
MSIE8 | pass (filename information not used)
Op10 | pass (filename information not used)
Saf4 | pass (filename information not used)
Konq | pass (filename information not used)
Chrome | pass (filename information not used)

'inline', specifying a filename of `foo.html`

Some UAs use this filename in a subsequent "save" operation.

#### inlwithasciifilenamepdf [TEST]

    Content-Disposition: inline; filename="foo.pdf"

Test Results
FF3 | pass (filename information not used)
MSIE8 | pass (filename information not used)
Op10 | pass (filename information not used)
Saf4 | pass (filename information not used)
Konq | pass (filename information not used)
Chrome | pass (filename information not used)

'inline', specifying a filename of `foo.pdf`

Some UAs use this filename in a subsequent "save" operation. This variation of the test checks whether whatever handles PDF display receives the filename information, and acts upon it (this was tested with the latest Acrobat Reader plugin).

### Content-Disposition: Disposition-Type Attachment

Various tests relating to the "attchment" disposition type, see Section 2.2 of RFC 2183.

#### attonly [TEST]

    Content-Disposition: attachment

Test Results
FF3 | pass
MSIE8 | pass
Op10 | pass
Saf4 | pass
Konq | pass
Chrome | pass

'attachment' only

UA should offer to download the resource.

#### attonlyucase [TEST]

    Content-Disposition: ATTACHMENT

Test Results
FF3 | pass
MSIE8 | pass
Op10 | pass
Saf4 | pass
Konq | fail
Chrome | pass

'ATTACHMENT' only

UA should offer to download the resource.

#### attwithasciifilename [TEST]

    Content-Disposition: attachment; filename="foo.html"

Test Results
FF3 | pass
MSIE8 | pass
Op10 | pass
Saf4 | pass
Konq | pass
Chrome | pass

'attachment', specifying a filename of `foo.html`

UA should offer to download the resource as "foo.html".

#### attwithasciifnescapedchar [TEST]

    Content-Disposition: attachment; filename="f\oo.html"

Test Results
FF3 | fail (apparently does not treat the backslash as escape character, replaces it with '_')
MSIE8 | fail (apparently does not treat the backslash as escape character, replaces it with '_')
Op10 | pass
Saf4 | fail (apparently does not treat the backslash as escape character, replaces it with '-')
Konq | pass
Chrome | fail (saves "oo.html" (what's going on here?))

'attachment', specifying a filename of `f\oo.html` (the first 'o' being escaped)

UA should offer to download the resource as "foo.html".

#### attwithfilenameandextparam [TEST]

    Content-Disposition: attachment; foo="bar"; filename="foo.html"

Test Results
FF3 | pass
MSIE8 | pass
Op10 | pass
Saf4 | pass
Konq | pass
Chrome | pass

'attachment', specifying a filename of `foo.html` and an extension parameter "foo" which should be ignored (see Section 2.8 of RFC 2183.).

UA should offer to download the resource as "foo.html".

#### attwithasciifilenameucase [TEST]

    Content-Disposition: attachment; FILENAME="foo.html"

Test Results
FF3 | pass
MSIE8 | pass
Op10 | pass
Saf4 | pass
Konq | fail (filename parameter is ignored)
Chrome | pass

'attachment', specifying a filename of `foo.html`

UA should offer to download the resource as "foo.html".

#### attwithasciifilenamenq [TEST]

    Content-Disposition: attachment; filename=foo.html

Test Results
FF3 | warn (accepts the unquoted value)
MSIE8 | warn (accepts the unquoted value)
Op10 | warn (accepts the unquoted value)
Saf4 | warn (accepts the unquoted value)
Konq | warn (accepts the unquoted value)
Chrome | warn (accepts the unquoted value)

'attachment', specifying a filename of `foo.html`, but missing the quotes.

This is invalid according to Section 19.5.1 of RFC2616, so UAs should ignore it.

#### attwithisofnplain [TEST]

    Content-Disposition: attachment; filename="foo-ä.html"

Test Results
FF3 | pass
MSIE8 | pass
Op10 | pass
Saf4 | pass
Konq | pass
Chrome | pass

'attachment', specifying a filename of `foo-ä.html`, using plain ISO-8859-1

UA should offer to download the resource as "foo-ä.html".

#### attwithutf8fnplain [TEST]

    Content-Disposition: attachment; filename="foo-Ã¤.html"

Test Results
FF3 | fail (decodes as UTF-8)
MSIE8 | pass
Op10 | pass
Saf4 | pass
Konq | pass
Chrome | fail (decodes as UTF-8)

'attachment', specifying a filename of `foo-Ã¤.html`, which happens to be `foo-ä.html` using UTF-8 encoding.

UA should offer to download the resource as "foo-Ã¤.html". Displaying "foo-ä.html" instead indicates that the UA tried to be smart by detecting something that happens to look like UTF-8.

#### attwithfnrawpctenca [TEST]

    Content-Disposition: attachment; filename="foo-%41.html"

Test Results
FF3 | pass
MSIE8 | fail (displays "foo-A.html")
Op10 | pass
Saf4 | pass
Konq | pass
Chrome | fail (displays "foo-A.html" (see Chrome Issue 118))

'attachment', specifying a filename of `foo-%41.html`

UA should offer to download the resource as "foo-%41.html". Displaying "foo-A.html" instead would indicate that the UA has attempted to percent-decode the parameter.

#### attwithfnrawpctenclong [TEST]

    Content-Disposition: attachment; filename="foo-%c3%a4-%e2%82%ac.html"

Test Results
FF3 | pass
MSIE8 | fail (displays "foo-ä-€.html")
Op10 | pass
Saf4 | pass
Konq | pass
Chrome | fail (displays "foo-ä-€.html" (see Chrome Issue 118))

'attachment', specifying a filename of `foo-%c3%a4-%e2%82%ac.html`, using raw percent encoded UTF-8 to represent `foo-ä-€.html`

UA should offer to download the resource as "foo-%c3%a4-%e2%82%ac.html". Displaying "foo-ä-€.html" instead would indicate that the UA has attempted to percent-decode the parameter (using UTF-8). Displaying something else would indicate that the UA tried to percent-decode, but used a different encoding.

#### attwithasciifilenamews1 [TEST]

    Content-Disposition: attachment; filename ="foo.html"

Test Results
FF3 | pass
MSIE8 | pass
Op10 | pass
Saf4 | pass
Konq | pass
Chrome | pass

'attachment', specifying a filename of `foo.html`, with one blank space before the equals character.

UA should offer to download the resource as "foo.html".

#### attwithasciifilenamews2 [TEST]

    Content-Disposition: attachment; filename= "foo.html"

Test Results
FF3 | pass
MSIE8 | pass
Op10 | pass
Saf4 | pass
Konq | pass
Chrome | pass

'attachment', specifying a filename of `foo.html`, with one blank space after the equals character.

UA should offer to download the resource as "foo.html".

#### attfnbrokentoken [TEST]

    Content-Disposition: attachment; filename=foo[1](2).html

Test Results
FF3 | warn (accepts the unquoted value)
MSIE8 | warn (accepts the unquoted value)
Op10 | warn (accepts the unquoted value)
Saf4 | warn (accepts the unquoted value)
Konq | warn (accepts the unquoted value)
Chrome | warn (accepts the unquoted value)

'attachment', specifying a filename of `foo[1](2).html`, but missing the quotes. Also, "[", "]", "(" and ")" are not allowed in the HTTP token production.

This is invalid according to Section 19.5.1 of RFC2616, so UAs should ignore it.

### Content-Disposition: Additional Parameters

Various tests relating to the additional parameters defined in Section 2 of RFC 2183.

#### attcdate [TEST]

    Content-Disposition: attachment; creation-date="Wed, 12 Feb 1997 16:29:51 -0500"

Test Results
FF3 | unsupported (seems to ignore the parameter)
MSIE8 | unsupported (seems to ignore the parameter)
Op10 | unsupported (seems to ignore the parameter)
Saf4 | unsupported (seems to ignore the parameter)
Konq | unsupported (seems to ignore the parameter)
Chrome | unsupported (seems to ignore the parameter)

'attachment', plus creation-date (see Section 2.4 of RFC 2183)

UA should offer to download the resource. When doing so, the creation date should be set to 12 Feb 1997.

#### attmdate [TEST]

    Content-Disposition: attachment; modification-date="Wed, 12 Feb 1997 16:29:51 -0500"

Test Results
FF3 | unsupported (seems to ignore the parameter)
MSIE8 | unsupported (seems to ignore the parameter)
Op10 | unsupported (seems to ignore the parameter)
Saf4 | unsupported (seems to ignore the parameter)
Konq | unsupported (seems to ignore the parameter)
Chrome | unsupported (seems to ignore the parameter)

'attachment', plus modification-date (see Section 2.5 of RFC 2183)

UA should offer to download the resource. When doing so, the modification date should be set to 12 Feb 1997.

### Content-Disposition: Disposition-Type Extension

A test checking behavior for disposition type extensions, which should be treated as "attachment", see Section 2.8 of RFC 2183.

#### dispext [TEST]

    Content-Disposition: foobar

Test Results
FF3 | pass
MSIE8 | fail (does not treat it as 'attachment')
Op10 | fail (does not treat it as 'attachment')
Saf4 | fail (does not treat it as 'attachment')
Konq | fail (does not treat it as 'attachment')
Chrome | pass

'foobar' only

This should be equivalent to using "attachment".

### RFC2231 Encoding: Character Sets

Various tests using the parameter value encoding defined in Section 4 of RFC 2231.

#### attwithisofn2231iso [TEST]

    Content-Disposition: attachment; filename*=iso-8859-1''foo-%E4.html

Test Results
FF3 | pass
MSIE8 | unsupported
Op10 | pass
Saf4 | unsupported
Konq | unsupported
Chrome | unsupported

'attachment', specifying a filename of `foo-ä.html`, using RFC2231 encoded ISO-8859-1

UA should offer to download the resource as "foo-ä.html".

#### attwithfn2231utf8 [TEST]

    Content-Disposition: attachment; filename*=UTF-8''foo-%c3%a4-%e2%82%ac.html

Test Results
FF3 | pass
MSIE8 | unsupported
Op10 | pass
Saf4 | unsupported
Konq | unsupported
Chrome | unsupported

'attachment', specifying a filename of `foo-ä-€.html`, using RFC2231 encoded UTF-8

UA should offer to download the resource as "foo-ä-€.html".

#### attwithfn2231noc [TEST]

    Content-Disposition: attachment; filename*=''foo-%c3%a4-%e2%82%ac.html

Test Results
FF3 | warn (decodes as UTF-8)
MSIE8 | unsupported
Op10 | warn (decodes as 8bit encoding (ISO-8859-1?))
Saf4 | unsupported
Konq | unsupported
Chrome | unsupported

Behavior is undefined in RFC 2231, the charset part is missing, although UTF-8 was used.

#### attwithfn2231utf8comp [TEST]

    Content-Disposition: attachment; filename*=UTF-8''foo-a%cc%88.html

Test Results
FF3 | pass
MSIE8 | unsupported
Op10 | warn (displays "foo-ä.html")
Saf4 | unsupported
Konq | unsupported
Chrome | unsupported

'attachment', specifying a filename of `foo-ä.html`, using RFC2231 encoded UTF-8, but choosing the decomposed form (lowercase a plus COMBINING DIAERESIS) -- on a Windows target system, this should be translated to the preferred Unicode normal form (composed).

UA should offer to download the resource as "foo-ä.html".

#### attwithfn2231utf8-bad [TEST]

    Content-Disposition: attachment; filename*=iso-8859-1''foo-%c3%a4-%e2%82%ac.html

Test Results
FF3 | fail (falls back to UTF-8)
MSIE8 | unsupported
Op10 | warn (displays the raw octet sequence as if it was ISO-8859-1 (which is internally treated as windows-1252, which does allow %82))
Saf4 | unsupported
Konq | unsupported
Chrome | unsupported

'attachment', specifying a filename of `foo-ä-€.html`, using RFC2231 encoded UTF-8, but declaring ISO-8859-1

The octet %82 does not represent a valid ISO-8859-1 code point, so the UA should really ignore the parameter.

#### attwithfn2231ws1 [TEST]

    Content-Disposition: attachment; filename *=UTF-8''foo-%c3%a4.html

Test Results
FF3 | fail (displays garbage)
MSIE8 | unsupported
Op10 | pass
Saf4 | unsupported
Konq | unsupported
Chrome | unsupported

'attachment', specifying a filename of `foo-ä.html`, using RFC2231 encoded UTF-8, with whitespace before "*="

The parameter is invalid, thus should be ignored.

#### attwithfn2231ws2 [TEST]

    Content-Disposition: attachment; filename*= UTF-8''foo-%c3%a4.html

Test Results
FF3 | pass
MSIE8 | unsupported
Op10 | pass
Saf4 | unsupported
Konq | unsupported
Chrome | unsupported

'attachment', specifying a filename of `foo-ä.html`, using RFC2231 encoded UTF-8, with whitespace after "*="

UA should offer to download the resource as "foo-ä.html".

#### attwithfn2231ws3 [TEST]

    Content-Disposition: attachment; filename* =UTF-8''foo-%c3%a4.html

Test Results
FF3 | pass
MSIE8 | unsupported
Op10 | pass
Saf4 | unsupported
Konq | unsupported
Chrome | unsupported

'attachment', specifying a filename of `foo-ä.html`, using RFC2231 encoded UTF-8, with whitespace inside "* ="

UA should offer to download the resource as "foo-ä.html".

#### attwithfn2231quot [TEST]

    Content-Disposition: attachment; filename*="UTF-8''foo-%c3%a4.html"

Test Results
FF3 | fail (tries to be helpful by removing the quotes)
MSIE8 | unsupported
Op10 | pass
Saf4 | unsupported
Konq | unsupported
Chrome | unsupported

'attachment', specifying a filename of `foo-ä.html`, using RFC2231 encoded UTF-8, with double quotes around the parameter value.

The parameter is invalid, thus should be ignored.

#### attwithfn2231encmissing [TEST]

    Content-Disposition: attachment; filename*=''foo-%c3%a4.html

Test Results
FF3 | fail (sniffs the encoding as UTF-8)
MSIE8 | unsupported
Op10 | fail (assumes a default of ISO-8859-1)
Saf4 | unsupported
Konq | unsupported
Chrome | unsupported

'attachment', specifying a filename of `foo-ä.html`, using RFC2231 encoded UTF-8, but leaving out the charset field.

The parameter is invalid, thus should be ignored.

### RFC2231 Encoding: Continuations

Various tests using the parameter value continuation efined in Section 3 of RFC 2231.

#### attfncont [TEST]

    Content-Disposition: attachment; filename*0="foo."; filename*1="html"

Test Results
FF3 | pass
MSIE8 | unsupported
Op10 | pass
Saf4 | unsupported
Konq | unsupported
Chrome | unsupported

'attachment', specifying a filename of `foo.html`, using RFC2231-style parameter continuations.

UA should offer to download the resource as "foo.html".

#### attfncontenc [TEST]

    Content-Disposition: attachment; filename*0*=UTF-8''foo-%c3%a4; filename*1=".html"

Test Results
FF3 | pass
MSIE8 | unsupported
Op10 | pass
Saf4 | unsupported
Konq | unsupported
Chrome | unsupported

'attachment', specifying a filename of `foo-ä.html`, using both RFC2231-style parameter continuations and UTF-8 encoding.

UA should offer to download the resource as "foo-ä.html".

#### attfncontlz [TEST]

    Content-Disposition: attachment; filename*0="foo"; filename*01="bar"

Test Results
FF3 | warn (accepts leading zeros)
MSIE8 | unsupported
Op10 | warn (accepts leading zeros)
Saf4 | unsupported
Konq | unsupported
Chrome | unsupported

'attachment', specifying a filename of `foo` (the parameter filename*01 should be ignored because of the leading zero)

UA should offer to download the resource as "foo".

#### attfncontnc [TEST]

    Content-Disposition: attachment; filename*0="foo"; filename*2="bar"

Test Results
FF3 | warn (accepts gaps)
MSIE8 | unsupported
Op10 | pass
Saf4 | unsupported
Konq | unsupported
Chrome | unsupported

'attachment', specifying a filename of `foo` (the parameter filename*2 because there's no filename*1 parameter)

UA should offer to download the resource as "foo".

#### attfnconts1 [TEST]

    Content-Disposition: attachment; filename*1="foo."; filename*2="html"

Test Results
FF3 | pass
MSIE8 | unsupported
Op10 | pass
Saf4 | unsupported
Konq | unsupported
Chrome | unsupported

'attachment' (the filename* parameters should be ignored because filename*0 is missing)

UA should offer to download, not getting the filename from the header.

#### attfncontord [TEST]

    Content-Disposition: attachment; filename*1="bar"; filename*0="foo"

Test Results
FF3 | fail (parameters are expected to be ordered)
MSIE8 | unsupported
Op10 | pass
Saf4 | unsupported
Konq | unsupported
Chrome | unsupported

'attachment', specifying a filename of `foobar`

UA should offer to download the resource as "foobar".

### RFC2231 Encoding: Fallback Behaviour

This tests how the UA behaves when the same parameter name appear both in traditional and RFC 2231 extended format.

#### attfnboth [TEST]

    Content-Disposition: attachment; filename="foo-ae.html"; filename*=UTF-8''foo-%c3%a4.html

Test Results
FF3 | pass (picks the traditionally encoded value -- the first of both)
MSIE8 | pass (picks the traditionally encoded value -- the first of both)
Op10 | pass (picks the traditionally encoded value -- the first of both)
Saf4 | pass (picks the traditionally encoded value -- the first of both)
Konq | pass (picks the traditionally encoded value -- the first of both)
Chrome | pass (picks the traditionally encoded value -- the first of both)

'attachment', specifying a filename of `foo-ae.html` in the traditional format, and `foo-ä.html` in RFC2231 format.

The behaviour of this undefined. Thus UAs should one of the two values.

#### attfnboth2 [TEST]

    Content-Disposition: attachment; filename*=UTF-8''foo-%c3%a4.html; filename="foo-ae.html"

Test Results
FF3 | pass (picks the RFC2231 encoded value -- the first of both)
MSIE8 | fail (ignores the parameter (this indicates a parsing bug))
Op10 | pass (picks the RFC2231 encoded value -- the first of both)
Saf4 | pass (picks the traditionally encoded value -- the one it understands)
Konq | pass (picks the traditionally encoded value -- the one it understands)
Chrome | fail (ignores the parameter (this indicates a parsing bug))

'attachment', specifying a filename of `foo-ae.html` in the traditional format, and `foo-ä.html` in RFC2231 format.

The behaviour of this undefined. Thus UAs should one of the two values.

### RFC2047 Encoding

These tests RFC 2047 style encoding.

Note that according to Section 5 of RFC 2047, this encoding does not apply here: An 'encoded-word' MUST NOT appear within a 'quoted-string'., and An 'encoded-word' MUST NOT be used in parameter of a MIME Content-Type or Content-Disposition field, or in any structured field body except within a 'comment' or 'phrase'.

Therefore, these tests are only be present in order to check whether the UA by mistake tries to implement RFC2047.

#### attrfc2047token [TEST]

    Content-Disposition: attachment; filename==?ISO-8859-1?Q?foo-=E4.html?=

Test Results
FF3 | fail (decodes it anyway to "foo-ä.html")
MSIE8 | pass (takes the whole value as filename, but does not decode it (replacing question marks by underscores))
Op10 | fail (displays garbage ("=.htm"))
Saf4 | pass (takes the whole value as filename, but does not decode it (replacing question marks by underscores))
Konq | fail (decodes it anyway to "foo-ä.html")
Chrome | fail (decodes it anyway to "foo-ä.html")

Uses RFC 2047 style encoded word. "=" is invalid inside the `token` production, so this is invalid.

#### attrfc2047quoted [TEST]

    Content-Disposition: attachment; filename="=?ISO-8859-1?Q?foo-=E4.html?="

Test Results
FF3 | fail (decodes it anyway to "foo-ä.html")
MSIE8 | pass (takes the whole value as filename, but does not decode it)
Op10 | fail (displays garbage ("=.htm"))
Saf4 | pass (takes the whole value as filename, but does not decode it)
Konq | fail (decodes it anyway to "foo-ä.html")
Chrome | fail (decodes it anyway to "foo-ä.html")

Uses RFC 2047 style encoded word, using the `quoted-string` production.