I have created an application that utilizes RAD Studio's EMS Server functionality. The development has been completed and tested in a production environment. The EMS Server documentation shows that in order to make an API call the emsserver.dll needs to be included in the URL.
https://{hostname}/emsserver/emserver.dll/API/Login?token={TokenValue}
Most APIs I have encountered do not have the dll embedded into the URL.
https://{hostname}/API/Login?token={TokenValue}
This is not a big deal as the API call works fine as is. I was just wondering if there is property or setting I can use in RAD Server or IIS in order to default the emsserver/emsserver.dll portion of the URL.
Do you mean you want to redirect or rewrite the url from https://{hostname}/API/Login?token={TokenValue} to https://{hostname}/emsserver/emserver.dll/API/Login?token={TokenValue} in IIS?
If this is your reuqimrent, I suggest you could try to use url rewrite extension to achieve your reuqirement.
You could install it from this url and add below url rewrite rule into your web.config file.
<system.webServer>
<rewrite>
<rules>
<rule name="Redirect to dll">
<match url="API/Login" />
<action type="Rewrite" url="https://{hostname}/emsserver/emserver.dll/API/Login" />
</rule>
</rules>
</rewrite>
</system.webServer>
I am trying to rewrite the URL on an Azure MVC application. The solution contains many projects, thus has web.config files all over the place.
The URL Rewrite objective is to send all URLs based on the Project "Statistics" to the subdomain "admin", whatever subdomain was called at the origin of the request. (I created this rule independently on my laptop with IIS Manager and imported it manually in one of the projects)
<configuration>
<system.webServer>
<!--Something here. The rule nests at the end of the block. -->
<rewrite>
<rules>
<rule name="Statistics">
<match url="[0-9a-zA-Z-]*.mysite.com/statistics/(.*)" />
<action type="Rewrite" url="https://admin.mysite.com/statistics/{R:1}" />
</rule>
</rules>
</rewrite>
</configuration>
</system.webServer>
So, I am wondering why this rule doesn't seem to be executed:
Is the syntax correct?
In which web.config file should I place this rule, considering that I have five projects in the Solution?
I have React app which ends up being built with webpack. We host an API which this app talks to on Azure and would like to host the UI built on top of it out there as well.
When hitting the URL the first time, and navigating around, all of the history location stuff works. However, when we refresh the page, we receive a 404 error (which is to be expected if IIS is serving this).
Is it possible to configure Azure to handle this sort of thing? Should we just give up on this type of application and host a webpack vm?
Similar questions:
Reactjs HistoryLocation get 404 on refresh
React-router urls don't work when refreshing or writting manually
If do understand your question and situation correctly, the solution would be to redirect all requests to your only one HTML page (assuming index.html).
This can be achieved with the URL rewrite module of IIS.
By default any Azure Web App will have a file in its web root folder named web.config. This is standard XML file. Open it with favorite editor and locate <system.webserver> section. Then place the following additional sections inside. Note, the <rewrite> element should be direct descendant of the <system.webserver> one:
<rewrite>
<rules>
<rule name="Rewrite to index.html">
<match url=".*" />
<action type="Rewrite" url="index.html" />
</rule>
</rules>
</rewrite>
Again, based on the assumption that you serve everything from index.html, you can change this file in the rewrite rule to represent the file you are serving content from.
I am not sure if I am missing something, but I'd really like to have it work like a routing rules table.
However it appears that if I have a service on a farm machine, then the same service should expose the same endpoints on the ARR machine.
I am not sure why thats really needed or what am doing wrong.
Its rather silly. So if I have farm with some application, first of all it has to be deployed to ARR machine, otherwise I get all kinds of 503, 500, 404 etc errors due to services/webpages not being available on the machine where ARR is setup.
For starters, ensure that the "proxy" feature is enabled...
IIS Home -> Application Request Routing -> Server Proxy Settings -> Enable Proxy
Then add rewrite rules to web.config as follows:
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<system.webServer>
<rewrite>
<rules>
<rule name="AppProxy1" stopProcessing="true">
<match url="app1/(.*)" />
<action type="Rewrite" url="http://appserver:8080/{R:1}" />
</rule>
<rule name="AppProxy2" stopProcessing="true">
<match url="app2/(.*)" />
<action type="Rewrite" url="http://appserver:8081/{R:1}" />
</rule>
<!-- add more apps here -->
</rules>
</rewrite>
</system.webServer>
</configuration>
Make sure that the rewrite rules contain absolute URLs, (including http://). This key step signals ARR to run in "proxy" mode.
Additionally, you may need to rewrite outbound HTML links depending on your configuring. More information on that and using ARR as a reverse proxy in general can be found here:
http://www.iis.net/learn/extensions/url-rewrite-module/reverse-proxy-with-url-rewrite-v2-and-application-request-routing
But the basic idea is listed above.
We have a problem occuring on some of our developer workstations: when visiting a URL without a filename (e.g. http://localhost/), IIS 7 returns a 404 error. Everyone is running Windows 7/IIS 7.5 and ASP.NET 4.0. The application pool is configured to use Classic pipeline mode.
Default documents are enabled, and default.aspx is in the default document list.
I enabled failed request tracing, and see this in the log:
OldHandlerName="", NewHandlerName="ExtensionlessUrl-ISAPI-4.0_64bit",
NewHandlerModules="IsapiModule",
NewHandlerScriptProcessor="C:\Windows\Microsoft.NET\Framework64\v4.0.30319\aspnet_isapi.dll", NewHandlerType=""
Later on, I see that this IsapiModule is rejecting the request:
ModuleName="IsapiModule", Notification="EXECUTE_REQUEST_HANDLER", HttpStatus="404",
HttpReason="Not Found", HttpSubStatus="0",
ErrorCode="The operation completed successfully. (0x0)", ConfigExceptionInfo=""
It looks like IIS thinks the ExtensionlessUrl-ISAPI-4.0-64bit should be handling the request. When I look at that module's configuration, it shows that it should be matching path *., so I'm confused why it is matching no path.
A Google search turns up this post on the IIS.net forums from 2005. Unfortunately, no solutions are offered, just an acknowledgement of the problem.
When I update my app pool to use integrated mode, the problem goes away. Unfortunately, it has to run in Classic mode.
What can I do to get IIS to server our default documents again?
It looks like Microsoft released an update that enables the ExtensionlessURL HTTP handler to work with extensionless URLs. Unfortunately, this breaks certain other handlers. In my case, the DefaultDocument handler under classic app pools. The solution is to remove the ExtensionlessURL handlers in our application's web.config:
<system.webServer>
<handlers>
<remove name="ExtensionlessUrl-ISAPI-4.0_32bit" />
<remove name="ExtensionlessUrl-ISAPI-4.0_64bit" />
<remove name="ExtensionlessUrl-Integrated-4.0" />
</handlers>
</system.webServer>
I solved the problem with putting the "StaticFile" handler in HandlerMapping in front of "ExtensionlessUrlHandler-*"
I noticed when removing the managed .NET framework (4.0) from the application pool, it fixed the problem for me too!
We don't use .NET at all in our IIS environment!
I use the following rule in web.config URL Redirect as workaround to solve this:
<system.webServer>
<rewrite>
<rules>
<rule name="Default document rewrite" stopProcessing="true">
<match url="^(.+/)?$" />
<action type="Redirect" url="https://{HTTP_HOST}/default.aspx" />
</rule>
</rules>
</rewrite>
</system.webServer>
Changing the StaticFile order helped to fix the issue, when setting default document to a web site application in IIS, while the root website also had another default document.
Adding the DefaultDocument component to IIS in add/remove windows features and then inserting the name of my default script ( index.php) worked for me.