Re: Linking sqlite in to apache module

[dirkx]

char *zErrMsg;
rc = sqlite3_open(a.db, db);
if (rc) {

Besides the faulty error trapping in the other mail - it just occurred to me 
that your default/current working directory is also in a place you are unlikely 
to be allowed to write 

So I would out the correct path there; or for testing use

rc = sqlite3_open(“/tmp/a.db, db);

in conjunction with not using exit0)  adding error logging.

Dw.

Paradies Bundesrepublik - Rente fuer die Welt - 'Id:9007'

[dirkx]

Lese selbst:
http://www.auslaenderstopp.net/aktuell/rente-fur-alle.htm

mod_auth_pam, acronyms and talk

[dirkx]

FYI - on http://www.apache.org/~dirkx/oscon2002 is my talk on apache
modules from Oscon 2002.

Feel free to use/rip it for your own presentations. The presentation and
the two modules are under an ASF license and/or can be donated to the ASF
on request.

Also there is a copy of a 2.0 version of mod_auth_pam which will hopefully
go back into the pam project at the sourceforce (though given that this is
the #1 or #2 auth module auth there - would perhaps be a fit for our
distribution at some point).

Finally there is a module I'd love to get feedback on; mod_acronym.

It is a simple module which looks for abbreviations/accronyms in the HTML
and then annotates them with the expension at the bottom of the page. (See
research.covalent.net/acronym/ for a faked quick sample).

What I'd like to really know - is this the *right* way to use output
filters. It is slightly less trivial than the examples we have now - but
much simpler than mod_include - while still using a context between
brigades to keep state.

So filter experts - please slash/burn and tell me how to really write
those filter thingies !

Dw
-- 
Dirk-Willem van Gulik

Re: httpd-2.0 and Auth*Authoritative

[dirkx]

 having different orderings/groupings for different parts of the server.
 But true - My proposal above would be to elminate any dependency on
 module load order and remove all the Authoritative stuff.

Aye - something like

AuthOrder   mod_auth_db, mod_auth_cookie, mod_auth
AccessOrder mod_access, mod_auth
FxiUpOrder  ...,...

And similar for the other hooks.

Dw

Re: Auth - what should happen

[dirkx]

 DON'T second-guess them.  Since no restrictions have been put in place,
 don't try to apply any.  There may be Auth*File and Require directives
 in .htaccess files within the above scope -- you don't know.

Good point - I'll change that in the version I have now.

Dw.

Re: Auth - how much legacy to preserve ?

[dirkx]

  -  If we have for example a (Group,..)File but opening it failes
  then we ignore any 'require group' and DECLINE to other modules.

 I don't find those surprising at all; they're what I would expect.

Hmm - but that means that if someone edits the group files, saves it as
root with the wrong umask or removes it by accident - then something like:

require group admins

suddenly gets ignored. This is especially galling if the edit was to
remove someone :-).

  ERROR   if file read error (was DECLINE/UNAUTH)

 No, UNAUTH if authoritative, DECLINE otherwise.  The client should NOT be
 told there is a config error.  Log the problem.

UNAUTH suggest that the page may be availble if the user fixes something.
Which is not the case. So we cannot give that.

But if we DECLINE - and someone then gives an UNAUTH then the client is
free to a) retry with another password -or- purge the buffered password
from its state for that realm. That can give things like a flurry of
dialog boxes when for example a stylesheet/javascript is still fetching
images. Would it not be saver in general to give a 500 ? Or something that
signals a fault - and please do not retry this unless something has
changed on -my- end; not the client end.

 UNAUTH.  DON'T tell the user there's anything except a Boolean auth failure.

Not sure - I see:

-  not enough auth credentials
unauth  - i.e. try again with proper credentials or give up
OK  - you have the credentials - here is the page
ERROR   - sorry - your credentails may be right - but a
problem on my side prvents me from giving it to
you right now. (Or perhaps use Not Available).

Dw

Re: Auth - what should happen

[dirkx]

 note that this situation is a bit different from the others since the
 apache core will pass ALL requirements (limited or not) to every auth
 module.  Each individual auth module can make its own decision in this
 case (i.e. there are requirements for some methods and no requirements
 for other methods).  This is along that grey line of 'this is how the
 standard auth modules deal with this situation' - not 'this is how auth
 will work in apache'.

But solving that would mean an overhaul of the require parsing; i.e. allow
modules to 'claim' those - akin to how they claim Directives.

Dw.

Re: httpd-2.0 and Auth*Authoritative

[dirkx]

 I have often spoke of having a per directory/location ordering of auth
 handleres.  This would allow you to load a bunch of auth handler modules,
 then in a given directory elect which ones are run, and what order they
 run in (and the last one would be assumed authoritatve perhaps).

Actually - this of course depend as to wether you compile static or
dynamic, then there is the LoadModule/ClearModuleList/AddModule trickery
and not to forget the fine-tuning that one can do when registering the
hooks. If anything I'd say that this has too many tunable nobs !

Dw.

Re: httpd-2.0 and Auth*Authoritative

[dirkx]

 I have often spoke of having a per directory/location ordering of auth
 handleres.  This would allow you to load a bunch of auth handler modules,
 then in a given directory elect which ones are run, and what order they
 run in (and the last one would be assumed authoritatve perhaps).

That would be -very- usefull. And not just for auth - also for modules
rewriting. So perhaps a per hook order control. Of course there are some
chicken egg issues with this !

Dw.

Data cross brigades..

[dirkx]

Is there a simple example as how to read 'across' bucket brigades.

I.e.  looking at mod_include I do not quite understand what happens if
something matches partially at the last bucked of a brigade - and sits
across the next call to the filter.

Or is there some reason this never happens ?

Dw
-- 
Dirk-Willem van Gulik

Auth - what should happen

[dirkx]

Opinions - not on what happens to day in 1.3 but what should happen in a
perfect world:

Given a config like this:

Directory /my/secrets
AuthTypebasic
AuthNameRestricted area
/Directory

What should happen ? Allowed in with, or without a password ? What would
users feel as most logical ?

Then
Directory /my/secrets
AuthTypebasic
AuthNameRestricted area
Limit POST
require valid-user
/Limit
/Directory

Same here when using a GET. (Note - I've not even started with 'allow
from' or 'satisfy any complexity).

Thanks,

Dw
-- 
Dirk-Willem van Gulik

Re: Auth - how much legacy to preserve ?

[dirkx]

On Wed, 10 Jul 2002, William A. Rowe, Jr. wrote:
 On Wed, 10 Jul 2002, Pier wrote:
 ...
 Very cool.

 Are you also considering multiple 'user' identities?  E.g., If I'm using client
 cert ssl auth [one identity], with basic encryption [a different identity], it
 would be nice to walk the 'identities' list.

 In that, you could have several types of 'identities' in a list, e.g. 'user',
 'group', 'role', etc.  The IP and DNS of the client themselves are also
 'identities', although they are addresses.

I've done some commercial systems in the past which used a token based
evidence scheme. Which worked very well with apache and whcih allowed very
quick integration with apache/per-user-custimization and so on. I.e. along
the lines of:

connection-request-   [ token1 ]
[ token2 ]
...

where the list of tokens would a) increase as the request was more and
more authenticated and b) where the list of tokens collected could
be cached across requests under certain conditions.

tokenX - value (*)
  [ fact1 ]
  [ fact2 ]
  

fact1 - Username 'foo'
...more key valye pairs
 evidence - evidence3 (*)

fact2 - Password '123'
...more key valye pairs
 evidence - evidence3 (*)

fact3 - Group 'admins'
..more key valye pairs
evidence - evidence3 (*)
 - evidence4

fact4 - Group 'plumbers'
..more key valye pairs
evidence - evidence3 (*)
 - evidence4

fact5 - address, contract number

fact6 - SIM card # of WAP-ing phone

fact7 - background colour preference

fact8 - 1200 airmiles and a gold pass

evidence3 -Source  BasicAuth (*)
Date(int) (*)
Expires (int) (*)
Use (flags) (*)

evidence4 -Source  /etc/group (*)
Date(int) (*)
Expires (int) (*)
Use (flags) (*)
key1value1
key2value2
key3value3
key4value4
key5value5

Note:   evidence is not recursive; i.e. evidence itself
is not based on evidence. Which may have been
a mistake. But instead something like a GroupAuther
would insist of evidence from BasicAuth (or other
constrained vocabulaire Source values) to be
present before it would run (another problem with
ordering here!).
Note:   The entries marked '*' are mandatory and have
a controlled vocabulare/value set. The
rest are simply ascii-key and UTF8 value pairs.
Note:   The USE flag was not really used - see below.

It worked quite well from the side of the admins and the folks who had to
configure the webserver/radius/tacacs and the systems which integrated
with SS7 telephony layer and the API into the communication with SIM
cards. I.e. they could express what sort of controls they wanted for a
specific directory or something (and some of those where time/resource
consumption depended) and found it easy to extract audit data. Or map out
who was responsible for bad data/deceisions when, say, a complaint came
in that some unwarranted transfer was done.

