[STATUS] (httpd-trunk) Wed Jan 9 23:50:40 2008

2008-01-09 Thread Rodent of Unusual Size 
APACHE 2.3 STATUS:  -*-text-*-
Last modified at [$Date: 2007-12-03 15:06:37 -0500 (Mon, 03 Dec 2007) $]

The current version of this file can be found at:

  * http://svn.apache.org/repos/asf/httpd/httpd/trunk/STATUS

Documentation status is maintained seperately and can be found at:

  * docs/STATUS in this source tree, or
  * http://svn.apache.org/repos/asf/httpd/httpd/trunk/docs/STATUS

Consult the following STATUS files for information on related projects:

  * http://svn.apache.org/repos/asf/apr/apr/trunk/STATUS
  * http://svn.apache.org/repos/asf/apr/apr-util/trunk/STATUS

Patches considered for backport are noted in their branches' STATUS:

  * http://svn.apache.org/repos/asf/httpd/httpd/branches/1.3.x/STATUS
  * http://svn.apache.org/repos/asf/httpd/httpd/branches/2.0.x/STATUS
  * http://svn.apache.org/repos/asf/httpd/httpd/branches/2.2.x/STATUS


Release history:
[NOTE that x.{odd}.z versions are strictly Alpha/Beta releases,
  while x.{even}.z versions are Stable/GA releases.]

2.3.0   : in development


Contributors looking for a mission:

  * Just do an egrep on "TODO" or "XXX" in the source.

  * Review the bug database at: http://issues.apache.org/bugzilla/

  * Review the "PatchAvailable" bugs in the bug database:


https://issues.apache.org/bugzilla/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&product=Apache+httpd-2&keywords=PatchAvailable

After testing, you can append a comment saying "Reviewed and tested".

  * Open bugs in the bug database.


CURRENT RELEASE NOTES:


RELEASE SHOWSTOPPERS:

  * Handling of non-trailing / config by non-default handler is broken
http://marc.theaimsgroup.com/?l=apache-httpd-dev&m=105451701628081&w=2
jerenkrantz asks: Why should this block a release?
wsanchez agrees: this may be a change in behavior, but isn't
  clearly wrong, and even if so, it doesn't seem like a
  showstopper.

  * the edge connection filter cannot be removed 
http://marc.theaimsgroup.com/?l=apache-httpd-dev&m=105366252619530&w=2

jerenkrantz asks: Why should this block a release?

stas replies: because it requires a rewrite of the filters stack
  implementation (you have suggested that) and once 2.2 is
  released you can't do that anymore. 


CURRENT VOTES:

  * If the parent process dies, should the remaining child processes
"gracefully" self-terminate. Or maybe we should make it a runtime
option, or have a concept of 2 parent processes (one being a 
"hot spare").
See: Message-ID: <[EMAIL PROTECTED]>

Self-destruct: Ken, Martin, Lars
Not self-destruct: BrianP, Ian, Cliff, BillS
Make it runtime configurable: Aaron, jim, Justin, wrowe, rederpj, nd

/* The below was a concept on *how* to handle the problem */
Have 2 parents: +1: jim
-1: Justin, wrowe, rederpj, nd
+0: Lars, Martin (while standing by, could it do
  something useful?)

  * Make the worker MPM the default MPM for threaded Unix boxes.
