Since r1860166 in 2.4.41 the order of request body prefetch and backend connect changed. This is due to backporting r1656259 "mod_proxy_http: don't connect or reuse backend before prefetching request body." or parts of it with the same commit. Now when a POST request has a small body that fits into the prefetch buffer and has CL set plus the request to the first backend in the balancer fails during the TCP connect to this backend, the failed over request will be send to the next backend with a CL of 0. Order of execution: 2.4.39: In proxy_http_handler(): - ap_proxy_determine_connection() - ap_proxy_check_connection() - optionally ap_proxy_connect_backend() which might fail. - ap_proxy_connection_create_ex() - ap_proxy_http_request() which does prefetch late! 2.4.41: In proxy_http_handler(): - ap_proxy_determine_connection() - early ap_proxy_http_prefetch() which does the prefetch! - optionally again ap_proxy_determine_connection() - ap_proxy_check_connection() - optionally ap_proxy_connect_backend() which might fail. - ap_proxy_connection_create_ex() - ap_proxy_http_request() Regards, Rainer
Fixed in trunk via r1869216 and r1869224. Not yet backported to 2.4.x
Created attachment 37044 [details] Patch for 2.4 Patch backported to 2.4 branch.
*** Bug 63959 has been marked as a duplicate of this bug. ***
To clarify comment #2: there's a patch backport available, but it has not yet been applied to 2.4.x.
Backported in 2.4.x in r1875111 This is part of 2.4.42
I observed the problem with version 2.4.54-1~deb11u1 (latest debian bullseye version) *Some* POST requests with a small body had their body dropped by mod_proxy_http. I cannot ascertain that this is the exact same problem, but the symptoms are the same. So maybe the fix pushed in 2.4.42 was not complete. Downgrading to 2.4.38-3+deb10u8 (latest debian buster version) fixed the problem.