DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUGĀ·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=37402>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED ANDĀ·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=37402





------- Additional Comments From [EMAIL PROTECTED]  2007-09-01 13:16 -------
(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.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to