treating invalid parameters in Content-Disposition

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


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


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-


> 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 

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

> ...

Best regards, Julian

Received on Sunday, 3 October 2010 14:12:02 UTC