Gone through HTTP response codes .. and understands the what these response codes(rcodes) stands for
But I am not sure what rcode will be sent to client/consumer(say browser) in below scenario. I am using NGINX as reverse proxy and Apache as HTTP
server running web application(say app) behind the NGINX.
Couple of scenario
Runtime error occurs in app which by throws rcode as 500(runtime error code by default). My understanding is nginx will continue to throw 500 and not convert
it to 502 ?
App is down or not available. My understanding is nginx will throw 503 not 502 in this case ?
App is taking more time to process than nginx default connection time out. My understanding is nginx will throw 504 in this case ?
If all above points are correct not sure when 502 will be thrown by nginx ? When NGINX will consider the response received from upstream server as invalid response ?
NGINX will not alter the 500 from the app as long as it doesn't step on a problem contacting / fetching data from Apache. E.g. it's a perfectly possible situation that your app will generate a 500, but a problem in NGINX communication against Apache will result in a different 50x, so that 50x is the one the client will see.
If Apache is completely down, you should be getting a 502 (bad gateway), because, in your setup, Apache is the gateway for NGINX. The same will happen if NGINX does not "like" Apache's response in a way, e.g. when Apache sends a response which has headers exceeding NGINX's proxy_buffer_size
Yes, you should be getting 504 (gateway timeout), when Apache/app is timing out in relation to NGINX timeouts
See point 2. And the following: NGINX will simply passthrough whichever response code from the upstream (as in gateway = Apache), so it doesn't need to take any consideration on whether a given response is invalid in terms of response codes, by default.
You can have NGINX take error response codes coming from Apache in consideration and act differently by use of proxy_intercept_errors, which combined with error_page, can allow you to "rewrite" response codes / error messages from Apache, e.g. to "masquarade" app failures as Service Unavailable:
error_page 500 =503 /503.html;
proxy_intercept_errors on;
Related
When I am searching for a link from my drupal website https://example.com/index2.php?option=com_ckforms&view=ckforms&id=1&Itemid=190
i am getting 502(bad gateway) response and redirecting to 502 nginx error page instead of 404 as 5xx errors are reserved for actual service errors.
I am getting "upstream sent unsupported FastCGI protocol version: 72 while reading response header from upstream" error in logs.
I found that the reason could be- This server (Web Front-End) received an invalid response from an upstream (Web Back-End) server it accessed to fulfil the request.In most cases this will not mean that the upstream server is down, but rather that the upstream server and the gateway/proxy do not agree on the protocol for exchanging data.The problem is most commonly caused when there is a problem with IP communications between the Web Front and Back-Ends. Before you attempt to resolve this problem you should clear your browser cache completely.
Could anyone please suggest me
Thanks in Advance!
I added
try_files $uri =404;
in nginx configuration file at location settings. This resolved my issue.
Let's say we are initiating oauth flow from our server and the provider times out. What do we return as status code? 503 for try again later or 504 to state some other server timed out?
I think 502 are the most appropiate in this case
502 Bad Gateway
A 502 error means that a website server that is serving as a reverse
proxy for the website origin server (for example, a CDN PoP) did not
receive a valid response from the origin server. This may be because
the origin server is experiencing issues, there is an invalid or
incorrect DNS name, or because a firewall on the origin server has
blocked the reverse proxy server request.
This may also occur when requests at the origin server are taking
several minutes to complete and a caching tool such as Varnish Cache
has been instructed to timeout after a set number of seconds. Varnish
Cache has a default timeout of 60 seconds, which section.io recommends
keeping for security and alerting reasons.
504 Gateway Timeout
Similar to the 502 error, the 504 Gateway Timeout error occurs if the
server that is acting as a proxy for the website origin server did not
receive a response from the website origin server within a set time
period. This may indicate an issue with the DNS host or hosting
company, or with the connection or configuration between the reverse
proxy servers and the website origin server.
More info here https://www.section.io/blog/504-503-errors-difference/
There is already an interesting question that has a similar context as yours, and there are a varied number of choices that you choose from.
Maybe have a quick look at this question.
In my opinion, from all the above-mentioned choices of HTTP status codes, I would recommend using 419 that states the following as per the documentation:
419 Authentication Timeout
Not a part of the HTTP standard, 419 Authentication Timeout denotes that previously valid authentication has expired. It is used as an alternative to 401 Unauthorized in order to differentiate from otherwise authenticated clients being denied access to the specific server
I have nginx as the reverse proxy of uwsgi service, and settings are very simple, just pass the connection to the backend. And when the code has come problem, uwsgi will send a 502 error to nginx, which make nginx only display 502 errors, and in order to check the problem, we have to check the uwsgi log, which is very inconvenient when we are developing. And I search the google which couldn't give me an answer, so is there any method to display code exceptions to nginx instead of just a 502 error.
use --catch-exceptions but use it only in development, as it could show sensible data
I hosted my application, and doing some stress tests, I noticed that when shooting around 50 requests in parallel, the server responds HTTP 503.
What does this means? It may be some specific configuration limiting the number of requests from Tomcat?
Thanks.
That typically just means you've run out of threads to handle the request. You could try increasing the maxThreads in your Tomcat server.xml file, or if you're using Apache HTTP server as a front end, you may need to configure your Connector to allow more connections.
A 503 status indicates the service handling the request is unavailable.
The server is currently unable to handle the request due to a
temporary overloading or maintenance of the server.
- HTTP Specification on 503
From time-to-time you'll see this if you're running Tomcat behind Apache, with Apache operating as a proxy. If Apache is unable to contact Tomcat it will return a 503 response.
If you are using Apache httpd as a front-end, you may want to check if there is a firewall between Tomcat and Apache. After having disabled the firewall on the Tomcat machine in our environment, the 503 errors disappeared.
See also this.
Above document also describes other less drastic ways of solving the 503 problem when a firewall is involved.
I've written a small proxy, and I'm wondering if it's correct for me to return a 502 Bad Gateway error when the proxy server itself has an internal error. The RFC seem to say that this is something you only do if the server on the other end gives a bad response.
The server, while acting as a gateway or proxy, received an invalid response from the upstream server it accessed in attempting to fulfill the request.
I take this to mean that if for example the upstream server is setting a content-length header that is different from the response body length, we should set a 502 error i.e. when the response is invalid.
Am I misinterpreting the RFC?
An invalid Content-Length could just as well be handled as an invalid response (502 error). 503 should only be used when the condition is temporary, i.e., the same request can be served at a later time.
The common practice is to use 500 AFAIK. This is in a way wrong, as there's no distinction between the origin server and the proxy. I've also observed servers returning 504, but I consider this behavior wrong.