Bug report for Apache httpd-1.3 [2008/04/13]

2008-04-14 Thread bugzilla 
+---+
| Bugzilla Bug ID   |
| +-+
| | Status: UNC=Unconfirmed NEW=New ASS=Assigned|
| | OPN=ReopenedVER=Verified(Skipped Closed/Resolved)   |
| |   +-+
| |   | Severity: BLK=Blocker CRI=Critical  REG=Regression  MAJ=Major   |
| |   |   MIN=Minor   NOR=NormalENH=Enhancement TRV=Trivial |
| |   |   +-+
| |   |   | Date Posted |
| |   |   |  +--+
| |   |   |  | Description  |
| |   |   |  |  |
|10038|New|Min|2002-06-20|ab benchmaker hangs on 10K https URLs with keepali|
|10744|New|Nor|2002-07-12|suexec might fail to open log file|
|10747|New|Maj|2002-07-12|ftp SIZE command and 'smart' ftp servers results i|
|10760|New|Maj|2002-07-12|empty ftp directory listings from cached ftp direc|
|14518|Opn|Nor|2002-11-13|QUERY_STRING parts not incorporated by mod_rewrite|
|16013|Opn|Nor|2003-01-13|Fooling mod_autoindex + IndexIgnore   |
|16631|Inf|Min|2003-01-31|.htaccess errors logged outside the virtual host l|
|17318|Inf|Cri|2003-02-23|Abend on deleting a temporary cache file if proxy |
|19279|Inf|Min|2003-04-24|Invalid chmod options in solaris build|
|21637|Inf|Nor|2003-07-16|Timeout causes a status code of 200 to be logged  |
|21777|Inf|Min|2003-07-21|mod_mime_magic doesn't handle little gif files|
|22618|New|Maj|2003-08-21|MultiViews invalidates PATH_TRANSLATED if cgi-wrap|
|25057|Inf|Maj|2003-11-27|Empty PUT access control in .htaccess overrides co|
|26126|New|Nor|2004-01-14|mod_include hangs with request body   |
|26152|Ass|Nor|2004-01-15|Apache 1.3.29 and below directory traversal vulner|
|26790|New|Maj|2004-02-09|error deleting old cache file |
|29257|Opn|Nor|2004-05-27|Problem with apache-1.3.31 and mod_frontpage (dso,|
|29498|New|Maj|2004-06-10|non-anonymous ftp broken in mod_proxy |
|29538|Ass|Enh|2004-06-12|No facility used in ErrorLog to syslog|
|30207|New|Nor|2004-07-20|Piped logs don't close read end of pipe   |
|30877|New|Nor|2004-08-26|htpasswd clears passwd file on Sun when /var/tmp i|
|30909|New|Cri|2004-08-28|sporadic segfault resulting in broken connections |
|31975|New|Nor|2004-10-29|httpd-1.3.33: buffer overflow in htpasswd if calle|
|32078|New|Enh|2004-11-05|clean up some compiler warnings   |
|32539|New|Trv|2004-12-06|[PATCH] configure --enable-shared= brocken on SuSE|
|32974|Inf|Maj|2005-01-06|Client IP not set |
|33086|New|Nor|2005-01-13|unconsistency betwen 404 displayed path and server|
|33495|Inf|Cri|2005-02-10|Apache crashes with WSADuplicateSocket failed for|
|33772|New|Nor|2005-02-28|inconsistency in manual and error reporting by sue|
|33875|New|Enh|2005-03-07|Apache processes consuming CPU|
|34108|New|Nor|2005-03-21|mod_negotiation changes mtime to mtime of Document|
|34114|New|Nor|2005-03-21|Apache could interleave log entries when writing t|
|34404|Inf|Blk|2005-04-11|RewriteMap prg can not handle fpout   |
|34571|Inf|Maj|2005-04-22|Apache 1.3.33 stops logging  vhost|
|34573|Inf|Maj|2005-04-22|.htaccess not working / mod_auth_mysql|
|35424|New|Nor|2005-06-20|httpd disconnect in Timeout on CGI|
|35439|New|Nor|2005-06-21|Problem with remove /../ in util.c and mod_rewri|
|35547|Inf|Maj|2005-06-29|Problems with libapreq 1.2 and Apache::Cookie |
|3|New|Nor|2005-06-30|Can't find DBM on Debian Sarge|
|36375|Opn|Nor|2005-08-26|Cannot include http_config.h from C++ file|
|37166|New|Nor|2005-10-19|Under certain conditions, mod_cgi delivers an empt|
|37185|New|Enh|2005-10-20|AddIcon, AddIconByType for OpenDocument format|
|37252|New|Reg|2005-10-26|gen_test_char reject NLS string   |
|38989|New|Nor|2006-03-15|restart + piped logs stalls httpd for 24 minutes (|
|39104|New|Enh|2006-03-25|[FR] fix build with -Wl,--as-needed   |
|39287|New|Nor|2006-04-12|Incorrect If-Modified-Since validation (due to syn|
|39937|New|Nor|2006-06-30|Garbage output if README.html is gzipped or compre|
|40176|New|Nor|2006-08-03|magic and mime|
|40224|Ver|Nor|2006-08-10|System time crashes Apache @year 2038 (win32 only?|
|41279|New|Nor|2007-01-02|Apache 1.3.37 htpasswd is vulnerable to buffer ove|
|42355|New|Maj|2007-05-08|Apache 1.3 permits non-rfc HTTP error code = 600 |

Re: FPE in linux loader on custom PHP extension

2008-04-14 Thread Michael B Allen 
On 4/10/08, Michael B Allen [EMAIL PROTECTED] wrote:
 Sorry this is a bit OT but I'm not sure what to do next and would
  really appreciate some ideas.

  One of my clients is seeing an FPE in ld-linux-x86-64.so when loading
  a custom PHP extension. The backtrace is inlined below.

  At least I assume it's blowing up loading my extension - with my
  extension disabled, everything loads and runs ok.

  # gdb /usr/sbin/httpd2-prefork
  GNU gdb 6.6
  Copyright (C) 2006 Free Software Foundation, Inc.
  GDB is free software, covered by the GNU General Public License, and you are
  welcome to change it and/or distribute copies of it under certain
  conditions.
  Type show copying to see the conditions.
  There is absolutely no warranty for GDB.  Type show warranty for details.
  This GDB was configured as x86_64-suse-linux...
  (no debugging symbols found)
  Using host libthread_db library /lib64/libthread_db.so.1.
  (gdb) run -X
  Starting program: /usr/sbin/httpd2-prefork -X
  (no debugging symbols found)
  (no debugging symbols found)
  (no debugging symbols found)

  [snipped]

  [Thread debugging using libthread_db enabled]
  [New Thread 47783686579872 (LWP 11366)]
  (no debugging symbols found)
  (no debugging symbols found)
  (no debugging symbols found)

  [snipped]

  Program received signal SIGFPE, Arithmetic exception.
  [Switching to Thread 47783686579872 (LWP 11366)]
  0x2b758030468f in do_lookup_x () from /lib64/ld-linux-x86-64.so.2
  (gdb) bt
  #0  0x2b758030468f in do_lookup_x () from /lib64/ld-linux-x86-64.so.2

This turned out to be a backward compatibility problem with .hash vs
newer .hash.gnu sections in the libs. Google on SIGFPE do_lookup_x
for details.

Signing off,
Mike

-- 
Michael B Allen
PHP Active Directory SPNEGO SSO
http://www.ioplex.com/

Re: Apache 3.0

2008-04-14 Thread William A. Rowe, Jr. 

Paul Querna wrote:

For those who were not there, slides from Roy's keynote at ApacheCon EU:
  http://roy.gbiv.com/talks/200804_Apache3_ApacheCon.pdf


I came away with one question...

if you read the slides you should understand Roy as pointing out the
relative peaks and valleys in traffic, corresponding to regular v.s.
drawn out release cycles, and general energy level.

But measuring the list as energy - Roy did you factor in the various
[EMAIL PROTECTED] traffic (and earlier generations?)

There's one fact, bug tracking has significantly changed things.  Yes,
we have too many open bugs, but many issues never hit dev@; they are
entirely discussed in the incident and svn history.

So to leave out bugs@ history (perhaps filter out initial postings, but
retain all comment-added messages) is to neglect a major aspect of httpd
ongoing progress and development.

Bill

Re: flood random subst patch

2008-04-14 Thread William A. Rowe, Jr. 

Guy Ferraiolo wrote:

Folks

Again, if there's anything I can do to help this along, please let me
know.


Pointer to the now-current patch after all of the recent discussion would
help - I'm happy to commit this today.

Re: Ship 1.3.0 apr in httpd 2.2.9

2008-04-14 Thread William A. Rowe, Jr. 

Ruediger Pluem wrote:


here is my idea:

Ship 1.3.0 with httpd 2.2.x, but do *not* make httpd dependent on 1.3.x
now. Wait for this until 1.3.x has settled a bit more and things like
the ones Nick mentioned are fixed.


I'm not entirely keen on this idea; the reasons being

 * we want to pick up 1.3 api's to fix log file creation 'the right way'
 * users looking at the mmn expect a certain baseline; explaining why
   they cannot compile this module which is purported to run with httpd
   ver 2.2.9 or later would become too complicated.


Furthermore I could image adding apr-1.2.x / apr-util-1.2.x directories
to our tarballs for the next release to make it easy for users to fall
back to 1.2.x if there is some kind of regression in 1.3.0.


Now that the code is branched, we should ensure there is fundamentally
no difference in existing 1.2.x functionality; we can't break abi or
even significantly change behaviors, only add new things


But it might be also ok to require the users in these cases to download
1.2.x separately drop in the sources and call buildconf.


well if there is no difference between 1.2 and 1.3, and we recognize
that the first 1.3.0 is entirely not solving the problem for memcached
for example, we could change the prereq to 1.3.1 for the next release
to ensure they have the bug-free implementation for the next httpd tag.

Bill

[Fwd: Re: more importuning about the flood patch]

2008-04-14 Thread William A. Rowe, Jr. 

Confirming; this is the patch?

Bill
---BeginMessage---
No problem!

On Fri, 2008-02-22 at 12:59 -0600, William A. Rowe, Jr. wrote:
 Guy Ferraiolo wrote:
  Folks
  
  I think flood is highly useful once the random substitution feature is
  added.  If we got that into the code base there might be greater use of
  flood and I think that would be a good thing.  Also, I have some other
  features planned but I don't want to have several patches outstanding at
  once.
  
  If no one cares about this how about just putting it in?  I've been
  working with flood for some time and I do care.  Is there anything I can
  do to get this going?
 
 I like the thought, but a pointer back to your patch, please?
-- 
Guy Ferraiolo   mailto:[EMAIL PROTECTED]
Performance Measurement  Analysis  http://CNET.com
CNETtel: 1.908.541.3739
1200 Route 22 East  fax: 1.908.575.7474
Bridgewater, NJ 08807   cel: 1.732.618.0250
diff --exclude-from=excludefile -urN flood-orig/config.h.in flood-patchbuild/config.h.in
--- flood-orig/config.h.in	2007-12-19 11:54:42.0 -0800
+++ flood-patchbuild/config.h.in	2007-12-19 12:32:12.0 -0800
@@ -53,6 +53,10 @@
 #define XML_FARM_USEFARMER_COUNT count
 #define XML_FARM_USEFARMER_DELAY startdelay
 #define XML_FARM_USEFARMER_START startcount
+#define XML_SUBST_LIST subst_list
+#define XML_SUBST_ENTRY subst_entry
+#define XML_SUBST_VAR subst_var
+#define XML_SUBST_FILE subst_file
 
 /* The delimiter (used above) between XML elements */
 #define XML_ELEM_DELIM .
diff --exclude-from=excludefile -urN flood-orig/examples/flood.dtd flood-patchbuild/examples/flood.dtd
--- flood-orig/examples/flood.dtd	2007-12-19 11:54:42.0 -0800
+++ flood-patchbuild/examples/flood.dtd	2007-12-19 12:32:12.0 -0800
@@ -1,5 +1,3 @@
-?xml version=1.0 ?
-
 !--
 
  This is a DTD for flood configuration files.
@@ -12,8 +10,7 @@
  is valid (in contrast to just well-formed).
 
 --
-
-!ELEMENT flood (urllist+,profile+,farmer+,farm+,seed?)
+!ELEMENT flood (urllist+,profile+,farmer+,farm+,seed?,subst_list?)
 
 !-- urllist --
 !ELEMENT urllist (name,description?,baseurl?,(url|sequence)+)
@@ -46,6 +43,15 @@
 !ATTLIST sequence sequencename CDATA #REQUIRED
 !ATTLIST sequence sequencelist CDATA #REQUIRED
 
+!-- subst_list --
+!--
+!ELEMENT subst_list (subst_entry|subst_seq)
+!ELEMENT subst_entry (subst_file, subst_var)
+!ELEMENT subst_file (#PCDATA)
+!ELEMENT subst_var (#PCDATA)
+!ELEMENT subst_seq (subst_list+)
+
+--
 !-- profile --
 
 !ENTITY % profile.events (profile_init?,get_next_url?,create_req?,postprocess?,loop_condition?,profile_destroy?)+
diff --exclude-from=excludefile -urN flood-orig/examples/subprojects flood-patchbuild/examples/subprojects
--- flood-orig/examples/subprojects	1969-12-31 16:00:00.0 -0800
+++ flood-patchbuild/examples/subprojects	2007-12-19 12:32:12.0 -0800
@@ -0,0 +1,2 @@
+test/flood
+apreq
diff --exclude-from=excludefile -urN flood-orig/examples/subst-example.xml flood-patchbuild/examples/subst-example.xml
--- flood-orig/examples/subst-example.xml	1969-12-31 16:00:00.0 -0800
+++ flood-patchbuild/examples/subst-example.xml	2007-12-19 12:32:12.0 -0800
@@ -0,0 +1,29 @@
+flood configversion=1
+  urllistnameTest Hosts/namedescriptionA bunch of hosts we want to hit/descriptionurl method=GET requesttemplate=http://httpd.apache.org/${subproject};http://httpd.apache.org/${subproject}/url/urllist
+  farm
+nameBingo/name
+usefarmer count=1Joe/usefarmer
+  /farm
+  subst_list
+subst_entry
+  subst_file./subprojects/subst_file
+  subst_varsubproject/subst_var
+/subst_entry
+  /subst_list
+  profile
+nameRoundRobinProfile/name
+profiletyperound_robin/profiletype
+descriptionA Test Round Robin Configuration/description
+verify_respverify_200/verify_resp
+socketgeneric/socket
+reporteasy/report
+useurllistTest Hosts/useurllist
+  /profile
+  seed1/seed
+  farmer
+nameJoe/name
+useprofileRoundRobinProfile/useprofile
+time23/time
+  /farmer
+  test_descriptionlab split test 2/test_description
+/flood
diff --exclude-from=excludefile -urN flood-orig/flood_round_robin.c flood-patchbuild/flood_round_robin.c
--- flood-orig/flood_round_robin.c	2007-12-19 11:54:42.0 -0800
+++ flood-patchbuild/flood_round_robin.c	2007-12-19 12:32:12.0 -0800
@@ -55,6 +55,7 @@
 #include config.h
 #include flood_net.h
 #include flood_round_robin.h
+#include flood_subst_file.h
 #include flood_profile.h
 
 /* On FreeBSD, the return of regexec() is 0 or REG_NOMATCH, and REG_OK is undefined */
@@ -116,6 +117,9 @@
 
 apr_hash_t *state;
 
+int subst_count;
+subst_rec_t* subst_list;
+
 int current_round;
 int current_url;
 
@@ -128,6 +132,16 @@
 int size, matchsize;
 regex_t re;
 regmatch_t match[2];
+subst_rec_t* subst_rec_p;
+char*

Re: Ship 1.3.0 apr in httpd 2.2.9

2008-04-14 Thread Plüm , Rüdiger , VF-Group 
 

 -Ursprüngliche Nachricht-
 Von: William A. Rowe, Jr. 
 Gesendet: Montag, 14. April 2008 12:49
 An: dev@httpd.apache.org
 Betreff: Re: Ship 1.3.0 apr in httpd 2.2.9
 
 Ruediger Pluem wrote:
  
  here is my idea:
  
  Ship 1.3.0 with httpd 2.2.x, but do *not* make httpd 
 dependent on 1.3.x
  now. Wait for this until 1.3.x has settled a bit more and 
 things like
  the ones Nick mentioned are fixed.
 
 I'm not entirely keen on this idea; the reasons being
 
   * we want to pick up 1.3 api's to fix log file creation 
 'the right way'

It has not be the right way for long and the fixes that need to be
done are small. So I see no issue here having this done in 2.2.9 with
apr 1.2.x. We can align it with trunk 2.2.10 or later.

   * users looking at the mmn expect a certain baseline; explaining why
 they cannot compile this module which is purported to run 
 with httpd
 ver 2.2.9 or later would become too complicated.

Do we really need a bump anyway when we only ship 2.2.x with 1.3.x but
do not make it dependent on it?
We could do the bump later once we depend on 1.3.x.


 
  Furthermore I could image adding apr-1.2.x / apr-util-1.2.x 
 directories
  to our tarballs for the next release to make it easy for 
 users to fall
  back to 1.2.x if there is some kind of regression in 1.3.0.
 
 Now that the code is branched, we should ensure there is fundamentally
 no difference in existing 1.2.x functionality; we can't break abi or
 even significantly change behaviors, only add new things

In general yes. All the measures above should only ensure that the users
have a quick fallback in case something is broken. I still think that
this approach gives us the best of both:

* A broad test audience for 1.3.0 and thus giving us a much better feeling
  for the quality of 1.3.x.
* A very quick possibility to resolve possible regression issues in 1.3.0
  Of course these possible regression issues should be solved quickly
  1.3..x


 
  But it might be also ok to require the users in these cases 
 to download
  1.2.x separately drop in the sources and call buildconf.
 
 well if there is no difference between 1.2 and 1.3, and we recognize
 that the first 1.3.0 is entirely not solving the problem for memcached
 for example, we could change the prereq to 1.3.1 for the next release
 to ensure they have the bug-free implementation for the next 
 httpd tag.

Sure. I guess this needs to be done anyway regardless of my proposal.

Regards

Rüdiger

Re: Ship 1.3.0 apr in httpd 2.2.9

2008-04-14 Thread William A. Rowe, Jr. 

Plüm wrote:
 
It has not be the right way for long and the fixes that need to be

done are small. So I see no issue here having this done in 2.2.9 with
apr 1.2.x. We can align it with trunk 2.2.10 or later.


fair enough


  * users looking at the mmn expect a certain baseline; explaining why
they cannot compile this module which is purported to run with httpd
ver 2.2.9 or later would become too complicated.


Do we really need a bump anyway when we only ship 2.2.x with 1.3.x but
do not make it dependent on it?
We could do the bump later once we depend on 1.3.x.


this makes things more difficult on third party module authors, but not
saying that makes it impossible.

You are right that we can ship apr-1.3 claiming apr-1.2 readiness, and
bump to 1.3 prereq+mmn bump a bit later.

Furthermore I could image adding apr-1.2.x / apr-util-1.2.x 

directories
to our tarballs for the next release to make it easy for 

users to fall

back to 1.2.x if there is some kind of regression in 1.3.0.

Now that the code is branched, we should ensure there is fundamentally
no difference in existing 1.2.x functionality; we can't break abi or
even significantly change behaviors, only add new things


In general yes. All the measures above should only ensure that the users
have a quick fallback in case something is broken. I still think that
this approach gives us the best of both:

* A broad test audience for 1.3.0 and thus giving us a much better feeling
  for the quality of 1.3.x.


goodness, yes


* A very quick possibility to resolve possible regression issues in 1.3.0
  Of course these possible regression issues should be solved quickly
  1.3..x


yes

let's see what others have to say over the next day or two, if they can
stand the frustration of waiting 2 more months to take advantage of the
api changes.

Re: flood random subst patch

2008-04-14 Thread William A. Rowe, Jr. 

For those unaware, there are new flood and framework components
of the httpd-test bugzilla product.

Re: flood random subst patch

2008-04-14 Thread Vincent van Scherpenseel 

William A. Rowe, Jr. wrote:

For those unaware, there are new flood and framework components
of the httpd-test bugzilla product.


Excellent :) I'm glad flood is regaining attention. It's a great tool 
and I find it a pity that the project isn't that active anymore. The 
site could use a little updating too: I get 404s for every 
svn.apache.org/... link. Also, I believe there's no link back to the 
homepage from the child pages.


Guy Ferraiolo: thank you very much for submitting your patch. It has 
really been a lifesaver for me. Keep up the good work.


Cheers, Vincent

rebase your current flood/framework checkouts!

2008-04-14 Thread William A. Rowe, Jr. 

for those with a flood checkout, from it's root you must

svn switch https://svn.apache.org/repos/asf/httpd/test/flood/trunk

and for a perl framework checkout, it's

svn switch https://svn.apache.org/repos/asf/httpd/test/framework/trunk

and for specweb99, it's

svn switch https://svn.apache.org/repos/asf/httpd/test/specweb99/trunk

If you have a checkout from http: then use that rather than https:

Re: [Fwd: Re: more importuning about the flood patch]

2008-04-14 Thread Oden Eriksson 
Den Monday 14 April 2008 12.32.25 skrev William A. Rowe, Jr.:
 Confirming; this is the patch?

 Bill

Does not build for me (r64) on Mandriva Linux 2008.1 (x86_64):

/bin/sh /usr/lib64/apr-1/build/libtool --silent --mode=compile 
gcc-O2 -g -pipe -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector 
--param=ssp-buffer-size=4   -pthread-I/usr/include/include   -DLINUX=2 
-D_REENTRANT -D_GNU_SOURCE -D_LARGEFILE64_SOURCE -I/usr/include/apr-1   
-I/usr/include/apr-1 -I/usr/include  -I. -I/home/oden/RPM/BUILD/flood   -c 
flood.c  touch flood.lo
/bin/sh /usr/lib64/apr-1/build/libtool --silent --mode=compile 
gcc-O2 -g -pipe -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector 
--param=ssp-buffer-size=4   -pthread-I/usr/include/include   -DLINUX=2 
-D_REENTRANT -D_GNU_SOURCE -D_LARGEFILE64_SOURCE -I/usr/include/apr-1   
-I/usr/include/apr-1 -I/usr/include  -I. -I/home/oden/RPM/BUILD/flood   -c 
flood_round_robin.c  touch flood_round_robin.lo
flood_round_robin.c: In function 'round_robin_profile_init':
flood_round_robin.c:793: warning: comparison is always false due to limited 
range of data type
flood_round_robin.c:793: warning: comparison is always false due to limited 
range of data type
flood_round_robin.c:910: error: lvalue required as left operand of assignment
flood_round_robin.c:920: error: lvalue required as left operand of assignment
flood_round_robin.c: In function 'round_robin_postprocess':
flood_round_robin.c:1086: warning: cast from pointer to integer of different 
size
flood_round_robin.c:1086: warning: cast from pointer to integer of different 
size
flood_round_robin.c:1097: warning: cast from pointer to integer of different 
size
flood_round_robin.c:1097: warning: cast from pointer to integer of different 
size
flood_round_robin.c:1236: warning: passing argument 3 of 'apr_file_write' from 
incompatible pointer type





-- 
Regards // Oden Eriksson

Re: [Fwd: Re: more importuning about the flood patch]

2008-04-14 Thread Vincent van Scherpenseel 


Oden Eriksson wrote:

Does not build for me (r64) on Mandriva Linux 2008.1 (x86_64):


 snip

Do you happen to compile flood using GCC 4.x? I couldn't compile flood 
with Guy's patch using GCC 4.1, particularly due to these two errors:


 flood_round_robin.c:910: error: lvalue required as left operand of
 assignment
 flood_round_robin.c:920: error: lvalue required as left operand of
 assignment

Compiling using GCC 3.3 it built like a charm, only warning me about the 
above two lines that it's deprecated. Perhaps someone could fix this?


 - Vincent van Scherpenseel

Re: [PROPOSAL] Time Based Releases

2008-04-14 Thread Jim Jagielski 


On Apr 12, 2008, at 1:20 PM, Paul Querna wrote:
This is something I have been thinking about for awhile, and  
discussed with a few other http server people before.


I think that for the 'stable' branch, we should move to time based  
releases.


My proposal is for every 2 months, we do a release of the main  
stable branch, which at this time is 2.2.x.


I also volunteer to be the Release Manager for the first couple  
releases, assuming no one else really wants to do them :-)


Thoughts?



As the person who's been pushing the last several releases out, I'm
+1 on having a set schedule, assuming, of course, that we aren't holding
ourselves to it (it's done when it's done after all), and I'm still
planning on calling for a 2.2.9 release soon and will continue to
offer to RM.

Re: [Fwd: Re: more importuning about the flood patch]

2008-04-14 Thread Oden Eriksson 
Den Monday 14 April 2008 15.15.22 skrev Vincent van Scherpenseel:
 Oden Eriksson wrote:
  Does not build for me (r64) on Mandriva Linux 2008.1 (x86_64):
   snip

 Do you happen to compile flood using GCC 4.x? I couldn't compile flood

 with Guy's patch using GCC 4.1, particularly due to these two errors:
   flood_round_robin.c:910: error: lvalue required as left operand of
   assignment
   flood_round_robin.c:920: error: lvalue required as left operand of
   assignment

Yes, using gcc-4.2.3 here. I think with 4.2.x lvalue became errors instead of 
warnings. We will soon switch to gcc 4.3.x so...

 Compiling using GCC 3.3 it built like a charm, only warning me about the
 above two lines that it's deprecated. Perhaps someone could fix this?

   - Vincent van Scherpenseel



-- 
Regards // Oden Eriksson

Re: flood random subst patch

2008-04-14 Thread William A. Rowe, Jr. 

Vincent van Scherpenseel wrote:


Excellent :) I'm glad flood is regaining attention. It's a great tool 
and I find it a pity that the project isn't that active anymore. The 
site could use a little updating too: I get 404s for every 
svn.apache.org/... link. Also, I believe there's no link back to the 
homepage from the child pages.


Give it an hour to refresh, these still might use work but I had a few
minutes just to fix the broken links.

Bill

2.2.9 (Was: Re: [PROPOSAL] Time Based Releases)

2008-04-14 Thread Jim Jagielski 


On Apr 13, 2008, at 3:32 AM, Justin Erenkrantz wrote:
On Sat, Apr 12, 2008 at 9:52 PM, Ruediger Pluem [EMAIL PROTECTED]  
wrote:
My proposal is for every 2 months, we do a release of the main  
stable

branch, which at this time is 2.2.x.




I would like to go for 3 month, so four times per year or once each
quarter.


I think it's a good idea - except I think 2 months is a little too
frequent as well.  That means 1 week out of every 8 that we're
spending checking and testing the release.  1 out of 12 weeks eases it
a bit...so +1 for every three months.  -- justin



Plus, every 3 months would coincide with the report-to-board cycle,
making it easier for everyone to follow :) Next is due in May, so
if we release this month, then we can follow a Release before
the board report or else Release at board report cycle (with
the caveat I noted before ;) )

As noted (and as I pinged a few people about in Amsterdam), I'm
looking to push for a 2.2.9 soon. We have enough for sure
warrant it... There is the ship 1.3.0 with 2.2.9 thread going on,
but I do not want 2.2.9 to hold off too long for that...

So I'd like to propose 2.2.9 for the end of this month.

Re: 2.2.9 (Was: Re: [PROPOSAL] Time Based Releases)

2008-04-14 Thread Jess Holle 

Jim Jagielski wrote:

Plus, every 3 months would coincide with the report-to-board cycle,
making it easier for everyone to follow :) Next is due in May, so
if we release this month, then we can follow a Release before
the board report or else Release at board report cycle (with
the caveat I noted before ;) )

