Test Cases for HTTP Content-Disposition header field (RFC 6266) and the Encodings defined in RFCs 2047, 2231 and 5987

inlonly [TEST] [R]

Content-Disposition: inline

'inline' only

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

Extracted raw data:

inlonlyquoted [TEST] [R]

Content-Disposition: "inline"

                     ^ (PARSE ERROR)

'inline' only, using double quotes

This is invalid syntax, thus the header should be ignored.

inlwithasciifilename [TEST] [R]

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

'inline', specifying a filename of foo.html

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

Extracted raw data:

After post-processing the disposition name, parameter names, and parameter values:

inlwithfnattach [TEST] [R]

Content-Disposition: inline; filename="Not an attachment!"

'inline', specifying a filename of Not an attachment! - this checks for proper parsing for disposition types.

Extracted raw data:

After post-processing the disposition name, parameter names, and parameter values:

inlwithasciifilenamepdf [TEST] [R]

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

Extracted raw data:

After post-processing the disposition name, parameter names, and parameter values:

attonly [TEST] [R]

Content-Disposition: attachment

'attachment' only

UA should offer to download the resource.

Extracted raw data:

attonlyquoted [TEST] [R]

Content-Disposition: "attachment"

                     ^ (PARSE ERROR)

'attachment' only, using double quotes

This is invalid syntax, thus the header should be ignored.

attonly403 [TEST] [R]

Content-Disposition: attachment

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

UA should report the server status.

Extracted raw data:

attonlyucase [TEST] [R]

Content-Disposition: ATTACHMENT

'ATTACHMENT' only

UA should offer to download the resource.

Extracted raw data:

After post-processing the disposition name, parameter names, and parameter values:

attwithasciifilename [TEST] [R]

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

'attachment', specifying a filename of foo.html

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

Extracted raw data:

After post-processing the disposition name, parameter names, and parameter values:

attwithasciifilename25 [TEST] [R]

Content-Disposition: attachment; filename="0000000000111111111122222"

'attachment', specifying a filename of 0000000000111111111122222 (25 characters)

Extracted raw data:

After post-processing the disposition name, parameter names, and parameter values:

attwithasciifilename35 [TEST] [R]

Content-Disposition: attachment; filename="00000000001111111111222222222233333"

'attachment', specifying a filename of 00000000001111111111222222222233333 (35 characters)

Extracted raw data:

After post-processing the disposition name, parameter names, and parameter values:

attwithasciifnescapedchar [TEST] [R]

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

Extracted raw data:

After post-processing the disposition name, parameter names, and parameter values:

attwithasciifnescapedquote [TEST] [R]

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

Extracted raw data:

After post-processing the disposition name, parameter names, and parameter values:

attwithquotedsemicolon [TEST] [R]

Content-Disposition: attachment; filename="Here's a semicolon;.html"

'attachment', specifying a filename of Here's a semicolon;.html - this checks for proper parsing for parameters.

Extracted raw data:

After post-processing the disposition name, parameter names, and parameter values:

attwithfilenameandextparam [TEST] [R]

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 4.4 of RFC 6266.).

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

Extracted raw data:

After post-processing the disposition name, parameter names, and parameter values:

attwithfilenameandextparamescaped [TEST] [R]

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

'attachment', specifying a filename of foo.html and an extension parameter "foo" which should be ignored (see Section 4.4 of RFC 6266.). In comparison to attwithfilenameandextparam, the extension parameter actually uses backslash-escapes. This tests whether the UA properly skips the parameter.

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

Extracted raw data:

After post-processing the disposition name, parameter names, and parameter values:

attwithasciifilenameucase [TEST] [R]

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

'attachment', specifying a filename of foo.html

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

Extracted raw data:

After post-processing the disposition name, parameter names, and parameter values:

attwithasciifilenamenq [TEST] [R]

Content-Disposition: attachment; filename=foo.html

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

