Losing https after redirecting from the backedn

Splash Forums PrettyFaces Users Losing https after redirecting from the backedn

This topic contains 5 replies, has 3 voices, and was last updated by  Sal 8 years, 3 months ago.

Viewing 6 posts - 1 through 6 (of 6 total)
  • Author
  • #25168



    I’ve been using prettyfaces (2.0.4.Final) for 3 months now and I find its a really useful tool. I’m looking forward to use the rewrite as well.

    Ok, let’s go to the point.

    We have a webapplication running on glassfish (glassfish 3.2.1 ) with an Apache server. The Apache Server is redirecting the request from http to https.

    If we don’t use pretty redirection from the back end the thing is working fine, but if we use pretty (like this “return pretty:home;”) we are losing the https in the URL.

    Example: URL before redirecting from the back end ----> https://oursite.com 
             URL after "return pretty:home;" -------------> oursite.com

    And here the definition of the home page in our pretty-config:

        <url-mapping id="home">
            <pattern value="/" />
            <view-id value="/index.xhtml" />
        <rewrite match="/home" substitute="/" redirect="301"/>

    This is happening every time we redirect from the back end. Not just in the home page.

    And that is the situation so far.

    I would like to thank you in advance for your help.


    • This topic was modified 8 years, 3 months ago by  Sal.
    • This topic was modified 8 years, 3 months ago by  Sal.


    First, I’d really like to help, and this sounds like a bug, so I think that it might be best if you could:

    1. Upgrade to PrettyFaces/Rewrite 2.0.8.Final.
    2. Provide a sample maven application and steps to reproduce the issue.



    Hey Sal,

    just to clarify. Are you using Rewrite 2.0.4.Final with the rewrite-config-prettyfaces module or are you using a really old version of PrettyFaces (2.0.4)?

    Sorry, for the dump question, but as PrettyFaces is now part of Rewrite, version numbers may get a bit confusing. 🙂




    Thanks for the quick answer.

    Lincoln, we are going to update to 2.0.8 and check if that solves the issue. If it doesn’t I’ll try to get back to you with the sample application and the steps to reproduce it.

    Christian, I think we are using rewrite-config-prettyfaces 2.0.4, here is the definition in our pom.xml





    Ok, great. So you are not using an ancient version of PrettyFaces. That’s good. 🙂

    Regarding your problem. You should have a look at the HTTP response headers of the redirect. AFAIK PrettyFaces only sends relative URLS (like /new-url) and NOT absolute URLs (like http://whatever.com/new-url). So actually I don’t think PrettyFaces can cause this issue, as relative URLs in redirects cannot change the URL schema. But I may be wrong. However, a sample app to would be very helpful.




    Hi again,

    First of all thanks for the help.

    I think I find a solution for this but I could not test it. In the end we decided to remove the prettyfaces from the part of the application where we are having the problems.

    BTW my guess is that we were missing to set the navigation-rules in the faces-config.xml to make it redirect.

                <redirect />

    The other components should be as follow, pretty-config.xml:

        <url-mapping id="page1">
            <pattern value="/page1" />
            <view-id value="/page1.xhtml" />

    And then from the managed bean:

    return "page1";

    Does it makes any sense to you guys?

    As I said a couldn’t test it, so I just leave it for the record. 🙂


    • This reply was modified 8 years, 3 months ago by  Sal.
Viewing 6 posts - 1 through 6 (of 6 total)

The forum ‘PrettyFaces Users’ is closed to new topics and replies.

Comments are closed.