Firefox 12 Firefox 14 ("aurora" - 2012-04-29) Firefox 15 ("nightly" - 2012-04-30) Microsoft IE 8 Microsoft IE 9 Opera 11.60 Safari 5.1 Konqueror 4.7.4 Google Chrome 18

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

inline 'inline' only This should be equivalent to not including the header at all. "inline" 'inline' only, using double quotes This is invalid syntax, thus the header should be ignored. apparently parsed as unknown disposition type, thus defaulting to "attachment" apparently parsed as unknown disposition type, thus defaulting to "attachment" apparently parsed as unknown disposition type, thus defaulting to "attachment" inline; filename="foo.html" 'inline', specifying a filename of foo.html Some UAs use this filename in a subsequent "save" operation. uses the filename in subsequent 'save' operation uses the filename in subsequent 'save' operation uses the filename in subsequent 'save' operation filename information not used filename information not used filename information not used filename information not used filename information not used filename information not used (filename derived from title) inline; filename="Not an attachment!" 'inline', specifying a filename of Not an attachment! - this checks for proper parsing for disposition types. thinks this is an attachment 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). filename information only used when save happens through UA menu, not PDF plugin (see Mozilla Bug 433613) filename information only used when save happens through UA menu, not PDF plugin (see Mozilla Bug 433613) filename information only used when save happens through UA menu, not PDF plugin (see Mozilla Bug 433613) filename information not used filename information not used filename information only used when save happens through UA menu, not PDF plugin filename information not used filename information not used uses the filename in subsequent 'save' operation

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

