Re: \-decoding filename parameters [general issue now #270]

On 04.02.2011 11:40, Ben Niven-Jenkins wrote:
>
> On 4 Feb 2011, at 08:17, Julian Reschke wrote:
>> On 04.02.2011 06:01, Mark Nottingham wrote:
>>>
>>> On 04/02/2011, at 5:52 AM, Julian Reschke wrote:
>>>> Sending a filename with a literal backslash character in it is likely an attempt by the sender to trick the recipient to overwrite files in another directory. The spec already recommends:
>>>>
>>>> "When the value contains path separator characters, all but the last segment SHOULD be ignored. This prevents unintentional overwriting of well-known file system location (such as "/etc/passwd")." --<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-content-disp-04.html#rfc.section.3.3>
>>>>
>>>> So it really doesn't matter a lot at what stage the \ disappears.
>>>
>>> Your argument assumes that \ is recognised as a path separator; on some platforms, it's not.
>>
>> I'm not talking about OS behavior but UA behavior. For the purpose of Content-Disposition/filename, I would *hope* that UAs treat \ and / the same. My tests are<http://greenbytes.de/tech/tc2231/#attabspath>  and<http://greenbytes.de/tech/tc2231/#attabspathwin>  and my results reflect the Windows versions of UAs; it would be nice if somebody could try whether Safari/Chrome/Opera behave differently on MacOS...
>
> Under Mac OS X 10.6.5
>
> http://greenbytes.de/tech/tc2231/#attabspath
>
> Firefox 3.6.13 =>  _foo.html
> Chrome 9.0.597.84 =>  foo.html
> Safari 5.0.3 (6533.19.4) =>  -foo.html

That's consistent with the Windows versions.

> http://greenbytes.de/tech/tc2231/#attabspathwin
>
> Firefox =>  \foo.html
> Chrome =>  \\foo.html
> Safari =>  \\foo.html

But this is not; apparently those UAs consider "\" a legitimate 
character in a filename.

I believe that's a very bad idea.

Best regards, Julian

Received on Friday, 4 February 2011 11:14:21 UTC