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 BenReceived on Friday, 4 February 2011 10:40:32 GMT
This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:36 GMT