Why is IIS app pool stopping after long request? - asp.net-core-webapi

I have created an API that makes calls to other APIs and returns a very long string (approximately 200mb).
Every time I make a request to it, it takes a long time to run then only responds with 4mb (exactly) of response and shut down the application pool.
I tried these solutions :
Increase executionTimeout and shutdownTimeout to 01:00:00
Setting bufferingOn to false and bufferingLimit to 1073741824
Disable Rapid-Fail Protection
<?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=".\Program.exe" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout" hostingModel="inprocess" />
</system.webServer>
</location>
<system.web>
<httpRuntime executionTimeout="3600" shutdownTimeout="3600" />
</system.web>
</configuration>
<location path="Internal Interfaces">
<system.webServer>
<asp bufferingOn="false">
<limits bufferingLimit="1073741824" />
</asp>
</system.webServer>
</location>
Thanks,
Khalenn

You can try this setting to increase the request Limits in iis.
IIS Setting: Request Limits:
<configuration>
<system.webServer>
<security>
<requestFiltering>
<requestLimits maxAllowedContentLength="2147483648" />
</requestFiltering>
</security>
<system.webServer>
</configuration>
With the above maxAllowedContentLength, users can upload files that are 2 GB in size.
Edit the request filtering feature settings and the request limits using IIS manager:
Open IIS Manager.
Select the website that you want to configure.
Select Requests Filtering and open it by double-clicking the icon. The Request Filtering pane displays.
From the Actions pane on the right hand side of the screen click Edit Feature Settings... link. The Edit Request Filtering Settings window displays.
In the Request Limits section, enter the appropriate Maximum allowed content length (Bytes) and then click the OK button.
Restart IIS.

Related

How to identify why IIS is not able to read the web.config?

I'm trying to get a basic .NET 5.0 app running on a new dev server and it is giving me an error trying to read the web.config with no Config Error.
The hosting framework is installed
And the App Pool user and folder path are the defaults.
I even ran Process Monitor and the file is successfully read, so it's the content that is giving it a hard time. This is the web.config content.
<?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=".\TestApp.Web.dll" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout" hostingModel="inprocess" />
</system.webServer>
</location>
</configuration>
The environment variable has been set as well
There are also no errors in the Event Viewer.
Thoughts?
--- EDIT ---
The file shows the IIS user as having access
I fixed it with a repair install of the Hosting framework install

how to exceed maximum iis post request Limit?

i have an asp web application, and a service witch people use to send large chunks of date trough HTTP POST.
bu Data riches many megabytes rejects the request and return nothing.
i tried to use this but didn't work. to change the limit to 10 megabytes.
<system.webServer>
<security>
<requestFiltering>
<requestLimits maxAllowedContentLength="10000000" />
</requestFiltering>
</security>
</system.webServer>
Add this to your web.config, too
<configuration>
<system.web>
<httpRuntime maxRequestLength="1000000" />
</system.web>
</configuration>
Check this link for more info: http://www.iis.net/configreference/system.webserver/security/requestfiltering/requestlimits

IIS7 - The request filtering module is configured to deny a request that exceeds the request content length

I want to upload images, it works fine on my machine but when I put my website on IIS7 server for public I can't upload anything.
Error
The request filtering module is configured to deny a request that
exceeds the request content length.
Most likely causes
Request filtering is configured on the Web server to deny the request
because the content length exceeds the configured value.
Things you can try
Verify the configuration/system.webServer/security/requestFiltering/requestLimits#maxAllowedContentLength
setting in the applicationhost.config or web.config file.
system.webServer in Web.config
<system.webServer>
<validation validateIntegratedModeConfiguration="false" />
<modules runAllManagedModulesForAllRequests="true" />
<security>
<requestFiltering>
<requestLimits maxAllowedContentLength="1048576" />
</requestFiltering>
</security>
</system.webServer>
As you can see I set my maxAllowedContentLength to 1gb. Restarted my website and still getting this error. I made an /uploads/ folder on my file system where it suppose to be as well. Have no idea what causes this error and why I can't upload images.
<configuration>
<system.web>
<httpRuntime maxRequestLength="1048576" />
</system.web>
</configuration>
From here.
For IIS7 and above, you also need to add the lines below:
<system.webServer>
<security>
<requestFiltering>
<requestLimits maxAllowedContentLength="1073741824" />
</requestFiltering>
</security>
</system.webServer>
The following example Web.config file will configure IIS to deny access for HTTP requests where the length of the "Content-type" header is greater than 100 bytes.
<configuration>
<system.webServer>
<security>
<requestFiltering>
<requestLimits>
<headerLimits>
<add header="Content-type" sizeLimit="100" />
</headerLimits>
</requestLimits>
</requestFiltering>
</security>
</system.webServer>
</configuration>
Source: http://www.iis.net/configreference/system.webserver/security/requestfiltering/requestlimits
I had similar issue, I resolved by changing the requestlimits maxAllowedContentLength ="40000000" section of applicationhost.config file, located in "C:\Windows\System32\inetsrv\config" directory
Look for security Section and add the sectionGroup.
<sectionGroup name="requestfiltering">
<section name="requestlimits" maxAllowedContentLength ="40000000" />
</sectionGroup>
*NOTE delete;
<section name="requestfiltering" overrideModeDefault="Deny" />