Note that was invalid according to Section 19.5.1 of RFC 2616.

Extracted raw data:

attwithtokfncommanq [TEST] [R]

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

                                             ^ (PARSE ERROR)

'attachment', specifying a filename of foo,bar.html using a comma despite using token syntax.

attwithasciifilenamenqs [TEST] [R]

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

                                                   ^ (PARSE ERROR)

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

The trailing semicolon makes the header field value syntactically incorrect, as no other parameter follows. Thus the header field should be ignored.

attemptyparam [TEST] [R]

Content-Disposition: attachment; ;filename=foo

                               ^ (PARSE ERROR)

'attachment', specifying a filename of foo, but including an empty parameter.

The empty parameter makes the header field value syntactically incorrect, as no other parameter follows. Thus the header field should be ignored.

attwithasciifilenamenqws [TEST] [R]

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

                                              ^ (PARSE ERROR)

'attachment', specifying a filename of foo bar.html without using quoting.

This is invalid. "token" does not allow whitespace.

attwithfntokensq [TEST] [R]

Content-Disposition: attachment; filename='foo.bar'

'attachment', specifying a filename of 'foo.bar' using single quotes.

Extracted raw data:

attwithisofnplain [TEST] [R]

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

Extracted raw data:

After post-processing the disposition name, parameter names, and parameter values:

attwithutf8fnplain [TEST] [R]

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.

Extracted raw data:

After post-processing the disposition name, parameter names, and parameter values:

attwithfnrawpctenca [TEST] [R]

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.

Extracted raw data:

After post-processing the disposition name, parameter names, and parameter values:

attwithfnusingpct [TEST] [R]

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

'attachment', specifying a filename of 50%.html

UA should offer to download the resource as "50%.html". This tests how UAs that fails at attwithfnrawpctenca handle "%" characters that do not start a "% hexdig hexdig" sequence.

Extracted raw data:

After post-processing the disposition name, parameter names, and parameter values:

attwithfnrawpctencaq [TEST] [R]

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

'attachment', specifying a filename of foo-%41.html, using an escape character (this tests whether adding an escape character inside a %xx sequence can be used to disable the non-conformant %xx-unescaping).

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

Extracted raw data:

After post-processing the disposition name, parameter names, and parameter values:

attwithnamepct [TEST] [R]

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

