HTTP response codes 500 vs 502 vs 503?

Question

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

1. 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 ?

2. App is down or not available. My understanding is nginx will throw 503 not 502 in this case ?

3. App is taking more time to process than nginx default connection time out. My understanding is nginx will throw 504 in this case ?

4. 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 ?

Louralourdes

Answer 1

1. 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.

2. 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

3. Yes, you should be getting 504 (gateway timeout), when Apache/app is timing out in relation to NGINX timeouts

4. 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;

Hartmann

Point 2 : You said ` because, in your setup, Apache is the gateway for NGINX` .Not sure whether we should classify NGINX as gateway or apache as gateway ? For browser/client NGINX is gateway . is n't ? Another point is if server is down then who will generate 502 ? Also not sure then, when 503 will be generated . As per doc 503 is generated when server is down. – Louralourdes

503 can be emitted for a number of reasons but it typically represents a capacity issue or intentional maintenance. One case where 503 is used for things similar to "server is down", is in Varnish setup - this software happens to use 503 for when in fails to communicate its gateway/upstream. In your setup Apache is the gateway for NGINX and not the other way around. In other words, Apache is the upstream server for NGINX. Again, in your specific setup, with NGINX being down only, the clients will see browser-specific errors and not HTTP status at all... – Hartmann

... as there is no HTTP connection per se. And if you have NGINX alive/Apache is down situation then the clients will get 502 from NGINX. (bad gateway = bad Apache). – Hartmann

Thanks. One last question on point 2 , you said If Apache is completely down, you should be getting a 502 (bad gateway), because, in your setup, Apache is the gateway for NGINX My understanding with this is, If apache is down and nginx is up then nginix will get connection refused error(or something like this) and will generate 502 response code(or I can say map connection refused error to 502 response code) itself. Right ? – Louralourdes

More or less, yes. To be exact, NGINX will see that the network port/socket of the gateway is not available/ does not exist, and emit 502. Contrary to the situation when those exist (Apache is alive), but it takes too much time getting any data from it (then 504). – Hartmann

NGINX is the gateway. By definition: [client] -> [gateway] -> [server]. We can say the name "Bad Gateway" is misleading or has a tricky interpretation. – Cockeye