Re: auth_ldap authentication as user

[Graham Leggett]

Sebastian Tusk wrote:

i had some trouble to bring auth_ldap to work. I solved the problems but 
not to my complete satisfaction. The reason for this is the way 
auth_ldap does the authentication with the ldap server.

Here the sequence of operations auth_ldap does in a default ldap setup. 
In this setup anyone has read access to all data (except passwords) of 
the directory.
Use the AuthLDAPBindDN and AuthLDAPBindPassword directives to solve 
this. Details are in the manual.

Regards,
Graham
--
-
[EMAIL PROTECTED]   "There's a moon
over Bourbon Street
tonight..."

Re: Apache 2.0.44 w/ auth_ldap build errors

[Graham Leggett]

Trevor Hurst wrote:

I'm guessing it's basically broken and does not
work right. Since it's [experimental].
Works great for me.

Have you followed the instructions in 
httpd-2.0/modules/experimental/README.ldap?

mod_auth_ldap.c:82:2: #error mod_auth_ldap requires APR-util to have LDAP
support built in
This tells you that you didn't switch on LDAP support in APR.

Regards,
Graham
--
-
[EMAIL PROTECTED]   "There's a moon
over Bourbon Street
tonight..."

RE: [PATCH] openssl configuration

[MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1)]

I haven't gone through the entire stuff, but some quick questions, based on
your patch :

1. I thought we should not be enforcing openssl version number checks
(something like - openssl version SHOULD be > 0.9.6i) - mainly because ppl.
can apply patches to their previous versions of OpenSSL, and thus avoid
security problems.. (ofcourse, I know you're coming from the OpenSSL
background, but that was the message I got here when I tried doing something
like that)

2. Regarding hardcoding "openssl/some_header_name.h", I think it's a bad
idea - how about ppl. who want to use other SSL toolkits along with apache
?. 

-Madhu

-Original Message-
From: Geoff Thorpe
To: Apache Development List
Sent: 2/26/03 9:18 PM
Subject: [PATCH] openssl configuration

Hi,

I'll be mailing back here at another time about my work on integrating
"distcache" (www.distcache.org) support into Apache 2. I first need to
run a bunch of checks on my autoconf hooks into the Apache 2 build
system though ...

... which leads nicely on to why I *am* posting now. The distcache
exercise put me in direct contact with the openssl checks in apache
(acinclude.m4 + modules/ssl/config.m4), and so I noticed that the code
had been waiting in a very strange state for someone to find time to
sort it out.  so I've been hacking away at it and have attached a
(unified) diff of where I'm at.

This isn't ready for CVS yet, but it needs (now) the input of an apache
hacker to verify a few things and fix an issue to do with how the rest
of the build system is tied together. Also, given some of the weirdness
of the existing code, any "Right Way" of doing things is necessarily
going to be a big enough change that regressions have to be watched for.
Eg. the existing openssl checks just cycle through some preset
commonly-used system paths, and don't use any of the normal autoconf
mechanisms to find or test anything. It's obviously not supposed to be
this way, but I can't guess how disruptive it might be to suddenly
commit a correction to it.

Well I'll leave off by logging some info about the patch contents. Any
and all feedback would most welcome.

Cheers,
Geoff

Patch notes:
- I've left the existing APACHE_CHECK_SSL_TOOLKIT implementation but
  simply renamed it out of the way - this is mainly to make sure the
  diff is nice and clean and not an abomination caused by diffing two
  *almost* entirely different blocks of code against one another.
- All the hard-coded path checking (where on earth did that come from?)
  that was used before is gone and the autoconf macros AC_TRY_COMPILE
  and AC_TRY_LINK are used instead to verify headers and libraries. This
  needs a regression once-over, but can't possibly be a good thing to
  leave the way it was.
- The existing implementation doesn't try any compile or link tests,
  because right now any linking test would fail because the basic system
  library checks hadn't been performed in advance. I've put a FIXME
  there so someone can take a look at the issue - whatever Apache's
  existing library checks are is obviously sufficient, because Apache
  links :-) So it's just a matter of rearranging or reproducing all the
  standard -ldl -lnsl -lsocket [etc] checks to occur before
  APACHE_CHECK_SSL_TOOLKIT runs.
- Relative paths to "--with-ssl" were broken but now work. Before they
  would pass the configure checks if the paths were valid relative to
  the top-level directory, but would then fail (not surprisingly) when
  compiling inside modules/ssl/. Linking was also broken for the same
  reason.
- A path supplied to "--with-ssl" might (before) have been overriden by
  another linker path containing openssl libraries and yet silently
  succeeded. This can lead to mismatches between headers and libraries
  (with all the obvious linker or run-time problems that can lead to),
  and also has the failing that it succeeds whilst contradicting what
  was asked for. This can be pretty painful if there are important
  reasons why --with-ssl was specifying a specific build.
- --with-ssl supports both installation bases (where include and lib are
  subdirectories) as well as compiled openssl source trees (just the lib
  subdirectory). I think this was the case before too, but because of
  the other items mentioned, this now actually works.
- "openssl version" isn't used any more, because it requires that the
  openssl binary be installed. More accurate (and much easier) version
  checking is possible from openssl's "opensslv.h" header, and this has
  the added advantage that RPM type systems only need the
  "libopenssl***" package installed rather than the utils as well.
- The version check is less fragile (no regexp string games) and has
  been bumped to 0.9.6i from 0.9.6e because of the recent SSL/TLS
  vulnerability.
- openssl headers are now included with the "openssl/" directory prefix.
- modules/ssl/config.m4 no longer needs to check SSL_set_state and
  SSL_set_cert_store functions - the only possible use for these was
  b

[PATCH] openssl configuration

[Geoff Thorpe]

Hi,

I'll be mailing back here at another time about my work on integrating
"distcache" (www.distcache.org) support into Apache 2. I first need to
run a bunch of checks on my autoconf hooks into the Apache 2 build
system though ...

... which leads nicely on to why I *am* posting now. The distcache
exercise put me in direct contact with the openssl checks in apache
(acinclude.m4 + modules/ssl/config.m4), and so I noticed that the code
had been waiting in a very strange state for someone to find time to
sort it out.  so I've been hacking away at it and have attached a
(unified) diff of where I'm at.

This isn't ready for CVS yet, but it needs (now) the input of an apache
hacker to verify a few things and fix an issue to do with how the rest
of the build system is tied together. Also, given some of the weirdness
of the existing code, any "Right Way" of doing things is necessarily
going to be a big enough change that regressions have to be watched for.
Eg. the existing openssl checks just cycle through some preset
commonly-used system paths, and don't use any of the normal autoconf
mechanisms to find or test anything. It's obviously not supposed to be
this way, but I can't guess how disruptive it might be to suddenly
commit a correction to it.

Well I'll leave off by logging some info about the patch contents. Any
and all feedback would most welcome.

