Test Cases for HTTP Content-Disposition header field and the Encodings defined in RFC 2047 and RFC 2231/5987

inlonly [TEST]

Content-Disposition: inline

'inline' only

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

inlwithasciifilename [TEST]

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

'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"

'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, or, in the case of Chrome, using the builtin PDF handler).

attonly [TEST]

Content-Disposition: attachment

'attachment' only

UA should offer to download the resource.

attonly403 [TEST]

Content-Disposition: attachment

'attachment' only, but returned with a 403 status.

UA should report the server status.

attonlyucase [TEST]

Content-Disposition: ATTACHMENT

'ATTACHMENT' only

UA should offer to download the resource.

attwithasciifilename [TEST]

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

'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"

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

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

attwithasciifnescapedquote [TEST]

Content-Disposition: attachment; filename="\"quoting\" tested.html"

'attachment', specifying a filename of \"quoting\" tested.html (using double quotes around "quoting" to test... quoting)

UA should offer to download the resource as something like '"quoting" tested.html' (stripping the quotes may be ok for security reasons, but getting confused by them is not.

attwithfilenameandextparam [TEST]

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

'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"

'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

'attachment', specifying a filename of foo.html using a token instead of a quoted-string.

This is invalid according to Section 19.5.1 of RFC2616, but probably can be considered a specification bug. It is legal according to RFC 2183 and will be in draft-reschke-rfc2183-in-http.

attwithisofnplain [TEST]

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

'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"

'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"

'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"

'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"

'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"

'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

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

attcdate [TEST]

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

'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"

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

dispext [TEST]

Content-Disposition: foobar

'foobar' only

This should be equivalent to using "attachment".

attwithisofn2231iso [TEST]

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

'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

'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

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

'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

'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

'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

'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

'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"

'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

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

attfncont [TEST]

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

'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"

'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"

'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"

'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"

'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"

'attachment', specifying a filename of foobar

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

attfnboth [TEST]

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

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

Section 4.2 of RFC 5987 suggests that the RFC 2231/5987 encoded parameter ("filename*") should take precedence when understood.

attfnboth2 [TEST]

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

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

Section 4.2 of RFC 5987 suggests that the RFC 2231/5987 encoded parameter ("filename*") should take precedence when understood.

attrfc2047token [TEST]

Content-Disposition: attachment; filename==?ISO-8859-1?Q?foo-=E4.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?="

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