non ASCI symbols in @URLMapping

Splash Forums PrettyFaces Users non ASCI symbols in @URLMapping

This topic contains 13 replies, has 2 voices, and was last updated by  Christian Kaltepoth 6 years, 6 months ago.

Viewing 14 posts - 1 through 14 (of 14 total)
  • Author
    Posts
  • #17893

    0swald
    Participant

    Hi all.

    Just encountered strange behavior of @URLMapping with regard to non-ASCI characters in URI. Here is the mapping:

    @URLMapping(id="test", pattern="/test/#{bean.subject}/", viewId="/faces/pages/test.xhtml")

    In this case pretty easily parses link like http://localhost:8080/test/Velký_třesk/ which is common case in wikipedia – http://cs.wikipedia.org/wiki/Velký_třesk

    But the following mapping always produces 404:

    @URLMapping(id="test", pattern="/Velký_třesk/#{bean.subject}/", viewId="/faces/pages/test.xhtml")

    Looks like static and dynamic parts of pattern are handled in different ways.

    Passing URL-encoded value does not solve the issue.

    Any ideas or workarounds?

    Regards,

    Osw.

    #20787

    Hey Oswald,

    thank you for reporting this. We know about some encoding problems in the current stable version 3.2.0 and already fixed them in the development branch. Could you perhaps give 3.2.1-SNAPSHOT a try and tell us if your problem shows up there too?

    https://github.com/ocpsoft/prettyfaces/wiki/Snapshots

    Thanks

    Christian

    #20788

    0swald
    Participant

    Latest snapshot prettyfaces-jsf2-3.2.1-20110402.070324-16.jar ruines even my working mapping:

    java.lang.IllegalArgumentException: java.net.URISyntaxException: Illegal character in path at index 18: http://localhost/тест
    com.ocpsoft.pretty.faces.url.URL.decodeSegment(URL.java:144)
    com.ocpsoft.pretty.faces.url.URL.getDecodedSegments(URL.java:92)
    com.ocpsoft.pretty.faces.url.URL.decode(URL.java:154)
    com.ocpsoft.pretty.PrettyContext.<init>(PrettyContext.java:89)
    com.ocpsoft.pretty.PrettyContext.newDetachedInstance(PrettyContext.java:174)
    com.ocpsoft.pretty.PrettyFilter.doFilter(PrettyFilter.java:72)
    root cause

    java.net.URISyntaxException: Illegal character in path at index 18: http://localhost/тест
    java.net.URI$Parser.fail(URI.java:2809)
    java.net.URI$Parser.checkChars(URI.java:2982)
    java.net.URI$Parser.parseHierarchical(URI.java:3066)
    java.net.URI$Parser.parse(URI.java:3014)
    java.net.URI.<init>(URI.java:578)
    com.ocpsoft.pretty.faces.url.URL.decodeSegment(URL.java:139)
    com.ocpsoft.pretty.faces.url.URL.getDecodedSegments(URL.java:92)
    com.ocpsoft.pretty.faces.url.URL.decode(URL.java:154)
    com.ocpsoft.pretty.PrettyContext.<init>(PrettyContext.java:89)
    com.ocpsoft.pretty.PrettyContext.newDetachedInstance(PrettyContext.java:174)
    com.ocpsoft.pretty.PrettyFilter.doFilter(PrettyFilter.java:72)

    URI mentioned in stacktrace is not the one I’ve actually tried: http://localhost/myapp/test/тест

    where myapp is context path and test is first part of mapping from my original post.

    #20789

    Its correct behavior that you see an different URL in the stacktrace. We are building a custom URL when encoding single path parameters. That is some kind of workaround to be able to use the URI class for URL encoding.

    But I don’t actually know why the т character is not allowed in an URI. I’ll have a deeper look at this as soon as I find some time.

    Thank you for testing the snapshots! :-)

    #20790

    0swald
    Participant

    Christian, actually Ñ wasn’t part of my url, these symbols resulted from wrong decoding, as I see it. There should be somewhat url-equal to %D1%82%D0%B5%D1%81%D1%82 which is encoded тест.

    Regards,

    Osw.

    #20791

    Ah, OK! Sorry, I misunderstood it! :-)

    So тест get decoded incorrectly. That’s strange. I’ll have a look at this.

    #20792

    Which JSF implementation and which container are you deploying to? And which versions?

    I did a quick check for тест as a path parameter and it worked fine with MyFaces and Tomcat7.

    #20793

    You can download the webapp I used for testing here:

    https://github.com/chkal/prettyfaces-tests/archives/encoding

    #20794

    0swald
    Participant

    Christian, thanks for link, but none of your url-mapped beans use non-ASCI pattern.

    What I want to achive is your GreetingBean.java like below:

    @ManagedBean
    @RequestScoped
    @URLMapping(id = "greeting",
    pattern = "/тест/#{greetingBean.name}",
    viewId = "/greeting.jsf"
    )
    public class GreetingBean
    ....
    ....

    (please note non-ASCI in pattern)

    #20795

    Yeah, but non-ASCII characters in the pattern also work fine for me! Did you try such a mapping like you posted? I have no problems with it!

    #20796

    0swald
    Participant

    You’re right. As a standalone app it’s working in 3.2.0, thanks!. Now I’ll try to figure out what’s wrong with my app. I’ll post the results here.

    #20797

    0swald
    Participant

    Found. I have an apache frontend with mod_jk module forwarding requests to Tomcat. By default mod_jk uses option JkOptions +ForwardURIProxy

    Using JkOptions ForwardURIProxy, the forwarded URI will be partially reencoded after processing inside Apache httpd and before forwarding to Tomcat.

    Changing it to JkOptions +ForwardURICompatUnparsed solved the issue:

    Using JkOptions ForwardURICompatUnparsed, the forwarded URI will be unparsed. It’s spec compliant and secure. It will always forward the original request URI, so rewriting URIs with mod_rewrite and then forwarding the rewritten URI will not work.

    Christian, thanks again! Hope this thread will be useful for those using apache frontend.

    #20798

    Great! Thanks for posting your findings! :)

    #20799

    I also added a note regarding this issue to the documentation:

    https://github.com/ocpsoft/prettyfaces/commit/ba3976a9768ba3ac3aa1f69284c6c84bddc0e347

Viewing 14 posts - 1 through 14 (of 14 total)

You must be logged in to reply to this topic.

Comments are closed.