Cheers,
Geoff

Patch notes:
- I've left the existing APACHE_CHECK_SSL_TOOLKIT implementation but
  simply renamed it out of the way - this is mainly to make sure the
  diff is nice and clean and not an abomination caused by diffing two
  *almost* entirely different blocks of code against one another.
- All the hard-coded path checking (where on earth did that come from?)
  that was used before is gone and the autoconf macros AC_TRY_COMPILE
  and AC_TRY_LINK are used instead to verify headers and libraries. This
  needs a regression once-over, but can't possibly be a good thing to
  leave the way it was.
- The existing implementation doesn't try any compile or link tests,
  because right now any linking test would fail because the basic system
  library checks hadn't been performed in advance. I've put a FIXME
  there so someone can take a look at the issue - whatever Apache's
  existing library checks are is obviously sufficient, because Apache
  links :-) So it's just a matter of rearranging or reproducing all the
  standard -ldl -lnsl -lsocket [etc] checks to occur before
  APACHE_CHECK_SSL_TOOLKIT runs.
- Relative paths to "--with-ssl" were broken but now work. Before they
  would pass the configure checks if the paths were valid relative to
  the top-level directory, but would then fail (not surprisingly) when
  compiling inside modules/ssl/. Linking was also broken for the same
  reason.
- A path supplied to "--with-ssl" might (before) have been overriden by
  another linker path containing openssl libraries and yet silently
  succeeded. This can lead to mismatches between headers and libraries
  (with all the obvious linker or run-time problems that can lead to),
  and also has the failing that it succeeds whilst contradicting what
  was asked for. This can be pretty painful if there are important
  reasons why --with-ssl was specifying a specific build.
- --with-ssl supports both installation bases (where include and lib are
  subdirectories) as well as compiled openssl source trees (just the lib
  subdirectory). I think this was the case before too, but because of
  the other items mentioned, this now actually works.
- "openssl version" isn't used any more, because it requires that the
  openssl binary be installed. More accurate (and much easier) version
  checking is possible from openssl's "opensslv.h" header, and this has
  the added advantage that RPM type systems only need the
  "libopenssl***" package installed rather than the utils as well.
- The version check is less fragile (no regexp string games) and has
  been bumped to 0.9.6i from 0.9.6e because of the recent SSL/TLS
  vulnerability.
- openssl headers are now included with the "openssl/" directory prefix.
- modules/ssl/config.m4 no longer needs to check SSL_set_state and
  SSL_set_cert_store functions - the only possible use for these was
  because nothing up until that point had run any compiler or link tests
  on the guesses made by configure. That's now changed so these checks
  are pointless.

-- 
Geoff Thorpe
[EMAIL PROTECTED]
http://www.geoffthorpe.net/

Index: acinclude.m4
===
RCS file: /home/cvspublic/httpd-2.0/acinclude.m4,v
retrieving revision 1.136
diff -u -r1.136 acinclude.m4
--- acinclude.m417 Feb 2003 02:32:19 -  1.136
+++ acinclude.m427 Feb 2003 05:14:01 -
@@ -312,7 +312,7 @@
 ])
 
 dnl
-dnl APACHE_CHECK_SSL_TOOLKIT
+dnl APACHE_CHECK_SSL_TOOLKIT (old version)
 dnl
 dnl Find the openssl toolkit installation and check it for the right
 dnl version, then add its flags to INCLUDES and LIBS

Re: cvs commit: httpd-2.0 CHANGES

[Justin Erenkrantz]

--On Wednesday, February 26, 2003 7:55 PM -0800 Greg Stein 
<[EMAIL PROTECTED]> wrote:

And remember: this *is* source control. If somebody commits a bug
fix and people want to shoot it down, then we can revert it. But
assuming correctness and committing the fix is hella better than
gating every single little change.
We have lazy consensus on the unstable tree (2.1).  I agree with you 
100% in the context of httpd-2.1 - go commit first - break the tree - 
we can revert changes easily as we have no expectations of stability 
there.

But, I don't trust anyone's 'common sense' to know whether the most 
trivial fix broke anything or whether a bug fix is 'right.'  Yes, it 
means gating changes on stable (2.0), but that's a price I'm willing 
to see us pay.  I'd hope our code quality and stability improves 
because of that.  -- justin

Re: cvs commit: httpd-2.0 CHANGES

[Greg Stein]

On Wed, Feb 26, 2003 at 05:10:12PM -0800, Justin Erenkrantz wrote:
> --On Thursday, February 27, 2003 12:02 PM +1100 Stas Bekman 
> <[EMAIL PROTECTED]> wrote:
> 
> > So if absolutely anything added to the dev branch must have a vote
> > for before merging back to the stable branch, I stand corrected and
> > will make sure that this won't happen again in the future. I
> > thought that the common sense should be applied when judging what
> > can be backported without the vote.
> 
> Heh.  The entire reason for the vote is to prevent 'common sense' 
> from interfering with the stability of the tree.  -- justin

Bah. That's insanity. A bug fix is a bug fix. We never took votes for bug
fixes for 1.3, and I see no reason to start now.

Feature changes? Sure, we voted for those.


Seriously, people. If there is a bug, then it should be fixed no matter
where it lies. Sure, there can be some waffling based on *how* a bug is
fixed, and hopefully people will know when to ask.

What's the problem with fixing a bug. Really?

And remember: this *is* source control. If somebody commits a bug fix and
people want to shoot it down, then we can revert it. But assuming
correctness and committing the fix is hella better than gating every single
little change.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

Re: [PATCH] Move http header parsing into the http_input_filter

[Bill Stoddard]

Justin Erenkrantz wrote:
--On Tuesday, February 25, 2003 8:09 PM -0500 Bill Stoddard 
<[EMAIL PROTECTED]> wrote:

Ok, I know what I was thinking. Check out tmp_bb in ap_read_request
in protocol.c (unpatched version). We create tmp_bb, do
read_request_line, ap_get_mime_headers then destroy tmp_bb.  My
patch does essentially the same thing.  If there is a request body
to read, whoeever needs to read it will create a new brigade. In
this regard, my patch does not create any new bogosity. (and no, we
do not throw away the first read).


No, it's not the same thing.  One is: 'read the request line and headers 
using this temporary brigade,' the other is: 'read part of the input 
body into this brigade - oh, by the way, feel free to read the headers 
and status while you are at it, and, oh, don't feel that I require any 
data.'
No, I think it is the same.  The request body (or the next request in a 
set of pipelined requests) is set aside in the http_input_filter_ctx_t 
in the HTTP_IN filter after the headers are parsed.   The next call to 
ap_get_brigade to fetch the body will fetch any setaside buckets then 
call down into core_in for more bytes as needed.

I probably cannot say this enough... I've not done any work to get the 
code to handle a request body, but AFAIK, it should not be difficult to 
do.

