tl;dr: Web apps should work behind reverse-proxy servers out of the box. Use relative URLs.
Here’s my issue: I run both personal and public web sites, each of which has multiple web applications unified into a single namespace. Often these applications use completely different technology stacks. For example, on risacher.org, I’m running WordPress & Gallery (mod_php), occasionally Ajaxterm (python stand-alone server), Etherpad and tty.js (Node.js), a file-uploader app (mod_perl), and static & CGI content through Apache httpd. I unify all these apps into a single namespace through the use of a reverse proxy server. For years, I did this with perlbal, but I now I use a 50-line custom proxy based on node-http-proxy. (Other common solutions are nginx, Varnish, mod_proxy, Squid, or Pound.) (UPDATE: my reverse proxy server code is now at https://github.com/risacher/yxorp-edon)
For any of my applications, I generally want to map this application’s URL namespace into the overall namespace of the server. So, for example, even though tty.js normally serves files from ‘/’, my instance is at “
https://risacher.org/term/“. Applications that only use relative paths for URLs do this easily. Both Etherpad and tty.js use Socket.IO, to manage AJAX connections, and Etherpad computes the right socket.io endpoint URL automagically. Alas, tty.js isn’t quite so smart, and requires a 1-line change to support a remapped socket.io endpoint and 7 URLs need fixing in “static/index.html”. As a node.js guy, this was pretty easy to do. (I will submit a pull request to tty.js soon.)
Recently I tried to stand up a WaveMaker (java/tomcat) instance (on my EC2 server) to evaluate its suitability for a project at work. WaveMaker abjectly fails to be reverse-proxy friendly. I can’t unify WaveMaker with my existing web applications (it’s not reverse-proxy friendly), and I cannot access the non-standard port directly (employer’s firewalls do not permit it) and I cannot install WaveMaker at the office (employer’s policies do not permit me to install unapproved software). If I knew I really wanted WaveMaker, I might hack the code to make it reverse-proxy friendly. Alas, I don’t know yet if it’s worth using, and I dislike using Java, so it’s hard to get up the motivation to move forward.
A better (but less expedient) solution is for web applications to support reverse-proxy out-of-the-box. Alas, it was difficult to articulate this requirement until right now, because the term “reverse-proxy friendly” hadn’t been defined. Now that I’ve coined this term, you should bother authors of web-applications to implement this “feature”.
Go! Go now! Commence bothering!
(p.s. start with WaveMaker)