As noted (and as I pinged a few people about in Amsterdam), I'm
looking to push for a 2.2.9 soon. We have enough for sure
warrant it... There is the ship 1.3.0 with 2.2.9 thread going on,
but I do not want 2.2.9 to hold off too long for that...

So I'd like to propose 2.2.9 for the end of this month.
Sorry to butt in, but is there any hope of getting issue #44803 
addressed in that timeframe?


[The gap between mod_jk and mod_proxy_ajp in this and other areas (I 
don't believe it can set a longer packet size than 8K yet) is a bit 
troubling...]


--
Jess Holle

Re: 2.2.9 (Was: Re: [PROPOSAL] Time Based Releases)

2008-04-14 Thread Jim Jagielski 


On Apr 14, 2008, at 10:00 AM, Jess Holle wrote:

Jim Jagielski wrote:

Plus, every 3 months would coincide with the report-to-board cycle,
making it easier for everyone to follow :) Next is due in May, so
if we release this month, then we can follow a Release before
the board report or else Release at board report cycle (with
the caveat I noted before ;) )

As noted (and as I pinged a few people about in Amsterdam), I'm
looking to push for a 2.2.9 soon. We have enough for sure
warrant it... There is the ship 1.3.0 with 2.2.9 thread going on,
but I do not want 2.2.9 to hold off too long for that...

