We are able to get the basic functionality of the reverse proxy to work just fine. It redirects to internal webserver and you get the web page back. So the inbound rule works.
The outbound rewrite rule does not though...
This is the first bit of the resulting HTML:
<!DOCTYPE html>
<html lang="en" class="main">
<head>
<meta charset="utf-8">
<meta http-equiv="X-UA-Compatible" content="IE=edge" />
<base href="http://10.1.1.111/?_version=11.0.0.614" />
<title>Crappy Webapp</title>
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<meta name="description" content="">
<meta name="author" content="">
And all links are "link href" that are then based on the "base href", so every resource lookup breaks. For some unfathomable reason we cannot get the rewrite rule to rewrite the damn internal IP to a public domain name.
We have turned off caching. (Worked for another service that had same issues.) We have tried a billion rules-variants and preconditions when what we expected was correct didn't work. - We target Base (and all other tags), Match pattern is ^http(s)?://10.1.1.111/(.*) - Regex - and test pattern does match. And rewrite is "http{R:1}://service.domain.com/{R:2}
Precontition is set to pattern="^text/html" and pattern="^text/css".
If it matters, it looks like the app generates the HTML with a metric ton of javascript.
I realize it is very hard/impossible to say what is the problem here, but perhaps someone has stumbled across a similar problem and solved it.
My smarter and more tenacious colleague found the solution!
In short, the issue seems to have been that the pattern to match (and rewrite) didn't start with "http://", it was just the domain and internal IP without http:// -prefix - a pitfall I hope others can learn from. :)
So this was the working webconfig code in full - urls and IPs changes to protect the innocent. :)