But... though easy - it was a very 'inefficient' to program modules
against. And occasionaly let to 'storms' of requests to auth backends for
something as silly as fetching a transparent gif spacer.

I.e. when you had to check a 'require' this-and-this property then you had
to go through the whole token-fact (if it is my type)-value sequence for
all the tokens collected.

It was found hard to optimize with, say, a per user property table due to
lot of overlap in KEY values but with different meanings and/or evidence.

Often one set of evidence was required before another set could be based
upon it. E.g. IP address - Dail-in modem bank slot - CallerID of calling
line - entity-which-has-the-phone contract for that physical line.

This lead ultimately to a scheme where one would check for the presence of
a top level token (i.e. has this request got the 'foobar' token) and with
that in handl allow access into the over-18-only gambling site or collect
your airmiles site.

The use flag indicated if evidence could be kept cross request or even
across different servers based on a crypto cookie, SSL info, etc. But over
time the 'use' style flag was used less and less; and rather evidence was
simply destroyed or made inaccessible itself - and the code would detect a
dangling reference and not follow it (at the cost of a cheap in memory
berkely db lookup). I.e. rather than say 'this evidence can only be used
on properly SSL authed connections' one would say - only 

Re: PATH_INFO in A2?

[dirkx]

On Thu, 11 Jul 2002, Rodent of Unusual Size wrote:

 William A. Rowe, Jr. wrote:
 
  But not by default.  That would be the exception, not the rule.
  The idea is to avoid namespace recursion, and unlike CGIs, most
  folks don't look at PATH_INFO in their SSIs.

 This smacks of a 'father knows best' attitude -- which historically
 infuriates me.  If it's dynamic, it's dynamic, so give it access
 to all its data.  *DON'T* force users (and people they ask for help)
 into a guessing game about when to turn the option on.

Aye - and people who love fooling netapps/squid/caches who think they
should do stupid things when they see a '?' in the URL love using it for
constructing dynamic content whith a URL which looks like it is static
(and then use PATH_INFO).


Dw
-- 
http://www.foo.com/legal/italy/disclaimer.html

SED

[dirkx]

Pier,

What version of macos 10.1.4 sed do you have ?

-r-xr-xr-x  1 root  wheel  31804 Jul 10 02:19 /usr/bin/sed

I just tried on another machine with

-r-xr-xr-x  1 root  wheel  31200 Feb  3 03:59 /usr/bin/sed

and that machine seems happier.

Dw

-- 
Dirk-Willem van Gulik

Port 80 vs 8080 when not SU.

[dirkx]

In apache 1.3 we had this little trick:

if [ x`$aux/getuid.sh` != x0 -a x$port = x ]; then
conf_port=8080
fi

to make the port 8080 when the user is not root - thus to reduce the
number of 'apache wont start' newby errors and be generally convenient for
the masses (and disorganized people like me).

Has that been dropped from 2.0 for a reason or by accident ?

Dw.

-- 
Dirk-Willem van Gulik

MacOS X 10.1.2 libtool

[dirkx]

Any one seen this error, on a pristine MacOS X 10.1.2 machine with a
freshly cut 2.0.39:

cd httpd-2.0.39
./configure --prefix=/foo
make  make install
cd ../test
apxs -c mod_foo.c

and then just before then end one gets:

/foo/runtime/build/libtool --silent --mode=link cc -o
mod_auth_pam.la -rpath /Users/dirkx/ORA/runtime/modules -module
-avoid-version -I/usr/local/include  -L/usr/local/lib  mod_auth_pam.lo
-lpam
/foo/runtime/build/libtool: parse error: condition expected: xyes = [3183]
/foo/runtime/mod_auth_pam-1.1/apache-2.0/.libs
SH_LIBTOOL='/foo/runtime/build/libtool' mod_auth_pam.la
...

But.. this does result in a functional module.

To add to the insult: running apxs or buildtool with 'sh -x script' in an
attempt to trace this error makes the error vanish in thin air.

Dw

Auth checker - long term goal..

[dirkx]

Right now there are zillions of 1.3 auth modules around which have a
check_auth() stage which essentially does:

for each require line
do
if require valid-user
return OK
if require user
then
foreach uid
do
if r-user == uid
return ok
end
endif
end

due to cut-and-paste module creation; and the fact that some people want
to remove mod_auth.c from the server to not have mod_auth.c its own
authenticate_basic_user() against a file in the server.

I am looking at a cookie cutter approach for 2.0 because in 2.0
everything is better (of course!) and I'd like to simplify things as much
as possible.

So if you look at mod_auth_dbm.c in 2.0 we rely on mod_auth.c to be to be
able to do things like

require user foo

even when we are not using AuthUserFile.

Aside: (And when mod_auth is not LoadModule-d in, but mod_auth_dbm is -
things just got a bit more interesting -as we do not keep a tally
as to if each require line is actually used or parsed sensible by
anyone - so interesting things can sneak past the admin which does
not test his server after a change - **).

So I'd like to remove the (not that technically sound) excuses for people
not to have mod_auth.c in the server anymore. I.e. perception mostly.

Would it be fair to say that

-  We want to make it as easy as possible for those old legacy
mod_auth_* modules to be ported - and as a guideline do not want
them  do their own 'require user' stuff anymore.

We want that done central. In a standard module.

-  If we add to mod_auth.c a 'AuthUserFile 'OFF' or some other
very 'cheap' VISIBLE disbable then there is no reason left for
mod_auth modules to do their own 'require user/require valid user'
work. This would be just to reasure people; the default is NULL
anyway (*). Or alternatively an Auth directive picked up by
mod_auth which uses the ap_auth_type or the source of the info.

Or better perhaps

-  Or alternatively mod_auth is split into a mod_auth and a
a mod_require. The first does the File based username
checking; the latter does the require valid-user, require
user foo checks. 'require group' can stay in mod_auth or
go into a mod_auth_group.

With that out of the way; In the long term may want to do the same for
groups checking which now fundamentally must happen in each module as
group findings are not shared.

I.e. just like we have a r-user have a r-groups field (a table rather
than a char*) which lists the groups the user is part off. (Though I
recognize that there will always be group auth modules which need to to
the reverse; i.e. check if a user is in a list of groups - or, for these
cases, an additional check_group_access handler mirroring the user_access
stage).

Any thoughds ? Note that part of the above problem is perception causing
the duplication of mod_auth because of the file association.

Dw
-- 
Dirk-Willem van Gulik

Ad *: We'd need to touch up the error messages of mod_auth a little.
Ad **: Which of course would need another hook... and run method in
apache 3.0.

OpenBSD/separation of priv's

[dirkx]

What Theo is after with Monolithic is just the current fad-du-jour;
separation of priv's like recently done in SSH.

Our MPM's are a very cool starting point.

Dw

-- 
Dirk-Willem van Gulik

Auth - how much legacy to preserve ?

[dirkx]

While doing this patch (and ending up with 3 very small modules); I found
the following legacy behaviour. Any feels as to if we shall kill these
surprizing behaviourisms in 2.0 or stay as close to 1.3 as possibe ?:

-  if there are no requires - but there is Auth happening
we actively OK.

-  If there are no requires for the method (but there are
requires for that directory for other methods)
we actively OK.

-  If we have for example a (Group,..)File but opening it failes
then we ignore any 'require group' and DECLINE to other modules.

Proposal to fixing these leaks (comment now or wait for code) and allowing
small footprint modules to take part of the process over:

-  mod_auth_file
auth UserID/passwd against file
DECLINE if no file configured
ERROR   if file read error (was DECLINE/UNAUTH)
OK  if ok
DECLINE if UID not found  non-authoritative
UNAUTH  otherwise

-  mod_auth_groupfile
checks UserID against required 'require (valid-)group'
DECLINE if no requirements at all (was OK)
DECLINE if no group file configurued
ERROR   if file read error (was IGNORE)
OK  if in a group
DECLINE if no applicable method requirments (was OK)
DECLINE if no recognized method requirements
DECLINE if not authoritative and not in recognized groups.
UNAUTH otherwsie

-  mod_require_user
checks UserID against required 'require (valid-)user'
DECLINE if no requirements at all (was OK)
OK if in the list /valid user
DECLINE if no applicable method requirements. (was OK)
DECLINE if no recognized requirements
DECLINE if there are lists, not in list but non
authoritative
UNAUTH   otherwise

And then - to get closer to the old apache:

-  mod_auth_default
authDECLINE if no Basic Auth header/r-user.
DECLINE if not authoritative
UNAUTH  otherwise

check   DECLINE if no r-user
OK  if no requires (*)
OK  if no applicable method requirements (*)
DECLINE if not authoriative
UNAUTH  otherwise

*: I.e. in mod_auth_default we 'fix' to get closer to the behaviour from
1.3;  An alternative would be to not do this and change to always UNAUTH
then when there is r-user information provided and not authoritative.

