I want to know if anybody here can help. I have using Nest.js for my program and I have added some web socket code into my program for some new feature. However, when I deploy to the server and there are a problem to the IIS Setting.
Now I use URL rewrite for my http server. My HTTP server run on port 8200 in localhost. My web socket port is 8085. What I have tested is that I can call it in local using ws://localhost:8085/socket.io/?EIO=3&transport=websocket and also ws://192.168.X.X:8085/socket.io/?EIO=3&transport=websocket in internal network. However, I cannot call by ws://myurl.com/socket.io/?EIO=3&transport=websocket. The URL is binding with a IIS server. Below is my IIS server web.config. Is it because we socket cannot called by url? or is my web.config have something wrong? Can anybody help me?
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<system.webServer>
<rewrite>
<rules>
<rule name="WebSocketsReverseProxy" enabled="true" stopProcessing="true">
<match url="ws://(.*)"/>
<action type="Rewrite" url="ws://localhost:8085/{R:1}"/>
</rule>
<rule name="HttpsReverseProxy" stopProcessing="true">
<match url="(.*)"/>
<conditions>
<add input="{CACHE_URL}" pattern="^(https?)://"/>
</conditions>
<action type="Rewrite" url="http://localhost:8200/{R:1}"/>
</rule>
</rules>
</rewrite>
</system.webServer>
</configuration>
remove ws:// from the first rule. iis match rule only matches folder or file but does not match the domain name. if you want to match the domain use condition server variable {HTTP_HOST}.
Related
Situation is that I have 2 backend apps and I need to set up HTTPS access for them. I install IIS 8 with ARR and URL rewrite module on the server. Than I install 2 https certificates and create an empty website with binding on 443 port
with second app https certificate. First app is set upped on 8081 ports and second app on port 80. The problem is that I can access via https only to first app and second app could be accessed via http only. So I am trying to set up reverse proxy, so I could access to the second app via https. I wrote 2 inbound rules in URL rewrite, but I got issue when I try to access to second app it is pointing not to localhost:80 but it pointing to localhost:8081. any suggestions why it happen?
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<system.webServer>
<rewrite>
<rules>
<clear />
<rule name="App2" stopProcessing="true">
<match url="^app2/(.*)" />
<conditions logicalGrouping="MatchAll" trackAllCaptures="false" />
<action type="Rewrite" url="http://localhost:80/{R:1}" />
</rule>
<rule name="Redirection" stopProcessing="true">
<match url="^app2/(.*)" />
<conditions logicalGrouping="MatchAll" trackAllCaptures="false">
<add input="{SERVER_PORT}" pattern="443" />
</conditions>
<action type="Redirect" url="https://app2/{R:0}" />
</rule>
</rules>
</rewrite>
</system.webServer>
</configuration>
My goal is to be able to access this URL from remote machine via IIS Rewrite:
http://host:5000/#!/room/5963bdd51eeaa415988ec6d9
using the following URL:
http://{host}/chat/
Here's my web.config
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<system.webServer>
<rewrite>
<rules>
<rule name="chat" stopProcessing="true">
<match url="chat/*" />
<action type="Rewrite" url="http://127.0.0.1:5000" />
</rule>
</rules>
<outboundRules>
<rule name="chat" preCondition="">
<match filterByTags="A, Area, Base, Form, Head, IFrame, Img, Input, Link, Script" pattern="chat/*" negate="false" />
<action type="Rewrite" value="http://127.0.0.1:5000" />
</rule>
</outboundRules>
</rewrite>
</system.webServer>
</configuration>
Anything I'm doing wrong? Thanks
Since this is a outbound rule, your client will receive the address as http://127.0.0.1:5000. Assuming the client machine has no application installed at port 5000, you will run into an error.
Try using a Inbound Rewrite rule (If you dont want the URL to change on the browser) or Inbound redirect rule (if you want the URL to change on the browser) with the same parameters and let the server do the talking.
On my development machine, I am trying to configure IIS as a reverse proxy to forward requests coming in port 443 to a nodejs application running locally.
The requests are getting forwarded fine, but sometimes the the nodejs application tries to redirect the browser to an external site and the IIS url rewrite module change that also to point to the local server.
I am accessing the site using https://localhost/test
IIS reroutes the requests to the node app http://localhost:14819/test
The node app returns an http 302 with location header set to https://example.com/someroute
IIS transforms this to https://localhost/someroute
I want the external urls to be untouched by IIS. How to do this?
Here is my Web.config content
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<system.webServer>
<rewrite>
<rules>
<clear />
<rule name="ReverseProxyInboundRule1" patternSyntax="ECMAScript" stopProcessing="true">
<match url="^test(.*)" />
<conditions logicalGrouping="MatchAll" trackAllCaptures="false">
<add input="{HTTP_HOST}" pattern="^localhost" />
</conditions>
<action type="Rewrite" url="http://localhost:14819/test{R:1}" logRewrittenUrl="true" />
</rule>
</rules>
</rewrite>
</system.webServer>
</configuration>
If you have any redirect coming back from the backend proxy and you do
not want to redirect the Location header coming ,You can do that by
unchecking "Reverse rewritehost in response headers" in Application
Request Routing
Select the server node in IIS manager
Go to Application Request routing Cache
Click on Server proxy Settings
UnCheck "Reverse rewritehost in response headers"
I want to use IIS8 to route traffic from ports 80/443 to two applications running on the same server - one sitting on port 8080 (node.js app, running as a separate service), another on port 8090 (a .NET application, running on the same IIS, handling api calls).
I have setup an app on port 80, with the following web.config
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<system.webServer>
<rewrite>
<rules>
<rule name="rewrite api to backend calls" stopProcessing="true">
<match url="^api/(.+)$"/>
<action type="Rewrite" url="http://127.0.0.1:8080/{R:1}"/>
</rule>
<rule name="rewrite everything else to frontend" stopProcessing="true">
<match url="(.*)" />
<action type="Rewrite" url="http://127.0.0.1:8090/{R:1}"/>
</rule>
</rules>
</rewrite>
</system.webServer>
</configuration>
Unfortunately this approach doesn't work - whatever resource I try to query, I get 404 error.
In the FREB logs, requests are properly translated from OldUrl, to the NewUrl, nothing is found in cache and then the following is mentioned in logs as MODULE_SET_RESPONSE_ERROR_STATUS
ModuleName="IIS Web Core", Notification="MAP_REQUEST_HANDLER", HttpStatus="404", HttpReason="Not Found", HttpSubStatus="4", ErrorCode="The filename, directory name, or volume label syntax is incorrect.
(0x8007007b)", ConfigExceptionInfo=""
Proxy in Application Request Routing had to be enabled as per the IIS Rewrite not working (but redirection does) topic. Issue solved :)
A server (x.com) has the following parameters:
- It is accessible from the outside from port 80.
- It has an internal service running on port 1000.
- The service needs to be accessible from a subdomain (service.x.com)
Running IIS on Windows 10, I did the following:
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<system.webServer>
<rewrite>
<rules>
<rule name="URL Rewrite" enabled="true" stopProcessing="true">
<match url="(.*)" />
<conditions>
<add input="{CACHE_URL}" pattern="^(https?)://" />
</conditions>
<action type="Rewrite" url="{C:1}://localhost:1000/{R:1}" logRewrittenUrl="true" />
</rule>
</rules>
</rewrite>
</system.webServer>
</configuration>
And it worked beautifully.
The same code, on the other end, run on Windows Server 2012 R2 yields this:
HTTP Error 404.4 - Not Found
The resource you are looking for does not have a handler associated with it.
Module IIS Web Core
Notification MapRequestHandler
Handler ExtensionlessUrlHandler-Integrated-4.0
Error Code 0x8007007b
I do not understand why it works on one version of IIS and not on the other one.
I found: ARR (Application Request Routing) needs to be enable.
Of course, this is not mentioned anywhere in any of the error messages nor in log.