Re: Problem session cache and HTTP headers AOL
Hi, now I have more precise data. The samples have been taken during 5 days. There where 10 million acceses to the server. 461 of these had corrupt headers. So increasing Log level is not really feasible. Browsers with corrupt headers (including count): 309 Mozilla/4.0 (compatible; MSIE 5.0; AOL 5.0; Windows 98; DigExt) 34 Mozilla/4.0 (compatible; MSIE 5.0; AOL 5.0; Windows 95; DigExt) 28 Mozilla/4.0 (compatible; MSIE 5.5; Windows 98) 11 Mozilla/4.0 (compatible; MSIE 5.0; MSN 2.5; AOL 5.0; Windows 98; DigExt) 10 Mozilla/4.0 (compatible; MSIE 5.0; AOL 5.0; Windows 98; DigExt; DT) 8 Mozilla/4.0 (compatible; MSIE 5.0; AOL 6.0; Windows 98; DigExt) 6 Mozilla/4.0 (compatible; MSIE 5.0; Windows 98; DigExt) 5 Mozilla/4.0 (compatible; MSIE 5.0; AOL 5.0; Windows 98; DigExt; T-Online Internatinal AG) 5 Mozilla/4.0 (compatible; MSIE 5.0; AOL 4.0; Windows 98; DigExt) 2 Mozilla/4.0 (compatible; MSIE 5.0; MSN 2.5; AOL 5.0; Windows 98) 2 Mozilla/4.0 (compatible; MSIE 5.0; AOL 5.0; Windows 98; DigExt; tn3.0) 2 Mozilla/4.0 (compatible; MSIE 5.0; AOL 5.0; Windows 98; DigExt; pi 3.0.0.0) 2 Mozilla/4.0 (compatible; MSIE 5.0; AOL 5.0; Windows 98; DigExt; Creative) 2 Mozilla/4.0 (compatible; MSIE 5.0; AOL 5.0; Windows 98; DigExt; A0111) 2 Mozilla/4.0 (compatible; MSIE 5.0; AOL 5.0; Windows 98; DigExt; */E-Plus-002) 2 Mozilla/4.0 (compatible; MSIE 5.0; AOL 5.0; Windows 95; DT; DigExt) 2 Mozilla/2.0 (compatible; MSIE 3.02; AOL 3.0; Windows 95) 1 Mozilla/4.0 (compatible; MSIE 5.0; Windows 98; DigExt; Quicken 98 DE) 1 Mozilla/4.0 (compatible; MSIE 5.0; Windows 95; DigExt) 1 Mozilla/4.0 (compatible; MSIE 5.0; Windows 95; DT; DigExt) 1 Mozilla/4.0 (compatible; MSIE 5.0; MSN 2.5; Windows 98; DigExt) 1 Mozilla/4.0 (compatible; MSIE 5.0; MSN 2.5; AOL 5.0; Windows 98; DigExt; UUNET-DE) 1 Mozilla/4.0 (compatible; MSIE 5.0; CS 2000; Windows 98; DigExt; CompuServe Deutschland IE 5.0) 1 Mozilla/4.0 (compatible; MSIE 5.0; AOL 6.0; Windows 95; DigExt) 1 Mozilla/4.0 (compatible; MSIE 5.0; AOL 5.0; Windows 98; surfEU DE M1) 1 Mozilla/4.0 (compatible; MSIE 5.0; AOL 5.0; Windows 98; QXW0332o) 1 Mozilla/4.0 (compatible; MSIE 5.0; AOL 5.0; Windows 98; PKBL008; DigExt) 1 Mozilla/4.0 (compatible; MSIE 5.0; AOL 5.0; Windows 98; DigExt; pbc4.0.0.0) 1 Mozilla/4.0 (compatible; MSIE 5.0; AOL 5.0; Windows 98; DigExt; o.tel.o online IFA99) 1 Mozilla/4.0 (compatible; MSIE 5.0; AOL 5.0; Windows 98; DigExt; freenet 4.0) 1 Mozilla/4.0 (compatible; MSIE 5.0; AOL 5.0; Windows 98; DigExt; chip 1) 1 Mozilla/4.0 (compatible; MSIE 5.0; AOL 5.0; Windows 98; DigExt; Vi-Interkom 1.0.2.1) 1 Mozilla/4.0 (compatible; MSIE 5.0; AOL 5.0; Windows 98; DigExt; QXW03318; pbc4.0.0.0) 1 Mozilla/4.0 (compatible; MSIE 5.0; AOL 5.0; Windows 98; DigExt; QXW03314) 1 Mozilla/4.0 (compatible; MSIE 5.0; AOL 5.0; Windows 98; DigExt; MIST1.01) 1 Mozilla/4.0 (compatible; MSIE 5.0; AOL 5.0; Windows 98; DigExt; AIS3.01) 1 Mozilla/4.0 (compatible; MSIE 5.0; AOL 5.0; Windows 98; DigExt; 11 Internet AG) 1 Mozilla/4.0 (compatible; MSIE 5.0; AOL 5.0; Windows 98; DT; Quicken 98 DE; DigExt) 1 Mozilla/4.0 (compatible; MSIE 5.0; AOL 5.0; Windows 98; DT; DigExt) 1 Mozilla/4.0 (compatible; MSIE 5.0; AOL 5.0; Windows 98) 1 Mozilla/4.0 (compatible; MSIE 5.0; AOL 5.0; Windows 95; DigExt; debitel.net 3.0) 1 Mozilla/4.0 (compatible; MSIE 5.0; AOL 4.0; Windows 98; DigExt; T-Online Internatinal AG) 1 Mozilla/4.0 (compatible; MSIE 5.0; AOL 4.0; Windows 98; DigExt; QXW03018) 1 Mozilla/4.0 (compatible; MSIE 5.0; AOL 4.0; Windows 98; DigExt; DT) 1 Mozilla/4.0 (compatible; MSIE 5.0; AOL 4.0; Windows 95; DigExt) 1 Mozilla/4.0 (compatible; MSIE 5.0; AOL 4.0; Windows 95; DT; talknet2.0; DigExt) The corrupt headers themselves (including count) obtained by mod_log_config: 421applicationent-Type: application/x-www-form-urlencoded 29application/x-www-form-urlencoded, application/x-www-form-urlencoded 6applicationontent-Type: application/x-www-form-urlencoded 3application0.5, application/x-www-form-urlencoded 1application;q=0.5, application/x-www-form-urlencoded 1application;q=0.7,fr;q=0.3, application/x-www-form-urlencoded SSL ciphers and key length (including count): 433 RC4-MD5 128 128 28 EDH-RSA-DES-CBC3-SHA 168 168 The 28 requests from Mozilla/4.0 (compatible; MSIE 5.5; Windows 98) where exactly those using EDH-RSA-DES-CBC3-SHA and they all had Content-Type application/x-www-form-urlencoded, application/x-www-form-urlencoded, but there was one more of that type using RC4-MD5 coming from Mozilla/4.0 (compatible; MSIE 5.0; Windows 95; DT; DigExt). Also these 28 requests had a Referrer-Header that contained the value duplicate, separated by a comma (so the same situation here, as in the Content-Type header. So these 28 cases might be something special. All the
new environment variables?
I am trying to define directory level access permissions on an Apache server based on information on certificates in a certificate chain, using .htaccess files. I checked the variables available and (unless I am mistaken) I cannot get hold of information on any certificate in the chain beyond the last one and its issuer. In particular I am interested in checking who issued the second last certificate, but the general problem is: the server is certainly checking all certificates in the chain and therefore (at least temporarily) storing information on each issuer and subject somewhere. I need to get hold of this information through some environment variable. I assume I must add new environment variables. How do I do that? Thank you very much. Giovanni Porcelli __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
HTTP/HTTPS both on non-standard ports?
Hi, This is my first post to the list. I've setup 2 Apache + mod_ssl listeners on the same machine for our test and development environments. The test listener is on the standard ports. The development listener is listening on for HTTP and for HTTPS. This works only if my URL looks like this: https://hostname.capis.com:/ I would like to be able to use http://hostname.capis.com: or even hostname.capis.com: as a URL. Is there anyway to rewrite the URL to do this? I messed with mod_rewrite some but was unsuccessful. Thanks in advance for any replies, -- Michael Champagne, Software Engineer Capital Institutional Services, Inc. wk: [EMAIL PROTECTED] hm: [EMAIL PROTECTED] ** This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction, unless specifically agreed otherwise. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect the views or opinions of Capital Institutional Services, Inc. Capital Institutional Services, Inc. accepts no liability for any errors or omissions arising as a result of transmission. Use of this communication by other than intended recipients is prohibited. ** __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
engine io question
I am working on a port of Apache 1.3.20+mod_ssl 2.8.4 to TPF. I'm still struggling to get it to correctly support cgi script processing in secure mode from a Netscape browser. One key difference I see between Netscape and other browsers is that Netscape sends a POST request in four chunks in two TCP packets. (In Opera and IE, the POST is in one chunk, one packet.) The first TCP packet has one chunk and the 2nd TCP packet has three chunks. Here I'm defining a chunk as something starting with 0x170300[length][encrypted data]. The first chunk has the request and the mime headers, the 2nd and 3rd chunk appear to be blank lines (or just CRLFs) and the 4th chunk has the content-type, content-length and form data. From what I understand of HTTP and TCP, this seems a valid thing to do. I put a trap in SSL_read to see what it is reading after the decrypt, and I see only the first chunk; SSL_read is not called again to try to read more before the connection shutdown. I see the comments in the file ssl_engine_io.c and wonder what the implications are on TPF. I tried compiling both with and without SSL_CONSERVATIVE and it makes no difference. The platform closest to TPF is OS/390; they both run on IBM zSeries processors (ebcdic). Running Apache+mod_ssl on OS/390, cgi scripts works fine from Netscape, so that would seem to rule out any bugs in, say, ebcdic translation. There must be some platform specific nuances here relating to the 'sucking' that ssl_engine_io.c does or with processing chunks. If anyone has words of wisdom of potential areas where the problem is, I'm all ears. Meanwhile I'll continue to rummage deeper into the code. Regards, Evan Jennings TPF Development, IBM Corp. Poughkeepsie NY (845) 435-1918 __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Re: engine io question
Evan Jennings [EMAIL PROTECTED] writes: I am working on a port of Apache 1.3.20+mod_ssl 2.8.4 to TPF. I'm still struggling to get it to correctly support cgi script processing in secure mode from a Netscape browser. One key difference I see between Netscape and other browsers is that Netscape sends a POST request in four chunks in two TCP packets. (In Opera and IE, the POST is in one chunk, one packet.) The first TCP packet has one chunk and the 2nd TCP packet has three chunks. Here I'm defining a chunk as something starting with 0x170300[length][encrypted data]. The first chunk has the request and the mime headers, the 2nd and 3rd chunk appear to be blank lines (or just CRLFs) and the 4th chunk has the content-type, content-length and form data. This is awfully suspicious sounding. HTTP posts consist of headers followed by a pair of CRLFs followed by a body. If there is no Content-Length header than the body is assumed to be zero length. Thus, if you're getting a request that looks like this: GET /url HTTP/1.0 Other-Header: foobar Even-Another-Header: Something Content-Type: mumble/frotz Content-Length: Some-number-of-bytes Form-data Then something is seriously wrong. Are you sure that's what's going on? From what I understand of HTTP and TCP, this seems a valid thing to do. I put a trap in SSL_read to see what it is reading after the decrypt, and I see only the first chunk; SSL_read is not called again to try to read more before the connection shutdown. I haven't checked the code but my memory is that HTTP servers typically try to read only the headers and (when there's a body) leave that on the wire until the script reads it. I would imagine that mod_ssl behaves roughly the same way. Except that the data needs to be processed by mod_ssl to decrypt it. So, what you may be having here is a problem establishing the pipe between mod_ssl and your CGI script. -Ekr __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Re: Problem session cache and HTTP headers AOL
On Thu, Sep 27, 2001 at 10:08:32AM +0200, Rainer Jung wrote: Hi, now I have more precise data. The samples have been taken during 5 days. There where 10 million acceses to the server. 461 of these had corrupt headers. So increasing Log level is not really feasible. snip of a lot of good data It really looks like buggy AOL proxies or buggy browser software to me. I bet that none of those browsers have been updated to the latest service pack, either. I would also assume that this issue does not only affect Apache/mod_ssl, but all other https servers as well. Not sure if there's anything you can do! -Dave __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Re: engine io question
Looking again at OS/390 for comparison, I did misstate the flow. Below are the actual intercepted SSL_read outputs on TPF. The S_r: prefix indicates each SSL_read: S_r: POST /cgi-bin/cgi-forms HTTP/1.0 Referer: https://1.2.3.4/cgiform.html Connection: Keep-Alive User-Agent: Mozilla/4.77 .en. (Windows NT 5.0; U) Host: 1.2.3.4 Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, image/png, */* Accept-Encoding: gzip Accept-Language: en,de Accept-Charset: iso-8859-1,*,utf-8 The same thing on OS/390 shows me: S_r: POST /cgi-bin/test-cgi HTTP/1.0 Referer: https://5.6.7.8:8443/cgiform2.html Connection: Keep-Alive User-Agent: Mozilla/4.77 [en] (Windows NT 5.0; U) Host: 5.6.7.8:8443 Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, image/png, */* Accept-Encoding: gzip Accept-Language: en,de Accept-Charset: iso-8859-1,*,utf-8 S_r: Content-type: application/x-www-form-urlencoded Content-length: 9 S_r: S_r: entry=123 So, the question is why is TPF not seeing the rest of the body that tells it there is more data to read?I can tell from an IP trace that it is sent from the client (in a packet containing three 170300's). I'll continue to examine the code in ssl_engine_io.c to see if the problem relates to the sucking and buffering it does. Regards, Evan Jennings TPF Development, IBM Corp. Poughkeepsie NY (845) 435-1918 Eric Rescorla [EMAIL PROTECTED]To: [EMAIL PROTECTED] Sent by: cc: owner-modssl-users@ Subject: Re: engine io question modssl.org 09/27/2001 05:37 PM Please respond to modssl-users Evan Jennings [EMAIL PROTECTED] writes: I am working on a port of Apache 1.3.20+mod_ssl 2.8.4 to TPF. I'm still struggling to get it to correctly support cgi script processing in secure mode from a Netscape browser. One key difference I see between Netscape and other browsers is that Netscape sends a POST request in four chunks in two TCP packets. (In Opera and IE, the POST is in one chunk, one packet.) The first TCP packet has one chunk and the 2nd TCP packet has three chunks. Here I'm defining a chunk as something starting with 0x170300[length][encrypted data]. The first chunk has the request and the mime headers, the 2nd and 3rd chunk appear to be blank lines (or just CRLFs) and the 4th chunk has the content-type, content-length and form data. This is awfully suspicious sounding. HTTP posts consist of headers followed by a pair of CRLFs followed by a body. If there is no Content-Length header than the body is assumed to be zero length. Thus, if you're getting a request that looks like this: GET /url HTTP/1.0 Other-Header: foobar Even-Another-Header: Something Content-Type: mumble/frotz Content-Length: Some-number-of-bytes Form-data Then something is seriously wrong. Are you sure that's what's going on? From what I understand of HTTP and TCP, this seems a valid thing to do. I put a trap in SSL_read to see what it is reading after the decrypt, and I see only the first chunk; SSL_read is not called again to try to read more before the connection shutdown. I haven't checked the code but my memory is that HTTP servers typically try to read only the headers and (when there's a body) leave that on the wire until the script reads it. I would imagine that mod_ssl behaves roughly the same way. Except that the data needs to be processed by mod_ssl to decrypt it. So, what you may be having here is a problem establishing the pipe between mod_ssl and your CGI script. -Ekr __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Re: HTTP/HTTPS both on non-standard ports?
Hi, Simply it's not possible ! Regards Rajidhar E - Original Message - From: Michael Champagne [EMAIL PROTECTED] Date: Thursday, September 27, 2001 2:30 pm Subject: HTTP/HTTPS both on non-standard ports? Hi, This is my first post to the list. I've setup 2 Apache + mod_ssl listeners on the same machine for our test and development environments. The test listener is on the standard ports. The development listener is listening on for HTTP and for HTTPS. This works only if my URL looks like this: https://hostname.capis.com:/ I would like to be able to use http://hostname.capis.com: or even hostname.capis.com: as a URL. Is there anyway to rewrite the URL to do this? I messed with mod_rewrite some but was unsuccessful. Thanks in advance for any replies, -- Michael Champagne, Software Engineer Capital Institutional Services, Inc. wk: [EMAIL PROTECTED] hm: [EMAIL PROTECTED] ** This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction, unless specifically agreed otherwise. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect the views or opinions of Capital Institutional Services, Inc. Capital Institutional Services, Inc. accepts no liability for any errors or omissions arising as a result of transmission. Use of this communication by other than intended recipients is prohibited. ** __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED] begin:vcard n:Etta;Rajidhar fn:Rajidhar Etta tel;cell:609.203.3697 tel;fax:(888) 979-8800 tel;home:(609) 750-0836 tel;work:(609) 951-8500 x192 org:eComServer Inc;ACB adr:;;Princeton Executive Campus, 4301, Route 1, South Suite 220,;Monmouth Junction;NJ;08852;United States of America version:2.1 email;internet:[EMAIL PROTECTED] title:Software Engineer end:vcard
Re: engine io question
Evan Jennings [EMAIL PROTECTED] writes: Looking again at OS/390 for comparison, I did misstate the flow. Below are the actual intercepted SSL_read outputs on TPF. The S_r: prefix indicates each SSL_read: S_r: POST /cgi-bin/cgi-forms HTTP/1.0 Referer: https://1.2.3.4/cgiform.html Connection: Keep-Alive User-Agent: Mozilla/4.77 .en. (Windows NT 5.0; U) Host: 1.2.3.4 Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, image/png, */* Accept-Encoding: gzip Accept-Language: en,de Accept-Charset: iso-8859-1,*,utf-8 The same thing on OS/390 shows me: S_r: POST /cgi-bin/test-cgi HTTP/1.0 Referer: https://5.6.7.8:8443/cgiform2.html Connection: Keep-Alive User-Agent: Mozilla/4.77 [en] (Windows NT 5.0; U) Host: 5.6.7.8:8443 Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, image/png, */* Accept-Encoding: gzip Accept-Language: en,de Accept-Charset: iso-8859-1,*,utf-8 S_r: Content-type: application/x-www-form-urlencoded Content-length: 9 S_r: S_r: entry=123 Note that these are totally different requests. It's a little hard to tell whether the first request actually contains a CRLF at the end or not. Can you clarify? It might be useful if you used ssldump to record the actual traffic being sent by the client (provide it with the private key so we can see the plaintext). -Ekr __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Re: DEAPI?
On Fri, 28 Sep 2001, Rachel wrote: I tried to install mod_ssl on my FreeBSD server today... when i finish installed the mod_ssl, openssl, MM and apache.. i tried to start the apache web server. But, the error messages as below appear. [Thu Sep 27 19:04:35 2001] [warn] Loaded DSO libexec/mod_example.so uses plain Apache 1.3 API, this module might c rash under EAPI! (please recompile it with -DEAPI) Do as the message suggests and recompile all your shared modules. Or perhaps you did recompile them but didn't install the new copies to their correct location... --Cliff -- Cliff Woolley [EMAIL PROTECTED] Charlottesville, VA __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Re: DEAPI?
Try to compile with this : $ CFLAGS=-DEAPI; export CFLAGS; -frida- Rachel wrote: Hi, Need help very urgently. I tried to install mod_ssl on my FreeBSD server today... when i finish installedthe mod_ssl, openssl, MM and apache.. i tried to start the apache web server. But,the error messages as below appear.[Thu Sep 27 19:04:35 2001] [warn] Loaded DSO libexec/mod_example.so uses plain Apache 1.3 API, this module might c rash under EAPI! (please recompile it with -DEAPI)[Thu Sep 27 19:04:35 2001] [warn] Loaded DSO libexec/mod_unique_id.so uses plain Apache 1.3 API, this module might crash under EAPI! (please recompile it with -DEAPI)[Thu Sep 27 19:04:35 2001] [warn] Loaded DSO libexec/mod_setenvif.so uses plain Apache 1.3 API, this module might crash under EAPI! (please recompile it with -DEAPI)[Thu Sep 27 19:04:35 2001] [warn] Loaded DSO libexec/libphp3.so uses plain Apache 1.3 API, this module might crash under EAPI! (please recompile it with -DEAPI)[Thu Sep 27 19:04:35 2001] [warn] Loaded DSO libexec/libperl.so uses plain Apache 1.3 API, this module might crash under EAPI! (please recompile it with -DEAPI)any idea?
Re: DEAPI?
Sorry, to confirm again... should i remove the existing folder and compile it again...? to which folder it compile in? i'm not sure which folder to remove... - Original Message - From: Cliff Woolley [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, September 28, 2001 12:39 PM Subject: Re: DEAPI? On Fri, 28 Sep 2001, Rachel wrote: I tried to install mod_ssl on my FreeBSD server today... when i finish installed the mod_ssl, openssl, MM and apache.. i tried to start the apache web server. But, the error messages as below appear. [Thu Sep 27 19:04:35 2001] [warn] Loaded DSO libexec/mod_example.so uses plain Apache 1.3 API, this module might c rash under EAPI! (please recompile it with -DEAPI) Do as the message suggests and recompile all your shared modules. Or perhaps you did recompile them but didn't install the new copies to their correct location... --Cliff -- Cliff Woolley [EMAIL PROTECTED] Charlottesville, VA __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED] __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Re: DEAPI?
Sorry, I'm new to mod_ssl may i know how to compilewith "CFLAGS=-DEAPI ; export CFLAGS ;" as suggested below? - Original Message - From: frida To: [EMAIL PROTECTED] Sent: Friday, September 28, 2001 12:54 PM Subject: Re: DEAPI? Try to compile with this : $ CFLAGS=-DEAPI; export CFLAGS; -frida- Rachel wrote: Hi, Need help very urgently. I tried to install mod_ssl on my FreeBSD server today... when i finish installedthe mod_ssl, openssl, MM and apache.. i tried to start the apache web server. But,the error messages as below appear.[Thu Sep 27 19:04:35 2001] [warn] Loaded DSO libexec/mod_example.so uses plain Apache 1.3 API, this module might c rash under EAPI! (please recompile it with -DEAPI)[Thu Sep 27 19:04:35 2001] [warn] Loaded DSO libexec/mod_unique_id.so uses plain Apache 1.3 API, this module might crash under EAPI! (please recompile it with -DEAPI)[Thu Sep 27 19:04:35 2001] [warn] Loaded DSO libexec/mod_setenvif.so uses plain Apache 1.3 API, this module might crash under EAPI! (please recompile it with -DEAPI)[Thu Sep 27 19:04:35 2001] [warn] Loaded DSO libexec/libphp3.so uses plain Apache 1.3 API, this module might crash under EAPI! (please recompile it with -DEAPI)[Thu Sep 27 19:04:35 2001] [warn] Loaded DSO libexec/libperl.so uses plain Apache 1.3 API, this module might crash under EAPI! (please recompile it with -DEAPI)any idea?
