Dispatcher mod_rewrite not working? | Community
Skip to main content
daitienshi
daitienshi
Level 2
August 23, 2017
Solved

Dispatcher mod_rewrite not working?

  • August 23, 2017
  • 12 replies
  • 5860 views

Related to another post (AEM Dispatcher not resolving vanity urls),​ I've created some rewrite rules in my httpd.conf in my dispatcher so that when I hit my site's root (e.g. www.mysite.com/), it should rewrite/redirect to a page of my choosing (e.g. www.mysite.com/content/mysite/login.html).

However, when I hit the root, I'm getting a response with a redirect (302) to /index.html instead, even though I've created a rewrite rule for this.

In my httpd.conf, I have:

Ideally, what I'd like is a combination of vanity urls and rewrite so that anything that hits the root get redirected to the vanity url, which I had tried to set up by configuring the sling:redirect property of the /content node, but the dispatcher keeps returning index.html instead of the value of the sling:redirect.

Thanks!

    This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.
    Best answer by joerghoh

    In the second case the dispatcher still forwards the request to AEM, although it should not. Have you restarted the httpd to make that change effective?

    If yes, please provide all webserver configuration (including dispatcher config) for both cases and report an issue with AEM support.

    Jörg

    12 replies

    joerghoh
    Adobe Employee
    joerghohAdobe Employee
    Adobe Employee
    August 23, 2017

    Have you set in the httpd.conf the statement "DispatcherDeclineRoot 1"?

    See Installing Dispatcher - docs.adobe.com

    regards,

    Jörg

    daitienshi
    daitienshiAuthor
    Level 2
    August 23, 2017

    Hi,

    I did set that value to 1 and the dispatcher.log still says it's returning a 302 to /index.html. 

    Is this supposed to let the root request pass through to the publisher? This way the publisher can return the redirected page as configured in the sling:redirect in the /content node?

    Thanks!

    joerghoh
    Adobe Employee
    joerghohAdobe Employee
    Adobe Employee
    August 23, 2017

    If you want to handle the initial redirect on the apache webserver, set it "1"; if you want to handle the redirect on hitting "/" on the AEM publish, set it to "0".

    Jörg

    daitienshi
    daitienshiAuthor
    Level 2
    August 23, 2017

    I've set it to 0 so the publisher can return the right page back, but I'm still seeing an index.html being returned to the dispatcher and the publisher's request log doesn't seem to show the request for the page.

    When setting it to 1 and having those rewrite rules on, it doesn't seem to be working either as it comes back with index.html instead of the login.html

    joerghoh
    Adobe Employee
    joerghohAdobe Employee
    Adobe Employee
    August 23, 2017

    Can you set the dispatcher loglevel to DEBUG and post the relevant log snippets then?

    ("If you don't find the log statements you are expecting in the log, you are looking at the wrong log". -- Old debugging wisdom, author unknown)

      daitienshi
      daitienshiAuthor
      Level 2
      August 23, 2017

      I've actually set it to TRACE just but here's the log snippet for when the DispatcherDeclineRoot is set to 0:

      Here is the log snippet when I set the DispatcherDeclineRoot to 1:

      Thanks!

      joerghoh
      Adobe Employee
      joerghohAdobe EmployeeAccepted solution
      Adobe Employee
      August 23, 2017

      In the second case the dispatcher still forwards the request to AEM, although it should not. Have you restarted the httpd to make that change effective?

      If yes, please provide all webserver configuration (including dispatcher config) for both cases and report an issue with AEM support.

      Jörg

        daitienshi
        daitienshiAuthor
        Level 2
        August 23, 2017

        Thanks. Yes, between switching the values, I've restarted apache. 

        I'll open up a ticket with AEM support and provide all of the configurations there.

        D
        dorianhallward
        Level 4
        January 17, 2018

        daitienshi, @Jorg Did this get resolved? I'm seeing similar.

        daitienshi
        daitienshiAuthor
        Level 2
        January 17, 2018

        Yep. Turns out because the site is using SSL, I had to put the rewrite rules in our ssl.conf file that contained the virtualhost entry for the secured site.  Once that's in there, it worked.

        Show more replies
        Terms & ConditionsAccessibility statement

        Loading footer...