I am getting the following exception when calling a web service operation in my .NET application:
System.Net.WebException: The operation has timed out at
System.Web.Services.Protocols.WebClientProtocol.GetWebResponse(WebRequest
request) at
System.Web.Services.Protocols.HttpWebClientProtocol.GetWebResponse(WebRequest
request) at
System.Web.Services.Protocols.SoapHttpClientProtocol.Invoke(String
methodName, Object[] parameters) at
org.wvi.hrmgmt.HRManagementServiceserviceagent.LoadReducedTemplate(LoadReducedTemplateRequest
LoadReducedTemplateRequest) at
org.wvi.mgmt.hr._ServiceClient.UploadReducedTemplate()
Basically, a user uploads a file into the web server and the binary contents of this file is being passed as one of the input parameters when calling a web service operation. The size of the file is 1,397 KB and if I choose to process this file, I am getting the exception. Whereas, processing a file with a relatively smaller size, supposed 127 KB, gives a successful response.
I have done the below steps in order to solve the dillema:
Setting the web service timeout to infinite. -> Not getting an exception and any response
Adding Response.Close() -> Not getting any response
Editing the web.config in the IIS server and adding the following lines: -> Still getting the exception
<system.web>
<customErrors mode="Off"/>
<httpRuntime executionTimeout="600" maxRequestLength="16384"/>
<sessionState timeout="540"/>
</system.web>
However, to no avail, I'm still getting the above exception. I am using a Javascript plugin called AjaxUpload from GitHub and I can't figure out whether they have file upload size limit. Besides, I have checked the file if it is being uploaded on the server and it does, therefore, the issue may not be because of that plugin.
Another issue is that I am getting the same exception when uploading the file after a period of time the web page has been opened. I surmise that this has something to do with session timeout so I added an additional line in my web.config file specifying the maximum timeout. Please advise me if I'm on the right track.
Are there additional settings I need to apply in my IIS server to make the operation successful? Otherwise, are there anything I am missing? If you have experienced this before, kindly inform me what to do.
Thank you so much,
Ralph
This might be due to lot of proxy opened before. So I suggest you to delete Service.Reference.Config along with web service reference and add the service reference again and see whether it solves your problem.
Adding on to the previous answer, you may try setting up the execution time out on the proxy class , Refer this discussion
And you service call is performing a long running task you may prefer to have a lengthy time out for any webservice call by setting the timeout in proxy class as said before.
Related
We got the following problem:
I am currently developing a web server implementing a specific API. The association behind that API provided specific test cases I'm using to test my implementation.
One of the test cases is:
5.3.2.12 Robustness, large resource ID
This test confirms correct error handling when sending a HTTP request with a very long location ID as URL parameter.
The url its calling looks something like this:
https://localhost:443/api/v2/functions/be13789-1f1e-47d0-8f8a-000000000005ebe13789-1f1e-47d0-8f8a-000000000005ebe13789-1f1e-47d0-8f8a-000000000005ebe13789-1f1e-47d0-8f8a-000000000005ebe13789-1f1e-47d0-8f8a-000000000005ebe13789-1f1e-47d0-8f8a-000000000005ebe13789-1f1e-47d0-8f8a-000000000005ebe13789-1f1e-47d0-8f8a-000000000005ebe13789-1f1e-47d0-8f8a-000000000005ebe13789-1f1e-47d0-8f8a-000000000005ebe13789-1f1e-47d0-8f8a-000000000005ebe13789-1f1e-47d0-8f8a-000000000005ebe13789-1f1e-47d0-8f8a-000000000005ebe13789-1f1e-47d0-8f8a-000000000005ebe13789-1f1e-47d0-8f8a-000000000005ebe13789-1f1e-47d0-8f8a-000000000005ebe13789-1f1e-47d0-8f8a-000000000005ebe13789-1f1e-47d0-8f8a-000000000005ebe13789-1f1e-47d0-8f8a-000000000005ebe13789-1f1e-47d0-8f8a-000000000005
Basically the tests checks, if my server responds with the correct error code if the URL is too long. (At the time of writing it is testing for Errorcode 405, but I already asked them if it shouldn't be 414)
I'm developing the server in Asp.Net 6 and it always returns Bad Request 400 in the testcase.
I don't seem to find a place to change the handling for this behaviour and I am not even sure, if I can, or if the IIS is blocking the request even before it reaches my server. I activated logging in IIS, but the request does not show in the logfile in inetpub/logs/LogFiles.
My question would be, if it is possible to tell IIS to return a different error code in this case, or if it is even possible to handle the error in my application.
What I tried:
Activating IIS Logs to see if the request is even passed to my site. (It did not)
Tried adding Filters to my Controller to see if I can catch an Exception
Checked, if Development Error Sites are called.
Breakpoints in existing middlewares are not reached.
EDIT:
I am now pretty sure now, that the request never reaches my application.
It is possible to reproduce the error by using the default site the IIS generates on windows. Just copy the whole path from above into a browser with the host http://localhost will also just produce the error 400
EDIT 2:
As #YurongDai pointed out, I tried activating failed request tracing for my IIS Site. I used the default path \logs\FailedReqLogFiles.
The folder was created, but no file is written, when I'm opening the URL above in my browser.
IIS Error 400 occurs when the server is unable to process a request sent to a web server. The most common cause of Bad Request error 400 is an invalid URL, but it can happen for other reasons as well. To resolve IIS Error 400, first make sure that you have entered the URL correctly, typos or disallowed characters in the URL are the most common causes of Bad Request errors. If the error persists after verifying the URL, please clear your browser's cache, DNS cache, and cookies and try again.
Clear your browser's cookies.
Clear your browser's cache.
Clear your DNS cache.(Execute the following command in the command prompt window: ipconfig /flushdns)
Currently writing an API that accepts files using multipart/form-data. Below are my settings in Web.config. IIS is set to 1.0737GB limit and .NET is set to a 1.0485GB limit.
<httpRuntime requestValidationMode="2.0" maxRequestLength="1048576" executionTimeout="1000000" targetFramework="4.7.1" />
<requestFiltering>
<requestLimits maxAllowedContentLength="1073741824" />
</requestFiltering>
When I upload a file around 1.5-2GB in size I get a 404 back as described in the Microsoft documentation linked below. This is my expected response from the server. But, when I upload a much larger file, around 2.5GB+, I get a 400 Bad Request instead. I have been looking around for documentation to describe why this would happen and why I would not expect to always see a 404 instead, but have found nothing stating a 400 could be returned. The only difference between the requests is the files attached, nothing else is changed. To make the larger file size I also just zipped two of the original file that throws the 404 together. As additional details, the endpoint is covered in Unit and Integration tests that verify normal use case functionality. The endpoint works when manually tested with files below the IIS/.NET set limits. This behavior has also been seen when manually tested with a C# library project as well as Postman. Any help is greatly appreciated, thanks in advance!
https://learn.microsoft.com/en-us/iis/configuration/system.webserver/security/requestfiltering/
Clarification on my use case:
A clarification is that I'm not trying to increase the size limit of my requests, I just need to make sure anything over the size limit returns the same error. The documentation that will be publicly available needs to state the return value in case of error and currently it can be either a 404 or a 400 and I can't explain explicitly why in the documentation yet.
Thanks to help from all of the commenters, the following link provided by Brian Clink answered the question. https://sitecore.stackexchange.com/questions/11788/sitecore-media-file-upload-above-2gb-throws-bad-request-400
IIS forces the max size to be 2GB. So, for all requests less than 2GB that are larger than your custom IIS settings a 404.13 is returned. For all requests over 2GB a 404 is returned.
I have a XML file stored in my IIS server. At several stages of the execution, my application retrieves this file. Basically it goes back to the server and gets the file again. The problem is that the application errors out because the file is not returned since it has been cached by the browser. It returns a 304 error. I know that when I pass a changing ID on the URL it is not cached; the problem is that this file has a fixed location and if I put something else in the URL it will not find it. So, is there a way to solve this elegantly? Changing the cache settings on the client is not an option. I use a WebClient object to request the file asynchronously.
Thanks!
304 is not an error, it is a "not modified" indication according to the HTTP response codes spec. You could try adding a random number or two to the querystring in order to attempt to get a 200 back instead.
Try setting the If-Modified-Since header in the request in order to do a conditional GET request. You can then check for the Not Modified (HTTP 304) status code and if it is modified then do something; otherwise let the browser use the cached version.
Here is a blog entry about this technique:
Setting If-Modified-Since Header in code
When you downloaded the XML file the first time, the settings of IIS told the client it was OK to cache the file. You can modify the cache settings for the directory containing your XML files so that it will tell the client not to cache anything.
Example:
<configuration>
<location path="myXmlFiles">
<system.webServer>
<staticContent>
<clientCache cacheControlMode="DisableCache" />
</staticContent>
</system.webServer>
</location>
</configuration>
I came across an issue today when adding an upload data modification to a ASP.NET 3.5 C# Web App. The user needs to upload a spreadsheet with a .xls extension containing large amounts of data. That spreadsheet will be converted to a datatable and then inserted into SQL Via a SqlBulkInsert method. The problem I am having is the sheet I am currently working with has 16 columns and can only contain 24889 rows before I receive this message from the server via Fiddler, 'ReadResponse() failed: The server did not return a response for this request.' I've searched and not found much info on this related to my issue. Any help would be appreciated.
Try giving some values for maxRequestLength like below
<system.web>
<!-- ... -->
<httpRuntime maxRequestLength="204800"/>
<!-- ... -->
</system.web>
By default you can upload a file upto 4MB.
The size of your excel must be excedding the limit.
What you can do is set the setting in Web Configuration file
What this will do is increase the request size that server can respond to.
You need to look into server logs to figure out what cases it (or simply debug the server portion if you can). You also should see if it cased by simply size of the file or data in the file (if you do any processing).
Possible reasons:
you code gets the data, but fails in some way likely tearing down whole process
ASP.Net blocks request due to size (see Pankaj Garg answer).
your code is just too slow
i have a web application which which proccesses some request on some data that client selects, when the client selects more than 20 objects and clicks on proceed the client recieves this error, because the server takes a long time to process, however if the records are less and hence a timely response is recieved, no such error comes can someone help me on this?
i have increased the sessiontimeout as well as set the
Try adjusting the executionTimeout in your web.config...this only applies if debug is set to false however.
<httpRuntime
executionTimeout="some number"
/>
If this alone does not solve your issue, check out this blog post which goes into a bit more depth on how to structure your timeouts. Note the IIS reference towards the bottom...