Re: [PATCH] allow implicit ServerRoot via apxs
this is in now. I've tested it against everything I have. mike, if you can give CVS a whirl today, that would be great. $ cvs -z9 :pserver:[EMAIL PROTECTED]:/home/cvspublic checkout mod_perl-2.0 or $ cvs -z9 :pserver:[EMAIL PROTECTED]:/home/cvspublic checkout httpd-test thanks. --Geoff
Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestConfigParse.pm
[EMAIL PROTECTED] wrote:
geoff 2003/11/07 07:03:39
Modified:perl-framework/Apache-Test/lib/Apache TestConfigParse.pm
Log:
use apxs PREFIX to resolve relative httpd.conf directives
ServerRoot is not present
Revision ChangesPath
1.36 +48 -6 httpd-test/perl-framework/Apache-Test/lib/Apache/TestConfigParse.pm
Index: TestConfigParse.pm
[...]
+else {
+warning unable to resolve $file - cannot find a suitable
ServerRoot;
+warning please specify a ServerRoot in your httpd.conf or use
apxs;
shouldn't this be an error message (not fatal, just s/warning/error/)
__
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: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestConfigParse.pm
Stas Bekman wrote:
[EMAIL PROTECTED] wrote:
geoff 2003/11/07 07:03:39
Modified:perl-framework/Apache-Test/lib/Apache TestConfigParse.pm
Log:
use apxs PREFIX to resolve relative httpd.conf directives
ServerRoot is not present
Revision ChangesPath
1.36 +48 -6
httpd-test/perl-framework/Apache-Test/lib/Apache/TestConfigParse.pm
Index: TestConfigParse.pm
[...]
+else {
+warning unable to resolve $file - cannot find a
suitable ServerRoot;
+warning please specify a ServerRoot in your httpd.conf
or use apxs;
shouldn't this be an error message (not fatal, just s/warning/error/)
well, I was thinking about that lots. the reason I went with warning is
that under normal circumstances 'perl Makefile.PL' would be the one throwing
the message, but it's really not a build-time problem. actually, the
'errors' might not end up being errors at all - if the configuration script
can't resolve conf/mime.types, for instance, but the EU has one in his
t/conf directory everything should work out fine.
so, given this, I thought warnings were more appropriate. but I'm flexible
and don't feel too strongly about it.
--Geoff
Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestConfigParse.pm
Geoffrey Young wrote:
Stas Bekman wrote:
[EMAIL PROTECTED] wrote:
geoff 2003/11/07 07:03:39
Modified:perl-framework/Apache-Test/lib/Apache TestConfigParse.pm
Log:
use apxs PREFIX to resolve relative httpd.conf directives
ServerRoot is not present
Revision ChangesPath
1.36 +48 -6
httpd-test/perl-framework/Apache-Test/lib/Apache/TestConfigParse.pm
Index: TestConfigParse.pm
[...]
+else {
+warning unable to resolve $file - cannot find a
suitable ServerRoot;
+warning please specify a ServerRoot in your
httpd.conf or use apxs;
shouldn't this be an error message (not fatal, just s/warning/error/)
well, I was thinking about that lots. the reason I went with warning is
that under normal circumstances 'perl Makefile.PL' would be the one
throwing the message, but it's really not a build-time problem.
actually, the 'errors' might not end up being errors at all - if the
configuration script can't resolve conf/mime.types, for instance, but
the EU has one in his t/conf directory everything should work out fine.
if that's the case, why not having A-T look in that directory and keep things
under a tight control.
so, given this, I thought warnings were more appropriate. but I'm
flexible and don't feel too strongly about it.
sure, let's keep it as it is for now.
__
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: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestConfigParse.pm
actually, the 'errors' might not end up being errors at all - if the configuration script can't resolve conf/mime.types, for instance, but the EU has one in his t/conf directory everything should work out fine. if that's the case, why not having A-T look in that directory and keep things under a tight control. yeah. but I'm not exactly sure what the proper behavior here ought to be, and there are lots of variables (like conf/foo.in which may not change into conf/foo before TestConfigParse looks for it). at any rate, I think we can delay the digging for a while - Mike's original problem has been addressed and we've added in a few extra checks and debugging, so if something like this crops up in real life it will be easy to address. --Geoff
[RELEASE CANDIDATE] Apache-Test-1.06
a release candidate for Apache-Test 1.06 is now available. 1.06 is the
version of Apache-Test that will ship with mod_perl 1.99_11.
http://perl.apache.org/~geoff/Apache-Test-1.06-dev.tar.gz
please take the time to excercise the candidate through all your existing
applications that use Apache-Test and report back successes or failures.
--Geoff
Changes since 1.05:
added -startup_timeout and $ENV{APACHE_TEST_STARTUP_TIMEOUT} as places
to specify the maximum number of seconds to wait for the test
server to start. the default is still 60 seconds. [Geoffrey Young]
use apxs PREFIX to resolve relative httpd.conf directives
ServerRoot is not present [Mike Cramer]
add support for a new subclass method 'bug_report', which if provided
will be called when 'make test' fails. we use it in mod_perl to print
the pointers on how to proceed when the failure occurs. [Stas]
sudo and su -u aren't portable, therefore use a simple setuid/setguid
perl program instead, to check whether the root directory of the test
suite is rwx by the user/group apache is going to run under (when
running 'make test' as root). [Stas]
Re: [RELEASE CANDIDATE] Apache-Test-1.06
On Friday, November 7, 2003, at 01:07 PM, Geoffrey Young wrote: a release candidate for Apache-Test 1.06 is now available. 1.06 is the version of Apache-Test that will ship with mod_perl 1.99_11. http://perl.apache.org/~geoff/Apache-Test-1.06-dev.tar.gz please take the time to excercise the candidate through all your existing applications that use Apache-Test and report back successes or failures. Works fine for me. The only issue I noticed was a warning when I ran `perl Makefile.PL` for MasonX::Interp::WithCallbacks: mercury% perl Makefile.PL Constant subroutine Apache::TestConfig::WIN32 redefined at /usr/local/lib/perl5/5.8.2/constant.pm line 108. Checking if your kit is complete... Looks good Writing Makefile for MasonX::Interp::WithCallbacks No big deal, but you might want to see if you can eliminate it. Actually, I notices I got some test failures that I don't remember having before. This is because it looks like at some point calls to POST were changed so that redirects are followed, just as they are for calls to GET or any of the rest of the request functions. I'm not sure how or why this changed (maybe it's a change in LWP??), but it necessitates a documentation update. Patch attached. Regards, David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://www.kineticode.com/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED] Kineticode. Setting knowledge in motion.[sm]
Re: [RELEASE CANDIDATE] Apache-Test-1.06
David Wheeler wrote: On Friday, November 7, 2003, at 01:07 PM, Geoffrey Young wrote: a release candidate for Apache-Test 1.06 is now available. 1.06 is the version of Apache-Test that will ship with mod_perl 1.99_11. http://perl.apache.org/~geoff/Apache-Test-1.06-dev.tar.gz please take the time to excercise the candidate through all your existing applications that use Apache-Test and report back successes or failures. Works fine for me. The only issue I noticed was a warning when I ran `perl Makefile.PL` for MasonX::Interp::WithCallbacks: mercury% perl Makefile.PL Constant subroutine Apache::TestConfig::WIN32 redefined at /usr/local/lib/perl5/5.8.2/constant.pm line 108. Checking if your kit is complete... Looks good Writing Makefile for MasonX::Interp::WithCallbacks No big deal, but you might want to see if you can eliminate it. Can you please test with the current cvs, should be fixed now. Actually, I notices I got some test failures that I don't remember having before. This is because it looks like at some point calls to POST were changed so that redirects are followed, just as they are for calls to GET or any of the rest of the request functions. I'm not sure how or why this changed (maybe it's a change in LWP??), but it necessitates a documentation update. Patch attached. I don't think we have changed anything, besides the patches you've submitted by yourself ;) There is no patch attachment, btw. __ 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: [RELEASE CANDIDATE] Apache-Test-1.06
On Friday, November 7, 2003, at 02:08 PM, Stas Bekman wrote: Can you please test with the current cvs, should be fixed now. Confirmed, thanks! I don't think we have changed anything, besides the patches you've submitted by yourself ;) There is no patch attachment, btw. That's because the mail list software strips them off! I'll send it to you directly. Must've been a change in LWP or something. Regards, David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://www.kineticode.com/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED] Kineticode. Setting knowledge in motion.[sm]
Re: [RELEASE CANDIDATE] Apache-Test-1.06
David Wheeler wrote: On Friday, November 7, 2003, at 02:08 PM, Stas Bekman wrote: Can you please test with the current cvs, should be fixed now. Confirmed, thanks! Thanks for testing, David. I don't think we have changed anything, besides the patches you've submitted by yourself ;) There is no patch attachment, btw. That's because the mail list software strips them off! I'll send it to you directly. eh? since when? it's a first time I hear that. Is it because of the way your mailer attaches them? __ 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: piped log files
Glenn wrote: On Thu, Nov 06, 2003 at 11:02:16AM -0500, Jeff Trawick wrote: Jeff Trawick wrote: Bastiaan van der Put wrote: CustomLog |/usr/local/apache2/bin/logresolve /home/accounts/x/x/logs/access_log combined unless somebody speaks up soon, I'll commit the patch to Apache 2.1-dev status: I hit a bit of a hangup that must be debugged :( there are two pieces of code handling piped loggers: error log and mod_log_config... in 1.3, both handled shell operations... in 2.0, as you discovered, neither handles shell operations the patch you are using is fine AFAICT, but trying the same change to the code to handle piped error log results in quite a bit of unhappiness (no logging at all)... that needs to be tracked down before trying to fix half the problem Maybe out in left field, but could ErrorLog be moved from the core and into mod_log_config? Then, if mod_log_config is not present, or no ErrorLog directive is specified, then stderr can be used. Any special reason to keep it in the core? because it is a critical function? If it is able to format write to stderr if no module has taken over the function, most of the existing support is required anyway. And if core code does the work of formatting, then there is no use in an external module to have to do that. Apache 2.0 did add an error log hook so that modules can grab error log entries and log them however they want. So some mod_log_error (why clutter up mod_log_config) could handle error log; we'd just need a way to turn off the default error log.
Re: cvs commit: httpd-2.0/modules/generators mod_cgid.c
[EMAIL PROTECTED] wrote: +#ifdef _AIX see related thread [PATCH] apr function to see if an arbitrary process is alive on [EMAIL PROTECTED]
Re: Sending multiple responses
At 12:38 AM 11/7/2003, amit athavale wrote: Thanks Bill for the reply. My 2 cents (I am filter novice :) ) We need to create a new metadata bucket to pass on the Continue, or Processing, or other 1xx-style response codes. It needs to be processed by the HTTP filter so that these responses aren't inserted into 1.0 streams, or into the middle of a chunked response, etc. I observed one more thing : Filters such as http_header_filter removes itself from filter chain by calling ap_remove_output_filter. So this filter should take care that if I am sending 1xx kind of responses it should not remove it from chain, else in subsequent responses there are no headers. Of course. The best-case is to put this in the HTTP filter itself, I'm guessing. It's a very interesting request, thank you for posting it to the list, Amit! Actually it will become necessary when mod_dav will be pushed more into commercial arena. COPYing large collection etc are normal operations and often clients sets time-out of 120sec or so. Its necessary from UI perspective (could show progress bar etc.). I have no doubt, there are occasional; complains about long-running cgis and so forth timing out on the connection before the request is serviced. Cranking the timeout to 5 minutes isn't a healty solution, as another thread on this list points out. I hope there would be more cleaner way of doing it somewhere in future. :) Apache 2.1 is in development, and has a number of new-feature changes like SSL/TLS connection upgrade. This should be written against and committed to the new codebase, and may be backported if it doesn't break compatibility between 2.0 releases. I'll sketch something up today for you to play with. Bill
Re: piped log files
On Fri, Nov 07, 2003 at 05:57:25AM -0500, Jeff Trawick wrote: Glenn wrote: Maybe out in left field, but could ErrorLog be moved from the core and into mod_log_config? Then, if mod_log_config is not present, or no ErrorLog directive is specified, then stderr can be used. Any special reason to keep it in the core? because it is a critical function? If it is able to format write to stderr if no module has taken over the function, most of the existing support is required anyway. And if core code does the work of formatting, then there is no use in an external module to have to do that. Not so. You said yourself that the code that handles piped logs is in two places, once in the core and once in mod_log_config, and this prevented you from committing a patch which only fixed a problem in one of those places. The point of my message was to suggest getting rid of the duplicated code and moving the ErrorLog directive to mod_log_config (or elsewhere). I am not suggesting moving all error logging out of the core since I agree that it is critical, just moving the interface to direct log output elsewhere (other than stderr). Apache 2.0 did add an error log hook so that modules can grab error log entries and log them however they want. So some mod_log_error (why clutter up mod_log_config) could handle error log; we'd just need a way to turn off the default error log. I haven't looked at the Apache2 error logging code carefully -- I'm still trying to get a 4 line patch applied to Apache 1.3 error logging code. I was thinking along the lines of mod_log_config exporting a function to handle piped logs. If it exists, the core would send the formatted error message to that filter instead of to stderr. Of course, this function could even be abstracted from mod_log_config into a mod_log_gw log gateway which would take a formatted string and send it to a file, a pipe, redirected output, a database, etc. Main point: duplicated code == BAD. Cheers, Glenn
Re: piped log files
Glenn wrote: On Fri, Nov 07, 2003 at 05:57:25AM -0500, Jeff Trawick wrote: Glenn wrote: Maybe out in left field, but could ErrorLog be moved from the core and into mod_log_config? Then, if mod_log_config is not present, or no ErrorLog directive is specified, then stderr can be used. Any special reason to keep it in the core? because it is a critical function? If it is able to format write to stderr if no module has taken over the function, most of the existing support is required anyway. And if core code does the work of formatting, then there is no use in an external module to have to do that. Not so. You said yourself that the code that handles piped logs is in two places, once in the core and once in mod_log_config, and this prevented you from committing a patch which only fixed a problem in one of those places. no, I was trying to simplify this situation since I didn't figure anybody cared about the detail :) it would have been helpful if I had been more explicit both sets of code to handle piped loggers are in core... one set is *on behalf of* plug-ins such as mod_log_config I'm still trying to get a 4 line patch applied to Apache 1.3 error logging code. what/where is that? repost to [EMAIL PROTECTED] I was thinking along the lines of mod_log_config exporting a function to handle piped logs. what if somebody doesn't want the mainline function of mod_log_config and instead has a different logging module? does that different logging module have to implement the piped log feature also? Main point: duplicated code == BAD. understood, it just happens that it isn't a duplication between mod_log_config and core, but a duplication of core and core... certainly combining as much as possible is a good thing to do... personally I won't be doing any such thing until I know why the broken flavor is broken ;)
Re: Apache gprof profiling
Chris Knight wrote: Hi all, I found some mention of profiling Apache with gprof via google. I tried the following: % setenv CFLAGS '-pg -DGPROF -g' % ./configure [my configure flags] % make; make install; cd $PREFIX [alter the conf file to set the MaxRequestsPerChild to 1] % bin/httpd -X [make a request and close the connection, which should cause httpd to terminate normally.] I should end up with a gmon.out file that I can then feed to gprof, but I'm not. Is there a step I'm missing and/or is this possible? For that matter, is there any official documentation regarding profiling? (In reality I want to profile a particular module but I thought it would be interesting to profile all of Apache's internals as well to get a complete picture.) After Jeff graciously pointed out that some gprof changes had occurred in 2.1-dev, I decided to give it a try and sure enough I could get a gmon.out file. Then, after doing a bunch of diffs, I came to the conclusion that the code defguarded by NO_USE_SIGACTION was removed in 2.1 and I tried defining that, sure enough it works now. Huzzah! (Just thought I'd report in so someone else trying to profile 2.0 will not stumble across this problem.) So the way to get profiling in 2.0.48: % setenv CFLAGS '-pg -DGPROF -g -DNO_USE_SIGACTION' % ./configure [my configure flags] % make; make install; cd $PREFIX [alter the conf file to set the MaxRequestsPerChild to 1] % bin/httpd -X [make a request and close the connection] I had a suspicion it had something to do with signals (since you don't get a gmon.out unless the process dies normally). Anyways, fixed a bug in the code along the way. :^)
Re: Apache gprof profiling
Chris Knight wrote: After Jeff graciously pointed out that some gprof changes had occurred in 2.1-dev, I decided to give it a try and sure enough I could get a gmon.out file. Then, after doing a bunch of diffs, I came to the conclusion that the code defguarded by NO_USE_SIGACTION was removed in 2.1 and I tried defining that, sure enough it works now. Huzzah! (Just thought I'd report in so someone else trying to profile 2.0 will not stumble across this problem.) weird... there was some code in 2.0.48's prefork.c guarded by NO_USE_SIGACTION that was moved to mpm_common.c in 2.1-dev... it is supposed to be the same :) So the way to get profiling in 2.0.48: % setenv CFLAGS '-pg -DGPROF -g -DNO_USE_SIGACTION' I would normally assume that I broke it when I moved the signal setup related to coredumping signals to mpm_common.c in 2.1-dev. But I think you're saying that the modern sigaction() logic actually works in 2.1-dev, but in 2.0.48 you have to avoid the sigaction() via -DNO_USE_SIGACTION because it is broken :) Very weird. The big difference between sigaction flavor and no_use_sigaction flavor in 2.0.48 when httpd is started with -X option seems to be that the sigaction flavor sets up handlers for SIGXCPU and SIGXFSZ, whereas the no_use_sigaction flavor does not.
Re: [PATCH] ErrorLogsWithVhost for Apache 1.3.28
[REPOST] On Mon, Oct 13, 2003 at 02:52:33PM -0700, Roy T. Fielding wrote: On Tue, Jul 08, 2003 at 12:41:09AM -0400, Glenn wrote: Comments appreciated on the method(s) that would most likely get this accepted into 1.3.28 or 1.3.29. (global flag, server_rec addition, other ...) Thanks! In general, it would require a great deal of value added to justify a new feature in 1.3. I don't see that here. It certainly doesn't justify a change to server_rec (even an append is a risky change). A global flag is possible, but a compile-time ifdef would be sufficient for 1.3. Thank you very much for the explanation. My original patch used a global and can be found at: http://www.mail-archive.com/[EMAIL PROTECTED]/msg16898.html Here's one that uses a #define: diff -ru apache_1.3.28/src/main/http_log.c apache_1.3.28.new/src/main/http_log.c --- apache_1.3.28/src/main/http_log.c 2003-02-03 12:13:21.0 -0500 +++ apache_1.3.28.new/src/main/http_log.c 2003-10-13 19:27:47.0 -0400 @@ -388,8 +388,14 @@ * quad is the most secure, which is why I'm implementing it * first. -djg */ +#ifdef ERRORLOGS_WITH_VHOST + len += ap_snprintf(errstr + len, sizeof(errstr) - len, + [client %s] [%s:%d] , r-connection-remote_ip, + r-server-server_hostname, r-server-port); +#else len += ap_snprintf(errstr + len, sizeof(errstr) - len, [client %s] , r-connection-remote_ip); +#endif } if (!(level APLOG_NOERRNO) (save_errno != 0) I prefer having the ability in a directive because I am not always permitted to recompile Apache with the #define on systems that are kept distribution conformist. Thank you for your consideration. Glenn
[APACHE2] http://domain/ generating garbage output ...
I've just spent the past little while searching Google for anything that might shed some light on this, and am drawing a blank ... from what I can tell, it isn't a configuration issue (unless I'm missing a configuration setting), but I don't know how to debug it from the server end ... I just setup an Apache 2.0.48 server, and all the config files are 'the default' based on what FreeBSD installs from ports ... if I go to: http://domain I get a string of 'garbage'(high ascii?) characters across my browser, almost as if its reading the raw directory, but if I go to: http://domain/index.html the page comes up fine ... I have a DirectoryIndex in place: DirectoryIndex index.php index.html index.cgi index.htm home.htm And if I put an index.php file in place, it gets loaded up fine as just 'http://domain' ... but if I remove it, I have to references the index.html explicitly for me to get up a page ... I saw the FAQ items about MMAP and SendFile, but altho I did try them just in case, they dn't appear pertinent, since the index.html page is accessible if referenced directly, just not when referenced with the DirectoryIndex directive ... and from what I understand about those directives, the pages wouldn't load up either way, but I might be mis-understanding on that one ... I tried removing the index.php from the DirectoryIndex directive, but that didn't make any difference either ... I'm figuring that its something obvious I'm not seeing ... or a directive that I'm not finding? I have 2.0.47 on another machine that appears to be working as expected, so I'm curious as to whether its maybe a bug in 2.0.48 ... ? Help? Thanks ...