So I'd like to propose 2.2.9 for the end of this month.
Sorry to butt in, but is there any hope of getting issue #44803  
addressed in that timeframe?




Possibly, yes.

The feedback on the real gap between mod_jk and mod_proxy_ajp is
stuff we really appreciate! Thanks!

Re: 2.2.9 (Was: Re: [PROPOSAL] Time Based Releases)

2008-04-14 Thread Jim Jagielski 


On Apr 14, 2008, at 10:15 AM, Jim Jagielski wrote:


On Apr 14, 2008, at 10:00 AM, Jess Holle wrote:

Jim Jagielski wrote:

Plus, every 3 months would coincide with the report-to-board cycle,
making it easier for everyone to follow :) Next is due in May, so
if we release this month, then we can follow a Release before
the board report or else Release at board report cycle (with
the caveat I noted before ;) )

As noted (and as I pinged a few people about in Amsterdam), I'm
looking to push for a 2.2.9 soon. We have enough for sure
warrant it... There is the ship 1.3.0 with 2.2.9 thread going on,
but I do not want 2.2.9 to hold off too long for that...

So I'd like to propose 2.2.9 for the end of this month.
Sorry to butt in, but is there any hope of getting issue #44803  
addressed in that timeframe?




Possibly, yes.



Quick look: We need to re-adjust this post fixups, since this
should be a setting ala flushpackets, etc...