+1:   Justin, Ian, Cliff, BillS, striker, wrowe, nd
+0:   BrianP, Aaron (mutex contention is looking better with the
  latest code, let's continue tuning and testing), rederpj, jim
-0:   Lars

pquerna: Do we want to change this for *2.4*?
wrowe: Replies "yes"

RELEASE NON-SHOWSTOPPERS BUT WOULD BE REAL NICE TO WRAP THESE UP:

  * Patches submitted to the bug database:

http://issues.apache.org/bugzilla/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&product=Apache+httpd-2&keywords=PatchAvailable

  * Filter stacks and subrequests, redirects and fast redirects.
There's at least one PR that suffers from the current unclean behaviour
(which lets the server send garbage): PR 17629
nd says: Every subrequest should get its own filter stack with the
 subreq_core filter as bottom-most. That filter does two things:
   - swallow EOS buckets
   - redirect the data stream to the upper request's (rr->main)
 filter chain directly after the subrequest's starting
 point.
 Once we have a clean solution, we can try to optimize
 it, so that the server won't be slow down too much.

  * RFC 2616 violations.
Closed PRs: 15857.
Open PRs: 15852, 15859, 15861, 15864, 15865, 15866, 15868, 15869,
  15870, 16120, 16125, 16126, 16133, 16135, 16136, 16137,
  16138, 16139, 16140, 16142, 16518, 16520, 16521, 
jerenkrantz says: need to decide how many we need to backport and/or
  if these rise to showstopper status.
wrowe suggests: it would be nice to see "MUST" v.s. "SHOULD" v.s. "MAY"
out of this list, without reviewing them individually.

  * There is a bug in how we sort some hooks, at least the pre-config
hook.  The first time we call the hooks,

[STATUS] (httpd-2.2) Wed Jan 9 23:47:26 2008

2008-01-09 Thread Rodent of Unusual Size 
APACHE 2.2 STATUS:  -*-text-*-
Last modified at [$Date: 2008-01-09 13:48:58 -0500 (Wed, 09 Jan 2008) $]

The current version of this file can be found at:

  * http://svn.apache.org/repos/asf/httpd/httpd/branches/2.2.x/STATUS

Documentation status is maintained seperately and can be found at:

  * docs/STATUS in this source tree, or
  * http://svn.apache.org/repos/asf/httpd/httpd/trunk/docs/STATUS

Consult the following STATUS files for information on related projects:

  * http://svn.apache.org/repos/asf/apr/apr/trunk/STATUS
  * http://svn.apache.org/repos/asf/apr/apr-util/trunk/STATUS

Patches considered for backport are noted in their branches' STATUS:

  * http://svn.apache.org/repos/asf/httpd/httpd/branches/1.3.x/STATUS
  * http://svn.apache.org/repos/asf/httpd/httpd/branches/2.0.x/STATUS
  * http://svn.apache.org/repos/asf/httpd/httpd/branches/2.2.x/STATUS


Release history:
[NOTE that x.{odd}.z versions are strictly Alpha/Beta releases,
  while x.{even}.z versions are Stable/GA releases.]

2.2.8   : In development
2.2.7   : Tagged January 4, 2008. Not released.
2.2.6   : Released September 7, 2007.
2.2.5   : Tagged August 10, 2007, not released.
2.2.4   : Released on January 9, 2007 as GA.
2.2.3   : Released on July 28, 2006 as GA.
2.2.2   : Released on May 1, 2006 as GA.
2.2.1   : Tagged on April 1, 2006, not released.
2.2.0   : Released on December 1, 2005 as GA.
2.1.10  : Tagged on November 19, 2005, not released.
2.1.9   : Released on November 5, 2005 as beta.
2.1.8   : Released on October 1, 2005 as beta.
2.1.7   : Released on September 12, 2005 as beta.
2.1.6   : Released on June 27, 2005 as alpha.
2.1.5   : Tagged on June 17, 2005.
2.1.4   : not released.
2.1.3   : Released on  February 22, 2005 as alpha.
2.1.2   : Released on December 8, 2004 as alpha.
2.1.1   : Released on November 19, 2004 as alpha.
2.1.0   : not released.


Contributors looking for a mission:

  * Just do an egrep on "TODO" or "XXX" in the source.

  * Review the bug database at: http://issues.apache.org/bugzilla/

  * Review the "PatchAvailable" bugs in the bug database:


https://issues.apache.org/bugzilla/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&product=Apache+httpd-2&keywords=PatchAvailable

After testing, you can append a comment saying "Reviewed and tested".

  * Open bugs in the bug database.


CURRENT RELEASE NOTES:

  * Forward binary compatibility is expected of Apache 2.2.x releases, such
that no MMN major number changes will occur.  Such changes can only be
made in the trunk.

  * All commits to branches/2.2.x must be reflected in SVN trunk,
as well, if they apply.  Logical progression is commit to trunk,
get feedback and votes on list or in STATUS, then merge into
branches/2.2.x, as applicable.


RELEASE SHOWSTOPPERS:

PATCHES ACCEPTED TO BACKPORT FROM TRUNK:
  [ start all new proposals below, under PATCHES PROPOSED. ]


PATCHES PROPOSED TO BACKPORT FROM TRUNK:
  [ New proposals should be added at the end of the list ]

   * mod_proxy: Support variable interpolation in reverse proxy configuration
 (revised proposal dealing with wrowe's concerns).
 trunk:
   http://svn.apache.org/viewvc?view=rev&revision=421686  (code)
   http://svn.apache.org/viewvc?view=rev&revision=422178  (code)
   
http://svn.apache.org/viewvc/httpd/httpd/trunk/docs/manual/mod/mod_proxy.xml?r1=420990&r2=421725
 (docs)
   http://svn.apache.org/viewvc?view=rev&revision=589371  (code+docs)
 2.2.x:
   http://people.apache.org/~niq/proxy-interp.patch
 rpluem says: Please add the documentation to your 2.2.x version of your
  patch and a minor bump (changes to public mod_proxy.h) and
  assume you are +1 to your own proposal.
 niq says: I'll attend to that.  As regards vote, I'm +1 on the proposal,
   but -0 on including this as a new feature in 2.2.7.
   Better IMHO to separate releasing it from the many bugfixes
   in 2.2.7 mod_proxy.  Hence +1 for 2.2.8.

   * configure / install: Make https port configurable.
  Trunk version of patch:
 http://svn.apache.org/viewvc?rev=606316&view=rev
 http://svn.apache.org/viewvc?rev=606806&view=rev
  Backport version for 2.2.x of patch:
 http://people.apache.org/~fuankg/diffs/sslport.diff
  +1: fuankg, wrowe
  wrowe notes; Win32 is already ready for this, and there's no rush
  to push this into the immediate next-release.

   * mod_ssl: Add server name indication (RFC 4366) support (PR 34607).
  Trunk version of patch:
 http://svn.apache.org/viewvc?view=rev&revision=606190
  Backport version for 2.2.x of patch:
 http://people.apache.org/~fuankg/diffs/httpd-2.2.x-sni.diff
  +1: fuankg
  +0: like ssl upgrade of 2.2, perhaps this is a good reas

[STATUS] (httpd-2.0) Wed Jan 9 23:46:53 2008

2008-01-09 Thread Rodent of Unusual Size 
APACHE 2.0 STATUS:  -*-text-*-
Last modified at [$Date: 2008-01-08 08:46:15 -0500 (Tue, 08 Jan 2008) $]

The current version of this file can be found at:

  * http://svn.apache.org/repos/asf/httpd/httpd/branches/2.0.x/STATUS

Documentation status is maintained seperately and can be found at:

  * docs/STATUS in this source tree, or
  * http://svn.apache.org/repos/asf/httpd/httpd/branches/2.0.x/docs/STATUS

Consult the following STATUS files for information on related projects:

  * http://svn.apache.org/repos/asf/apr/apr/branches/0.9.x/STATUS
  * http://svn.apache.org/repos/asf/apr/apr-util/branches/0.9.x/STATUS

Consult the trunk/ for all new development and documentation efforts:

  * http://svn.apache.org/repos/asf/httpd/httpd/trunk/STATUS
  * http://svn.apache.org/repos/asf/httpd/httpd/trunk/docs/STATUS


Release history:

2.0.63  : In development
2.0.62  : Tagged January 4, 2008. Not released.
2.0.61  : Released September 7, 2007.
2.0.60  : Tagged August 10, 2007, not released.
2.0.59  : released July 28, 2006 as GA.
2.0.58  : released May 1, 2006 as GA. 
2.0.57  : tagged April 19, 2006, not released.
2.0.56  : tagged April 16, 2006, not released.
2.0.55  : released October 16, 2005 as GA.
2.0.54  : released April 17, 2005 as GA.
2.0.53  : released February 7, 2005 as GA.
2.0.52  : released September 28, 2004 as GA.
2.0.51  : released September 15, 2004 as GA.
2.0.50  : released June 30, 2004 as GA.
2.0.49  : released March 19, 2004 as GA.
2.0.48  : released October 29, 2003 as GA.
2.0.47  : released July 09, 2003 as GA.
2.0.46  : released May 28, 2003 as GA.
2.0.45  : released April 1, 2003 as GA.
2.0.44  : released January 20, 2003 as GA.
2.0.43  : released October 3, 2002 as GA.
2.0.42  : released September 24, 2002 as GA.
2.0.41  : rolled September 16, 2002.  not released.
2.0.40  : released August 9, 2002 as GA.
2.0.39  : released June 17, 2002 as GA.
2.0.38  : rolled June 16, 2002.  not released.
2.0.37  : rolled June 11, 2002.  not released.
2.0.36  : released May 6, 2002 as GA.
2.0.35  : released April 5, 2002 as GA.
2.0.34  : tagged March 26, 2002.
2.0.33  : tagged March 6, 2002.  not released.
2.0.32  : released Feburary 16, 2002 as beta.
2.0.31  : rolled Feburary 1, 2002.  not released.
2.0.30  : tagged January 8, 2002.  not rolled.
2.0.29  : tagged November 27, 2001.  not rolled.
2.0.28  : released November 13, 2001 as beta.
2.0.27  : rolled November 6, 2001
2.0.26  : tagged October 16, 2001.  not rolled.
2.0.25  : rolled August 29, 2001
2.0.24  : rolled August 18, 2001
2.0.23  : rolled August 9, 2001
2.0.22  : rolled July 29, 2001
2.0.21  : rolled July 20, 2001
2.0.20  : rolled July 8, 2001
2.0.19  : rolled June 27, 2001
2.0.18  : rolled May 18, 2001
2.0.17  : rolled April 17, 2001
2.0.16  : rolled April 4, 2001
2.0.15  : rolled March 21, 2001
2.0.14  : rolled March 7, 2001
2.0a9   : released December 12, 2000
2.0a8   : released November 20, 2000
2.0a7   : released October 8, 2000
2.0a6   : released August 18, 2000
2.0a5   : released August 4, 2000
2.0a4   : released June 7, 2000
2.0a3   : released April 28, 2000
2.0a2   : released March 31, 2000
2.0a1   : released March 10, 2000


Contributors looking for a mission:

  * Just do an egrep on "TODO" or "XXX" in the source.

  * Review the bug database at: http://issues.apache.org/bugzilla/

  * Review the "PatchAvailable" bugs in the bug database:


http://issues.apache.org/bugzilla/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&product=Apache+httpd-2.0&keywords=PatchAvailable

After testing, you can append a comment saying "Reviewed and tested".

  * Open bugs in the bug database.


CURRENT RELEASE NOTES:

  * Forward binary compatibility is expected of Apache 2.0.x releases, such
that no MMN major number changes will occur.  Such changes can only be
made in the trunk.

  * All commits to branches/2.0.x must be reflected in SVN trunk,
as well, if they apply.  Logical progression is commit to trunk,
get feedback and votes on list or in STATUS, then merge into 
branches/2.2.x, and finally merge into branches/2.0.x, as applicable.


RELEASE SHOWSTOPPERS:

PATCHES ACCEPTED TO BACKPORT FROM TRUNK:
  [ start all new proposals below, under PATCHES PROPOSED. ]

PATCHES PROPOSED TO BACKPORT FROM TRUNK:
  [ please place SVN revisions from trunk here, so it is easy to
identify exactly what the proposed changes are!  Add all new
proposals to the end of this list. ]

  * Backport 327179; PR 31226; allow ap_add_output_filters_by_type to handle
proxied requests.  Basic tests by jorton and [rpluem] show that this works, 
nobody can actually remember why this limitation was introduced at all 
(r94028) and the mai

Re: [VOTE] initial release of httpd-mod_ftp-0.9.1

2008-01-09 Thread William A. Rowe, Jr. 

Niklas Edmundsson wrote:



The changes in trunk are rational but widely distributed, we now set up
a single initialization where once we had many, for an assortment of
state  variables.  Those sorts of changes are prone to fallout.  If you
are playing with trunk and svn up, be sure to make clean; make straight
away.  In any case, I don't see trunk as being releasable until folks
have bashed on it for a time, so if anyone's eager for 0.9.2 please test
trunk and chime in once you believe it's ready to tag.


Uhm. It seems that the old bug of not delivering http with mod_ftp 
loaded is back... Or am I seeing a ghost? Same symptoms as before, 
0-length replies...


Ghost is possibly working in trunk without doing the make clean; make
I mentioned?

Bill

Re: [VOTE] initial release of httpd-mod_ftp-0.9.1

2008-01-09 Thread Niklas Edmundsson 

On Tue, 8 Jan 2008, William A. Rowe, Jr. wrote:


I've heard one + and one - for removing STATUS-FTP, and I think Jorge's
point is well taken, at least for alphas and betas, so it seems it's
worth leaving STATUS-FTP in our alpha and beta packages (and I think
it's also a good point for httpd-2.3-alphas when we get to those.)


I'm for keeping STATUS-FTP in alphas and betas at least.


The changes in trunk are rational but widely distributed, we now set up
a single initialization where once we had many, for an assortment of
state  variables.  Those sorts of changes are prone to fallout.  If you
are playing with trunk and svn up, be sure to make clean; make straight
away.  In any case, I don't see trunk as being releasable until folks
have bashed on it for a time, so if anyone's eager for 0.9.2 please test
trunk and chime in once you believe it's ready to tag.


Uhm. It seems that the old bug of not delivering http with mod_ftp 
loaded is back... Or am I seeing a ghost? Same symptoms as before, 
0-length replies...



/Nikke - cramming in some quick testing before going to bed...
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
 Niklas Edmundsson, Admin @ {acc,hpc2n}.umu.se  | [EMAIL PROTECTED]
---
 Get rid of temptation - Yield to it.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

Re: Pre-release test tarballs of httpd 1.3.40, 2.0.62 and 2.2.7 available

2008-01-09 Thread William A. Rowe, Jr. 

William A. Rowe, Jr. wrote:

I'm thinking of a scenario where the console *parent only* and on win32
might hold onto the stdin handle.  I'll research and reply.


I'm becoming more certain that without stdout (we *do* launch with stdin
to the console, because it's only deprived from the child) we have
changed the behavior of console services.


Boy, I was off-base.  *READ* the "help start" docs before you go blaming
httpd ;-)


The most suspicious, there is one fewer thread (yup, I'm guessing it's a
cmd.exe monitor thread) when run from start.exe rather than on this
existing console.  It's also possible that our WaitForMultipleObjects
in the parent really needs to be MsgWaitForMultipleObjects.


BINGO.  HTTPD is unwilling to manage the console except when it's doing
its very goofy Win9x-service dance.  You have two choices;

start.exe cmd /c httpd.exe

start.exe /b httpd.exe

The first command gives you a controllable httpd that can be stopped
with ^C / ^BREAK.  The second command starts httpd in the current
console, gives you back the console (although the display of messages
make this confusing) and just like a unix daemon, you _must_ kill it
by-pid (and like unix, httpd doesn't do this.)  Although closing the
console window *does* kill it, ^C / ^BREAK will not.

The behavior of start.exe httpd.exe has definitely not been a design
consideration, and sure isn't worth holding up Apache 2.2.8.  To
whatever degree it "accidentally" worked before, its senseless.

Long and short of things; perhaps we should also evaluate closing stdin
as the unix daemon does, and figure out the mechanics to httpd -k stop
either a service or by logs/httpd.pid, but this is certainly good enough
for release 2.2.8 and 2.0.63.

Bill

Re: Issues with mod_proxy_http, keep-alive, and SSL

2008-01-09 Thread Ruediger Pluem 
Answer to your first question can be found at
http://issues.apache.org/bugzilla/show_bug.cgi?id=43238#c3

Regards

Rüdiger


On 01/09/2008 10:34 PM, Adam Woodworth wrote:
> 1st question still up for grabs, but I found the answer to my 2nd
> question for those interested:
> 
> Bug 43472 (http://issues.apache.org/bugzilla/show_bug.cgi?id=43472)
> reported this problem and the fix for it is in 2.2.7.  I just tried
> the 2.2.7 tag from svn and it solved the issue for me.
> 
> 
> On Jan 8, 2008 7:10 PM, Adam Woodworth <[EMAIL PROTECTED]> wrote:
>> Hi,
>>
>> I have a couple issues with mod_proxy:
>>
>> 1) HTTP Keep-Alive on an SSL Connection:
>>
>> In the source for Apache 2.2.6, around line 1704 of
>> modules/proxy/mod_proxy_http.c there is this code that causes HTTPS
>> connections to not use Keep-Alive's:
>>
>> backend->is_ssl = is_ssl;
>> /*
>>  * TODO: Currently we cannot handle persistent SSL backend connections,
>>  * because we recreate backend->connection for each request and thus
>>  * try to initialize an already existing SSL connection. This does
>>  * not work.
>>  */
>> if (is_ssl)
>> backend->close_on_recycle = 1;
>>
>> Looking in the same function in the latest Apache 2.0.x source, in
>> file modules/proxy/proxy_http.c around line 1081, the check for
>> setting close_on_recycle doesn't exist (there is no close_on_recycle
>> in the source).
>>
>> I'm not intimately familiar with the differences between mod_proxy in
>> 2.0.x and 2.2.x, but does this mean that the bug described (and
>> prevented) above in the 2.2.6 code (Keep-Alive persistent connections
>> with SSL in mod_proxy won't work with the current 2.2.6 design, and
>> are thus prevented) is still an issue (was never fixed) in 2.0.x?
>>
>>
>> 2) Using Apache 2.2.6, mod_proxy opens a new connection for each
>> request being proxied:
>>
>> This is the same exact problem that is described in this bug from 2006
>> (except our backend isn't JBoss, it's just another Apache web server):
>> http://issues.apache.org/bugzilla/show_bug.cgi?id=38602
>>
>> To summarize, if a client (A) requests a keep-alive connection to our
>> Apache proxy (B) (running httpd 2.2.6), mod_proxy still opens a new
>> connection to the back-end (C) for each request coming from the
>> client, even though the client has keep-alive connections open.
>>
>> Simple scenario:
>> I connect from A to B over a single connection (one socket) and use
>> HTTP/1.1 keep-alive requests to GET 4 URLs.  For each request that A
>> sends B over that single connection, B creates a new request to C.  I
>> would expect only one connection to be opened from B to C, to mirror
>> what A is requesting of B.
>>
>> This problem, described in bug 38602, was solved for that individual
>> with the patch made at that time that is in the code for 2.2.6.  So
>> it's strange that I'm seeing the same issue now.
>>
>> Anyone have any insight here?
>>
>> Thanks!
>> Adam
>>
> 
>

Re: Pre-release test tarballs of httpd 1.3.40, 2.0.62 and 2.2.7 available

2008-01-09 Thread William A. Rowe, Jr. 

William A. Rowe, Jr. wrote:


START httpd goes into it's goofy mode because it has no interactive
behavior, but has no cmd to exit to, and cmd sees it's process is still
running.  start -k httpd should not exhibit this behavior.  If there was
a start -hide -k httpd, it wouldn't be offensive.


FYI - contrary to Stephan's claims, messages are displayed on the
console.  As Tom correctly diagnosed, the cmd.exe window's refresh/paint
loop is dead.


I'm thinking of a scenario where the console *parent only* and on win32
might hold onto the stdin handle.  I'll research and reply.


I'm becoming more certain that without stdout (we *do* launch with stdin
to the console, because it's only deprived from the child) we have
changed the behavior of console services.

The most suspicious, there is one fewer thread (yup, I'm guessing it's a
cmd.exe monitor thread) when run from start.exe rather than on this
existing console.  It's also possible that our WaitForMultipleObjects
in the parent really needs to be MsgWaitForMultipleObjects.

Stdin is never closed for the parent; about to experiment with that
(it's also closed by prefork and worker MPM's at the point we enter
the daemonize() phase).

Bill

Re: Pre-release test tarballs of httpd 1.3.40, 2.0.62 and 2.2.7 available

2008-01-09 Thread Jim Jagielski 

Just a FYI: Since I have some plans for this evening, the
T&R of the Holy Trinity :) will occur tomorrow am.

