When requesting images on path site/image.jpg or site/image.jpg?process=no i only get a 404 while site/image.jpg?maxwidht=2000 works just fine.
removing the servicestack handler from web.config resolves the issue:
<system.webServer>
<handlers>
<add path="*" name="ServiceStack.Factory" type="ServiceStack.HttpHandlerFactory, ServiceStack" verb="*" preCondition="integratedMode" resourceType="Unspecified" allowPathInfo="true" />
</handlers>
How can I make servicestack and imageresizer run together on IIS8?
That configuration causes all requests to be given to ServiceStack, preventing middleware from working. It's a terrible practice if one values interoperability, and I'm suprised to see it.
Because if its location at the top of the queue, it is preventing the StaticFileModule & StaticFileHandler from handling static requests, yet failing to serve them itself.
You may want to install ImageResizer in a subfolder/sub application to avoid a conflict. Example w/ service stack.
ImageResizer has a way to 'fixup' frameworks which don't handle VPPs correctly. In this case, static files aren't getting handled correctly, so the detection doesn't work. You can set <pipeline vppUsage="Always" /> to force this code path.
Related
I configured IIS ApplicationInitialization as recommended in the documentation
add initializationPage='/warm-up'.
I implemented a /warm-up endpoint on my app deploy it to both staging and production slots.
When the app starts/restarts/swap the endpoint is NOT called because I can't see it in the logs.
When I hit the endpoint manually, it works fine!
What I'm trying to achieve is:
When I start/restart/swap my app
I want a page (/warm-up) to be called in order to preload the app
So the first call from a real client doesn't have to suffer from the app loading time
Currently, I implemented a service that runs when the app starts (IStartupfilter)
But the app, hence the filter, is not running before a first request hits the server!
So I want to hit the server instance as soon as possible with appInit
We have more than 5 instances at some time of the day
initializationPage is an IIS thing, it will not help you start up the ASP.NET Core application before the first request hits.
Instead, what you will need to do is configure the Application Initialization Module for ASP.NET Core. According to this documentation, you will need to enable the IIS Application Initialization module (which you probably already did if you could configure the initializationPage) and then modify the generated web.config to include the applicationInitialization node to the webServer section:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<location path="." inheritInChildApplications="false">
<system.webServer>
<handlers>
<add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModuleV2" resourceType="Unspecified" />
</handlers>
<aspNetCore processPath="dotnet" arguments=".\MyApp.dll" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout" hostingModel="inprocess" />
<applicationInitialization doAppInitAfterRestart="true" />
</system.webServer>
</location>
</configuration>
This should start the ASP.NET Core application as soon as the IIS website starts, so there should be no delay. You will not need an initialization page then and can just initialize the ASP.NET Core application as the host starts.
I'm attempting to us the RunFromPackage App Setting for an Azure Web Site.
I'm using the following stack
asp.net core (out-of-process)
Targeting .Net Framework 4.7.2
and I can no longer get my web application to run correctly. when I hit the url all I get is
"The page cannot be displayed because an internal server error has occurred."
in the response.
I have launched my application using the Kudu powershell window with the command
".{applicationName}.exe"
and it start up fine. No errors or anything
Viewing the event viewer logs all I see is
APPLICATION_MANAGER::~APPLICATION_MANAGER | this=000001D1CD999A60 [TID 8872] [PID 8028]
When turning on the Failed Request Tracing Logs I see the following relevant information
URL_CACHE_ACCESS_START RequestURL="/favicon.ico" 15:37:30.729
URL_CACHE_ACCESS_END PhysicalPath="", URLInfoFromCache="false", URLInfoAddedToCache="true", ErrorCode="The operation completed successfully.
(0x0)" 15:37:30.729
GENERAL_GET_URL_METADATA PhysicalPath="", AccessPerms="545" 15:37:30.729
HANDLER_CHANGED OldHandlerName="", NewHandlerName="aspNetCore", NewHandlerModules="AspNetCoreModule", NewHandlerScriptProcessor="", NewHandlerType="" 15:37:30.729
MODULE_SET_RESPONSE_ERROR_STATUS
Warning ModuleName="IIS Web Core", Notification="BEGIN_REQUEST", HttpStatus="500", HttpReason="Internal Server Error", HttpSubStatus="0", ErrorCode="Access is denied.
(0x80070005)", ConfigExceptionInfo=""
I have tried to turn on the asp.net core module logging but I get no log files. I have also tried to turn on the stdoutlog but nothing is appearing to log.
Here is a copy of my web.config
<configuration>
<system.webServer>
<security>
<access sslFlags="SslNegotiateCert" />
</security>
<serverRuntime uploadReadAheadSize="30000000" />
<handlers>
<add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModule" resourceType="Unspecified" />
</handlers>
<aspNetCore processPath="%LAUNCHER_PATH%" stdoutLogEnabled="true" stdoutLogFile="\\?\%home%\LogFiles\stdout" hostingModel="OutOfProcess" arguments="%LAUNCHER_ARGS%">
<handlerSettings>
<handlerSetting name="debugFile" value="\\?\%home%\LogFiles\aspnetcore-debug.log" />
<handlerSetting name="debugLevel" value="FILE,TRACE" />
</handlerSettings>
</aspNetCore>
</system.webServer>
</configuration>
I'm not really sure what is going on. All I can gather is something is going wrong with the IIS Module. from the error message it appears that it cannot read or process my web.config ErrorCode="Access is denied."
Strangely enough I had a previous build of the application up and running. I have tried to isolate the changes that may have broke the site but I cant seem to find out what has cause this.
It appears that this was due to the fact I was trying to get only client authentication on one endpoint.
The following setting
<access sslFlags="SslNegotiateCert" />
in the web.config, and Require incoming Certificate in the App Settings caused my issue.
I then tried the feature of "Certificate exclusion paths" but having this and the web.config access node makes the web server very upset and causes the error message
"The page cannot be displayed because an internal server error has occurred."
I had to remove the node from my web.config file, leave the Required SSL, and set my Certificate Exclusion path and everything turned back online.
I've read many similar issues but none of the resolutions solved my problem. So, here is my case.
I have a NET Core 2.1.1 app that runs beautifully within VS2017 and when published to my desktop running Win10 Pro and IIS10, i.e. running it outside of VS2017. But, when I deploy the app to a remote server Win2012 R2 with IIS8.5, I get the following issues with it.
I have followed different pages on deploying net core apps like this one.
https://learn.microsoft.com/en-us/aspnet/core/host-and-deploy/iis/index?view=aspnetcore-2.1
When attempting to reach the site I get error 500 Internal Server Error.
IIS manager complains about the generated web.config when clicking on any of the site's settings e.g. Net authorization, Net Error pages etc...
Even when setting the stdoutLogEnabled to true, I don't get any log files. I even tried adding custom details flags in the web.config yet still nothing changed.
This is the generated web.config, and I hope someone points me in the right direction.
Thanks.
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<location path="." inheritInChildApplications="false">
<system.webServer>
<handlers>
<add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModule" resourceType="Unspecified" />
</handlers>
<aspNetCore processPath="dotnet" arguments=".\eSignWebMVC.dll" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout" />
</system.webServer>
</location>
</configuration>
<!--ProjectGuid: 72897161-bbbb-4f20-a12c-7f33922ea6bc-->
So I finally got this to work and I HAD to install the latest bundle v2.2.2 even though my app is targetting Net Core 2.1.1, but Microsoft's horrible technology still didn't make the app to run with the 2.1.1. bundle. Total waste of time and effort on such a stupid thing!!
What's the meaning of still providing the prior bundles if none of them does anything?
I have an ASP.NET MVC3 application .NET4 in which a routing exists for content files, which are served from a resource inside a class library.
Routing is configured as follows
routes.MapRoute("Resources", "Default{Content}/{*contentpath}", new {controller = "Resource", action="GetResource"});
So if there is a request DefaultMvcScripts/test.js, the GetResource method will be called.
However, when converted to MVC4 ,.NET4.5 this doesn't work anymore, GetResource is not called anymore, it bypasses routing even if I put
routes.RouteExistingFiles = true;
For a request DefaultMvcScript/test (without extension), routing is not ignored (I can see GetResource being called).
Can I have the old behaviour back, so that even if I specify an extension, routing is honoured.
I think you're just missing the last step - you need to configure your app so that the handler pipeline pays attention to requests for static files.
In they system.webserver section of the web config you need to add a handler for the static files you want to serve. You need to use the TransferRequestHandler
<add name="staticHandler" path="*.js" verb="GET" type="System.Web.Handlers.TransferRequestHandler" preCondition="integratedMode,runtimeVersion4.0"/>
See Jon Galloway's article for a complete description
http://weblogs.asp.net/jongalloway/asp-net-mvc-routing-intercepting-file-requests-like-index-html-and-what-it-teaches-about-how-routing-works
Apparently, adding this to the web.config restores previous behaviour:
<modules>
<remove name="UrlRoutingModule-4.0" />
<add name="UrlRoutingModule-4.0" type="System.Web.Routing.UrlRoutingModule" preCondition="" />
</modules>
The preCondition="" seems to be the trick.
Source: http://www.britishdeveloper.co.uk/2010/06/dont-use-modules-runallmanagedmodulesfo.html
I have written a site that uses ASP.NET MVC Web API and everything is working nicely until I put it on the staging server. The site works fine on my local machine and on the dev web server. Both dev and staging servers are Windows Server 2008 R2.
The problem is this: basically the site works, but there are some API calls that use the HTTP PUT method. These fail on staging returning a 404, but work fine elsewhere.
The first problem that I came across and fixed was in Request Filtering. But still getting the 404.
I have turned on tracing in IIS and get the following problem.
168. -MODULE_SET_RESPONSE_ERROR_STATUS
ModuleName IIS Web Core
Notification 16
HttpStatus 404
HttpReason Not Found
HttpSubStatus 0
ErrorCode 2147942402
ConfigExceptionInfo
Notification MAP_REQUEST_HANDLER
ErrorCode The system cannot find the file specified. (0x80070002)
The configs are the same on dev and staging, matter of fact the whole site is a direct copy.
Why would the GETs and POSTs work, but not the PUTs?
For those of you who do not have WebDAV enabled but are still running into this issue using MVC 4's Web API's...
Steve Michelotti documented a solution that worked for me here.
At the end of the day, I enabled all verbs (verb="*") to the ExtensionlessUrlHandler-Integrated-4.0 handler in my web config.
<system.webServer>
<validation validateIntegratedModeConfiguration="false" />
<modules runAllManagedModulesForAllRequests="true" />
<handlers>
<remove name="ExtensionlessUrlHandler-Integrated-4.0" />
<add name="ExtensionlessUrlHandler-Integrated-4.0" path="*." verb="*" type="System.Web.Handlers.TransferRequestHandler" resourceType="Unspecified" requireAccess="Script" preCondition="integratedMode,runtimeVersionv4.0" />
</handlers>
</system.webServer>
Those IIS servers have web-dav module installed on them and i bet it is not needed and it was installed because the person installing ticked all boxes.
Just remove web-dav from iis.
Alternatively use web.config to remove web dav module:
<system.webServer>
<modules>
<remove name="WebDAVModule" />
</modules>
...
It seems there are a number of reasons that this occurs. None of the above quite worked for me. I already had the ExtensionlessUrlHandler settings in web.config with all the required HTTP verbs. In the end I had to make the following changes in IIS:
In IIS select your website and double-click Handler Mappings
Find ExtensionlessUrlHandler-ISAPI-4.0_32bit and double-click
In the dialog that appears, click Request Restrictions
On the Verbs tab add the missing HTTP verbs separated by commas (in my case it was PUT and DELETE
Click Ok where required and answer Yes in the Edit Script Map dialog that pops up.
Repeat for ExtensionlessUrlHandler-ISAPI-4.0_64bit
Hope this helps somebody :)
My hosting provider could NOT uninstall WebDAV as this would affect everyone.
This, runAllManagedModulesForAllRequests="true" , worked but was not recommended.
Many fixes included removing the module for WebDAVModule but that still didn't work. I removed the handler also, and finally I could use all verbs POST GET PUT DELETE.
Remove WebDAVModule and WebDAV in modules and handlers.
<modules>
<remove name="WebDAVModule" />
</modules>
<handlers>
<remove name="WebDAV" />
</handlers>
I fixed this removing the UrlScan ISAPI filter
In my case, none of these solutions applied.
I fixed it by changing my app pool to Integrated instead of Classic.
The handler:
<add name="ExtensionlessUrlHandler-Integrated-4.0" path="*." verb="*" type="System.Web.Handlers.TransferRequestHandler" preCondition="integratedMode,runtimeVersionv4.0" />
is not going to work with a Classic app pool, since its preCondition is integratedMode.
Rick Strahl from West-Wind recommended the following:
< handlers>
< remove name="ExtensionlessUrlHandler-Integrated-4.0"/>
< add name="ExtensionlessUrlHandler-Integrated-4.0"
path="*."
verb="GET,HEAD,POST,DEBUG,PUT,DELETE,PATCH,OPTIONS"
type="System.Web.Handlers.TransferRequestHandler"
preCondition="integratedMode,runtimeVersionv4.0"
/>
< /handlers>
Which Worked very well for me.
Hi For me none of the solutions worked. I finally got it working doing this :
1) In IIS select you application.
2) Go to Request Filtering
3) Then select the HTTP Verbs tab
4) I found the PUT and other verbs to have allowed to false but wasn't able to just edit so I removed the verb then either in the pane on the right select allow verb or right click on the list and select it. Enter the verb you're having troubles with and voilà !
Hope this will help someone !
I resolved this by changing my application pool for the website to Integrated mode when it was previously on Classic mode.