attachment 'attachment' only UA should offer to download the resource. "attachment" 'attachment' only, using double quotes This is invalid syntax, thus the header should be ignored. apparently parsed either as unknown disposition type, thus defaulting to "attachment", or mistaken for "attachment" apparently parsed either as unknown disposition type, thus defaulting to "attachment", or mistaken for "attachment" apparently parsed either as unknown disposition type, thus defaulting to "attachment", or mistaken for "attachment" apparently parsed either as unknown disposition type, thus defaulting to "attachment", or mistaken for "attachment" apparently parsed either as unknown disposition type, thus defaulting to "attachment", or mistaken for "attachment" attachment 403 'attachment' only, but returned with a 403 status. UA should report the server status. but displays a misleading error message (see Mozilla Bug 364354) but displays a misleading error message (see Mozilla Bug 364354) but displays a misleading error message (see Mozilla Bug 364354) but displays a misleading error message error is reported saves the content without warning saves the content without warning displays the content as if the header field wasn't present but displays a misleading error message ATTACHMENT 'ATTACHMENT' only UA should offer to download the resource. attachment; filename="foo.html" 'attachment', specifying a filename of foo.html UA should offer to download the resource as "foo.html". attachment; filename="0000000000111111111122222" 'attachment', specifying a filename of 0000000000111111111122222 (25 characters) attachment; filename="00000000001111111111222222222233333" 'attachment', specifying a filename of 00000000001111111111222222222233333 (35 characters) 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". apparently does not treat the backslash as escape character, replaces it with '_' apparently does not treat the backslash as escape character, replaces it with '_' apparently does not treat the backslash as escape character, replaces it with '-' 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). needs to be investigated, apparently double quotes are still replaced with '_' needs to be investigated, apparently double quotes are still replaced with '_' needs to be investigated, apparently double quotes are still replaced with '_' apparently does not treat the backslash as escape character, replaces it with '_' apparently does not treat the backslash as escape character, replaces it with '_' apparently does not treat the backslash as escape character, replaces it with '-' unquotes properly, but replaces the double quotes with "-" attachment; filename="Here's a semicolon;.html" 'attachment', specifying a filename of Here's a semicolon;.html - this checks for proper parsing for parameters. thinks the filename is terminated by the semicolon thinks the filename is terminated by the semicolon 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". 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". trips over the extension parameter (further investigation shows it's caused by the \" sequence) attachment; FILENAME="foo.html" 'attachment', specifying a filename of foo.html UA should offer to download the resource as "foo.html". 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. accepts the unquoted value accepts the unquoted value accepts the unquoted value accepts the unquoted value accepts the unquoted value accepts the unquoted value accepts the unquoted value accepts the unquoted value accepts the unquoted value attachment; filename=foo,bar.html 'attachment', specifying a filename of foo,bar.html using a comma despite using token syntax. accepts the unquoted value accepts the unquoted value accepts the unquoted value accepts the unquoted value accepts the unquoted value accepts the unquoted value treats the comma as delimiter and offers to download "foo.html" ignores thes header field reports a network error ("Duplicate headers received from server") attachment; filename=foo.html ; '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. accepts the unquoted value, treats semicolon as delimiter accepts the unquoted value, treats semicolon as delimiter accepts the unquoted value, treats semicolon as delimiter accepts the unquoted value, treats semicolon as delimiter accepts the unquoted value, treats semicolon as delimiter accepts the unquoted value, treats semicolon as delimiter accepts the unquoted value, treats semicolon as delimiter accepts the unquoted value, treats semicolon as delimiter accepts the unquoted value, treats semicolon as delimiter attachment; ;filename=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. skips the missing parameter and sees 'foo' skips the missing parameter and sees 'foo' skips the missing parameter and sees 'foo' skips the missing parameter and sees 'foo' skips the missing parameter and sees 'foo' skips the missing parameter and sees 'foo' skips the missing parameter and sees 'foo' header field ignored skips the missing parameter and sees 'foo' attachment; filename=foo bar.html 'attachment', specifying a filename of foo bar.html without using quoting. This is invalid. "token" does not allow whitespace. ignores "bar" ignores "bar" ignores "bar" apparently replaces whitespace by "_" accepts the whitespace as part of the value accepts the whitespace as part of the value accepts the whitespace as part of the value ignores the parameter accepts the whitespace as part of the value attachment; filename='foo.bar' 'attachment', specifying a filename of 'foo.bar' using single quotes. note that the second quote disappears as the extension gets rewritten removes the single quotes 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". 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. decodes as UTF-8 (see Mozilla Bug 588409) decodes as UTF-8 (see Mozilla Bug 588409) decodes as UTF-8 (see Mozilla Bug 588409) decodes as UTF-8 decodes as UTF-8 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. displays "foo-A.html" displays "foo-A.html" displays "foo-A.html" (see Chrome Issue 118) 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. 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". apparently does not treat the backslash as escape character, replaces it with '_' apparently does not treat the backslash as escape character, replaces it with '_' apparently does not treat the backslash as escape character, replaces it with '-' saves "foo-%_41.html" (skips the unescaping of "\") 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. displays "foo-%41.html" (support for "name" apparently was added as part of Mozilla Bug 229785) displays "foo-%41.html" (support for "name" apparently was added as part of Mozilla Bug 229785) displays "foo-%41.html" (support for "name" apparently was added as part of Mozilla Bug 229785) parameter ignored parameter ignored parameter ignored parameter ignored parameter ignored displays "foo-A.html" 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) displays "ä-A.html" displays "ä-A.html" 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. displays "foo-ä-€.html" displays "foo-ä-€.html" displays "foo-ä-€.html" (see Chrome Issue 118) 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". attachment; filename="foo.html"; filename="bar.html" 'attachment', specifying two filename parameters. This is invalid syntax. Takes first parameter Takes first parameter Takes first parameter Takes first parameter Takes first parameter Takes first parameter Takes first parameter Takes first parameter attachment; filename=foo[1](2).html 'attachment', specifying a filename of foo[1](2).html, but missing the quotes. Also, "[", "]", "(" and ")" are not allowed in the HTTP token production. This is invalid according to Section 19.5.1 of RFC 2616 and RFC 6266, so UAs should ignore it. accepts the unquoted value accepts the unquoted value accepts the unquoted value accepts the unquoted value accepts the unquoted value accepts the unquoted value accepts the unquoted value accepts the unquoted value attachment; filename=foo-ä.html '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. accepts the umlaut accepts the umlaut accepts the umlaut accepts the umlaut accepts the umlaut accepts the umlaut accepts the umlaut accepts the umlaut attachment; filename=foo-ä.html '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. accepts the umlaut, also sniffs as UTF-8 accepts the umlaut, also sniffs as UTF-8 accepts the umlaut, also sniffs as UTF-8 accepts the umlaut accepts the umlaut accepts the umlaut accepts the umlaut, also sniffs as UTF-8 accepts the umlaut, also sniffs as UTF-8 filename=foo.html Disposition type missing, filename specified. This is invalid, so UAs should ignore it. Treated as inline (and filename used in subsequent save operation) Treated as inline (and filename used in subsequent save operation) Treated as inline (and filename used in subsequent save operation) Header field ignored Header field ignored Header field ignored Header field ignored Header field ignored Header field ignored x=y; filename=foo.html Disposition type missing, filename specified after extension parameter. This is invalid, so UAs should ignore it. Treated as named attachment (see Mozilla Bug 671204) Treated as named attachment (see Mozilla Bug 671204) Treated as named attachment (see Mozilla Bug 671204) Header field ignored Header field ignored Header field ignored Header field ignored Header field ignored Header field ignored "foo; filename=bar;baz"; filename=qux Disposition type missing, filename "qux". Can it be more broken? (Probably) This is invalid, so UAs should ignore it. Sees "qux" (see Mozilla Bug 671204) Sees "qux" (see Mozilla Bug 671204) Sees "qux" (see Mozilla Bug 671204) Header field ignored Header field ignored Header field ignored Header field ignored Header field ignored Header field ignored filename=foo.html, filename=bar.html 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. Header field ignored Header field ignored Header field ignored Header field ignored Header field ignored Header field ignored Header field ignored Header field ignored reports a network error ("Duplicate headers received from server") ; filename=foo.html Disposition type missing (but delimiter present), filename specified. This is invalid, so UAs should ignore it. Header field ignored Header field ignored Header field ignored Header field ignored Header field ignored Header field ignored Header field ignored Header field ignored Header field ignored inline; attachment; filename=foo.html Both disposition types specified. This is invalid, so UAs should ignore it. Header field ignored Header field ignored Header field ignored Picks 'attachment' Picks 'attachment' Header field ignored Header field ignored Header field ignored Header field ignored attachment; inline; filename=foo.html Both disposition types specified. This is invalid, so UAs should ignore it. treats it as (named) attachment treats it as (named) attachment treats it as (named) attachment treats it as (named) attachment treats it as (named) attachment treats it as (named) attachment treats it as (named) attachment treats it as (unnamed) attachment attachment; filename="foo.html".txt '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. ignores the stuff after the second double quote ignores the stuff after the second double quote ignores the stuff after the second double quote treats the suffix as part of the filename treats the suffix as part of the filename ignores the stuff after the second double quote treats the suffix as part of the filename replaces second double quote by "-" attachment; filename="bar 'attachment', specifying a filename parameter that is broken (missing ending double quote). This is invalid syntax. This is invalid, so UAs should ignore it. accepts the filename parameter as if complete (see Mozilla Bug 686198) accepts the filename parameter as if complete (see Mozilla Bug 686198) accepts the filename parameter as if complete (see Mozilla Bug 686198) accepts the filename parameter as if complete accepts the filename parameter as if complete appears to see the token form, and derives ""bar.html" (note the leading double quote) accepts the filename parameter as if complete attachment; filename=foo"bar;baz"qux '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. sees "foo_bar" (apparently substituting the double quote, and truncating at the semicolon) sees "foo_bar" (apparently substituting the double quote, and truncating at the semicolon) sees "foo_bar" (apparently substituting the double quote, and truncating at the semicolon) sees "foo_bar" (apparently substituting the double quote, and truncating at the semicolon) sees "foo_bar" (apparently substituting the double quote, and truncating at the semicolon) sees "foo"bar;baz"qux" (accepts all characters inside the token?) sees "foo"bar;baz"qux" (accepts all characters inside the token?) sees "foo-bar;baz"qux" (accepts all characters inside the token?) attachment; filename=foo.html, attachment; filename=bar.html '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. sees "bar.html" (picking the second value, see Mozilla Bug 480100) sees "bar.html" (picking the second value, see Mozilla Bug 480100) sees "bar.html" (picking the second value, see Mozilla Bug 480100) sees "foo[1].html, attachment" sees "foo[1].html, attachment" sees "foo.htm" sees "foo.html, attachment.html" sees "bar.html" reports a network error ("Duplicate headers received from server") attachment; foo=foo filename=bar Uses two parameters, but the mandatory delimiter ";" is missing. This is invalid, so UAs should ignore it. sees "bar" sees "bar" sees "bar" sees unnamed attachment sees unnamed attachment sees unnamed attachment sees unnamed attachment sees unnamed attachment sees unnamed attachment filename=foo.html; attachment filename parameter and disposion type reversed. This is invalid, so UAs should ignore it. (but see Mozilla Bug 263933) (but see Mozilla Bug 263933) (but see Mozilla Bug 263933) treated as named attachment attachment; xfilename=foo.html 'attachment', specifying an "xfilename" parameter. Should be treated as unnamed attachment. attachment; filename="/foo.html" 'attachment', specifying an absolute filename in the filesystem root. Either ignore the filename altogether, or discard the path information. Replaces the path separator with "_". Replaces the path separator with "_". Replaces the path separator with "_". Replaces the path separator with "_". Replaces the path separator with "_". Strips the path separator. Replaces the path separator with "-". Strips the path separator. Replaces the path separator with "_". 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. Replaces the path separator with "_". Replaces the path separator with "_". Replaces the path separator with "_". Replaces the path separator with "__"; apparently processing raw "\" characters instead of the unescaped quoted-string. Replaces the path separator with "__"; apparently processing raw "\" characters instead of the unescaped quoted-string. Strips the path separator. Replaces the path separator with "--"; apparently processing raw "\" characters instead of the unescaped quoted-string. Strips the platform-specific path separator. Replaces the path separator with "_".

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

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. seems to ignore the parameter (see Mozilla Bug 531353) seems to ignore the parameter (see Mozilla Bug 531353) seems to ignore the parameter (see Mozilla Bug 531353) seems to ignore the parameter seems to ignore the parameter seems to ignore the parameter seems to ignore the parameter seems to ignore the parameter seems to ignore the parameter 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. seems to ignore the parameter (see Mozilla Bug 531353) seems to ignore the parameter (see Mozilla Bug 531353) seems to ignore the parameter (see Mozilla Bug 531353) seems to ignore the parameter seems to ignore the parameter seems to ignore the parameter seems to ignore the parameter seems to ignore the parameter

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

