File upload is broken with IE 11 and Edge: Backslashes in Content-Disposition filename

[jsimomaa]

Copied from https://java.net/jira/browse/JERSEY-3159

IE11 and Microsoft Edge both still send non-standard conforming filename:

-----------------------------7db13314200d0
Content-Disposition: form-data; name="file"; filename="C:\tmp\test.txt"
Content-Type: application/octet-stream

What my application gets when reading the filename is "C:tmptest.txt" This could be fixed like the original issue by matching the User-Agent by adding matching for "Trident/" and "Edge/"

[sutherlandpb]

Any word on this pull request? It has been a year and Jersey still does not support filenames for uploads in Edge or IE 11 (This is a work-around for quirky behavior in IE, I understand that, but if you work around it in IE6-10, you have to work around it in IE11 and Edge too.)

[amdonov]

This is a big issue for us too.

[sutherlandpb]

We just forked, which is a crap solution, but it takes about 5 minutes to fix this issue and recompile. The other option is to rewrite your file processing in the js/html side to avoid it. My dumb fork is published on my profile

[llech]

I've found a discussion where the author of the bug reveals himself and acknowledges reusing the code used to parse HTTP Headers: http://jersey.576304.n2.nabble.com/Jersey-truncating-the-slashes-from-the-uploaded-file-name-td5984041.html

What is very sad, he doesn't acknowledge the bug, but blames IE for 'not adhering to standards', although cited RFC 2616 acknowledges Content-Disposition as being non-standard. Even if it were so, such attitude is childish. IE doesn't adhere to many actual standards, and the good developers has learned to adapt to them. We can't say our clients that they should not use IE because it doesn't adhere to RFC 2616 rules of encoding Content-Disposition!

Code reuse is good, but only when it makes sense. The workaround for old IE is ugly, and it depends on the volatile User-Agent string. However, the pull request would extend it for IE 11 and Edge.

As for now, we work with forked and fixed code. But we consider switching frameworks and staying away from Jersey in future.

[llech]

One important note: this patch does not fix a bug. It is not even a workaround for the bug. It is a workaround for a single manifestation of the bug.

The real bug is in parsing of Content-Disposition headers, which is fully false. Try uploading file with non-ASCII characters. Modern browsers send them as UTF-8, the parsing method expects... ASCII. I wasn't able to locate the place where the false assumption is made within reasonable time and I was able to make client-side workaroud, but it's surprising this bug hasn't been noticed, as if the library wasn't reasonably tested at all.

[chrisregnier]

I just ran into this as well and it's frustrating to see a fix sit here for so long with no word on things. Even if this is a bandaid and only a fix for a single case, I think this is common enough scenario that warrants that the old fix be updated to work with newer browsers.

Is there at least another issue for properly fixing parsing of Content-Disposition headers in utf-8? I could only find https://github.com/jersey/jersey/issues/3457 which doesn't seem to have any further discussion on either. Also the issue for this PR https://github.com/jersey/jersey/issues/3431, and https://github.com/jersey/jersey/issues/3316

And can someone please merged this in the meantime?