Some of the changes made to mod_proxy in trunk (which were also backported to 2.0.55) have resulting in mod_proxy assuming that all sub-requests are GETs. Whilst this is typically true of SSIs, I don't see a reason to enforce this. Indeed, I have a custom module that requires exactly this (it turns certain sub-requests into POSTs, which go to a backend server using mod_proxy). I asked about this on the apache-dev mailing list: http://marc.theaimsgroup.com/?l=apache-httpd-dev&m=111099194601082&w=2 No one stated any opposition (though it generate much discussion to be fair), so I'd like to go ahead and suggest this is a regression in behaviour and the patch(s) I'm about to attach should be applied.
Created attachment 16904 [details] allow POST sub-requests in HTTP proxy (for 2.1-HEAD)
(In reply to comment #1) > Created an attachment (id=16904) [edit] > allow POST sub-requests in HTTP proxy (for 2.0-HEAD) > Nrgh - sorry, that's the 2.1-HEAD patch - have updated the description.
Created attachment 16907 [details] allow POST sub-requests in HTTP proxy (for 2.0-HEAD)
Did this ever get applied, or has it fallen by the wayside?
(In reply to comment #4) > Did this ever get applied, or has it fallen by the wayside? I'm pretty certain it has not been applied. Just checked mod_proxy_http.c in trunk, and it's still doing if (r->main) { ...; goto skip_body; } for all HTTP methods. I never got the "should httpd allow sub-requests to be other than GET?" question answered, but I would stand by the argument that it did previously, and to change the behaviour back should not break anything. I was contacted privately a while ago from someone else who found this bug report, and would also appreciate the suggested patch being applied. So if you're happy to do that, great! If I can do anything to help (such as creating updated patches for trunk and 2.2.x) please do let me know. Reviewing the patch (I wrote it a while ago now!), I wonder if r->method_number != M_POST is a reasonable check. Do any other HTTP methods have bodies (eg: PUT); is there something else we can check? Actually, I wonder if the "correct" fix here is actually in the sub-request generation code - making it not inherit C-L/T-E headers for GETs (the default). If someone (such as myself) tries to generate a POST sub-request, they should be responsible for setting those headers accordingly. Then the explicit skip_body check would no longer be necessary.
There are some underlying issues caused by the way the server currently works that make this a difficult problem to solve. Right now today, the server goes to some effort to ensure that a body is read from the browser once, and once only. If the body were to be read twice, the next browser request would be read in and interpreted as a body instead, or if there is no next request, the request would hang waiting for data from the browser that the browser has no intention of sending. This has been addressed on trunk through the kept body filter, which attempts to set aside the body up to some limit just once, and then "caps" the input filter stack, allowing you to read the same saved body over and over again in subrequests, without ever having to worry that the browser be read from more than once.
Please help us to refine our list of open and current defects; this is a mass update of old and inactive Bugzilla reports which reflect user error, already resolved defects, and still-existing defects in httpd. As repeatedly announced, the Apache HTTP Server Project has discontinued all development and patch review of the 2.2.x series of releases. The final release 2.2.34 was published in July 2017, and no further evaluation of bug reports or security risks will be considered or published for 2.2.x releases. All reports older than 2.4.x have been updated to status RESOLVED/LATER; no further action is expected unless the report still applies to a current version of httpd. If your report represented a question or confusion about how to use an httpd feature, an unexpected server behavior, problems building or installing httpd, or working with an external component (a third party module, browser etc.) we ask you to start by bringing your question to the User Support and Discussion mailing list, see [https://httpd.apache.org/lists.html#http-users] for details. Include a link to this Bugzilla report for completeness with your question. If your report was clearly a defect in httpd or a feature request, we ask that you retest using a modern httpd release (2.4.33 or later) released in the past year. If it can be reproduced, please reopen this bug and change the Version field above to the httpd version you have reconfirmed with. Your help in identifying defects or enhancements still applicable to the current httpd server software release is greatly appreciated.