Re: story posted

On Mon, 10 Feb 2003 11:42:49 -0800, Rasmus Lerdorf wrote: > As for the Apache2+PHP stuff, we are not deflecting blame. We are simply > not acknowledging that it is somehow our duty to drop everything and > support Apache2 just because someone decided it was a good idea to release > a new web serv

Re: cvs commit: httpd-2.0/modules/aaa mod_auth_digest.c

* [EMAIL PROTECTED] wrote: > Do not use local paths for the domain parameter on non-unix systems. > > PR: 16937 The guessing code is somewhat weird anyway. RFC 2617, 3.2.1 writes (about 'domain'): | If this directive is omitted or its value is empty, the client should | assume that the pro

Re: layering mod_auth_digest and mod_python authentication inapache2

--On Monday, February 10, 2003 4:42 PM -0800 Paul Querna <[EMAIL PROTECTED]> wrote: Okay, so now the big question, how long do you think it will be before Apache2.1 is released? 2 Months? 6 Months? 1+ Year(s)? I am willing to code it out for Apache2.1 assuming it will be coming fairly soon, but

Re: layering mod_auth_digest and mod_python authentication in apache2

On Mon, 10 Feb 2003 15:55:21 -0800, Justin Erenkrantz wrote > The easiest thing to do would be to rewrite mod_python's > authentication handler as an auth provider for 2.1. You would want > to make sure that the provider implements the get_realm_hash function. > > That doesn't help for 2.0, but y

Re: layering mod_auth_digest and mod_python authentication inapache2

--On Monday, February 10, 2003 3:39 PM -0800 Paul Querna <[EMAIL PROTECTED]> wrote: What I want is AuthDigest to decode the username, and password, and then to pass this onto my mod_python authenticationn scripts, without having to re-write the entire mod_auth_digest in Python. The easiest thin

layering mod_auth_digest and mod_python authentication in apache2

I am trying to setup mod_auth_digest to work with a mod_python script. What I want is AuthDigest to decode the username, and password, and then to pass this onto my mod_python authenticationn scripts, without having to re-write the entire mod_auth_digest in Python. I have been tyying to use the m

Re: [PATCH] HPUX static's and Mixing C with C++ modules

Just a side note here; although I haven't the faintest idea about the intricacies of dynamic loading on HP-UX, I _do_ know that in some situations, even plain C code needs constructor-like initialization when a shared library is loaded. This leads me to guess that BIND_NOSTART might be bad even for

Re: story posted

> On to a). The PHP developers have screamed quite loudly about the > failings of Apache2, when, in fact, the largest reason why mod_php will > not work with Apache2 is because it is not a priority for PHP developers. Nobody is screaming. > Personally, my servers run PHP as CGI. Works well. Th

Strange Behavior of Apache 2.0.43 on SPARC MP system

Hi All, Sorry I am posting this directly to the development list. But I think this is not a user setup problem and it is so strange maybe only you guys will have a clue on what's going on. I am a student of UW-Madison. In order to study computer architecture of commercial multiprocessor servers,

RE: [PATCH] HPUX static's and Mixing C with C++ modules

I agree with Noah.. Moreover, we've removed the BIND_NOSTART from our version (both 1.3 and 2.x), and not had any problems so far. As regards enabling dlopen instead of shl_load, I think you can do it using a engineered config.cache file, and then giving it to configure.. -Madhu >-Original Me

Re: story posted

* Rasmus Lerdorf wrote: > Do you really think we don't know this? > > The point is that at this point we would basically have to mutex every > call to every 3rd-party library function since we simply don't know which > ones are threadsafe and which ones aren't. And if we lock everything, > isn't

RE: [PATCH] HPUX static's and Mixing C with C++ modules

I understand BIND_NOSTART has been in the code since it was first checked into apache 1.3. I also understand the desire not to break existing functionality. I can tell you that BIND_NOSTART prevents any C++ module developer from being able to take advantage of static initialization. I'd be more tha

Re: story posted

Jeff Trawick asked a well-directed pair of questions: > What I think is useful information to people who want PHP+Apache-2.0 is: > > a) is PHP not production ready with Apache 2.0 because it was not high > enough priority for PHP to be tested? > > or > > b) is PHP not production ready with Apache

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

At 10:27 AM 2/10/2003, [EMAIL PROTECTED] wrote: >trawick 2003/02/10 08:27:28 > > Modified:.CHANGES > server log.c > Log: > Fix an existing problem with error handling in piped_log_spawn(). > > Use new APR apr_proc_create() features to prevent Apache from starti

Re: story posted

Do you really think we don't know this? The point is that at this point we would basically have to mutex every call to every 3rd-party library function since we simply don't know which ones are threadsafe and which ones aren't. And if we lock everything, isn't it simpler to just go prefork and

Re: suexec bug #9977 on sunos4

* Glenn wrote: > On Mon, Feb 10, 2003 at 04:51:38AM +0100, Andr? Malo wrote: >> http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9977 >> >> can someone have a look at it? I can't verify, because I don't have access >> to a sunos4 system :) > > I don't have access to such a system either, but I d

Re: Client fd?

Vinod Panicker wrote: Hi, Anyone knows where the socket pointing to the client is stored in apache 2? In apache 1.3 it was in r->connection->client->fd Tx, Vinod. It's hidden in the apr_socket_t. Use apr_os_sock_get() to retrieve it from the client apr_socket_t. Bill

redirection with Apache module

Hi all,   I'm new in this list but please, could you help me to do a redirection in an Apache module with the request_rec struct. I'm sure that for you, it's very simple!   Thanks in advance, Frédéric Vissault http://www.softandem.com/ [EMAIL PROTECTED]