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

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

http://greenbytes.de/tech/tc2231/#attabspathwin

Firefox => \foo.html
Chrome => \\foo.html
Safari => \\foo.html

HTH
Ben

Received on Friday, 4 February 2011 10:40:32 UTC