Re: Issues with mod_proxy_http, keep-alive, and SSL

2008-01-09 Thread Adam Woodworth 
1st question still up for grabs, but I found the answer to my 2nd
question for those interested:

Bug 43472 (http://issues.apache.org/bugzilla/show_bug.cgi?id=43472)
reported this problem and the fix for it is in 2.2.7.  I just tried
the 2.2.7 tag from svn and it solved the issue for me.


On Jan 8, 2008 7:10 PM, Adam Woodworth <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I have a couple issues with mod_proxy:
>
> 1) HTTP Keep-Alive on an SSL Connection:
>
> In the source for Apache 2.2.6, around line 1704 of
> modules/proxy/mod_proxy_http.c there is this code that causes HTTPS
> connections to not use Keep-Alive's:
>
> backend->is_ssl = is_ssl;
> /*
>  * TODO: Currently we cannot handle persistent SSL backend connections,
>  * because we recreate backend->connection for each request and thus
>  * try to initialize an already existing SSL connection. This does
>  * not work.
>  */
> if (is_ssl)
> backend->close_on_recycle = 1;
>
> Looking in the same function in the latest Apache 2.0.x source, in
> file modules/proxy/proxy_http.c around line 1081, the check for
> setting close_on_recycle doesn't exist (there is no close_on_recycle
> in the source).
>
> I'm not intimately familiar with the differences between mod_proxy in
> 2.0.x and 2.2.x, but does this mean that the bug described (and
> prevented) above in the 2.2.6 code (Keep-Alive persistent connections
> with SSL in mod_proxy won't work with the current 2.2.6 design, and
> are thus prevented) is still an issue (was never fixed) in 2.0.x?
>
>
> 2) Using Apache 2.2.6, mod_proxy opens a new connection for each
> request being proxied:
>
> This is the same exact problem that is described in this bug from 2006
> (except our backend isn't JBoss, it's just another Apache web server):
> http://issues.apache.org/bugzilla/show_bug.cgi?id=38602
>
> To summarize, if a client (A) requests a keep-alive connection to our
> Apache proxy (B) (running httpd 2.2.6), mod_proxy still opens a new
> connection to the back-end (C) for each request coming from the
> client, even though the client has keep-alive connections open.
>
> Simple scenario:
> I connect from A to B over a single connection (one socket) and use
> HTTP/1.1 keep-alive requests to GET 4 URLs.  For each request that A
> sends B over that single connection, B creates a new request to C.  I
> would expect only one connection to be opened from B to C, to mirror
> what A is requesting of B.
>
> This problem, described in bug 38602, was solved for that individual
> with the patch made at that time that is in the code for 2.2.6.  So
> it's strange that I'm seeing the same issue now.
>
> Anyone have any insight here?
>
> Thanks!
> Adam
>

