Date: Mon, 10 Dec 2012 02:09:41 +0100 Subject: WARNING COMMIT --> FIRST REKONQ 2 IMPORT Preparing repo to merge rekonq2 code... --- src/tests/html/HTTP_tests.html | 601 ----------------------------------------- 1 file changed, 601 deletions(-) delete mode 100644 src/tests/html/HTTP_tests.html (limited to 'src/tests/html/HTTP_tests.html') diff --git a/src/tests/html/HTTP_tests.html b/src/tests/html/HTTP_tests.html deleted file mode 100644 index 7a5ac00d..00000000 --- a/src/tests/html/HTTP_tests.html +++ /dev/null @@ -1,601 +0,0 @@ - - - - -Test Cases for HTTP Content-Disposition header and RFC 2231/2047 Encoding - - - - - - - -

Test Cases for HTTP Content-Disposition header and RFC 2231/2047 Encoding

- - -

Test Cases

Content-Disposition: Disposition-Type Inline

- Various tests relating to the "inline" disposition type, see - Section 2.1 of RFC 2183. -

inlonly - [TEST] -

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.

inlwithasciifilename - [TEST] -

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

inlwithasciifilenamepdf - [TEST] -

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

Content-Disposition: Disposition-Type Attachment

- Various tests relating to the "attchment" disposition type, see - Section 2.2 of RFC 2183. -

attonly - [TEST] -

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.

attonlyucase - [TEST] -

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.

attwithasciifilename - [TEST] -

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

attwithasciifnescapedchar - [TEST] -

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

attwithfilenameandextparam - [TEST] -

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

attwithasciifilenameucase - [TEST] -

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

attwithasciifilenamenq - [TEST] -

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.

attwithisofnplain - [TEST] -

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

attwithutf8fnplain - [TEST] -

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.

attwithfnrawpctenca - [TEST] -

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

attwithfnrawpctenclong - [TEST] -

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

attwithasciifilenamews1 - [TEST] -

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

attwithasciifilenamews2 - [TEST] -

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

attfnbrokentoken - [TEST] -

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.

Content-Disposition: Additional Parameters

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

attcdate - [TEST] -

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.

attmdate - [TEST] -

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.

Content-Disposition: Disposition-Type Extension

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

dispext - [TEST] -

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

RFC2231 Encoding: Character Sets

- Various tests using the parameter value encoding defined - in Section 4 of RFC 2231. -

attwithisofn2231iso - [TEST] -

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

attwithfn2231utf8 - [TEST] -

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

attwithfn2231noc - [TEST] -

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

attwithfn2231utf8comp - [TEST] -

Content-Disposition: attachment; filename*=UTF-8''foo-a%cc%88.html

- Test Results -
FF3	pass
MSIE8	unsupported
Op10	warn - (displays "foo-ä.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". -

attwithfn2231utf8-bad - [TEST] -

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

attwithfn2231ws1 - [TEST] -

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

attwithfn2231ws2 - [TEST] -

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

attwithfn2231ws3 - [TEST] -

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

attwithfn2231quot - [TEST] -

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

attwithfn2231encmissing - [TEST] -

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

RFC2231 Encoding: Continuations

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

attfncont - [TEST] -

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

attfncontenc - [TEST] -

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

attfncontlz - [TEST] -

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

attfncontnc - [TEST] -

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

attfnconts1 - [TEST] -

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

attfncontord - [TEST] -

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

RFC2231 Encoding: Fallback Behaviour

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

attfnboth - [TEST] -

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

attfnboth2 - [TEST] -

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

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

attrfc2047token - [TEST] -

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

attrfc2047quoted - [TEST] -

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

- \ No newline at end of file -- cgit v1.2.1