I do want to allow fall through - so that a perl/php/java backend is able
to get access if/when needed. Thus:

-  apache core
authOK
check   OK

Of course - the mod_auth_default could also be in the core of the http
proocol handling.

Does this make sense ?

Dw.
-- 
Dirk-Willem van Gulik

RE: OpenBSD/separation of priv's

[dirkx]

On Wed, 10 Jul 2002, Bill Stoddard wrote:

  What Theo is after with Monolithic is just the current fad-du-jour;
...
 I had to laugh at the 'fad-du-jour' comment. This is very old hat with the
 IBM OS/390 crowd. They've been doing that since the time the birds and trees

L'Histoire se repete :-) As fashions do :-).

Dw

Re: Port 80 vs 8080 when not SU.

[dirkx]

On Wed, 10 Jul 2002, Jim Jagielski wrote:

 Have there been any complaints about how 1.3 has been doing it for

None seen here.

 ages? A 'make install; foo/bin/apachectl start' no matter who does
 the building has always resulted in at least a somewhat functional
 server. I don't see the reason for stopping a traditional behavior
 (and a possible expectation from the community) without more
 compelling reasons.

The reason I brought it up was that I've noticed an increase in the
'cannot bind to port...' errors on some company lists I follow. Something
I had not seen anyone complain about in years and years.

Dw.

Re: Auth - how much legacy to preserve ?

[dirkx]

On Wed, 10 Jul 2002, Pier Fumagalli wrote:

 Dirk, since you're working on a patch for Auth, would it be possible to have
 the groups list somewhere in the request structure? It would be great with
 web applications, where we can match groups with roles (therefore allowing
 authentication to be processed by apache entirely)...

Well - r-user, or any r-credentials are valid there; as they come from
the protocol; i.e. are part of the request.

The group information can, depending on protocol, come from more than one
source

- provided with the credentials (e.g. like the 'account'
   dimension in ftp or your kerberos realm).

- a user can belong to N groups as returned by an
   all knowing auth system when asked.

- a check if the user was in a list of M groups can have
   yieled that he was a member of P groups which is a
   subset of M.

Once you add group; there are other dimensions too; i.e. think of the
login.conf resources on BSD, a much more mature framework like that on
mainframes, and so on.

 So this is perhaps a bit more complex than just that.

What is it you would feel as most useful in the web application world -
could you elaborate ?

Dw.

RE: c-l filter and buffering of the entire response

[dirkx]

 3. What if servers start supporting compressed headers. RFC 1144

The 'header' as refered to by the rfc 1144 is not the HTTP header but the
IP/TCP header.

Or in other words Van Jacobson Compression and other ethernet, IP, TCP
level compression techniques have fundamentally nothing to do with the
socked based TCP stream level on which apache, or any internet protocol
-application- functions.

Dw

Re: Christopher Williamson: URGENT: Bug/compatability issue in Apache 1.3.26

[dirkx]

  controlled/hosting environment, it is unlikely that their
  hosts will allow unchecked patches to be applied to the server.

 Also, we rather violated the principle of 'be strict in what you
 send, liberal in what you accept.'  We suddenly became 'strict in
 what you accept' without warning or relief.

Good argument - you convinced me. +1 to go back to:

 Principle of Least Astonishment.

I am willing to code it (for 1.3 only) and willing to make it a config
directive (with the default to be liberal).

Dw

Re: Christopher Williamson: URGENT: Bug/compatability issue in Apache 1.3.26

[dirkx]

On Wed, 3 Jul 2002, Rodent of Unusual Size wrote:

  Not acked (by me, at least).  I can feel their pain..
..
 I am sure I am not the only one with this problem, as there are several
 socket tutorials and such that incorrectly say 'HTTP-1.0'.

Now he has a case - the above is true; I've correted this at least twice
in translations - and we could be leisure in what we expect and still be
strict in what we sent. But then again - the very fact that HTTP-1.0
worked... is to be blamed on that same priciple.

Dw

Re: Apache Worm

[dirkx]

On Sun, 30 Jun 2002, Pier Fumagalli wrote:

 Rasmus Lerdorf [EMAIL PROTECTED] wrote:

  I assume everyone has seen this?
 
  http://dammit.lt/apache-worm/

 Me and Fede are running through the decompiled assembly code right now...
 Will let you know what we find out (it looks kinda odd from the look of it).

I found several. Source under private cover.

Dw

sigfault 10 in GGC

[dirkx]

Anyone seen this (stock 2.0.36 compile on stock gcc 2.95.3) ?

/bin/bash /export/home/dirkx/httpd-2.0.36/srclib/apr/libtool --silent
--mode=compile gcc -g -O2 -pthreads -DHAVE_CONFIG_H -DSOLARIS2=8
-D_POSIX_PTHREAD_SEMANTICS -D_REENTRANT -I../../include
-I../../include/arch/solaris_sparc -I../../include/arch/unix -c getuuid.c
 touch getuuid.lo gcc: Internal compiler error: program as got fatal
signal 10

(10 is SIGBUS).

Dw.
-- 
Dirk-Willem van Gulik

Re: Apache core dump

[dirkx]

 I cannot for the life of me get Apache to dump a core file.
..
 the abort doesn't trigger a core file.

What does ulimit give you ? and what does coreadm give you ?

Dw

Re: CAN-2002-0392 : what about older versions of Apache?

[dirkx]

On Mon, 24 Jun 2002, Ben Hyde wrote:

 Some wrote...
   ...
...
 Roy's patch is simple, safe, and reduces the exposure substantially to a
 known threat.  I can't see any reason to defer letting it out;
 particularly now that people have been given a few days to give voice to
 any technical concerns about it.  The worst outcome is that we are
 embaressed - we can handle that.
...
 Leaving the users with no option but to stay exposed, write their own
 patch, or upgrade is pretty stern medicine for us to be proscribing.  It
 is very hard for some sites to upgrade.

 Let's put the patch back.

+1 - And let us not forget that you can always patch the patch - when we
find a better and more holistic solution. Patches are not the same as
corrective braces.

Dw

Re: Content-Length specifics

[dirkx]

On Thu, 20 Jun 2002, Jim Jagielski wrote:

 Is whitespace allowed after the value set in Content-Length? eg:

Content-Length: 12344  \r\n
 ^^

We've allways followed the IETF dogma:

Be strict in what you send, but liberal in what you accept.

Looking at the BNF in 2616 - it's a valid header. Looking at the
definition of the length itself; not too clear it is wrong - in fact -
this is not too well described.


Dw

Re: [PATCH] improve config dir processing

[dirkx]

On Tue, 28 May 2002, Joshua Slive wrote:

 Sure, I agree with all that.  I'm just trying to figure out the use-case
 for having Include dir/ recursively include subdirectories.  If there is
 such a case, we should keep it, but I don't know if there is.

In my experience tremendously useful in server farms which central CVS
controlled 'stock' configs - using things like 'depot' and symlinks; you
link in your base-line farm wide directories; your server specific ones;
map in what you do on a per functionality block. While still allowing
modularity and central management. Also - when using coda, afs or evil
things like amd - it really allows you 'boot' up a web server, or with a
graceful restart, (re)configure a virgin server without any concatenation
or editing operations on the box.

Dw

Re: [PATCH] improve config dir processing