Windows Server 2008 Application Compatability Lab Invitation

2008-01-09 Thread Garrett Serack 
Howdy,

(William Rowe from the ASF suggested I post this to your dev@ list)

My name is Garrett Serack, and I am the Community Program Manager in the Open
Source Software Labs here at Microsoft.

I would like to extend an official invitation to the Apache Software Foundation
to participate in the Microsoft Windows Server 2008 Compatibility Labs here
in Redmond. The Compatibility lab is scheduled for

   Monday February 25 2008 through Wednesday February 28 2008.

(the lab is actually booked thru Thurs the 29th, so an extra day is possible)

WHAT IS IT?
---
The Windows Server 2008 Application Compatibility Lab is an event where we
invite companies to bring their applications into our lab, and have the
opportunity to perform compatibility testing with Windows Server 2008. In
addition to gaining insight into Windows Server 2008, this also includes
unprecedented access to various product groups (developers, architects and PMs)
inside of Microsoft, who can lend their assistance, give technical information
and answer design questions you may have.

Normally, we request companies send 3-4 attendees, and we usually have 3-4
companies in the lab in a given week. Given the ASF's size and breadth, we've
reserved the entire lab for the week for the Apache Foundation, and we'd like
to see somewhere in the range of 15-18 people from a wide variety of projects
attend.