'attachment', specifying a name parameter of foo-%41.html. (this test was added to observe the behavior of the (unspecified) treatment of "name" as synonym for "filename"; see Ned Freed's summary where this comes from in MIME messages)

Should be treated as extension parameter, therefore almost any behavior is acceptable.

Extracted raw data:

After post-processing the disposition name, parameter names, and parameter values:

attwithfilenamepctandiso [TEST] [R]

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

'attachment', specifying a filename parameter of ä-%41.html. (this test was added to observe the behavior when non-ASCII characters and percent-hexdig sequences are combined)

Extracted raw data:

After post-processing the disposition name, parameter names, and parameter values:

attwithfnrawpctenclong [TEST] [R]

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.

Extracted raw data:

After post-processing the disposition name, parameter names, and parameter values:

attwithasciifilenamews1 [TEST] [R]

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

Extracted raw data:

After post-processing the disposition name, parameter names, and parameter values:

attwith2filenames [TEST] [R]

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

'attachment', specifying two filename parameters. This is invalid syntax.

Extracted raw data:

Invalid syntax: parameter 'filename' appears multiple times.

attfnbrokentoken [TEST] [R]

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

                                             ^ (PARSE ERROR)

'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 RFC 2616 and RFC 6266, so UAs should ignore it.

attfnbrokentokeniso [TEST] [R]

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

                                              ^ (PARSE ERROR)

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

This is invalid, as the umlaut is not a valid token character, so UAs should ignore it.

attfnbrokentokenutf [TEST] [R]

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

                                              ^ (PARSE ERROR)

'attachment', specifying a filename of foo-ä.html (which happens to be foo-ä.html using UTF-8 encoding) but missing the quotes.

This is invalid, as the umlaut is not a valid token character, so UAs should ignore it.

attmissingdisposition [TEST] [R]

Content-Disposition: filename=foo.html

                             ^ (PARSE ERROR)

Disposition type missing, filename specified.

This is invalid, so UAs should ignore it.

attmissingdisposition2 [TEST] [R]

Content-Disposition: x=y; filename=foo.html

                      ^ (PARSE ERROR)

Disposition type missing, filename specified after extension parameter.

This is invalid, so UAs should ignore it.

attmissingdisposition3 [TEST] [R]

Content-Disposition: "foo; filename=bar;baz"; filename=qux

                     ^ (PARSE ERROR)

Disposition type missing, filename "qux". Can it be more broken? (Probably)

This is invalid, so UAs should ignore it.

attmissingdisposition4 [TEST] [R]

Content-Disposition: filename=foo.html, filename=bar.html

                             ^ (PARSE ERROR)

Disposition type missing, two filenames specified separated by a comma (this is syntactically equivalent to have two instances of the header with one filename parameter each).

This is invalid, so UAs should ignore it.

emptydisposition [TEST] [R]

Content-Disposition: ; filename=foo.html

                     ^ (PARSE ERROR)

Disposition type missing (but delimiter present), filename specified.

This is invalid, so UAs should ignore it.

doublecolon [TEST] [R]

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

                     ^ (PARSE ERROR)

Header field value starts with a colon.

This is invalid, so UAs should ignore it.

attandinline [TEST] [R]

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

                           ^ (PARSE ERROR)

Both disposition types specified.

This is invalid, so UAs should ignore it.

attandinline2 [TEST] [R]

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

                               ^ (PARSE ERROR)

Both disposition types specified.

This is invalid, so UAs should ignore it.

attbrokenquotedfn [TEST] [R]

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

                                                    ^ (PARSE ERROR)

'attachment', specifying a filename parameter that is broken (quoted-string followed by more characters). This is invalid syntax.

This is invalid, so UAs should ignore it.

attbrokenquotedfn2 [TEST] [R]

Content-Disposition: attachment; filename="bar

                               ^ (PARSE ERROR)

'attachment', specifying a filename parameter that is broken (missing ending double quote). This is invalid syntax.

This is invalid, so UAs should ignore it.

attbrokenquotedfn3 [TEST] [R]

Content-Disposition: attachment; filename=foo"bar;baz"qux

                                             ^ (PARSE ERROR)

'attachment', specifying a filename parameter that is broken (disallowed characters in token syntax). This is invalid syntax.

This is invalid, so UAs should ignore it.

attmultinstances [TEST] [R]

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

                                                  ^ (PARSE ERROR)

'attachment', two comma-separated instances of the header field. As Content-Disposition doesn't use a list-style syntax, this is invalid syntax and, according to RFC 2616, Section 4.2, roughly equivalent to having two separate header field instances.

This is invalid, so UAs should ignore it.

attmissingdelim [TEST] [R]

Content-Disposition: attachment; foo=foo filename=bar

                                         ^ (PARSE ERROR)

Uses two parameters, but the mandatory delimiter ";" is missing.

This is invalid, so UAs should ignore it.

attmissingdelim2 [TEST] [R]

Content-Disposition: attachment; filename=bar foo=foo 

                                              ^ (PARSE ERROR)

Uses two parameters, but the mandatory delimiter ";" is missing.

This is invalid, so UAs should ignore it.

attmissingdelim3 [TEST] [R]

Content-Disposition: attachment filename=bar

                                ^ (PARSE ERROR)

";" missing between disposition type and filename parameter.

This is invalid, so UAs should ignore it.

attreversed [TEST] [R]

Content-Disposition: filename=foo.html; attachment

                             ^ (PARSE ERROR)

filename parameter and disposition type reversed.

This is invalid, so UAs should ignore it.

attconfusedparam [TEST] [R]

Content-Disposition: attachment; xfilename=foo.html

'attachment', specifying an "xfilename" parameter.

Should be treated as unnamed attachment.

Extracted raw data:

attabspath [TEST] [R]

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

'attachment', specifying an absolute filename in the filesystem root.

Either ignore the filename altogether, or discard the path information.

Extracted raw data:

After post-processing the disposition name, parameter names, and parameter values:

attabspathwin [TEST] [R]

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

'attachment', specifying an absolute filename in the filesystem root.

Either ignore the filename altogether, or discard the path information.

Note that test results under Operating Systems other than Windows vary (see http://lists.w3.org/Archives/Public/ietf-http-wg/2011JanMar/0112.html); apparently some UAs consider the backslash a legitimate filename character.

Extracted raw data:

After post-processing the disposition name, parameter names, and parameter values:

attcdate [TEST] [R]

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.

Extracted raw data:

After post-processing the disposition name, parameter names, and parameter values:

attmdate [TEST] [R]

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.

Extracted raw data:

After post-processing the disposition name, parameter names, and parameter values:

dispext [TEST] [R]

Content-Disposition: foobar

'foobar' only

This should be equivalent to using "attachment".

Extracted raw data:

dispextbadfn [TEST] [R]

Content-Disposition: attachment; example="filename=example.txt"

'attachment', with no filename parameter

Extracted raw data:

After post-processing the disposition name, parameter names, and parameter values:

attwithisofn2231iso [TEST] [R]

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

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

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

Extracted raw data:

After decoding according to RFC 5987:

attwithfn2231utf8 [TEST] [R]

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

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

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

Extracted raw data:

After decoding according to RFC 5987:

attwithfn2231noc [TEST] [R]

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.

Extracted raw data:

Error: parseerror: ABNF does not match; unmatched sequence: ''foo-%c3%a4-%e2%82%ac.html

attwithfn2231utf8comp [TEST] [R]

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

Extracted raw data:

After decoding according to RFC 5987:

attwithfn2231utf8-bad [TEST] [R]

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.

Extracted raw data:

Error: illegal-octet: 130

attwithfn2231iso-bad [TEST] [R]

Content-Disposition: attachment; filename*=utf-8''foo-%E4.html

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

The octet %E4 does not represent a valid UTF-8 octet sequence, so the UA should really ignore the parameter.

Extracted raw data:

Error: illegal-octet: 228

attwithfn2231ws1 [TEST] [R]

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

                               ^ (PARSE ERROR)

'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] [R]

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

Extracted raw data:

After decoding according to RFC 5987:

attwithfn2231ws3 [TEST] [R]

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

Extracted raw data:

After decoding according to RFC 5987:

attwithfn2231quot [TEST] [R]

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.

Extracted raw data:

After post-processing the disposition name, parameter names, and parameter values:

Error: syntax: RFC 5987 only applies to "token" form.

attwithfn2231quot2 [TEST] [R]

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

'attachment', specifying a filename of foo bar.html, using "filename*", but missing character encoding and language (this replicates a bug in MS Exchange 2010, see Mozilla Bug 704989).

The parameter is invalid, thus should be ignored.

Extracted raw data:

After post-processing the disposition name, parameter names, and parameter values:

Error: syntax: RFC 5987 only applies to "token" form.

attwithfn2231singleqmissing [TEST] [R]

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

'attachment', specifying a filename of foo-ä.html, using RFC2231 encoded UTF-8, but a single quote is missing.

The parameter is invalid, thus should be ignored.

Extracted raw data:

Error: parseerror: ABNF does not match; unmatched sequence: UTF-8'foo-%c3%a4.html

attwithfn2231nbadpct1 [TEST] [R]

Content-Disposition: attachment; filename*=UTF-8''foo%

'attachment', specifying a filename of foo%, using RFC2231 encoded UTF-8, with a single "%" at the end.

The parameter is invalid, thus should be ignored.

Extracted raw data:

Error: parseerror: ABNF does not match; unmatched sequence: %

attwithfn2231nbadpct2 [TEST] [R]

Content-Disposition: attachment; filename*=UTF-8''f%oo.html

'attachment', specifying a filename of f%oo.html, using RFC2231 encoded UTF-8, with a "%" not starting a percent-escape.

The parameter is invalid, thus should be ignored.

Extracted raw data:

Error: parseerror: ABNF does not match; unmatched sequence: %oo.html

attwithfn2231dpct [TEST] [R]

Content-Disposition: attachment; filename*=UTF-8''A-%2541.html

'attachment', specifying a filename of A-%41.html, using RFC2231 encoded UTF-8.

Extracted raw data:

After decoding according to RFC 5987:

attwithfn2231abspathdisguised [TEST] [R]

Content-Disposition: attachment; filename*=UTF-8''%5cfoo.html

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

Extracted raw data:

After decoding according to RFC 5987:

attfncont [TEST] [R]

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

Extracted raw data:

After post-processing the disposition name, parameter names, and parameter values:

attfncontqs [TEST] [R]

Content-Disposition: attachment; filename*0="foo"; filename*1="\b\a\r.html"

'attachment', specifying a filename of foobar.html, using RFC2231-style parameter continuations, with the continuation using quoted-string syntax.

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

Extracted raw data:

After post-processing the disposition name, parameter names, and parameter values:

attfncontenc [TEST] [R]

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

Extracted raw data:

After post-processing the disposition name, parameter names, and parameter values:

attfncontlz [TEST] [R]

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

Extracted raw data:

After post-processing the disposition name, parameter names, and parameter values:

attfncontnc [TEST] [R]

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

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

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

Extracted raw data:

After post-processing the disposition name, parameter names, and parameter values:

attfnconts1 [TEST] [R]

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.

Extracted raw data:

After post-processing the disposition name, parameter names, and parameter values:

attfncontord [TEST] [R]

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

'attachment', specifying a filename of foobar

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

Extracted raw data:

After post-processing the disposition name, parameter names, and parameter values:

attfnboth [TEST] [R]

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 and Section 4.3 of RFC 6266 suggest that the RFC 2231/5987 encoded parameter ("filename*") should take precedence when understood.

Extracted raw data:

After post-processing the disposition name, parameter names, and parameter values:

After decoding according to RFC 5987:

attfnboth2 [TEST] [R]

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 and Section 4.3 of RFC 6266 suggest that the RFC 2231/5987 encoded parameter ("filename*") should take precedence when understood.

Extracted raw data:

After post-processing the disposition name, parameter names, and parameter values:

After decoding according to RFC 5987:

attfnboth3 [TEST] [R]

Content-Disposition: attachment; filename*0*=ISO-8859-15''euro-sign%3d%a4; filename*=ISO-8859-1''currency-sign%3d%a4

'attachment', specifying a filename of currency-sign=¤ in the simple RFC2231/5987 format, and euro-sign=€ in RFC2231-with-continuations format.

A UA that supports could pick either, or ignore both because of the ambiguity.

Extracted raw data:

After post-processing the disposition name, parameter names, and parameter values:

After decoding according to RFC 5987:

attnewandfn [TEST] [R]

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

'attachment', specifying a new parameter "foobar", plus a filename of foo.html in the traditional format.

"foobar" should be ignored, thus "foo.html" be used as filename (this tests whether the UA properly skips unknown parameters).

Extracted raw data:

After post-processing the disposition name, parameter names, and parameter values:

attrfc2047token [TEST] [R]

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

                               ^ (PARSE ERROR)

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

attrfc2047quoted [TEST] [R]

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

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

Extracted raw data:

After post-processing the disposition name, parameter names, and parameter values: