My AngularJS makes RESTful API calls to my ApiController.
Everything works fine in localhost, but returns a boring and frustrating {"message":"An error has occurred."} when testing on IIS Server.
I have made sure these things are in place. There is a good post in here.
<system.webServer>
<httpErrors existingResponse="PassThrough" />
</system.webServer>
<system.web>
<customErrors mode="Off"/>
</system.web>
On the IIS7, I go to Error Pages >> Edit Feature Settings >> Error Responses is now Detailed errors.
How can we see the detailed exception? Have I missed something else?
Related
I had already published my site using the IIS Manager.
I successfully can access it with my PC but when my colleagues tried to access it, it says,
HTTP Runtime Error.
Is there something wrong in the config file? How come I can access it with no error? Can anyone help us with this?
http runtime error
Is not a lot to go by.
What do the windows event logs say?
What is the website, Asp.net or something else?
If it is asp.net, update this setting and post what error they see:
<?xml version="1.0"?>
<configuration>
<system.web>
<customErrors mode="Off"/>
</system.web>
</configuration>
I've been developing a RESTful API using Web Api 2 and as part of it I implemented batch requests using JSON objects as described in one of their wiki articles (https://aspnetwebstack.codeplex.com/wikipage?title=Web+API+Request+Batching).
This process went smoothly enough while testing using IIS Express, but when I deployed the application in IIS 8 under an IIS application the batch requests no longer function properly. Every sub request returns 404 not found even when the url points to the proper location. However, this only happens when the program is deployed as an application under an IIS website. If you simply drop the program into the root of an IIS website batching behaves correctly.
I have some images of the failure / success responses in Fiddler, but SO won't let me post them. So as an example, a batch POST request made to the IIS website hosted at "http:// domain.com/api/v1.0/" with the inner url set to "realtimedata/queues?queueIds=1" works fine, but when the app is accessible at "http:// domain.com/test/api/v1.0/" the same request with the same inner url returns 404, even though "http:// domain.com/test/api/v1.0/realtimedata/queues?queueIds=1" is a perfectly valid address that can be called fine without using the batch request. (The space in between "http" and "domain in the example urls is just to get around SO's link limit, so imagine they aren't there). Does anyone know what is going on?
After more testing, I found that this was an issue particular to hosting via OWIN in IIS. I had to register my routes against the GlobalConfiguration.Configuration object instead of a new’d up Configuration object and then the 404’s were resolved. I’m not sure why this was the case, but it worked.
Add/modify system.webServer section in your web.config according to this sample:
<system.webServer>
<modules runAllManagedModulesForAllRequests="true" />
<handlers>
<remove name="ExtensionlessUrlHandler-Integrated-4.0" />
<remove name="OPTIONSVerbHandler" />
<remove name="TRACEVerbHandler" />
<add name="ExtensionlessUrlHandler-Integrated-4.0" path="*." verb="*" type="System.Web.Handlers.TransferRequestHandler" resourceType="Unspecified" requireAccess="Script" preCondition="integratedMode,runtimeVersionv4.0" />
</handlers>
</system.webServer>
Please note, that path="/*" replaced with path="*." in add tag.
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.
I've implemented a sample app like the one here. It is a really basic app just to get things started. Everything works fine in IIS on my local machine, I've got it running on my IIS Express as well, but now come the tricky part. I do want to host this on AppHarbor, but I get 404 error. I've started a discussion on the support forum of AppHarbor, and they have taken a screen shot of the error when they run it.
It seems like it is something wrong with the routing since the StaticFile handler is used, but I'm just guessing. Does anyone have any suggestions?
Try and add
<system.webServer>
<modules runAllManagedModulesForAllRequests="true" />
</system.webServer>
to your web.config
I'm wondering how to remove the error messages IIS7 adds to the top of the page.
I have my own 500 and 404 error pages served.
Not needing the error pages I have deleted them, but I am still getting this on top of my page:
The resource you are looking for has been removed, had its name changed, or is temporarily unavailable
Any ideas?
To prevent IIS7 hijacking your error pages, set existingResponse="PassThrough" in your httpErrors section in your web.config file. For example:
<configuration>
<system.webServer>
<httpErrors existingResponse="PassThrough" />
</system.webServer>
</configuration>
You can also go into IIS manager --> Error Pages then click on the right on "Edit feature settings..." And set the option to "Detailed errors" then it will be your application that process the error and not IIS.
Just for addtional information I'll share what helped me:
<system.webServer>
<httpErrors errorMode="DetailedLocalOnly">
</system.webServer>
In such setup I could see detailed errors when developing on my local machine, but they would not be shown to users when remote server is accessed from outside.
You could find more information regarding errorMode here.