On 2019-10-30 07:07, Yann Ylavic wrote:
On Tue, Oct 29, 2019 at 8:01 PM Rainer Jung wrote:
...
That's intended?
Yes, if req->prefetch_nonblocking we need to enter the loop at least
once, but since we are non-blocking it does not hurt to _try_ to read
more (even when we come back here in the
On Tue, Oct 29, 2019 at 8:01 PM Rainer Jung wrote:
>
> Double check: the condition in the do-while loop that was chaned to a
> while loop has also changed:
>
> FROM
>
> do { ... }
> while ((bytes_read < MAX_MEM_SPOOL - 80)
> && !APR_BUCKET_IS_EOS(APR_BRIGADE_LAST(input_brigade))
>
Double check: the condition in the do-while loop that was chaned to a
while loop has also changed:
FROM
do { ... }
while ((bytes_read < MAX_MEM_SPOOL - 80)
&& !APR_BUCKET_IS_EOS(APR_BRIGADE_LAST(input_brigade))
&& !req->prefetch_nonblocking);
TO
while (((bytes_read <
Hi Yann,
Am 29.10.2019 um 16:58 schrieb Yann Ylavic:
On Tue, Oct 29, 2019 at 4:24 PM Rainer Jung wrote:
Thank you Yann. Let me know when I should test something. It's OK, if it
is not yet the final fix ;)
The attached patch seems to work for me..
LGTM. I applied/ported to 2.4.x, it fixes
On Tue, Oct 29, 2019 at 4:24 PM Rainer Jung wrote:
>
> Thank you Yann. Let me know when I should test something. It's OK, if it
> is not yet the final fix ;)
The attached patch seems to work for me..
Index: modules/proxy/mod_proxy_http.c
Am 29.10.2019 um 16:19 schrieb Yann Ylavic:
Hi Rainer,
thanks for looking at this.
Aha, and this is due to the fact, that r1656259 "mod_proxy_http: don't
connect or reuse backend before prefetching request body." or parts of
it was backported from trunk to 2.4 as part of r1860166.
Yes,
Hi Rainer,
thanks for looking at this.
>
> Aha, and this is due to the fact, that r1656259 "mod_proxy_http: don't
> connect or reuse backend before prefetching request body." or parts of
> it was backported from trunk to 2.4 as part of r1860166.
Yes, that's where prefetch was moved before
> Am 29.10.2019 um 14:45 schrieb Rainer Jung :
>
> Aha, and this is due to the fact, that r1656259 "mod_proxy_http: don't
> connect or reuse backend before prefetching request body." or parts of it was
> backported from trunk to 2.4 as part of r1860166.
>
> So I think (not yet verified),
Yikes! How can we test for that via the Perl test framework?
> On Oct 29, 2019, at 9:45 AM, Rainer Jung wrote:
>
> Aha, and this is due to the fact, that r1656259 "mod_proxy_http: don't
> connect or reuse backend before prefetching request body." or parts of it was
> backported from trunk to
Aha, and this is due to the fact, that r1656259 "mod_proxy_http: don't
connect or reuse backend before prefetching request body." or parts of
it was backported from trunk to 2.4 as part of r1860166.
So I think (not yet verified), that the same problems applies to trunk
since r1656259 in
The reason why this fails now is that we prefetch in 2.4.41 the request
body before doing the connection check to the backend. In 2.4.39 we did
that after doing the check, so the body was still there when doing the
final request sending.
2.4.39:
In proxy_http_handler():
-
This happens in the case of a small body. We read the body into
req->input_brigade in ap_proxy_http_prefetch() before trying the first
node, but then loose it on the second node, because we use another req
and thus also another req->input_brigade then.
Not sure, how we could best save the
A first heads-up: it seems this commit broke failover for POST requests.
Most (or all?) of the times a balancer failover happens for a POST
request, the request send to the failover node has a Content-Length of
"0" instead of the real content length.
I use a trivial setup like this:
13 matches
Mail list logo
