Hello everybody,

I have an outsystems application deployed on a Windows 2008R2, IIS 7 environment. This application is already working with no problems. It is serving requests through HTTPS on port 443 and i can access it with no problems.

Now, there is the need to enable some users to access it through a NAT, which is configured to serve requests on port 8200. The requests are forwarded to the server with no problem, except when the response is a redirect (HTTP 302). In these cases, the Location Header of the response is set with the port where the application is actually being served which is port 443. When the client's browser tries to access this URL that was set in the Location Header, it will fail since the NAT is only serving the requests in port 8200.
This is (i think) not a problem in the outsystems platform itself, but probably a configuration/setup that needs to be done at the server level.

In sum:
- Client browser accesses https://myserver:8200/myapp ;
- NAT translates the URL and forwards to https://myserver:443/myapp ;
- Application replies with a 302 redirect to https://myserver:443/redirect ;
- Client browser accesses https://myserver:443/redirect ;
- NAT blocks this access because it is expecting port 8200 ;

Here is what i tried to do; I installed the URL Rewrite module in IIS and created the following rules:
 - An Inbound rule to store the request's Host Header (in these cases it's https://myserver:8200) to a server variable ORIGINAL_HOST.
 - An Outbound rule to replace the host part of the URL that is sent in the response's Location Header (https://myserver:443/redirect) with the value stored in my server variable ORIGINAL_HOST. The rule is only applied in case of a redirect.

The problem i am facing now is that the minute i enable this Rule, all AJAX requests stop working even it the rule does not apply to them and even if not accessing the application through the NAT.
When this happens, i am seeing through IE's Network tab in Developer Tools that the request header and body is ok, response header is ok, but the response body is empty and should not be. Also, if i try to debug the AJAX request in Service Studio using a breakpoint, it is not stopping at the breakpoint.

So, my question: Is using the URL Rewrite the best way to solve this problem? If so, how can i solve the AJAX situation? If not, then how do i solve the redirect problem?

Thank you in Advance,
João Gomes

Hi João

At first light, I can't see a reason why the AJAX requests stop working. Perhaps a more indepth analysis of the problem will shed some light on the cause.

We are aware that NAT translation of Ajax request may cause some requests to generate broken links, because the URL is inside the content of the Ajax payload, and not the header. So it's possible that some of the contents got broken links, as the URL rewrite might not be able to compensate for the URLs in the payload, so but to get an empty respond it's unexpected..

Do you get any error in the Service Center error logs when the AJAX request doesn't work? Do you get any error message in the browser, or server's application event viewer?

As an alternative, what we see other users using, is a reverse proxy with HTTPS offload. This will allow to expose an application with a different IP:port tuple. Although this works well on HTTP, to work accurately in HTTPS one needs to offload the HTTPS certificates to the reverse proxy, so the information can be decrypted and redirect to the OutSystems servers. If this is not an option, lets dig in in the URL rewriter issue.

Can you also share the URL rewriter rules, so we can check and attempt to replicate?

Let us know your findings.



Hi Miguel,

I cannot see any errors in either Servicer Center or the browser. And the AJAX problem does not happen only when behind the NAT. It also happens when accessing the application directly in port 443. This may indicate a problem with my URL Rewrite rules.

You can find my rule configuration here: Thanks,
João Gomes

Hi João,

I haven't got the opportunity to check this problem out, but it occorred to me that if the port doesn't change, it might work.

Have you tried setting the port 8200 has a HTTPs binding on the server, and make the NAT redirect to that port instead of 443? You should keep both port 80 and 443 in the bindings as well.


Miguel SImões João
Hi Miguel,

Sorry for not replying sooner, i just got back from vacations.
But that actually sounds like a good idea. And a simple one too, cannot believe i didn't think of that. :)
I'll give feedback after we've tested it.


João Gomes