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

Please send feedback to julian.reschke@gmx.de.

Related Reading

How to send filenames in Content-Disposition

Historically, it was impossible to send filenames containing non-ASCII characters without doing browser sniffing, and varying the response based on the detected browser.

With the work leading to RFCs 5987 and 6266, and the subsequent improvements in IE and Chrome, and finally in Safari 6, the sitution has improved a lot.

In cases where it's acceptable to fall back to an ASCII filename in both Safari (versions prior to 6) and Internet Explorer (versions prior to IE9), the recommendation in Section D of RFC 6266 should be followed: all recent browsers except Safari will use the internationalized filename, other versions will fallback to the ASCII filename (this will be the case for Firefox 4 and older, Chrome 10 and older, and Internet Explorer 8 and older).

The IETF HTTPbis Working Group has a Wiki Page for collecting information about what producers do, please contribute!

Browsers Tested

Unless stated otherwise, all tests were executed with the latest release versions of Firefox, Google Chrome, Microsoft Internet Explorer (both 8 & 9 as IE9 is not available for XP), Safari, Konqueror (kde4win) and Opera on a machine running Windows 7. Test versions of Firefox are included because Content-Disposition header field related fixes are currently being worked on.

Known Buggy Senders

Unfortunately, there are web sites/services out there that produce broken header fields, which makes it non-trivial to change browsers to reject more broken header fields. In particular, for historical reasons, many sites still send different notations based on the User Agent they believe to see, causing them to appear to work for on User Agent, but not for the other.

The list below just mentions the top sites/services the author is aware of. If you can help to improve these, please do so.

Outlook Web App, the web mail front end for Exchange 2010, uses the "*" suffix indicating RFC2231/5987 encoding, but adds double quotes around the field value. This has been a known issue for Chrome since April 2011 (see Chrome Bug 41308), but was apparently fixed by Microsoft for Exchange 2010 SP1. Surprisingly, the same behavior was left in the code for Firefox, breaking Firefox 8 which attempted to become more strict (see Mozilla Bug 703015 and Microsoft Technet Thread).

Gmail encodes filenames using the encoding defined in RFC 2047, which does not apply to HTTP header field parameters, and is only "supported" by Firefox and Chrome. Instead, it should use the RFC 5987 encoding, which is supported all UAs that implement RFC 2047, plus some more. This issue has been known since December 2010 (see Mozilla Bug 601933), and it appears the Gmail team is now looking into this issue.

SMF, a forum software developed at Simple Machines, produces a broken header field when the UA is Firefox. This bug has been known since September 2011 and hasn't been fixed yet (see Issue 4825).

Test Result Summary

Colors -- Red: Failure, Green: Pass, Yellow: Warning, Grey: Not Supported

Score -- Passes: 2 points, Warning: 1 point, in percent of possible points (this should be updated to count optional features differently)

Test Case Firefox 22 Microsoft IE 8 Microsoft IE 9 Opera 12 Safari 6 (OSX) Konqueror 4.7.4 Google Chrome 25
Summary 64% passes, 6% failures, 28% warnings, 2% unsupported, 0% to-do
Score: 78
33% passes, 12% failures, 22% warnings, 33% unsupported, 0% to-do
Score: 44
52% passes, 11% failures, 25% warnings, 12% unsupported, 0% to-do
Score: 64
67% passes, 3% failures, 26% warnings, 3% unsupported, 0% to-do
Score: 80
66% passes, 3% failures, 18% warnings, 12% unsupported, 0% to-do
Score: 75
90% passes, 0% failures, 7% warnings, 3% unsupported, 0% to-do
Score: 93
62% passes, 8% failures, 19% warnings, 11% unsupported, 0% to-do
Score: 71
Content-Disposition: Disposition-Type Inline inlonly pass pass pass pass pass pass
inlonlyquoted warn (apparently parsed as unknown disposition type, thus defaulting to "attachment") pass pass pass pass pass
inlwithasciifilename pass (uses the filename in subsequent 'save' operation) unsupported (filename information not used) unsupported (filename information not used) unsupported (filename information not used) unsupported (filename information not used) unsupported (filename information not used (filename derived from title) (see Chrome Issue 257250))
inlwithfnattach pass fail (thinks this is an attachment) pass pass pass pass pass
inlwithasciifilenamepdf pass (filename information only used when save happens through UA menu, not PDF plugin (see Mozilla Bug 433613)) unsupported (filename information not used) pass (filename information only used when save happens through UA menu, not PDF plugin) pass (uses the filename in subsequent 'save' operation) unsupported (filename information not used) pass (uses the filename in subsequent 'save' operation)
Content-Disposition: Disposition-Type Attachment attonly pass pass pass pass pass pass
attonlyquoted warn (apparently parsed either as unknown disposition type, thus defaulting to "attachment", or mistaken for "attachment") warn (apparently parsed either as unknown disposition type, thus defaulting to "attachment", or mistaken for "attachment") pass pass pass pass
attonly403 pass (but displays a misleading error message (see Mozilla Bug 364354)) pass (but displays a misleading error message) pass (error is reported) fail (saves the content without warning) fail (saves the content without warning) warn (displays the content as if the header field wasn't present) pass (but displays a misleading error message)
attonlyucase pass pass pass pass pass pass
attwithasciifilename pass pass pass pass pass pass
attwithasciifilename25 pass pass pass pass pass pass
attwithasciifilename35 pass pass pass pass pass pass
attwithasciifnescapedchar pass fail (apparently does not treat the backslash as escape character, replaces it with '_') pass pass pass pass
attwithasciifnescapedquote warn (unquotes properly, but replaces the double quotes with "_") fail (apparently does not treat the backslash as escape character, replaces it with '_') warn (unquotes properly, but replaces the double quotes with "_") pass pass warn (unquotes properly, but replaces the double quotes with "-")
attwithquotedsemicolon pass fail (thinks the filename is terminated by the semicolon) pass pass pass pass
attwithfilenameandextparam pass pass pass pass pass pass
attwithfilenameandextparamescaped pass pass pass pass pass pass
attwithasciifilenameucase pass pass pass pass pass pass
attwithasciifilenamenq pass (accepts the unquoted value) pass (accepts the unquoted value) pass (accepts the unquoted value) pass (accepts the unquoted value) pass (accepts the unquoted value) pass (accepts the unquoted value)
attwithtokfncommanq warn (accepts the unquoted value) warn (accepts the unquoted value) warn (accepts the unquoted value) warn (treats the comma as delimiter and offers to download "foo.html") pass (ignores thes header field) pass (reports a network error ("Duplicate headers received from server"))
attwithasciifilenamenqs warn (accepts the unquoted value, treats semicolon as delimiter) warn (accepts the unquoted value, treats semicolon as delimiter) warn (accepts the unquoted value, treats semicolon as delimiter) warn (accepts the unquoted value, treats semicolon as delimiter) warn (accepts the unquoted value, treats semicolon as delimiter) warn (accepts the unquoted value, treats semicolon as delimiter)
attemptyparam warn (skips the missing parameter and sees 'foo') warn (skips the missing parameter and sees 'foo') warn (skips the missing parameter and sees 'foo') warn (skips the missing parameter and sees 'foo') pass (header field ignored) warn (skips the missing parameter and sees 'foo')
attwithasciifilenamenqws warn (ignores "bar") warn (apparently replaces whitespace by "_") warn (accepts the whitespace as part of the value) warn (accepts the whitespace as part of the value) warn (accepts the whitespace as part of the value) pass (ignores the parameter) warn (accepts the whitespace as part of the value)
attwithfntokensq pass pass pass (note that the second quote disappears as the extension gets rewritten) pass pass fail (removes the single quotes (see Chrome Issue 179825))
attwithisofnplain pass pass pass pass pass pass
attwithutf8fnplain fail (decodes as UTF-8 (see Mozilla Bug 588409)) pass pass fail (decodes as UTF-8) pass fail (decodes as UTF-8)
attwithfnrawpctenca pass fail (displays "foo-A.html") pass pass pass fail (displays "foo-A.html" (see Chrome Issue 118))
attwithfnusingpct pass pass pass pass pass pass
attwithfnrawpctencaq pass fail (apparently does not treat the backslash as escape character, replaces it with '_') pass pass pass fail (saves "foo-A.html" (apparently unescapes the "\" but then applies %-decoding))
attwithnamepct pass (parameter ignored) pass (parameter ignored) pass (parameter ignored) pass (parameter ignored) pass (parameter ignored) pass (displays "foo-A.html" (see Chrome Issue 162815))
attwithfilenamepctandiso pass fail (displays "-A.html") pass pass pass pass
attwithfnrawpctenclong pass fail (displays "foo--€.html") pass pass pass fail (displays "foo--€.html" (see Chrome Issue 118))
attwithasciifilenamews1 pass pass pass pass pass pass
attwith2filenames warn (Takes first parameter) warn (Takes first parameter) warn (Takes first parameter) warn (Takes first parameter) pass warn (Takes first parameter)
attfnbrokentoken warn (accepts the unquoted value) warn (accepts the unquoted value) warn (accepts the unquoted value) warn (accepts the unquoted value) pass warn (accepts the unquoted value)
attfnbrokentokeniso warn (accepts the umlaut) warn (accepts the umlaut) warn (accepts the umlaut) warn (accepts the umlaut) pass warn (accepts the umlaut)
attfnbrokentokenutf warn (accepts the umlaut, also sniffs as UTF-8) warn (accepts the umlaut) warn (accepts the umlaut) warn (accepts the umlaut, also sniffs as UTF-8) pass warn (accepts the umlaut, also sniffs as UTF-8)
attmissingdisposition warn (Treated as inline (and filename used in subsequent save operation)) pass (Header field ignored) pass (Header field ignored) pass (Header field ignored) pass (Header field ignored) pass (Header field ignored)
attmissingdisposition2 fail (Treated as named attachment (see Mozilla Bug 671204)) pass (Header field ignored) pass (Header field ignored) pass (Header field ignored) pass (Header field ignored) pass (Header field ignored)
attmissingdisposition3 fail (Sees "qux" (see Mozilla Bug 671204)) pass (Header field ignored) pass (Header field ignored) pass (Header field ignored) pass (Header field ignored) pass (Header field ignored)
attmissingdisposition4 pass (Header field ignored) pass (Header field ignored) pass (Header field ignored) pass (Header field ignored) pass (Header field ignored) pass (reports a network error ("Duplicate headers received from server"))
emptydisposition pass (Header field ignored) pass (Header field ignored) pass (Header field ignored) pass (Header field ignored) pass (Header field ignored) pass (Header field ignored)
doublecolon warn (surplus colon ignored (see Mozilla Bug 671204)) warn (surplus colon ignored) warn (surplus colon ignored) pass (header field ignored) pass (header field ignored) pass (header field ignored)
attandinline pass (Header field ignored) fail (Picks 'attachment') pass (Header field ignored) pass (Header field ignored) pass (Header field ignored) pass (Header field ignored)
attandinline2 warn (treats it as (named) attachment) warn (treats it as (named) attachment) warn (treats it as (named) attachment) warn (treats it as (named) attachment) pass warn (treats it as (unnamed) attachment)
attbrokenquotedfn warn (ignores the stuff after the second double quote) warn (treats the suffix as part of the filename) warn (ignores the stuff after the second double quote) warn (ignores the stuff after the second double quote) pass warn (replaces second double quote by "-")
attbrokenquotedfn2 warn (accepts the filename parameter as if complete (see Mozilla Bug 686198)) warn (accepts the filename parameter as if complete) pass pass pass warn (accepts the filename parameter as if complete)
attbrokenquotedfn3 warn (sees "foo_bar" (apparently substituting the double quote, and truncating at the semicolon)) warn (sees "foo_bar" (apparently substituting the double quote, and truncating at the semicolon)) warn (sees "foo"bar;baz"qux" (accepts all characters inside the token?)) pass pass warn (sees "foo-bar;baz"qux" (accepts all characters inside the token?))
attmultinstances warn (sees "bar.html" (picking the second value, see Mozilla Bug 480100)) warn (sees "foo[1].html, attachment") warn (sees "foo.htm") warn (sees "foo.html") warn (sees "bar.html") pass (reports a network error ("Duplicate headers received from server"))
attmissingdelim warn (sees unnamed attachment) warn (sees unnamed attachment) warn (sees unnamed attachment) warn (sees unnamed attachment) warn (sees unnamed attachment) warn (sees unnamed attachment)
attmissingdelim2 warn (sees "bar") warn (sees "bar_foo=foo") warn (sees "bar foo=foo") warn (sees "bar foo=foo") warn (sees "bar foo=foo") warn (sees unnamed attachment) warn (sees "bar foo=foo")
attmissingdelim3 warn (sees unnamed attachment) warn (sees unnamed attachment) warn (sees "bar") pass pass pass
attreversed pass ((but see Mozilla Bug 263933)) warn (treated as named attachment) pass pass pass pass pass
attconfusedparam pass pass pass pass pass pass
attabspath pass (Replaces the path separator with "_".) pass (Replaces the path separator with "_".) pass (Strips the path separator.) pass (Replaces the path separator with "-".) pass (Strips the path separator.) pass (Replaces the path separator with "_".)
attabspathwin pass (Replaces the path separator with "_".) pass (Replaces the path separator with "__"; apparently processing raw "\" characters instead of the unescaped quoted-string.) pass (Strips the path separator.) warn (On OSX: stores the leading "\") pass (Strips the platform-specific path separator.) pass (Replaces the path separator with "_".)
Content-Disposition: Additional Parameters attcdate unsupported (seems to ignore the parameter (see Mozilla Bug 531353)) unsupported (seems to ignore the parameter) unsupported (seems to ignore the parameter) unsupported (seems to ignore the parameter) unsupported (seems to ignore the parameter) unsupported (seems to ignore the parameter)
attmdate unsupported (seems to ignore the parameter (see Mozilla Bug 531353)) unsupported (seems to ignore the parameter) unsupported (seems to ignore the parameter) unsupported (seems to ignore the parameter) pass unsupported (seems to ignore the parameter)
Content-Disposition: Disposition-Type Extension dispext pass fail (does not treat it as 'attachment') pass fail (does not treat it as 'attachment') pass pass
dispextbadfn pass pass pass pass pass pass
RFC 2231/5987 Encoding: Character Sets attwithisofn2231iso pass unsupported fail (does not accept ISO-8859-1) pass pass pass pass
attwithfn2231utf8 pass unsupported pass pass pass pass pass
attwithfn2231noc warn (decodes as UTF-8 (see Mozilla Bug 685192)) unsupported pass warn (decodes as 8bit encoding (ISO-8859-1?)) pass (ignores the parameter) pass (ignores the parameter) pass (ignores the parameter)
attwithfn2231utf8comp pass unsupported pass pass pass pass pass
attwithfn2231utf8-bad pass unsupported pass warn (displays the raw octet sequence as if it was ISO-8859-1 (which is internally treated as windows-1252, which does allow %82)) warn (displays the raw octet sequence as if it was ISO-8859-1) pass warn (displays the raw octet sequence as if it was ISO-8859-1)
attwithfn2231iso-bad pass unsupported warn (detects "foo-%E4.html") warn (apparently falls back to ISO-8859-1) pass pass (seems to insert a replacement character) pass
attwithfn2231ws1 pass unsupported pass pass pass pass pass
attwithfn2231ws2 pass unsupported pass pass pass pass pass
attwithfn2231ws3 pass unsupported pass pass pass pass pass
attwithfn2231quot warn (accepts the encoding despite double quotes not being allowed here (see Mozilla Bug 651185)) unsupported pass pass pass pass pass
attwithfn2231quot2 warn (processes the parameter despite broken quotes and missing delimiters (see Mozilla Bug 651185, Mozilla Bug 685192, and Mozilla Bug 692574)) unsupported pass pass pass pass pass
attwithfn2231singleqmissing warn (tolerates the missing single quote (see Mozilla Bug 692574)) unsupported pass pass pass pass pass
attwithfn2231nbadpct1 pass unsupported warn (displays "foo%") warn (displays "foo%") pass pass warn (displays "foo%")
attwithfn2231nbadpct2 pass unsupported warn (displays "f%oo.html") warn (displays "f%oo.html") pass pass (ignores the filename parameter) warn (displays "f%oo.html")
attwithfn2231dpct pass unsupported pass pass pass pass pass
attwithfn2231abspathdisguised pass (substitutes "\" by "_") unsupported pass (substitutes "\" by "_") pass (strips the "\") unsupported warn (On OSX: stores the leading "\") pass (substitutes "\" by "_")
RFC2231 Encoding: Continuations attfncont pass (but see (Mozilla Bug 776324)) unsupported pass unsupported pass unsupported
attfncontqs pass (but see (Mozilla Bug 776324)) unsupported pass unsupported pass unsupported
attfncontenc pass (but see (Mozilla Bug 776324)) unsupported pass unsupported pass unsupported
attfncontlz pass (but see (Mozilla Bug 776324)) unsupported warn (accepts leading zeros) unsupported pass unsupported
attfncontnc pass (but see (Mozilla Bug 776324)) unsupported pass unsupported pass unsupported
attfnconts1 pass (but see (Mozilla Bug 776324)) unsupported pass unsupported pass unsupported
attfncontord pass (but see (Mozilla Bug 776324)) unsupported pass unsupported pass unsupported
RFC2231 Encoding: Fallback Behaviour attfnboth pass (picks the RFC 2231 encoded value) unsupported (picks the traditionally encoded value -- the first of both) pass (picks the RFC 2231 encoded value) pass (picks the RFC 2231 encoded value) pass (picks the RFC 2231 encoded value) pass (picks the RFC 2231 encoded value) pass (picks the RFC 2231 encoded value)
attfnboth2 pass (picks the RFC 2231 encoded value) fail (ignores the parameter (this indicates a parsing bug)) pass (picks the RFC 2231 encoded value) pass (picks the RFC 2231 encoded value) pass (picks the RFC 2231 encoded value) pass (picks the RFC 2231 encoded value) pass (picks the RFC 2231 encoded value)
attfnboth3 pass (uses RFC5987 simple format) unsupported pass (ignores both) pass (uses RFC2231/cont format (the first one)) pass (uses RFC5987 simple format) pass (uses RFC2231/cont format (the first one)) pass (uses RFC5987 simple format)
attnewandfn pass pass pass pass pass pass
RFC2047 Encoding attrfc2047token fail (decodes it anyway to "foo-.html" (see Mozilla Bug 601933)) warn (takes the whole value as filename, but does not decode it (replacing question marks by underscores)) fail (displays garbage ("=.htm")) warn (takes the whole value as filename, but does not decode it (replacing question marks by underscores)) pass (ignores the parameter) fail (decodes it anyway to "foo-.html" (see Chrome Issue 66694))
attrfc2047quoted fail (decodes it anyway to "foo-.html" (see Mozilla Bug 601933)) pass (takes the whole value as filename, but does not decode it) fail (displays garbage ("=.htm")) pass (takes the whole value as filename, but does not decode it) pass (takes the whole value as filename, but does not decode it) fail (decodes it anyway to "foo-.html" (see Chrome Issue 66694))

Test Cases

Content-Disposition: Disposition-Type Inline

Various tests relating to the "inline" disposition type, see Section 4.2 of RFC 6266.

inlonly [TEST] [R]

Content-Disposition: inline
Test Results
FF22 pass
MSIE8 pass
MSIE9 pass
Opera pass
Saf6 pass
Konq pass
Chr25 pass

'inline' only

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

Extracted raw data:

disposition type    parameter name    parameter value   
inline

inlonlyquoted [TEST] [R]

Content-Disposition: "inline"
                     ^ (PARSE ERROR)
Test Results
FF22 warn (apparently parsed as unknown disposition type, thus defaulting to "attachment")
MSIE8 pass
MSIE9 pass
Opera pass
Saf6 pass
Konq pass
Chr25 pass

'inline' only, using double quotes

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

inlwithasciifilename [TEST] [R]

Content-Disposition: inline; filename="foo.html"
Test Results
FF22 pass (uses the filename in subsequent 'save' operation)
MSIE8 unsupported (filename information not used)
MSIE9 unsupported (filename information not used)
Opera unsupported (filename information not used)
Saf6 unsupported (filename information not used)
Konq unsupported (filename information not used)
Chr25 unsupported (filename information not used (filename derived from title) (see Chrome Issue 257250))

'inline', specifying a filename of foo.html

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

Extracted raw data:

disposition type    parameter name    parameter value   
inline filename "foo.html"

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

disposition type    parameter name    parameter value   
inline filename foo.html

inlwithfnattach [TEST] [R]

Content-Disposition: inline; filename="Not an attachment!"
Test Results
FF22 pass
MSIE8 fail (thinks this is an attachment)
MSIE9 pass
Opera pass
Saf6 pass
Konq pass
Chr25 pass

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

Extracted raw data:

disposition type    parameter name    parameter value   
inline filename "Not an attachment!"

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

disposition type    parameter name    parameter value   
inline filename Not an attachment!

inlwithasciifilenamepdf [TEST] [R]

Content-Disposition: inline; filename="foo.pdf"
Test Results
FF22 pass (filename information only used when save happens through UA menu, not PDF plugin (see Mozilla Bug 433613))
MSIE8 unsupported (filename information not used)
MSIE9 unsupported (filename information not used)
Opera pass (filename information only used when save happens through UA menu, not PDF plugin)
Saf6 pass (uses the filename in subsequent 'save' operation)
Konq unsupported (filename information not used)
Chr25 pass (uses the filename in subsequent 'save' operation)

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

disposition type    parameter name    parameter value   
inline filename "foo.pdf"

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

disposition type    parameter name    parameter value   
inline filename foo.pdf

Content-Disposition: Disposition-Type Attachment

Various tests relating to the "attachment" disposition type, see Section 4.2 of RFC 6266.

attonly [TEST] [R]

Content-Disposition: attachment
Test Results
FF22 pass
MSIE8 pass
MSIE9 pass
Opera pass
Saf6 pass
Konq pass
Chr25 pass

'attachment' only

UA should offer to download the resource.

Extracted raw data:

disposition type    parameter name    parameter value   
attachment

attonlyquoted [TEST] [R]

Content-Disposition: "attachment"
                     ^ (PARSE ERROR)
Test Results
FF22 warn (apparently parsed either as unknown disposition type, thus defaulting to "attachment", or mistaken for "attachment")
MSIE8 warn (apparently parsed either as unknown disposition type, thus defaulting to "attachment", or mistaken for "attachment")
MSIE9 warn (apparently parsed either as unknown disposition type, thus defaulting to "attachment", or mistaken for "attachment")
Opera pass
Saf6 pass
Konq pass
Chr25 pass

'attachment' only, using double quotes

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

attonly403 [TEST] [R]

Content-Disposition: attachment
Test Results
FF22 pass (but displays a misleading error message (see Mozilla Bug 364354))
MSIE8 pass (but displays a misleading error message)
MSIE9 pass (error is reported)
Opera fail (saves the content without warning)
Saf6 fail (saves the content without warning)
Konq warn (displays the content as if the header field wasn't present)
Chr25 pass (but displays a misleading error message)

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

UA should report the server status.

Extracted raw data:

disposition type    parameter name    parameter value   
attachment

attonlyucase [TEST] [R]

Content-Disposition: ATTACHMENT
Test Results
FF22 pass
MSIE8 pass
MSIE9 pass
Opera pass
Saf6 pass
Konq pass
Chr25 pass

'ATTACHMENT' only

UA should offer to download the resource.

Extracted raw data:

disposition type    parameter name    parameter value   
ATTACHMENT

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

disposition type    parameter name    parameter value   
attachment

attwithasciifilename [TEST] [R]

Content-Disposition: attachment; filename="foo.html"
Test Results
FF22 pass
MSIE8 pass
MSIE9 pass
Opera pass
Saf6 pass
Konq pass
Chr25 pass

'attachment', specifying a filename of foo.html

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

Extracted raw data:

disposition type    parameter name    parameter value   
attachment filename "foo.html"

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

disposition type    parameter name    parameter value   
attachment filename foo.html

attwithasciifilename25 [TEST] [R]

Content-Disposition: attachment; filename="0000000000111111111122222"
Test Results
FF22 pass
MSIE8 pass
MSIE9 pass
Opera pass
Saf6 pass
Konq pass
Chr25 pass

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

Extracted raw data:

disposition type    parameter name    parameter value   
attachment filename "0000000000111111111122222"

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

disposition type    parameter name    parameter value   
attachment filename 0000000000111111111122222

attwithasciifilename35 [TEST] [R]

Content-Disposition: attachment; filename="00000000001111111111222222222233333"
Test Results
FF22 pass
MSIE8 pass
MSIE9 pass
Opera pass
Saf6 pass
Konq pass
Chr25 pass

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

Extracted raw data:

disposition type    parameter name    parameter value   
attachment filename "00000000001111111111222222222233333"

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

disposition type    parameter name    parameter value   
attachment filename 00000000001111111111222222222233333

attwithasciifnescapedchar [TEST] [R]

Content-Disposition: attachment; filename="f\oo.html"
Test Results
FF22 pass
MSIE8 fail (apparently does not treat the backslash as escape character, replaces it with '_')
MSIE9 fail (apparently does not treat the backslash as escape character, replaces it with '_')
Opera pass
Saf6 pass
Konq pass
Chr25 pass

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

disposition type    parameter name    parameter value   
attachment filename "f\oo.html"

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

disposition type    parameter name    parameter value   
attachment filename foo.html

attwithasciifnescapedquote [TEST] [R]

Content-Disposition: attachment; filename="\"quoting\" tested.html"
Test Results
FF22 warn (unquotes properly, but replaces the double quotes with "_")
MSIE8 fail (apparently does not treat the backslash as escape character, replaces it with '_')
MSIE9 fail (apparently does not treat the backslash as escape character, replaces it with '_')
Opera warn (unquotes properly, but replaces the double quotes with "_")
Saf6 pass
Konq pass
Chr25 warn (unquotes properly, but replaces the double quotes with "-")

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

disposition type    parameter name    parameter value   
attachment filename "\"quoting\" tested.html"

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

disposition type    parameter name    parameter value   
attachment filename "quoting" tested.html

attwithquotedsemicolon [TEST] [R]

Content-Disposition: attachment; filename="Here's a semicolon;.html"
Test Results
FF22 pass
MSIE8 fail (thinks the filename is terminated by the semicolon)
MSIE9 fail (thinks the filename is terminated by the semicolon)
Opera pass
Saf6 pass
Konq pass
Chr25 pass

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

Extracted raw data:

disposition type    parameter name    parameter value   
attachment filename "Here's a semicolon;.html"

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

disposition type    parameter name    parameter value   
attachment filename Here's a semicolon;.html

attwithfilenameandextparam [TEST] [R]

Content-Disposition: attachment; foo="bar"; filename="foo.html"
Test Results
FF22 pass
MSIE8 pass
MSIE9 pass
Opera pass
Saf6 pass
Konq pass
Chr25 pass

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

disposition type    parameter name    parameter value   
attachment foo "bar"
filename "foo.html"

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

disposition type    parameter name    parameter value   
attachment foo bar
filename foo.html

attwithfilenameandextparamescaped [TEST] [R]

Content-Disposition: attachment; foo="\"\\";filename="foo.html"
Test Results
FF22 pass
MSIE8 pass
MSIE9 pass
Opera pass
Saf6 pass
Konq pass
Chr25 pass

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

disposition type    parameter name    parameter value   
attachment foo "\"\\"
filename "foo.html"

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

disposition type    parameter name    parameter value   
attachment foo "\
filename foo.html

attwithasciifilenameucase [TEST] [R]

Content-Disposition: attachment; FILENAME="foo.html"
Test Results
FF22 pass
MSIE8 pass
MSIE9 pass
Opera pass
Saf6 pass
Konq pass
Chr25 pass

'attachment', specifying a filename of foo.html

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

Extracted raw data:

disposition type    parameter name    parameter value   
attachment FILENAME "foo.html"

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

disposition type    parameter name    parameter value   
attachment filename foo.html

attwithasciifilenamenq [TEST] [R]

Content-Disposition: attachment; filename=foo.html
Test Results
FF22 pass (accepts the unquoted value)
MSIE8 pass (accepts the unquoted value)
MSIE9 pass (accepts the unquoted value)
Opera pass (accepts the unquoted value)
Saf6 pass (accepts the unquoted value)
Konq pass (accepts the unquoted value)
Chr25 pass (accepts the unquoted value)

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

disposition type    parameter name    parameter value   
attachment filename foo.html

attwithtokfncommanq [TEST] [R]

Content-Disposition: attachment; filename=foo,bar.html
                                             ^ (PARSE ERROR)
Test Results
FF22 warn (accepts the unquoted value)
MSIE8 warn (accepts the unquoted value)
MSIE9 warn (accepts the unquoted value)
Opera warn (accepts the unquoted value)
Saf6 warn (treats the comma as delimiter and offers to download "foo.html")
Konq pass (ignores thes header field)
Chr25 pass (reports a network error ("Duplicate headers received from server"))

'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)
Test Results
FF22 warn (accepts the unquoted value, treats semicolon as delimiter)
MSIE8 warn (accepts the unquoted value, treats semicolon as delimiter)
MSIE9 warn (accepts the unquoted value, treats semicolon as delimiter)
Opera warn (accepts the unquoted value, treats semicolon as delimiter)
Saf6 warn (accepts the unquoted value, treats semicolon as delimiter)
Konq warn (accepts the unquoted value, treats semicolon as delimiter)
Chr25 warn (accepts the unquoted value, treats semicolon as delimiter)

'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)
Test Results
FF22 warn (skips the missing parameter and sees 'foo')
MSIE8 warn (skips the missing parameter and sees 'foo')
MSIE9 warn (skips the missing parameter and sees 'foo')
Opera warn (skips the missing parameter and sees 'foo')
Saf6 warn (skips the missing parameter and sees 'foo')
Konq pass (header field ignored)
Chr25 warn (skips the missing parameter and sees 'foo')

'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)
Test Results
FF22 warn (ignores "bar")
MSIE8 warn (apparently replaces whitespace by "_")
MSIE9 warn (accepts the whitespace as part of the value)
Opera warn (accepts the whitespace as part of the value)
Saf6 warn (accepts the whitespace as part of the value)
Konq pass (ignores the parameter)
Chr25 warn (accepts the whitespace as part of the value)

'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'
Test Results
FF22 pass
MSIE8 pass
MSIE9 pass
Opera pass (note that the second quote disappears as the extension gets rewritten)
Saf6 pass
Konq pass
Chr25 fail (removes the single quotes (see Chrome Issue 179825))

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

Extracted raw data:

disposition type    parameter name    parameter value   
attachment filename 'foo.bar'

attwithisofnplain [TEST] [R]

Content-Disposition: attachment; filename="foo-.html"
Test Results
FF22 pass
MSIE8 pass
MSIE9 pass
Opera pass
Saf6 pass
Konq pass
Chr25 pass

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

disposition type    parameter name    parameter value   
attachment filename "foo-.html"

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

disposition type    parameter name    parameter value   
attachment filename foo-.html

attwithutf8fnplain [TEST] [R]

Content-Disposition: attachment; filename="foo-ä.html"
Test Results
FF22 fail (decodes as UTF-8 (see Mozilla Bug 588409))
MSIE8 pass
MSIE9 pass
Opera pass
Saf6 fail (decodes as UTF-8)
Konq pass
Chr25 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.

Extracted raw data:

disposition type    parameter name    parameter value   
attachment filename "foo-ä.html"

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

disposition type    parameter name    parameter value   
attachment filename foo-ä.html

attwithfnrawpctenca [TEST] [R]

Content-Disposition: attachment; filename="foo-%41.html"
Test Results
FF22 pass
MSIE8 fail (displays "foo-A.html")
MSIE9 fail (displays "foo-A.html")
Opera pass
Saf6 pass
Konq pass
Chr25 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.

Extracted raw data:

disposition type    parameter name    parameter value   
attachment filename "foo-%41.html"

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

disposition type    parameter name    parameter value   
attachment filename foo-%41.html

attwithfnusingpct [TEST] [R]

Content-Disposition: attachment; filename="50%.html"
Test Results
FF22 pass
MSIE8 pass
MSIE9 pass
Opera pass
Saf6 pass
Konq pass
Chr25 pass

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

disposition type    parameter name    parameter value   
attachment filename "50%.html"

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

disposition type    parameter name    parameter value   
attachment filename 50%.html

attwithfnrawpctencaq [TEST] [R]

Content-Disposition: attachment; filename="foo-%\41.html"
Test Results
FF22 pass
MSIE8 fail (apparently does not treat the backslash as escape character, replaces it with '_')
MSIE9 fail (apparently does not treat the backslash as escape character, replaces it with '_')
Opera pass
Saf6 pass
Konq pass
Chr25 fail (saves "foo-A.html" (apparently unescapes the "\" but then applies %-decoding))

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

disposition type    parameter name    parameter value   
attachment filename "foo-%\41.html"

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

disposition type    parameter name    parameter value   
attachment filename foo-%41.html

attwithnamepct [TEST] [R]

Content-Disposition: attachment; name="foo-%41.html"
Test Results
FF22 pass (parameter ignored)
MSIE8 pass (parameter ignored)
MSIE9 pass (parameter ignored)
Opera pass (parameter ignored)
Saf6 pass (parameter ignored)
Konq pass (parameter ignored)
Chr25 pass (displays "foo-A.html" (see Chrome Issue 162815))

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

disposition type    parameter name    parameter value   
attachment name "foo-%41.html"

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

disposition type    parameter name    parameter value   
attachment name foo-%41.html

attwithfilenamepctandiso [TEST] [R]

Content-Disposition: attachment; filename="-%41.html"
Test Results
FF22 pass
MSIE8 fail (displays "-A.html")
MSIE9 fail (displays "-A.html")
Opera pass
Saf6 pass
Konq pass
Chr25 pass

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

disposition type    parameter name    parameter value   
attachment filename "-%41.html"

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

disposition type    parameter name    parameter value   
attachment filename -%41.html

attwithfnrawpctenclong [TEST] [R]

Content-Disposition: attachment; filename="foo-%c3%a4-%e2%82%ac.html"
Test Results
FF22 pass
MSIE8 fail (displays "foo--€.html")
MSIE9 fail (displays "foo--€.html")
Opera pass
Saf6 pass
Konq pass
Chr25 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.

Extracted raw data:

disposition type    parameter name    parameter value   
attachment filename "foo-%c3%a4-%e2%82%ac.html"

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

disposition type    parameter name    parameter value   
attachment filename foo-%c3%a4-%e2%82%ac.html

attwithasciifilenamews1 [TEST] [R]

Content-Disposition: attachment; filename ="foo.html"
Test Results
FF22 pass
MSIE8 pass
MSIE9 pass
Opera pass
Saf6 pass
Konq pass
Chr25 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".

Extracted raw data:

disposition type    parameter name    parameter value   
attachment filename "foo.html"

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

disposition type    parameter name    parameter value   
attachment filename foo.html

attwith2filenames [TEST] [R]

Content-Disposition: attachment; filename="foo.html"; filename="bar.html"
Test Results
FF22 warn (Takes first parameter)
MSIE8 warn (Takes first parameter)
MSIE9 warn (Takes first parameter)
Opera warn (Takes first parameter)
Saf6 warn (Takes first parameter)
Konq pass
Chr25 warn (Takes first parameter)

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

Extracted raw data:

disposition type    parameter name    parameter value   
attachment filename "foo.html"
filename "bar.html"

Invalid syntax: parameter 'filename' appears multiple times.

attfnbrokentoken [TEST] [R]

Content-Disposition: attachment; filename=foo[1](2).html
                                             ^ (PARSE ERROR)
Test Results
FF22 warn (accepts the unquoted value)
MSIE8 warn (accepts the unquoted value)
MSIE9 warn (accepts the unquoted value)
Opera warn (accepts the unquoted value)
Saf6 warn (accepts the unquoted value)
Konq pass
Chr25 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 RFC 2616 and RFC 6266, so UAs should ignore it.

attfnbrokentokeniso [TEST] [R]

Content-Disposition: attachment; filename=foo-.html
                                              ^ (PARSE ERROR)
Test Results
FF22 warn (accepts the umlaut)
MSIE8 warn (accepts the umlaut)
MSIE9 warn (accepts the umlaut)
Opera warn (accepts the umlaut)
Saf6 warn (accepts the umlaut)
Konq pass
Chr25 warn (accepts the umlaut)

'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)
Test Results
FF22 warn (accepts the umlaut, also sniffs as UTF-8)
MSIE8 warn (accepts the umlaut)
MSIE9 warn (accepts the umlaut)
Opera warn (accepts the umlaut)
Saf6 warn (accepts the umlaut, also sniffs as UTF-8)
Konq pass
Chr25 warn (accepts the umlaut, also sniffs as UTF-8)

'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)
Test Results
FF22 warn (Treated as inline (and filename used in subsequent save operation))
MSIE8 pass (Header field ignored)
MSIE9 pass (Header field ignored)
Opera pass (Header field ignored)
Saf6 pass (Header field ignored)
Konq pass (Header field ignored)
Chr25 pass (Header field ignored)

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)
Test Results
FF22 fail (Treated as named attachment (see Mozilla Bug 671204))
MSIE8 pass (Header field ignored)
MSIE9 pass (Header field ignored)
Opera pass (Header field ignored)
Saf6 pass (Header field ignored)
Konq pass (Header field ignored)
Chr25 pass (Header field ignored)

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)
Test Results
FF22 fail (Sees "qux" (see Mozilla Bug 671204))
MSIE8 pass (Header field ignored)
MSIE9 pass (Header field ignored)
Opera pass (Header field ignored)
Saf6 pass (Header field ignored)
Konq pass (Header field ignored)
Chr25 pass (Header field ignored)

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)
Test Results
FF22 pass (Header field ignored)
MSIE8 pass (Header field ignored)
MSIE9 pass (Header field ignored)
Opera pass (Header field ignored)
Saf6 pass (Header field ignored)
Konq pass (Header field ignored)
Chr25 pass (reports a network error ("Duplicate headers received from server"))

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)
Test Results
FF22 pass (Header field ignored)
MSIE8 pass (Header field ignored)
MSIE9 pass (Header field ignored)
Opera pass (Header field ignored)
Saf6 pass (Header field ignored)
Konq pass (Header field ignored)
Chr25 pass (Header field ignored)

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)
Test Results
FF22 warn (surplus colon ignored (see Mozilla Bug 671204))
MSIE8 warn (surplus colon ignored)
MSIE9 warn (surplus colon ignored)
Opera warn (surplus colon ignored)
Saf6 pass (header field ignored)
Konq pass (header field ignored)
Chr25 pass (header field ignored)

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)
Test Results
FF22 pass (Header field ignored)
MSIE8 fail (Picks 'attachment')
MSIE9 fail (Picks 'attachment')
Opera pass (Header field ignored)
Saf6 pass (Header field ignored)
Konq pass (Header field ignored)
Chr25 pass (Header field ignored)

Both disposition types specified.

This is invalid, so UAs should ignore it.

attandinline2 [TEST] [R]

Content-Disposition: attachment; inline; filename=foo.html
                               ^ (PARSE ERROR)
Test Results
FF22 warn (treats it as (named) attachment)
MSIE8 warn (treats it as (named) attachment)
MSIE9 warn (treats it as (named) attachment)
Opera warn (treats it as (named) attachment)
Saf6 warn (treats it as (named) attachment)
Konq pass
Chr25 warn (treats it as (unnamed) attachment)

Both disposition types specified.

This is invalid, so UAs should ignore it.

attbrokenquotedfn [TEST] [R]

Content-Disposition: attachment; filename="foo.html".txt
                                                    ^ (PARSE ERROR)
Test Results
FF22 warn (ignores the stuff after the second double quote)
MSIE8 warn (treats the suffix as part of the filename)
MSIE9 warn (treats the suffix as part of the filename)
Opera warn (ignores the stuff after the second double quote)
Saf6 warn (ignores the stuff after the second double quote)
Konq pass
Chr25 warn (replaces second double quote by "-")

'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)
Test Results
FF22 warn (accepts the filename parameter as if complete (see Mozilla Bug 686198))
MSIE8 warn (accepts the filename parameter as if complete)
MSIE9 warn (accepts the filename parameter as if complete)
Opera pass
Saf6 pass
Konq pass
Chr25 warn (accepts the filename parameter as if complete)

'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)
Test Results
FF22 warn (sees "foo_bar" (apparently substituting the double quote, and truncating at the semicolon))
MSIE8 warn (sees "foo_bar" (apparently substituting the double quote, and truncating at the semicolon))
MSIE9 warn (sees "foo_bar" (apparently substituting the double quote, and truncating at the semicolon))
Opera warn (sees "foo"bar;baz"qux" (accepts all characters inside the token?))
Saf6 pass
Konq pass
Chr25 warn (sees "foo-bar;baz"qux" (accepts all characters inside the token?))

'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)
Test Results
FF22 warn (sees "bar.html" (picking the second value, see Mozilla Bug 480100))
MSIE8 warn (sees "foo[1].html, attachment")
MSIE9 warn (sees "foo[1].html, attachment")
Opera warn (sees "foo.htm")
Saf6 warn (sees "foo.html")
Konq warn (sees "bar.html")
Chr25 pass (reports a network error ("Duplicate headers received from server"))

'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)
Test Results
FF22 warn (sees unnamed attachment)
MSIE8 warn (sees unnamed attachment)
MSIE9 warn (sees unnamed attachment)
Opera warn (sees unnamed attachment)
Saf6 warn (sees unnamed attachment)
Konq warn (sees unnamed attachment)
Chr25 warn (sees unnamed attachment)

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)
Test Results
FF22 warn (sees "bar")
MSIE8 warn (sees "bar_foo=foo")
MSIE9 warn (sees "bar foo=foo")
Opera warn (sees "bar foo=foo")
Saf6 warn (sees "bar foo=foo")
Konq warn (sees unnamed attachment)
Chr25 warn (sees "bar foo=foo")

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)
Test Results
FF22 warn (sees unnamed attachment)
MSIE8 warn (sees unnamed attachment)
MSIE9 warn (sees unnamed attachment)
Opera warn (sees "bar")
Saf6 pass
Konq pass
Chr25 pass

";" 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)
Test Results
FF22 pass ((but see Mozilla Bug 263933))
MSIE8 warn (treated as named attachment)
MSIE9 pass
Opera pass
Saf6 pass
Konq pass
Chr25 pass

filename parameter and disposition type reversed.

This is invalid, so UAs should ignore it.

attconfusedparam [TEST] [R]

Content-Disposition: attachment; xfilename=foo.html
Test Results
FF22 pass
MSIE8 pass
MSIE9 pass
Opera pass
Saf6 pass
Konq pass
Chr25 pass

'attachment', specifying an "xfilename" parameter.

Should be treated as unnamed attachment.

Extracted raw data:

disposition type    parameter name    parameter value   
attachment xfilename foo.html

attabspath [TEST] [R]

Content-Disposition: attachment; filename="/foo.html"
Test Results
FF22 pass (Replaces the path separator with "_".)
MSIE8 pass (Replaces the path separator with "_".)
MSIE9 pass (Replaces the path separator with "_".)
Opera pass (Strips the path separator.)
Saf6 pass (Replaces the path separator with "-".)
Konq pass (Strips the path separator.)
Chr25 pass (Replaces the path separator with "_".)

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

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

Extracted raw data:

disposition type    parameter name    parameter value   
attachment filename "/foo.html"

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

disposition type    parameter name    parameter value   
attachment filename /foo.html

attabspathwin [TEST] [R]

Content-Disposition: attachment; filename="\\foo.html"
Test Results
FF22 pass (Replaces the path separator with "_".)
MSIE8 pass (Replaces the path separator with "__"; apparently processing raw "\" characters instead of the unescaped quoted-string.)
MSIE9 pass (Replaces the path separator with "__"; apparently processing raw "\" characters instead of the unescaped quoted-string.)
Opera pass (Strips the path separator.)
Saf6 warn (On OSX: stores the leading "\")
Konq pass (Strips the platform-specific path separator.)
Chr25 pass (Replaces the path separator with "_".)

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

disposition type    parameter name    parameter value   
attachment filename "\\foo.html"

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

disposition type    parameter name    parameter value   
attachment filename \foo.html

Content-Disposition: Additional Parameters (optional)

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

attcdate [TEST] [R]

Content-Disposition: attachment; creation-date="Wed, 12 Feb 1997 16:29:51 -0500"
Test Results
FF22 unsupported (seems to ignore the parameter (see Mozilla Bug 531353))
MSIE8 unsupported (seems to ignore the parameter)
MSIE9 unsupported (seems to ignore the parameter)
Opera unsupported (seems to ignore the parameter)
Saf6 unsupported (seems to ignore the parameter)
Konq unsupported (seems to ignore the parameter)
Chr25 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.

Extracted raw data:

disposition type    parameter name    parameter value   
attachment creation-date "Wed, 12 Feb 1997 16:29:51 -0500"

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

disposition type    parameter name    parameter value   
attachment creation-date Wed, 12 Feb 1997 16:29:51 -0500

attmdate [TEST] [R]

Content-Disposition: attachment; modification-date="Wed, 12 Feb 1997 16:29:51 -0500"
Test Results
FF22 unsupported (seems to ignore the parameter (see Mozilla Bug 531353))
MSIE8 unsupported (seems to ignore the parameter)
MSIE9 unsupported (seems to ignore the parameter)
Opera unsupported (seems to ignore the parameter)
Saf6 unsupported (seems to ignore the parameter)
Konq pass
Chr25 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.

Extracted raw data:

disposition type    parameter name    parameter value   
attachment modification-date "Wed, 12 Feb 1997 16:29:51 -0500"

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

disposition type    parameter name    parameter value   
attachment modification-date Wed, 12 Feb 1997 16:29:51 -0500

Content-Disposition: Disposition-Type Extension

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

dispext [TEST] [R]

Content-Disposition: foobar
Test Results
FF22 pass
MSIE8 fail (does not treat it as 'attachment')
MSIE9 fail (does not treat it as 'attachment')
Opera pass
Saf6 fail (does not treat it as 'attachment')
Konq pass
Chr25 pass

'foobar' only

This should be equivalent to using "attachment".

Extracted raw data:

disposition type    parameter name    parameter value   
foobar

dispextbadfn [TEST] [R]

Content-Disposition: attachment; example="filename=example.txt"
Test Results
FF22 pass
MSIE8 pass
MSIE9 pass
Opera pass
Saf6 pass
Konq pass
Chr25 pass

'attachment', with no filename parameter

Extracted raw data:

disposition type    parameter name    parameter value   
attachment example "filename=example.txt"

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

disposition type    parameter name    parameter value   
attachment example filename=example.txt

RFC 2231/5987 Encoding: Character Sets

Various tests using the parameter value encoding defined in RFC 5987.

attwithisofn2231iso [TEST] [R]

Content-Disposition: attachment; filename*=iso-8859-1''foo-%E4.html
Test Results
FF22 pass
MSIE8 unsupported
MSIE9 fail (does not accept ISO-8859-1)
Opera pass
Saf6 pass
Konq pass
Chr25 pass

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

disposition type    parameter name    parameter value   
attachment filename* iso-8859-1''foo-%E4.html

After decoding according to RFC 5987:

disposition type    parameter name    parameter value   
attachment filename* foo-.html

attwithfn2231utf8 [TEST] [R]

Content-Disposition: attachment; filename*=UTF-8''foo-%c3%a4-%e2%82%ac.html
Test Results
FF22 pass
MSIE8 unsupported
MSIE9 pass
Opera pass
Saf6 pass
Konq pass
Chr25 pass

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

disposition type    parameter name    parameter value   
attachment filename* UTF-8''foo-%c3%a4-%e2%82%ac.html

After decoding according to RFC 5987:

disposition type    parameter name    parameter value   
attachment filename* foo--€.html

attwithfn2231noc [TEST] [R]

Content-Disposition: attachment; filename*=''foo-%c3%a4-%e2%82%ac.html
Test Results
FF22 warn (decodes as UTF-8 (see Mozilla Bug 685192))
MSIE8 unsupported
MSIE9 pass
Opera warn (decodes as 8bit encoding (ISO-8859-1?))
Saf6 pass (ignores the parameter)
Konq pass (ignores the parameter)
Chr25 pass (ignores the parameter)

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

Extracted raw data:

disposition type    parameter name    parameter value   
attachment filename* ''foo-%c3%a4-%e2%82%ac.html

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
Test Results
FF22 pass
MSIE8 unsupported
MSIE9 pass
Opera pass
Saf6 pass
Konq pass
Chr25 pass

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

disposition type    parameter name    parameter value   
attachment filename* UTF-8''foo-a%cc%88.html

After decoding according to RFC 5987:

disposition type    parameter name    parameter value   
attachment filename* foo-ä.html

attwithfn2231utf8-bad [TEST] [R]

Content-Disposition: attachment; filename*=iso-8859-1''foo-%c3%a4-%e2%82%ac.html
Test Results
FF22 pass
MSIE8 unsupported
MSIE9 pass
Opera warn (displays the raw octet sequence as if it was ISO-8859-1 (which is internally treated as windows-1252, which does allow %82))
Saf6 warn (displays the raw octet sequence as if it was ISO-8859-1)
Konq pass
Chr25 warn (displays the raw octet sequence as if it was ISO-8859-1)

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

disposition type    parameter name    parameter value   
attachment filename* iso-8859-1''foo-%c3%a4-%e2%82%ac.html

Error: illegal-octet: 130

attwithfn2231iso-bad [TEST] [R]

Content-Disposition: attachment; filename*=utf-8''foo-%E4.html
Test Results
FF22 pass
MSIE8 unsupported
MSIE9 warn (detects "foo-%E4.html")
Opera warn (apparently falls back to ISO-8859-1)
Saf6 pass
Konq pass (seems to insert a replacement character)
Chr25 pass

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

disposition type    parameter name    parameter value   
attachment filename* utf-8''foo-%E4.html

Error: illegal-octet: 228

attwithfn2231ws1 [TEST] [R]

Content-Disposition: attachment; filename *=UTF-8''foo-%c3%a4.html
                               ^ (PARSE ERROR)
Test Results
FF22 pass
MSIE8 unsupported
MSIE9 pass
Opera pass
Saf6 pass
Konq pass
Chr25 pass

'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
Test Results
FF22 pass
MSIE8 unsupported
MSIE9 pass
Opera pass
Saf6 pass
Konq pass
Chr25 pass

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

disposition type    parameter name    parameter value   
attachment filename* UTF-8''foo-%c3%a4.html

After decoding according to RFC 5987:

disposition type    parameter name    parameter value   
attachment filename* foo-.html

attwithfn2231ws3 [TEST] [R]

Content-Disposition: attachment; filename* =UTF-8''foo-%c3%a4.html
Test Results
FF22 pass
MSIE8 unsupported
MSIE9 pass
Opera pass
Saf6 pass
Konq pass
Chr25 pass

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

disposition type    parameter name    parameter value   
attachment filename* UTF-8''foo-%c3%a4.html

After decoding according to RFC 5987:

disposition type    parameter name    parameter value   
attachment filename* foo-.html

attwithfn2231quot [TEST] [R]

Content-Disposition: attachment; filename*="UTF-8''foo-%c3%a4.html"
Test Results
FF22 warn (accepts the encoding despite double quotes not being allowed here (see Mozilla Bug 651185))
MSIE8 unsupported
MSIE9 pass
Opera pass
Saf6 pass
Konq pass
Chr25 pass

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

disposition type    parameter name    parameter value   
attachment filename* "UTF-8''foo-%c3%a4.html"

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

disposition type    parameter name    parameter value   
attachment filename* UTF-8''foo-%c3%a4.html

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

attwithfn2231quot2 [TEST] [R]

Content-Disposition: attachment; filename*="foo%20bar.html"
Test Results
FF22 warn (processes the parameter despite broken quotes and missing delimiters (see Mozilla Bug 651185, Mozilla Bug 685192, and Mozilla Bug 692574))
MSIE8 unsupported
MSIE9 pass
Opera pass
Saf6 pass
Konq pass
Chr25 pass

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

disposition type    parameter name    parameter value   
attachment filename* "foo%20bar.html"

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

disposition type    parameter name    parameter value   
attachment filename* foo%20bar.html

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

attwithfn2231singleqmissing [TEST] [R]

Content-Disposition: attachment; filename*=UTF-8'foo-%c3%a4.html
Test Results
FF22 warn (tolerates the missing single quote (see Mozilla Bug 692574))
MSIE8 unsupported
MSIE9 pass
Opera pass
Saf6 pass
Konq pass
Chr25 pass

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

disposition type    parameter name    parameter value   
attachment filename* UTF-8'foo-%c3%a4.html

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

attwithfn2231nbadpct1 [TEST] [R]

Content-Disposition: attachment; filename*=UTF-8''foo%
Test Results
FF22 pass
MSIE8 unsupported
MSIE9 warn (displays "foo%")
Opera warn (displays "foo%")
Saf6 pass
Konq pass
Chr25 warn (displays "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:

disposition type    parameter name    parameter value   
attachment filename* UTF-8''foo%

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

attwithfn2231nbadpct2 [TEST] [R]

Content-Disposition: attachment; filename*=UTF-8''f%oo.html
Test Results
FF22 pass
MSIE8 unsupported
MSIE9 warn (displays "f%oo.html")
Opera warn (displays "f%oo.html")
Saf6 pass
Konq pass (ignores the filename parameter)
Chr25 warn (displays "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:

disposition type    parameter name    parameter value   
attachment filename* UTF-8''f%oo.html

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

attwithfn2231dpct [TEST] [R]

Content-Disposition: attachment; filename*=UTF-8''A-%2541.html
Test Results
FF22 pass
MSIE8 unsupported
MSIE9 pass
Opera pass
Saf6 pass
Konq pass
Chr25 pass

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

Extracted raw data:

disposition type    parameter name    parameter value   
attachment filename* UTF-8''A-%2541.html

After decoding according to RFC 5987:

disposition type    parameter name    parameter value   
attachment filename* A-%41.html

attwithfn2231abspathdisguised [TEST] [R]

Content-Disposition: attachment; filename*=UTF-8''%5cfoo.html
Test Results
FF22 pass (substitutes "\" by "_")
MSIE8 unsupported
MSIE9 pass (substitutes "\" by "_")
Opera pass (strips the "\")
Saf6 unsupported
Konq warn (On OSX: stores the leading "\")
Chr25 pass (substitutes "\" by "_")

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

Extracted raw data:

disposition type    parameter name    parameter value   
attachment filename* UTF-8''%5cfoo.html

After decoding according to RFC 5987:

disposition type    parameter name    parameter value   
attachment filename* \foo.html

RFC2231 Encoding: Continuations (optional)

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

attfncont [TEST] [R]

Content-Disposition: attachment; filename*0="foo."; filename*1="html"
Test Results
FF22 pass (but see (Mozilla Bug 776324))
MSIE8 unsupported
MSIE9 unsupported
Opera pass
Saf6 unsupported
Konq pass
Chr25 unsupported

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

disposition type    parameter name    parameter value   
attachment filename*0 "foo."
filename*1 "html"

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

disposition type    parameter name    parameter value   
attachment filename*0 foo.
filename*1 html

attfncontqs [TEST] [R]

Content-Disposition: attachment; filename*0="foo"; filename*1="\b\a\r.html"
Test Results
FF22 pass (but see (Mozilla Bug 776324))
MSIE8 unsupported
MSIE9 unsupported
Opera pass
Saf6 unsupported
Konq pass
Chr25 unsupported

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

disposition type    parameter name    parameter value   
attachment filename*0 "foo"
filename*1 "\b\a\r.html"

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

disposition type    parameter name    parameter value   
attachment filename*0 foo
filename*1 bar.html

attfncontenc [TEST] [R]

Content-Disposition: attachment; filename*0*=UTF-8''foo-%c3%a4; filename*1=".html"
Test Results
FF22 pass (but see (Mozilla Bug 776324))
MSIE8 unsupported
MSIE9 unsupported
Opera pass
Saf6 unsupported
Konq pass
Chr25 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".

Extracted raw data:

disposition type    parameter name    parameter value   
attachment filename*0* UTF-8''foo-%c3%a4
filename*1 ".html"

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

disposition type    parameter name    parameter value   
attachment filename*0* UTF-8''foo-%c3%a4
filename*1 .html

attfncontlz [TEST] [R]

Content-Disposition: attachment; filename*0="foo"; filename*01="bar"
Test Results
FF22 pass (but see (Mozilla Bug 776324))
MSIE8 unsupported
MSIE9 unsupported
Opera warn (accepts leading zeros)
Saf6 unsupported
Konq pass
Chr25 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".

Extracted raw data:

disposition type    parameter name    parameter value   
attachment filename*0 "foo"
filename*01 "bar"

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

disposition type    parameter name    parameter value   
attachment filename*0 foo
filename*01 bar

attfncontnc [TEST] [R]

Content-Disposition: attachment; filename*0="foo"; filename*2="bar"
Test Results
FF22 pass (but see (Mozilla Bug 776324))
MSIE8 unsupported
MSIE9 unsupported
Opera pass
Saf6 unsupported
Konq pass
Chr25 unsupported

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

disposition type    parameter name    parameter value   
attachment filename*0 "foo"
filename*2 "bar"

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

disposition type    parameter name    parameter value   
attachment filename*0 foo
filename*2 bar

attfnconts1 [TEST] [R]

Content-Disposition: attachment; filename*1="foo."; filename*2="html"
Test Results
FF22 pass (but see (Mozilla Bug 776324))
MSIE8 unsupported
MSIE9 unsupported
Opera pass
Saf6 unsupported
Konq pass
Chr25 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.

Extracted raw data:

disposition type    parameter name    parameter value   
attachment filename*1 "foo."
filename*2 "html"

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

disposition type    parameter name    parameter value   
attachment filename*1 foo.
filename*2 html

attfncontord [TEST] [R]

Content-Disposition: attachment; filename*1="bar"; filename*0="foo"
Test Results
FF22 pass (but see (Mozilla Bug 776324))
MSIE8 unsupported
MSIE9 unsupported
Opera pass
Saf6 unsupported
Konq pass
Chr25 unsupported

'attachment', specifying a filename of foobar

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

Extracted raw data:

disposition type    parameter name    parameter value   
attachment filename*1 "bar"
filename*0 "foo"

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

disposition type    parameter name    parameter value   
attachment filename*1 bar
filename*0 foo

RFC2231 Encoding: Fallback Behaviour

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

attfnboth [TEST] [R]

Content-Disposition: attachment; filename="foo-ae.html"; filename*=UTF-8''foo-%c3%a4.html
Test Results
FF22 pass (picks the RFC 2231 encoded value)
MSIE8 unsupported (picks the traditionally encoded value -- the first of both)
MSIE9 pass (picks the RFC 2231 encoded value)
Opera pass (picks the RFC 2231 encoded value)
Saf6 pass (picks the RFC 2231 encoded value)
Konq pass (picks the RFC 2231 encoded value)
Chr25 pass (picks the RFC 2231 encoded value)

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

disposition type    parameter name    parameter value   
attachment filename "foo-ae.html"
filename* UTF-8''foo-%c3%a4.html

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

disposition type    parameter name    parameter value   
attachment filename foo-ae.html
filename* UTF-8''foo-%c3%a4.html

After decoding according to RFC 5987:

disposition type    parameter name    parameter value   
attachment filename foo-ae.html
filename* foo-.html

attfnboth2 [TEST] [R]

Content-Disposition: attachment; filename*=UTF-8''foo-%c3%a4.html; filename="foo-ae.html"
Test Results
FF22 pass (picks the RFC 2231 encoded value)
MSIE8 fail (ignores the parameter (this indicates a parsing bug))
MSIE9 pass (picks the RFC 2231 encoded value)
Opera pass (picks the RFC 2231 encoded value)
Saf6 pass (picks the RFC 2231 encoded value)
Konq pass (picks the RFC 2231 encoded value)
Chr25 pass (picks the RFC 2231 encoded value)

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

disposition type    parameter name    parameter value   
attachment filename* UTF-8''foo-%c3%a4.html
filename "foo-ae.html"

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

disposition type    parameter name    parameter value   
attachment filename* UTF-8''foo-%c3%a4.html
filename foo-ae.html

After decoding according to RFC 5987:

disposition type    parameter name    parameter value   
attachment filename* foo-.html
filename foo-ae.html

attfnboth3 [TEST] [R]

Content-Disposition: attachment; filename*0*=ISO-8859-15''euro-sign%3d%a4; filename*=ISO-8859-1''currency-sign%3d%a4
Test Results
FF22 pass (uses RFC5987 simple format)
MSIE8 unsupported
MSIE9 pass (ignores both)
Opera pass (uses RFC2231/cont format (the first one))
Saf6 pass (uses RFC5987 simple format)
Konq pass (uses RFC2231/cont format (the first one))
Chr25 pass (uses RFC5987 simple format)

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

disposition type    parameter name    parameter value   
attachment filename*0* ISO-8859-15''euro-sign%3d%a4
filename* ISO-8859-1''currency-sign%3d%a4

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

disposition type    parameter name    parameter value   
attachment filename*0* ISO-8859-15''euro-sign%3d%a4
filename* ISO-8859-1''currency-sign%3d%a4

After decoding according to RFC 5987:

disposition type    parameter name    parameter value   
attachment filename*0* ISO-8859-15''euro-sign%3d%a4
filename* currency-sign=

attnewandfn [TEST] [R]

Content-Disposition: attachment; foobar=x; filename="foo.html"
Test Results
FF22 pass
MSIE8 pass
MSIE9 pass
Opera pass
Saf6 pass
Konq pass
Chr25 pass

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

disposition type    parameter name    parameter value   
attachment foobar x
filename "foo.html"

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

disposition type    parameter name    parameter value   
attachment foobar x
filename foo.html

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 RFC 2047.

Note that for some bizarre reason, some Web sites, such as GMail, use this encoding despite historically it was only implemented in Mozilla browsers, which do support the RFC2231 encoding as well.

attrfc2047token [TEST] [R]

Content-Disposition: attachment; filename==?ISO-8859-1?Q?foo-=E4.html?=
                               ^ (PARSE ERROR)
Test Results
FF22 fail (decodes it anyway to "foo-.html" (see Mozilla Bug 601933))
MSIE8 warn (takes the whole value as filename, but does not decode it (replacing question marks by underscores))
MSIE9 warn (takes the whole value as filename, but does not decode it (replacing question marks by underscores))
Opera fail (displays garbage ("=.htm"))
Saf6 warn (takes the whole value as filename, but does not decode it (replacing question marks by underscores))
Konq pass (ignores the parameter)
Chr25 fail (decodes it anyway to "foo-.html" (see Chrome Issue 66694))

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?="
Test Results
FF22 fail (decodes it anyway to "foo-.html" (see Mozilla Bug 601933))
MSIE8 pass (takes the whole value as filename, but does not decode it)
MSIE9 pass (takes the whole value as filename, but does not decode it)
Opera fail (displays garbage ("=.htm"))
Saf6 pass (takes the whole value as filename, but does not decode it)
Konq pass (takes the whole value as filename, but does not decode it)
Chr25 fail (decodes it anyway to "foo-.html" (see Chrome Issue 66694))

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

Extracted raw data:

disposition type    parameter name    parameter value   
attachment filename "=?ISO-8859-1?Q?foo-=E4.html?="

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

disposition type    parameter name    parameter value   
attachment filename =?ISO-8859-1?Q?foo-=E4.html?=

Test Case Generation

Both this document and the indiviual test "scripts" are generated from one single XML source (tc2231.xml), using an XSLT2 transformation (tc2231.xslt).

The transformation contains a regular-expression based parser for header fields, and embeds the parse results in the output. For now, the parser only checks the syntax (based on the ABNF), but does not inspect the actual parameters that are discovered.

To generate the files, an XSLT2 processor such as Saxon 9 is needed. Copy both files into an empty directory, then run:

saxon9 tc2231.xml tc2231.xslt > index.html

Note that this will also generate a set of "asis" files that contain the actual test cases. These can be served using the Apache httpd mod_asis module.