Got a pickle here. We have an application that, for some reason, the mobile app developer and the main developer haven’t gotten on the same page and mucked some things up.

The backend app sits at https://externalapp.webserver.com/apppath/appsubpath . This hasn’t been much of an issue in the past because a simple URL redirect was all that was needed, but the mobile developer has decided the mobile app has to be forced to use https://externalapp.webserver.com/appsubpath , which leaves the pickle. If the user is lucky enough to completely delete the app and re-enter the URI of https://externalapp.webserver.com/apppath/appsubpath manually, it seems to want to work. That’s not a practical workaround so I’m wanting to see if our old friend Apache can help, because it’s either that or IIS acting as the reverse proxy, and I don’t like IIS much.

So, what I need to do is check to see if the URI starts with https://externalapp.webserver.com/appsubpath , then rewrite the URI to be https://externalapp.webserver.com/apppath/appsubpath , otherwise, don’t rewrite any part of the URI and proxy it as is. Here in lies the issues. This config works as long as the user is lucky to be able to manually enter the URI,

<VirtualHost *:443>

    ServerName externalapp.webserver.com

    ProxyPreserveHost On

    ProxyPass "/" "https://backend.webserver.com/"
    ProxyPassReverse "/" "https://backend.webserver.com/"

    SSLProxyEngine On
    SSLProxyCheckPeerCN Off
    SSLProtocol All -SSLv2 -SSLv3 -TLSv1 -TLSv1.1
    SSLProxyCipherSuite ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS

    LogLevel debug
    CustomLog "C:/Apache24/logs/externalapp_webserver_com_https.log" combined

</VirtualHost>

Anyone not so lucky, I have tried this config but it doesn’t seem to want to work.

<VirtualHost *:443>

    ServerName externalapp.webserver.com

    RewriteEngine On
    ProxyPreserveHost On

    # ProxyPassMatch ^/appsubpath/(.*)$ https://backend.webserver.com/apppath/appsubpath/$1
    # ProxyPassReverse "/apppath" "https://backend.webserver.com/apppath/"

    RewriteRule "^/appsubpath/(.*)$" "https://backend.webserver.com/apppath/appsubpath/$1" [PT]

    ProxyPass "/" "https://backend.webserver.com/"
    ProxyPassReverse "/" "https://backend.webserver.com/"

    SSLProxyEngine On
    SSLProxyCheckPeerCN Off
    SSLProtocol All -SSLv2 -SSLv3 -TLSv1 -TLSv1.1
    SSLProxyCipherSuite ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS

    LogLevel debug
    CustomLog "C:/Apache24/logs/externalapp_webserver_com_https.log" combined

</VirtualHost>

I’m not sure why it isn’t working, and as you can see I even tried to use a ProxyPassMatch, but that doesn’t seem to work either. Thoughts?

3 Spice ups

If I am understanding properly, you want it to be when a user goes to one URL is goes instead to another.

A reverse proxy will relay this information, however to the user the information exchange is transparent.

Since you said in the past a redirect would work and now will not, and the dev is “forcing” the change, I assume that means the app is checking the URL literally?

So the backend development group apparently decided that https://backend.webserver.com/apppath/appsubpath is what they wanted and hard coded that, but the mobile developers have decided that https://backend.webserver.com/appsubpath is how they want it, and while not hard-coded, until this recent update the users only had to go to https://backend.webserver.com/ and we had a redirect page to point them to https://backend.webserver.com/apppath/appsubpath . If a user is lucky enough to get the chance to manually type https://backend.webserver.com/apppath/appsubpath in, then everything works, but if they still use https://backend.webserver.com/ for a number of reasons, then the app automatically appends /appsubpath and tries to use it, which doesn’t work.

Management has tasked be with ensuring that users not have to manually type in https://backend.webserver.com/apppath/appsubpath , but rather the shorter https://backend.webserver.com/ like they always have, so I need to rewrite the app generated url of https://backend.webserver.com/appsubpath to https://backend.webserver.com/apppath/appsubpath on the fly. Now the fun, and this is where I see Apache hanging up, is appsubpath is the same text regardless of position, so I have to tell it to only rewrite if it sees /appsubpath, not /apppath/appsubpath. That’s where I think I’m falling down at.

As an added bonus, if I do this

RewriteRule ^/appsubpath/(.*) https://backend.webserver.com/apppath/appsubpath/$1 [P]
ProxyPassReverse "/apppath" "https://backend.webserver.com/apppath/"

This does seem to work, but then the second ProxyPass doesn’t seem to get hit anymore for other URLs going to https://backend.webserver.com that also need to pass through unaltered, only when https://backend.webserver.com /appsubpath is seen do I want the rewrite to occur, otherwise, pass the URL through unaltered.

ProxyPass "/" "https://backend.webserver.com"
ProxyPassReverse "/" "https://backend.webserver.com"

Just curious if you can just user a URL shortener to the new URL? And make it all go away?
Because on reading your second post this sems to just be the complexity to the end user, and in a browser?
Not an application’s backend API?

It’s about trying to fix the developers two teams not talking to each other and forcing different URI schemes

Ok, so, another wrinkle came up in trying to figure this all out. Apparently there is multiple appsubpaths that give an issue, and the mobile app is really screwed up on this. So, what I needed to do is this, which works if the mobile app is set to use https://externalapp.webserver.com/appsubpath , but not if it’s set to use https://externalapp.webserver.com/apppath , which should meet the requirements but I’m frustraited it’s not working in both cases.

<VirtualHost *:443>

    ServerName externalapp.webserver.com

    RewriteEngine On
    ProxyPreserveHost On

    RewriteRule "^/appsubpath2(.*)$" "https://backend.webserver.com/apppath/appsubpath2$1" [P]
    RewriteRule "^/appsubpath/appsubpath(.*)$" "https://backend.webserver.com/apppath/appsubpath/$1" [P]

    ProxyPass "/" "https://backend.webserver.com"
    ProxyPassReverse "/" "https://backend.webserver.com"

    SSLProxyEngine On
    SSLProxyCheckPeerCN Off
    SSLProtocol All -SSLv2 -SSLv3 -TLSv1 -TLSv1.1
    SSLProxyCipherSuite ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS

    LogLevel debug
    CustomLog "C:/Apache24/logs/externalapp_webserver_com_https.log" combined

</VirtualHost>

I guess what I should be doing is checking if the URI doesn’t begin with https://externalapp.webserver.com/apppath , then rewrite it so that it does and append whever was the path before after that.

Doing this method seems to be working as expected.