<p dir="ltr">Because there is chance to call ngx_http_upstream_finalize_request in function ngx_http_upstream_connect or it's sub calls, and i think this makes no difference with failed resolution~</p>
<div class="gmail_quot<blockquote class=" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello!<br>
<br>
On Wed, Mar 13, 2013 at 12:31:00AM +0800, lanshun zhou wrote:<br>
<br>
> in ngx_http_upstream_resolve_handler, posted requests are not handled, so<br>
> if a run time<br>
> dns resolving is failed in a subrequest, (for example, the resolver can not<br>
> be reached, or<br>
> the domain does not exist) the main request will know nothing about this,<br>
> until something<br>
> else attached to this connection happens, like connection broken or a write<br>
> timeout<br>
><br>
> a patch is attached and hope it helps<br>
><br>
> simple configuration that can reproduce the problem (with addition module<br>
> enabled):<br>
><br>
> addition_types *;<br>
><br>
> resolver your_resolver_here;<br>
><br>
> location /test {<br>
> set $ihost xxx; # xxx here causes a failed<br>
> run-time dns resolving<br>
> proxy_pass http://$ihost;<br>
> }<br>
><br>
> location /zzz {<br>
> add_after_body /test;<br>
> return 200 "test";<br>
> }<br>
><br>
> curl -v <a href="http://localhost/zzz" target="_blank">http://localhost/zzz</a><br>
<br>
Thank you for your report, see below for comments about the patch.<br>
<br>
<br>
> diff -ruNp nginx-1.3.14/src/http/ngx_http_upstream.c nginx-1.3.14_zls/src/http/ngx_http_upstream.c<br>
> --- nginx-1.3.14/src/http/ngx_http_upstream.c 2013-02-18 23:08:46.000000000 +0800<br>
> +++ nginx-1.3.14_zls/src/http/ngx_http_upstream.c 2013-03-13 00:01:01.490582380 +0800<br>
> @@ -878,11 +878,13 @@ ngx_http_upstream_cache_send(ngx_http_re<br>
> static void<br>
> ngx_http_upstream_resolve_handler(ngx_resolver_ctx_t *ctx)<br>
> {<br>
> + ngx_connection_t *c;<br>
> ngx_http_request_t *r;<br>
> ngx_http_upstream_t *u;<br>
> ngx_http_upstream_resolved_t *ur;<br>
><br>
> r = ctx->data;<br>
> + c = r->connection;<br>
><br>
> u = r->upstream;<br>
> ur = u->resolved;<br>
> @@ -894,7 +896,8 @@ ngx_http_upstream_resolve_handler(ngx_re<br>
> ngx_resolver_strerror(ctx->state));<br>
><br>
> ngx_http_upstream_finalize_request(r, u, NGX_HTTP_BAD_GATEWAY);<br>
> - return;<br>
> +<br>
> + goto posted_requests;<br>
> }<br>
><br>
> ur->naddrs = ctx->naddrs;<br>
> @@ -919,13 +922,17 @@ ngx_http_upstream_resolve_handler(ngx_re<br>
> if (ngx_http_upstream_create_round_robin_peer(r, ur) != NGX_OK) {<br>
> ngx_http_upstream_finalize_request(r, u,<br>
> NGX_HTTP_INTERNAL_SERVER_ERROR);<br>
> - return;<br>
> + goto posted_requests;<br>
> }<br>
><br>
> ngx_resolve_name_done(ctx);<br>
> ur->ctx = NULL;<br>
><br>
> ngx_http_upstream_connect(r, u);<br>
> +<br>
> +posted_requests:<br>
> +<br>
> + ngx_http_run_posted_requests(c);<br>
> }<br>
<br>
Any reason to run posted requests on successful resolution? For<br>
me it looks like something like this should be enough:<br>
<br>
--- a/src/http/ngx_http_upstream.c<br>
+++ b/src/http/ngx_http_upstream.c<br>
@@ -894,6 +894,7 @@ ngx_http_upstream_resolve_handler(ngx_re<br>
ngx_resolver_strerror(ctx->state));<br>
<br>
ngx_http_upstream_finalize_request(r, u, NGX_HTTP_BAD_GATEWAY);<br>
+ ngx_http_run_posted_requests(r->connection);<br>
return;<br>
}<br>
<br>
@@ -919,6 +920,7 @@ ngx_http_upstream_resolve_handler(ngx_re<br>
if (ngx_http_upstream_create_round_robin_peer(r, ur) != NGX_OK) {<br>
ngx_http_upstream_finalize_request(r, u,<br>
NGX_HTTP_INTERNAL_SERVER_ERROR);<br>
+ ngx_http_run_posted_requests(r->connection);<br>
return;<br>
}<br>
<br>
<br>
--<br>
Maxim Dounin<br>
<a href="http://nginx.org/en/donation.html" target="_blank">http://nginx.org/en/donation.html</a><br>
<br>
_______________________________________________<br>
nginx-devel mailing list<br>
<a href="mailto:nginx-devel@nginx.org">nginx-devel@nginx.org</a><br>
<a href="http://mailman.nginx.org/mailman/listinfo/nginx-devel" target="_blank">http://mailman.nginx.org/mailman/listinfo/nginx-devel</a><br>
</div>