I have the following web API url which is not working
www.localproject.com:843/api/user/validate/eyJhbGciOiJodHRwOi8vd3d3LnczLm9yZy8yMDAxLzA0L3htbGRzaWctbW9yZSNobWFjLXNoYTI1NiIsInR5cCI6IkpXVCJ9eyJ0ZW1wVXJsIjoie1wiQ3VzdG9tZXJJZFwiOjEsXCJDb3Vyc2VJZFwiOjEsXCJUb2tlblwiOm51bGwsXCJFeHBpcnlcIjpcIjIwMTgtMDQtMThUMTc6MzU6MTMuOTQ2MjM2NCswNTowMFwifSJ9uvm7jZ3us5UFa1hqh4bod2cSamcxF2rRUbfxs7DHQs
whenever I hit the above url It gives me following error
Bad Request - Invalid URL
HTTP Error 400. The request URL is invalid.
I updated my web.config to this as well but still not working.
<httpRuntime targetFramework="4.6.1" maxRequestLength="20480" maxUrlLength="6144" relaxedUrlToFileSystemMapping="true" />
I also tried editing registry but no luck.
How to allow long url using web api?
By default, HTTP.sys permits 255 segments at a maximum length of 260 characters each. That 260 character limit is why you are seeing this issue.
To fix this you need to make a registry change.
Navigate to:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\HTTP\Parameters
Add a DWORD value named UrlSegmentMaxLength and set its value to something like 500 or say 1000.
While you can probably avoid reboot by restarting the HTTP System Service thru command line is a possibility "net stop http" and "net start http", but because several other services depend upon this service like WWW, Print Spooler, SSDP Discovery etc. I will still recommend rebooting the server.
There are lots of similar questions on StackOverflow. If this is a duplicate, I would appreciate a little explanation of how to apply other solution in my context please.
I have a project that is a WebAPI. This WebAPI in turn calls a web service (WSDL), processes the data and returns to the client:
[Client] ----> [My WebAPI] ----> [WSDL Server]
|
<-------- [My WebAPI] <---------
The WSDL part is a Java-based service. The only way we could consume it without issue in VS2015 was to add it as a Web Reference (2.0 in the dialog). It works perfectly, with strongly-typed values as required, but today we've seen a timeout between My WebApi and WSDL Server.
In other answers on SO, I see that the timeout period can be configured in web.config <bindings> or via a proxy, but I can't see how to wire this up given my web.config contents, which differs massively from other peoples. The code below was generated by VS2015 when the WSDL service was consumed:
<system.serviceModel>
<bindings />
<client />
</system.serviceModel>
<applicationSettings>
<MyWebAPI.Properties.Settings>
<setting name="MyWebAPIs_ThirdPartyWSDLService_GetData" serializeAs="String">
<value>https://wsdl.domain.com/webservices/services/GetData</value>
</setting>
</MyWebAPIs.Properties.Settings>
</applicationSettings>
I also can't find any mention of timeouts in the c# intellisense code. Any help or pointers would be appreciated. I've read about 12 posts on SO but still can't figure it out.
I hate to answer my own question but I think I've found the answer (I will remove if not). This is obvious, but reading too much on SO actually threw me off course and I was inspecting the wrong class in VS.
When consumed, the third-party web service client class GetData() is forced to derive from SoapHttpClientProtocol. This class derives from HttpWebClientProtocol, derived from WebClientProtocol.
WebClientProtocol has a public property Timeout, expressed in milliseconds.
Indicates the time an XML Web service client waits for the reply to a synchronous XML Web service request to arrive (in milliseconds).
The time out, in milliseconds, for synchronous calls to the XML Web service. The default is 100000 milliseconds.
Setting the Timeout property to Timeout.Infinite indicates that the request does not time out. Even though an XML Web service client can set the Timeout property to not time out, the Web server can still cause the request to time out on the server side.
Therefore the Timeout property is available directly from code when instantiated as a web service client, which I believe is due to the magic of VS:
SomeComsumedWebService wsc = new SomeComsumedWebService();
SomeComsumedWebService.Timeout = 600000; // 10 minutes
var obj = SomeComsumedWebService.MethodToGetData();
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.
I'm using MiniProfile to try and figure out why my MVC site is taking a long time. It looks like the 'Find' method is where the time is being spent. I have read a couple things on this and most people seemed to suggest that it was due to having <compilation debug="true" .. > set in the web.conf. I can confirm that in the following example the debug is not set (my compilation looks like the following):
<compilation targetFramework="4.0">
...
</compilation>
No where is debug mentioned. But yet, my find calls are taking upwards of three seconds :S
Any suggestions on how I can figure this out? (Note: I am running on an Azure production server. I have RDC'd into the system to confirm that the pushed web.config does not contain the debug="true").
If this is the first request coming to your website after publishing or after the AppDomain has been brought down by IIS it is normal that the Find method takes a long time. It will then cache the location for this view and on subsequent requests it should be much faster. Try Ctrl+F5ing in your browser on the same url.
Also try explicitly setting debug="false" in your web.config.
I am building a site in which i would like to create a file client side from the value of a textarea element.
I have the code in place to do this, but i am getting this error
HTTP Error 404.15 - Not Found The request filtering module is
configured to deny a request where the query string is too long.
Is there a way to override this so that I am able to process requests of any size?
If not, is there a way to generate files client side without using the filesystem/active x object?
thanks
Add the following to your web.config:
<system.webServer>
<security>
<requestFiltering>
<requestLimits maxQueryString="32768"/>
</requestFiltering>
</security>
</system.webServer>
See:
http://www.iis.net/ConfigReference/system.webServer/security/requestFiltering/requestLimits
Updated to reflect comments.
requestLimits Element for requestFiltering [IIS Settings Schema]
You may have to add the following in your web.config as well
<system.web>
<httpRuntime maxQueryStringLength="32768" maxUrlLength="65536"/>
</system.web>
See: httpRuntime Element (ASP.NET Settings Schema)
Of course the numbers (32768 and 65536) in the config settings above are just examples. You don't have to use those exact values.
In my case ( Visual Studio 2012 / IIS Express / ASP.NET MVC 4 app / .Net Framework 4.5 ) what really worked after 30 minutes of trial and error was setting the maxQueryStringLength property in the <httpRuntime> tag:
<httpRuntime targetFramework="4.5" maxQueryStringLength="10240" enable="true" />
maxQueryStringLength defaults to 2048.
More about it here:
Expanding the Range of Allowable URLs
I tried setting it in <system.webServer> as #MattVarblow suggests, but it didn't work... and this is because I'm using IIS Express (based on IIS 8) on my dev machine with Windows 8.
When I deployed my app to the production environment (Windows Server 2008 R2 with IIS 7), IE 10 started returning 404 errors in AJAX requests with long query strings. Then I thought that the problem was related to the query string and tried #MattVarblow's answer. It just worked on IIS 7. :)
If you run into this issue when running an IIS 8.5 web server you can use the following method.
First, find the "Request Filtering" module in the IIS site you are working on, then double click it...
Next, you need to right click in the white area shown below then click the context menu option called "Edit Feature Settings".
Then the last thing to do is change the "Maximum query string (Bytes)" value from 2048 to something more appropriate such as 5000 for your needs.
Something else to check: if your site is using MVC, this can happen if you added [Authorize] to your login controller class. It can't access the login method because it's not authorized so it redirects to the login method --> boom.
It will also generate error when you pass large string in ajax call parameter.
so for that alway use type post in ajax will resolve your issue 100% and no need to set the length in web.config.
// var UserId= array of 1000 userids
$.ajax({
global: false,
url: SitePath + "/User/getAussizzMembersData",
"data": { UserIds: UserId},
"type": "POST",
"dataType": "JSON"
}}
I had a similar issue trying to deploy an ASP Web Application to IIS 8. To fix it I did as Matt and Leniel suggested above. But also had to configure the Authentication setting of my site to enable Anonymous Authentication. And that Worked for me.
I had to add [AllowAnonymous] to the ActionResult functions in my login page because the user was not authenticated yet.
If your website is using authentication, but you don't have the correct authentication method set up in IIS (e.g. Basic, Forms etc..) then the browser will be getting stuck in a redirect loop. This causes the redirect url to get longer and longer until it explodes.
For someone who experiences this while running the apps from Visual Studio, while using IIS Express, first you have to locate the applicationhost.config file being used by the application. See the answer at https://stackoverflow.com/a/41553876/1849880 on how to locate the applicationhost.config file. Then, you can change the maxQueryString value as explained above.
HTTP Error 404.15 - Not Found The request filtering module is
configured to deny a request where the query string is too long.
To resolve this problem, check in the source code whether the Form tag has a property method is get/set state.
If so, the method property should be removed.