WHO SHOULD COME?

We would be very interested in having several people from the Tomcat, HTTPD and
Axis groups attend.  Other projects including APR, Apache C++ Standard Library
project, Harmony, and Maven.NET also come to mind.  Any project that is impacted
by the release of Windows 2008, or is looking to solve Windows-specific project
issues, may profit from this opportunity.

We are interested in having each project who deals with Microsoft Windows
compatibility or portability to bring small contingent of 1 or 2 developers to
the table, so please chat within your own PMC or even your dev@ list first to
determine who is most interested in attending this camp on behalf of your
project.  Space is constrained, and we'd like to ensure that specific attention
can be given to projects that need it.


WHAT'S THE COST?

The cost of the event itself is being handled by our team (the Open Source
Software Lab), all you have to do is actually get here.  Some travel assistance
by Microsoft will be available (hotel/airfare), *if* your employer can't
pick up such costs.  As my budget is limited, how much travel assistance we can
provide is linked to how many need to avail themselves of it.  If you don't
need a subsidy, hotels can still be booked at MS's corp rate at most nearby,
saving some money.


WHAT IS THE PROCESS?

To track interest, please register for this event in the subversion file

  
https://svn.apache.org/repos/private/committers/hackathons/port25-08/attending.txt

and send me an email with the following information:

   Full Name:
   Street Address:
   Phone Number:
   Email Address:
   ASF Projects Involved in:
   Travel Assistance Required: (full/part/none)
   Product Groups you wish to get access to:
   Any technical aspects you'd like to address:

