I am using HttpWebRequest to download a remote file, however i get a 504 error.
I pasted the url in firefox and the first and 3rd try it took 16seconds, the 2nd nothing happened (it looked like it timed out).
How do i decrease the 504 error? Would changing HttpWebRequest timeout help? should i attempt to retry the file (lets say 3 times) if i receive a 504 error?
That's a server problem. There's no way for you to prevent that. I would retry a couple of times adding some Thread.Sleep in between.
5xx is a server error. Look at the entity body of the response to see if the server gives any hint as to why this is happening.
You can get the entity body by getting the Response from the WebException object.
Try putting an & at the end of your POST request body:
variable=value&
Maybe the server is waiting for POST data.
Related
I have a .Net application up and running.
We have had a fluctuating connection yesterday. While testing in such scenarios we had received multiple server time out exception emails like below.
Server Time Out
Type : System.Web.HttpException, System.Web, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a
Message : Request timed out.
Source :
Help link :
WebEventCode : 3001
ErrorCode : -2147467259
Data : System.Collections.ListDictionaryInternal
TargetSite :
HResult : -2147467259
Stack Trace : The stack trace is unavailable.
Additional Info:
IMPORTANT: Above exception occurred while doing a ajax post by a button placed with in update panel.
My question here is why would a slow internet on client side raise such server time out exception?
Isn't server timeout exception is related to such cases where server cannot execute the request in underlying time mention in HttpRuntime setting? May be due to some lengthy operation or some long database execution which takes longer than the time mentioned in setting under HttpRuntime.
If server is not able to connect to the client due to clients fluctuating internet, then Client Disconnected exception would be raised which we did yesterday. But I am not able to conclude the reason for this server timeout exception.
I already know that increasing the execution timeout will fix the issue, but I have to provide technical explanation for the reason as to why such exception of Server Timeout raised.
My best guess here is that the ajax request would be doing some continuous communication with server for executing of single request server and would raise timeout exception if it does not receives some required further communication messages due to client's bad internet. I have search over internet for the same to support my guess but in vain.
Also to provide environmental details, there is a load balancer serving the request.
Any help would be highly appreciated.
It is because (as you write) the connection of client to server is slow, so if the server (or client) sending data to this server, connection can´t handle it, so you get timeout error, because the data can´t been transfered in defined time.
You also write, that this is caused by sending Ajax request, so maybe try to increase execusion timeout in web configuration file (web.config):
<httpRuntime executionTimeout = "number(in seconds)"/>
More about executionTimeout here and here about Ajax requests.
Firstly, I think the cause of this error is because of execution time required by your application request connecting with the remote server is exceeding the currently set ASP.NET request execution timeout value. As per the MSDN Exception Document, default value is set to 110 seconds, in that it is remarked like:
The ExecutionTimeout property indicates the maximum number of seconds
a request is allowed to execute before being automatically shut down
by ASP.NET.
So based on error detail with event code 3001 occurs because no response was received during the time-out period for a request. You can use IIS troubleshooting failed request mechanism to figure it out exact issue like any poor performance/deadlocks when making calls from your ASP.NET application.
Secondly, it is not related to user's internet connectivity issue otherwise you get exception with status like connection-closed or keep alive failure. See this article for detail. The browser is going to wait for a 60 minutes(which is very long period of time that server isn't going to answer any request)for server to response.
And at any case when the browser abandons any request, it is going to close the socket and you'll get an error page from the browser. You don't get anything related to sever-end.
I am stuck with this, I am calling a simple report server URL which returns report's PDF, but strangely the WebRequest.GetResponse method doesn't return anything, when I say this, I mean the code just stop executing at that point, no exception, no error, no status code, no event viewer log on server, nothing!! And so I am not able to debug it
This is my code
HttpWebRequest req = (HttpWebRequest)WebRequest.Create(url);
req.PreAuthenticate = true;
req.UseDefaultCredentials = true;
req.Credentials = CredentialCache.DefaultNetworkCredentials;
req.ImpersonationLevel = TokenImpersonationLevel.Impersonation;
req.Timeout = int.MaxValue;
Log.Write("Log before");
var response = req.GetResponse();
Log.Write("Log after");
It just prints Log before log and then nothing is printed after that.
This code works perfectly fine when I run through visual studio and stops working when it is deployed in dev and test servers!
I am just expecting it to atleast through the exception or return unauthorized or any other status code, then I will be able to debug the issue.
Any suggestions what I can try to debug it?
Have you tried leaving it for 24 days 20 hours 31 minutes and 24 seconds? In other words, have you left it for as long as you have set the timeout to?
The server is not returning a response and the code is waiting int.MaxValue milliseconds to tell you that. The most likely cause of this is that there is a piece of networking infrastructure between your client and server that is stopping the request. This could be a firewall or proxy. It may also be being caused by the server not liking the request and refusing to respond.
Things I would try:
Try accessing the URL though a web browser on the machine that the code is failing on.
Set the timeout to something sensible like one minute and run the request to timeout.
Try pinging the remote server from the client machine.
Use a product like Fiddler to check what is actually being sent and received.
Have a chat with your network provider to see if they can help.
Check the server logs to see if the server has erred.
Change the first log to Log.Write("Log before: " + url); to check what is actually being requested.
In C# 5 and winform, I used a library created by Telegram Company. In this library there is a function SendDocument(UserId,DocumentStream). I know in this function, they used some HttpWebRequest, and the Timeout property of that is not handled. because sometimes it can't send large documents and after exact 100 seconds(default timeout in DotNet), the function throws an exception The task was canceled.
From the document of Telegram Company, we can send 50 MB files and my example files is about 15 MB.
Ok, Now I want to adjust the timeout of all HttpWebRequest of my server but I don't have any feature for this.
Can I adjust all HttpWebRequest.Timeout property in my server??
This is not directly related to your question, but may help ease your mind.
My advice is, don't bother adjusting the timeout. It is not likely to help. Here is what I have gone through:
I have tried to upload a 20M mp4 video file using Telegram Bot API. From a Raspberry Pi, it took 5 minutes, then returned a 504 Gateway-Timeout error. From a hosted server, it took 1 minute, then returned a 504 Gateway-Timeout error. In both cases, however, the video did eventually reach the recipient 5 minutes later. So, the upload seemed somewhat successful, yet not quite successful.
I tried to fix the problem by streaming the upload. Same problem persisted.
I tried to adjust the HTTP timeout parameter. Same problem persisted.
I tried to use cURL to make the request (instead of using telepot, a Python library I author). Same problem persisted.
I suspect the problem lies with the Telegram servers, so I talked to Bot Support. They got back to me once, saying they have made some improvements and asked if I still have the same problem. But same problem still persists.
So, it seems the problem does lie with the Telegram servers. It's not your code.
I know it's a pretty old question but may be my answer will help somebody. When I tried to send cosiderably large files via my bot I received Telegram.Bot.Exceptions.ApiRequestException: Request timed out and the only solution I found was this issue. Which wasn't really helpfull because if you check source code then you'll see that passing cancellation token does nothing with request timeout. But then I saw that you can pass HttpClient to your bot client instance and make it something like this:
_httpClient = new HttpClient();
_httpClient.Timeout = new TimeSpan(0, 5, 0); // 5 min
_client = new TelegramBotClient(botConfig.Token, _httpClient);
Hope this will help
Just wanted to ask if somebody encountered a problem of using HttpWebRequest class (or even new HttpClient) when trying upload some file to the server when Fiddler is launched.
I have encountered the bug, namely, AllowWriteStreamBuffering property of HttpWebRequest class is not working when the fiddler is launched, so upload progress is not working at all. Bytes are not sent instantly but buffored even if I set AllowWriteStreamBuffering to true, therefore I can't track upload progress. It is works ok when fiddler is not launched.
Moreover if I close fiddler when my application is uploading some file, it will crash too throwing WebException which says "The underlying connection was closed: An unexpected error occurred on a receive."
The same things is happening with new .net 4.5 HttpClient class.
Sorry for the confusion; Fiddler currently only supports streaming of responses and not requests.
Some proxies (like Fiddler) or other intermediaries will fully buffer a request before sending it to the server for performance or functional (e.g. virus scanning, breakpoint debugging) reasons.
http://www.fiddler2.com/fiddler/help/streaming.asp
Ok, caught my interest this, it appears for AllowWriteSteamBuffering to work the server must support Chunked transfer encoding. which led me to this forum post about proxies and the afore mentioned chunked encoding: https://groups.google.com/forum/?fromgroups=#!topic/httpfiddler/UkOiK96kg_k.
It appears from what I read here that when using a proxy you may or may not get the chunked encoding, etc. hence your issue.
I also found this which seemed a good detailed article on uploading with feedback which may be helpful?
http://blogs.msdn.com/b/delay/archive/2009/09/08/when-framework-designers-outsmart-themselves-how-to-perform-streaming-http-uploads-with-net.aspx
I want to monitor a WCF server, and send email notification if the server is down. To accomplish that, I am writing a console app to periodically send dummy request to the server, and check if response is sent back. When the console app received exception the server has issues, including the server being down.
However, the problem is that I received different exception on different status of the server. Below is the exceptions returned from the server when it is on different status. However, all seem belong to server down category. Any idea??:
When IIS is turned off
System.ServiceModel.EndpointNotFoundException,
Message:
There was no endpoint listening at http://localhost/service.svc that could accept the message. This is often caused by an incorrect
address or SOAP action. See InnerException, if present, for more
details.
Inner Exception Message:The remote server returned an error: (404) Not Found
When a Web.config file is deliberately changed to a wrong name:
System.ServiceModel.ServiceActivationException
Link:
http://localhost/service.svc
Message:
The requested service, 'http://localhost/service.svc' could not be activated. See the server's diagnostic trace logs for more
information.
For other unknown reason
System.ServiceModel.ServerTooBusyException
Message:
The HTTP service located at http://localhost/service.svc' is too busy.
Message:
The remote server returned an error: (503) Server Unavailable.
Update 1
The exception does NOT always return http status code.
Update 2
Apart from using WCF proxy to call the service, I have to use WebRequest too, as below:
try
{
WebRequest webRequest = WebRequest.Create(uri);
webRequest.Method = "GET";
HttpWebResponse httpWebResponse = (HttpWebResponse)webRequest.GetResponse();
}
catch () //what excpetion will tell me server is down??
{
...
}
The actual content of the error shouldn't really be of consequence - unless you're monitoring individual operations on the service (i.e. should a POST with some data to a particular URL return a specific response) - realistically, then, you're just going to be looking at the status code itself; and for that you want to look through all the HTTP Status Codes and see those which look like errors as far as you're concerned.
As a good starting point - you might want to consider nearly all of the 5xx codes; as they are all connected with server errors.
You might also want to consider some of the 4xx codes (although these are usually connected with clients, so be ruthless). In particular:
400 - Bad Request - so long as you can be sure that the server should be able to understand the request
404 - Not Found - if you're sure that the given URL should be present
405 - Method Not Allowed - if you're sure that the given HTTP verb should be supported (e.g. a POST or DELETE)
For some of the narrower 4xx codes, e.g. 413 Request Entity Too Large or 414 Request-URI Too Long; these could conceivably happen after days or months of normal operation due to things like security updates. In which case you're not necessarily identifying that the service is down as such, but you might be anticipating it being unable to perform it's intended function.
Any HTTP status result code in the 400 or 500 series is a problem that will prevent you're request from processing. All of these errors derive from System.ServiceModel.CommunicationException so check for that.