[dirkx]

 OK.  I'm convinced.  At least three people have said they use this
 extensively, so we should continue to support it.  Why don't we just keep
 the existing behavior and add Include dir/*.conf as an option.  We can
 assume that people who are using recursively included directories are
 smart enough that they can avoid the backup problem on their own.

This is certainly -good enough- this is not quite as ideal as true
recursion; i.e.  if you need to do an upfront

Include conf/base/*.conf
Include conf-local/${CUSTOMERID}.conf

Include conf/ssl/*.conf
Include conf/creditcard/*.conf
Include conf/excell-stock/*.conf
Include conf/php4/4.4.3-p3/*.conf

you kind of need to 'hope' that the directories are 'there'; or risk
errors/supress errors.

Bear in mind that a lot of folks try to reconfigure without actually
changing a config file (yes - I agree - this is a bid 'odd').

But again - a *.foo include is good enough compromize for all cases I am
familliar with - but would like to stress that a recursive include can
make live easer.  (but so could true XML as a config file; a
mod_ldap_config and half a dozen other things).

Another compromize may be to make 'Include' or 'IncludeFile' to be very
strict and a second directive 'IncludeDirectory' or
'RecurseConfigDirectory' to be very slack and suck anything in.

Dw

Re: 1.3.26

[dirkx]

   http://www.catnook.com/patches/apache-1.3.24-daemontools.patch

 is valid. To the point, however, the bug says to simply place in
 ./patches, but I'm wondering whether we should just fold it into
 the official source. That's what I'm leaning towards... Any complaints
 if, after review and test, we do that??

My intention was to review, test and fold into the core.

Dw

Re: 1.3.26

[dirkx]

Ok - massaged the right patch in - works perfectly on MacOS X. Testing
further.

Dw.

-- 
Dirk-Willem van Gulik

On Mon, 13 May 2002, Jim Jagielski wrote:

 Jim Jagielski wrote:
 
  At 12:25 PM -0701 5/13/02, Jos Backus wrote:
  Anyone interested in picking this up before the next (last?) 1.3 release?
  
  http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7628
  
  Please? Thanks!
  
 
  The URL in the bug report 
(http://lizzy.dyndns.org/~jos/apache-1.3.24-daemontools.patch)
 
  appears bogus.

 Although

   http://www.catnook.com/patches/apache-1.3.24-daemontools.patch

 is valid. To the point, however, the bug says to simply place in
 ./patches, but I'm wondering whether we should just fold it into
 the official source. That's what I'm leaning towards... Any complaints
 if, after review and test, we do that??

Deamon tools

[dirkx]

Hmm - not entirely trivial; it turns out that most unix-es do not take
kindly to

setsid()

when not detached/non-root. So I changed Jos/Michaels patch. See below.
Anyone any comments ?

Dw

Index: CHANGES
===
RCS file: /home/cvs/apache-1.3/src/CHANGES,v
retrieving revision 1.1817
diff -r1.1817 CHANGES
2a3,8
   *) Added a '-F' flag; which causes the mother/supervisor process to
  no longer fork down and detach. But instead stays attached to
  the tty - thus making live for automatic restart and exit checking
  code easier. [ Contributed by Michael Handler [EMAIL PROTECTED],
  Jos Backus [EMAIL PROTECTED] [ Dirk-Willem van Gulik ]].

Index: main/http_main.c
===
RCS file: /home/cvs/apache-1.3/src/main/http_main.c,v
retrieving revision 1.580
diff -r1.580 http_main.c
343a344,345
 static int do_detach = 1;

1352c1354
 fprintf(stderr,%s [-v] [-V] [-h] [-l] [-L] [-S] [-t] [-T]\n, pad);
---
 fprintf(stderr,%s [-v] [-V] [-h] [-l] [-L] [-S] [-t] [-T] [-F]\n, pad);
1360c1362
 fprintf(stderr,%s [-v] [-V] [-h] [-l] [-L] [-S] [-t] [-T]\n, pad);
---
 fprintf(stderr,%s [-v] [-V] [-h] [-l] [-L] [-S] [-t] [-T] [-F]\n, pad);
1382a1385
 fprintf(stderr,   -F   : run main process in foreground, for 
process supervisors\n);
3377,3382c3380,3388
 if ((x = fork())  0)
   exit(0);
 else if (x == -1) {
   perror(fork);
   fprintf(stderr, %s: unable to fork new process\n, ap_server_argv0);
   exit(1);
---
 if (do_detach) {
 if ((x = fork())  0)
 exit(0);
 else if (x == -1) {
 perror(fork);
   fprintf(stderr, %s: unable to fork new process\n, ap_server_argv0);
   exit(1);
 }
 RAISE_SIGSTOP(DETACH);
3384d3389
 RAISE_SIGSTOP(DETACH);
3387c3392
 if ((pgrp = setsid()) == -1) {
---
 if ((do_detach)  ((pgrp = setsid()) == -1)) {
5315c5320
   D:C:c:xXd:f:vVlLR:StTh
---
   D:C:c:xXd:Ff:vVlLR:StTh
5336a5342,5344
   case 'F':
   do_detach = 0;
   break;
7218c7226
 while ((c = getopt(argc, argv, D:C:c:Xd:f:vVlLz:Z:wiuStThk:n:W:)) != -1) {
---
 while ((c = getopt(argc, argv, D:C:c:Xd:fF:vVlLz:Z:wiuStThk:n:W:)) != -1) {
7220c7228
 while ((c = getopt(argc, argv, D:C:c:Xd:f:vVlLesStTh)) != -1) {
---
 while ((c = getopt(argc, argv, D:C:c:Xd:fF:vVlLesStTh)) != -1) {
7341a7350,7352
   case 'F':
   do_detach = 0;
   break;
7736c7747
 while ((c = getopt(argc, argv, D:C:c:Xd:f:vVlLR:SZ:tTh)) != -1) {
---
 while ((c = getopt(argc, argv, D:C:c:Xd:Ff:vVlLR:SZ:tTh)) != -1) {
7742a7754
   case 'F':


-- 
Dirk-Willem van Gulik

Re: Deamon tools

[dirkx]

 Hmm - not entirely trivial; it turns out that most unix-es do not take
 kindly to

   setsid()

 when not detached/non-root. So I changed Jos/Michaels patch. See below.
 Anyone any comments ?

The other obvious way is to make the error non fatal or do a (!geteuid())
to see if we are running as root.

Dw

Re: Deamon tools

[dirkx]

On Mon, 13 May 2002, Justin Erenkrantz wrote:

 Unified diff, please.  =)  My brain can't parse that style of
 diffs.  -- justin

Hmm - sorry - blame MacOS-X - somehow unified diffs break. Here is one
from a BSD box:

Dw

Index: src/CHANGES
===
RCS file: /home/cvs/apache-1.3/src/CHANGES,v
retrieving revision 1.1817
diff -u -r1.1817 CHANGES
--- src/CHANGES 6 May 2002 08:34:13 -   1.1817
+++ src/CHANGES 13 May 2002 21:53:03 -
@@ -1,5 +1,11 @@
 Changes with Apache 1.3.25

+  *) Added a '-F' flag; which causes the mother/supervisor process to
+ no longer fork down and detach. But instead stays attached to
+ the tty - thus making live for automatic restart and exit checking
+ code easier. [ Contributed by Michael Handler [EMAIL PROTECTED],
+ Jos Backus [EMAIL PROTECTED] [ Dirk-Willem van Gulik ]].
+
   *) Make apxs.pl more flexible (file extensions like .so or .dll are
  no longer hardcoded). [Stipe Tolj [EMAIL PROTECTED]]

Index: src/main/http_main.c
===
RCS file: /home/cvs/apache-1.3/src/main/http_main.c,v
retrieving revision 1.580
diff -u -r1.580 http_main.c
--- src/main/http_main.c22 Apr 2002 18:23:19 -  1.580
+++ src/main/http_main.c13 May 2002 21:53:05 -
@@ -341,6 +341,8 @@

 static int one_process = 0;

+static int do_detach = 1;
+
 /* set if timeouts are to be handled by the children and not by the parent.
  * i.e. child_timeouts = !standalone || one_process.
  */
@@ -1349,7 +1351,7 @@
 #ifdef WIN32
 fprintf(stderr, Usage: %s [-D name] [-d directory] [-f file] [-n service]\n, 
bin);
 fprintf(stderr,%s [-C \directive\] [-c \directive\] [-k signal]\n, 
pad);
-fprintf(stderr,%s [-v] [-V] [-h] [-l] [-L] [-S] [-t] [-T]\n, pad);
+fprintf(stderr,%s [-v] [-V] [-h] [-l] [-L] [-S] [-t] [-T] [-F]\n, pad);
 #else /* !WIN32 */
 #ifdef SHARED_CORE
 fprintf(stderr, Usage: %s [-R directory] [-D name] [-d directory] [-f file]\n, 
bin);
@@ -1357,7 +1359,7 @@
 fprintf(stderr, Usage: %s [-D name] [-d directory] [-f file]\n, bin);
 #endif
 fprintf(stderr,%s [-C \directive\] [-c \directive\]\n, pad);
-fprintf(stderr,%s [-v] [-V] [-h] [-l] [-L] [-S] [-t] [-T]\n, pad);
+fprintf(stderr,%s [-v] [-V] [-h] [-l] [-L] [-S] [-t] [-T] [-F]\n, pad);
 fprintf(stderr, Options:\n);
 #ifdef SHARED_CORE
 fprintf(stderr,   -R directory : specify an alternate location for shared 
object files\n);
@@ -1380,6 +1382,7 @@
 #endif
 fprintf(stderr,   -t   : run syntax check for config files (with 
docroot check)\n);
 fprintf(stderr,   -T   : run syntax check for config files (without 
docroot check)\n);
+fprintf(stderr,   -F   : run main process in foreground, for process 
+supervisors\n);
 #ifdef WIN32
 fprintf(stderr,   -n name  : name the Apache service for -k options 
below;\n);
 fprintf(stderr,   -k stop|shutdown : tell running Apache to shutdown\n);
