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
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 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>
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
here is my URL
http://abc.domain.com/controller/action/A74444C3A7FA858C7995CA9954CBCF1E26604634767C5575396D908E8415CF8CCC04C05F49FED0AA9D9743B69ABF232BDE9787A5222D081DA638896C0D2379A673E1747A2FFE1158F14AF098B2899D2ABEB4EA738D89369627E479796B6B2B9EA9B247CC59EF10E3A88B6A56A87F0818E2AD2A942FFA31F1C941BB7AF6FDC55FE6733353F28DFAC1827688604CBFBAB4856E6C75F810D13923F9D913F51F5B02980163E6CD63BC04610AD2C12E07360D7BC2C69F1B0CD03E
There are no invalid characters in the URL itself as everything is encrypted. Still I am getting
Bad Request - Invalid URL
HTTP Error 400. The request URL is invalid.
I know the URL is awfully long and I was able to resolve that issue in my Cassini by adding this
httpRuntime maxUrlLength="512"
in the web.config
However in IIS7 even after playing around with the requestfiltering maxurl and maxquerystring values I have not been able to resolve this.
This is an asp.net mvc 3 application.
This one is for posterity and for tracking my own problem. It's been said in another answer however, not as explicitly.
I've had the same problem on my end. The answer is of course to transfer the long URL segment to a Query string. Easier to handle.
The problem however is that HTTP.sys is not even letting the request through because a segment of the URL is exceeding 260 or so characters. However, we still had to support it.
You can change that setting in the registry. Once you reboot, the url will work.
Registry:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\HTTP\Parameters]
"UrlSegmentMaxLength"=dword:00000400
This will effectively set the segment length to 1024.
Source
Your problem is you're not using a query string, but a path. A path has a maximum length of 255.
The final path segment is likely to be too long.
See: http://social.msdn.microsoft.com/Forums/nl/netfxnetcom/thread/723e6bfd-cab7-417b-b487-67f1dcfa524f
I have written ASP.NET (4.0) code that sets the Response.StatusCode to 400 if the data posted to the server is in valid.
I place useful information in the response body in the format that the request accepts header asks for. eg an html message saying "The date field is required...".
In IIS7 (7.5.7600) on Windows 7 I get the correct html response back to the browser.
In IIS7 (7.5.6000) on Windows 2008 I do not get the html body back, but only a text body with "Bad Request" as the content.
Can someone point me to how I change the configuration of the 2008 server to return the body.
Or is there a difference between these versions of IIS?
Maybe a module in the Machine.config?
For example I know (and have had to work around) that the FormsAuthentication module changes a 401 to a 302 even if you do not want this. May be there is a module that stops the content of a 400 being sent.
TIA.
Solution: edited the web.config system.webServer section and set httpErrors existingResponse attribute to "PassThrough" et voilá fixed.
ie:
<system.webServer>
...
<httpErrors existingResponse="PassThrough"></httpErrors>
...
</system.webServer>
Well 2 things got me think about this issue:
the classic CustomErrors behaviour because I was comparing localhost with a remote server
the first wouldn't explain how some of my other Authentication 'errors' were getting through intact
I dug around and came across this article on IIS7: How to Use HTTP Detailed Errors in IIS 7.0
It didn't fully pertain to what I found when editing the web.config maybe due me using IIS7.5 but it was enough to get me into the right neighbourhood.
**Also be aware that with IIS 10 now supporting HTTP2, StatusDescriptions that contain text are no longer supported when request upgrade to HTTP2 so if you respond with 400 (Bad Request) this will get stripped to the numeric 400 only.
"HTTP/2 does not define a way to carry the version or reason phrase
that is included in an HTTP/1.1 status line."
If altering the web.config isn't an option, below may help:
Response.TrySkipIisCustomErrors = true;