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