1

I am trying to get an apache 2.4 reverse proxy (RHEL 7.7) working with an application that has hard coded paths making my reverse proxy configuration quite challenging. This serverfault link (How to handle relative urls correctly with a reverse proxy) has been great, particularly approach solution #3 of putting in a bunch of locations (which have been hard coded). My proxy runs paths to distinguish applications (www.example.com/app1 and www.example.com/app2). In this example, /app2 has hard-coded a bunch of directories like /static and /api. Putting those Locations with ProxyPass and ProxyPassReverse in has worked great and the site is functional.

However, they have also hard coded /#/ for whatever reason and I see them in href links in certain places. So, I followed the pattern and defined a Location for /#/. However, it doesn't work. For whatever reason, when I hit that link, it doesn't direct it to the app2.internal.example.com server, but instead serves my home page that responds at www.example.com/. In the URL, I see it is displaying www.example.com/#/SOMEWHERE, but it is clearly not getting to app2. The config file is below. Is /#/ a special location that can't be used? Are there any solutions for this? Thanks in advance.

<Location /app2/>
  ProxyPass https://app2.internal.example.com/
  ProxyPassReverse https://app2.internal.example.com/
  Header add referer "https://app2.internal.example.com/"
  RequestHeader set referer "https://app2.internal.example.com/"
</Location>

<Location /static/>
  ProxyPass https://app2.internal.example.com/static/
  ProxyPassReverse https://app2.internal.example.com/static/
  Header add referer "https://app2.internal.example.com/"
  RequestHeader set referer "https://app2.internal.example.com/"
</Location>

<Location /api/>
  ProxyPass https://app2.internal.example.com/api/
  ProxyPassReverse https://app2.internal.example.com/api/
  Header add referer "https://app2.internal.example.com/"
  RequestHeader set referer "https://app2.internal.example.com/"
</Location>

<Location /#/>
  ProxyPass https://app2.internal.example.com/#/
  ProxyPassReverse https://app2.internal.example.com/#/
  Header add referer "https://app2.internal.example.com/"
  RequestHeader set referer "https://app2.internal.example.com/"
</Location>
Foghorn
  • 123
  • 5
  • Crossdupe [Why is the hash part of the URL not available on the server side?](https://stackoverflow.com/questions/3664257/why-is-the-hash-part-of-the-url-not-available-on-the-server-side) – dave_thompson_085 Aug 10 '19 at 04:33

1 Answers1

2

The # in a URL delineates the URL fragment, a part of the URL indicating a location in the document to which the browser will scroll once the document is loaded.

Some JavaScript libraries have abused the URL fragment to pass information around client-side to support various functions of single page apps. This is no longer in vogue (and never was a very good idea) and such applications need to be updated to use the History API and change these URLs appropriately to no longer use fragments. Your developers should do this a few years ago.

There are several reasons this was a bad idea to begin with, but most importantly for your situation, the URL fragment is strictly client side and is never passed to the server. If you have a URL http://www.example.com/#/, the path is /, and that is all the server sees. It never sees the #/ as these are only client side. There is no way in plain HTTP to send it to the server, so you can't match on it in a Location. Or anything else.

Michael Hampton
  • 237,123
  • 42
  • 477
  • 940
  • Thanks. I guess I will have to work on a mod_substitute approach, or something similar to get the href's changed before they are sent to the end user. – Foghorn Aug 10 '19 at 17:09
  • @George That would probably break the app's functionality. About the only thing you can do that will work is to put the app on its own subdomain, so you don't have to do any of this. – Michael Hampton Aug 10 '19 at 17:21