As I've said before, the patch uses ap_get_brigade only as a way to 
drive the input filters before we are ready to read the body.  
Call me dense but the unpatched code in ap_read_request sure appears to 
do the same thing.

> To me, it
indicates a strong disconnect with how the filters are designed. Filters 
are meant to be called asynchronously as needed (pulled), but the 
request parsing must happen synchronously and at a specific point in time.

I don't fully understand why the status and header parsing must belong 
in an input filter (hammer, meet balloon).  I think the patch could be 
rewritten removing the context of an input filter and still see 
significant performance benefits.  At the time the request is read, 
there should be no other input filters, so I don't believe there would 
be significant overhead to not being an input filter.  -- justin
One of the keys behind why this patch improves performance is the 
elimination of the repeat calls to ap_rgetline() to read the header 
fields. ap_rgetline calls ap_get_brigade(AP_MODE_GETLINE) which drived 
multiple trips into the core input filter. The patch enables 
ap_http_filter to make a -single- call to 
ap_get_brigade(AP_MODE_READBYTES) (and a single entry to core_in) and 
works on parsing the header fields out of the returned brigade. So how 
do you solve the problem of ap_get_brigade(AP_MODE_READBYTES) returning 
bytes beyond the header fields?  AFAIK there are two ways to solve this:

1. push the extra bytes back to the core input filter
2. setaside the extra bytes in the ap_http_filter context so that they 
can be fetched later
My patch implements 2) which is essentially the same thing 
core_input_filter does. core_in will issue a bucket read on the socket 
and that read may return request body bytes. If core_in is entered with 
mode AP_MODE_GETLINE, only a single line is returned and the other bytes 
are setaside in the core_input_filter context. My patch just moves that 
setaside function up one level to a protocol level filter.

Bill

Re: cvs commit: httpd-2.0 CHANGES

[Stas Bekman]

[EMAIL PROTECTED] wrote:
wrowe   2003/02/26 11:03:00

  Modified:.CHANGES
  Log:
Brad, Stas, I presume these patches were first committed to 2.1-dev.
Please keep the CHANGES logs in sync!
Duh! Sorry for being a troublemaker. I thought that CHANGES in the dev tree 
includes only CHANGES which weren't backported to the stable tree. At least 
that's what the header says:

  [Remove entries to the current 2.0 section below, when backported]

since I've immediately committed to the stable tree, instead of adding and 
immediately removing, I skipped adding in first place. I suppose the 
add/remove is important for cvs logs, which I've missed to see.

Will do that in the future.

  Revision  ChangesPath
  1.1090+13 -1 httpd-2.0/CHANGES
  
  Index: CHANGES
  ===
  RCS file: /home/cvs/httpd-2.0/CHANGES,v
  retrieving revision 1.1089
  retrieving revision 1.1090
  diff -u -r1.1089 -r1.1090
  --- CHANGES	25 Feb 2003 22:59:56 -	1.1089
  +++ CHANGES	26 Feb 2003 19:02:59 -	1.1090
  @@ -135,9 +135,21 @@
   
   Changes with Apache 2.0.45
   
  +  *) Enhance the behavior of mod_isapi's WriteClient() callback to
  + provide better emulation for isapi modules that presume that the
  + first WriteClient() call may send status and headers.  An example
  + of WriteClient() abuse is the foxisapi module, which relies on
  + that assumpion and now works.  [William Rowe, Milan Kosina]
  +
  +  *) Check the return value of ap_run_pre_connection(). So if the
  + pre_connection phase fails (without setting c->aborted)
  + ap_run_process_connection is not executed. [Stas Bekman]
  +
 *) Fixed a problem with mod_ldap which caused it to fault when caching
was disabled.  Needed to make sure that the code did not
  - attempt to use the cache if it didn't exist. [Brad Nicholes]
  + attempt to use the cache if it didn't exist. Also fixed some memory
  + leaks which were due to not releasing LDAP resources on error
  + conditions.  [Brad Nicholes]

 *) Hook mod_proxy's fixup before mod_rewrite's fixup, so that by
mod_rewrite proxied URLs will not be escaped accidentally by
  
  
  


--

__
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com

Re: Apache 2.0.44 w/ auth_ldap build errors

[Cliff Woolley]

On Wed, 26 Feb 2003, Trevor Hurst wrote:

> 0.9.1 is *very* old? Please let me know where I can find
> a newer version because last I looked (yesterday) on
> apr.apache.org, it shows Sep. 11th, 2002 latest build
> 0.9.1 ? And I'm speaking of what's in the released
> area and not the CVS repositories.

We don't use anything but what's in the CVS repositories.

Well, we're about to tag a new version, but that's irrelevant.  Ignore
0.9.1.

--Cliff

Re: Apache 2.0.44 w/ auth_ldap build errors

[Cliff Woolley]

On Wed, 26 Feb 2003, Trevor Hurst wrote:

> > Because when I run the make I get the following errors:
> >
> > -static -c mod_auth_ldap.c && touch mod_auth_ldap.lo
> > mod_auth_ldap.c:82:2: #error mod_auth_ldap requires APR-util to have LDAP
> > support built in

If you go into the apr-util directory and run ./configure --help, among 
other things it will tell you:

  --with-ldap-include=path  path to ldap include files with trailing slash
  --with-ldap-lib=pathpath to ldap lib file
  --with-ldap=library ldap library to use


Go back to the top-level Apache directory and pass ./configure these 
arguments, and it will pass them through to apr-util for you.

I admit this is not entirely obvious, but it's just the way it is.

--Cliff

Re: Apache 2.0.44 w/ auth_ldap build errors

[Trevor Hurst]

Justin, I've tried pointing both apr and apr-util to the
prefix INSTALL_DIR which is /usr/local/apr. To no avail it
fails with the same errors no matter what. I've also tried
pointing it at my build tree after successful builds of both.

0.9.1 is *very* old? Please let me know where I can find
a newer version because last I looked (yesterday) on
apr.apache.org, it shows Sep. 11th, 2002 latest build
0.9.1 ? And I'm speaking of what's in the released
area and not the CVS repositories.

Thanks for the response.

Cheers,

-- Trev

--
Trevor Hurst
Senior Systems Administrator
DCO Unix Production Systems
Silicon Graphics
Office Ph: 650.933.6144
e-mail: [EMAIL PROTECTED]
pager: [EMAIL PROTECTED]

--
Thus a mind that is free from passion is a very citadel;
man has no stronger fortress in which to seek shelter and
defy every assault. Failure to perceive this is ignorance;
but to perceive it, and still not to seek its refuge, is
misfortune indeed. --Marcus Aurelius

On Wed, 26 Feb 2003, Justin Erenkrantz wrote:

