Request body: next upstream fix.

After introduction of chunked request body handling in 1.3.9 (r4931),
r->request_body->bufs buffers have b->start pointing to original buffer
start (and b->pos pointing to real data of this particular buffer).

While this is ok as per se, it caused bad things (usually original request
headers included before the request body) after reinit of the request
chain in ngx_http_upstream_reinit() while sending the request to a next
upstream server (which used to do b->pos = b->start for each buffer
in the request chain).

Patch by Piotr Sikora.


git-svn-id: svn://svn.nginx.org/nginx/trunk@5111 73f98a42-aea0-e011-b76d-00259023448c
Request body: avoid linking rb->buf to r->header_in.

Code to reuse of r->request_body->buf in upstream module assumes it's
dedicated buffer, hence after 1.3.9 (r4931) it might reuse r->header_in
if client_body_in_file_only was set, resulting in original request
corruption.  It is considered to be safer to always create a dedicated
buffer for rb->bufs to avoid such problems.


git-svn-id: svn://svn.nginx.org/nginx/trunk@5112 73f98a42-aea0-e011-b76d-00259023448c
Upstream: call ngx_http_run_posted_requests() on resolve errors.

If proxy_pass to a host with dynamic resolution was used to handle
a subrequest, and host resolution failed, the main request wasn't run
till something else happened on the connection.  E.g. request to "/zzz"
with the following configuration hanged:

    addition_types *;
    resolver 8.8.8.8;

    location /test {
        set $ihost xxx;
        proxy_pass http://$ihost;
    }

    location /zzz {
      add_after_body /test;
      return 200 "test";
    }

Report and original version of the patch by Lanshun Zhou,
http://mailman.nginx.org/pipermail/nginx-devel/2013-March/003476.html.


git-svn-id: svn://svn.nginx.org/nginx/trunk@5113 73f98a42-aea0-e011-b76d-00259023448c