I'm getting the following error when my win32 (c#) app is calling web services.
The request failed with HTTP status 504: Gateway timeout server response timeout.
I understand 'I think' that this is because the upstream request does not get a response in a timely fashion.
But my question is this? How do I change the app.config settings in my win32 application to allow more time to process its data. I assume I require these changes to be made on my app settings as the webservices and IIS hosting the ws are setup with extended times.
Look forward to a response and thank you in advance.
Scott
This question is related to
http
One thing I have observed regarding this error is that is appears only for the first response from the server, which in case of http should be the handshake response. Once an immediate response is sent from the server to the gateway, if after the main response takes time it does not give an error. The key here is that the first response on a request by a server should be fast.
CheckUpDown has a nice explanation of the 504 error:
A server (not necessarily a Web server) is acting as a gateway or proxy to fulfil the request by the client (e.g. your Web browser or our CheckUpDown robot) to access the requested URL. This server did not receive a timely response from an upstream server it accessed to deal with your HTTP request.
This usually means that the upstream server is down (no response to the gateway/proxy), rather than that the upstream server and the gateway/proxy do not agree on the protocol for exchanging data.
This problem is entirely due to slow IP communication between back-end computers, possibly including the Web server. Only the people who set up the network at the site which hosts the Web server can fix this problem.
I have had another issue giving me a 504. It's pretty far out but I'll write it up here for googlers and posterity...
I have a client calling an IIS hosted webservice hosted in another domain (Active Directory). There is not full trust between the client domain and the domain where the web services is hosted. One of the many challenges with the selective trust between these two domains is that Kerberos does not work when calling from one to the other.
In my case I was trying to call a service in another domain where I found out that a SPN was registered. Like this : http/myurl.test.local (just an example)
This forces the call to use Kerberos instead of letting it fall back to NTLM and this gave me a 405 back from the calling server.
After removing the spn and allowing the call to fall back to NTLM, it works fine.
As I said ... this is not something you are likely to run into, as most organizations do not venture into having such a selective trusts between two domains ... But it gives a 504 and caused me a few (more) gray hairs.
You can't. The problem is not that your app is impatient and timing out; the problem is that an intermediate proxy is impatient and timing out. "The server, while acting as a gateway or proxy, did not receive a timely response from the upstream server specified by the URI." (http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.5.5) It most likely indicates that the origin server is having some sort of issue, so it's not responding quickly to the forwarded request.
Possible solutions, none of which are likely to make you happy:
If your using ASP.Net 5 (now known as ASP.Net Core v1) ensure in your project.json "commands" section for each site you are hosting that the Kestrel proxy listening port differs between sites, otherwise one site will work but the other will return a 504 gateway timeout.
"commands": {
"web": "Microsoft.AspNet.Server.Kestrel --server.urls http://localhost:5090"
},
Suppose access a proxy server A(eg. nginx), and the server A forwards the request to another server B(eg. tomcat).
If this process continues for a long time (more than the proxy server read timeout setting), A still did not get a completed response of B. It happens.
for nginx, You can configure the proxy_read_timeout(in location) property to solve his.But this is usually not a good idea, if you set the value too high. This may hide the real error.You'd better improve the design to really solve this problem.
You can't. The problem is not that your app is impatient and timing out; the problem is that an intermediate proxy is impatient and timing out. "The server, while acting as a gateway or proxy, did not receive a timely response from the upstream server specified by the URI." (http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.5.5) It most likely indicates that the origin server is having some sort of issue, so it's not responding quickly to the forwarded request.
Possible solutions, none of which are likely to make you happy:
Suppose access a proxy server A(eg. nginx), and the server A forwards the request to another server B(eg. tomcat).
If this process continues for a long time (more than the proxy server read timeout setting), A still did not get a completed response of B. It happens.
for nginx, You can configure the proxy_read_timeout(in location) property to solve his.But this is usually not a good idea, if you set the value too high. This may hide the real error.You'd better improve the design to really solve this problem.
CheckUpDown has a nice explanation of the 504 error:
A server (not necessarily a Web server) is acting as a gateway or proxy to fulfil the request by the client (e.g. your Web browser or our CheckUpDown robot) to access the requested URL. This server did not receive a timely response from an upstream server it accessed to deal with your HTTP request.
This usually means that the upstream server is down (no response to the gateway/proxy), rather than that the upstream server and the gateway/proxy do not agree on the protocol for exchanging data.
This problem is entirely due to slow IP communication between back-end computers, possibly including the Web server. Only the people who set up the network at the site which hosts the Web server can fix this problem.
One thing I have observed regarding this error is that is appears only for the first response from the server, which in case of http should be the handshake response. Once an immediate response is sent from the server to the gateway, if after the main response takes time it does not give an error. The key here is that the first response on a request by a server should be fast.
CheckUpDown has a nice explanation of the 504 error:
A server (not necessarily a Web server) is acting as a gateway or proxy to fulfil the request by the client (e.g. your Web browser or our CheckUpDown robot) to access the requested URL. This server did not receive a timely response from an upstream server it accessed to deal with your HTTP request.
This usually means that the upstream server is down (no response to the gateway/proxy), rather than that the upstream server and the gateway/proxy do not agree on the protocol for exchanging data.
This problem is entirely due to slow IP communication between back-end computers, possibly including the Web server. Only the people who set up the network at the site which hosts the Web server can fix this problem.
I have had another issue giving me a 504. It's pretty far out but I'll write it up here for googlers and posterity...
I have a client calling an IIS hosted webservice hosted in another domain (Active Directory). There is not full trust between the client domain and the domain where the web services is hosted. One of the many challenges with the selective trust between these two domains is that Kerberos does not work when calling from one to the other.
In my case I was trying to call a service in another domain where I found out that a SPN was registered. Like this : http/myurl.test.local (just an example)
This forces the call to use Kerberos instead of letting it fall back to NTLM and this gave me a 405 back from the calling server.
After removing the spn and allowing the call to fall back to NTLM, it works fine.
As I said ... this is not something you are likely to run into, as most organizations do not venture into having such a selective trusts between two domains ... But it gives a 504 and caused me a few (more) gray hairs.
If your using ASP.Net 5 (now known as ASP.Net Core v1) ensure in your project.json "commands" section for each site you are hosting that the Kestrel proxy listening port differs between sites, otherwise one site will work but the other will return a 504 gateway timeout.
"commands": {
"web": "Microsoft.AspNet.Server.Kestrel --server.urls http://localhost:5090"
},
Source: Stackoverflow.com