Details
-
Type:
Bug
-
Status: Closed
-
Priority:
Major
-
Resolution: Won't Fix
-
Affects Version/s: 4.0.BETA
-
Fix Version/s: None
-
Component/s: ACE-Components, Sample Apps
-
Labels:None
-
Environment:ICEfaces4 trunk rev# 40075/ 40089
App server: wildfly-8.0.0.Final (JBoss 8.0) @ Windows7
Browsers: Firefox27
Testing used the app server stock JSF.
-
Workaround Exists:Yes
-
Workaround Description:It would likely be possible to write a filter that would find filenames in the upload and decode the bytes, as an application-level workaround.
Description
> Overview: on this showcase demo - files don't appear to be uploaded on the server, although the message rendered on page confirms successful uploads.
On tomcat7, the files are uploaded from this demo in a directory /files/[session name], like this:
C:\Servers\apache-tomcat-7.0.27\temp\0-showcase\files\48CB4A19796D98841EC534E5EA917139.
> Overview/Validation/Callback: when uploading files with names containing special unicode characters, the confirmation message fails to render properly the file name on page, as example when uploading äöü€.txt, the characters are rendered as in attached screen shot; this is also an issue if using the QA fileEntry test application (http://dev.icesoft.com/svn/repo/qa/trunk/Regression-Icefaces4/Sparkle/Nightly/fileEntry) on WildFly/JBoss8.0.
Deryk:
I was able to see the files uploaded - just to an odd location. On my Mac they were located at ./wildfly-8.0.0.Final/bin/null/1DE2666E626C639233B821E2B7B160CA. Confirming Carmen’s observation about the characters. The files are saved in the same location as noted above and the characters have already been ‘changed' so the conversion occurs before or during saving of the files and the rendered display is simply reflecting this.
Activity
- All
- Comments
- History
- Activity
- Remote Attachments
- Subversion
Running WildFly with
bin/standalone.sh -b 0.0.0.0
from .war built with
ant web-profile
Verified that ICEmobile camera upload is working.
Verified that files with ascii filenames can be uploaded successfully.
Uploaded files are also found (for example, in the listener demo) here:
wildfly-8.0.0.Final/standalone/tmp/vfs/temp/tempa3d06f12ada1c86/showcase.war-e668b022f2bf7f5d/bWKGBQ3yvHASnsPIU9iOZTH4/ice_file_1876708291977589702.tmp
The file name appears to be incorrectly reported in the demo, but that may be an issue with the character set of the containing page.
This is a WildFly "bug". When the uploaded MIME part is decoded the header contains the unexpected characters, likely due to the character set used to decode the header:
part.getHeader("content-disposition")
There is no standard behaviour specified for this, as this stackoverflow discussion shows:
It is possible that JBoss would be willing to modify WildFly to conform to tomcat behaviour, since accepting a unicode header is not unusual.
May be related to this issue:
https://issues.jboss.org/browse/WFLY-2531
https://issues.jboss.org/browse/WFLY-2533
However adding jboss-web.xml containing the following does not appear to have an effect:
<jboss-web version="8.0" xmlns="http://www.jboss.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.jboss.org/j2ee/schema/jboss-web_8_0.xsd" >
<default-encoding>UTF-8</default-encoding>
</jboss-web>
Comment was added to WFLY-2533 requesting clarification on whether the above configuration should resolve this.
This issue may or may not relate to an earlier one with similar symptoms of the file-name localization being incorrect on linux:
IPCK-461