httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <>
Subject Re: svn commit: r160645 - httpd/httpd/branches/2.0.x/STATUS
Date Fri, 29 Apr 2005 01:06:08 GMT
At 03:19 PM 4/28/2005, Greg Ames wrote:
> wrote:
>>     * don't propagate input headers describing a body to a GET subrequest
>>       with no body
>>@@ -219,12 +220,34 @@
>>       -1: jerenkrantz (read_length isn't a sufficient check to see if a body
>>                        is present in the request; presence of T-E and C-L in
>>                        the headers is the correct flag.)
>>+      +/-0: wrowe (this has a negative impact on modules who wish to 'inspect'
>>+            the headers, e.g. an xml transformation affected by the query
>>+            string or request POST args.  The right solution is adopt apreq,
>>+            providing an API for filters to participate in POST bodies.)
>>       gregames: done in rev 160573
>Will, can you help me understand your concern?  this doesn't change the headers of the
POST request.  it only affects which new headers we generate for the new SSI GET subrequest.

Well I totally understand the issue - I'm blowing up in some PHP
code due to an earlier php include= snarfing up the post body.

My concern is, what -if- the body is actually destined/desired
by the 'included' content as opposed to the outer (apparent) url?

If we can revert to 2.0.39 behavior (this changed, either in
apache or in php between 4.0 and 4.3.10) I'd be fine with some
fix.  But sub-content should be able to participate.  So I'm
effectively arguing that apreq should be the arbiter of bodies.
If the subrequest calls apreq API's (rather than trusting headers
which should be handled in our HTTP filter stack) then everything
would be goodness.  And the included body shouldn't 'snarf' that
post content leaving nothing for the main handler.  apreq would
be a good broker to distribute it.


View raw message