Re: [Fwd: Re: more importuning about the flood patch]

2008-04-14 Thread Guy Ferraiolo 
OK, I'll get a new checkout and build a patch that won't complain.

Thanks!

Guy

On Mon, 2008-04-14 at 15:21 +0200, Oden Eriksson wrote:
 Den Monday 14 April 2008 15.15.22 skrev Vincent van Scherpenseel:
  Oden Eriksson wrote:
   Does not build for me (r64) on Mandriva Linux 2008.1 (x86_64):
snip
 
  Do you happen to compile flood using GCC 4.x? I couldn't compile flood
 
  with Guy's patch using GCC 4.1, particularly due to these two errors:
flood_round_robin.c:910: error: lvalue required as left operand of
assignment
flood_round_robin.c:920: error: lvalue required as left operand of
assignment
 
 Yes, using gcc-4.2.3 here. I think with 4.2.x lvalue became errors instead of 
 warnings. We will soon switch to gcc 4.3.x so...
 
  Compiling using GCC 3.3 it built like a charm, only warning me about the
  above two lines that it's deprecated. Perhaps someone could fix this?
 
- Vincent van Scherpenseel
 
 
 
-- 
Guy Ferraiolo   mailto:[EMAIL PROTECTED]
Performance Measurement  Analysis  http://CNET.com
CNETtel: 1.908.541.3739
1200 Route 22 East  fax: 1.908.575.7474
Bridgewater, NJ 08807   cel: 1.732.618.0250

