I have a web.config with the following lines:
<requestFiltering>
<requestLimits maxUrl="25000" maxQueryString="25000"></requestLimits>
</requestFiltering>
This lets me access urls up to 25k characters including query string. However, when I publish to an Azure website it completely disregards this specific part of my web.config, but I can't find any kind of limits published by Microsoft.
Anyone know what's going on?
You can find the detailed overview of Request Limits in this Azure doc
This can be happening either due to ASP.NET Runtime or IIS Requests Filtering module. By default, the maximum allowed length for a query string is 2048 ref: link and Internet Explorer You should set the appropriate values in your Web.config, under the requestLimits subnodes.
Even if you set a big value for maximum query string, there is a limit for each browser which is handling the url and the query string. This not available in IIS 6 or in IIS 7 app pools running in classic mode.
Couldn't find any documentation, but Azure App Services seems to have query string limitation set at 2048, which is the recommended default.
The reason your web.config configuration is not working is because it is applied at the worker level and this limit is probably being enforced (also) at the Front-End level, which is the reverse proxy component receiving requests and distributing them to the appropriate backend workers.
afaik there is no way to configure this setting at the front-end level. If you wish to send more data to your application consider using a POST request.
For older servers you had to set the value higher up in the config, it may be worth experimenting with also setting this.
<configuration>
<system.web>
<httpRuntime maxQueryStringLength="25000" />
</system.web>
</configuration>
Related
I'm currently working on an ASP.NET MVC website and it works fine.
But I have a problem that I don't understand at all... When I launch my website on Visual Studio with Chrome for example no problem, but when I stop it and try to launch an other test with Firefox for example, my url is growing and then I get this error :
HTTP 400. The size of the request headers is too long.
Can someone explain me why this is happening ? Is it something with my code or does it come from IIS express or anything else ?
Thanks in advance
You can probably increase the size of requests your webserver will allow. However, take a look at the amount and the size of cookies your browser are sending to the server. Clear your cookies and try again, and see if you can reduce the size and amount of cookies your app is using. The less, the better! Mobile browsers can get these errors, as they don't allow the same size as do desktop browsers(?).
The error can also mean the query string is getting too large.
.NET MVC SOLUTION FOR ME
In my case, it was my claims that was multiplying my session cookies to look as below in my browser cookies:
.AspNet.ApplicationCookie
.AspNet.ApplicationCookieC1
.AspNet.ApplicationCookieC2
.AspNet.ApplicationCookieC3
.AspNet.ApplicationCookieC4
.AspNet.ApplicationCookieC5
.AspNet.ApplicationCookieC6
.AspNet.ApplicationCookieC7
__RequestVerificationToken
I simply went to aspNetUserClaims table in my mssql management studio and cleared it. Then cleared the browser cookie for the project.
Refreshed the page. Kalas!!! Done!!
I believe it happened because I was switching from one database connectionstring to another which caused the claimsManager to recreate session and add to my cookie. On saturation, everyting exploded.
Check the MSDN:
Cause
This issue may occur when the user is a member of many Active
Directory user groups. When a user is a member of a large number of
active directory groups the Kerberos authentication token for the user
increases in size. The HTTP request that the user sends to the IIS
server contains the Kerberos token in the WWW-Authenticate header, and
the header size increases as the number of groups goes up. If the
HTTP header or packet size increases past the limits configured in
IIS, IIS may reject the request and send this error as the response.
Resolution
To work around this problem, choose one of the following options:
A) Decrease the number of Active Directory groups that the user is a
member of.
OR
B) Modify the MaxFieldLength and the MaxRequestBytes registry settings
on the IIS server so the user's request headers are not considered too
long. To determine the appropriate settings for the MaxFieldLength
and the MaxRequestBytes registry entries, use the following
calculations:
Calculate the size of the user's Kerberos token using the formula described in the following article:
New resolution for problems with Kerberos authentication when users belong to many groups
http://support.microsoft.com/kb/327825
Configure the MaxFieldLength and the MaxRequestBytes registry keys on the IIS server with a value of 4/3 * T, where T is the user's token
size, in bytes. HTTP encodes the Kerberos token using base64 encoding
and therefore replaces every 3 bytes in the token with 4 base64
encoded bytes. Changes that are made to the registry will not take
effect until you restart the HTTP service. Additionally, you may have
to restart any related IIS services.
try this
<system.web>
<httpRuntime maxRequestLength="2097151" executionTimeout="2097151" />
</system.web>
The maxRequestLength default size is 4096 KB (4 MB).
if browser request some resource again and again , at some time request header value length increase by number of times so we may try to extend request length to max length.
i hope this may usefull
In windows system generally this error occurs due to the default header size limits set in the http.sys service. This service acts as a protective layer before requests are forwarded to the application to prevent it from being overwhelmed by invalid requests.
You can override the default max header limit by modifying the windows registry.
Follow the steps :
Run regedit
From the address bar go to the address : Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\HTTP\Parameters or drill down manually.
Right click on "Parameters" > New > DWORD
Rename the new entry to MaxFieldLength
Right click the newly created MaxFieldLength, modify it and set the value to desired max individual header size in bytes, make sure base is set to decimal.
Do the same for MaxRequestBytes. Make it sufficiently higher to match value set in MaxFieldLength.
Open command prompt as administrator
Enter the command "net stop http" (make sure visual studio or other interfering programs are closed)
Enter the command "net start http"
Resources:
Enabling logging
Supported parameters
In my case, I had cookies from a number of different apps served on my localhost with large cookies. FF differentiates by host-name so clearing my cookies from localhost fixed it.
Following Ifeanyi Chukwu's answer, for my case, I tried with private mode (Incognito) and it works fine. Then I go to browser settings and delete cookies of my site (localhost). That fixes the issue.
As you may already figured out issue, a simple temporary solution would be to switch your browser while debugging.
I'm trying to appease a PCI scan failure we recently had done, in which it states:
Microsoft ASP.NET MS-DOS Device Name DoS
Synopsis :
A framework used by the remote web server has a denial of service vulnerability.
Impact:
The web server running on the remote host appears to be using Microsoft
ASP.NET, and may be affected by a denial of service vulnerability. Requesting a URL
containing an MS-DOS device name can cause the web server to become
temporarily unresponsive.
In a nutshell, we visit a URL on our app such as /AUX/.aspx we get a 500 error.
I'm using RequestFiltering to filter these requests out, and return 404's instead, without the server trying to process the request.
An excerpt of my web.config is below:
<system.webServer>
<security>
<requestFiltering>
<denyUrlSequences>
<add sequence="/AUX/.aspx" />
</denyUrlSequences>
</requestFiltering>
</security>
</system.webServer>
However, this isn't working, it's still returning a 500.
I would expect it to return a 404.
If I add the following catch-all url to the denyUrlSequences then the whole site produces the expected 404.
<add sequence="/" />
It's worth mentioning the application in question is an MVC app running on IIS 7.5 (Windows 2008 R2)
Just had to solve this problem.
My solution was to disable .Net Error Pages and enable IIS Error Pages.
When you move the custom error handling from the higher .Net level to the lower IIS level the HTTP response code changes from 500 to 404.
PCI Test Passed :-)
I struggled with this for quite some time myself. I think the 500 response code is correct for MS-DOS names in the URL, and you do not need to add anything to request filtering.
You'll notice that you will get a 500 error if you use any of the MS-DOS names (https://support.microsoft.com/en-us/kb/74496) without doing anything to your configuration. However, if you add a RequestFiltering denySequence for something else, like "foo", then you will see the 404.5 error when browsing to /foo.
If you add relaxedUrlToFileSystemMapping="true" to the httpRuntime element along with your request filtering denySequence entries, then you will get the 404.5 for MS-DOS names.
But disabling the default asp.net configuration just so you can get something other then a 500 response for a URL with MS-DOS name is a rediculous request from a PCI compliance check.
I have a application developed in asp net mvc 4 (IIS 7 and windows server 2008) and it has a upload system.
The problem is that with large files I get an 413 http error.
I am trying to set uploadaheadsize but can´t find it anywhere.
Tried Roles and features and also in application pool. Could someone guide me through this config setting?
Thanks.
I found the solution.
Just added:
<security>
<requestFiltering>
<requestLimits maxAllowedContentLength="524288000"/>
</requestFiltering>
</security>
in my web.config!
Edit 1:
In addition, I found this useful information on www.iis.net:
The requestLimits element specifies limits on HTTP requests that are
processed by the Web server. These limits include the maximum size of
a request, the maximum URL length, and the maximum length for a query
string. In addition, the element can contain a
collection of user-defined HTTP header limits in the
element, which allows you to define custom settings on HTTP headers.
reference: http://www.iis.net/configreference/system.webserver/security/requestfiltering/requestlimits
What are the best practices that I can follow to increase the max length of the URL in IIS7/ASP.NET?
Please advise.
From this site: http://technet.microsoft.com/en-us/library/cc754791(v=ws.10).aspx
Use command line : appcmd set config /section:requestfiltering/requestlimits.maxurl: unit
Here is explained how to use appcmd:
http://www.windowsnetworking.com/articles_tutorials/Configuring-IIS-7-command-line-Appcmdexe-Part1.html
You need to know where the AppCmd.exe command is located as it is not
in the default PATH. In order to run AppCmd.exe, you will either need
to change directory into %windir%\system32\inetsrv\ or add that
directory to your PATH variable. On my Windows 2008 server with a
default installation, AppCmd.exe was located in
C:\Windows\System32\inetsrv.
But be careful. If your request url became realy realy large, use post message to pass parameters
Although the specification of the HTTP protocol does not specify any maximum length, the practical limit is 2,083 characters, with no more than 2,048 characters in the path portion of the URL. These are the restrictions currently enforced by Microsoft Interet Explorer, which is still used by a sizeable majority of all users. A reasonable upper limit on the length of URLs has always been imposed by major web browsers. When you wish to submit a form containing many fields, which would otherwise produce a very long URL, the standard solution is to use the POST method rather than the GET method:
<form action="myscript.php" method="POST">
...
</form>
The form fields are then transmitted as part of the HTTP transaction header, not as part of the URL.
You may be limited by the following setting in web.config:
<configuration>
<system.webServer>
<security>
<requestFiltering>
<requestLimits>
</requestLimits>
</requestFiltering>
</security>
</system.webServer>
</configuration>
Refer to:
http://www.iis.net/configreference/system.webserver/security/requestfiltering/requestlimits#005
I was getting 404 errors for some long URLs on a website I'm developing. After a bit of digging I discovered that this occurs when the length of certain aspects of the URL exceed configurable limits in IIS7. In this case the maxQueryString attribute of the requestLimits property needed to be increased in the web.config
<system.webServer>
<security>
<requestFiltering>
<requestLimits maxQueryString="4096" maxAllowedContentLength="4096" maxUrl="8192" >
</requestLimits>
</requestFiltering>
</security>
This fixed the problem instantly on my development server but on the remote server I now get:
500 - Internal server error.
There is
a problem with the resource you are
looking for, and it cannot be
displayed.
And that's all the information it gives me.
Change your Flash to send the data as POST, so it won't be appended to the URL. Here's some sample code. Also, you may need to change the server side to look for the data as POST instead of GET.
Are you sure your hoster/production-server is running Windows Server 2008 (or 2008 R2)?
The settings you are describing above are only valid for IIS 7+.
You should not use such long URLs. Among other reasons, at least one of the common toolbars (Bing, Yahoo, Google) will break them, producing just such errors. Users will blame you.
I know this because one of my users was having just such a problem with a legacy app. When I removed the toolbars (she had all three installed!), the problem went away.
A GET request is only limited by a browser's limit on the length of the URL string.
In IE it is 2,083 characters, minus the number of characters in the actual path. Other browsers do not have a clearly defined limit on the length of the URL string. These articles might be helpful to you.
http://www.boutell.com/newfaq/misc/urllength.html
http://support.microsoft.com/kb/q208427
RFC 2616, "Hypertext Transfer Protocol -- HTTP/1.1," does not specify any requirement for URL length, so browsers are free to stipulate what they deem fit.
therefore you should use POST instead of GET if it's fits within your requirements