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

On 03.10.2010 20:15, Adam Barth wrote:
> On Sun, Oct 3, 2010 at 7:01 AM, Julian Reschke<julian.reschke@gmx.de>  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.

But we won't make it say that (as it breaks existing implementations) 
unless we have to.

Do we have to, despite we see that 4 out of 6 UAs tested do *not* do this?

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

Again, 4 out of 6 browser implementations do not do this. So I simply do 
not buy the "but we have to" argument.

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

Changing the spec to allow percent to be an escape character would break 
other existing implementations.

We can *warn* producers from relying on it, but the alternative (using 
the RFC 5987 encoding) will only work when IE/Chrome/Safari adopt it.

>>> 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
>> (<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-content-disp-02.html#rfc.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.

There's nothing exact to standardize right now, and it also depends on 
the limitations of the OS the UA runs on. From that point of view, 
requiring something specific seems to be the wrong approach.

That being said: if you have more potential things to consider in that 
part, please report them. I'm pretty sure there could be more than those 
I mentioned.

Best regards, Julian

Received on Sunday, 3 October 2010 18:54:04 UTC