foobar 'foobar' only This should be equivalent to using "attachment". does not treat it as 'attachment' does not treat it as 'attachment' does not treat it as 'attachment' attachment; example="filename=example.txt" 'attachment', with no filename parameter

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

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". does not accept ISO-8859-1 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". 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. decodes as UTF-8 (see Mozilla Bug 685192) decodes as UTF-8 (see Mozilla Bug 685192) decodes as UTF-8 (see Mozilla Bug 685192) decodes as 8bit encoding (ISO-8859-1?) ignores the parameter ignores the parameter 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". 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. falls back to UTF-8 (see Mozilla Bug 693806) falls back to UTF-8 (see Mozilla Bug 693806) displays the raw octet sequence as if it was ISO-8859-1 (which is internally treated as windows-1252, which does allow %82) displays the raw octet sequence as if it was ISO-8859-1 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. detects "foo-%E4.html" apparently falls back to ISO-8859-1 seems to insert a replacement character attachment; filename *=UTF-8''foo-%c3%a4.html 'attachment', specifying a filename of foo-ä.html, using RFC2231 encoded UTF-8, with whitespace before "*=" The parameter is invalid, thus should be ignored. 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". 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". 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. accepts the encoding despite double quotes not being allowed here (see Mozilla Bug 651185) accepts the encoding despite double quotes not being allowed here (see Mozilla Bug 651185) accepts the encoding despite double quotes not being allowed here (see Mozilla Bug 651185) 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. processes the parameter despite broken quotes and missing delimiters (see Mozilla Bug 651185, Mozilla Bug 685192, and Mozilla Bug 692574) processes the parameter despite broken quotes and missing delimiters (see Mozilla Bug 651185, Mozilla Bug 685192, and Mozilla Bug 692574) processes the parameter despite broken quotes and missing delimiters (see Mozilla Bug 651185, Mozilla Bug 685192, and Mozilla Bug 692574) 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. tolerates the missing single quote (see Mozilla Bug 692574) tolerates the missing single quote (see Mozilla Bug 692574) tolerates the missing single quote (see Mozilla Bug 692574) 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. displays "foo%" displays "foo%" displays "foo%" displays "foo%" displays "foo%" displays "foo%" 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. displays "f%oo.html" displays "f%oo.html" displays "f%oo.html" displays "f%oo.html" displays "f%oo.html" ignores the filename parameter displays "f%oo.html" attachment; filename*=UTF-8''A-%2541.html 'attachment', specifying a filename of A-%41.html, using RFC2231 encoded UTF-8. attachment; filename*=UTF-8''%5cfoo.html 'attachment', specifying a filename of \foo.html, using RFC2231 encoded UTF-8. substitutes "\" by "_" substitutes "\" by "_" substitutes "\" by "_" substitutes "\" by "_" strips the "\" Strips the platform-specific path separator. substitutes "\" by "_"

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

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". 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". fails to apply quoted-string unescaping, replaces backquotes by underscores (see Mozilla Bug 730574) fails to apply quoted-string unescaping, replaces backquotes by underscores (see Mozilla Bug 730574) fails to apply quoted-string unescaping, replaces backquotes by underscores (see Mozilla Bug 730574) 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". 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". accepts leading zeros 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". 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. attachment; filename*1="bar"; filename*0="foo" 'attachment', specifying a filename of foobar UA should offer to download the resource as "foobar". parameters apparently are expected to be ordered (see Mozilla Bug 384571)

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

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. picks the RFC 2231 encoded value picks the RFC 2231 encoded value picks the RFC 2231 encoded value picks the traditionally encoded value -- the first of both picks the RFC 2231 encoded value picks the RFC 2231 encoded value picks the traditionally encoded value -- the first of both picks the RFC 2231 encoded value picks the RFC 2231 encoded value 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. picks the RFC 2231 encoded value picks the RFC 2231 encoded value picks the RFC 2231 encoded value ignores the parameter (this indicates a parsing bug) picks the RFC 2231 encoded value picks the RFC 2231 encoded value picks the traditionally encoded value -- the one it understands picks the RFC 2231 encoded value picks the RFC 2231 encoded value 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. uses RFC5987 simple format uses RFC5987 simple format uses RFC5987 simple format ignores both uses RFC2231/cont format (the first one) uses RFC2231/cont format (the first one) uses RFC5987 simple format 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).

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.

