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 server. And when attacked repeatedly on this issue we tend to > point out that thread safety issues in commonly used libraries pretty much > nullify any threading gains of the new architecture since we'd have to > mutex them, and also the fact that the filter api's complexity isn't > making life easy for us, nor does the architecture mesh well with how PHP > likes to do things. As a handler under prefork it may work very well. Who > knows. Feel free to apply for a CVS account and write it, but please stop > trying to browbeat us into doing something. I personally have a working > web server that does what I need. Show me something irresistible about > this new server and I will be compelled to work on it myself. > ok. you know have 2 implementations of the handler based php sapi for use with apache2, instead of using the Filter API. www.apache.org/~ianh www.apache.org/~jerenkrantz/apache2handler I don't know PHP's code review process or how to check the code in (I have a CVS account for PHP) my limited testing of the code appears that it works correctly. --Ian > -Rasmus
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 protection space consists of all URIs on the responding | server. And the ABNF says: domain= "domain" "=" <"> URI *( 1*SP URI ) <"> URI = absoluteURI | abs_path so, a) domain _cannot_ be empty. We should omit it entirely if it has no value. right? (I think, it's probably intended, that it can be empty, but who knows the clients?) b) We have to ensure, that (at least the guessed) domain is either an absoluteURI or an abs_path. This is currently not the case. IMHO, we should (1) guess more strictly and throw a 500 with a hint in the error_log to use AuthDigestDomain or (2) require AuthDigestDomain always. I'd prefer the latter for 2.1. Opinions? nd -- Da fällt mir ein, wieso gibt es eigentlich in Unicode kein "i" mit einem Herzchen als Tüpfelchen? Das wär sooo süüss! -- Björn Höhrmann in darw
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 if it is too far off, i will have todo it another way. I'd hope within 3-4 months, but the real answer is, 'whenever it is ready.' I have a feeling we'd be better off with smaller more incremental changes between minor releases. (The aaa code has been there since last August, so I think it is reasonably stable.) I think we definitely have to have the APR situation straightened out before we can even consider a 2.2. Yet, perhaps I will roll a 2.1 release in the next few weeks just to get one out there. At ApacheCon, we discussed a way that we could backport the new aaa modules to 2.0, but I won't have the time to do that. If someone wanted to do that, it'd be goodness. (It wouldn't break backwards compatibility if done carefully.) The only major thing I'd like to see happen before 2.2 (and that I think is reasonable in that timeframe) is getting a handle on the mod_dav memory situation and cleaning up how it uses pools. I know some other people have thoughts for HEAD that they could get in in the next few months. -- justin
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 you can't do this type of layering in > 2.0 anyway. -- justin 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 if it is too far off, i will have todo it another way. -chip
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 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 you can't do this type of layering in 2.0 anyway. -- justin
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 mod_python's PythonAuthenHandler[1] and AuthType Digest in my httpd.conf, but AuthDigest is always rejecting the users/passwords, because I am not using a localfile at all. I thought mod_auth_digest would have somthing simular to mod_auth_ldap's AuthLDAPAuthoritative[2], which can pass authentication onto the next handler, but I don't think that exists for mod_auth_digest Here is the basic plan, the HTTP client, uses Digest authentication to apache, which passes it onto mod_auth_digest, who will NOT find it in a local text file, but instead will pass on the request with the decoded username and password to mod_python's PythonAuthenHandler where i will use my own python scripts to validate the user information. Is what I am trying todo even possible, and if it is, what do i need todo? Thanks, -chip [1] http://www.modpython.org/live/mod_python-3.0.1/doc-html/node54.html [2] http://httpd.apache.org/docs-2.0/mod/mod_auth_ldap.html#authldapauthoritative
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 C, not just C++. Arliss, Noah wrote: >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 than happy to leave that code be if I had a definative way to enable >dlopen instead of shl_load. > >-N > >-Original Message- >From: Joe Orton [mailto:[EMAIL PROTECTED]] >Sent: Saturday, February 08, 2003 5:01 AM >To: [EMAIL PROTECTED]; [EMAIL PROTECTED] >Subject: Re: [PATCH] HPUX static's and Mixing C with C++ modules > > >Hi, > >On Fri, Feb 07, 2003 at 12:23:09PM -0500, Arliss, Noah wrote: > > >>I'll try to clarify things as best I can. First off, BIND_VERBOSE would be >>fantastic. I had to add it in order to get my module to load at all with >>shl_load, even though it still would not function. If there was a good >>reason to remove BIND_VERBOSE that history would be nice to have. The >>shl_load call would look better as: >> >> > >BIND_VERBOSE means the library writes error message to whatever file you >happen to have open as fd 2 - which is unacceptable for a library. (the >app may have closed stderr and be using fd 2 for something completely >different). You get exactly the same error string back via >apr_dso_error() anyway, which is the defined interface for retrieving >the error string. > >Changing the call to: > > > >>+ shl_t os_handle = shl_load(path, BIND_IMMEDIATE, 0L); >> >> > >seems fine to me, FWIW, but as Will says, the BIND_NOSTART has been >there since the code was first checked into Apache 1.3, so there may be >some subtle reason why it's needed. > >Regards, > >joe > > -- Brane Čibej <[EMAIL PROTECTED]> http://www.xbc.nu/brane/
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. Thank you. > Kudos for safe_mode and safe_mode_gid. ?? safe_mode and safe_mode_gid are rather useless when running PHP as a CGI. All you are doing is burning syscalls aimlessly and slowing everything down. If you are running PHP as a CGI anyway, run it under suExec. 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 server. And when attacked repeatedly on this issue we tend to point out that thread safety issues in commonly used libraries pretty much nullify any threading gains of the new architecture since we'd have to mutex them, and also the fact that the filter api's complexity isn't making life easy for us, nor does the architecture mesh well with how PHP likes to do things. As a handler under prefork it may work very well. Who knows. Feel free to apply for a CVS account and write it, but please stop trying to browbeat us into doing something. I personally have a working web server that does what I need. Show me something irresistible about this new server and I will be compelled to work on it myself. -Rasmus
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, we have used APACHE as one of our important workloads. I am the one who setup the workload on a 14-processor Sun Enterprise server. During setup I found a very strange behavior of the apache server (running with worker MPM). Essentially the strange thing is that: The server optimal throughput is not achieved by using a greedy client, who drive the server with no think time. But with tiny amount of think time, much better throughput is archievable. Also, with the greedy client, the server's performance decreased over time, which seems to be very counter-intuitive. Of course, just give you the short decription above does not help you to help me. So I will give you the detail problem description and data in the following. With the understanding of the source code, maybe you can give me some more hypothesises to try on. Workload background --- The setup of apache workload on is fairly simple comparing with some of the other workloads we have (OLTP). In this workload, we have a HTTP server and an automatic request generator(SURGE). Both of the programs are highly multi-threaded. The server has a pool of static text files to be served from a known URL to the request generator (the client). The size of the files follows a statistical distribution. And the client has multiple threads each emulate a user who access a serial of files in fixed order. In previous setup of the workload, we have removed client think time. The basis of that is the following: (we also have to put the server and the client on the same machine for other reasons) The workload (server + client) is a closed queueing system. The throughput of the system is ultimately determined by the bottleneck in the system. Having think time in the client only increase the parallelism in the system. It shouldn't change the maximum throughput too much. BTW, our goal is to archieve realistic workload setup with available hardware. If you think about it, for our current server throughput level, say 5000 trans/sec, if each user have 1 second think time between fetching each file, this will need 5000 users to sustain this throughput. On the other hand, if we remove the think time from the client, maybe 10 users can also generate the same 5000 requests per second. So the difference here is that one server has 5000 httpd threads and the other has only 10 httpd threads. 10 won't be worse(in terms of server behavior) than 5000, right? Greedy client won't be worse(in terms of performance) than the lazy client, right? Well it is not that simple... I know how to get higher performance, but I don't know why it works! I have two version of surge clients in my hand. One is the original, one is my modified version. The difference between them would be the client efficiency. My modified version would fetch files more efficiently (because I made it emulate a simpler user) and have less thread switching overhead. However, when I comparing the server throughput using these two clients, I got very surprising results, roughly: old client: 3000 trans/sec new client: starts out from 4700 trans/sec, gradually degrade to 2500 trans/sec after 10-20 minutes of runtime. And this really puzzled me for a long time. My supposedly performance enhancement did not improve the server Xput, but hurt it! Turns out the reason for this is the new client was too efficient! I added the think time between each URL request and new client was able to drive the server Xput to as high as 5000 trans/sec. But note, the real interesting thing is not the think time, but how sensitive the Xput was affected by it. I'd prefer to call the think time "delay time" in the following because I really only introduced very small amount of delay between each file fetch. The result can be seen in the following plots: http://www.cs.wisc.edu/~xu/files/delay_results.eps http://www.cs.wisc.edu/~xu/files/side1.eps http://www.cs.wisc.edu/~xu/files/side2.eps In this experiment, instead of using both old and new version of the client, I just used the new version with varying delay time and number of threads. Since there are two dimensions of freedom in the client, the plot is in 3D. The figures side1 and side2 is roughly the 2D projection of the Xput vs. thread and Xput vs. delay time. Each point on the plot is a 30 minutes benchmarking on a 14P MP system. Clearly, driving the server using no delay time is not optimal. No matter using same amount of threads or less number of threads, the server Xput is no higher than delayed counterparts. However, you can see, the server Xput raise rapidly with client nu
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 Message- >From: Arliss, Noah [mailto:[EMAIL PROTECTED]] >Sent: Monday, February 10, 2003 10:51 AM >To: 'Joe Orton'; [EMAIL PROTECTED]; [EMAIL PROTECTED] >Subject: 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 than happy to leave that code be if I had a definative >way to enable >dlopen instead of shl_load. > >-N > >-Original Message- >From: Joe Orton [mailto:[EMAIL PROTECTED]] >Sent: Saturday, February 08, 2003 5:01 AM >To: [EMAIL PROTECTED]; [EMAIL PROTECTED] >Subject: Re: [PATCH] HPUX static's and Mixing C with C++ modules > > >Hi, > >On Fri, Feb 07, 2003 at 12:23:09PM -0500, Arliss, Noah wrote: >> I'll try to clarify things as best I can. First off, >BIND_VERBOSE would be >> fantastic. I had to add it in order to get my module to load >at all with >> shl_load, even though it still would not function. If there >was a good >> reason to remove BIND_VERBOSE that history would be nice to have. The >> shl_load call would look better as: > >BIND_VERBOSE means the library writes error message to >whatever file you >happen to have open as fd 2 - which is unacceptable for a library. (the >app may have closed stderr and be using fd 2 for something completely >different). You get exactly the same error string back via >apr_dso_error() anyway, which is the defined interface for retrieving >the error string. > >Changing the call to: > >> + shl_t os_handle = shl_load(path, BIND_IMMEDIATE, 0L); > >seems fine to me, FWIW, but as Will says, the BIND_NOSTART has been >there since the code was first checked into Apache 1.3, so there may be >some subtle reason why it's needed. > >Regards, > >joe >
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 it simpler to just go prefork and avoid the whole thing? just an idea: why not make such mutexes configurable anyway? It would probably not be such a big effort and lets the user decide. It would need some documentation (why and when it's neccessary with some hints about TS), of course. nd -- Gib' mal folgendes in die Kommandozeile ein (und einen Moment warten): net send localhost "Buuuh!" Na, erschreckt? -- Markus Becker in mpdsh
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 than happy to leave that code be if I had a definative way to enable dlopen instead of shl_load. -N -Original Message- From: Joe Orton [mailto:[EMAIL PROTECTED]] Sent: Saturday, February 08, 2003 5:01 AM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: [PATCH] HPUX static's and Mixing C with C++ modules Hi, On Fri, Feb 07, 2003 at 12:23:09PM -0500, Arliss, Noah wrote: > I'll try to clarify things as best I can. First off, BIND_VERBOSE would be > fantastic. I had to add it in order to get my module to load at all with > shl_load, even though it still would not function. If there was a good > reason to remove BIND_VERBOSE that history would be nice to have. The > shl_load call would look better as: BIND_VERBOSE means the library writes error message to whatever file you happen to have open as fd 2 - which is unacceptable for a library. (the app may have closed stderr and be using fd 2 for something completely different). You get exactly the same error string back via apr_dso_error() anyway, which is the defined interface for retrieving the error string. Changing the call to: > + shl_t os_handle = shl_load(path, BIND_IMMEDIATE, 0L); seems fine to me, FWIW, but as Will says, the BIND_NOSTART has been there since the code was first checked into Apache 1.3, so there may be some subtle reason why it's needed. Regards, joe
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 2.0 because Apache 2.0 must > be fixed before such a thing is even possible? > > I see more comments implying b) than a). As such, it seems that anybody > that wants to hack PHP to work better with 2.0 is wasting their time. The comments implying b) have to do with the problems with implementing PHP as a filter versus PHP as a handler. The discussion on that front has been positive and I'm hopeful that a solution can be reached. 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. I wrote: > It's trivial to make a library thread safe by serializing access to the > functions of the non-thread-safe library. and Rasmus' irked response was: > Do you really think we don't know this? I do think you know this. I was making a point and I thank you for your help in doing so. Rasmus continued: > It boils down to where our time is best spent. Yes, we can come up with > all sorts of tricks to sorta-kinda-almost make this work. But why? What > do we gain? At this point most of us feel that we really don't gain > anything. I respectfully request that PHP developers own up to the fact that while there are issues with Apache2 and PHP as a filter/handler, that the main reason why mod_php is not production ready with Apache2 is because of the PHP developer non-interest in fixing the PHP core non-reentrancy (use of thread local storage) and because PHP uses many non-thread-safe third party libraries and does not think it worth the time to protect accesses to those non-thread-safe functions. If properly documented, you might find some people willing to tackle the problem rather than finger pointing at the Apache developers. Currently, PHP propaganda implies that the reason is the ASF's fault. Yes, PHP is the #1 module in Apache, but Apache installations generally serve content in addition to PHP. The new threading models make a huge difference in performance on some platforms for that additional content and it is egomaniacal to refuse to acknowledge that people use Apache for more than just PHP. Will a possibly slower Apache2 PHP hurt more than help in such environments? I don't know and make no claims. My aim here is to clarify the issues to answer Jeff's question. Personally, my servers run PHP as CGI. Works well. Thank you. Kudos for safe_mode and safe_mode_gid. -Glenn Please direct flames to gs-apache-dev at gluelogic.com. They will be read and responded to privately.
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 starting > on Unix* in most cases where a piped log program can be started, > and add log messages for the other situations. *Other platforms > already failed Apache initialization if a piped log program +1 for backporting to 2.0.45-dev for the coming release! Bill
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 avoid the whole thing? It boils down to where our time is best spent. Yes, we can come up with all sorts of tricks to sorta-kinda-almost make this work. But why? What do we gain? At this point most of us feel that we really don't gain anything. -Rasmus On Sun, 9 Feb 2003, Glenn wrote: > At the risk of inflaming an already tense conversation (too late), > I have to say that third party thread-safety issues are not a very > good excuse. > > It's trivial to make a library thread safe by serializing access to the > functions of the non-thread-safe library. Although scripts that employ > the non-thread-safe library would suffer a performance penalty, they > would still work! > > If the core of PHP is thread safe, then this should not be a big deal. > Also, as time goes on, third party library locks can be removed as > thread-safe versions of the libraries become available. > > For a well-written and concise explanation, please refer to: > >http://www.unet.univie.ac.at/aix/aixprggd/genprogc/writing_reentrant_thread_safe_code.htm > > Cheers, > -Glenn > > On Fri, Feb 07, 2003 at 02:02:39AM +0100, Sascha Schumann wrote: > > > Rather than fix the TS issues in all the 3rd party libraries > > > that can be used with PHP's and its extension its more > > > pragmatic to sort out thread/filter issues in PHP core. > > > > The PHP project has been working on thread-safety since 1999. > > All core components and most extensions can be compiled in > > thread-safe mode. > > > > The first SAPI module for a threaded UNIX web server was > > completed in the same year (for AOLserver). > > > > It's safe to assert that we need to primarily worry about 3rd > > party libraries. > > > > > Also blaming on use of TLS seems a little strange since use of > > > TLS is supposed to improve re-entrancy isn't it ? > > > > Let me just quickly define what these concepts refer to. > > > > Thread-safe means that you can run code in multiple threads > > concurrently (e.g. multiple worker threads). > > > > Reentrant means that you can run code in a single thread > > context in a nested way (e.g. Apache sub-requests). > > > > Thread local storage aids only the former one. > > > > From my point of view we should not worry about reentrancy > > right now, at least not until we a have firm grasp on the 3rd > > party TS issues. > > > > - Sascha >
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 do remember seeing > a similar bug report a long, long time ago. See: > http://bugs.apache.org/index.cgi/full/5913 ah, thanks. After some further looking through the rest of apache code, I'd consider this to be correct. I've attached patches for 1.3 and 2.1. Any objections, someone? nd -- s s^saoaaaoaaoaaaom a alataa aaoat a a a maoaa a laoata a oia a o a m a o alaoooat aaool aaoaa matooololaaatoto aaa o a o ms;s;\s;s;g;y;s;:;s;y#mailto: # \51/\134\137| http://www.perlig.de #;print;# > [EMAIL PROTECTED] Index: src/CHANGES === RCS file: /home/cvs/apache-1.3/src/CHANGES,v retrieving revision 1.1874 diff -u -r1.1874 CHANGES --- src/CHANGES 31 Jan 2003 02:25:36 - 1.1874 +++ src/CHANGES 10 Feb 2003 14:03:19 - @@ -1,5 +1,8 @@ Changes with Apache 1.3.28 + *) Fix suexec compile error under SUNOS4, where strerror() doesn't + exist. PR 5913, 9977. [André Malo] + *) Fix bug where 'Satisfy Any' without an AuthType resulted in an "Internal Server Error" response. PR 9076. [André Malo] Index: src/support/suexec.c === RCS file: /home/cvs/apache-1.3/src/support/suexec.c,v retrieving revision 1.58 diff -u -r1.58 suexec.c --- src/support/suexec.c3 Feb 2003 17:13:37 - 1.58 +++ src/support/suexec.c10 Feb 2003 14:03:21 - @@ -111,6 +111,11 @@ } #endif +#if defined(NEED_STRERROR) +extern char *sys_errlist[]; +#define strerror(x) sys_errlist[(x)] +#endif + #if defined(PATH_MAX) #define AP_MAXPATH PATH_MAX #elif defined(MAXPATHLEN) Index: CHANGES === RCS file: /home/cvs/httpd-2.0/CHANGES,v retrieving revision 1.1056 diff -u -r1.1056 CHANGES --- CHANGES 10 Feb 2003 03:37:22 - 1.1056 +++ CHANGES 10 Feb 2003 14:02:17 - @@ -2,6 +2,9 @@ [Remove entries to the current 2.0 section below, when backported] + *) Fix suexec compile error under SUNOS4, where strerror() doesn't + exist. PR 5913, 9977. [André Malo] + *) Let suexec send a message to stderr, if it failed or its policy was violated. This message appears in the error log and allows for easier debugging. PR 10773. [André Malo] Index: support/suexec.c === RCS file: /home/cvs/httpd-2.0/support/suexec.c,v retrieving revision 1.23 diff -u -r1.23 suexec.c --- support/suexec.c10 Feb 2003 03:37:22 - 1.23 +++ support/suexec.c10 Feb 2003 14:02:20 - @@ -111,6 +111,11 @@ } #endif +#if defined(SUNOS4) +extern char *sys_errlist[]; +#define strerror(x) sys_errlist[(x)] +#endif + #if defined(PATH_MAX) #define AP_MAXPATH PATH_MAX #elif defined(MAXPATHLEN)
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]