> --On Wednesday, February 26, 2003 5:00 PM -0800 Trevor Hurst
> <[EMAIL PROTECTED]> wrote:
>
> >> -prefer-non-pic -static -c mod_auth_ldap.c && touch
> >> mod_auth_ldap.lo
> >> mod_auth_ldap.c:82:2: #error mod_auth_ldap requires APR-util to
> >> have LDAP support built in
>
> Sounds like you need to specify --with-ldap.  APR-util isn't finding
> your LDAP libraries.  Check the configure output to make sure that
> apr-util found your LDAP library correctly.
>
> >> > the ones bundled with Apache?  I'm not sure that version 0.9.1
> >> > had the APU_BINDIR variable (I'd have to check... Justin would
> >> > probably know).  We're not at the point yet where we have
>
> Probably not.  0.9.1 is *really* old.  -- justin
>

Re: cvs commit: httpd-2.0 CHANGES

[Justin Erenkrantz]

--On Thursday, February 27, 2003 12:02 PM +1100 Stas Bekman 
<[EMAIL PROTECTED]> wrote:

So if absolutely anything added to the dev branch must have a vote
for before merging back to the stable branch, I stand corrected and
will make sure that this won't happen again in the future. I
thought that the common sense should be applied when judging what
can be backported without the vote.
Heh.  The entire reason for the vote is to prevent 'common sense' 
from interfering with the stability of the tree.  -- justin

Re: Apache 2.0.44 w/ auth_ldap build errors

[Justin Erenkrantz]

--On Wednesday, February 26, 2003 5:00 PM -0800 Trevor Hurst 
<[EMAIL PROTECTED]> wrote:

-prefer-non-pic -static -c mod_auth_ldap.c && touch
mod_auth_ldap.lo
mod_auth_ldap.c:82:2: #error mod_auth_ldap requires APR-util to
have LDAP support built in
Sounds like you need to specify --with-ldap.  APR-util isn't finding 
your LDAP libraries.  Check the configure output to make sure that 
apr-util found your LDAP library correctly.

> the ones bundled with Apache?  I'm not sure that version 0.9.1
> had the APU_BINDIR variable (I'd have to check... Justin would
> probably know).  We're not at the point yet where we have
Probably not.  0.9.1 is *really* old.  -- justin

Re: cvs commit: httpd-2.0 CHANGES

[Stas Bekman]

Jeff Trawick wrote:
[EMAIL PROTECTED] wrote:

stas2003/02/25 15:33:55

  Modified:server   Tag: APACHE_2_0_BRANCH connection.c
   .Tag: APACHE_2_0_BRANCH CHANGES
  Log:
  check the return value of ap_run_pre_connection(). So if the
  pre_connection phase fails (without setting c->aborted)
  ap_run_process_connection is not executed.
  Reviewed by:trawick, jim
I don't recall a vote for merging it into the stable branch.
I figured, since it's a segfault bug fix (httpd was segfaulting when 
run_process_connection was run, when pre_connection has failed) it's an 
obvious 'must go into the stable branch' (making it more stable). My patch 
hasn't introduced a new API or broken anything, other than doing something 
that should have been done in first place: checking the return value of the call.

So if absolutely anything added to the dev branch must have a vote for before 
merging back to the stable branch, I stand corrected and will make sure that 
this won't happen again in the future. I thought that the common sense should 
be applied when judging what can be backported without the vote.

__
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com

Re: Apache 2.0.44 w/ auth_ldap build errors

[Trevor Hurst]

I'm guessing it's basically broken and does not
work right. Since it's [experimental].

I've tried everything... no luck here man.

Please let me know if I'm doing anything wrong.

Thanks for your response, greatly appreciated.

-- Trev

On Wed, 26 Feb 2003, Trevor Hurst wrote:

