Try the latest CVS snapshot from http://snaps.php.net/ as rfc1867.c has been rewritten in it and should fix this problem too.
--Jani On Mon, 12 Nov 2001, Duncan Gibb wrote: >Hello > >First let me apologise in case I've raised this question in the wrong >place. It seemed too difficult for the general users mailing list but >not a big enough issue to file a bug report. > >In main/rfc1867.c, the function php_mime_split() deliberately truncates >the filename string containing the client-side name of an uploaded file, >preserving only the portion right of the rightmost backslash. This >means the application script won't see the client-side filename as >passed by the browser. > >I think I know why this has been done (because IE stupidly passes the >complete client-side path, rather than just the file _name_), but IMVHO >it is a mis-feature to impose an MS-DOS/Windows filename restriction on >the server side (\ is valid in filenames on Mac and Unix). What do you >folks think about this? Was it imposed for another reason? > > >The reason I came upon this is I am looking at porting an existing ASP >(spit) application which includes a file storage area. One of the >problems we have with the ASP/WinNT system is that it doesn't deal well >with client-side filenames. We want to preserve but platform-proof >filenames. So we need to get our hands on the whole filename and then >replace dangerous characters like \ with less dangerous ones. > >Is there another way to retreive the string as passed by the browser, or >do I need to comment out a few lines and re-compile? > > >Also (OT, sorry), does anyone happen to know how IE for Mac behaves? >Does it pass the full path of uploaded file (with colons?) or just the >filename? Or some other random Microsoft junk? > > >Thanks > > >Duncan > > > -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
