Utf 8 % encoding for redirection target

[GoogleCodeExporter]

What steps will reproduce the problem?
   <rewrite match="^/virtual$" url="/virtuální"
redirect="301" />

 <rewrite match="^/virtualencoded$" url="/virtu%C3%A1ln%C3%AD"
redirect="301" />

What is the expected output? What do you see instead?
The fisrt rule makes redirection to virtu%E1ln%ED, which uses iso-latin 
encoding.

I would expext to make redirection to utf encoded string, because I use utf-8 
encoding for whole configuration file.

What version of PrettyFaces are you using? On what server and version,
version of JSF, and other relevant technologies?
3.1.0 over JSF2 mojarra, tomcat with enabled URIEncoding="UTF-8"

---------------------------
BTW: I noticed one more thing that can be confusing from the first sight, but I 
consider it as correct:

<rewrite match="^/přesměruj$" url="/presmeruj"
redirect="301" />

<rewrite match="^/p%C5%99esm%C4%9Brujencoded$" url="/presmeruj"
redirect="301" />

Expexted: Both variants performs redirection to /presmeruj
I see: The first redirection is OK, the second is not taken into account.

After a while I reconsidered this be a correct behaviour, because match 
atribute is filled with REGEXP. Maybe some note in doc should be helpfull for 
others.

Original issue reported on code.google.com by jamaja...@gmail.com on 18 Nov 2010 at 2:04

[GoogleCodeExporter]

Verified.

Original comment by lincolnb...@gmail.com on 9 Dec 2010 at 3:28

[GoogleCodeExporter]

Which container are you using? By the way.

Original comment by lincolnb...@gmail.com on 13 Dec 2010 at 5:49

[GoogleCodeExporter]

Apache Tomcat/6.0.16 with enabled URIEncoding="UTF-8

Original comment by jamaja...@gmail.com on 19 Dec 2010 at 8:43

[GoogleCodeExporter]

So I think that what you said is correct, this is intended behavior. The 
rewrite rules should always be in the decoded form. It does not make much sense 
to me to perform rewriting on the value of the URL before it is decoded.

What do you think?

Original comment by lincolnb...@gmail.com on 20 Dec 2010 at 4:19

[GoogleCodeExporter]

This issue and many other encoding related bugs are fixed in the current 
snapshots.

It would be great if someone who was affected by these encoding issues could 
confirm that the current snapshot is working.

You can grab "3.1.1-SNAPSHOT" from the OcpSoft repository:

<repository>
 <id>ocpsoft</id>
 <name>OcpSoft</name>
 <url>http://ocpsoft.com/repository/</url>
 <releases>
   <enabled>true</enabled>
 </releases>
 <snapshots>
   <enabled>true</enabled>
 </snapshots>
</repository>

Thanks

Original comment by chkalt on 16 Jan 2011 at 1:59

[GoogleCodeExporter]

Original comment by lincolnb...@gmail.com on 2 Feb 2011 at 7:29

• Changed state: Fixed