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

Re: Working Group Last Call: draft-ietf-httpbis-content-disp-02

From: Julian Reschke <julian.reschke@gmx.de>
Date: Sat, 02 Oct 2010 21:54:47 +0200
Message-ID: <4CA78E07.6040509@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. 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. 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.

That being said: thanks for the additional test cases; I'll add those 
over the weekend.

>> We should either add enough detail to the document to allow for user
>> agent implementations or clarify that this document is intended to
>> apply only to servers.
>
> That would be missing the point. The point of a profile specification is
> that if a sender sends out something that conforms to the profile, then
> recepients will process it in a manner conforming to the specification.

Yes. We need only one valid way to do things.

Best regards, Julian
Received on Saturday, 2 October 2010 21:42:11 GMT

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