3.3.0 to 3.3.1 migration url rewrite problem

Splash Forums PrettyFaces Users 3.3.0 to 3.3.1 migration url rewrite problem

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

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

    m1m
    Participant

    With 3.3.0 I was using these rewrites:

    <?xml version="1.0" encoding="UTF-8"?>
    <pretty-config xmlns="http://ocpsoft.com/prettyfaces/3.3.0"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://ocpsoft.com/prettyfaces/3.3.0
    http://ocpsoft.com/xml/ns/prettyfaces/ocpsoft-pretty-faces-3.3.0.xsd">
    <rewrite match="^(?![^/]*/(javax.faces.resource/)).*(.html|?).*$" substitute="/" outbound="false"/>
    <rewrite match="^(?![^/]*/(javax.faces.resource/|error|ping|images/|favicon.ico|robots.txt)).*$" trailingSlash="append" toCase="lowercase" outbound="false"/>
    </pretty-config>

    After change to 3.3.1 I got 301 redirect to “/”. If I remove these 2 rewrites everything is ok. What’s going on? :)

    #21621

    We fixed some bugs in 3.3.1 that caused rewrite loops in some situations. But this shouldn’t have any effects on existing rewrite rules.

    What exactly do you want to achieve with these rules? It looks like the first one matches in your test. Isn’t this intended? That substiute="/" part looks a bit strange to me.

    #21622

    m1m
    Participant

    First rule is to forbid users accesing .html pages or append any parmeters (?) to url, except urls containing /javax.faces.resource/.

    It was working with 3.3.0. Now I got redirect no matter which rule is applied.

    #21623

    m1m
    Participant

    One more question, should I update <pretty-config> xmlns url to 3.3.1?

    #21624

    No, you don’t have to adjust the namespace. The namespace is ignored during the parsing process. Using the most current XSD just helps you if you are using code completion in you IDE.

    Which URL did you test with? I mean could you give an example for an URL that worked before and now redirects to the wrong place.

    I’m note sure if your regular expression is correct. Could you test it with this applet?

    http://myregexp.com/signedJar.html

    Another important point is that the recent changes in 3.3.1 now prevent that more than one rewrite rule is applied to an URL. This was part of the efforts to prevent rewrite loops.

    #21625

    m1m
    Participant

    Ok, I tested following expression with applet

    ^(?![^/]*/(javax.faces.resource/)).*(.html|?).*$

    /testimonials/ - not matching
    /testimonials/index.html - matching
    /testimonials/?id=11 - matching

    So rewrite rule should be applied to last two urls. Now I got redirected every time, even if I go to http://mysite.com/

    #21626

    I think the rewrite rules will also be applied to the viewId of your mapping (the JSF view that is hidden behind “/testimonials/” for example). Could this be the problem?

    Could you perhaps post your mapping for the testimonials page?

    #21627

    m1m
    Participant

    Mapping is very simple:

    @URLMapping(id = "testimonials",
    viewId = "/testimonials.html",
    pattern = "/testimonials/")

    I changed rule to

    <rewrite match="^(?![^/]*/(javax.faces.resource/)).*$" substitute="/" />

    but still redirecting me to /

    #21628

    The rule from your last post will definitively redirect because it matches “/testimonials/“. So this is expected behavior.

    The first rule from your first post doesn’t match “/testimonials/“. But the problem here is that your mapping forwards “/testimonials/” to “/testimonials.html“. Therefore the request is hit by the rewrite engine a second time. The second time the rewrite engine sees the URL “/testimonials.html” which matches your rule. Therefore you are getting the redirect.

    To be honest, I think that your rule previously only worked because there was a bug in the rewrite engine that caused the rewrite engine to work on the wrong URL on the second hit. We fixed this in 3.3.1 so you are running in the situation as described in the second paragraph.

    You could argue that it doesn’t make sense that the rewrite engine processes the forwarded request. And it may indeed not be optimal that it currently does so, but I’m unsure what implications it may have if we change this.

    Perhaps you could create a ticket for this. I’m meeting Lincoln next week. Perhaps we find some time to discuss this.

    Anyway, thanks for reporting this.

    Christian

    #21629

    m1m
    Participant

    Thanks for explanation.

    I didn’t know rewrite engine is working for both pattern and viewId. Now it’s clear why I got redirected. But in my opinion rewrite should work only for pattern. I’ll stick to 3.3.0 for now.

    #21630

    Ok, I think it makes sense to stay with 3.3.0 in this case.

    We are currently working on PrettyFaces 4.0 and will take special care that these situations are handled correctly.

    #21631

    Hey m1m,

    I just committed a fix that should fix the problems you had with 3.3.1/3.3.2. In the current 3.3.3-SNAPSHOT version rewrite rules aren’t applied to the view-id of URL mappings anymore.

    If you have some time could you perhaps give 3.3.3-SNAPSHOT a try? I just want to make sure that users are happy with this change.

    Thanks

    Christian

    #21632

    m1m
    Participant

    Hey,

    It’s nice you remember about that. I’ve tried prettyfaces-jsf2-3.3.3-20111216.050844-8.jar and it’s working OK!

    Looking forward for v4. Good luck.

    Thanks

    #21633

    Thanks for you feedback. I think we will release version 3.3.3 in the next weeks. Thanks for your help! :)

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

You must be logged in to reply to this topic.

Comments are closed.