Re: [PROPOSAL] Time Based Releases

2008-04-14 Thread Brad Nicholes 
 On 4/12/2008 at 11:20 AM, in message [EMAIL PROTECTED], Paul
Querna [EMAIL PROTECTED] wrote:
 This is something I have been thinking about for awhile, and discussed 
 with a few other http server people before.
 
 I think that for the 'stable' branch, we should move to time based releases.
 
 My proposal is for every 2 months, we do a release of the main stable 
 branch, which at this time is 2.2.x.
 
 Security Issues of great importance of course would trigger an immediate 
 release.  Depending on the nearness to a scheduled release, we may or 
 may not scrap the next time based release.
 

I guess I am not sure what setting a schedule is trying to accomplish.  Can't 
you do this already?  If somebody wants to release every 2 months, that person 
can call for the release and be the RM every two months.  In other words, as 
long as there is somebody willing to do the work, then the work will happen.  
If a release isn't required, ie. no real appreciable improvement since the 
previous release, then why require everyone to mobilize for very little gain.  
I guess I am looking for the problem that a hard schedule resolves when we can 
already release as early or as often as desired.

Brad

Re: [PROPOSAL] Time Based Releases

2008-04-14 Thread Plüm , Rüdiger , VF-Group 
 

 -Ursprüngliche Nachricht-
 Von: Brad Nicholes [mailto:[EMAIL PROTECTED] 
 Gesendet: Montag, 14. April 2008 17:44
 An: dev@httpd.apache.org
 Betreff: Re: [PROPOSAL] Time Based Releases
 
  On 4/12/2008 at 11:20 AM, in message 
 [EMAIL PROTECTED], Paul
 Querna [EMAIL PROTECTED] wrote:
  This is something I have been thinking about for awhile, 
 and discussed 
  with a few other http server people before.
  
  I think that for the 'stable' branch, we should move to 
 time based releases.
  
  My proposal is for every 2 months, we do a release of the 
 main stable 
  branch, which at this time is 2.2.x.
  
  Security Issues of great importance of course would trigger 
 an immediate 
  release.  Depending on the nearness to a scheduled release, 
 we may or 
  may not scrap the next time based release.
  
 
 I guess I am not sure what setting a schedule is trying to 
 accomplish.  Can't you do this already?  If somebody wants to 
 release every 2 months, that person can call for the release 
 and be the RM every two months.  In other words, as long as 
 there is somebody willing to do the work, then the work will 
 happen.  If a release isn't required, ie. no real appreciable 
 improvement since the previous release, then why require 
 everyone to mobilize for very little gain.  I guess I am 
 looking for the problem that a hard schedule resolves when we 
 can already release as early or as often as desired.

Well put. Reminds me of André's question What problem are we trying to solve?
The only benefit I can see in the schedule is that it gives all of us a gentle
reminder every x month that we should think about a new release. If there are
not enough people then that think that a release makes sense then there will
be no release.
So my point in proposing a longer period than the two month is that I want
to increase the likelyhood that enough people think that a release makes sense.
IMHO it would be a pity if the RM puts its valueable time in creating a
release tarball that fails to get the needed votes.
Even if gets enough votes I think it would be bad if the testing is limited
due to a tough schedule which could lower the quality of the release.


Regards

Rüdiger

Re: [PROPOSAL] Time Based Releases

2008-04-14 Thread Jim Jagielski 

I think what Paul is suggesting (he will for sure correct me
if I'm wrong) is that it's better to at least have some semblance
of a schedule than not, and by baselining every X months for a release,
it provides us, as volunteers, to better allocate time. It does
not mean, imo, that we rush out packages that aren't ready or
release something just because we have a schedule to keep...
we all have day jobs that force that on us, and we don't want
that kind of pressure here as well.

However, looking over things, I think that we have enough active
activity such that a ~3month cycle might be workable...

Re: [PROPOSAL] Time Based Releases

2008-04-14 Thread Mads Toftum 
On Mon, Apr 14, 2008 at 12:46:43PM -0400, Jim Jagielski wrote:
 I think what Paul is suggesting (he will for sure correct me
 if I'm wrong) is that it's better to at least have some semblance
 of a schedule than not, and by baselining every X months for a release,
 it provides us, as volunteers, to better allocate time. It does
 not mean, imo, that we rush out packages that aren't ready or
 release something just because we have a schedule to keep...
 we all have day jobs that force that on us, and we don't want
 that kind of pressure here as well.

TBH, I'm not too keen on the idea of releasing just because we're
suddenly hitting a specific date - if there's no changes worth
releasing... Yeah, I'd like to see it happen more often than every 6-8
months, but every 2-3 months is just going to create unnecessary work
fort the admins out there. Going down this route, I think the bare
minimum way of playing nice would be to very clearly mark releases as
either security, feature or just that time of the month releases.

 However, looking over things, I think that we have enough active
 activity such that a ~3month cycle might be workable...

How many branches are we talking about? the whole 2.x bunch or?

just my $.02

Mads Toftum
-- 
http://soulfood.dk

Re: Solaris sed based apache filtering module (mod_sed)

2008-04-14 Thread Basant Kukreja 
On Sat, Apr 12, 2008 at 10:27:40AM -0700, Chris Elving wrote:
 Basant Kukreja wrote:
 +static void sed_write(sed_eval_t *eval, char *buf, int sz)
 +{
 +if (eval-curoutbuf + sz = eval-outbend) {
 +// flush current buffer
 +sed_flush_output_buffer(eval, buf, sz);
 +}
 +else {
 +memcpy(eval-curoutbuf, buf, sz);
 +eval-curoutbuf += sz;
 +}

 sed is an inherently line-oriented editor. It seems wrong to buffer 
 multiple lines within libsed. Consider, for example, how adding such 
 multi-line buffering to libsed would complicate implementing an interactive 
 sed like sed(1).

 Instead, it seems like such buffering should occur in mod_sed. mod_sed is 
 what couples libsed to the bucket brigade, and mod_sed knows that such such 
 buffering is appropriate.
sed_eval_buffer and sed_finalize_eval flush the output before returning. If
somebody want to implement interactive sed then one can send line vise line
data to sed_eval_buffer (but that seems like poor assumption). So it is still
possible to implement interactive sed code using these APIs. 

But still it makes more sense to me to move buffering code outside the libsed.
I will work towards moving buffering code outside the libsed to mod_sed filter
code.

Regards,
Basant.

Re: AuthzMergeRules directive

2008-04-14 Thread Chris Darroch 

Brad Nicholes wrote:


I'm not real excited about adding a new authz directive.  Authn and
authz are already very complex and adding a new directive to the mix will
just help to confuse people even more.


  That's a good point.  Mostly the idea of an Accept replacement for
Require came up as a way to distinguish pre-2.4 and 2.4 per-dir authz,
and in case there were any Require foo directives which had slightly
different meanings in the two contexts and which might therefore trip
people up.  If we can do without it, all the better.



I am OK with this one except for the reason that I mentioned before.
By allowing authz to be inherited even when AuthzMergeRules is OFF is
kind of a conflict.  In other words, since AuthzMergeRules OFF implies
an AND, 1 AND 0 should be 0 or no authz rather than inherited authz.
However I could buy into this if it seems to make more intuitive sense
to the user.


  Well, I may be missing something, but what I envisioned was that
AuthzMergeRules had three options: Off (i.e., inherited until overridden,
the pre-2.4 default), SatisfyOne, and SatisfyAll.  That would give
administrators full control over how they wanted authz in different
per-dir blocks to be merged.

  It seems to me we have three basic possibilities when it comes to
merging authz across per-dir blocks, and the most common authz case
to consider is going to be where security gets tighter as you move down
the document tree.  Imagine something like the following in a pre-2.4
configuration, where admin is not a member of team:

Directory /htdocs
   ## full access
/Directory
Directory /htdocs/team
   ## anyone in team has access
   Require group team
/Directory
Directory /htdocs/team/admin
   ## only admin user has access
   Require user admin
/Directory


1) The first option for 2.4 merging is to use OR logic (the current
  default in trunk).  This leads to anyone in team having access to
  /htdocs/team/admin, I believe.  I think I'd have to vote -1 against
  this, because it will lead to lots of previously secure configurations
  becoming insecure.  Plus it would seem to increase the required
  number of directives (since you have to add AuthzMergeRules Off
  in each sub-Directory) to achieve what seems to me to be a typical
  configuration, i.e., increasing security as you go down the tree.

2) Another option might be to use AND logic.  In this case, if I'm
  applying the logic correctly, no one would be able to access
  /htdocs/team/admin given the configuration above in a 2.4 context
  (since admin isn't in team).  While more secure, this also seems
  counter-intuitive to me.  Maybe -0.5?

3) Finally there's the pre-2.4 logic of overriding all previous authz.
  This would seem to be the most preferable option, since it ensures
  many pre-2.4 configurations will continue to work as expected, and
  I think also reduces configuration verbosity in typical cases.


  You were concerned, I think, about more complex configurations
like this:


Directory /www/pages
   SatisfyAll
  Require ip 10.10.0.1
  Require ldap-group sales
  SatisfyOne
 Require ldap-group ne-sales
 Require ldap-group sw-sales
  /SatisfyOne
/SatisfyAll
/Directory



Directory /www/pages/private
   Require ldap-group marketing
/Directory


  I would suggest that the default pre-2.4 logic of overriding previous
authz when any authz is defined in a per-dir block is still reasonable as
a default.  Thus, only those in marketing have access to
/www/pages/private, and they can access it from other addresses than
10.10.0.1.  Even if this isn't what is desired, it's clear enough that
an administrator can figure out what's going on and why the configuration
isn't achieving the desired result.

  I'd propose giving the administrator the choice of both alternatives
to the default logic.  Instead of simply offering AuthzMergeRules On,
there would be two alternatives to the default Off condition.  These
would be AuthzMergeRules SatisfyOne (the OR logic) and
AuthzMergeRules SatisfyAll (the AND logic).

  We might offer Or and And as synonyms for SatisfyOne and
SatisfyAll, respectively.

Chris.

--
GPG Key ID: 366A375B
GPG Key Fingerprint: 485E 5041 17E1 E2BB C263  E4DE C8E3 FA36 366A 375B

Re: AuthzMergeRules directive

2008-04-14 Thread Brad Nicholes 
 On 4/14/2008 at 12:21 PM, in message [EMAIL PROTECTED], Chris
Darroch [EMAIL PROTECTED] wrote:
 Brad Nicholes wrote:
 
 I'm not real excited about adding a new authz directive.  Authn and
 authz are already very complex and adding a new directive to the mix will
 just help to confuse people even more.
 
That's a good point.  Mostly the idea of an Accept replacement for
 Require came up as a way to distinguish pre-2.4 and 2.4 per-dir authz,
 and in case there were any Require foo directives which had slightly
 different meanings in the two contexts and which might therefore trip
 people up.  If we can do without it, all the better.
 
 
 I am OK with this one except for the reason that I mentioned before.
 By allowing authz to be inherited even when AuthzMergeRules is OFF is
 kind of a conflict.  In other words, since AuthzMergeRules OFF implies
 an AND, 1 AND 0 should be 0 or no authz rather than inherited authz.
 However I could buy into this if it seems to make more intuitive sense
 to the user.
 
Well, I may be missing something, but what I envisioned was that
 AuthzMergeRules had three options: Off (i.e., inherited until overridden,
 the pre-2.4 default), SatisfyOne, and SatisfyAll.  That would give
 administrators full control over how they wanted authz in different
 per-dir blocks to be merged.
 
It seems to me we have three basic possibilities when it comes to
 merging authz across per-dir blocks, and the most common authz case
 to consider is going to be where security gets tighter as you move down
 the document tree.  Imagine something like the following in a pre-2.4
 configuration, where admin is not a member of team:
 
 Directory /htdocs
 ## full access
 /Directory
 Directory /htdocs/team
 ## anyone in team has access
 Require group team
 /Directory
 Directory /htdocs/team/admin
 ## only admin user has access
 Require user admin
 /Directory
 
 
 1) The first option for 2.4 merging is to use OR logic (the current
default in trunk).  This leads to anyone in team having access to
/htdocs/team/admin, I believe.  I think I'd have to vote -1 against
this, because it will lead to lots of previously secure configurations
becoming insecure.  Plus it would seem to increase the required
number of directives (since you have to add AuthzMergeRules Off
in each sub-Directory) to achieve what seems to me to be a typical
configuration, i.e., increasing security as you go down the tree.
 
 2) Another option might be to use AND logic.  In this case, if I'm
