** Observed with 2/23/2000 Win32 build ** This problem was recently reported for Communicator 4.7. I found this to be also a problem currently for Mozilla. In a nutshell, when we have a form file upload page in EUC-JP (HTTP-Equiv or HTTP-charset or menu setting to EUC-JP), somehow file uploads fail if file or path names contain Shift_JIS characters. When you change the page charset to Shift_JIS, the content of a file gets uploaded. Otherwise, empty content gets uploaded. This is known in the SCOPUS Bug #384681. Mozilla is currently suffering from the same problem. Perhaps this is already on someone's agenda. Let's hope so. I have an inetrnal test case on my server but it requires an additional explanation. Anyone assigned to work on this can contact me for futher info on how to work the test case.

For detailed explanation of this problem, see the SCOPUS bug. It contains live example URLs.

I've corrected the summary line because as I mentioned in the original bug for 4.7x, the problem occurs when the system's file charset (e.g. Shift_JIS for JPN windows) does not match the charset of the form you're using. It does not have to be an EUC-JP form to reproduce this problem. Just any form which does not have the same charset as the JPN system charset for the platform you're using. But this kind of prblem occurs typically in Japanese because 3 different charsets are used in web Japanese web pages.

rename the summary to file upload does not work if file path contains character encoded different than the docuemnt charset When I said "does not work" I mean it looks like upload the file but the upload content is empty Here is the cause, before we post, we convert the value of the form field from unicode into the "document charset" . However, the following lines of code also use the converted result to open the file. This is wrong because the file system charset may not the same as the document charset of the form page. In layout/html/form/src/nsFormFrame.cpp if (NS_FORM_INPUT_FILE == type) { nsIFileSpec* contentFile = nsnull; rv = NS_NewFileSpec(&contentFile); NS_ASSERTION(contentFile, "Post content file couldn't be created!"); if (NS_FAILED(rv) || !contentFile) break; // NS_ERROR_OUT_OF_MEMORY rv = contentFile->SetNativePath(value); Notice the value is already convert to encoding other than the file system encoding. What we should do is use values[valueX] (nsString) and convert it to the file system charset by using nsIUnicodeEncoder. You need to get a seperate unicode encoder by calling nsIPlatformCharset(kPlatformCharset_FileName) for the purpose of converting file name.

jbetak- I think you can help to fix this bug. I know where is the problem and can tell you how to fix it tomorrow.

(ftang using jbetak account) pollmann- jbetak is trying to fix this bug. We need your code review and apporval after he have the fix.

I'm happy to code review anything, just send me a file or diff, thanks!

Please use the modified upload form on http://kaze:8000/formuploadecho.html for verification. You will only see an transmission echo, the file will not be saved on the server...

tentatively closing, I was not able to verify the fix. This might require a Japanese Win installation, per conversation with Momoi-san, the previous analysis of the problem might have been incomplete or partially wrong.

I review the code jbetak check in. There are some problem with memory leak and the conversion of the "file name" itself. Reopen this so jbetak can work on it again.

Reopened, but not an M15 stopper. Moved to M16.

This should be "won't fix" On RFC18xx, Content-Disposition header is defined, but charactor-set isn't defined. So this should leave to filesystem encoding of client OS... If you work this issue, we should create new RFC or ieft-draft about charactor- set of Content-Disposition...

Sorry, RFC1806 The Content-Disposition Header

Frank, thanks for pointing out the problems and helping to fix it! m_kato, I looked up the RFC, but I'm not sure if this problem really relates to it. We are fixing some problems in the client that are specific to fetching the file from the OS file system. It does not affect the way Mozilla transmits them over the wire... I can't really comment if the transmission part is standards-compliant, but I would think it is. This bug deals with the issue that we encode the local file names into the form charset for transmission and then internally "forget" the proper platform encoding and fail to fetch the file content for transmission...

I verified this in 2000042709 Win32 and Linux, and 2000042710 Mac build.