attachment; filename==?ISO-8859-1?Q?foo-=E4.html?= Uses RFC 2047 style encoded word. "=" is invalid inside the token production, so this is invalid. decodes it anyway to "foo-ä.html" (see Mozilla Bug 601933) decodes it anyway to "foo-ä.html" (see Mozilla Bug 601933) decodes it anyway to "foo-ä.html" (see Mozilla Bug 601933) takes the whole value as filename, but does not decode it (replacing question marks by underscores) takes the whole value as filename, but does not decode it (replacing question marks by underscores) displays garbage ("=.htm") takes the whole value as filename, but does not decode it (replacing question marks by underscores) ignores the parameter decodes it anyway to "foo-ä.html" (see Chrome Issue 66694) attachment; filename="=?ISO-8859-1?Q?foo-=E4.html?=" Uses RFC 2047 style encoded word, using the quoted-string production. decodes it anyway to "foo-ä.html" (see Mozilla Bug 601933) decodes it anyway to "foo-ä.html" (see Mozilla Bug 601933) decodes it anyway to "foo-ä.html" (see Mozilla Bug 601933) takes the whole value as filename, but does not decode it takes the whole value as filename, but does not decode it displays garbage ("=.htm") takes the whole value as filename, but does not decode it takes the whole value as filename, but does not decode it decodes it anyway to "foo-ä.html" (see Chrome Issue 66694)