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.
Related
My application using spring rest and deployed in Azure server. Created rest apis using spring rest.
Am able to access all rest urls, except in one scenario.
for eg: http://mydomain123.com/api/abc , http://mydomain123.com/api/xyz/abc
Am able to access above urls
http://mydomain123.com/api/bin , http://mydomain123.com/api/xyz/bin , http://mydomain123.com/api/bin/dfdff
But above urls having bin word with which am getting below error:
The resource you are looking for has been removed, had its name changed, or is temporarily unavailable.
I am trying as below,but not working at all:
<configuration>
<system.webServer>
<rewrite>
<rules>
<rule name="Main Rule" stopProcessing="true">
<match url=".*" />
</rule>
</rules>
</rewrite>
</system.webServer>
</configuration>
Please someone help me out to fix above issue (I should be able to access rest apis even having word "bin" in it)
Please make sure to place the web.config file at the root of the application folder.And after making changes try to restart the application.
Also check this for matching pattern .
Also check to allow wide range of urls by allowing CORS in any of the ways mentioned in references here
spring-boot-security-cors
how-to-enable-spring-boot-cors-example-crossorigin
/spring-boot-security-cors
ex:
registry.addMapping("/*")
.allowedOrigins("*").allowedMethods("*");
And as a workaround try to add
<system.webServer> <modules runAllManagedModulesForAllRequests="true"/> </system.webServer>
in web.config
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 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'm in the process of migrating from one site to another and, although the websites sit on the same server, they aren't in the same application pool.
As such, what I'm proposing is similar to the IIS article 'Reverse Proxy with URL Rewrite v2 and Application Request Routing'.
My setup as as follows:
Default Website (accepts connections on *:80 and *:443).
New Website (accepts connections on *:81)
I've enabled proxying in the ARR module and have one rewrite rule in 'New Website'. Currently, I only have one page in the new site (new-page), but this will increase gradually as we migrate over.
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<system.webServer>
<rewrite>
<rules>
<rule name="Reverse Proxy to New Website" stopProcessing="true">
<match url="^new-page" />
<action type="Rewrite" url="http://www.mysite.com:81/new-page" />
</rule>
</rules>
</rewrite>
</system.webServer>
</configuration>
When I go to www.mysite.com/index.htm, I see my old homepage, which is correct.
However, if I go to www.mysite.com/new-page, I receive an error:
HTTP Error 502.3 Bad Gateway
The server returned an invalid or unrecognized response
Any help with this would be greatly appreciated.
Edit:
I have also enabled WinHttp tracing, and a log of the request today can be found here at pastebin.
I have some further information (retrieved from IIS Failed Request Logging) below.
It appears that ARR has an issue with headers that have spaces in.
The new application has a single header with a space, and replacing it with a hyphen fixed the issue.
I just ran into this. However, my problem had to do with conflicting cookies.
A good test is to use a different browser (or incognito in Chrome). If it works on the other browser, it could be the cookies. Try deleting the cookies to see if that helps. If it's something you can control, try changing the cookie name between different sites/environments you may have. If it's out of your control (you're doing a reverse proxy to some tool you've purchased, this may not be possible).
I have to set up a couple of apps on a new intranet server (Win 2008 R2 Standard SP1). I have been having some difficulty with a URL Rewriter rule. I had a similar rule working great on my local IIS (Win 7). The rule is designed to create a reverse proxy for a web service that enables jQuery AJAX requests from the client to avoid XSS.
The rule is as below and if I use this as is, and type an example URL into the browser:
http://srv01.domain.com/serviceproxy/workflow/Users/GetUsers?q=smith&max=10
I get a 404 response from the server. If I change the type to "Redirect" I get the response from the server expected (but obviously this will void my attempt to avoid XSS).
<rewrite>
<rules>
<rule name="Reverse Proxy - WCF Service" stopProcessing="true">
<match url="serviceproxy/workflow/(.+)" />
<action type="Rewrite" url="http://srv01.domain.com/WorkflowService/{R:1}" />
</rule>
</rules>
</rewrite>
Any ideas what might be missing from the server configuration? Is it a security setting somewhere that needs to be configured to allow the rewrite to occur?
I found my issue. I didn't have Application Request Routing installed on this server. Either I forgot installing it on my other server or it was already on there for another reason.
Found this article that helped me resolve it.
http://www.iis.net/learn/extensions/url-rewrite-module/reverse-proxy-with-url-rewrite-v2-and-application-request-routing
Had a similar issue on Windows 2008, IIS 7.5
The problem was that the app pool was in integrated mode. that caused issues with the rewrite.
Redirect was always ok, but rewrite always failed.
changed the app pool to classic mode and problem solved (at least for now).
a better solution might be http://forums.iis.net/t/1200671.aspx?ARR+URl+Rewrite+is+not+working+for+external+servers
right at the end. but i havent tried it.