Re: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate tarballs for review
Jim Jagielski wrote: Available for your testing pleasure, 3, count 'em, 3 [+1]apache_1.3.39 [+1]httpd-2.0.61 [+1]httpd-2.2.6 Thanks!! No, thank YOU :) Small chaos today as some reports contradicted my earlier testing, but I see no regressions, with the exception possibly of mod_fcgid which is playing with some internals of apr. Apparently mod_perl/mod_cgi do work as expected (better, in the case of mod_cgi). Bill
Re: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate tarballs for review
On 09/05/2007 04:29 PM, Plüm wrote: -Ursprüngliche Nachricht- Von: Jim Jagielski Gesendet: Dienstag, 4. September 2007 23:29 An: dev@httpd.apache.org; [EMAIL PROTECTED] Betreff: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate tarballs for review Available for your testing pleasure, 3, count 'em, 3 Apache HTTP Server release candidate tarballs, located, as expected at: http://httpd.apache.org/dev/dist/ This vote will run through Sept 6, 2007 and close Sept 7, unless otherwise noted... +/-1 (x == +1) [ ]apache_1.3.39 [ ]httpd-2.0.61 [ ]httpd-2.2.6 Results for 2.0.61 / 2.2.6: md5 / signature ok for .tar.gz / .tar.bz2. Solaris 9: 5.9 Generic_122300-05 sun4u sparc SUNW,UltraSPARC-IIi-cEngine Solaris gcc (GCC) 3.3.2 No regressions in the perl framework tests that can run on my box compared to 2.2.4 / 2.0.59. 2.0.61: Failed 6/63 test scripts, 90.48% okay. 21/1569 subtests failed, 98.66% okay. 2.2.6 : Failed 6/63 test scripts, 90.48% okay. 2/1579 subtests failed, 99.87% okay. Solaris 8: 5.8 Generic_117350-46 sun4u sparc SUNW,UltraSPARC-IIi-cEngine Solaris gcc (GCC) 3.3.2 Compiles and starts up fine (did not run the perl framework). Linux tests will follow with my votes. No regression on SuSE Linux 10.2 (32 bit). So +1 from me on 2.2.6 and 2.0.61 Regards Rüdiger
[mod_spelling] Not fixing directory names in 2.2?
Hi, i upgraded to Apache 2.2. But since that upgrade, mod_spelling does not fix misspelled directory names any more. An example: With Apache 2.0, the URL /jh/magdeburg/images/btn_home.gif was changed to /jh/magdeburg/Images/btn_home.gif With Apache 2.2, the first URL doesn't work anymore. But the URL /jh/magdeburg/images is still redirected to /jh/magdeburg/Images. So it seems, mod_spelling only checks the last URL component. Is that intentionally or a bug? And how could i get back old Apache 2.0 behaviour? Greetings, Sven signature.asc Description: OpenPGP digital signature
Re: [mod_spelling] Not fixing directory names in 2.2?
And how could i get back old Apache 2.0 behaviour? OK, found a sollution here: http://issues.apache.org/bugzilla/show_bug.cgi?id=38635 signature.asc Description: OpenPGP digital signature
Re: [mod_spelling] Not fixing directory names in 2.2?
torsdagen den 6 september 2007 skrev Sven Köhler: Hi, i upgraded to Apache 2.2. But since that upgrade, mod_spelling does not fix misspelled directory names any more. An example: With Apache 2.0, the URL /jh/magdeburg/images/btn_home.gif was changed to /jh/magdeburg/Images/btn_home.gif With Apache 2.2, the first URL doesn't work anymore. But the URL /jh/magdeburg/images is still redirected to /jh/magdeburg/Images. So it seems, mod_spelling only checks the last URL component. Is that intentionally or a bug? And how could i get back old Apache 2.0 behaviour? IfModule mod_speling.c CheckSpelling On AcceptPathInfo On /IfModule -- Regards // Oden Eriksson
influencing mod_proxy via request_status hook
(If this is better directed at another Apache httpd tech list, please
let me know.)
I'm trying to modify the behaviour of mod_proxy via its optional
request_status hook. I want Apache to use mod_cache's local copy of
a file if it can't verify it with the remote, reverse-proxied server
(server down, or not responding, etc.)
The VirtualHost's Cache and Proxy is configured like this:
CacheRoot /var/cache
CacheEnable disk /
ProxyRequests Off
ProxyVia On
Proxy *
Order allow,deny
Allow from all
/Proxy
ProxyPass /path http://realserver/path
ProxyPassReverse /path http://realserver/path
ProxyRemote * http://proxyserver:8080/
The requests are just GETs. realserver is the remote server hostname,
and proxyserver is the in-between proxy server that the request must
go through (just for that added extra complication.)
I've successfully got my own module being called via the request_status
hook every time. But I can't seem to then make mod_proxy act as if it
had got a 304 HTTP_NOT_MODIFIED from the remote server (which is what
it would normally get if the remote server were to respond) and so
use the locally cached copy of the file.
Whenever the remote server is down, I get the 5xx error from the in-between
proxy. If I take the in-between proxy down, I get an error from within
Apache.
Here's my module's code:
#include httpd.h
#include ap_config.h
#include mod_core.h
#include mod_proxy.h
static int proxy_request_status_handler ( int *status, request_rec *r )
{
ap_log_error(APLOG_MARK,APLOG_ERR,OK,NULL,request_status hook called (%s):
%d (%d), r-server-server_hostname, *status, r-status);
if ( r-status = HTTP_INTERNAL_SERVER_ERROR ) {
*status = DECLINED;
ap_log_error(APLOG_MARK,APLOG_ERR,OK,NULL,request_status hook declined:
%d (%d), *status, r-status);
}
}
static void my_register_hooks(apr_pool_t *p)
{
APR_OPTIONAL_HOOK(proxy, request_status, proxy_request_status_handler,
NULL, NULL, APR_HOOK_MIDDLE );
}
module AP_MODULE_DECLARE_DATA my_module =
{
STANDARD20_MODULE_STUFF,
NULL, /* create per-dir config */
NULL, /* merge per-dir config */
NULL, /* server config */
NULL, /* merge server config */
NULL, /* command apr_table_t */
my_register_hooks /* register hooks */
};
Here I'm setting the status code to DECLINED, but I've also tried
setting it to HTTP_NOT_MODIFIED, and I've tried setting the remote
r-status to that too. Clearly that's the wrong thing to do.
What should I be setting? Or should I do this a different way altogether?
James.
Re: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate tarballs for review
On Sep 4, 2007, at 5:29 PM, Jim Jagielski wrote: Available for your testing pleasure, 3, count 'em, 3 Apache HTTP Server release candidate tarballs, located, as expected at: http://httpd.apache.org/dev/dist/ This vote will run through Sept 6, 2007 and close Sept 7, unless otherwise noted... So far, I see nothing yet preventing us from releasing this tomorrow... assuming that stays the same, I will move the files over to the main dist location to allow mirrors to start snagging and allow us a real release and announcement tomorrow.
Re: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate tarballs for review
k I the meantime we have to advise the users not to use 2.2.6 because is not compatible with some mods (not just mod_fcgid). We shall advise to stay on 2.2.4 or 2.2.5 RC. Steffen www.apachelounge.com - Original Message - From: Jim Jagielski [EMAIL PROTECTED] To: dev@httpd.apache.org Cc: [EMAIL PROTECTED] Sent: Thursday, 06 September, 2007 15:48 Subject: Re: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate tarballs for review On Sep 4, 2007, at 5:29 PM, Jim Jagielski wrote: Available for your testing pleasure, 3, count 'em, 3 Apache HTTP Server release candidate tarballs, located, as expected at: http://httpd.apache.org/dev/dist/ This vote will run through Sept 6, 2007 and close Sept 7, unless otherwise noted... So far, I see nothing yet preventing us from releasing this tomorrow... assuming that stays the same, I will move the files over to the main dist location to allow mirrors to start snagging and allow us a real release and announcement tomorrow.
Re: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate tarballs for review
An other report: mod_cgi is working OK for me with the Apache 2.2.6 RC, which I built with VC6 - not VC8, on Win2k sp4. I can run the Apache-provided /cgi-bin/printenv.pl test Perl program with no problems. mod_fcgid is not working for me, either with Perl or with my own FCGI test program. Steffen - Original Message - From: Jim Jagielski [EMAIL PROTECTED] To: dev@httpd.apache.org Cc: [EMAIL PROTECTED] Sent: Thursday, 06 September, 2007 15:48 Subject: Re: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate tarballs for review On Sep 4, 2007, at 5:29 PM, Jim Jagielski wrote: Available for your testing pleasure, 3, count 'em, 3 Apache HTTP Server release candidate tarballs, located, as expected at: http://httpd.apache.org/dev/dist/ This vote will run through Sept 6, 2007 and close Sept 7, unless otherwise noted... So far, I see nothing yet preventing us from releasing this tomorrow... assuming that stays the same, I will move the files over to the main dist location to allow mirrors to start snagging and allow us a real release and announcement tomorrow.
Re: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate tarballs for review
On Sep 6, 2007, at 11:05 AM, Steffen wrote: k I the meantime we have to advise the users not to use 2.2.6 because is not compatible with some mods (not just mod_fcgid). We shall advise to stay on 2.2.4 or 2.2.5 RC. What other mods is it not compatible with? So far, I haven't heard anyone else confirm your reports. Also, as you know, there was no 2.2.5 released, so make sure that if they do bother to use that, not to post anything on the user or dev lists saying I'm using 2.2.5 and... because it is likely they will be ignored :) I'm assuming the we is you, right?
Re: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate tarballs for review
Did you rebuild mod_fcgid? On Sep 6, 2007, at 11:08 AM, Steffen wrote: An other report: mod_cgi is working OK for me with the Apache 2.2.6 RC, which I built with VC6 - not VC8, on Win2k sp4. I can run the Apache-provided /cgi-bin/printenv.pl test Perl program with no problems. mod_fcgid is not working for me, either with Perl or with my own FCGI test program. Steffen - Original Message - From: Jim Jagielski [EMAIL PROTECTED] To: dev@httpd.apache.org Cc: [EMAIL PROTECTED] Sent: Thursday, 06 September, 2007 15:48 Subject: Re: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate tarballs for review On Sep 4, 2007, at 5:29 PM, Jim Jagielski wrote: Available for your testing pleasure, 3, count 'em, 3 Apache HTTP Server release candidate tarballs, located, as expected at: http://httpd.apache.org/dev/dist/ This vote will run through Sept 6, 2007 and close Sept 7, unless otherwise noted... So far, I see nothing yet preventing us from releasing this tomorrow... assuming that stays the same, I will move the files over to the main dist location to allow mirrors to start snagging and allow us a real release and announcement tomorrow.
Re: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate tarballs for review
On Sep 6, 2007, at 9:48 AM, Jim Jagielski wrote: So far, I see nothing yet preventing us from releasing this tomorrow... assuming that stays the same, I will move the files over to the main dist location to allow mirrors to start snagging and allow us a real release and announcement tomorrow. I'm copying the files to the real dist location as we speak...
Re: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate tarballs for review
I'm assuming the we is you, right? It is not just me. We are a team and of course the users. Just as an example the other post from me here which is a report from an other webmaster. I report here test results from the Apache Windows Community from the Apache Lounge, mostly I receive them by mail. To give an idea, there are almost 80.000 thousand downloads 2.2.4 from the two primary sites of the Apache Lounge. I have no figures from the mirrors and others who are making it available, I think an extra few thousand. I respect that you want to release. But it is a pity that we have leave them in the dark with 2.2.6 . But on the other hand, for me, 2.2.6 has minor changes over 2.2.5. Maybe we have to patch 2.2.6 to get it error-free. Yes we all aware that 2.2.5 is not released and when they download they are informed that it is/was a test-release. Don't worry too much, not a lot windows users are posting on the lists. I shall put a an extra note that they cannot expect response on the lists. Btw. The authors of the modules are investigating the issues right now. I do not expect that they are coming soon with solutions. Steffen - Original Message - From: Jim Jagielski [EMAIL PROTECTED] To: dev@httpd.apache.org Sent: Thursday, 06 September, 2007 17:52 Subject: Re: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate tarballs for review On Sep 6, 2007, at 11:05 AM, Steffen wrote: k I the meantime we have to advise the users not to use 2.2.6 because is not compatible with some mods (not just mod_fcgid). We shall advise to stay on 2.2.4 or 2.2.5 RC. What other mods is it not compatible with? So far, I haven't heard anyone else confirm your reports. Also, as you know, there was no 2.2.5 released, so make sure that if they do bother to use that, not to post anything on the user or dev lists saying I'm using 2.2.5 and... because it is likely they will be ignored :) I'm assuming the we is you, right?
Re: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate tarballs for review
I did, not sure the guy from the report below did. The author(s) of mod_fcgid looking at the issue right now. Do not expect that there is a solution from them soon. I do not now how many users are affected by the bug(s) in 2.2.6 . I guess there are thousands users running mod-fcgid , special heavy loaded sites. The guess is based on the ~80.000 downloads of 2.2.4 from the www.apachelounge.com . And also now a days quite some users Win 32 building Apache. Steffen - Original Message - From: Jim Jagielski [EMAIL PROTECTED] To: dev@httpd.apache.org Sent: Thursday, 06 September, 2007 17:53 Subject: Re: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate tarballs for review Did you rebuild mod_fcgid? On Sep 6, 2007, at 11:08 AM, Steffen wrote: An other report: mod_cgi is working OK for me with the Apache 2.2.6 RC, which I built with VC6 - not VC8, on Win2k sp4. I can run the Apache-provided /cgi-bin/printenv.pl test Perl program with no problems. mod_fcgid is not working for me, either with Perl or with my own FCGI test program. Steffen - Original Message - From: Jim Jagielski [EMAIL PROTECTED] To: dev@httpd.apache.org Cc: [EMAIL PROTECTED] Sent: Thursday, 06 September, 2007 15:48 Subject: Re: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate tarballs for review On Sep 4, 2007, at 5:29 PM, Jim Jagielski wrote: Available for your testing pleasure, 3, count 'em, 3 Apache HTTP Server release candidate tarballs, located, as expected at: http://httpd.apache.org/dev/dist/ This vote will run through Sept 6, 2007 and close Sept 7, unless otherwise noted... So far, I see nothing yet preventing us from releasing this tomorrow... assuming that stays the same, I will move the files over to the main dist location to allow mirrors to start snagging and allow us a real release and announcement tomorrow.
Re: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate tarballs for review
Better we stop this thread. See the post at: http://www.apachelounge.com/forum/viewtopic.php?p=8691 , please do not reply to that post. Steffen - Original Message - From: Jim Jagielski [EMAIL PROTECTED] To: dev@httpd.apache.org Sent: Thursday, 06 September, 2007 21:47 Subject: Re: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate tarballs for review On Sep 6, 2007, at 3:25 PM, Steffen wrote: I'm assuming the we is you, right? It is not just me. We are a team and of course the users. Just as an example the other post from me here which is a report from an other webmaster. I report here test results from the Apache Windows Community from the Apache Lounge, mostly I receive them by mail. You said that we need to: advise the users not to use 2.2.6 because is not compatible with some mods which, afaik, is not the case. You reported issues with mod_fcgid, which may be true, but that hasn't been confirmed by anyone else, nor do I see reports to support the some mods statement as well. Unless, of course, the cryptic phrase An other report actually means The below is a report from someone else who is also seeing an issue instead of Oh, by the way, I also tried this personally and I see that mod_cgi is working OK for me.. With all this being the case, I can't see holding up a release nor can I see us (us being the ASF) making some blanket statement that Win32 users should not use 2.2.6 because it is not compatible with some mods... If we had some more supporting data for that, then maybe... Maybe we have to patch 2.2.6 to get it error-free. Well, there is the patches directory that, if we discover a bug, allows people to download the patch and rebuild. Of course, this all means tracking down and discovering the bug with some detailed debugging info rather than a it doesn't work :)
Re: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate tarballs for review
Ummm hrmm: A hurry backport is causing this and there is hardly tested in real live. Hopefully ASF comes with a patch soon. So you know what's causing this? Please point out the exact hurry backport so we can look there. And again, WHAT OTHER 3rd party modules are having problems?? Can you provide ANY FURTHER information other than cryptic its not working messages followed by ASF hates Windows users comments?? If we *knew* what the problems were, we'd try like heck to fix 'em. I know Bill looked hard and long, but had no luck, mostly because the amount of real concrete data was woefully lacking. On Sep 6, 2007, at 4:08 PM, Steffen wrote: Better we stop this thread. See the post at: http://www.apachelounge.com/forum/viewtopic.php? p=8691 , please do not reply to that post. Steffen - Original Message - From: Jim Jagielski [EMAIL PROTECTED] To: dev@httpd.apache.org Sent: Thursday, 06 September, 2007 21:47 Subject: Re: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate tarballs for review On Sep 6, 2007, at 3:25 PM, Steffen wrote: I'm assuming the we is you, right? It is not just me. We are a team and of course the users. Just as an example the other post from me here which is a report from an other webmaster. I report here test results from the Apache Windows Community from the Apache Lounge, mostly I receive them by mail. You said that we need to: advise the users not to use 2.2.6 because is not compatible with some mods which, afaik, is not the case. You reported issues with mod_fcgid, which may be true, but that hasn't been confirmed by anyone else, nor do I see reports to support the some mods statement as well. Unless, of course, the cryptic phrase An other report actually means The below is a report from someone else who is also seeing an issue instead of Oh, by the way, I also tried this personally and I see that mod_cgi is working OK for me.. With all this being the case, I can't see holding up a release nor can I see us (us being the ASF) making some blanket statement that Win32 users should not use 2.2.6 because it is not compatible with some mods... If we had some more supporting data for that, then maybe... Maybe we have to patch 2.2.6 to get it error-free. Well, there is the patches directory that, if we discover a bug, allows people to download the patch and rebuild. Of course, this all means tracking down and discovering the bug with some detailed debugging info rather than a it doesn't work :)
Re: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate tarballs for review
On Thu, Sep 06, 2007 at 09:48:28AM -0400, Jim Jagielski wrote: On Sep 4, 2007, at 5:29 PM, Jim Jagielski wrote: Available for your testing pleasure, 3, count 'em, 3 Apache HTTP Server release candidate tarballs, located, as expected at: http://httpd.apache.org/dev/dist/ This vote will run through Sept 6, 2007 and close Sept 7, unless otherwise noted... So far, I see nothing yet preventing us from releasing this tomorrow... assuming that stays the same, I will move the files over to the main dist location to allow mirrors to start snagging and allow us a real release and announcement tomorrow. Any chance I can test for bugs on BSD/OS ? The last time it was major. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -- Member - Liberal International This is [EMAIL PROTECTED] Ici [EMAIL PROTECTED] God Queen and country! Beware Anti-Christ rising! PAtriots! MAke your declaration of loyalty! -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Re: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate tarballs for review
On Sep 6, 2007, at 4:33 PM, The Doctor wrote: Any chance I can test for bugs on BSD/OS ? The last time it was major. Well, we are pushing out to mirrors, but that shouldn't stop people from testing... If something shows up we have options, the best option being determined by the kind of bug, the severity, etc...
Re: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate tarballs for review
I am a typical Windows user and not a developer. Yes I can build with VC and can do little adjustments in C++ Sorry I cannot give more info, it is just not working with no signs in the Apache logs. As I told, the authors are looking at it, had to wait when they have more info. Maybe I am thinking to simple, 2.2.6 contains some backports over 2.2.5 so a big change that one of lines in the change log must cause this. Oh btw, we/I do not hate ASF at all, we Windows users sometimes crying for a little more attention. This is the main reason that the Apache Lounge is started. Can we stop now this discussion ? Steffen - Original Message - From: Jim Jagielski [EMAIL PROTECTED] To: dev@httpd.apache.org Sent: Thursday, 06 September, 2007 22:20 Subject: Re: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate tarballs for review Ummm hrmm: A hurry backport is causing this and there is hardly tested in real live. Hopefully ASF comes with a patch soon. So you know what's causing this? Please point out the exact hurry backport so we can look there. And again, WHAT OTHER 3rd party modules are having problems?? Can you provide ANY FURTHER information other than cryptic its not working messages followed by ASF hates Windows users comments?? If we *knew* what the problems were, we'd try like heck to fix 'em. I know Bill looked hard and long, but had no luck, mostly because the amount of real concrete data was woefully lacking. On Sep 6, 2007, at 4:08 PM, Steffen wrote: Better we stop this thread. See the post at: http://www.apachelounge.com/forum/viewtopic.php? p=8691 , please do not reply to that post. Steffen - Original Message - From: Jim Jagielski [EMAIL PROTECTED] To: dev@httpd.apache.org Sent: Thursday, 06 September, 2007 21:47 Subject: Re: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate tarballs for review On Sep 6, 2007, at 3:25 PM, Steffen wrote: I'm assuming the we is you, right? It is not just me. We are a team and of course the users. Just as an example the other post from me here which is a report from an other webmaster. I report here test results from the Apache Windows Community from the Apache Lounge, mostly I receive them by mail. You said that we need to: advise the users not to use 2.2.6 because is not compatible with some mods which, afaik, is not the case. You reported issues with mod_fcgid, which may be true, but that hasn't been confirmed by anyone else, nor do I see reports to support the some mods statement as well. Unless, of course, the cryptic phrase An other report actually means The below is a report from someone else who is also seeing an issue instead of Oh, by the way, I also tried this personally and I see that mod_cgi is working OK for me.. With all this being the case, I can't see holding up a release nor can I see us (us being the ASF) making some blanket statement that Win32 users should not use 2.2.6 because it is not compatible with some mods... If we had some more supporting data for that, then maybe... Maybe we have to patch 2.2.6 to get it error-free. Well, there is the patches directory that, if we discover a bug, allows people to download the patch and rebuild. Of course, this all means tracking down and discovering the bug with some detailed debugging info rather than a it doesn't work :)
Re: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate tarballs for review
On 9/6/07, Jim Jagielski [EMAIL PROTECTED] wrote: ASF hates Windows users comments?? I usually prefure not to poke my nose into other peoples discussions but... my experience with the ASF is that they threat windows users equally than linux/unix/whatever users. The problem is windows users generally don't compile things them selfs and let others do it. So they don't know the code as wel or at all compared to other users who report bugs on linux. Windows users (my self included) usually go like: Dudez XYZ is broken, Fix it, Fix it, Fix it. When the dev's look at it and ask for more information they usually don't get it. So it isn't fixed at all or as fast as a linux bug would be. While people having bugs or minor problems on unix/linux/bsd/... sometimes provide a ready cooked patch that with a few tweaks can be imported into the source tree and the problem is gone. Note: I'm in no way accusing steffen of not providing or trying to provide more information. I myself can't usually can't. I remember me spamming wrowe's inbox for x64 fixed. After lots of attempts I did manged to get it working. I'll try to see if I can find out why mod_fcgid isn't working but like so many windows users I don't the programing language used. I can read tiny bits of it with my experience in other language but thats about it. -- ~Jorge
Re: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate tarballs for review
I tried to compiled mod_fcgid myself to see if I can replicate the problem. I can't even compiled it against 2.2.6. I get a lot of link errors agains APR. --- complete buildlog availble on request but nothing odd until this --- 1fcgid_spawn_ctl.obj : error LNK2019: unresolved external symbol __imp__ap_log_error referenced in function _spawn_control_init 1mod_fcgid.obj : error LNK2001: unresolved external symbol __imp__ap_log_error 1fcgid_pm_win.obj : error LNK2001: unresolved external symbol __imp__ap_log_error 1fcgid_proc_win.obj : error LNK2001: unresolved external symbol __imp__ap_log_error 1fcgid_proctbl_win.obj : error LNK2001: unresolved external symbol __imp__ap_log_error 1fcgid_protocol.obj : error LNK2001: unresolved external symbol __imp__ap_log_error 1fcgid_bridge.obj : error LNK2001: unresolved external symbol __imp__ap_log_error 1fcgid_bucket.obj : error LNK2001: unresolved external symbol __imp__ap_log_error 1fcgid_filter.obj : error LNK2001: unresolved external symbol __imp__ap_log_error 1fcgid_pm_main.obj : error LNK2001: unresolved external symbol __imp__ap_log_error 1fcgid_bridge.obj : error LNK2019: unresolved external symbol [EMAIL PROTECTED] referenced in function _bucket_ctx_cleanup 1fcgid_pm_main.obj : error LNK2001: unresolved external symbol [EMAIL PROTECTED] 1fcgid_spawn_ctl.obj : error LNK2001: unresolved external symbol [EMAIL PROTECTED] 1fcgid_bridge.obj : error LNK2001: unresolved external symbol __imp__apr_bucket_type_immortal 1fcgid_filter.obj : error LNK2001: unresolved external symbol __imp__apr_bucket_type_immortal 1fcgid_bridge.obj : error LNK2001: unresolved external symbol __imp__apr_bucket_type_eos 1fcgid_filter.obj : error LNK2001: unresolved external symbol __imp__apr_bucket_type_eos 1fcgid_proc_win.obj : error LNK2019: unresolved external symbol __imp__apr_bucket_type_eos referenced in function _proc_spawn_process 1fcgid_bridge.obj : error LNK2019: unresolved external symbol [EMAIL PROTECTED] referenced in function _handle_request 1fcgid_filter.obj : error LNK2001: unresolved external symbol [EMAIL PROTECTED] 1fcgid_bridge.obj : error LNK2019: unresolved external symbol [EMAIL PROTECTED] referenced in function _handle_request 1fcgid_bridge.obj : error LNK2019: unresolved external symbol [EMAIL PROTECTED] referenced in function _handle_request 1mod_fcgid.obj : error LNK2001: unresolved external symbol [EMAIL PROTECTED] 1fcgid_bridge.obj : error LNK2019: unresolved external symbol [EMAIL PROTECTED] referenced in function _handle_request 1fcgid_bridge.obj : error LNK2019: unresolved external symbol [EMAIL PROTECTED] referenced in function _handle_request 1fcgid_conf.obj : error LNK2001: unresolved external symbol [EMAIL PROTECTED] 1mod_fcgid.obj : error LNK2001: unresolved external symbol [EMAIL PROTECTED] 1fcgid_bridge.obj : error LNK2019: unresolved external symbol [EMAIL PROTECTED] referenced in function _handle_request 1fcgid_bridge.obj : error LNK2019: unresolved external symbol [EMAIL PROTECTED] referenced in function _handle_request 1fcgid_filter.obj : error LNK2001: unresolved external symbol [EMAIL PROTECTED] 1fcgid_bridge.obj : error LNK2019: unresolved external symbol [EMAIL PROTECTED] referenced in function _handle_request 1fcgid_pm_main.obj : error LNK2001: unresolved external symbol [EMAIL PROTECTED] 1fcgid_pm_win.obj : error LNK2001: unresolved external symbol [EMAIL PROTECTED] 1fcgid_bridge.obj : error LNK2019: unresolved external symbol [EMAIL PROTECTED] referenced in function _handle_request 1fcgid_pm_win.obj : error LNK2001: unresolved external symbol [EMAIL PROTECTED] 1fcgid_proc_win.obj : error LNK2001: unresolved external symbol [EMAIL PROTECTED] 1fcgid_proc_win.obj : error LNK2001: unresolved external symbol __imp__apr_pool_cleanup_null 1mod_fcgid.obj : error LNK2001: unresolved external symbol __imp__apr_pool_cleanup_null 1fcgid_bridge.obj : error LNK2019: unresolved external symbol __imp__apr_pool_cleanup_null referenced in function _handle_request 1fcgid_conf.obj : error LNK2001: unresolved external symbol __imp__apr_pool_cleanup_null 1fcgid_pm_main.obj : error LNK2001: unresolved external symbol __imp__apr_pool_cleanup_null 1fcgid_pm_win.obj : error LNK2001: unresolved external symbol __imp__apr_pool_cleanup_null 1fcgid_spawn_ctl.obj : error LNK2001: unresolved external symbol [EMAIL PROTECTED] 1mod_fcgid.obj : error LNK2001: unresolved external symbol [EMAIL PROTECTED] 1fcgid_bridge.obj : error LNK2019: unresolved external symbol [EMAIL PROTECTED] referenced in function _handle_request 1fcgid_conf.obj : error LNK2001: unresolved external symbol [EMAIL PROTECTED] 1fcgid_proc_win.obj : error LNK2001: unresolved external symbol [EMAIL PROTECTED] 1fcgid_proctbl_win.obj : error LNK2001: unresolved external symbol [EMAIL PROTECTED] 1fcgid_bridge.obj : error LNK2019: unresolved external symbol [EMAIL PROTECTED] referenced in function _bridge_request 1fcgid_bridge.obj : error LNK2019: unresolved external symbol [EMAIL PROTECTED] referenced in
Re: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate tarballs for review
Steffen wrote: I the meantime we have to advise the users not to use 2.2.6 because is not compatible with some mods (not just mod_fcgid). We shall advise to stay on 2.2.4 or 2.2.5 RC. If you would like to clear up FUD (some mods) with explicit mods that would be productive. It would also be productive to discuss your concern with the mod_fcgid maintainers, as the apr behavior is not likely to be regressed to the previous behavior of leaking file handles (which I suspect mod_fcgid had leveraged). If I understand your later post; mod_fcgid is not working for me, either with Perl or with my own FCGI test program. your issues with mod_perl were in conjunction -with- mod_fcgid? Just trying to narrow down the focus. Bill
Re: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate tarballs for review
Jorge Schrauwen wrote: Windows users (my self included) usually go like: Dudez XYZ is broken, Fix it, Fix it, Fix it. When the dev's look at it and ask for more information they usually don't get it. So it isn't fixed at all or as fast as a linux bug would be. You know, you hit the nail on the head. http://httpd.apache.org/dev/debugging.html has some great information, presuming the distributor of your win32 binaries actually provides the .pdb debugging context files that are required to emit a legible backtrace. (Ok, not strictly required, a significantly less helpful backtrace is emitted without .pdb's, no arguments from the call stack for example, but only if the recommended /Oy- flag is passed to the compiler. OpenSSL doesn't enable this flag by default, so a crash behind an openssl callback from a stock build of openssl will produce an entirely illegible backtrace.) I'm going to rip section 2 of that document in two, one for live backtraces, and a second for JIT/postmortem backtraces, since these seem shrouded in mystery from many users/developers (and they shouldn't be). Bill
Re: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate tarballs for review
Jorge Schrauwen wrote: I tried to compiled mod_fcgid myself to see if I can replicate the problem. I can't even compiled it against 2.2.6. I get a lot of link errors agains APR. Silly question, did you add libapr-1.lib, libaprutil-1.lib libhttpd.lib to the link command? (Worse, if you did add apr-1.lib aprutil-1.lib, those are static libraries and wouldn't even interface into the running instance of the libraries in a running httpd process). Bill
Re: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate tarballs for review
The later post was a report of an other tester, sorry no answer I have. Yes, I dicusssed it with the maintainer of mod_fcgid today. He is puzzling now an as I told before, we have to wait. Oh, btw: mod_perl (also build with VC8) is not working with 2.2.6, with 2.2.5 RC no single issue. Steffen - Original Message - From: William A. Rowe, Jr. [EMAIL PROTECTED] To: dev@httpd.apache.org Sent: Thursday, 06 September, 2007 23:22 Subject: Re: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate tarballs for review Steffen wrote: I the meantime we have to advise the users not to use 2.2.6 because is not compatible with some mods (not just mod_fcgid). We shall advise to stay on 2.2.4 or 2.2.5 RC. If you would like to clear up FUD (some mods) with explicit mods that would be productive. It would also be productive to discuss your concern with the mod_fcgid maintainers, as the apr behavior is not likely to be regressed to the previous behavior of leaking file handles (which I suspect mod_fcgid had leveraged). If I understand your later post; mod_fcgid is not working for me, either with Perl or with my own FCGI test program. your issues with mod_perl were in conjunction -with- mod_fcgid? Just trying to narrow down the focus. Bill
Re: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate tarballs for review
On 9/6/07, Steffen [EMAIL PROTECTED] wrote: The later post was a report of an other tester, sorry no answer I have. Yes, I dicusssed it with the maintainer of mod_fcgid today. He is puzzling now an as I told before, we have to wait. Oh, btw: mod_perl (also build with VC8) is not working with 2.2.6, with 2.2.5 RC no single issue. Odd works fine with my limited setup over here. I you want to try my binary? Steffen - Original Message - From: William A. Rowe, Jr. [EMAIL PROTECTED] To: dev@httpd.apache.org Sent: Thursday, 06 September, 2007 23:22 Subject: Re: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate tarballs for review Steffen wrote: I the meantime we have to advise the users not to use 2.2.6 because is not compatible with some mods (not just mod_fcgid). We shall advise to stay on 2.2.4 or 2.2.5 RC. If you would like to clear up FUD (some mods) with explicit mods that would be productive. It would also be productive to discuss your concern with the mod_fcgid maintainers, as the apr behavior is not likely to be regressed to the previous behavior of leaking file handles (which I suspect mod_fcgid had leveraged). If I understand your later post; mod_fcgid is not working for me, either with Perl or with my own FCGI test program. your issues with mod_perl were in conjunction -with- mod_fcgid? Just trying to narrow down the focus. Bill -- ~Jorge
Re: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate tarballs for review
On 9/6/07, William A. Rowe, Jr. [EMAIL PROTECTED] wrote: Jorge Schrauwen wrote: I tried to compiled mod_fcgid myself to see if I can replicate the problem. I can't even compiled it against 2.2.6. I get a lot of link errors agains APR. Silly question, did you add libapr-1.lib, libaprutil-1.lib libhttpd.lib to the link command? I have no idea... I update all the paths for via the project properties so the pointed to my httpd-2.2.6 source dir since that what it seems to want. Usually thats enough to get it to compile and run fine. Any ideas to where to look? (providing the sln, vcproj etc help?) http://dev.blackdot.be/mod_fcgid.2.1.zip This should be online untill I head of to bed in 2h if you want to have a look. note: I have my httpd-2.2(.6) folder located 2 directories above the current one. httpd-2.2 modules/mod_fcgid modules/mod_perl modules/blabla Once/if I get it to compile and it doesn't work I'll try to provide you with a back trace... all I need to do is rebuild my httpd and not delete the *.pdb's this time round. So I definitely have them available (Worse, if you did add apr-1.lib aprutil-1.lib, those are static libraries and wouldn't even interface into the running instance of the libraries in a running httpd process). Bill -- ~Jorge
Re: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate tarballs for review
Steffen wrote: Oh, btw: mod_perl (also build with VC8) is not working with 2.2.6, with 2.2.5 RC no single issue. Perl, mod_perl, httpd and apr all built with VC8? Or is this AS perl or some other? Bill
Re: mod_proxy: Is smax=0 allowed ?
Phil Endecott wrote:
[EMAIL PROTECTED] wrote:
Seems like you are right about the smax=0.
Luckily for you, according to the documentation you may control the persistency
of the backend connection with the environment variable proxy-nokeepalive
Well, I can use that to switch of persistency, i.e. I can get smax=0
ttl=0. I don't think I can use that to get smax=0 ttl=60, can I?
I'm going to have another look at the source, and see whether I can
change the sentinel value for smax not specified from 0 to -1, so
that 0 can really mean zero.
I have tried the following:
Index: proxy_util.c
===
--- proxy_util.c(revision 573391)
+++ proxy_util.c(working copy)
@@ -1752,7 +1752,7 @@
if (worker-hmax == 0 || worker-hmax mpm_threads) {
worker-hmax = mpm_threads;
}
-if (worker-smax == 0 || worker-smax worker-hmax) {
+if (worker-smax == -1 || worker-smax worker-hmax) {
worker-smax = worker-hmax;
}
/* Set min to be lower then smax */
Index: mod_proxy.c
===
--- mod_proxy.c (revision 573391)
+++ mod_proxy.c (working copy)
@@ -1263,6 +1263,7 @@
}
PROXY_COPY_CONF_PARAMS(worker, conf);
+worker-smax = -1;
for (i = 0; i arr-nelts; i++) {
const char *err = set_worker_param(cmd-pool, worker, elts[i].key,
elts[i].val);
This does seem to result in smax=0 being used, but it breaks something;
as far as I can see the requests never reach the backend. I have taken
the source from trunk and am loading the module into my 2.2.4 server; I
suppose that's far from certain to work. Or maybe the APR reslist is
not designed to work with smax=0.
I would much appreciate some input from someone who knows their way
around this code.
Regards,
Phil.
Re: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate tarballs for review
Steffen wrote: The later post was a report of an other tester, sorry no answer I have. Yes, I dicusssed it with the maintainer of mod_fcgid today. He is puzzling now an as I told before, we have to wait. Before he puzzles too long, you might want to ensure you have a full rebuild of mod_fcgid against apr-1.2.11, that is the one bundled in the new httpd-2.2.6. If it *did* use include/arch/win32/*.h files (which does *not* following the versioning rules, because those entries are strictly private to the library) --- there's a good chance that a new module build is required. It occurred to me that since the authors do probably delve into the win32 internals, you might want to check this out.
Re: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate tarballs for review
+1 httpd-2.2.6, OS X 10.4.10, gcc 4.0.1 Roy