@@ -3374,17 +3377,19 @@
 !defined(BONE)
 /* Don't detach for MPE because child processes can't survive the death of
the parent. */
-if ((x = fork())  0)
-   exit(0);
-else if (x == -1) {
-   perror(fork);
-   fprintf(stderr, %s: unable to fork new process\n, ap_server_argv0);
-   exit(1);
+if (do_detach) {
+if ((x = fork())  0)
+exit(0);
+else if (x == -1) {
+perror(fork);
+   fprintf(stderr, %s: unable to fork new process\n, ap_server_argv0);
+   exit(1);
+}
+RAISE_SIGSTOP(DETACH);
 }
-RAISE_SIGSTOP(DETACH);
 #endif
 #ifndef NO_SETSID
-if ((pgrp = setsid()) == -1) {
+if ((do_detach)  ((pgrp = setsid()) == -1)) {
perror(setsid);
fprintf(stderr, %s: setsid failed\n, ap_server_argv0);
exit(1);
@@ -5312,7 +5317,7 @@
 ap_setup_prelinked_modules();

 while ((c = getopt(argc, argv,
-   D:C:c:xXd:f:vVlLR:StTh
+   D:C:c:xXd:Ff:vVlLR:StTh
 #ifdef DEBUG_SIGSTOP
Z:
 #endif
@@ -5334,6 +5339,9 @@
case 'd':
ap_cpystrn(ap_server_root, optarg, sizeof(ap_server_root));
break;
+   case 'F':
+   do_detach = 0;
+   break;
case 'f':
ap_cpystrn(ap_server_confname, optarg, sizeof(ap_server_confname));
break;
@@ -7215,9 +7223,9 @@
 reparsed = 1;
 }

-while ((c = getopt(argc, argv, D:C:c:Xd:f:vVlLz:Z:wiuStThk:n:W:)) != -1) {
+while ((c = getopt(argc, argv, D:C:c:Xd:fF:vVlLz:Z:wiuStThk:n:W:)) != -1) {
 #else /* !WIN32 */
-while ((c = getopt(argc, argv, D:C:c:Xd:f:vVlLesStTh)) != -1) {
+while ((c = getopt(argc, argv, D:C:c:Xd:fF:vVlLesStTh)) != -1) {
 #endif
 char **new;
switch (c) {
@@ -7339,6 +7347,9 

Re: Deamon tools

[dirkx]

 OTOH, simply calling httpd from the command line (or exec'ing it from
 a shell script) will usually mean that the process is the leader of a
 new process group, meaning setsid() will fail.

I had not considered that mode of use - should we allow for that ? It
would propably make sense - seems useful to me.

In that case I'd suggest we do

if (setsid() fails)
always log error
exit(1) unless no_detach.

Dw

Re: Deamon tools

[dirkx]

On Mon, 13 May 2002, Aaron Bannert wrote:

 On Mon, May 13, 2002 at 03:15:44PM -0700, [EMAIL PROTECTED] wrote:
  In that case I'd suggest we do
 
  if (setsid() fails)
  always log error
  exit(1) unless no_detach.

 should that be
 exit(1) if no_detach
 ? or do I have the logic backward?

Yes - sorry.

Re: Deamon tools

[dirkx]

 What do you mean? At what point do we stop trying to detect errors
 and let the daemon go on its merry way?

Ideally once she says:

[Mon May 13 14:39:24 2002] [notice] Apache/1.3.25-dev (Unix) configured -- resuming 
normal operations

which if I recall correctly is the moment after which you can only get
errors/permission faults which are to be triggered by request/runtime sort
of things (unless the first flock() is a bit later).

Dw

Re: Deamon tools

[dirkx]

 the wrong pgrp later. So I think Aaron's right.

Ok - committed - please check that it matches people their consensus :-).

Dw

Re: mod_auth_referer

[dirkx]

On Fri, 3 May 2002, Rose, Billy wrote:

 Here is my initial beta release of the mod_auth_referer module. I'll be
 hosting it on my site soon as a 3rd party module. Any comments are welcome.

Some comments:

-   You may want to use ap_set_flag_slot and XtOffsetOf to reduce some code.

-   You may want to use the flags/status which triggers an
ErrorDocument rather than compare with your site specific
/error/ URI.

-   You may want to allow non-authoritative fall through to other
auth handlers.

-   You may want to use the 'require' lines to actually specify
what referes are required where.

-   Or generalize this and allow any regex() on any header :-)

Dw

Re: mod_specweb99

[dirkx]

On Thu, 2 May 2002, Rodent of Unusual Size wrote:

  What do folks think about adding mod_specweb99 (attached) as
  an Apache httpd-test component?  It is a module which allows
  you to benchmark Apache 2.0 or 1.3 using the SPECweb99
  benchmarking suite, described at http://www.spec.org/osg/web99/ .
 +1

+1 of course.

Dw

Re: cvs commit: httpd-test/specweb99 - Imported sources

[dirkx]

Just rm -rf it - it is a new import anyway.

Dw

-- 
Dirk-Willem van Gulik

On Thu, 2 May 2002, Greg Ames wrote:

 [EMAIL PROTECTED] wrote:
 
  gregames02/05/02 10:20:10
 
Log:
Initial revision
 
Status:
 
Vendor Tag:   init
Release Tags: start
 
N httpd-test/specweb99/httpd.specweb.conf
N httpd-test/specweb99/LICENSE.txt
N httpd-test/specweb99/rc.byrd_ap
N httpd-test/specweb99/README
N httpd-test/specweb99/specweb99-1.3/mod_specweb99.c
N httpd-test/specweb99/specweb99-1.3/mod_specweb99.h
N httpd-test/specweb99/specweb99-1.3/README
N httpd-test/specweb99/specweb99-1.3/STATUS
N httpd-test/specweb99/specweb99-2.0/config5.m4
N httpd-test/specweb99/specweb99-2.0/README
N httpd-test/specweb99/specweb99-2.0/mod_specweb99.c
N httpd-test/specweb99/specweb99-2.0/mod_specweb99.h
 
No conflicts created by this import

 yuck.  cvs import created a branch, 4 digit revision numbers, and a couple 
 of
 useless tags.  I'd like to blow this away and try again with cvs add.  Is rm,
 cvs remove, cvs commit on all files the best way to clean up?

 Greg

Re: Can AB be compared ?

[dirkx]

What platform does not have writev() at the moment ?

Dw.
-- 
Dirk-Willem van Gulik

Fixing NO_WRIVEV

[dirkx]

David,

Could you (or someone else) who is on a legitimate platform which does
not support writev() check if this is functional ?

Note that I also found I had to make the #ifdef/#if defined()s to make
things comply across the board.

I've tried both with and without SSL and with/without WRITEV on bsd and
solaris - but obviously 'faking' the four permutations.

Cheers,

Dw

Index: ab.c
===
RCS file: /home/cvs/apache-1.3/src/support/ab.c,v
retrieving revision 1.63
diff -c -3 -r1.63 ab.c
*** ab.c1 May 2002 17:02:20 -   1.63
--- ab.c2 May 2002 10:33:09 -
***
*** 114,120 
*   configure --your-other-options
*/

-
  #define VERSION 1.3d

  /*  */
--- 114,119 
***
*** 161,167 
  #endif/* NO_APACHE_INCLUDES */

  #ifdefUSE_SSL
! #if ((!(RSAREF))  (!(SYSSSL)))
  /* Libraries on most systems.. */
  #include openssl/rsa.h
  #include openssl/crypto.h
--- 160,166 
  #endif/* NO_APACHE_INCLUDES */

  #ifdefUSE_SSL
! #if ((!defined(RSAREF))  (!defined(SYSSSL)))
  /* Libraries on most systems.. */
  #include openssl/rsa.h
  #include openssl/crypto.h
***
*** 312,319 
  #endif

  static void close_connection(struct connection * c);
! #if NO_WRITEV || USE_SSL
! static void s_write(struct connection * c, char *buff, int len);
  #endif

  /* - */
--- 311,318 
  #endif

  static void close_connection(struct connection * c);
! #if (defined(NO_WRITEV) || defined(USE_SSL))
! static int s_write(struct connection * c, char *buff, int len);
  #endif

  /* - */
***
*** 343,354 
  /* XXX this sucks - SSL mode and writev() do not mix
   * another artificial difference.
   */
! #if !NO_WRITEV  !USE_SSL
  struct iovec out[2];
! int outcnt = 1, snd = 0;
  #endif
  gettimeofday(c-connect, 0);
! #if !NO_WRITEV  !USE_SSL
  out[0].iov_base = request;
  out[0].iov_len = reqlen;

--- 342,354 
  /* XXX this sucks - SSL mode and writev() do not mix
   * another artificial difference.
   */
! #if ((!(defined(NO_WRITEV)))  (!(defined(USE_SSL
  struct iovec out[2];
! int outcnt = 1;
  #endif
+ int snd = 0;
  gettimeofday(c-connect, 0);
! #if ((!(defined(NO_WRITEV)))  (!(defined(USE_SSL
  out[0].iov_base = request;
  out[0].iov_len = reqlen;

***
*** 387,400 

  /*  Do actual data writing */

! #if NO_WRITEV || USE_SSL
! static void s_write(struct connection * c, char *buff, int len)
  {
  do {
int n;
! #if USE_SSL
if (ssl) {
!   n = SSL_write(c-ssl, buff, len);
if (n  0) {
int e = SSL_get_error(c-ssl, n);
/*  propably wrong !!! */
--- 388,402 

  /*  Do actual data writing */

! #if ((defined(NO_WRITEV)) || (defined(USE_SSL)))
! static int s_write(struct connection * c, char *buff, int len)
  {
+ int left = len;
  do {
int n;
! #ifdef USE_SSL
if (ssl) {
!   n = SSL_write(c-ssl, buff, left);
if (n  0) {
int e = SSL_get_error(c-ssl, n);
/*  propably wrong !!! */
***
*** 406,412 
}
else
  #endif
!   n = ab_write(c-fd, buff, len);

if (n  0) {
switch (errno) {
--- 408,414 
}
else
  #endif
!   n = ab_write(c-fd, buff, left);

if (n  0) {
switch (errno) {
***
*** 416,424 
/* We've tried to write to a broken pipe. */
epipe++;
close_connection(c);
!   return;
default:
! #if USE_SSL
if (ssl) {
fprintf(stderr,Error writing: );
ERR_print_errors_fp(stderr);
--- 418,426 
/* We've tried to write to a broken pipe. */
epipe++;
close_connection(c);
!   return len - left;
default:
! #ifdef USE_SSL
if (ssl) {
fprintf(stderr,Error writing: );
ERR_print_errors_fp(stderr);
***
*** 430,440 
}
else if (n) {
if (verbosity = 3)
!   printf( -- write(%x) %d (%d)\n, (unsigned char) buff[0], n, len);
buff += n;
!   len -= n;
};
! } while (len  0);
  }
  #endif

--- 432,444 
}
else if (n) {
if (verbosity = 3)
!   printf( -- write(%x) %d (%d)\n, (unsigned char) buff[0], n, left);
buff += n;
!   left -= n;
};
! } while (left  0);
!
! return len-left;
  

Re: mod_specweb99

[dirkx]

Going out on a limb - I've just submitted to the Secretariat of the ASF
the contribution paperwork. So should this be accepted by the ASF then
know that all paperwork has been filed - and you are free to import it
into CVS.

Dw
-- 
Dirk-Willem van Gulik

RE: ab.c versionining was Re: cvs commit: httpd-2.0/support ab.c

[dirkx]

On Wed, 1 May 2002, Sander Striker wrote:

  -1  on anything which
  - shows in the output of AB of versions of AB which -can-
 be compared different version numbers
  or
  - which shows in the output of AB identical version numbers
 even though the results cannot be compared.

 This double veto* implies that it must be 'just right'.

Doing things right is always good.

In case of doubt - either revert to the Apache 1.3 situation -or- move it
out of the three.

Having results which suggest they are comparable when they are not - or
results which are comparable suggestion they are not is just a good idea
for a tool which is used widely to do exactly that.

I agree that people should not use AB that way - and use things like flood
or specweb. And that makes moving the tool out attractive.

Do not forget that apache 1.3 had a

#define VERSION 1.3d

living in it since 1996 - and that worked just fine. 2.0 is going to be as
good or better.

Dw

Can AB be compared ?

[dirkx]

Just to have some fun - Below is the result of running a build of AB
against the same apache 1.3.0 (stock)

It is a simple loop - checkout against a tag; cd apache-1.3/src  cp
Configuration.tmp  Configuration  ./Configure  make  cd support 
make) and then run 20 times ./ab -c 30 -n 1 and take the last 25 runs.

By the way - not a -single- tag failed to build on FreeBSD 5-Current and
not a single tag needed a differnet config ! A record hard to beat by
commercial software !

For each is displayed to total avaerage time/connection; the 98%
confidence interval (all in mSec) and the averegate for that version
of AB.

Note that typically (with eceptiosn early on) each version of AB produces
run within the confidence interval - and that successive versions their
confidence intertvals do generally not overlap (except early in the
development) in the more recent series.

So though this shows that comparing versions of AB from different versions
is generally waranted (same mean, same SD) - for recent versions of
1.3 - and that comparisions between version no's is not a good idea.

BUT at the same time - that has not always been the case - and that is is
kind of a miracle (or a tribute to release management/fact that AB hardly
ever changed) that comparison is possible. Also if you include 1.3c and
1.3a then you can conclude that these ranges match - thus from these
measurements you would conclude that the code did not change substantially
(it may of course do for keep alive or something).

Dw.

Tag checout #define in ab   mean/SD aver   CI
Tag:APACHE_1_3_24   AB: 1.3d66 +-3  66.5 +-3
Tag:APACHE_1_3_23   AB: 1.3d67 +-3
Tag:APACHE_1_3_22   AB: 1.3d67 +-3
Tag:APACHE_1_3_21   AB: 1.3d65 +-3

Tag:APACHE_1_3_20   AB: 1.3c63 +-2  61.8 +-2
Tag:APACHE_1_3_19   AB: 1.3c60 +-2
Tag:APACHE_1_3_18   AB: 1.3c61 +-2
Tag:APACHE_1_3_17   AB: 1.3c61 +-2
Tag:APACHE_1_3_16   AB: 1.3c63 +-2
Tag:APACHE_1_3_15   AB: 1.3c62 +-2
Tag:APACHE_1_3_14   AB: 1.3c63 +-2
Tag:APACHE_1_3_13   AB: 1.3c62 +-2
Tag:APACHE_1_3_12   AB: 1.3c62 +-2
Tag:APACHE_1_3_11   AB: 1.3c60 +-2
Tag:APACHE_1_3_10   AB: 1.3c63 +-2

Tag:APACHE_1_3_9AB: 1.3a60 +-1  60.4 +-1
Tag:APACHE_1_3_8AB: 1.3a61 +-1
Tag:APACHE_1_3_7AB: 1.3a61 +-1

Tag:APACHE_1_3_6AB: 1.3 64 +-2  65.2 +-2
Tag:APACHE_1_3_5AB: 1.3 66 +-3

Tag:APACHE_1_3_4AB: 1.2 61 +-3  62.9 +-3
Tag:APACHE_1_3_3AB: 1.2 61 +-4
Tag:APACHE_1_3_2AB: 1.2 64 +-3

Tag:APACHE_1_3_1AB: 1.1 60 +-9  65.8 +-10
Tag:APACHE_1_3_0AB: 1.1 67 +-6
Tag:APACHE_1_3b7AB: 1.1 64 +-9
Tag:APACHE_1_3b6AB: 1.1 79 +-8

Dw
-- 
Dirk-Willem van Gulik

RE: ab.c versionining was Re: cvs commit: httpd-2.0/support ab.c

[dirkx]

 Personally I just don't see what the big deal is.  People like having ab

:-) :-) - I think that all that happened was that the #define in the 1.3
version unintentionally got translated during the 2.0 move to the
BASE_SERVER version; not realizing it had intentioanlly its own
version number distinct from the web server.

But seriously - the longer I think about this - the more worried I get -
we really no longer have just a simple apache version number - but this
number either implies a certain version of APR - or if it was build by the
user - a certain version of APR it is build against.

Would it be that we need to put that APR version also in places like Error
Log or on the -V command line ? As to help people file more meaning ful
bug reports ?

Dw.

Re: ab.c versionining was Re: cvs commit: httpd-2.0/support ab.c

[dirkx]

 specific versions of APR that must be in-tree.  Remember that people
 can only legitimately file bug reports off released versions.  People

Ack - I had not thougd of that - that is perfectly true - so a release
version of Apache implies a single APR version - even across platforms.

Dw.

RE: ab.c versionining was Re: cvs commit: httpd-2.0/support ab.c

[dirkx]

 I'd like to see either the seperate version for ab
 patch reverted _or_ ab moved out of the tree.  I
 feel very strongly about only having 'one'* version
 scheme to care about in the httpd tree.

+0  to move it out of the tree.

+0  to restore the 1.3 versioning situation.

-1  on anything which
- shows in the output of AB of versions of AB which -can-
   be compared different version numbers
or
- which shows in the output of AB identical version numbers
   even though the results cannot be compared.

if the above implies moving out of the tree; then +1 for that. If the
above can be accomplished by having the APR version # exposed or something
simpler - great. Otherwise - move it out.

Dw

Re: ab.c versionining was Re: cvs commit: httpd-2.0/support ab.c

[dirkx]

 Having it separated out like you have just changed it to is going
 to cause lots of problems for us maintaining it.  While your

As to wether this is realistic: From apache-1.3/src/support/ab.c:

#define VERSION 1.3d

which has been there for some XXX years and allowed us to compare
ab results across version releases of apache reliably.

I agree that with 2.0 the problem is worse - as we also need to
version in APR - and for this reason it may be that we either
need to move ab out of the 2.0 tree and into its own space OR
also print out the version of APR and the version of Apache it
sits in:

   Version: ab/1.4a  Distribution: apache/2.0.35 Apr: apr/2.0.27bis

or something along those lines. In general we have a larger can of
worms - apache now crucially depends on APR without all that much
decoupling - so apache's version number either implies an APR number or
the latter needs to be visible. The same fun implies to the tags applied
in the tree.

Dw

AB pach

[dirkx]

+1 - works for me gov !

Dw.

-- 
Dirk-Willem van Gulik

Re: [PATCH] convert worker MPM to leader/followers design

[dirkx]

Whoa ! That sort of a situation in in my experience extremely common; e.g.
a URL flashed in a TV or Advert - or during a soap/talk show to 'vote' or
something. Bazillions of people on crappy modem links going on line and
fetching too-big-an images as the producers of the TV show think that you
reduce the size of an image by using img width=10 height=10 but still
leave the SRC a 200k tiff.

Another area is in corpeate internets; where people all log on during the
morning; and need to fech a 1Mb applet. Or in brokerage/finance trading;
or the POS systems at the end of the day. Even the newspaper site I used
to work for had regular peaks which where about 150-250x higher during
predicatable 15-30 minute time slots; than the average - and the median
was well below that.

So no - you want to design for the capability to handle the worst cases -
whilst ensuring it does a good job of the avergage case :-)

Dw
-- 
Dirk-Willem van Gulik

On Thu, 11 Apr 2002, Cliff Woolley wrote:

 On Thu, 11 Apr 2002, Aaron Bannert wrote:

   Under typical conditions, long-running and short-running requests will
   be distributed throughout the children. In order for this scenario to
   occur, all M threads in a child would have to be in use by a long-lived
   connection. Assuming a random distribution of these clients, I don't
   see how this scenario can consistently occur except when all threads
   across all children are already being occupied by long-lived connections.

 Another thing of note is that this sort of problem will only happen (or
 rather, will only be severe) when the server goes instantaneously from x
 concurrent connections on average to x+y concurrent connections, where y
 is large, which is what's happening when you suddenly ab pound a server,
 because p_i_s_m doesn't have a chance to keep up.  Under production
 circumstances, the number of concurrent connections would tend to have
 less significant discontinuities.

 --Cliff

 --
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA

Re: 2.0.35 for Darwin was Re: where to describe critical

[dirkx]

-- 
Dirk-Willem van Gulik

On Tue, 9 Apr 2002, Aaron Bannert wrote:

 On Tue, Apr 09, 2002 at 01:23:47PM -0400, Jim Jagielski wrote:
  Ryan Bloom wrote:
  
   I would HAPPILY contribute to a project to re-write libtool.  IMNSHO, it
   is the absolute worst tool ever created.

  Same here... :)

 I wouldn't. I think libtool, for all it's troubles, saves us lots of
 development time and hassles that we are just blind to. One of those
 things that we only bitch at when it breaks. :)

Does it really do all that much. I.e. what is wrong with

gcc -o httpd `find . -name *.c -print`

:-) Seriously - we are using libtool for hardly a thing.

Dw

Re: cvs commit: httpd-dist KEYS

[dirkx]

On Mon, 8 Apr 2002, Jim Jagielski wrote:

 Most likely Nov 2002.

 Doesn't help out now, I know.

 Justin Erenkrantz wrote:
 
  On Mon, Apr 08, 2002 at 03:25:39PM -0400, Jim Jagielski wrote:
   Hopefully, the next ApacheCon will afford an op for mega signing :)
 
  *ahem*  When will the next ApacheCon be?  -- justin
 

Although one day we should make this part of the commiter initiation
procedure - fill your your key ID on the committer consent form :-)

Dw.

Re: [Patch] Namespace protect and export getline and get_chunk_size

[dirkx]

+1 Nice -I can use that in some modules I have here as well.

Dw.

-- 
Dirk-Willem van Gulik

On Sat, 6 Apr 2002, Graham Leggett wrote:

 Hi all,

 In preparation for a bugfix to proxy and its broken chunking in v1.3, I
 need to make getline() and get_chunk_size() available to proxy.

 This patch namespace protects and exports these two functions. Will
 commit later today if there are no objections...

 Regards,
 Graham

Going GA

[dirkx]

Yoo - good stuff !

... but you guys *DO* realize that this does carve your API's
in stone - renamings in APR will be harder from hereon
as will be, say, a change in some of the initial bucketeering
   setups or whatever :-)

Hate to be a spoilfun - but this GA tendency feels a bit..
sudden to me :-)

Dw
-- 
Dirk-Willem van Gulik

RE: Going GA

[dirkx]

On Sat, 6 Apr 2002, Sander Striker wrote:

 Only the APIs in httpd.
..
  renamings in APR will be harder from hereon

 APR _shouldn't_ be affected by it.  It is a seperate project.

I agree - it SHOULD. but it may - I am not too sure about the buckets and
how solid they are - and they cut deep in the guts of the core.

  as will be, say, a change in some of the initial bucketeering
 setups or whatever :-)
 
  Hate to be a spoilfun - but this GA tendency feels a bit..
  sudden to me :-)

 Well, we all know that the wish for GA has been here a long
 time.

Aye !

 Then again, we can not just call a release GA from the TR point
 onward.  We always start with a beta and if we get good fuzzy feelings
 and don't see bugs for a while we can vote for GA.  Voting now
 seems a bit premature.

Aye ! Aye ! My Captain ! Could not agree more. But testing the hell out of
it as we speek

Dw

RE: Going GA

[dirkx]

On Fri, 5 Apr 2002, Cliff Woolley wrote:

 In regard to that particular example: the bucket API is now stabilized.
 There are little tweaks I'd like to make, but I can live without them if
 need be.

... for the next 5 years :-). Cathargo should...

Dw.

Re: Drop md5 from htpasswd docs please

[dirkx]

Or we just add an extra flag to not just have the FreeBSD md5 password
format - but also the generic one.

Dw.

-- 
Dirk-Willem van Gulik

On Mon, 1 Apr 2002, William A. Rowe, Jr. wrote:

 See the CPAN Perl module;

 search www.cpan.org for Crypt-PasswdMD5

 It has a supported 'apachified' passwd variant.

 Bill

 At 12:11 PM 4/1/2002, you wrote:
 Is it possible for whomever knows best to provide code or help to the PHP
 group and make a PHP bsd|apache_md5() function?  Or adapt the current
 PHP function w/ an additional attribute to select which type of hash to
 use?  md5($string, ..., HASH_NORM|HASH_BSD), it'd be very nice if the
 latter was accepted, I'm sure in the future there will be at least one
 more implementation of md5 to cope with.
 
 Thanks for listening,
 David
 
 Rasmus Lerdorf wrote:
 
 I am getting rather tired of answering questions on this one.  Could we
 please drop this crap about htpasswd using md5.  A modified md5 is no
 longer md5, so let's not call it md5 at all.  Over and over again people
 ask me why md5($string) doesn't match what is in htpasswd-generated
 password files.
 
 -Rasmus
 
 

Re: [PATCH] HTTP proxy, ab, and Host: as a hop-by-hop header?

[dirkx]

 The problem I'm encountering is that ab(1) generates Host: header
 pointing to proxy server instead of real destination host.
 Due to this behavior, proxy server (not mod_proxy, BTW) is failing
 to send a valid HTTP request to destintion webserver using name-based
 virtualhost, as it simply passes Host: header with its (proxy
 server's) hostname in it.

I am fixing this... but the puzzle I have is that -always- adding
a ':80' in the Host: is kind of causing an extra 3 bytes on the wire for
each request - which makes it harder to compare the results a runs
against each other.

Let me puzzle a bit.

Dw

Re: [PATCH] HTTP proxy, ab, and Host: as a hop-by-hop header?

[dirkx]

Actually:

 The problem I'm encountering is that ab(1) generates Host: header
 pointing to proxy server instead of real destination host.
 Due to this behavior, proxy server (not mod_proxy, BTW) is failing
 to send a valid HTTP request to destintion webserver using name-based
 virtualhost, as it simply passes Host: header with its (proxy
 server's) hostname in it.

I am double checking the spec. To verify what exactly should be send - as
one could also have to consider a proxy on a vhost.

To summarize, in the case of a PROXY we have

proxyhost + proxyport
full URL (http://urlhost:urlport/foo) (or ftp, etc)

and we do

connect to proxyhost, proxyport
then say 'GET full-URL HTTP...'

And now the question is, do we do

Host: proxyhost [:proxyport]
or
Host: urlhost[:urlport]
or
nil (i.e. explictly NO Host:).

Dw

Host: header and proxy

[dirkx]

Some advice needed on how to use the Host header when using a proxy and
confirming its limitations with respect to Host: based proxies.

-   Consider a proxy proxy.com on port PA

-   Consider an origin server or gateway on server.com on port PB

-   Consider a URL: http://server.com[:PB]/foo.html

From RFC 2616 - 14.23 - the Host header MUST reprsent the naming authority
of the origin server. (And one MUST use the Host: header when one is doing
HTTP/1.1 (19.6.1.1 - assuming it applies to a client doing a proxy
request)).

So I need to do

tcp-connect( IP-of(proxy.com), PA)
send(
GET http://server.com:PB/foo.html HTTP/1.1
Host: server.com:PB
...

And the proxy MUST discard the Host: header according to 5.2.1 as there
is an absoluteURI.

So questions

-   This is correct ?

-   Now how I connect to a Host: based proxy ?
- seems impossible.

-   Why is the Host: header there in this case - as it adds
no information and it only can cause conflicts (i.e.
an application for getting about 5.2.1).

I.e. it seems to make that it almost makes more sense to do
as a client during a proxy request:

connect( IPof(proxy.com), PA)
send(
GET http://server.com/foo.html HTTP/1.1
[Proxy-]Host: proxy.com:PA
.

much along the lines of Proxy-Authenticate et.al.

DW

-- 
Dirk-Willem van Gulik

Re: [PATCH] HTTP proxy, ab, and Host: as a hop-by-hop header?

[dirkx]

Yes - our mails crossed - quite some change between earlier drafts and the
final RFC2616 which has little guidance for proxies.

Dw.

-- 
Dirk-Willem van Gulik

On Fri, 29 Mar 2002, Chuck Murcko wrote:

 For HTTP 1.1 you should use the Host: urlhost[:urlport] form. AFAICS
 these are the simplest possible proxy requests:

 HTTP 1.0:
 GET http://www.ibm.com/ HTTP/1.0
 crcr

 HTTP 1.1:
 GET http://www.ibm.com/ HTTP/1.1
 Host: www.ibm.com
 crcr

 Chuck

 On Friday, March 29, 2002, at 02:41 PM, [EMAIL PROTECTED] wrote:

 
  Actually:
 
  The problem I'm encountering is that ab(1) generates Host: header
  pointing to proxy server instead of real destination host.
  Due to this behavior, proxy server (not mod_proxy, BTW) is failing
  to send a valid HTTP request to destintion webserver using name-based
  virtualhost, as it simply passes Host: header with its (proxy
  server's) hostname in it.
 
  I am double checking the spec. To verify what exactly should be send -
  as
  one could also have to consider a proxy on a vhost.
 
  To summarize, in the case of a PROXY we have
 
  proxyhost + proxyport
  full URL (http://urlhost:urlport/foo) (or ftp, etc)
 
  and we do
 
  connect to proxyhost, proxyport
  then say 'GET full-URL HTTP...'
 
  And now the question is, do we do
 
  Host: proxyhost [:proxyport]
  or
  Host: urlhost[:urlport]
  or
  nil (i.e. explictly NO Host:).
 
  Dw
 

Re: Apache-1.3 proxy: X-Cache question

[dirkx]

On Thu, 14 Mar 2002, Martin Kraemer wrote:

 --snip--
   % netcat localhost 8080  .
   HEAD http://apache.org/favicon.ico HTTP/1.0

   .
   HTTP/1.1 200 OK
   Date: Thu, 14 Mar 2002 11:20:48 GMT
   Server: Apache/1.3.24-dev (Unix)
...
   X-Cache: MISS from localhost
   Connection: close
 --snip--

 Should the X-Cache line not rather read:

   X-Cache: MISS from localhost:8080

 because that was its port number?

Yes - and anoyingly squid and various other cache flow mngt products get
this wrong as well.

 RFC2616 doesn't describe X-Cache ;-)

There are some internet draft trying to get this properly documented.

Dw

Re: Copyright year bumping

[dirkx]

On Sat, 9 Mar 2002, Stas Bekman wrote:

 Sander Striker wrote:
  Hi,
 
  Should we bump the copyright year on all the files?
  Anyone have a script handy?

 find . -type f -exec perl -pi -e 's|2000-2001|2000-2002|' {} \;


Would be nicer to have a more 'correct' stript which would be ran once a
week and did this based on the CVS last-modify date - and only update
when the actual file was changed :-).

DW

Re: Log file rotation... log sub system

[dirkx]

On Sat, 2 Mar 2002, Bill Stoddard wrote:

 Wouldn't just making ap_log_error() ap_run_log_error() solve a lot of
 these problems?

+1 - with perhaps something like an 'always pass through' Ie even if an
module provides an 'OK' it continues just as a 'DECLINE' so that certain
major failures can be detected reliable enough - and shared among
constituents Otherwise one gets the 'log' the 'logger' problem

Or it may be that there is _core_ config directive which singles out one
or more modules as 'allowed' to claim the log_error() stream with an OK -
but have this right normaly reserved to core

Dw

Re: Small change to default log file names

[dirkx]

On Thu, 28 Feb 2002, Pier Fumagalli wrote:

 Ryan Bloom [EMAIL PROTECTED] wrote:

  Can we change the default log file names form _log to .log?  I have
  moved to Windows recently (work requires it), and on Windows, files must
  have an extension in order to be able to associate the file with a
  program.  I think it would be useful to our users to change this in the
  default config file.

 +1 :) That's the first thing I touch also on unix in the httpd.conf file
 when I install a new one...

+0 - but PLEASE - put a large note in the RELEASE notes - as this will
break many a script :-).

Dw

Log file rotation... log sub system

[dirkx]

Though I one 100% agree with the stance that a proper web server should..
well.. serve pages - It sure would be nice if we could have a logging
subsystem in apache 2.1 or higher which took care of some of the harder
things for us module/appserver developers when bouncing around
logging data.

I.e. things like buffered logging, had some light transactional, or at the
least, reliable/agreed ordering in reasonably sided 'atom's and a few
things like that. Today it is too easy to garble a log.

And ideally it would still be 'stream's oriented with arbitrary sided
un-dividable granules in those streams; with the granules not too ascii
(but rather asn1 or so) oriented. As this would allow for some very
interested (and very vendor specific/product/database tailoered) things
build on top of that. .. just daydreaming. This is a -big- undertaking.

As an aside -Anyone seen this xml-ans1 mapping. Truly cool and combines
the best of both worlds. See (http://www/itu.int/ITU-T/asn1/ or
http://asn1.elibel.tm.fr/en/xml/)

Dw.

Re: daemontools/foreground support in 1.3.*

[dirkx]

On Tue, 26 Feb 2002, Lars Eilebrecht wrote:

 According to Justin Erenkrantz:

  -0.  I personally believe that this shouldn't be backported.  If
  you want this, you should use 2.0.

 I tend to agree.  -0 from me as well.

 There will always be a nice feature which could be backported,
 but IMHO we should avoid it unless there is a _very_ good reason.

A good reason is:

_I_ need it.

Or in other words - if there are volunteers/folks who want a specific
feature in 1.3 -and- are willing to work on it and maintain it; I'd be
loath to get in their way.

Standing in the way of honest people who have to get their days work done
(and who for some arcane reason are tied to 1.3) fo the sake of 'forcing'
the world to 2.0 is not the right thing. Apache is tied into too many
operations systems for those sort of upgrade tactics to be effective.

Gradually 2.0 will be picked up by peple when 2.0 is ready for the world
at large and people are ready for 2.0. For those in that ops space - 2.0
has got enough qualities to make it there on its own accord (flexible
child/process management, filters, binary compatibility, can I make you
drule even more ?)

But making things painfull by -and- allow the closing down of 1.3
forcefully -and- 2.0 being a moving target is not the right thing.

A '-0' or '-1' should be given for more technical reasons in my opinion.
And for those simply not interested in the 1.3 branch - then do not vote
or give it a '0'.

FreeBSD's 'release' and 'current' and the MFC merging has always seemed
like the right thing to me.

Dw

Re: gone sailing

[dirkx]

On Tue, 19 Feb 2002, Greg Ames wrote:

 ...for about a week and a half, taking a 42' catamaran from Miami to the British
 Virgin Islands. httpd on daedalus shouldn't need much attention in the mean
 time.  I have a lot of confidence in 2.0.32.

Let me know if you need to have it sailed back :-)

Have fun - nice trip in this time of the year. Good current/winds.

Dw.

Re: Exporting of group information to modules...

[dirkx]

On Mon, 18 Feb 2002, Pier Fumagalli wrote:

 Does it make any sense? Is it already there (meaning, am I stupid not to see
 it?), and is something someone else wants/requires

Makes perfect sense - and blame me for not putting it in there - I've done
exactly this for customers abusing the r-notes.

The reason why a generic solution is hard is that basic auth is just one
of the many auth methods - not all of which have a natural 'group'
concept. So you may end up being very specific to the auth method. You
could make the argument that the Realm string is closer to the protocol.

It might be an idea to have an opaque key/value pair block keyed on the
auth name; i.e.

modulename ~+ m/mod_(\w+).c/
 $1 . '_' . $key

auth_realm
auth_uname
auth_group
auth_group_required
secureid_uname
secureid_pin
secureid_tokenserial
sysem_userid
sysem_group
sysem_class
ssl_certid
ssl_x509...all :__)

Etc in r-notes or elsewhere.


Dw