yip.ng added a comment - 19/Nov/12 10:25 PM - edited The changes for ICE-4342 (1.8) are not in 3.2. The two branches have diverged too much now (many differences in OutputResource class; ResourceDispatcher class has even disappeared.) Even just porting the changes may not straight forward.

Deryk Sinotte added a comment - 21/Nov/12 6:50 PM - edited I used the ice:outputResource - Filename Example to test. The mixup appears= to be in the key used for storing and retrieving the resources from the Se= ssionBasedResourceDispatcher. In a scenario where no special characters ar= e involved, the initial resource is stored like this: DynamicResourceDispatcher$SessionBasedResourceDispatcher.registerReso= urce:=20 file name : Custom-Name.pdf dispatch file name: \u0043\u0075\u0073\u0074\u006F\u006D\u002D\u004E\u006= 1\u006D\u0065\u002E\u0070\u0064\u0066 uri file name : Custom-Name.pdf name : /icefaces/resource/LTE2MTUwODUwMTM=3D/ full name (key) : /icefaces/resource/LTE2MTUwODUwMTM=3D/Custom-Name.pdf= The last entry (full name) is the key used to store the mapping for the res= ource where "mappings" is a HashMap of SessionBasedResourceDispatcher. When= the link is clicked, resource handling is done inside the SessionBasedReso= urceDispatcher.handleResourceRequest() method and it tries to look up the m= apping: DynamicResourceDispatcher$SessionBasedResourceDispatcher.handleResour= ceRequest:=20 looking for =20 /icefaces/resource/LTE2MTUwODUwMTM=3D/Custom-Name.pdf in=20 {/icefaces/resource/LTE2MTUwODUwMTM=3D/Custom-Name.pdf=3Dorg.icefaces.impl.= push.DynamicResourceDispatcher$Mapping@e4541bd, /icefaces/resource/MTI1Mjkx= NTcxMA=3D=3D/Download_PDF=3Dorg.icefaces.impl.push.DynamicResourceDispatche= r$Mapping@64dee69c} Which all works fine and dandy for the regular use case. Doing the same th= ing but adding some special characters to the file name: DynamicResourceDispatcher$SessionBasedResourceDispatcher.registerReso= urce:=20 file name : Custom-Name-??o?.pdf dispatch file name: \u0043\u0075\u0073\u0074\u006F\u006D\u002D\u004E\u006= 1\u006D\u0065\u002D\u00E9\u00F8\u006F\u00E5\u002E\u0070\u0064\u0066 uri file name : Custom-Name-%C3%A9%C3%B8o%C3%A5.pdf name : /icefaces/resource/LTE2MTUwODUwMTM=3D/ full name (key) : /icefaces/resource/LTE2MTUwODUwMTM=3D/Custom-Name-%C3= %A9%C3%B8o%C3%A5.pdf You can see that the special characters get encoded to what will be submitt= ed by the link: http://localhost:8080/showcase/icefaces/resource/LTE2MTUwODUwMTM=3D/Custom-= Name-%C3%A9%C3%B8o%C3%A5.pdf But when it hits the SessionBasedResourceDispatcher to do the lookup, the k= ey does not match anything so it fails: DynamicResourceDispatcher$SessionBasedResourceDispatcher.handleResour= ceRequest:=20 looking for =20 /icefaces/resource/LTE2MTUwODUwMTM=3D/Custom-Name-=CC=A9??o=CC=B4.pdf=20 in=20 {/icefaces/resource/LTE2MTUwODUwMTM=3D/Custom-Name.pdf=3Dorg.icefaces.impl.= push.DynamicResourceDispatcher$Mapping@e4541bd, /icefaces/resource/MTI1Mjkx= NTcxMA=3D=3D/Download_PDF=3Dorg.icefaces.impl.push.DynamicResourceDispatche= r$Mapping@64dee69c, /icefaces/resource/LTE2MTUwODUwMTM=3D/Custom-Name-%C3%A= 9.pdf=3Dorg.icefaces.impl.push.DynamicResourceDispatcher$Mapping@44d4df3f, = /icefaces/resource/LTE2MTUwODUwMTM=3D/Custom-Name-%C3%A9%C3%B8o%C3%A5.pdf= =3Dorg.icefaces.impl.push.DynamicResourceDispatcher$Mapping@3f9b4e74} =20

yip.ng added a comment - 04/Dec/12 5:09 PM - edited Nothing wrong with output resource component. The problems are all in the core resource dispatcher. The key isn't used in the look-up at all. The whole map is iterated through and some regular expression is used in the mapping. (Then why used a key at all? Might as well have used an array-like data structure?) Three problems when redoing resource dispatcher from ICEfaces 1.8: getRequestPathInfo() returns gibberish with unicode URL, should have used getRequestURI() as in 1.8. URLDecoder.decode required. Not required in 1.8, even with unicode URL. Something must have changed in the URL storage/mapping in ICEfaces 3. bug introduced when copying/modifying/rearranging code from 1.8: Content-Disposition HTTP header always set to null. All fixed. See under the Subversion tab of this JIRA for check-in details.