applying the logic correctly, no one would be able to access
/htdocs/team/admin given the configuration above in a 2.4 context
(since admin isn't in team).  While more secure, this also seems
counter-intuitive to me.  Maybe -0.5?
 
 3) Finally there's the pre-2.4 logic of overriding all previous authz.
This would seem to be the most preferable option, since it ensures
many pre-2.4 configurations will continue to work as expected, and
I think also reduces configuration verbosity in typical cases.
 
 
You were concerned, I think, about more complex configurations
 like this:
 
 Directory /www/pages
SatisfyAll
   Require ip 10.10.0.1
   Require ldap-group sales
   SatisfyOne
  Require ldap-group ne-sales
  Require ldap-group sw-sales
   /SatisfyOne
 /SatisfyAll
 /Directory
 
 Directory /www/pages/private
Require ldap-group marketing
 /Directory
 
I would suggest that the default pre-2.4 logic of overriding previous
 authz when any authz is defined in a per-dir block is still reasonable as
 a default.  Thus, only those in marketing have access to
 /www/pages/private, and they can access it from other addresses than
 10.10.0.1.  Even if this isn't what is desired, it's clear enough that
 an administrator can figure out what's going on and why the configuration
 isn't achieving the desired result.
 

I'm OK with it up to this point.


I'd propose giving the administrator the choice of both alternatives
 to the default logic.  Instead of simply offering AuthzMergeRules On,
 there would be two alternatives to the default Off condition.  These
 would be AuthzMergeRules SatisfyOne (the OR logic) and
 AuthzMergeRules SatisfyAll (the AND logic).
 