>
>
> Because when I run the make I get the following errors:
>
> make[3]: Entering directory
> `/usr/people/trev/src/httpd-2.0.44/modules/experimental'
> /bin/sh /usr/people/trev/src/httpd-2.0.44/srclib/apr/libtool --silent
> --mode=compile gcc  -g -O2-D_POSIX_THREAD_SAFE_FUNCTIONS
> -DAP_HAVE_DESIGNATED_INITIALIZER
> -I/usr/people/trev/src/httpd-2.0.44/srclib/apr/include
> -I/usr/people/trev/src/httpd-2.0.44/srclib/apr-util/include
> -I/usr/local/include -I. -I/usr/people/trev/src/httpd-2.0.44/os/unix
> -I/usr/people/trev/src/httpd-2.0.44/server/mpm/prefork
> -I/usr/people/trev/src/httpd-2.0.44/modules/http
> -I/usr/people/trev/src/httpd-2.0.44/modules/filters
> -I/usr/people/trev/src/httpd-2.0.44/modules/proxy
> -I/usr/people/trev/src/httpd-2.0.44/include
> -I/usr/freeware/lib/openssl/include/openssl
> -I/usr/freeware/lib/openssl/include
> -I/usr/people/trev/src/httpd-2.0.44/modules/dav/main -prefer-non-pic
> -static -c mod_auth_ldap.c && touch mod_auth_ldap.lo
> mod_auth_ldap.c:82:2: #error mod_auth_ldap requires APR-util to have LDAP
> support built in
> mod_auth_ldap.c:104: parse error before "deref_options"
> mod_auth_ldap.c:104: warning: no semicolon at end of struct or union
> mod_auth_ldap.c:120: parse error before '}' token
> mod_auth_ldap.c:120: warning: data definition has no type or storage class
> mod_auth_ldap.c:139: parse error before "mod_auth_ldap_config_t"
> mod_auth_ldap.c:168: parse error before "mod_auth_ldap_config_t"
> mod_auth_ldap.c: In function `mod_auth_ldap_build_filter':
> mod_auth_ldap.c:175: `filtbuf' undeclared (first use in this function)
> mod_auth_ldap.c:175: (Each undeclared identifier is reported only once
> mod_auth_ldap.c:175: for each function it appears in.)
>
>
> Is there another place I should point the --with-apr-util option
> inside the apache-2.0.44 tree??
>
> Thanks,
>
> -- Trev
>
> On
> Wed, 26 Feb
> 2003,
> Cliff Woolley wrote:
>
> > On Wed, 26 Feb 2003, Trevor Hurst wrote:
> >
> > > No one wants to take a stab at this eh?
> > > I know there must be someone out there
> > > amongst the dev community that would know what
> > > the problem is?
> > > >
> > > > I've built and installed both apr 0.9.1 and apr-util 0.9.1.
> >
> > Why did you build and install apr and apr-util rather than using the ones
> > bundled with Apache?  I'm not sure that version 0.9.1 had the APU_BINDIR
> > variable (I'd have to check... Justin would probably know).  We're not at
> > the point yet where we have declared a particular version number of apr
> > and apr-util to work with Apache 2.0.44 (or any other 2.0.x release) other
> > than the one bundled with it.
> >
> > --Cliff
> >
> >
>

Re: [PATCH] Move http header parsing into thehttp_input_filter

[Justin Erenkrantz]

--On Tuesday, February 25, 2003 8:09 PM -0500 Bill Stoddard 
<[EMAIL PROTECTED]> wrote:

Ok, I know what I was thinking. Check out tmp_bb in ap_read_request
in protocol.c (unpatched version). We create tmp_bb, do
read_request_line, ap_get_mime_headers then destroy tmp_bb.  My
patch does essentially the same thing.  If there is a request body
to read, whoeever needs to read it will create a new brigade. In
this regard, my patch does not create any new bogosity. (and no, we
do not throw away the first read).
No, it's not the same thing.  One is: 'read the request line and 
headers using this temporary brigade,' the other is: 'read part of 
the input body into this brigade - oh, by the way, feel free to read 
the headers and status while you are at it, and, oh, don't feel that 
I require any data.'

As I've said before, the patch uses ap_get_brigade only as a way to 
drive the input filters before we are ready to read the body.  To me, 
it indicates a strong disconnect with how the filters are designed. 
Filters are meant to be called asynchronously as needed (pulled), but 
the request parsing must happen synchronously and at a specific point 
in time.

I don't fully understand why the status and header parsing must 
belong in an input filter (hammer, meet balloon).  I think the patch 
could be rewritten removing the context of an input filter and still 
see significant performance benefits.  At the time the request is 
read, there should be no other input filters, so I don't believe 
there would be significant overhead to not being an input filter.  -- 
justin

Re: Apache 2.0.44 w/ auth_ldap build errors

[Trevor Hurst]

Because when I run the make I get the following errors:

make[3]: Entering directory
`/usr/people/trev/src/httpd-2.0.44/modules/experimental'
/bin/sh /usr/people/trev/src/httpd-2.0.44/srclib/apr/libtool --silent
--mode=compile gcc  -g -O2-D_POSIX_THREAD_SAFE_FUNCTIONS
-DAP_HAVE_DESIGNATED_INITIALIZER
-I/usr/people/trev/src/httpd-2.0.44/srclib/apr/include
-I/usr/people/trev/src/httpd-2.0.44/srclib/apr-util/include
-I/usr/local/include -I. -I/usr/people/trev/src/httpd-2.0.44/os/unix
-I/usr/people/trev/src/httpd-2.0.44/server/mpm/prefork
-I/usr/people/trev/src/httpd-2.0.44/modules/http
-I/usr/people/trev/src/httpd-2.0.44/modules/filters
-I/usr/people/trev/src/httpd-2.0.44/modules/proxy
-I/usr/people/trev/src/httpd-2.0.44/include
-I/usr/freeware/lib/openssl/include/openssl
-I/usr/freeware/lib/openssl/include
-I/usr/people/trev/src/httpd-2.0.44/modules/dav/main -prefer-non-pic
-static -c mod_auth_ldap.c && touch mod_auth_ldap.lo
mod_auth_ldap.c:82:2: #error mod_auth_ldap requires APR-util to have LDAP
support built in
mod_auth_ldap.c:104: parse error before "deref_options"
mod_auth_ldap.c:104: warning: no semicolon at end of struct or union
mod_auth_ldap.c:120: parse error before '}' token
mod_auth_ldap.c:120: warning: data definition has no type or storage class
mod_auth_ldap.c:139: parse error before "mod_auth_ldap_config_t"
mod_auth_ldap.c:168: parse error before "mod_auth_ldap_config_t"
mod_auth_ldap.c: In function `mod_auth_ldap_build_filter':
mod_auth_ldap.c:175: `filtbuf' undeclared (first use in this function)
mod_auth_ldap.c:175: (Each undeclared identifier is reported only once
mod_auth_ldap.c:175: for each function it appears in.)


Is there another place I should point the --with-apr-util option
inside the apache-2.0.44 tree??

Thanks,

-- Trev

On
Wed, 26 Feb
2003,
Cliff Woolley wrote:

