I have an ASP.NET MVC 4 application running under IIS 8.5. My previous understanding/experience of these scenarios in MVC is that if a static file exists, it will be served. If it doesn't exist, the path will be sent through MVC routing. This is the desired behaviour, but doesn't seem to be happening.
By default if I create a catchall route at /blah.html and no corresponding static file, IIS serves up a 404 (courtesy of the StaticFile handler). The MVC route is never hit. If the file exists, it is served.
So, I did some Googling and chatting to colleagues and came up with the answer as posted here:
https://stackoverflow.com/a/14327897/1043198
In goes the handler:
<add name="ApiURIs-ISAPI-Integrated-4.0" path="*" type="System.Web.Handlers.TransferRequestHandler" verb="GET,HEAD,POST,DEBUG,PUT,DELETE,PATCH,OPTIONS" preCondition="integratedMode,runtimeVersionv4.0" />
Great! The request now hits the MVC app and my dynamic content is served as expected. Except now, when I put a physical file in place, I get an error again. An uninformative 500 error with the following information (and nothing else):
Module: ManagedPipelineHandler
Notification: ExecuteRequestHandler
Handler: ApiURIs-ISAPI-Integrated-4.0
Error Code: 0x800703e9
What's going on? Why does IIS not fall back to my MVC app when static files don't exist and how come when I fix that, the inverse occurs and static files are no longer served properly? I'm fairly sure this has always been default behaviour in the past.
App pool is running in Integrated mode, CLR v4.0.
After finding various answers and blog posts suggesting enabling runAllManagedModulesForAllRequests, it seems that this - while it works - isn't the right approach.
RAMMFAR does exactly what it says on the tin and runs all requests (including those for "unmanaged" static resources) through all managed modules, which has a performance overhead and can also cause unusual side-effects depending on the modules enabled and the requests run through them.
Turns out the only module required to solve this problem is the UrlRoutingModule which, when the precondition is removed, causes all static resources to be run through MVC routing (when no static file exists):
<remove name="UrlRoutingModule" />
<add name="UrlRoutingModule-4.0" type="System.Web.Routing.UrlRoutingModule"
preCondition="" />
Related
I have an ASPNET Core project that is running a set of RESTful services using C# and Newtonsoft.JSON 11.0.2 which I incorporated using NuGet. When I run everything locally using Visual Studio 2017 and IIS Express, things work fine and my JSON Deserializer efforts work with no issue.
When I publish the solution in a Web Deploy package and then install that application in IIS 10 on a Windows Server 2016 instance in AWS, the deserializer fails. The error is:
Newtonsoft.Json.JsonReaderException: Unexpected character encountered while parsing value: <. Path '', line 0, position 0
It does not matter if I publish in Debug or Release mode.
I ran Postman calls and the JSON being returned is both validate and produces the correct objects. I did see that, in the Solution Explorer, the version is 11.0.2 but in the assets JSON file, the version is pointed to 10.0.1. The .CS project file, when viewed in a text editor outside of Visual Studio, does show 11.0.2.
When I look in the deployed application's folder on the server, I do not see any NewtonSoft DLLs but I do see other NuGet-obtained DLLs. This might not be an issue given how JSON.NET deploys but I thought it was worth mentioning.
I then included a logger and sent the incoming JSON to a file and, again, it all validated as expected.
I have tried everything, ensured CORS is properly implemented both in the application and in IIS. I am at a complete loss as to how to proceed.
Can somebody please help?
Thank you!
I had the same problem and solved by this code in web.config
<system.webServer>
<handlers>
<remove name="WebDAV" />
<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" preCondition="integratedMode,runtimeVersionv4.0" />
</handlers>
<modules>
<remove name="WebDAVModule" />
</modules>
</system.webServer>
I sometimes browse old question that has no/accepted answers and check if they are still in need of some help, or if something can be done to close the cold case.
This post has already been solved, but the cause and the solution were left only in the comments.
If the first character encountered when parsing is <, you can be sure
that is not JSON. Something is probably sending XML or HTML to your
code in the deployed environment. I would look at that angle. This
doesn't seem like a version conflict to me, otherwise you would be
getting a much different error about not being able to load the file
or assembly. I think this is solely a data problem.
Brian Rogers
#Brian Rogers - Thank you SO MUCH for this last comment. I ended up
opening Production to my development machine and then running
Wireshark to see the communications. Turns out that IIS had "GEWT"
instead of "GET" in the allowed methods web.config for the host
website and I was getting rejections in the cloud instead of the JSON.
Every test I ran which generated output was LocalHost but, of course,
none of the real production work used anything local. Once I fixed
that error, everything worked great!
Ken Tola
#ken-tola, can you please self-answer the question and then accept it to close the case.
I have IIS8 (complete, not Express) on Win8. I'm trying to make the PUT verb to work on IIS. In fact, my question would be exactly this: ASP.NET Web API - PUT & DELETE Verbs Not Allowed - IIS 8
However, the highest voted answer (provided by the asker himself) doesn't help me because I just don't have the "ExtensionlessUrl-Integrated-4.0" handler. It is simply missing, along with a host of other handlers, that I've have seen in screenshots from similar posts. My only three handlers (that show up on the Handler Mappings dialog of IIS management console at the server level) are: OPTIONSVerbHandler TRACEVerbHandler and StaticFile.
However much I've tried to find a way to add the "ExtensionlessUrl-Integrated-4.0" handler, I've been unable to do it. I tried even to copy into %systemroot%\System32\inetsrv\config\
applicationHost.config the <add> element (within <handlers>) that the author of the referenced post used to solve the problem: <add name="ExtensionlessUrl-Integrated-4.0" path="*." verb="GET,HEAD,POST,DEBUG,PUT,DELETE" type="System.Web.Handlers.TransferRequestHandler" preCondition="integratedMode,runtimeVersionv4.0" />. But to no avail.
I know this is a very noob question (I'm new to IIS), but just have not been able to find an answer in the documentation. May I get a hand, pls?
In a typical SignalR view it includes...
<script src="/signalr/hubs"></script>
I'm trying to get my head around SignalR and want to look at the javascript within this folder. But I cant find it within my project.
Also, I understand this contains javascript that is generated customised for my hub class etc. Is this correct?
The /signalr/hubs file is dynamically created by the SignalR server when the app boots up. Since the SignalR server hangs off of the /signalr endpoint it then generates the /hubs ontop of it.
Here's how SignalR 2.0.2 generates the file at a high level: https://github.com/SignalR/SignalR/blob/2.0.2/src/Microsoft.AspNet.SignalR.Core/Hubs/DefaultJavaScriptProxyGenerator.cs .
And here's where it determines that the request is to /signalr/hubs (in 2.0.2) https://github.com/SignalR/SignalR/blob/2.0.2/src/Microsoft.AspNet.SignalR.Core/Hubs/HubDispatcher.cs#L235-L253
Finally to answer your last question, it absolutely does. This is why it's dynamically generated. If you'd ever like to get a physical file that represents the /signalr/hubs endpoint you can follow the instructions here: http://www.asp.net/signalr/overview/signalr-20/hubs-api/hubs-api-guide-javascript-client#manualproxy
Hope this helps!
You are correct. It's dynamically generated so that's why you can't see it in visual studio. Enable directory browsing in your web.config by adding
<system.webServer>
<directoryBrowse enabled="true"/>
</system.webServer>
You can then navigate to localhost/signalr/hubs to see the file contents.
I am trying to use mini profiler with WCF.
I keep getting a 404 error:
http://website/mini-profiler-resources/results
There are no results being returned.
I am using two versions of the mini profiler. The NUGET version which doesn't include support for WCF works just fine.
I downloaded the git version so that I can use the WCF integration.
I note that if I run the test project included in the sources 'Sample.Mvc' the same error occurs when the home page is executed, but not for some of the links. I cannot seem to get results for any of my own web site pages. The same 404 occurs.
I have downloaded the master version. I am using .NET 4.0 and studio 2010.
I have the following in the config file, I have tried with and without the handlers.
<system.webServer>
<validation validateIntegratedModeConfiguration="false" />
<modules runAllManagedModulesForAllRequests="true" />
<handlers>
<add name="MiniProfiler" path="mini-profiler-resources/*" verb="*" type="System.Web.Routing.UrlRoutingModule" resourceType="Unspecified" preCondition="integratedMode" />
</handlers>
</system.webServer>
I am definitely calling the start and stop methods.
StackExchange.Profiling.MiniProfiler.Stop();
I have read this: MvcMiniProfiler results request giving 404 in Asp.Net MVC app
It did not help.
I have found a clue as to the problem
The following code in miniprofiler is returning NotFound
The profiler is expecting some kind of guid value to be present, and it isn't.
private static string Results(HttpContext context) {
// this guid is the MiniProfiler.Id property
Guid id;
if (!Guid.TryParse(context.Request["id"], out id))
return isPopup ? NotFound(context) : NotFound(context, "text/plain", "No Guid id specified on the query string");
temporary fix
I took out the code above, and just collected the first guid out of storage, and this fixed the problem. I think this code needs cleaning up. I need to learn GIT, and then try and clean it up myself.
var id = MiniProfiler.Settings.Storage.List(10).FirstOrDefault();
Can you see .../mini-profiler-resources/results-index ?
Handler not required btw. There is a comma in your link but assume that is just a question typo.
Are you calling start last thing in the Application_BeginRequest() and stop in Application_EndRequest()
Have you set GlobalFilters.Filters.Add(new ProfilingActionFilter());?
and are you using WebActivator with a MiniProfilerPackage and MiniProfilerStartupModule
Think I need to tidy up my own implementation as looks like I have some unnecessary cruft.
I'm currently struggling with httphandlers in IIS.
I'm developing a website in .NET4 in VS2010 and Cassini. In this website, i have a gallery, whose pictures are loaded through my handler.
For example http://mywebsite.com/Gallery/123/Pic1.jpg
My HTTP Handler gets the id 123 and returns the picture from the database (simplified).
So, everything works fine in Cassini (VS integrated webserver) and in IIS7 in "integrated mode". Pictures are loaded like they should.
But I have to deploy this site on a shared hoster, who is using IIS6.
After many searching and own logging, I found out, the the request isn't routed to my handler, and so I get a 404 from IIS.
My definition which is enough for IIS7 integrated mode:
<system.web>
<handlers>
<add verb="*" path="Gallery/*/*" type="[coorect Type spec]" />
</handlers>
</system.web>
For IIS7 in classic mode I had to add
<system.webServer>
<handlers>
<add name="ImageHandler" verb="*" path="Galler</*/*" type="[type]" modules="IsapiModule" scriptProcessor="c:\windows\Microsoft.net\framework\v4.0.30319\aspnet_isapi.dll"/>
</handlers
</system.webServer>
This last config only works whith the stuff in the module and scriptprocessor attributes...
But this config doesn't work in IIS6....
Can anyone help me ?
The issue is that IIS6 typically decides what ISAPI handler to pass the request to by using the file extension. So it sees .jpg and tries to serve a static file from that path. This is also what IIS7 refers to as classic mode. And you'll note you are referencing aspnet_isapi.dll in your configuration because it needs to be told what should handle this. Once you've passed it into aspnet_isapi, the asp.net http handling pipeline kicks in and you can execute your handler.
The easiest fix would be to find a host that supports IIS7. Failing that, you could see if they have any url rewriting options. With that, you could rewrite things so that you append an .ashx on the url, which will let IIS6 grab it and put it into the asp.net pipeline and your handler would fire. You could also see if they allow wildcard mappings, but that is a very tall order for most shared hosts.