Windows store app and non-ascii filename uploads

Question

I'm trying to upload a file to an Apache server with a Windows Store App. Ascii file names work fine, but any other foreign characters will not work, Apache is throwing a 400.

The files are being uploaded the standard Windows store way with Windows.Networking.BackgroundTransfer.BackgroundUploader, and then creating a BackgroundTransferContentPart from the file.

   var uploader = new Windows.Networking.BackgroundTransfer.BackgroundUploader();
   var part = new Windows.Networking.BackgroundTransfer.BackgroundTransferContentPart('file',  file.name);
   part.setFile(file);
   var parts = [ part ];
   uploader.createUploadAsync(url, parts).then(callback)

Doing an upload in javascript with an ajax request works fine with non-ascii filenames. Has anyone encountered this in the windows apps?

Answer 1

I got fiddler working and here is part of the body of the request:

Content-Disposition: form-data; name="file"; filename*=utf-8''%C3%BCf.txt

It's sending a malformed request so thats why apache rejects it. The "filename" part is malformed, it should just be something like filename="üf.txt"

Answer 2

That filename part isn't obviously malformed: the UTF-8 encoding for LATIN SMALL LETTER U WITH DIAERESIS (ü) is 0xC3 0xBC.  I'm not familiar enough with this to know if it's less obviously malformed elsewhere.

That said, a few searches suggest that the specific formatting for passing UTF-8 in Content-Disposition is unclear and inconsistent. The RFC 2231 encoding sent here looks common, and I found reference that sounds like Apache has supported it for several years.

What does the working ajax request look like in fiddler?

--Rob

Answer 3

A working request looks like:

Content-Disposition; name="file"; filename="test.txt"

Similarly, with chrome if I upload a file using formdata:

Content-Disposition; name="file"; filename="你好.txt"

Answer 4

RFC 6266 covers this in detail (see sections 4.3 and Appendix D). The filename* parameter is correctly formed, but requires that the server agent implement RFC 5987. Including non-ASCII in the filename parameter is non-compliant (not to say that it isn't being done by certain browsers). The correct solution would be to include the filename parameter with an approximation of the non-ASCII filename as a fallback (e.g., filename=uf.txt). However, that requires a change in the BackgroundTransfer API implementation. Another option would be to work with a server implementation that supports RFC 5987.

---

This posting is provided "AS IS" with no warranties, and confers no rights.

Answer 5

Thanks, that makes sense now.  It seems there's actually a bug in our backend then