> On Wed, 26 Feb 2003, Trevor Hurst wrote:
>
> > No one wants to take a stab at this eh?
> > I know there must be someone out there
> > amongst the dev community that would know what
> > the problem is?
> > >
> > > I've built and installed both apr 0.9.1 and apr-util 0.9.1.
>
> Why did you build and install apr and apr-util rather than using the ones
> bundled with Apache?  I'm not sure that version 0.9.1 had the APU_BINDIR
> variable (I'd have to check... Justin would probably know).  We're not at
> the point yet where we have declared a particular version number of apr
> and apr-util to work with Apache 2.0.44 (or any other 2.0.x release) other
> than the one bundled with it.
>
> --Cliff
>
>

Re: minor MMN bump for 2.0

[William A. Rowe, Jr.]

At 05:07 PM 2/26/2003, Greg Ames wrote:

>Sure.  A handler which does its own apr_file_open looses the ability to use sendfile.

Who cares?  That's an APR implementation-dependent detail that you
(the module/app author) has minimal control over.

Bill 

Re: minor MMN bump for 2.0

[William A. Rowe, Jr.]

At 04:02 PM 2/26/2003, Greg Ames wrote:
>I'd like to do a minor MMN bump in the 2.0 stable tree to account for the 
>apr_file_open interface changing via the addition of APR_ENABLE_SENDFILE.  It's not a 
>huge deal unless you're a 3rd party module with a handler that needs all the 
>performance it can get, ala mod_specweb99.  I'm not too concerned about the 2.1 tree; 
>we can just piggyback on to one of the other recent MMN changes there.
>
>Q. Shouldn't this really be a major bump?
>A. Strictly speaking, yes.  But that would cause more headaches than it would solve.
>
>Can I get some votes on this, please?

It's absolutely not a major bump - that is - modules with or without the flags
still *work*.  We aren't breaking modules.

Now if you flipped the bit definition that would be a bigger problem - but we
already agreed that wouldn't happen - another flag would gain another new
bit.

In fact, I can't say that I see one reason to actually apply the bump.  Running
a module with the flag, on apr built at any point won't "break" the module.

And APR isn't Apache.  We shouldn't be bumping Apache, in any case, for
this change.  This is a change to APR (and I regularly cross two different APR 
and Apache versions for the best performance or the greatest reliability.)

So I'd say no, no bump.  We are about to tag 0.9.2 (or is that 0.9.3) in the next
24 hours to create a candidate.  That APR version 0.9.2 (-gold) will tell you that 
your apr_file_open supports the new semantics.

The hassle is that we've been using 0.9.2-dev and there is no way to distinguish
the 'version' of apr between -dev and -gold.  So I'm tempted to make this 0.9.3
and continue development on 0.9.3-dev till we are ready to call it 0.9.4.

But that discussion is off-topic here ... snipping that bit for the apr list 
to continue the discussion there.

Bill

Re: Apache 2.0.44 w/ auth_ldap build errors

[Cliff Woolley]

On Wed, 26 Feb 2003, Trevor Hurst wrote:

> No one wants to take a stab at this eh?
> I know there must be someone out there
> amongst the dev community that would know what
> the problem is?
> >
> > I've built and installed both apr 0.9.1 and apr-util 0.9.1.

Why did you build and install apr and apr-util rather than using the ones 
bundled with Apache?  I'm not sure that version 0.9.1 had the APU_BINDIR 
variable (I'd have to check... Justin would probably know).  We're not at 
the point yet where we have declared a particular version number of apr 
and apr-util to work with Apache 2.0.44 (or any other 2.0.x release) other 
than the one bundled with it.

--Cliff

Re: minor MMN bump for 2.0

[Jeff Trawick]

Greg Ames wrote:

Jeff Trawick wrote:

> Regardless of a bump, it seems like the app is going to have to do
>
> #ifdef APR_ENABLE_SENDFILE
> add in the flag
> #endif
>
> unless they don't care what happens if they build it with 2.0.44.
hey, that solves the whole thing, in both of the trees simultaneously!
OK, we don't need a bump.
I was thinking of:

#if AP_MODULE_MAGIC_AT_LEAST(whatever)
  add in the flag
#endif


well, that's probably the cool way but it is too late to work properly 
(i.e., deal with 2.0.44)

Re: Apache 2.0.44 w/ auth_ldap build errors

[Trevor Hurst]

No one wants to take a stab at this eh?
I know there must be someone out there
amongst the dev community that would know what
the problem is?

-- Trev

--
Trevor Hurst
Senior Systems Administrator
DCO Unix Production Systems
Silicon Graphics
Office Ph: 650.933.6144
e-mail: [EMAIL PROTECTED]
pager: [EMAIL PROTECTED]

--
Thus a mind that is free from passion is a very citadel;
man has no stronger fortress in which to seek shelter and
defy every assault. Failure to perceive this is ignorance;
but to perceive it, and still not to seek its refuge, is
misfortune indeed. --Marcus Aurelius

On Wed, 26 Feb 2003, Trevor Hurst wrote:

>
> Hello,
>
> First off, I like to say that I've posted to the users
> list prior to this with not a single reply...
>
> I am trying to build Apache 2.0.44 w/ auth_ldap support
> on IRIX 6.5.19. I've successfully built without the ldap
> and with many options such as SSL with few problems.
>
> I've built and installed both apr 0.9.1 and apr-util 0.9.1.
>
> I've done _everything_ under the sun to get this to pass the
> configure stage without error, but to no avail!
>
> Here's my configure parameters:
>
> ./configure --enable-auth-ldap --with-apr-util=../apr-util
> --enable-mime-magic --enable-ssl --enable-static-rotatelogs --enable-so
> --with-ssl=/usr/freeware/lib/openssl
>
> And here are the errors I'm receiving, is it not knowing how to use
> the apu-config correctly? Notice the sed errors:
>
> creating test/Makefile
> config.status: creating docs/conf/httpd-std.conf
> sed: command garbled: s,@APU_BINDIR@,Usage: apu-config [OPTION]
> config.status: creating include/ap_config_layout.h
> sed: command garbled: s,@APU_BINDIR@,Usage: apu-config [OPTION]
> config.status: creating support/apxs
> sed: command garbled: s,@APU_BINDIR@,Usage: apu-config [OPTION]
> config.status: creating support/apachectl
> sed: command garbled: s,@APU_BINDIR@,Usage: apu-config [OPTION]
> config.status: creating support/dbmmanage
> sed: command garbled: s,@APU_BINDIR@,Usage: apu-config [OPTION]
> config.status: creating support/envvars-std
> sed: command garbled: s,@APU_BINDIR@,Usage: apu-config [OPTION]
> config.status: creating support/log_server_status
> sed: command garbled: s,@APU_BINDIR@,Usage: apu-config [OPTION]
> config.status: creating support/logresolve.pl
> sed: command garbled: s,@APU_BINDIR@,Usage: apu-config [OPTION]
> config.status: creating support/phf_abuse_log.cgi
> sed: command garbled: s,@APU_BINDIR@,Usage: apu-config [OPTION]
> config.status: creating support/split-logfile
> sed: command garbled: s,@APU_BINDIR@,Usage: apu-config [OPTION]
> config.status: creating build/rules.mk
> sed: command garbled: s,@APU_BINDIR@,Usage: apu-config [OPTION]
> config.status: creating include/ap_config_auto.h
> config.status: include/ap_config_auto.h is unchanged
> config.status: executing default commands
>
>
> Thanks in advance for any tips.
>
> -- Trev
>
>
>

Re: minor MMN bump for 2.0

[Greg Ames]

Jeff Trawick wrote:

Regardless of a bump, it seems like the app is going to have to do

#ifdef APR_ENABLE_SENDFILE
add in the flag
#endif
unless they don't care what happens if they build it with 2.0.44.
hey, that solves the whole thing, in both of the trees simultaneously!  OK, we 
don't need a bump.

I was thinking of:

#if AP_MODULE_MAGIC_AT_LEAST(whatever)
  add in the flag
#endif
u da man!

Greg

mod_logio won't be compiled with 'most'

[Astrid Keßler]

I looked at the status of some modules and found, that mod_logio won't
compile with 'most' modules (configure --enable-modules=most). Are there
any reason for?

 Kess

E-Mail: [EMAIL PROTECTED]

Re: minor MMN bump for 2.0

[Greg Ames]

Bill Stoddard wrote:
Greg Ames wrote:

I'd like to do a minor MMN bump in the 2.0 stable tree to account for 
the apr_file_open interface changing via the addition of 
APR_ENABLE_SENDFILE.  It's not a huge deal unless you're a 3rd party 
module with a handler that needs all the performance it can get, ala 
mod_specweb99.  I'm not too concerned about the 2.1 tree; we can just 
piggyback on to one of the other recent MMN changes there.

Q. Shouldn't this really be a major bump?
A. Strictly speaking, yes.  But that would cause more headaches than 
it would solve.


Why should this be a major bump?  Is there any possible use of the API 
in 2.0.44 that would now be broken?
Sure.  A handler which does its own apr_file_open looses the ability to use 
sendfile.

Greg

auth_ldap authentication as user

[Sebastian Tusk]

Hi there,

i had some trouble to bring auth_ldap to work. I solved the problems but 
not to my complete satisfaction. The reason for this is the way 
auth_ldap does the authentication with the ldap server.

Here the sequence of operations auth_ldap does in a default ldap setup. 
In this setup anyone has read access to all data (except passwords) of 
the directory.

OperationBound As	Access

open connection to ldap server  --  --
bind as admin (dn and password provided by conf)
admin   read/write
start authentication of user "name1"  admin   read/write
search for user "name1"   admin   read/write
bind as name1 (dn provided by search operation, password by user)
name1   read
end authentication of user "name1"name1   read
start authentication of user "name2"  name1   read
search for user "name2"   name1   read
bind as name2 (dn provided by search operation, password by user)
name2   read
end authentication of user "name2"name2   read
.
.
.
In my setup only the ldap admin has read access to the data in the 
directories. Nobody else has read access rights to the data. That works 
with pam and samba but not with auth_ldap. Here the sequence with the 
altered setup.

OperationBound As	Access

open connection to ldap server  --  --
bind as admin (dn and password provided by conf)
admin   read/write
start authentication of user "name1"  admin   read/write
search for user "name1"   admin   read/write
bind as name1 (dn provided by search operation, password by user)
name1   --
end authentication of user "name1"name1   --
start authentication of user "name2"  name1   --
search for user "name2"   name1   --
Because of the missing access rights to the data the search fails and 
returns everytime zero results.

I think a solution would be to bind as admin before doing the search. As 
workaround i give read access to authenticated users.

Sebastian

Re: minor MMN bump for 2.0

[Jeff Trawick]

Greg Ames wrote:

I'd like to do a minor MMN bump in the 2.0 stable tree to account for
the apr_file_open interface changing via the addition of
APR_ENABLE_SENDFILE. 


Regardless of a bump, it seems like the app is going to have to do

#ifdef APR_ENABLE_SENDFILE
add in the flag
#endif
unless they don't care what happens if they build it with 2.0.44.

Re: minor MMN bump for 2.0

[Bill Stoddard]

Greg Ames wrote:
I'd like to do a minor MMN bump in the 2.0 stable tree to account for 
the apr_file_open interface changing via the addition of 
APR_ENABLE_SENDFILE.  It's not a huge deal unless you're a 3rd party 
module with a handler that needs all the performance it can get, ala 
mod_specweb99.  I'm not too concerned about the 2.1 tree; we can just 
piggyback on to one of the other recent MMN changes there.

Q. Shouldn't this really be a major bump?
A. Strictly speaking, yes.  But that would cause more headaches than it 
would solve.
Why should this be a major bump?  Is there any possible use of the API 
in 2.0.44 that would now be broken?

Bill

ap_start_restart() isnt exported any more?

[Günter Knauf]

Hi,
found ap_start_restart() in the in Apache 1.3 headers, so I had the idea to make a 
small module for doing a restart from a webpage. I know I know, 1001 other possible 
ways to do that, first of all with a cgi script; but these are all 
platform-dependant...
so I deleted a module from mod_example together, tested it on Win32 and works fine so 
far...
compiled NetWare and Linux, and surprise: there happens nothing! Brad then told me 
that ap_start_restart() was never implemented on other platforms than Win32...
So looking forward I just tried to do it with 2.1-dev now, but next suprise: 
ap_start_restart() dispeared completely from the headers. Found that it's still in 
worker.c, so my question:
isnt it possible that ap_start_restart() is exported again, and - if not supported by 
the platform - simply do nothing, as 1.3 did?

Guenter.
  

minor MMN bump for 2.0

[Greg Ames]

I'd like to do a minor MMN bump in the 2.0 stable tree to account for the 
apr_file_open interface changing via the addition of APR_ENABLE_SENDFILE.  It's 
not a huge deal unless you're a 3rd party module with a handler that needs all 
the performance it can get, ala mod_specweb99.  I'm not too concerned about the 
2.1 tree; we can just piggyback on to one of the other recent MMN changes there.

Q. Shouldn't this really be a major bump?
A. Strictly speaking, yes.  But that would cause more headaches than it would solve.
Can I get some votes on this, please?

Thanks,
Greg

mod_auth_ldap changes (was: Re: cvs commit: httpd-2.0 CHANGES)

[Brad Nicholes]

The LDAP memory leak fix was added to the 2.1 tree with the SSL changes
that I commited a couple of weeks ago.  Since I had to fix the caching
fault in both trees anyway, I also back ported the memory leak fixes to
the 2.0 tree.  Both trees are in sync as far as the caching fault and
memory leak fixes go.  I would still like to back port the SSL changes
and then propose that mod_auth_ldap be moved out of experimental.

Brad

Brad Nicholes
Senior Software Engineer
Novell, Inc., the leading provider of Net business solutions
http://www.novell.com 

>>> [EMAIL PROTECTED] Wednesday, February 26, 2003 12:03:00 PM >>>
wrowe   2003/02/26 11:03:00

  Modified:.CHANGES
  Log:
Brad, Stas, I presume these patches were first committed to
2.1-dev.
Please keep the CHANGES logs in sync!
  
  Revision  ChangesPath
  1.1090+13 -1 httpd-2.0/CHANGES
  
  Index: CHANGES
  ===
  RCS file: /home/cvs/httpd-2.0/CHANGES,v
  retrieving revision 1.1089
  retrieving revision 1.1090
  diff -u -r1.1089 -r1.1090
  --- CHANGES   25 Feb 2003 22:59:56 -  1.1089
  +++ CHANGES   26 Feb 2003 19:02:59 -  1.1090
  @@ -135,9 +135,21 @@
   
   Changes with Apache 2.0.45
   
  +  *) Enhance the behavior of mod_isapi's WriteClient() callback to
  + provide better emulation for isapi modules that presume that
the
  + first WriteClient() call may send status and headers.  An
example
  + of WriteClient() abuse is the foxisapi module, which relies on
  + that assumpion and now works.  [William Rowe, Milan Kosina]
  +
  +  *) Check the return value of ap_run_pre_connection(). So if the
  + pre_connection phase fails (without setting c->aborted)
  + ap_run_process_connection is not executed. [Stas Bekman]
  +
 *) Fixed a problem with mod_ldap which caused it to fault when
