I don’t know what changed, but now when I try the test.asp I get html displayed, but not the stuff inside the asp tags with the ASP stuff in the <VirtualHost _default_:443> section of my httpd.conf file. It does not interpret the asp tags. Here’s the access_log
207.43.195.204 - - [21/Jan/2004:08:05:22 -0800] "GET /register/test.asp HTTP/1.1" 304 There is nothing in the error_log when it serves the test.asp page. I think the ASP stuff should go into the <VirtualHost 209.133.46.187> section of the httpd.conf file, but Apache won’t come up when it’s there and it makes no entry in the error_log. I see this line in the error_log when I do a restart: [Wed Jan 21 08:17:37 2004] [notice] caught SIGTERM, shutting down There is just nothing in the error_log until I comment out my ASP stuff and restart. View my /etc/httpd/conf/httpd.conf file here http://ptoc.org/register/httpd_conf.txt -----Original Message----- From: Josh Chamas <[EMAIL PROTECTED]> Sent: Jan 21, 2004 9:47 AM To: Steve Brown <[EMAIL PROTECTED]> Cc: Helmut Zeilinger <[EMAIL PROTECTED]>, [EMAIL PROTECTED] Subject: Re: ASP on Virtual Server Steve Brown wrote: > When I could not find the error_log message you requested, I did a find from / and > found /var/log/httpd/error_log. > Here's the last 3 lines from a restart of Apache. I notice perl is missing. > According to my /etc/httpd/conf/httpd.conf file the error_log should be in > /home/webadmin/ptoc.org > > [Wed Jan 21 07:05:51 2004] [notice] Apache/1.3.27 (Unix) (Red-Hat/Linux) PHP/4.1.2 > mod_perl/1.27 configured -- resuming normal operations > [Wed Jan 21 07:05:51 2004] [notice] suEXEC mechanism enabled (wrapper: > /usr/sbin/suexec) > [Wed Jan 21 07:05:51 2004] [notice] Accept mutex: sysvsem (Default: sysvsem) > The mod_perl part of the header is enough to show that this system should work. Assuming this is the right error_log, what does it say when you try the ASP page, and you get a 500 error? 500 errors are almost always reported in the error_log. Note though that port 443 is your SSL port typically so that could be the problem. Also, to confirm you are looking at the right error_log, you should also find the access_log which records the page request as well and shows the 500 error occuring. Regards, Josh ________________________________________________________________ Josh Chamas, Founder phone:925-552-0128 Chamas Enterprises Inc. http://www.chamas.com NodeWorks Link Checker http://www.nodeworks.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Steve Brown --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]