Re: svn commit: r160645 - httpd/httpd/branches/2.0.x/STATUS

[Greg Ames <gr...@remulak.net>]

William A. Rowe, Jr. wrote:

>>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?

thanks, I think I understand the concern.  in that case it wouldn't be 
appropriate for the subrequest to simply inherit body headers/lack of body 
headers from the outer request, as the 2.0 branch does now.  they would have to 
be created independently.  it probably would be asking too much to expect 
ap_sub_req_protocol to do the right thing for a GET subrequest with a body.  but 
that's where this fix is.

> 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.

[gregames@gandalf httpd-2.1]$ grep -ri apreq .
[gregames@gandalf httpd-2.1]$

doesn't appear to be stable enough for 2.0 at present.

however, I will remove this backport vote.  I only know of one real site that 
ever hit this.  if someone wants to come up with an improved patch for 2.1, that 
would be great.

Greg

Re: svn commit: r160645 - httpd/httpd/branches/2.0.x/STATUS

[Joe Schaefer <jo...@sunstarsys.com>]

Greg Ames <gr...@remulak.net> writes:

> William A. Rowe, Jr. wrote:

[...]

>> 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.
>
> [gregames@gandalf httpd-2.1]$ grep -ri apreq .
> [gregames@gandalf httpd-2.1]$
>
> doesn't appear to be stable enough for 2.0 at present.

I'd like to help see httpd 2.2 + libapreq2 integrated, but it's sort of 
tricky for us over in apreq because we have a very complex autmake-based
build system.  I think everyone'd be happier if apreq weaned
itself off of automake and towards the build system used by apr-util,
but at present we don't have a lot of auto-foo guys floating around 
over on apreq-dev@.  What makes things *very* complicated for apreq, IMO,
is the CPAN distribution channel that mod_perl'ers expect from us.

-- 
Joe Schaefer