INSIGHT
---
You might be interested in the "political" rational of why we value this chance
to meet some of the ASF developers and help them work through Windows
compatibility issues. You can see Sam Ramji's blog entry about why we asked
Mozilla out:

  http://port25.technet.com/archive/2006/09/20/Why-I-invited-Mozilla.aspx

Garrett Serack | Open Source Community Lead | Microsoft Corporation
Office:(425)706-7939
email/messenger: [EMAIL PROTECTED]
blog: http://fearthecowboy.com

Re: mod_dav patch to force scheme/port on https->http proxying

2008-01-09 Thread David Sklar 
On Jan 9, 2008 2:00 AM, Sander Temme <[EMAIL PROTECTED]> wrote:
>
> On Jan 8, 2008, at 3:10 PM, David Sklar wrote:
>
> > Any comments on the patch would be appreciated -- it's wonderful, it's
> > a good solution but could be improved, it's a ridiculous way to solve
> > this problem, etc.
>
> Doesn't setting the global directive:
>
> ServerName https://foo.bar:443
>
> already do what you need?

Indeed it does! Thanks for the tip.

David

Re: Pre-release test tarballs of httpd 1.3.40, 2.0.62 and 2.2.7 available

2008-01-09 Thread Plüm , Rüdiger , VF-Group 


> -Ursprüngliche Nachricht-
> Von: Jim Jagielski [mailto:[EMAIL PROTECTED] 
> Gesendet: Mittwoch, 9. Januar 2008 16:17
> An: dev@httpd.apache.org
> Betreff: Re: Pre-release test tarballs of httpd 1.3.40, 
> 2.0.62 and 2.2.7 available
> 
> 
> 
> On Jan 9, 2008, at 9:59 AM, Jim Jagielski wrote:
> 
> >
> > On Jan 9, 2008, at 9:42 AM, Nick Kew wrote:
> >> Not so sure here - we're not really returning an error status in
> >> any case, and sending errors to the backend falls outside the scope
> >> of HTTP.
> >>
> >> I've just voted +1 on keeping that as-is, in the hope of getting
> >> backported in time for Jim's 2.2.8 schedule.
> >
> > Reviewing and testing http://people.apache.org/~niq/ 
> > chunk_optimization.diff
> > as we speak... I'd also like this in 2.2.8...
> >
> 
> In the case where we have nothing but zero-length data buckets
> in the brigade, we leveraging that when we leave the
> loop, we'll be at a sentinel. Even so, any issues with
> the small "can't happen" check below?
> 
>  /* We had no data in this brigade */
>  if (!len || e == APR_BRIGADE_SENTINEL(b)) {
>  return APR_EAGAIN;
>  }
> 
>

No. Safety first.

Regards

Rüdiger

Re: Pre-release test tarballs of httpd 1.3.40, 2.0.62 and 2.2.7 available

2008-01-09 Thread Jim Jagielski 


On Jan 9, 2008, at 9:59 AM, Jim Jagielski wrote:



On Jan 9, 2008, at 9:42 AM, Nick Kew wrote:

Not so sure here - we're not really returning an error status in
any case, and sending errors to the backend falls outside the scope
of HTTP.

I've just voted +1 on keeping that as-is, in the hope of getting
backported in time for Jim's 2.2.8 schedule.


Reviewing and testing http://people.apache.org/~niq/ 
chunk_optimization.diff

as we speak... I'd also like this in 2.2.8...



In the case where we have nothing but zero-length data buckets
in the brigade, we leveraging that when we leave the
loop, we'll be at a sentinel. Even so, any issues with
the small "can't happen" check below?

/* We had no data in this brigade */
if (!len || e == APR_BRIGADE_SENTINEL(b)) {
return APR_EAGAIN;
}

Re: Pre-release test tarballs of httpd 1.3.40, 2.0.62 and 2.2.7 available

2008-01-09 Thread Jim Jagielski 


On Jan 9, 2008, at 9:42 AM, Nick Kew wrote:

Not so sure here - we're not really returning an error status in
any case, and sending errors to the backend falls outside the scope
of HTTP.

I've just voted +1 on keeping that as-is, in the hope of getting
backported in time for Jim's 2.2.8 schedule.


Reviewing and testing http://people.apache.org/~niq/ 
chunk_optimization.diff

as we speak... I'd also like this in 2.2.8...

Re: Pre-release test tarballs of httpd 1.3.40, 2.0.62 and 2.2.7 available

2008-01-09 Thread Nick Kew 
On Wed, 9 Jan 2008 11:15:57 +0100
Plüm, Rüdiger, VF-Group <[EMAIL PROTECTED]> wrote:

> > At lines 364 and 460 (trunk), you set HTTP_SERVICE_UNAVAILABLE
> > when broken chunking is encountered.  I don't think that's right:
> 
> That's because this was the error code that was used there before for
> empty chunk size lines, but I agree that this error code might be
> wrong.
> 
> > 
> > - bad chunking in a request should return HTTP_BAD_REQUEST
> > - bad chunking in a proxy response should return HTTP_BAD_GATEWAY
> > 
> > Can we know if we're processing request or response at this point?
> 
> IMHO unfortunately not, but it does not matter in the proxy case
> anyway, because the error messages sent via bail_out_on_error are
> sent to the backend server in this case and not the client :-). This
> is because we have switched the meaning of INPUT and OUTPUT filters
> for our proxy connection to the backend. The client will receive
> internal server error just as with your test with the insane sized
> chunk extension. This is no regression it has worked forever like
> this. So in the light of this it might make sense to change this
> simply from HTTP_SERVICE_UNAVAILABLE to HTTP_BAD_REQUEST. WDYT?

Not so sure here - we're not really returning an error status in
any case, and sending errors to the backend falls outside the scope
of HTTP.

I've just voted +1 on keeping that as-is, in the hope of getting
backported in time for Jim's 2.2.8 schedule.

