You are viewing a plain text version of this content. The canonical link for it is here.
Posted to cvs@httpd.apache.org by wr...@apache.org on 2005/04/09 02:38:46 UTC
svn commit: r160645 - httpd/httpd/branches/2.0.x/STATUS
Author: wrowe
Date: Fri Apr 8 17:38:46 2005
New Revision: 160645
URL: http://svn.apache.org/viewcvs?view=rev&rev=160645
Log:
Commit some votes before this gets out of hand.
Re-promote a patch (not voted down) to 'under consideration',
Eliminate a patch I 1) don't know how to write, and 2) would
only apply to non-OpenSSL solutions, which I no longer hack at.
Add some notes on our recent dev@httpd discussions.
Modified:
httpd/httpd/branches/2.0.x/STATUS
Modified: httpd/httpd/branches/2.0.x/STATUS
URL: http://svn.apache.org/viewcvs/httpd/httpd/branches/2.0.x/STATUS?view=diff&r1=160644&r2=160645
==============================================================================
--- httpd/httpd/branches/2.0.x/STATUS (original)
+++ httpd/httpd/branches/2.0.x/STATUS Fri Apr 8 17:38:46 2005
@@ -105,6 +105,7 @@
http://cvs.apache.org/viewcvs.cgi/httpd-2.0/server/log.c?r1=1.150&r2=1.151
http://cvs.apache.org/viewcvs.cgi/httpd-2.0/include/http_log.h?r1=1.46&r2=1.48
+1: trawick, stoddard
+ -0: wrowe; seems this (valid) improvement would encourage non-compatible mods.
*) mod_headers: Support {...}s tag for SSL variable lookup.
http://www.apache.org/~jorton/mod_headers-2.0-ssl.diff
@@ -208,7 +209,7 @@
* Win32: Move call to mpm_service_install to the rewrite_args hook
from the post_config hook.
http://svn.apache.org/viewcvs?view=rev&rev=154319
- +1: stoddard, striker
+ +1: stoddard, striker, wrowe (as corrected in subsequent patches)
* 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
* mod_version: New Module, Backport from trunk.
http://svn.apache.org/repos/asf/httpd/httpd/trunk/modules/metadata/mod_version.c
(Also need to backport docs, and build system stuff.)
- +1: pquerna, jerenkrantz
+ +1: pquerna, jerenkrantz, wrowe (trivial, would even be cool in 1.3)
+
+ *) Provide TLS/SSL upgrade functionality in mod_ssl allowing an unsecure
+ connection to be upgraded to a secure connection upon request by the
+ client. The full patch file is available at http://www.apache.org/~bnicholes/
+ as well as a test client tlsupgrade.c. This functionality is mainly used by
+ IPP clients today.
+ modules/ssl/mod_ssl.c: r1.75, r1.97, r1.100
+ modules/ssl/mod_ssl.h: r1.123
+ modules/ssl/ssl_engine_config.c: r1.71, r1.90
+ modules/ssl/ssl_engine_init.c: r1.107, r1.126
+ modules/ssl/ssl_engine_io.c: r1.102, r1.124
+ modules/ssl/ssl_engine_kernel.c: r1.83, r1.105, r1.108
+ modules/ssl/ssl_util.c: r1.36
+ modules/ssl/ssl_private.h: r1.2
+ +1: bnicholes, wrowe
+ -0: jerenkrantz (should wait for 2.2)
+ -0: pquerna (2.2)
+ -0: jorton (msgid <20...@redhat.com>)
PATCHES TO BACKPORT THAT ARE ON HOLD OR NOT GOING ANYWHERE SOON:
@@ -263,24 +286,6 @@
2.0, just let 'em in
-1: wrowe (as nd suggests, leave the dead horse in peace.)
- *) Provide TLS/SSL upgrade functionality in mod_ssl allowing an unsecure
- connection to be upgraded to a secure connection upon request by the
- client. The full patch file is available at http://www.apache.org/~bnicholes/
- as well as a test client tlsupgrade.c. This functionality is mainly used by
- IPP clients today.
- modules/ssl/mod_ssl.c: r1.75, r1.97, r1.100
- modules/ssl/mod_ssl.h: r1.123
- modules/ssl/ssl_engine_config.c: r1.71, r1.90
- modules/ssl/ssl_engine_init.c: r1.107, r1.126
- modules/ssl/ssl_engine_io.c: r1.102, r1.124
- modules/ssl/ssl_engine_kernel.c: r1.83, r1.105, r1.108
- modules/ssl/ssl_util.c: r1.36
- modules/ssl/ssl_private.h: r1.2
- +1: bnicholes, wrowe
- -0: jerenkrantz (should wait for 2.2)
- -0: pquerna (2.2)
- -0: jorton (msgid <20...@redhat.com>)
-
* Replace some of the mutex locking in the worker MPM with
atomic operations for higher concurrency.
server/mpm/worker/fdqueue.c 1.24, 1.25
@@ -437,18 +442,6 @@
RELEASE NON-SHOWSTOPPERS BUT WOULD BE REAL NICE TO WRAP THESE UP:
- * mod_ssl: We twiddle status bits rather than calling SSL_renegotiate
- to unset the current negotiation status. This especially affects
- sslc users who can't touch these internal bits (nor should OpenSSL
- based apps do so.) Flipping to SSL_renegotiate causes us to start
- failing perl-framework tests. Needs some further research.
- http://www.apache.org/~wrowe/ssl_renegotiate.patch for a clean 2.0 patch,
- or for httpd-2.1 refer to:
- modules/ssl/config.m4 1.15
- modules/ssl/ssl_engine_io.c 1.08
- modules/ssl/ssl_engine_kernel.c 1.93
- modules/ssl/ssl_toolkit_compat.c 1.34
-
* There is a bug in how we sort some hooks, at least the pre-config
hook. The first time we call the hooks, they are in the correct
order, but the second time, we don't sort them correctly. Currently,
@@ -642,6 +635,9 @@
Questions; htdbm exists, time to kill dbmmanage, or does it remain
useful as a perl dbm management example? If we keep it,
do we address the issue above?
+ March discussion summary; we are missing group support. With that
+ added to trunk, this script will go away. It will remain
+ in 2.0 based on our versioning approach.
* Integrate mod_dav.
Some additional items remaining:
mod_version for 2.0.x, was Re: svn commit: r160645 - httpd/httpd/branches/2.0.x/STATUS
Posted by Paul Querna <ch...@force-elite.com>.
Paul Querna wrote:
> Okay, I was backporting this, but ran into a few problems.
>
> First, it requires a minor MMN bump to add the version API stuff. Thats
> not too bad, and I was making a patch for all of it.
>
> The biggest problem is that my working copy in subversion broke. 'svn
> diff' just doesn't work right (added files are not shown).
>
> I opened a bug report on it:
> http://subversion.tigris.org/issues/show_bug.cgi?id=2270
>
> I am ready to give up on mod_version for 2.0.54.... unless someone else
> is feeling lucky..
Since the subversion people think that my 'expectations' of 'svn diff'
working this way are wrong, I turned it into an integration branch:
https://svn.apache.org/repos/asf/httpd/httpd/branches/mod_version_for_2.0.x
I believe everything needed is done in that branch. Source Code
(Including a Minor MMN Bump!), Build System and Documentation.
Because this backport has grown quite large, I reset the voting in the
STATUS file -- I think people were mostly agreeing on the concept.
Personally, I didn't see the need of a minor MMN bump until I did the
backport.
-Paul
Re: svn commit: r160645 - httpd/httpd/branches/2.0.x/STATUS
Posted by Paul Querna <ch...@force-elite.com>.
Paul Querna wrote:
> Sander Striker wrote:
>
>> Paul, Justin, could you either provide me with a complete patch
>> against 2.0.x
>> or add the revisions I need to merge?
>>
>
> I am backporting mod_version right now.
>
Okay, I was backporting this, but ran into a few problems.
First, it requires a minor MMN bump to add the version API stuff. Thats
not too bad, and I was making a patch for all of it.
The biggest problem is that my working copy in subversion broke. 'svn
diff' just doesn't work right (added files are not shown).
I opened a bug report on it:
http://subversion.tigris.org/issues/show_bug.cgi?id=2270
I am ready to give up on mod_version for 2.0.54.... unless someone else
is feeling lucky..
-Paul
Re: svn commit: r160645 - httpd/httpd/branches/2.0.x/STATUS
Posted by Paul Querna <ch...@force-elite.com>.
Sander Striker wrote:
> Paul, Justin, could you either provide me with a complete patch against
> 2.0.x
> or add the revisions I need to merge?
>
I am backporting mod_version right now.
Re: svn commit: r160645 - httpd/httpd/branches/2.0.x/STATUS
Posted by Sander Striker <st...@apache.org>.
wrowe@apache.org wrote:
> Author: wrowe
> Date: Fri Apr 8 17:38:46 2005
> New Revision: 160645
> @@ -208,7 +209,7 @@
> * Win32: Move call to mpm_service_install to the rewrite_args hook
> from the post_config hook.
> http://svn.apache.org/viewcvs?view=rev&rev=154319
> - +1: stoddard, striker
> + +1: stoddard, striker, wrowe (as corrected in subsequent patches)
Bill, could you please add the revisions of these subsequent patches?
> * mod_version: New Module, Backport from trunk.
> http://svn.apache.org/repos/asf/httpd/httpd/trunk/modules/metadata/mod_version.c
> (Also need to backport docs, and build system stuff.)
> - +1: pquerna, jerenkrantz
> + +1: pquerna, jerenkrantz, wrowe (trivial, would even be cool in 1.3)
Paul, Justin, could you either provide me with a complete patch against 2.0.x
or add the revisions I need to merge?
Thanks,
Sander
Re: svn commit: r160645 - httpd/httpd/branches/2.0.x/STATUS
Posted by 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
Re: svn commit: r160645 - httpd/httpd/branches/2.0.x/STATUS
Posted by 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
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
At 03:19 PM 4/28/2005, Greg Ames wrote:
>wrowe@apache.org 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.
Bill
Re: svn commit: r160645 - httpd/httpd/branches/2.0.x/STATUS
Posted by Greg Ames <gr...@remulak.net>.
wrowe@apache.org 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.
thanks,
Greg