Using IIS as a reverse proxy is not ideal. I mean, it’s not bad, it does work, it’s just that in my opinion it’s overly complex to configure, maintain and debug when compared to apache/nginx/varnish. We don’t live in an ideal universe, IIS reverse proxies exist and plus, it’s your right to disagree, not the first time you’d be wrong about something.
Anyway, when working on legacy products, from time to time you’ll need to introduce new components to existing stacks. There’s no possible way you can rewrite and re-engineer a product all at once, that just doesn’t work.
Logically you’ll just create a new component that replaces an existing one, add an adapter on top of it and just deploy the new component. When you do that you’ll need to plug it in the existing architecture.
If it’s a client facing component you’ll just reverse proxy the requests. If your legacy stack is IIS based, you’ll have to use IIS for the reverse proxying. That’s life.
It will work most of the time but when it just doesn’t you’ll need to debug it. And there’s no way you can debug the problem based on this:
What you can do to properly debug it is use Failed Request Tracing Rules, read more about it here: https://www.iis.net/learn/troubleshoot/using-failed-request-tracing/using-failed-request-tracing-rules-to-troubleshoot-application-request-routing-arr
The short story is:
Configure it to trace All content, 500 Status code and all providers. That’ll give you a full view of what’s interacting with ARR.
After you do that, reproduce the error, go to C:\inetpub\logs\FailedReqLogFiles\ and open up the most recent log file. It’ll be a huge XML file. Search for ErrorDescription and you’ll get a textual representation of your error, something like :
<Data Name="ErrorDescription">Outbound rewrite rules cannot be applied when the content of the HTTP response is encoded ("gzip").</Data>
That’ll save your night.