caching
was disabled.  Needed to make sure that the code did not
  - attempt to use the cache if it didn't exist. [Brad Nicholes]
  + attempt to use the cache if it didn't exist. Also fixed some
memory
  + leaks which were due to not releasing LDAP resources on error
  + conditions.  [Brad Nicholes]

 *) Hook mod_proxy's fixup before mod_rewrite's fixup, so that by
mod_rewrite proxied URLs will not be escaped accidentally by
  
  
  

Apache 2.0.44 w/ auth_ldap build errors

[Trevor Hurst]

Hello,

First off, I like to say that I've posted to the users
list prior to this with not a single reply...

I am trying to build Apache 2.0.44 w/ auth_ldap support
on IRIX 6.5.19. I've successfully built without the ldap
and with many options such as SSL with few problems.

I've built and installed both apr 0.9.1 and apr-util 0.9.1.

I've done _everything_ under the sun to get this to pass the
configure stage without error, but to no avail!

Here's my configure parameters:

./configure --enable-auth-ldap --with-apr-util=../apr-util
--enable-mime-magic --enable-ssl --enable-static-rotatelogs --enable-so
--with-ssl=/usr/freeware/lib/openssl

And here are the errors I'm receiving, is it not knowing how to use
the apu-config correctly? Notice the sed errors:

