W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2010

treating invalid parameters in Content-Disposition

From: Julian Reschke <julian.reschke@gmx.de>
Date: Sun, 03 Oct 2010 15:44:35 +0200
Message-ID: <4CA888C3.8040908@gmx.de>
To: Bjoern Hoehrmann <derhoermi@gmx.net>
CC: Adam Barth <w3c@adambarth.com>, Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>
On 02.10.2010 21:46, Bjoern Hoehrmann wrote:
> * Adam Barth wrote:
>> This document appears to be insufficiently precise for user agents to
>> implement Content-Disposition.  In particular, it does not
>> disambiguate what filename a user agent should use if multiple
>> filename attributes are present.  The grammar will fail to parse a
>> large number of Content-Disposition headers user agents receive on the
>> public Internet, etc.  The document says:
>
> The parameters are advisory only; the draft defines that `filename*`
> gives better advice than `filename`; there is little need to specify
> something beyond that. As for content that falls outside the profile
> here, browsers don't really agree on much. For instance,
>
>    Content-Disposition: inline; attachment; filename=example.txt
>
> that's "inline" in Opera and Firefox, but "attachment" in IE6...

<http://greenbytes.de/tech/tc2231/#attandinline>

(IE8 behaves as IE6, Chrome and Safari behave like Opera and Firefox).

> ... Something
> that actually occurs practise is unquoted spaces,
>
>    Content-Disposition: attachment; filename=ex ample.txt
>
> That's "ex" in Firefox, but "ex ample.txt" in Opera and IE6....

<http://greenbytes.de/tech/tc2231/#attwithasciifilenamenqws>

IE8, Safari and Chrome are like Opera/IE6.

> ... Malformed
>
>    Content-Disposition: attachment;filename="example.txt".txt
>
> is rejected as malformed by IE6 which then makes up its own name, but
> it ends up as "example.txt" in Firefox and Opera. If we take the in-

<http://greenbytes.de/tech/tc2231/#attbrokenquotedfn>

> tersection of what works in all major browsers and what actually occurs
> in practise where it is more than a slight inconvenience for the user
> if the header is ignored alltogether, we won't end up with something
> that's noticably different than what's in the draft.

Exactly. I don't see any interop for malformed headers right now. 
There's nothing to be standardized, and also, nothing that *needs* to be 
standardized.

I'm much more interested in achieving interoperability for *valid* 
header fields.

> ...

Best regards, Julian
Received on Sunday, 3 October 2010 14:12:02 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:27 GMT