I've searched for a while, but can't seem to find anything that deals with the specific situation I'm facing.
I've set maxRequestLength to 5MB like so...
<httpRuntime maxRequestLength="5120"/>
and then I've set maxAllowedContentLength to 20MB...
<requestLimits maxAllowedContentLength="20971520"/>
For some reason though the lower limit is ignored. My application is allowing files up to 20MB to be uploaded.
It thought anything over maxRequestLength should trigger a .Net exception.
The application is classic ASP, with a custom Interop COM object managing the upload.
If I upload directly with .Net, the limits are respected, and the exceptions are thrown.
Does anyone know why maxRequestLength is ignored for ASP and/or COM?
This is happening in IIS 8 and IIS 10.
I have the following set, if it makes a difference...
<modules runAllManagedModulesForAllRequests="true"/>
Does anyone know why maxRequestLength is ignored for ASP and/or COM?
As well as all the other system.web settings, it is an ASP.NET setting. You already have experienced. So it's normal to be ignored for non ASP.NET requests.
From httpRuntime Element (ASP.NET Settings Schema)
Configures ASP.NET HTTP run-time settings that determine how to
process a request for an ASP.NET application.
Related
My session is getting reset after I upload file using a flash plugin. I put some logging into the Session_Start function and I see its called every time I upload a file using the flash plugin. I'm not sure what would be causing this. This is working locally for me in dev environment with the same server and settings.
I'm using
IIS 7 with Windows Server 2008 R2.
My app:
ASP.NET MVC .NET 4.0 (legacy app)
I upload other files on the site without the flash plugin and those work. This functionality worked before. But for some reason now it stopped working.
Any ideas on what could be causing this to occur?
First Microsoft End of support for Windows Server 2008 and Windows Server 2008 R2.
The default server configuration does not allow you to upload files with Flash Uploader.
You could try below settings:
1)Disabling Request Validation:
ASP.NET automatically validates a request or rejects it if there are dangerous fields. However, HTML5/Flash Uploader sends files data in text fields (instead of binary ones) due to Adobe Flash Player limitations. IIS may treat this behavior as potentially dangerous and, thus, you can get the following error during uploading:
A potentially dangerous Request. Form value was detected from the client
use below code to disable the request validation on the page which processes the upload request:
<%# Page Language="C#" ValidateRequest="false" %>
2)Assign permission:
The folder where you are going to save files should have modified permissions.
Assign the iis_iusrs and iusr or application pool identity full permission to the upload folder.
3)Configuring Maximum POST Request Length:
Usually, the limitation for maximum POST request length is specified to reduce the risk of DoS attacks. If the request size exceeds a specific value, it is considered malicious and the upload would be broken.
If you are going to upload files larger than the default limitation, increase the latter.
Go to C:\Windows\System32\inetsrv\config\applicationHost.config and change
<section name="requestFiltering" overrideModeDefault="Deny" />
To
<section name="requestFiltering" overrideModeDefault="Allow" />
add below code in your application web.config file:
<system.webServer>
<security>
<requestFiltering>
<requestLimits maxAllowedContentLength ="2147482624" /> <!-- in bytes -->
</requestFiltering>
</security>
</system.webServer>
<system.web>
<httpRuntime maxRequestLength="2097151"/> <!-- in kilobytes -->
</system.web>
4)Configuring Control to Support Medium Trust Level:
.NET Trust Level in IIS specifies the level of code access security for ASP.NET applications. By default, HTML5/Flash Uploader works under the full trust level. However, if you create a website with the medium trust level on your server, you should configure HTML5/Flash Uploader to support this level as well. To perform this, just set the MediumTrustCompatibility property to true as the snippet below shows:
<aur:ImageUploaderFlash ID="ImageUploaderFlash1" runat="server"
MediumTrustCompatibility="true">
</aur:ImageUploaderFlash>
Setting the MediumTrustCompatibility property to true requires an application's pool to be routed to a single worker process. To perform this run IIS Manager, choose the application pool under which your website works, click Advanced Settings in the Actions panel, and set Maximum Worker Processes to 1:
Senario: I have multiple .aspx page coded with Get session timeout, and the .aspx are stored in SPS .../_layouts/15/MyPages/ folder. Below is my changes on web.config
web.config
<pages enableSessionState="true" ... >
...
<add name="Session" type="System.Web.SessionState.SessionStateModule" preCondition="" />
.aspx C# code
int milliSec = (this.Session.Timeout * 60000);
Will this affect other application in SharePoint? If yes, can my .aspx page have it's own web.config to prevent conflict?
Changes of web.config will affect only corresponding web application. But increasing timeout is generally not a good idea especially when you want to affect only one your page. Much better solution is using SPLongOperation object to implement your logic. There are at least three reasons:
It is systematic solution that solves not only timeout but also waiting animation and standard behavior.
Setting timeout in web.config affects whole web application not only your page.
Any value you put in web.config could be too low for slow systems and too high for fast systems.
I develop mostly for desktop so, I tend to think as WebForms as a web equivalent of WinForms. Unfortunetly this is not true.
Recently I have discovered that the Viewstate have some kind of timeout.
My problem is similar as I have read in most questions, in particular here (in my case is only around 5 to 10 minutes).
Here Microsoft says that one solution for this problem is:
<asp:Page EnableViewStateMac="False" />
However as we can read further they say:
Security Note:
This attribute should never be set to false in a production Web site,
even if the application or page does not use view state.
The view state MAC helps ensure the security of other ASP.NET functions
in addition to view state.
For this reason I don't want to set EnableViewStateMac to false and I have no access to my server (is shared hosting).
My question is: can we store the Viewstate between postbacks even if our page stay idle for a long time? If yes, how?
Thank you
The viewstate is encrypted using a machine key to ensure that it is not tampered with during postback. The machine key used to encrypt the viewstate is by default auto-generated and if the time out happens then the key's decryption will fail because the machinekey will get regenerated.
The machinekey is by default available at machine level config file.
<machineKey validationKey="AutoGenerate,IsolateApps"
decryptionKey="AutoGenerate,IsolateApps"
validation="SHA1" decryption="Auto" />
To fix this, you can use your own defined machine key. You can generate using online tools as well, like this or through IIS.
How to add this machinekey to web.config can be read at MSDN.
It should be placed under the system.web section, like this -
<configuration>
<system.web>
<machineKey decryptionKey="Decryption key goes here,IsolateApps"
validationKey="Validation key goes here,IsolateApps" />
</system.web>
</configuration>
I want to upload a large file in asp.net app of visual studio 2010. But I have got connection reset error. How can I solve it? Thanks.
P.S I have changed the requestlimited in the webconfig which is not to be make any effect.
It's a security setting to limit the size of the request. It's a setting called RequestMaxLength in web config. I believe the default is 3 or 4 MB... An asp.net file upload will be limited by the number defined in this setting (any request for that matter).
<configuration>
<system.web>
<httpRuntime maxRequestLength="4096" executionTimeout="1200" />
</system.web>
</configuration>
It's not wise to make this a very large number because it exposes you to DOS attack since someone could just flood your server with huge files. There is also an executionTimeout property that might have to be set as well
I have published an ASP.NET MVC3 site. It runs great. However, looking back at my web.config file, I was not sure if some of the values I used are correct for publishing versus for developing. These configurations are in the <system.web> section.
...
<system.web>
<httpRuntime requestValidationMode="2.0" executionTimeout="200" maxRequestLength="20000000"/>
<compilation debug="true" targetFramework="4.0">
...
I read here ( http://msdn.microsoft.com/en-us/library/e1f13641.aspx ) that using debug=true in compilation will disregard the executionTimeout of 200, and use a default value of 110. This seems to be the case, and the site is setup to allow very large amounts of files to be uploaded all at once. However, with only 110 seconds, not much can be uploaded.
My question is this: Is the correct setting to publish a live site for debug "false"? In addition, is requestValidationMode="2.0" still safe to use considering asp.net is now on version 4 (soon to be 4.5)?
Validationmode 2.0 is not the framework version and can stay like that.
Put debug=false and you are fine.
requestValidationMode... As far as I'm aware, this has to be set to 2.0 if you want to allow special characters (<, >, % etc.) in request data to pass ASP.NET's request validation at all. requestValidationMode="2.0" means "only enforce validation on pages (i.e. .aspx), rather than on every request (as was introduced in 4.0). That allows ASP.NET MVC to take over the validation - and hence also lets you turn it off for specific requests.
Is it safe? It is, if you've made sure that any actions or controllers that have [ValidateInput(false)] applied or models with [AllowHtml] have been properly secured against attacks. Imran Baloch has a full explanation here.
And yes, debug should be "false" for several reasons, including performance and memory usage. Also, debug="true" changes the default cache policy for static files to never cache the files in the browser, meaning tons of redundant requests for scripts, CSS etc.
As for the image upload, other than the suggestions given, check in Event Viewer that it's not really the application pool recycling for one reason or other, rather than an execution timeout.