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 ?

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;