We might offer Or and And as synonyms for SatisfyOne and
 SatisfyAll, respectively.
 

This is where it starts to go wrong for me.  Where it gets confusing for 
somebody who is trying to figure out what the configuration is doing is:

 Directory /www/pages
SatisfyAll
   Require ip 10.10.0.1
   Require ldap-group sales
   SatisfyOne
  Require ldap-group ne-sales
  Require ldap-group sw-sales
   /SatisfyOne
 /SatisfyAll
 /Directory
 
 Directory /www/pages/private
AuthzMergeRules SatisfyOne
SatisfyAll
   Require ldap-group marketing
   Require ldap-group alt-marketing
/SatisfyAll
 /Directory

Now I have to reconcile the logic of

Re: flood random subst patch

2008-04-14 Thread Guy Ferraiolo 
Thanks!

Guy

On Mon, 2008-04-14 at 14:27 +0200, Vincent van Scherpenseel wrote:
 William A. Rowe, Jr. wrote:
  For those unaware, there are new flood and framework components
  of the httpd-test bugzilla product.
 
 Excellent :) I'm glad flood is regaining attention. It's a great tool 
 and I find it a pity that the project isn't that active anymore. The 
 site could use a little updating too: I get 404s for every 
 svn.apache.org/... link. Also, I believe there's no link back to the 
 homepage from the child pages.
 
 Guy Ferraiolo: thank you very much for submitting your patch. It has 
 really been a lifesaver for me. Keep up the good work.
 
 Cheers, Vincent
