Hi. Sorry for not thinking to check there first. AFAICS, the same
methodology is still being applied. Looking at php4-200111130900,
main/rfc1867 lines 762 to 767:
-8<-----------------------------------------------------------
s = strrchr(filename, '\\');
if (s && s > filename) {
safe_php_register_variable(lbuf, s+1, NULL, 0 TSRMLS_CC);
} else {
safe_php_register_variable(lbuf, filename, NULL, 0 TSRMLS_CC);
}
-8<-----------------------------------------------------------
The effect of this is to truncate whatever the browser passed as
filename="client-side-name-string" at the rightmost backslash. This
causes a problem for my application where the client is Unix or Mac, on
which platforms the filename may legally contain a \ character. For
example where the browser passes:
Content-Disposition: form-data; name="userfile"; filename="stupid\user"
the application script will be interpreted with $userfile_name set to
'user', when it should, IMHO be 'stupid\user'.
There is a similar problem where the filename contains a double quote.
The browser will send a mime header like:
Content-Disposition: form-data; name="userfile"; filename="stupid"user"
and the application script will think the file was named 'stupid'.
Thanks, and sorry to be awkward.
Duncan
+--
Jani Taskinen wrote:
JT> Try the latest CVS snapshot from http://snaps.php.net/
JT> as rfc1867.c has been rewritten in it and should fix this
JT> problem too.
>> 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.
--
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]