> > Also, I committed a simple edge-case fix against empty data
> > buckets getting in the way of detecting a lineend.
> > I presume you're OK with r610240?
> 
> Thanks. Your patch is much better than my stupid one.

Or in other words a trivial improvement on yours.  But I added it
to the backport proposal in STATUS.


-- 
Nick Kew

Application Development with Apache - the Apache Modules Book
http://www.apachetutor.org/

Re: svn commit: r609953 - /httpd/httpd/branches/2.2.x/CHANGES

2008-01-09 Thread Nick Kew 
On Wed, 9 Jan 2008 09:25:54 -0500
Jim Jagielski <[EMAIL PROTECTED]> wrote:

> In any case, one sees that we've done it both ways.
> Consider 2.2.5 and 2.2.1. Same with the 2.0.x
> ones as well...
> 
> Looking back, I prefer keeping the "old" way, where
> once we've tagged, we have a corresponding entry
> in CHANGES... My intent is to keep the 2.2.7,
> 2.0.62 and 1.3.40 lines in CHANGES.

Agreed.  I'd have preferred not wiping 2.2.5 from the record,
but not strongly enough to make a fuss.

-- 
Nick Kew

Application Development with Apache - the Apache Modules Book
http://www.apachetutor.org/

Re: svn commit: r609953 - /httpd/httpd/branches/2.2.x/CHANGES

2008-01-09 Thread Jim Jagielski 


On Jan 9, 2008, at 9:21 AM, Jim Jagielski wrote:



On Jan 9, 2008, at 9:00 AM, Nick Kew wrote:


On Wed, 9 Jan 2008 08:56:58 -0500
Jim Jagielski <[EMAIL PROTECTED]> wrote:


BTW: Shouldn't we drop 2.2.7 entirely from the CHANGES file and
put all
changes since 2.2.6 under 2.2.8?



No, since there *was* a 2.2.7... it just wasn't released.


Just as there *was* a 2.2.5.



Ohhh... I see what he's asking my mistake...



In any case, one sees that we've done it both ways.
Consider 2.2.5 and 2.2.1. Same with the 2.0.x
ones as well...

Looking back, I prefer keeping the "old" way, where
once we've tagged, we have a corresponding entry
in CHANGES... My intent is to keep the 2.2.7,
2.0.62 and 1.3.40 lines in CHANGES.

Re: svn commit: r609953 - /httpd/httpd/branches/2.2.x/CHANGES

2008-01-09 Thread Jim Jagielski 


On Jan 9, 2008, at 9:00 AM, Nick Kew wrote:


On Wed, 9 Jan 2008 08:56:58 -0500
Jim Jagielski <[EMAIL PROTECTED]> wrote:


BTW: Shouldn't we drop 2.2.7 entirely from the CHANGES file and
put all
changes since 2.2.6 under 2.2.8?



No, since there *was* a 2.2.7... it just wasn't released.


Just as there *was* a 2.2.5.



Ohhh... I see what he's asking my mistake...

Re: svn commit: r609953 - /httpd/httpd/branches/2.2.x/CHANGES

2008-01-09 Thread Nick Kew 
On Wed, 9 Jan 2008 08:56:58 -0500
Jim Jagielski <[EMAIL PROTECTED]> wrote:

> > BTW: Shouldn't we drop 2.2.7 entirely from the CHANGES file and
> > put all
> > changes since 2.2.6 under 2.2.8?
> >
> 
> No, since there *was* a 2.2.7... it just wasn't released.

Just as there *was* a 2.2.5.

-- 
Nick Kew

Application Development with Apache - the Apache Modules Book
http://www.apachetutor.org/

Re: svn commit: r609953 - /httpd/httpd/branches/2.2.x/CHANGES

2008-01-09 Thread Jim Jagielski 


On Jan 8, 2008, at 3:19 PM, Ruediger Pluem wrote:




On 01/08/2008 05:47 PM, Ruediger Pluem wrote:


On 01/08/2008 05:12 PM, William A. Rowe, Jr. wrote:

[EMAIL PROTECTED] wrote:

+  *) SECURITY: CVE-2008-0005 (cve.mitre.org)
I thought we concur that (short of direct html injection in the  
page's

) the browser misdetection of UTF-7, contrary on it's face to
RFC2616, was a client specific problem?  If so, this is a  
"related to

CVE-2008-0005" footnote, not the topic.


So did I misunderstood Mark in its mail on [EMAIL PROTECTED]
I am now confused, because the browser issue is one and the same for
all cases. Why having a special CVE number for the mod_proxy_ftp case
then?
Anyway I can change this to a footnote if you like.



BTW: Shouldn't we drop 2.2.7 entirely from the CHANGES file and put  
all

changes since 2.2.6 under 2.2.8?



No, since there *was* a 2.2.7... it just wasn't released.

Re: svn commit: r606190 - in /httpd/httpd/trunk: CHANGES modules/ssl/ssl_engine_init.c modules/ssl/ssl_engine_kernel.c modules/ssl/ssl_toolkit_compat.h

2008-01-09 Thread Kaspar Brand 

Kaspar Brand wrote:

Has a configuration
with an SSLVerifyClient specified in the named vhost been tested?


Yes, and one specific configuration actually made me tweak the code in
the servername callback further:  [...]


