I have a [HttpDelete] action in my Web API, and when I invoke it with a long URL, I get 400.
I know for sure it's the URL length since I managed to fail / pass the request by adding and removing a single character.
I had a similar issue with [HttpGet] request length which I had resolved by adding configurations to my web.config:
Under system.web:
<httpRuntime maxRequestLength="1048576" maxQueryStringLength="32768" maxUrlLength="65536" waitChangeNotification="2147483647" maxWaitChangeNotification="2147483647" requestPathInvalidCharacters="" targetFramework="4.5" />
Under system.webServer:
<security>
<requestFiltering>
<requestLimits maxAllowedContentLength="1073741824" maxQueryString="32768" maxUrl="65536"/>
</requestFiltering>
</security>
But the issue seems to be reproducing in the Delete action as well, and I'm failing to come with a solution. I'm not getting anything in IIS trace and IIS logs as well.
How to fix this?
So I think I found the cause, looks like Microsoft limits URL segments to 260.
more information here, look for the UrlSegmentMaxLength
https://support.microsoft.com/en-us/kb/820129
Edit:
So this is defiantly the issue.
It's not just for Delete, but for any other http type of action, that has a long segment in the URL.
the solution is to update the registry key with the value you want, should you need url segments which are over 260 characters, which is the default value.
Hope this will help someone else.
Related
I have trouble posting 'large' objects to my web api using the HttpClient's PostAsJsonAsync method. The objects contain a base64 encoded image file.
After a period which seems like the client's timeout setting, the exception
'A task was canceled.'
is thrown by the HttpClient. The timeout is already set very high (10 minutes). This only happens with files larger than ~2 MB. Anything smaller works fine. I know that the request does not even hit the first line of code in the controller method because the first line is a logging line and the log is empty. There are no exceptions in the server event viewer.
It is hard to pin down the issue because the controller works fine when I deploy the web api on my local IIS. But when I deploy it on my Azure VM, it only work for small files. The web.config files are identical.
maxRequestLength is already set high enough.
<httpRuntime targetFramework="4.5.2" maxRequestLength="1048576" />
Instead of IIS hosting in an Azure VM, i've just tried to deploy the API as an app service. The exact same thing happens there.
You can also try setting this limit:
<system.webServer>
<security>
<requestFiltering>
<requestLimits maxAllowedContentLength="1073741824" />
</requestFiltering>
</security>
</system.webServer>
Note that contrary to the maxRequestLength parameter, this value is in bytes.
I have rest wcf service working okay.
Except in some scenarios It throws bad request.
On some search and checks, it seems when the url has longer parameters.(sometimes url length is more than 1000) .It does not hit the service and thrown bad request straight away.
http://testservice/Service.svc/endpoint/get/1/2/longparameter
How can I address for such situations?
I had a similar issue and thanks to this answer was able to resolve it by adding the following:
<system.web>
<httpRuntime maxUrlLength="500" />
</system.web>
That worked for me, but in your case it sounds like you'd need to set it even higher.
I need to somehow do a work around with an asp.net File Uploader so it can take more than 4gb of multiple files. Is there any way to set the web.config or write a C# function that just bypasses the Max Limit of File space that is used by ASP.Net and IIS 7? I tried to look at this http://msdn.microsoft.com/en-us/library/hh195568.aspx but I have no idea how to use the function. Please help, anyone with information about a work around that would be great since microsoft has put limits I'm guessing there has to be something out there that can bypass the limitations.
Unfortunately maxRequestLength is an variable of Int32 type (maximum value is 2147483647 - 0x7FFFFFFF)
But if you want to extend maxRequestLangh for your application then you can do that by adding couple of attributes to your httpRuntime in web.config:
<httpRuntime maxRequestLength="<size in bytes>" executionTimeout="<timeout in seconds>" />
Here is an example (2 gb of max lenght and about 10 minutes of timeout):
<httpRuntime maxRequestLength="2147483647" executionTimeout="600" />
Also you need to add security part to system.webServer:
<security>
<requestFiltering>
<requestLimits maxAllowedContentLength="2147483647" />
</requestFiltering>
</security>
Might be useful:
MSDN: maxAllowedContentLength
MSDN: httpRuntime Element
Large File Upload in IIS
Fixing File Upload Size Limit in IIS 7
When attempting to upload a file of 35 megs, the website hangs.
I have set a break point on the server side before the File.SaveAs(path) command is even called.
I do a check on the server side to make sure the file is less than 20 megs, but it doesn't even reach this point. The web page just continues to load until I get a connection was reset error.
Increase maxAllowedContentLength in web.config
<system.webServer>
<security>
<requestFiltering>
<requestLimits maxAllowedContentLength="1048576000" />
</requestFiltering>
</security>
</system.webServer>
In Web.config in system.web :
<httpRuntime maxRequestLength="100000"/>
100000kb =100 MB
If you upload the file with simple HTTP-POST you need to wait for the whole file to be uploaded. You can't abort the upload earlier in the controller, only with web.config as cosset's answer suggests.
You could use maybe Flash to check the file size on the client already, don't know details about that though
Could this be a good chance to use async as shown here?
There is also an excellent article on async and await here.
Web.Config issues aside, a file that big is going to take some time. I would try not to block the current thread with such an action.
I've got a custom HttpModule to redirect legacy URLs from an old build of the site which checks the incoming request URL against a database table of redirects.
However, when the incoming request URL contains a plus (+) sign, the request doesn't fall through the HttpModule - it works as expected for standard URLs.
For example, these URLs works:
http://www.example.com/sample-url
http://www.example.com/sample url
http://www.example.com/sample%20url
These don't:
http://www.example.com/sample+url
http://www.example.com/sample%2Burl
Here's my module declaration:
<add name="LegacyUrlHttpModule" type="Web.LegacyUrlHttpModule, Framework.Web" preCondition="managedHandler" />
Am I missing a setting here or something?
Scott Hanselmann wrote a nice blog post explaining how you could enable all kind of crap symbols in the Path portion of an url.
His conclusion is the following:
After ALL this effort to get crazy stuff in the Request Path, it's
worth mentioning that simply keeping the values as a part of the Query
String (remember WAY back at the beginning of this post?) is easier,
cleaner, more flexible, and more secure.
So basically if you have such characters in a url, those characters should be passed as query string parameters instead of attempting to pass them in the Path portion.
IIS rejects + in URLs by default. A workaround would be to allowDoubleEscaping
<system.webServer>
<security>
<requestFiltering allowDoubleEscaping="true" />
</security>
</system.webServer>
but beware that this may make your site more vulnerable to malicious URLs.
You can follow the below steps:
in the IIS webserver section, double click the 'Request Filtering' icon
in the 'File Name Extension' right click->Edit Feature Settings...' the file 'web.config'
check the option 'Allow double escaping' (this option is unchecked by default)
repeat all above 3 steps for the 'default website' (or whatever you have given the name to your site)
re-start the IIS