locked
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?


    • Edited by Bobenheimer Friday, January 03, 2014 12:13 AM
    Friday, January 03, 2014 12:13 AM

Answers

  • 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.

    Friday, January 03, 2014 10:07 PM

All replies

  • 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"

    Friday, January 03, 2014 7:50 PM
  • 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

    Friday, January 03, 2014 8:47 PM
    Owner
  • 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"



    • Edited by Bobenheimer Friday, January 03, 2014 8:55 PM
    Friday, January 03, 2014 8:54 PM
  • 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.

    Friday, January 03, 2014 10:07 PM
  • Thanks, that makes sense now.  It seems there's actually a bug in our backend then
    Monday, January 06, 2014 7:10 PM