Thanks for the reply, Paul. And thanks very much for updating the post to offer that additional clarification (and more).
As for the alternatives that could offer reverse proxy without ARR, I appreciate that you mention there are some, but again I would love to hear from you or anyone offering more about those. I have tried to find them before with no success. I did say I didn't mind if they are 3rd-party add-ons. 🙂
And it's not that I am anti-ARR, but I fear that because it does much more than just setup reverse-proxying, it would be that some would either not want to or perhaps even not be allowed to enable it. And yes, I realize ARR "is" at least those two things you list, but it also adds still more, from load balancing to caching, and several more features listed at the bottom of that page. Again my concern is that someone may worry that adding such a toolbox when they want just a hammer may be overkill.
For instance, they may want simply one IIS instance (perhaps running as a Docker container) to proxy requests to just one backend server (perhaps also in Docker), to avoid exposing that backend publicly. You mention Tomcat, and there is its AJP approach to connecting IIS to it. But Tomcat also offers its own web server. Someone may want to leverage IIS features to be the front-end for a site, but have those requests then processed by the backend Tomcat. That would be a perfect use case of enabling such a proxy.
And of course both Apache and nginx make it simple, but IIS does not. And adding ARR is overkill for that one need. So again if there is any alternative that would provide for this, I'd love to hear it. This URL Rewrite option of a "reverse proxy" rule was compelling, until I found everywhere that it was only offered if ARR was added.
And in case anyone may think it's just a technicality that the IIS UI only adds that rewrite option if ARR is installed, I can confirm that it will not work if you enable it via xml, such as in web.config, at least in trying to do a rewrite to a URL not processed by IIS itself, which again is my goal above. You will get errors indicating that IIS cannot process the request. Others have wanted to also do it (without respect to Docker) simply to have an IIS request be forwarded to some other back-end application, and they have encountered (and reported) the same problem.