Various tests relating to the "inline" disposition type, see Section 2.1 of RFC 2183.
Content-Disposition: inline
Test Results | |
---|---|
FF3 | pass |
MSIE8 | pass |
Op10 | pass |
Saf4 | pass |
Konq | pass |
Chrome | pass |
'inline' only
This should be equivalent to not including the header at all.
Content-Disposition: inline; filename="foo.html"
Test Results | |
---|---|
FF3 | pass (uses the filename in subsequent 'save' operation) |
MSIE8 | pass (filename information not used) |
Op10 | pass (filename information not used) |
Saf4 | pass (filename information not used) |
Konq | pass (filename information not used) |
Chrome | pass (filename information not used) |
'inline', specifying a filename of foo.html
Some UAs use this filename in a subsequent "save" operation.
Content-Disposition: inline; filename="foo.pdf"
Test Results | |
---|---|
FF3 | pass (filename information not used) |
MSIE8 | pass (filename information not used) |
Op10 | pass (filename information not used) |
Saf4 | pass (filename information not used) |
Konq | pass (filename information not used) |
Chrome | pass (filename information not used) |
'inline', specifying a filename of foo.pdf
Some UAs use this filename in a subsequent "save" operation. This variation of the test checks whether whatever handles PDF display receives the filename information, and acts upon it (this was tested with the latest Acrobat Reader plugin).
Various tests relating to the "attchment" disposition type, see Section 2.2 of RFC 2183.
Content-Disposition: attachment
Test Results | |
---|---|
FF3 | pass |
MSIE8 | pass |
Op10 | pass |
Saf4 | pass |
Konq | pass |
Chrome | pass |
'attachment' only
UA should offer to download the resource.
Content-Disposition: ATTACHMENT
Test Results | |
---|---|
FF3 | pass |
MSIE8 | pass |
Op10 | pass |
Saf4 | pass |
Konq | fail |
Chrome | pass |
'ATTACHMENT' only
UA should offer to download the resource.
Content-Disposition: attachment; filename="foo.html"
Test Results | |
---|---|
FF3 | pass |
MSIE8 | pass |
Op10 | pass |
Saf4 | pass |
Konq | pass |
Chrome | pass |
'attachment', specifying a filename of foo.html
UA should offer to download the resource as "foo.html".
Content-Disposition: attachment; filename="f\oo.html"
Test Results | |
---|---|
FF3 | fail (apparently does not treat the backslash as escape character, replaces it with '_') |
MSIE8 | fail (apparently does not treat the backslash as escape character, replaces it with '_') |
Op10 | pass |
Saf4 | fail (apparently does not treat the backslash as escape character, replaces it with '-') |
Konq | pass |
Chrome | fail (saves "oo.html" (what's going on here?)) |
'attachment', specifying a filename of f\oo.html
(the first 'o' being escaped)
UA should offer to download the resource as "foo.html".
Content-Disposition: attachment; foo="bar"; filename="foo.html"
Test Results | |
---|---|
FF3 | pass |
MSIE8 | pass |
Op10 | pass |
Saf4 | pass |
Konq | pass |
Chrome | pass |
'attachment', specifying a filename of foo.html
and an extension parameter "foo" which should be ignored
(see Section 2.8 of RFC 2183.).
UA should offer to download the resource as "foo.html".
Content-Disposition: attachment; FILENAME="foo.html"
Test Results | |
---|---|
FF3 | pass |
MSIE8 | pass |
Op10 | pass |
Saf4 | pass |
Konq | fail (filename parameter is ignored) |
Chrome | pass |
'attachment', specifying a filename of foo.html
UA should offer to download the resource as "foo.html".
Content-Disposition: attachment; filename=foo.html
Test Results | |
---|---|
FF3 | warn (accepts the unquoted value) |
MSIE8 | warn (accepts the unquoted value) |
Op10 | warn (accepts the unquoted value) |
Saf4 | warn (accepts the unquoted value) |
Konq | warn (accepts the unquoted value) |
Chrome | warn (accepts the unquoted value) |
'attachment', specifying a filename of foo.html
, but missing
the quotes.
This is invalid according to Section 19.5.1 of RFC2616, so UAs should ignore it.
Content-Disposition: attachment; filename="foo-ä.html"
Test Results | |
---|---|
FF3 | pass |
MSIE8 | pass |
Op10 | pass |
Saf4 | pass |
Konq | pass |
Chrome | pass |
'attachment', specifying a filename of foo-ä.html
, using plain ISO-8859-1
UA should offer to download the resource as "foo-ä.html".
Content-Disposition: attachment; filename="foo-ä.html"
Test Results | |
---|---|
FF3 | fail (decodes as UTF-8) |
MSIE8 | pass |
Op10 | pass |
Saf4 | pass |
Konq | pass |
Chrome | fail (decodes as UTF-8) |
'attachment', specifying a filename of foo-ä.html
,
which happens to be foo-ä.html
using UTF-8 encoding.
UA should offer to download the resource as "foo-ä.html". Displaying "foo-ä.html" instead indicates that the UA tried to be smart by detecting something that happens to look like UTF-8.
Content-Disposition: attachment; filename="foo-%41.html"
Test Results | |
---|---|
FF3 | pass |
MSIE8 | fail (displays "foo-A.html") |
Op10 | pass |
Saf4 | pass |
Konq | pass |
Chrome | fail (displays "foo-A.html" (see Chrome Issue 118)) |
'attachment', specifying a filename of foo-%41.html
UA should offer to download the resource as "foo-%41.html". Displaying "foo-A.html" instead would indicate that the UA has attempted to percent-decode the parameter.
Content-Disposition: attachment; filename="foo-%c3%a4-%e2%82%ac.html"
Test Results | |
---|---|
FF3 | pass |
MSIE8 | fail (displays "foo-ä-€.html") |
Op10 | pass |
Saf4 | pass |
Konq | pass |
Chrome | fail (displays "foo-ä-€.html" (see Chrome Issue 118)) |
'attachment', specifying a filename of foo-%c3%a4-%e2%82%ac.html
, using raw percent encoded UTF-8
to represent foo-ä-€.html
UA should offer to download the resource as "foo-%c3%a4-%e2%82%ac.html". Displaying "foo-ä-€.html" instead would indicate that the UA has attempted to percent-decode the parameter (using UTF-8). Displaying something else would indicate that the UA tried to percent-decode, but used a different encoding.
Content-Disposition: attachment; filename ="foo.html"
Test Results | |
---|---|
FF3 | pass |
MSIE8 | pass |
Op10 | pass |
Saf4 | pass |
Konq | pass |
Chrome | pass |
'attachment', specifying a filename of foo.html
, with one
blank space before the equals character.
UA should offer to download the resource as "foo.html".
Content-Disposition: attachment; filename= "foo.html"
Test Results | |
---|---|
FF3 | pass |
MSIE8 | pass |
Op10 | pass |
Saf4 | pass |
Konq | pass |
Chrome | pass |
'attachment', specifying a filename of foo.html
, with one
blank space after the equals character.
UA should offer to download the resource as "foo.html".
Content-Disposition: attachment; filename=foo[1](2).html
Test Results | |
---|---|
FF3 | warn (accepts the unquoted value) |
MSIE8 | warn (accepts the unquoted value) |
Op10 | warn (accepts the unquoted value) |
Saf4 | warn (accepts the unquoted value) |
Konq | warn (accepts the unquoted value) |
Chrome | warn (accepts the unquoted value) |
'attachment', specifying a filename of foo[1](2).html
, but missing
the quotes. Also, "[", "]", "(" and ")" are not allowed in the HTTP token
production.
This is invalid according to Section 19.5.1 of RFC2616, so UAs should ignore it.
Various tests relating to the additional parameters defined in Section 2 of RFC 2183.
Content-Disposition: attachment; creation-date="Wed, 12 Feb 1997 16:29:51 -0500"
Test Results | |
---|---|
FF3 | unsupported (seems to ignore the parameter) |
MSIE8 | unsupported (seems to ignore the parameter) |
Op10 | unsupported (seems to ignore the parameter) |
Saf4 | unsupported (seems to ignore the parameter) |
Konq | unsupported (seems to ignore the parameter) |
Chrome | unsupported (seems to ignore the parameter) |
'attachment', plus creation-date (see Section 2.4 of RFC 2183)
UA should offer to download the resource. When doing so, the creation date should be set to 12 Feb 1997.
Content-Disposition: attachment; modification-date="Wed, 12 Feb 1997 16:29:51 -0500"
Test Results | |
---|---|
FF3 | unsupported (seems to ignore the parameter) |
MSIE8 | unsupported (seems to ignore the parameter) |
Op10 | unsupported (seems to ignore the parameter) |
Saf4 | unsupported (seems to ignore the parameter) |
Konq | unsupported (seems to ignore the parameter) |
Chrome | unsupported (seems to ignore the parameter) |
'attachment', plus modification-date (see Section 2.5 of RFC 2183)
UA should offer to download the resource. When doing so, the modification date should be set to 12 Feb 1997.
A test checking behavior for disposition type extensions, which should be treated as "attachment", see Section 2.8 of RFC 2183.
Content-Disposition: foobar
Test Results | |
---|---|
FF3 | pass |
MSIE8 | fail (does not treat it as 'attachment') |
Op10 | fail (does not treat it as 'attachment') |
Saf4 | fail (does not treat it as 'attachment') |
Konq | fail (does not treat it as 'attachment') |
Chrome | pass |
'foobar' only
This should be equivalent to using "attachment".
Various tests using the parameter value encoding defined in Section 4 of RFC 2231.
Content-Disposition: attachment; filename*=iso-8859-1''foo-%E4.html
Test Results | |
---|---|
FF3 | pass |
MSIE8 | unsupported |
Op10 | pass |
Saf4 | unsupported |
Konq | unsupported |
Chrome | unsupported |
'attachment', specifying a filename of foo-ä.html
, using RFC2231 encoded ISO-8859-1
UA should offer to download the resource as "foo-ä.html".
Content-Disposition: attachment; filename*=UTF-8''foo-%c3%a4-%e2%82%ac.html
Test Results | |
---|---|
FF3 | pass |
MSIE8 | unsupported |
Op10 | pass |
Saf4 | unsupported |
Konq | unsupported |
Chrome | unsupported |
'attachment', specifying a filename of foo-ä-€.html
, using RFC2231 encoded UTF-8
UA should offer to download the resource as "foo-ä-€.html".
Content-Disposition: attachment; filename*=''foo-%c3%a4-%e2%82%ac.html
Test Results | |
---|---|
FF3 | warn (decodes as UTF-8) |
MSIE8 | unsupported |
Op10 | warn (decodes as 8bit encoding (ISO-8859-1?)) |
Saf4 | unsupported |
Konq | unsupported |
Chrome | unsupported |
Behavior is undefined in RFC 2231, the charset part is missing, although UTF-8 was used.
Content-Disposition: attachment; filename*=UTF-8''foo-a%cc%88.html
Test Results | |
---|---|
FF3 | pass |
MSIE8 | unsupported |
Op10 | warn (displays "foo-ä.html") |
Saf4 | unsupported |
Konq | unsupported |
Chrome | unsupported |
'attachment', specifying a filename of foo-ä.html
, using RFC2231 encoded UTF-8, but
choosing the decomposed form (lowercase a plus COMBINING DIAERESIS) --
on a Windows target system, this should be translated to the preferred
Unicode normal form (composed).
UA should offer to download the resource as "foo-ä.html".
Content-Disposition: attachment; filename*=iso-8859-1''foo-%c3%a4-%e2%82%ac.html
Test Results | |
---|---|
FF3 | fail (falls back to UTF-8) |
MSIE8 | unsupported |
Op10 | warn (displays the raw octet sequence as if it was ISO-8859-1 (which is internally treated as windows-1252, which does allow %82)) |
Saf4 | unsupported |
Konq | unsupported |
Chrome | unsupported |
'attachment', specifying a filename of foo-ä-€.html
, using RFC2231 encoded UTF-8, but declaring ISO-8859-1
The octet %82 does not represent a valid ISO-8859-1 code point, so the UA should really ignore the parameter.
Content-Disposition: attachment; filename *=UTF-8''foo-%c3%a4.html
Test Results | |
---|---|
FF3 | fail (displays garbage) |
MSIE8 | unsupported |
Op10 | pass |
Saf4 | unsupported |
Konq | unsupported |
Chrome | unsupported |
'attachment', specifying a filename of foo-ä.html
, using RFC2231 encoded UTF-8, with whitespace before "*="
The parameter is invalid, thus should be ignored.
Content-Disposition: attachment; filename*= UTF-8''foo-%c3%a4.html
Test Results | |
---|---|
FF3 | pass |
MSIE8 | unsupported |
Op10 | pass |
Saf4 | unsupported |
Konq | unsupported |
Chrome | unsupported |
'attachment', specifying a filename of foo-ä.html
, using RFC2231 encoded UTF-8, with whitespace after "*="
UA should offer to download the resource as "foo-ä.html".
Content-Disposition: attachment; filename* =UTF-8''foo-%c3%a4.html
Test Results | |
---|---|
FF3 | pass |
MSIE8 | unsupported |
Op10 | pass |
Saf4 | unsupported |
Konq | unsupported |
Chrome | unsupported |
'attachment', specifying a filename of foo-ä.html
, using RFC2231 encoded UTF-8, with whitespace inside "* ="
UA should offer to download the resource as "foo-ä.html".
Content-Disposition: attachment; filename*="UTF-8''foo-%c3%a4.html"
Test Results | |
---|---|
FF3 | fail (tries to be helpful by removing the quotes) |
MSIE8 | unsupported |
Op10 | pass |
Saf4 | unsupported |
Konq | unsupported |
Chrome | unsupported |
'attachment', specifying a filename of foo-ä.html
, using RFC2231 encoded UTF-8, with double quotes
around the parameter value.
The parameter is invalid, thus should be ignored.
Content-Disposition: attachment; filename*=''foo-%c3%a4.html
Test Results | |
---|---|
FF3 | fail (sniffs the encoding as UTF-8) |
MSIE8 | unsupported |
Op10 | fail (assumes a default of ISO-8859-1) |
Saf4 | unsupported |
Konq | unsupported |
Chrome | unsupported |
'attachment', specifying a filename of foo-ä.html
, using RFC2231 encoded UTF-8, but
leaving out the charset field.
The parameter is invalid, thus should be ignored.
Various tests using the parameter value continuation efined in Section 3 of RFC 2231.
Content-Disposition: attachment; filename*0="foo."; filename*1="html"
Test Results | |
---|---|
FF3 | pass |
MSIE8 | unsupported |
Op10 | pass |
Saf4 | unsupported |
Konq | unsupported |
Chrome | unsupported |
'attachment', specifying a filename of foo.html
, using RFC2231-style parameter continuations.
UA should offer to download the resource as "foo.html".
Content-Disposition: attachment; filename*0*=UTF-8''foo-%c3%a4; filename*1=".html"
Test Results | |
---|---|
FF3 | pass |
MSIE8 | unsupported |
Op10 | pass |
Saf4 | unsupported |
Konq | unsupported |
Chrome | unsupported |
'attachment', specifying a filename of foo-ä.html
, using both RFC2231-style parameter continuations
and UTF-8 encoding.
UA should offer to download the resource as "foo-ä.html".
Content-Disposition: attachment; filename*0="foo"; filename*01="bar"
Test Results | |
---|---|
FF3 | warn (accepts leading zeros) |
MSIE8 | unsupported |
Op10 | warn (accepts leading zeros) |
Saf4 | unsupported |
Konq | unsupported |
Chrome | unsupported |
'attachment', specifying a filename of foo
(the parameter filename*01 should be ignored because of the leading zero)
UA should offer to download the resource as "foo".
Content-Disposition: attachment; filename*0="foo"; filename*2="bar"
Test Results | |
---|---|
FF3 | warn (accepts gaps) |
MSIE8 | unsupported |
Op10 | pass |
Saf4 | unsupported |
Konq | unsupported |
Chrome | unsupported |
'attachment', specifying a filename of foo
(the parameter filename*2 because there's no filename*1 parameter)
UA should offer to download the resource as "foo".
Content-Disposition: attachment; filename*1="foo."; filename*2="html"
Test Results | |
---|---|
FF3 | pass |
MSIE8 | unsupported |
Op10 | pass |
Saf4 | unsupported |
Konq | unsupported |
Chrome | unsupported |
'attachment' (the filename* parameters should be ignored because filename*0 is missing)
UA should offer to download, not getting the filename from the header.
Content-Disposition: attachment; filename*1="bar"; filename*0="foo"
Test Results | |
---|---|
FF3 | fail (parameters are expected to be ordered) |
MSIE8 | unsupported |
Op10 | pass |
Saf4 | unsupported |
Konq | unsupported |
Chrome | unsupported |
'attachment', specifying a filename of foobar
UA should offer to download the resource as "foobar".
This tests how the UA behaves when the same parameter name appear both in traditional and RFC 2231 extended format.
Content-Disposition: attachment; filename="foo-ae.html"; filename*=UTF-8''foo-%c3%a4.html
Test Results | |
---|---|
FF3 | pass (picks the traditionally encoded value -- the first of both) |
MSIE8 | pass (picks the traditionally encoded value -- the first of both) |
Op10 | pass (picks the traditionally encoded value -- the first of both) |
Saf4 | pass (picks the traditionally encoded value -- the first of both) |
Konq | pass (picks the traditionally encoded value -- the first of both) |
Chrome | pass (picks the traditionally encoded value -- the first of both) |
'attachment', specifying a filename of foo-ae.html
in
the traditional format, and foo-ä.html
in RFC2231 format.
The behaviour of this undefined. Thus UAs should one of the two values.
Content-Disposition: attachment; filename*=UTF-8''foo-%c3%a4.html; filename="foo-ae.html"
Test Results | |
---|---|
FF3 | pass (picks the RFC2231 encoded value -- the first of both) |
MSIE8 | fail (ignores the parameter (this indicates a parsing bug)) |
Op10 | pass (picks the RFC2231 encoded value -- the first of both) |
Saf4 | pass (picks the traditionally encoded value -- the one it understands) |
Konq | pass (picks the traditionally encoded value -- the one it understands) |
Chrome | fail (ignores the parameter (this indicates a parsing bug)) |
'attachment', specifying a filename of foo-ae.html
in
the traditional format, and foo-ä.html
in RFC2231 format.
The behaviour of this undefined. Thus UAs should one of the two values.
These tests RFC 2047 style encoding.
Note that according to Section 5 of RFC 2047,
this encoding does not apply here: An 'encoded-word' MUST NOT appear within a 'quoted-string'.
, and
An 'encoded-word' MUST NOT be used in parameter of a MIME
Content-Type or Content-Disposition field, or in any structured
field body except within a 'comment' or 'phrase'.
Therefore, these tests are only be present in order to check whether the UA by mistake tries to implement RFC2047.
Content-Disposition: attachment; filename==?ISO-8859-1?Q?foo-=E4.html?=
Test Results | |
---|---|
FF3 | fail (decodes it anyway to "foo-ä.html") |
MSIE8 | pass (takes the whole value as filename, but does not decode it (replacing question marks by underscores)) |
Op10 | fail (displays garbage ("=.htm")) |
Saf4 | pass (takes the whole value as filename, but does not decode it (replacing question marks by underscores)) |
Konq | fail (decodes it anyway to "foo-ä.html") |
Chrome | fail (decodes it anyway to "foo-ä.html") |
Uses RFC 2047 style encoded word. "=" is invalid inside the token
production, so this is invalid.
Content-Disposition: attachment; filename="=?ISO-8859-1?Q?foo-=E4.html?="
Test Results | |
---|---|
FF3 | fail (decodes it anyway to "foo-ä.html") |
MSIE8 | pass (takes the whole value as filename, but does not decode it) |
Op10 | fail (displays garbage ("=.htm")) |
Saf4 | pass (takes the whole value as filename, but does not decode it) |
Konq | fail (decodes it anyway to "foo-ä.html") |
Chrome | fail (decodes it anyway to "foo-ä.html") |
Uses RFC 2047 style encoded word, using the quoted-string
production.