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

On Sun, Oct 3, 2010 at 7:01 AM, Julian Reschke <> wrote:
> On 03.10.2010 02:23, Adam Barth wrote:
>> 2) It looks like the user agent is supposed to URL-decode the filename:
>> Content-Disposition: inline; filename="abc%20de.pdf"
>> =>  abc de.pdf
> Well, it's not supposed to from a standards point of view, nor from an
> interop point of view.

Well, we're writing the standards, so we can make them say whatever we want.

>> Appendix C.4 seems to indicate that that this is implemented by IE and
>> Chrome.  From the comments in the file referenced above, it seems this
>> is important for the Asian market.  Both according to Appendix C.2 and
>> the comments in the file referenced above, it looks like the encoding
>> for the unescaped is supposed to be based on the current code page,
>> which admitted sucks.
> It sucks totally, because it's impossible to be used in practice for an
> international audience.

Yes.  I agree that servers shouldn't generate %-encoded
Content-Disposition headers.  However, that doesn't mean it isn't in
the user agent's best interested to consume them if the user agent
receives one.

> The support in Chrome (which I complained about the day it came out, see
> <>) might be
> well-intentioned, but will not always work as intended:

I would have responded on that bug exactly the way Jungshik Shin did.
WONTFIX.  That's the incentives user agent implementors face.

> long before Chrome
> and Safari where available, server implementers had to choose between the IE
> "encoding" and the RFC2231-encoding (supported by Firefox and Opera), and at
> least in some cases, the IE encoding would only be sent based on the
> User-Agent string (believe me, I had to write one of these).

Yes.  It's not a useful feature for server operators.  However, there
appear to be a number of servers in the Asian market that emit these
headers.  If a browser wishes to be used by folks in the Asian market,
the browser is incentivized to support this behavior.

> Remember --
> until two years ago, only IE supported this broken encoding; thus Chrome
> made the situation worse by copying IE's broken behavior, instead of
> Firefox' and Opera's.

That's a value judgment.

>> Again, the optimal generative grammar is probably to avoid this mess.
>> However, it seems entirely likely the optimal consumption grammar is
>> to do something with percent-encoded inputs, especially if you care
>> about pleasing customers in the Asian market.
> If you really care about pleasing Asian customers, please convince more UA
> implementers to support the standardized encoding, which does not depend on
> the client's locale, and also does not conflict with other legitimate uses
> of the filename parameter.

I have nothing against supporting filename*.  What I object to is
having the spec ban a behavior that user agent implementors are going
to keep.

>> 3) Apparently whitespace in the filename are supposed to be converted to
>> spaces:
>> Content-Disposition: inline; filename="abc<TAB><NEWLINE>de.pdf"
>> =>  abc    de.pdf
> I would consider this as part of post-processing something as filename, not
> the actual parsing. There are more things to worry about (stripping path
> separators, making things relative, avoiding trailing and leading
> whitespace, assigning a sane extension, and so on).
> This is covered at the end of Section 3.3
> (<>),
> but I would be surprised if there wasn't more that should be mentioned.

That's fine, as far as it goes.  A more informative spec would explain
exactly what transformations user agents should or should not do.


Received on Sunday, 3 October 2010 18:46:13 UTC