https://bz.apache.org/bugzilla/show_bug.cgi?id=63626
--- Comment #3 from Michael Osipov <[email protected]> --- My initial problem is described in https://www.mail-archive.com/[email protected]/msg132332.html. I will try to summarize: HTTPd responded HTTP_SERVICE_UNAVAILABLE, Tomcat did not respond it time, but after ProxyTimeout has elapsed with 500 because of a broken pipe. Our API users were surprised just like me because the service was up and running, but external resources (some domain controllers) did not respond in time. The service *was* available. It took me some time to understand the root cause. HTTP_GATEWAY_TIME_OUT would have made it easiser/faster to understand. It shall be possible to clearly understand whether an upstream server did not respond in time, did not respond to a connect() (unavailable) or send a bad response (bad gateway). Look at the first hunk: > diff --git a/modules/proxy/mod_proxy_http.c b/modules/proxy/mod_proxy_http.c > index ec1e042c4e..6667931efd 100644 > --- a/modules/proxy/mod_proxy_http.c > +++ b/modules/proxy/mod_proxy_http.c > @@ -1255,7 +1255,7 @@ int ap_proxy_http_process_response(proxy_http_req_t > *req) > apr_table_setn(r->notes, "proxy_timedout", "1"); > ap_log_rerror(APLOG_MARK, APLOG_DEBUG, 0, r, APLOGNO(01103) > "read timeout"); > if (do_100_continue) { > - return ap_proxyerror(r, HTTP_SERVICE_UNAVAILABLE, > "Timeout on 100-Continue"); > + return ap_proxyerror(r, HTTP_GATEWAY_TIME_OUT, "Timeout > on 100-Continue"); "proxy_timedout" is set, but the status code does not reflect that. Moreover, as you have already noticed, it violates RFC 7231, 6.6. -- You are receiving this mail because: You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