Enabling PUT on IIS 7.5 for an ASHX handler using Windows Authentication

I have an ASP.NET (.NET 4) website that uses http PUT for an .ashx generic handler. The PUT call originates from a Silverlight front end. All works in VS 2010 on my local machine (Cassini web server).
Then I deployed to an IIS7.5 Win Server 2008 R2 box.
The silverlight/website is fine, but PUT calls to the .ashx handler are met with a Windows Login Prompt.
This is a local intranet so Windows Authentication (with NTLM & Negotiate providers) is the only enabled authentication.
Then I read this: http://blogs.msdn.com/b/joseph_fultz/archive/2009/07/23/enabling-the-put-verb-with-handlers-and-iis-7-0.aspx
I've followed his suggestion and I can now make PUT calls via my .ashx handler. Problem is only folks in the Administrators Group of the web server can do this. No one else can. They are met with the windows login prompt.
Any idea what this could be?
I can't give Everyone in the company Admin privileges on the webserver. They would no doubt cut off one of my hands, eat said hand in front of me, and then show me the door.
Ok I figured it out.
Here are the key configuration elements in IIS 7.5:
Under Windows Authentication / Providers - NTLM had to be on top of Negotiate
Domain Users needed write access to the directory containing the ashx handler
URL Authorization was not enabled as a role on the web server. I added it and then stuck this in the web.config under system.webServer:
<security>
<authorization>
<remove users="*" roles="" verbs="" />
<add accessType="Allow" users="*" verbs="GET,HEAD,POST,PUT,DELETE,DEBUG" />
</authorization>
</security>
(I'll trim that down a bit, but for now it works)
My entire system.webServer element is as follows:
<system.webServer>
<modules>
<remove name="WebDAVModule" />
</modules>
<defaultDocument>
<files>
<clear />
<add value="default.aspx" />
</files>
</defaultDocument>
<handlers accessPolicy="Read, Write, Execute, Script">
<remove name="WebDAV" />
<remove name="SimpleHandlerFactory-Integrated-4.0" />
<remove name="SimpleHandlerFactory-Integrated" />
<add name="SimpleHandlerFactory-Integrated" path="*.ashx" verb="GET,HEAD,POST,DEBUG,PUT" type="System.Web.UI.SimpleHandlerFactory" resourceType="Unspecified" requireAccess="Write" preCondition="integratedMode" />
<add name="SimpleHandlerFactory-Integrated-4.0" path="*.ashx" verb="GET,HEAD,POST,DEBUG,PUT" type="System.Web.UI.SimpleHandlerFactory" resourceType="Unspecified" requireAccess="Write" preCondition="integratedMode,runtimeVersionv4.0" />
</handlers>
<security>
<authorization>
<remove users="*" roles="" verbs="" />
<add accessType="Allow" users="*" verbs="GET,HEAD,POST,PUT,DELETE,DEBUG" />
</authorization>
</security>
</system.webServer>
That did it.

How do I protect static files with ASP.NET form authentication on IIS 7.5?

I have a website running on a IIS 7.5 server with ASP.NET 4.0 on a shared host, but in full trust.
The site is a basic "file browser" that allows the visitors to login and have a list of files available to them displayed, and, obviously, download the files. The static files (mostly pdf files) are located in a sub folder on the site called data, e.g. http://example.com/data/...
The site uses ASP.NET form authentication.
My question is: How do I get the ASP.NET engine to handle the requests for the static files in the data folder, so that request for files are authenticated by ASP.NET, and users are not able to deep link to a file and grab files they are not allowed to have?
If you application pool is running in Integrated mode then you can do the following.
Add the following to your top level web.config.
<system.webServer>
<modules>
<add name="FormsAuthenticationModule" type="System.Web.Security.FormsAuthenticationModule" />
<remove name="UrlAuthorization" />
<add name="UrlAuthorization" type="System.Web.Security.UrlAuthorizationModule" />
<remove name="DefaultAuthentication" />
<add name="DefaultAuthentication" type="System.Web.Security.DefaultAuthenticationModule" />
</modules>
</system.webServer>
Now you can use the standard ASP.NET permissions in your web.config to force forms authentication for all files in the directory.
<system.web>
<authorization>
<deny users="?" />
</authorization>
<authentication mode="Forms" />
</system.web>
I had the same problem with getting roles to authenticate. Through trial and error I finally got it to work with a small edit to #Joel Cunningham's code:
<modules runAllManagedModulesForAllRequests="true" >
I used these two sites as references: http://forums.iis.net/t/1177964.aspx and http://learn.iis.net/page.aspx/244/how-to-take-advantage-of-the-iis-integrated-pipeline/
This is an old thread, but I happened on it and ran into the same problem as Egil. Here is the version of Joel's fix that includes roles:
<modules runAllManagedModulesForAllRequests="false">
<remove name="FormsAuthenticationModule" />
<add name="FormsAuthenticationModule" type="System.Web.Security.FormsAuthenticationModule" />
<remove name="UrlAuthorization" />
<add name="UrlAuthorization" type="System.Web.Security.UrlAuthorizationModule" />
<remove name="RoleManager" />
<add name="RoleManager" type="System.Web.Security.RoleManagerModule" />
<remove name="DefaultAuthentication" />
<add name="DefaultAuthentication" type="System.Web.Security.DefaultAuthenticationModule" />
</modules>
Addendum:
As #eych noted the accepted answer also blocks access to the ~/Content folder (or wherever you have your CSS), and ~/Scripts, and so on.
If you want to allow exceptions -- i.e. allow certain files/folders to be accessible by unauthenticated users -- you can do that by means of the location element. Add the following to web.config:
<location path="Content">
<system.web>
<authorization>
<allow users="*" />
</authorization>
</system.web>
</location>
Update:
An alternative solution is to is to leave access on by default -- which will allow access to your CSS / JavaScript / etc. -- and apply the "lock" (only) to the folder where the static content is stored:
<location path="data">
<system.web>
<authorization>
<deny users="?"/>
</authorization>
</system.web>
</location>
Caveat: in our case (an MVC site) we needed to decorate all our controller actions (except login) with [AuthorizeAttribute]. Which is a good idea anyway, but had previously not been necessary (because previously any unauthorized request was redirected to the login page).
I wanted to know why it would be required to re-add modules (with default options) that are added by default for the Integrated Pipeline, so I dug a little deeper.
You need to remove and re-add the modules because, by default, the modules aren't added with the default options. They have a precondition added for backwards compatibility to run only for content handled by a registered ASP.NET handler (e.g., .aspx pages).
The default looks like this:
<add name="FormsAuthentication" type="System.Web.Security.FormsAuthenticationModule"
preCondition="managedHandler" />
By removing the modules and re-adding them without a precondition, those individual modules run for every request (including your static content). It is more granular than enabling runAllManagedModulesForAllRequests.
You can read about it in a couple articles from when the Integrated Pipeline was introduced with IIS 7:
ASP.NET Integration with IIS 7
How to Take Advantage of the IIS 7.0 Integrated Pipeline
Note that there is a typo or the module name in the second article (and #John's answer) was changed from FormsAuthenticationModule to FormsAuthentication at some point.
The set of working modules in IIS 7.5 thru 8.5 looks like this for me:
<system.webServer>
<modules>
<!-- Re-add auth modules (in their original order) to run for all static and dynamic requests -->
<remove name="FormsAuthentication" />
<add name="FormsAuthentication" type="System.Web.Security.FormsAuthenticationModule" />
<remove name="DefaultAuthentication" />
<add name="DefaultAuthentication" type="System.Web.Security.DefaultAuthenticationModule" />
<remove name="RoleManager" />
<add name="RoleManager" type="System.Web.Security.RoleManagerModule" />
<remove name="UrlAuthorization" />
<add name="UrlAuthorization" type="System.Web.Security.UrlAuthorizationModule" />
</modules>
</system.webServer>
If you application pool is running in Classic mode, you can do the following. You will have to repeat these steps for each file extension you'd like to handle, but I'm using .html here.
First, add a page build provider to the Web.config:
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<system.web>
<compilation>
<buildProviders>
<add type="System.Web.Compilation.PageBuildProvider" extension=".html"/>
</buildProviders>
</compilation>
</system.web>
</configuration>
Then add a page handler factory:
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<system.web>
<httpHandlers>
<add type="System.Web.UI.PageHandlerFactory" path="*.html" verb="*"/>
</httpHandlers>
</system.web>
</configuration>
Then add a page handler:
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<system.webServer>
<handlers>
<add scriptProcessor="C:\Windows\Microsoft.NET\Framework\v4.0.30319\aspnet_isapi.dll" requireAccess="Script" preCondition="classicMode,runtimeVersionv2.0,bitness32" path="*.html" verb="GET,HEAD,POST,DEBUG" modules="IsapiModule" name="HtmlHandler-Classic-32" />
<add scriptProcessor="C:\Windows\Microsoft.NET\Framework64\v4.0.30319\aspnet_isapi.dll" requireAccess="Script" preCondition="classicMode,runtimeVersionv2.0,bitness64" path="*.html" verb="GET,HEAD,POST,DEBUG" name="HtmlHandler-Classic-64"/>
</handlers>
</system.webServer>
</configuration>
This worked for me. (Credit: http://www.ifinity.com.au/Blog/EntryId/66/How-To-301-Redirect-htm-or-html-pages-to-DotNetNuke-aspx-pages.)

Resources