-- 
Guy Ferraiolo   mailto:[EMAIL PROTECTED]
Performance Measurement  Analysis  http://CNET.com
CNETtel: 1.908.541.3739
1200 Route 22 East  fax: 1.908.575.7474
Bridgewater, NJ 08807   cel: 1.732.618.0250

Re: AuthzMergeRules directive

2008-04-14 Thread Chris Darroch 

Brad Nicholes wrote:


This is where it starts to go wrong for me.  Where it gets confusing
for somebody who is trying to figure out what the configuration
is doing is:

 Directory /www/pages
SatisfyAll
   Require ip 10.10.0.1
   Require ldap-group sales
   SatisfyOne
  Require ldap-group ne-sales
  Require ldap-group sw-sales
   /SatisfyOne
 /SatisfyAll
 /Directory
 
 Directory /www/pages/private

AuthzMergeRules SatisfyOne
SatisfyAll
   Require ldap-group marketing
   Require ldap-group alt-marketing
/SatisfyAll
 /Directory

Now I have to reconcile the logic of the parent with the logic of
both the AuthzMergeRules and the SatisfyAll tag.  Even though it
might not always look like the cleanest configuration, I think it
will be less confusing if the logic rules were confined to
the SatisfyAll and SatisfyOne tags rather than introducing
alternate logic directives.


  I take your point about complexity, but on the other hand,
these aren't alternate logic directives -- they're additional.
The logic specified above for /www/pages/private would be:

( Require ip 10.10.0.1
 
 Require ldap-group sales
 
 ( Require ldap-group ne-sales
   ||
   Require ldap-group sw-sales))
||  - AuthzMergeRules SastifyOne
( Require ldap-group marketing
 
 Require ldap-group alt-marketing)


At least with AuthzMergeRules being ON or OFF, the only thing I need
to know is if I am merging with the parent or not.  All of the
logic rules just flow from there.


  Granted, the above example is complex and maybe non-intuitive,
but most people aren't going to attempt or need such a large set
of authz directives.  For those who really do, there are surely
going to be cases where AND'ing block is useful while OR'ing is
not at all (since OR'ing tends to short-circuit the configurations
deeper down the document tree, which seems unlikely to be what people
will mostly want).

  If you'd like to stick to just Off (my proposed default for
AuthzMergeRules) and On, perhaps AND should be the logic implemented
by On?  Consider the following, where AND'ing helps tighten
security as you go down the tree:

Directory /www/private
   Require ip 10.10.0.1
/Directory
Directory /www/private/sales
   ## must come from 10.10.0.1
   AuthzMergeRules SatisfyAll

   SatisfyAll
   Require ldap-group sales
   SatisfyOne
   Require ldap-group ne-sales
   Require ldap-group sw-sales
   /SatisfyOne
   /SatisfyAll
/Directory
Directory /www/private/sales/admin
   ## must come from 10.10.0.1, belong to sales, and also
   ## belong to one of ne-sales or sw-sales

   AuthzMergeRules SatisfyAll
   SatisfyAll
   Require ldap-group admin
   Require ldap-group sales-admin
   /SatisfyAll
/Directory

  Perhaps others have opinions on this stuff?  Basically my principal
concern is that the default AuthzMergeRules setting must be Off.
Beyond that, I can live any other choices.

  Personally, I'm gradually coming around to the feeling that AND is
more useful/secure than OR when merging per-dir blocks, and possibly
even within a single per-dir block (although that's another conversation),
and so should either be an option to AuthzMergeRules or the action
implemented by On if there are only two states.

  The reason I say it might make sense to AND authz requirements
within a block is that it reads a little more naturally.  Consider
the following, which suggests to me that I need a shirt and shoes
to be served, not one or the other:

Directory /www/service
   Require shirt on
   Require shoes on
/Directory

  At rate rate, thanks for hashing through all my scattershot ideas
on this stuff.

Chris.

--
GPG Key ID: 366A375B
GPG Key Fingerprint: 485E 5041 17E1 E2BB C263  E4DE C8E3 FA36 366A 375B