It turns out that this change was too radical, actually - it prevented 
per-directory specific SSLVerifyClient settings [1] from working 
correctly. I have updated the patch to fix this, as shown by the 
attached interdiff (against the version attached to 
http://mail-archives.apache.org/mod_mbox/httpd-dev/200801.mbox/[EMAIL PROTECTED]).


The complete patch against trunk is attached to PR 34607 
(http://issues.apache.org/bugzilla/show_bug.cgi?id=34607):


   http://issues.apache.org/bugzilla/attachment.cgi?id=21365

And a proposed backport for 2.2.x is available at:

   http://sni.velox.ch/httpd-2.2.x-sni.diff

These versions should fix the remaining issues I'm aware of, so it would 
be great if there's a chance to consider this for inclusion in 2.2.8. 
Please let me know if there's anything else I can do to help with this 
process.


Thanks,
Kaspar


[1] I've also verified that other per-directory mod_ssl settings, such 
as SSLCipherSuite, will work as expected, e.g. with a configuration like 
the following:


NameVirtualHost *:443


  ServerName www1.example.net
  SSLCertificateFile www1.crt
  SSLCertificateKeyFile www1.key
  SSLCipherSuite ALL



  ServerName www2.example.net
  SSLCertificateFile www2.crt
  SSLCertificateKeyFile www2.key
  SSLCACertificateFile my_ca.crt
  SSLVerifyClient optional_no_ca
  SSLCipherSuite MEDIUM:HIGH
  
SSLVerifyClient require
SSLCipherSuite HIGH
  


In this case, more restrictive requirements are enforced for 
www2.example.net (at least 128-bit ciphers, client auth optional), and 
even more restrictive settings for www2.example.net/topsecret (stronger 
ciphers, and mandatory client auth).
diff -u ssl_engine_init.c ssl_engine_init.c
--- ssl_engine_init.c   (working copy)
+++ ssl_engine_init.c   (working copy)
@@ -1095,7 +1095,7 @@
 #ifdef OPENSSL_NO_TLSEXT
  "Init: SSL server IP/port conflict: "
 #else
- "Init: SSL server IP/port congruence: "
+ "Init: SSL server IP/port overlap: "
 #endif
  "%s (%s:%d) vs. %s (%s:%d)",
  ssl_util_vhostid(p, s),
diff -u ssl_engine_kernel.c ssl_engine_kernel.c
--- ssl_engine_kernel.c (working copy)
+++ ssl_engine_kernel.c (working copy)
@@ -2009,8 +2009,18 @@
  * from the ctx by hand
  */
 SSL_set_options(ssl, SSL_CTX_get_options(ssl->ctx));
-SSL_set_verify(ssl, SSL_CTX_get_verify_mode(ssl->ctx),
-   SSL_CTX_get_verify_callback(ssl->ctx));
+if ((SSL_get_verify_mode(ssl) == SSL_VERIFY_NONE) ||
+(SSL_num_renegotiations(ssl) == 0)) {
+   /*
+* Only initialize the verification settings from the ctx
+* if they are not yet set, or if we're called when a new
+* SSL connection is set up (num_renegotiations == 0).
+* Otherwise, we would possibly reset a per-directory
+* configuration which was put into effect by ssl_hook_Access.
+*/
+SSL_set_verify(ssl, SSL_CTX_get_verify_mode(ssl->ctx),
+   SSL_CTX_get_verify_callback(ssl->ctx));
+}
 
 return 1;
 }

Re: mod_dav patch to force scheme/port on https->http proxying

2008-01-09 Thread Plüm , Rüdiger , VF-Group 


> -Ursprüngliche Nachricht-
> Von: Sander Temme
> Gesendet: Mittwoch, 9. Januar 2008 08:01
> An: dev@httpd.apache.org
> Betreff: Re: mod_dav patch to force scheme/port on 
> https->http proxying
> 
> 
> 
> On Jan 8, 2008, at 3:10 PM, David Sklar wrote:
> 
> > Any comments on the patch would be appreciated -- it's 
> wonderful, it's
> > a good solution but could be improved, it's a ridiculous 
> way to solve
> > this problem, etc.
> 
> Doesn't setting the global directive:
> 
> ServerName https://foo.bar:443
> 
> already do what you need?
> 
> I'd rather see a solution in terms of that directive (where mod_dav  
> picks up the setting in core which is there specifically for the  
> scenario you describe and is available through the 
> ap_hook_http_scheme  
> hook), or an extension to the ProxyPassReverse case which rewrites  
> this particular repsonse part in addition to any Location: header it  
> encounters.

I agree that a general solution is preferred. Changing headers like the
Location header of incoming requests is already possible via mod_headers,
but what makes things really nasty with WebDAV is the fact that you also
need to modify the body of the request. For responses you could use
mod_substitute to do this, but mod_substitute is only an output filter
not an input filter.

Regards

Rüdiger

Re: Pre-release test tarballs of httpd 1.3.40, 2.0.62 and 2.2.7 available

2008-01-09 Thread Plüm , Rüdiger , VF-Group 


> -Ursprüngliche Nachricht-
> Von: Nick Kew 
> Gesendet: Mittwoch, 9. Januar 2008 01:27
> An: dev@httpd.apache.org
> Betreff: Re: Pre-release test tarballs of httpd 1.3.40, 
> 2.0.62 and 2.2.7 available
> 
> 
> On Mon, 07 Jan 2008 11:29:43 +0100
> Ruediger Pluem <[EMAIL PROTECTED]> wrote:
> 
> > I will also propose the optimizations. If someone has cycles to
> > review then fine, if not then in 2.2.9 :-).
> 
> At lines 364 and 460 (trunk), you set HTTP_SERVICE_UNAVAILABLE
> when broken chunking is encountered.  I don't think that's right:

That's because this was the error code that was used there before for
empty chunk size lines, but I agree that this error code might be wrong.

> 
> - bad chunking in a request should return HTTP_BAD_REQUEST
> - bad chunking in a proxy response should return HTTP_BAD_GATEWAY
> 
> Can we know if we're processing request or response at this point?

IMHO unfortunately not, but it does not matter in the proxy case anyway,
because the error messages sent via bail_out_on_error are sent to the backend
server in this case and not the client :-). This is because we have switched
the meaning of INPUT and OUTPUT filters for our proxy connection to the backend.
The client will receive internal server error just as with your test with the
insane sized chunk extension. This is no regression it has worked forever like 
this.
So in the light of this it might make sense to change this simply from
HTTP_SERVICE_UNAVAILABLE to HTTP_BAD_REQUEST. WDYT?

> 
> Also, I committed a simple edge-case fix against empty data
> buckets getting in the way of detecting a lineend.
> I presume you're OK with r610240?

Thanks. Your patch is much better than my stupid one.

Regards

Rüdiger