creating test/Makefile
config.status: creating docs/conf/httpd-std.conf
sed: command garbled: s,@APU_BINDIR@,Usage: apu-config [OPTION]
config.status: creating include/ap_config_layout.h
sed: command garbled: s,@APU_BINDIR@,Usage: apu-config [OPTION]
config.status: creating support/apxs
sed: command garbled: s,@APU_BINDIR@,Usage: apu-config [OPTION]
config.status: creating support/apachectl
sed: command garbled: s,@APU_BINDIR@,Usage: apu-config [OPTION]
config.status: creating support/dbmmanage
sed: command garbled: s,@APU_BINDIR@,Usage: apu-config [OPTION]
config.status: creating support/envvars-std
sed: command garbled: s,@APU_BINDIR@,Usage: apu-config [OPTION]
config.status: creating support/log_server_status
sed: command garbled: s,@APU_BINDIR@,Usage: apu-config [OPTION]
config.status: creating support/logresolve.pl
sed: command garbled: s,@APU_BINDIR@,Usage: apu-config [OPTION]
config.status: creating support/phf_abuse_log.cgi
sed: command garbled: s,@APU_BINDIR@,Usage: apu-config [OPTION]
config.status: creating support/split-logfile
sed: command garbled: s,@APU_BINDIR@,Usage: apu-config [OPTION]
config.status: creating build/rules.mk
sed: command garbled: s,@APU_BINDIR@,Usage: apu-config [OPTION]
config.status: creating include/ap_config_auto.h
config.status: include/ap_config_auto.h is unchanged
config.status: executing default commands


Thanks in advance for any tips.

-- Trev

more FrontPage extension idiocy

[Roy T. Fielding]

The patches at  for including
FrontPage support in Apache modify the request_rec to add an
execfilename field in the *middle* of the structure, thus
blowing binary compatibility with all other Apache modules.
Move the execfilename to the end of the request_rec to avoid
the support headache, or just shoot the bastard who installed
the extensions.
Roy

snapshots not deleted

[Günter Knauf]

Hi,
just for info:
have just seen that the automatically generated snapshots are not deleted anymore 
since Feb-03...
if this is wanted just ignore this post...

G.

Re: cvs commit: httpd-2.0/server connection.c

[William A. Rowe, Jr.]

At 03:32 AM 2/26/2003, Greg Stein wrote:
>On Tue, Feb 25, 2003 at 11:25:21PM -, [EMAIL PROTECTED] wrote:
>>...
>>   +++ connection.c25 Feb 2003 23:25:19 -  1.108
>>   @@ -199,10 +199,14 @@
>>
>>AP_CORE_DECLARE(void) ap_process_connection(conn_rec *c, void *csd)
>>{
>>   +apr_status_t rc;
>>ap_update_vhost_given_ip(c);
>>
>>   -ap_run_pre_connection(c, csd);
>>   -
>>   +rc = ap_run_pre_connection(c, csd);
>>   +if (rc != OK && rc != DONE) {
>>   +c->aborted = 1;
>>   +}
>
>OK and DONE are not apr_status_t values. If you're truly returning a status,
>then you simply check for non-zero (or != APR_SUCCESS). If you truly want to
>return OK/DONE types of values, then the type of rc should be "int".
>
>IMO, since you aren't even at HTTP processing at this point, it *should* be
>an apr_status_t, and the OK/DONE types of values don't enter the picture.

They should, ap_run_pre_connection is an Apache hook.  Yes, it returns
an int, so the only change here should be

>>   -apr_status_t rc;
>>   +int rc;

We aren't calling apr_ function here, and hooks always allow OK, DONE,
or (result).

Bill 

Re: cvs commit: httpd-2.0/server connection.c

[Jeff Trawick]

Greg Stein wrote:

On Tue, Feb 25, 2003 at 11:25:21PM -, [EMAIL PROTECTED] wrote:

OK and DONE are not apr_status_t values. If you're truly returning a 
status,
then you simply check for non-zero (or != APR_SUCCESS). If you truly 
want to
return OK/DONE types of values, then the type of rc should be "int".

IMO, since you aren't even at HTTP processing at this point, it 
*should* be
an apr_status_t, and the OK/DONE types of values don't enter the picture.
Just do:


Greg, are you suggesting that Stas change the API for 2.1?  I can't tell 
whether

[a] you don't like the way he implemented the check
[b] you think the original pre_connection declarations were wrong and 
you want him to both change the API as well as implement the error 
checking that he found necessary
[c] something else

PR 9446: substitute conf/srm.conf and conf/access.conf

[André Malo]

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9446

The patch provided there looks reasonable to me. And it's not fixed yet.
Any objections to apply this?

nd
-- 
>>> Muschelflucht-Zusatzeinrichtung.
>> Shell-Escape ist ja noch klar, aber `Zusatzeinrichtung'?
> extension?
Feature.  -- gefunden in de.org.ccc

Re: cvs commit: httpd-2.0 CHANGES

[Jeff Trawick]

[EMAIL PROTECTED] wrote:

stas2003/02/25 15:33:55

  Modified:server   Tag: APACHE_2_0_BRANCH connection.c
   .Tag: APACHE_2_0_BRANCH CHANGES
  Log:
  check the return value of ap_run_pre_connection(). So if the
  pre_connection phase fails (without setting c->aborted)
  ap_run_process_connection is not executed.
  Reviewed by:  trawick, jim


I don't recall a vote for merging it into the stable branch.

Re: cvs commit: httpd-2.0/server connection.c

[Greg Stein]

On Tue, Feb 25, 2003 at 11:25:21PM -, [EMAIL PROTECTED] wrote:
>...
>   +++ connection.c25 Feb 2003 23:25:19 -  1.108
>   @@ -199,10 +199,14 @@
>
>AP_CORE_DECLARE(void) ap_process_connection(conn_rec *c, void *csd)
>{
>   +apr_status_t rc;
>ap_update_vhost_given_ip(c);
>
>   -ap_run_pre_connection(c, csd);
>   -
>   +rc = ap_run_pre_connection(c, csd);
>   +if (rc != OK && rc != DONE) {
>   +c->aborted = 1;
>   +}

OK and DONE are not apr_status_t values. If you're truly returning a status,
then you simply check for non-zero (or != APR_SUCCESS). If you truly want to
return OK/DONE types of values, then the type of rc should be "int".

IMO, since you aren't even at HTTP processing at this point, it *should* be
an apr_status_t, and the OK/DONE types of values don't enter the picture.
Just do:

  if (ap_run_pre_connection(c, csd) != APR_SUCCESS)
  c->aborted = 1;

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/