W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2011

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

From: Ben Niven-Jenkins <ben@niven-jenkins.co.uk>
Date: Fri, 4 Feb 2011 10:40:00 +0000
Cc: Mark Nottingham <mnot@mnot.net>, Adam Barth <ietf@adambarth.com>, httpbis <ietf-http-wg@w3.org>
Message-Id: <EB0EBBB0-7570-4D63-B5D7-20F5BC27BE40@niven-jenkins.co.uk>
To: Julian Reschke <julian.reschke@gmx.de>

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


Firefox 3.6.13 => _foo.html
Chrome 9.0.597.84 => foo.html
Safari 5.0.3 (6533.19.4) => -foo.html


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

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

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:56 UTC