Setting up IIS Reverse Proxy for WordPress isn’t as straight forward primarily due to the fact that WordPress generates absolute URLs in its HTML output, so while IIS Inbound rule works fine:
https://www.PublicDomain.com/ResourceName => http://linux/wordpress
The outbound HTML contains absolute links as follows:
…which is obviously unreachable from beyond the intranet.
We need to create Outbound URL Rewrite rules to change all instances of:
So after creating an Inbound rule as we normally do, we create an Outbound rule as follows:
Note the ‘Precondnition:’ option? This is where you restrict the application of this rule only to specific type of content. For example, we do not want the URL ReWrite rule running on Zip files, or images, etc. We only want to target HTML pages by this rule where we change all references from http://linux/wordpress to /ResourceName
So if an appropriate Precondition doesn’t already exist, create one by clicking on ‘View Preconditions’:
And add a condition named appropriately: ResponseIsHtml with the following conditions:
This ensures that the rule is applied only to:
- Files whose content type is text/html, and;
- are originating from internal domain name: linux, to exclude other applications/servers from this rule.
NB: Where an application needs Outbound rules, create both Inbound AND Outbound rules at RDS > Sites > Default Web Site level, and NOT at RDS level.
But hold your horses, we’re not done yet!
which the Outbound rule obviously could not detect. To deal with these, we have to create yet another Outbound rule which looks for the string above and replaces it with something appropriate like this:
To do this we create yet another Outbound rule as follows:
Point in case: Gravatar. It tries to load content through unsecure HTTP protocol, if wordpress is actually being served from an unsecure http protocol, which is perfectly reasonable. It doesn’t know that it’s being served by a proxy using HTTPS. So we create an Outbound rule which looks like this:
This simply makes turns HTTP into HTTPS and problem solved!
Keep checking the browser’s console and apply the same technique where needed.
Another link of interest: