Re: # of threads needed to run winnt mpm correlates to # of vhosts

[William A. Rowe, Jr.]

How interesting!  thanks for the discovery... FirstBill actually created the
connection threadpool for mpm_winnt, iirc, so i'll punt to him or tackle
next week.   

At 11:50 AM 3/9/2004, Stas Bekman wrote:
>Steve Hay wrote:
>>Steve Hay wrote:
>>
>>>I'll try chopping some of the new (post _12) tests out to see if I can get it 
>>>working again.
>>If I remove:
>>t/htdocs/vhost/startup.pl
>>t/response/TestVhost/config.pm
>>t/vhost/config.t
>>then run "t/TEST -conf" and then try "nmake test" again, then it's all OK with 20 
>>threads.
>
>Would it make any difference if you remove some other vhost, and not this specific 
>one? e.g. one of the perlloadmodule\d.pm vhosts?
>
>>Increasing ThreadsPerChild to 50 was overkill, though -- it actually works fine 
>>(with the vhost tests back in) with just 21 threads.  Looks like the new vhost tests 
>>need 1 extra thread.
>
>Perfect, Steve. We have 20 vhosts and 1 main server => 21. So I suppose we need to 
>change A-T to figure out how many vhosts it's going to run and configure that number 
>of threads plus a few more (let's say 5-10 more).
>
>Bill, can you please explain why each vhost requires a thread with winnt mpm?
>Is this documented somewhere? Thanks!
>
>>Interestingly, the number of threads required seems to be quite specific.  If I have 
>>20 specified instead of the 21 that it needs then I get this in the error_log:
>>Server ran out of threads to serve requests. Consider raising the 
>> ThreadsPerChild setting
>>If I specify 19 threads then I get that error 2 times; if I specify 18 threads then 
>>I get it 3 times; ...if I specify 21-X threads then I get it X times.
>>Without the vhost tests, if I specify 20-X threads then I get the error X times.
>>Is this expected behaviour?
>
>__
>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



-- 
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Re: mp2 Apache2.0.49 on HPUX11i : mod_perl does not load in Apache

[William A. Rowe, Jr.]

At 10:38 AM 4/29/2004, olivier blanc wrote:
>   
>While trying to load compiled DSO modperl in Apache, I got the following error 

>Syntax error on line 223 of /opt/hpws/apache2/conf/httpd.conf:
>Cannot load /opt/hpws/apache2/modules/mod_perl.so into server: Error 0

Hmmm, while I don't have your answer, I have a hint.  Take a look 
back at rev 1.57 of

http://cvs.apache.org/viewcvs.cgi/apr/dso/unix/dso.c

http://cvs.apache.org/viewcvs.cgi/apr/dso/unix/dso.c?r1=1.56&r2=1.57

and back that bit out.  Passing 
BIND_VERBOSE to shl_load() 
will spew
ugly junk into your error log (you might even test w/ httpd -X -t which does
a pretty trivial attempt to just get the module to load.)

One fix for 32 bit builds that might need to be backed out to build successfully
for 64 bit builds is rev 1.490 of;

http://cvs.apache.org/viewcvs.cgi/apr/configure.in

http://cvs.apache.org/viewcvs.cgi/apr/configure.in?r1=1.489&r2=1.490

That patch addressed the fact that -ldl support in the hpux-11 family has
been incremental and spotty.  If you move a 32 bit build from one hpux-11
box to another, it now just works.  But revert that patch as I suggest, and
you discover the boxes vary quite a bit.

If the apr project expanded on that 1.490 fix, it would be best to build -ldld
flavor dso on a 32 bit build, -ldl (hpux-11i only) for 64 bit builds, if reverting
this patch helps you get modules loading.

Good luck,

Bill

Bill  


-- 
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Re: mp2 Apache2.0.49 on HPUX11i : mod_perl does not load in Apache

[William A. Rowe, Jr.]

At 12:23 PM 4/30/2004, Stas Bekman wrote:
>Thanks Bill!
>
>Do other Apache modules work as DSO on those platforms?

Since my builds are 32 bit, I can't tell you for certain, but I'd expect
the httpd/apr folks would have heard by now of a problem.

Difference, is that most modules are not nearly as complex, nor require
the startup constructor and destructor logic that mod_perl needs.

Oh, silly observation - but if the whole thing is fluxored, I wonder if modperl,
or perl is compiled against some additional 32-bit libs.

HP is migrating folks away from shl_xxx api to the dl_xxx api, but they
have done a lousy job on consistency in hpux-11/32 bit.  With their 11i
64 bit support they have been much more consistent, and practically
scream for users to move to dl_xxx.  This is why I wanted Olivier to try
backing out that patch that picks up shl_ over dl_.

>We have DSO problems with OpenBSD 2.9, FreeBSD (not sure which version) and a few 
>others, not sure if they are related at all. Most of the time there is no error at 
>all, httpd just hangs.

Altogether unrelated, I expect.  The items I mentioned were unique to HP/UX.



-- 
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Re: mod_perl on win32

[William A. Rowe, Jr.]

Michiel Beijen wrote:
> 
> I'd like to know if it's possible to build mod_perl on Win32; I'd like
> to use mod_perl with StrawberryPerl. It seems to be that the only way
> that could be done is to compile Apache also with MinGW, and that's not
> possible because of limited support for Windows Shared Memory in MinGW.

There are various flaws in the build, report them to d...@httpd or collect
them in bugzilla reports, and mind the existing reports which might already
solve your problem.

Since there is no MinGW port maintainer, this often falls apart, sorry there
is nothing we can do if a platform's community does not participate with or
engage the developers with patches.

> Also if you'd try to compile mod_perl it will try to run "./configure"
> on the Apache sources but that will fail on Win32 because 1. there is no
> Configure in the win32 Apache sources and 2. Windows will try to execute
> "." which is not exactly an executable file...
> 
> Does anyone have pointers or tips?

You don't use the -win32-src package because that package is for building
on the Microsoft Windows platform.  If you want to build for a faux-unix
platform you would obtain the usual tarball.

Re: ApacheCon 2009 in Oakland

[William A. Rowe, Jr.]

Jeff Trawick wrote:
> On Mon, Oct 19, 2009 at 12:15 AM, Fred Moyer  wrote:
>> Greetings,
>>
>> Is anyone here attending ApacheCon in Oakland this year?  I am
>> organizing a mod_perl social.  I'll be at the conference at least one
>> day hacking mod_perl.
> 
> This lurker will be there.

Sounds like a plan, would be good to know 2.0.5 is ready for httpd 2.4, or at
least something like it.  See you all there!

Re: modperl / apache13 memory footprints on 32 adn 64 bit servers

[William A. Rowe Jr.]

Joe Niederberger wrote:
> Does anyone know if one can have 64bit perl use 64 bit addressing (to make
> use of >4GB RAM) but still use 32-bit INTs etc (to keep footprint from
> getting
> large)?

This is the default on windows x64.

Re: modperl and comet?

[William A. Rowe Jr.]

On 4/16/2010 3:37 PM, E R wrote:
> I'm interested in adding a Comet capability to a (rather large)
> mod-perl application.
> 
> To get around XSS limitations, the Comet service will have the same
> host and port as the web service. However, I don't want a large
> mod-perl process tied up performing the Comet service.
> 
> Is there a way that a web request can be passed off to another process
> without tying up the Apache process? For instance, can the Apache
> process pass the file descriptors for the HTTP connection to another
> process which would free itself up for handling the next Apache
> request?

That should become a goal of event mpm, but right now event's only purpose
is to unhook the worker between the requests on keepalive connections.

Re: Bucket Heap? Error?

[William A. Rowe Jr.]

On 6/25/2010 4:54 PM, Dos Wizard wrote:
> Hello,
> 
> I can't make mod_perl to work with httpd-2.2.15
> While everything is ok, I get this annoying error whatever I had tried yet 
> (e.g. read the docs and follow the installation steps accurately)
> 
> Currenlty I am using a custom compiled Perl5.12.1 which had NO problems 
> during the installation (it had passed all the tests successfully), and so on 
> with additional modules, etc.
> 
> Now, when I try mod_perl I get this:
> 
> /usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../x86_64-suse-linux/bin/ld: 
> /usr/src/httpd-2.2.15/srclib/apr-util/.libs/libaprutil-1.a(apr_buckets_pool.o):
>  relocation R_X86_64_32S against `apr_bucket_type_heap' can not be used when 
> making a shared object; recompile with -fPIC 
> /usr/src/httpd-2.2.15/srclib/apr-util/.libs/libaprutil-1.a: could not read 
> symbols: Bad value collect2: ld returned 1 exit status

Recompile *PERL* -fPIC - it can't relocate the perl code.

Re: Fwd: All responses are 200 (server error)

[William A. Rowe Jr.]

Two thoughts...

try status 400 (might be special handling for 4xx unknown)

try r->status instead of/in addition to just r->status_line?

Re: Fwd: All responses are 200 (server error)

[William A. Rowe Jr.]

On 9/28/2010 12:25 AM, Nico Coetzee wrote:
> The status 400 (with $r->status_line) produces the same result "HTTP/1.1 200 
> OK" and with
> ($r->status) is creates a "HTTP/1.1 400 Bad Request" (the custom string gets 
> lost)
> 
> The $r->status with a code of 499 produces a "HTTP/1.1 400 Bad Request"

Sort of confirms my theory.

Set status to 400 and set status_line to 400 Custom Message, see what happens?

I suspect that 499 simply isn't allowed, which is wrong, but the current
behavior none the less.

Re: Fwd: All responses are 200 (server error)

[William A. Rowe Jr.]

On 9/28/2010 1:32 AM, Nico Coetzee wrote:
> and... it works now !!

I'd hit the same bug from CGI some half-decade ago, sorry I didn't
see where the problem was in the first place :(

Re: All responses are 200 (server error)

[William A. Rowe Jr.]

On 9/27/2010 6:09 AM, Peter Janovsky wrote:
> Are you returning the value of 200 within a module you've written?  I 
> encountered a
> similar issue within a C module specific to valid requests. It was resolved 
> by returning
> the internal constant OK. 

This is a generalized issue of serving ErrorDocuments; if they have a Status/
result code update (such as a backend proxy response or a cgi response), that
will override the original error code.  c.f.
https://issues.apache.org/bugzilla/show_bug.cgi?id=49996

So it is not strictly a bug, but you certainly aren't the first to be frustrated
by the behavior; look to the manner you handle ErrorDocuments with, first.

Re: experiencing Out of memory errors

[William A. Rowe Jr.]

On 1/27/2011 7:16 PM, Michael Peters wrote:
> On 01/27/2011 07:41 PM, Michael Ludwig wrote:
>> Michael Peters schrieb am 27.01.2011 um 19:14 (-0500):
>>
>>> But, even after all that I have applications where we consistently
>>> run 3-4G just for mod_perl/Apache.
>>
>> But surely not in one process as the OP said he'd like to do?
> 
> No you're right, but I'm guessing he might be running a threaded MPM, so 
> single process,
> multiple threads.

Exactly.  Even constraining httpd to smaller stacks is unlikely to be wise
with mod_perl running, consider the default is 256kb IIRC.  Shrinking this
to 128k obviously is a big help, but is unrealistic.

I agree with Peters, run a proxy in front of the server hosting mod_perl.
Even when we ship binary 64 bit for win32, there are far too many broken
perl and similar modules which don't expect sizeof(long*) > sizeof(long),
which has tripped up many porters.  Most of these defects are gone from
apr and httpd, and perl and modperl can likely catch up quickly, but to
isolate every possible modperl XS package on cpan and identify all those
which make stupid long x = (long)xptr; assignments will be arduous.

Re: Ubuntu and mod_perl

[William A. Rowe Jr.]

On 5/17/2011 3:39 PM, Tom Kane wrote:
> I'm still a little new at responding to mail lists. Here is an email that I 
> sent directly in a reply to Marco. I thought that it should be shared:
> 
> Marco,
> 
> I had to do the following just the other day:
> 
> sudo ln -sf /usr/lib/libperl.so.5.10.1 /usr/lib/libperl.so
> 
> That got me over the hurdle that occurred because of the missing symbolic 
> link to perl. I also had to do the following:
> 
> sudo ln -sf /usr/lib/libgdbm.so.3.0.0 /usr/lib/libgdbm.so
> 
> The libgdbm issue actually occurred prior to the perl problem.
> 
> I hope this helps. I am now trying to find the settings for mod_perl in the 
> /etc/apache2 configuration. My startup.pl file returns an error message that 
> I can't use 'use'.

Tom, it seems you are missing gdbm-devel and perl-devel packages.  To get
the appropriate .a/.so/.h files, you usually have to add -devel (or -dev)
flavors of various system components to build new software against them.

Re: Minor issue with AuthenNTLM

[William A. Rowe Jr.]

On 3/30/2012 1:56 AM, Dami Laurent (PJ) wrote:
>> -Message d'origine-
>> De : André Warnier [mailto:a...@ice-sa.com]
>>>
>>> I was considering forking the module and fixing bugs like these, but I
>>> am not quite sure how much sense that makes given the fact that NTLM is
>>> deprecated technology.
>>>
>> Huh ? Who said that ?  To my knowledge, 99% of large corporations use NTLM
>> (Windows Domain
>> Authentication) as their basic AAA mechanism.

Well, NTLM was DoA.  It is isn't HTTP compatible (0.9, 1.0 or 1.1).  HTTP is 
stateless, MS
NTLM presumes a stateful connection.

> For the future, the way to go is Kerberos; this is what Microsoft is pushing 
> in replacement for NTLM. 

Bingo.

Re: highscalability.com report

[William A. Rowe Jr.]

On 4/3/2012 9:50 PM, Jim Schueler wrote:
> Hope this doesn't get trapped by too many spam filters.
> 
> Sad news.  Just saw a blog
> 
>   http://www.highscalability.com/
> 
> that reports YouPorn.com switched from Perl to PHP.  Apparently there's a 
> reported 10%
> improvement in speed, but I haven't noticed :).
> 
> After a couple months of total immersion, I have less inclination towards
> PHP than ever.  Fight's not out of me yet.

If one is comparing an every-connection mod_perl enabled environment
to a specific-content, fastcgi-proxied php buildout, there's no contest.

When was the last time you built perl with no threading support?  It's
certainly a 5%-15% win.

Re: highscalability.com report

[William A. Rowe Jr.]

On 4/4/2012 1:41 PM, Fred Moyer wrote:
> On Wed, Apr 4, 2012 at 6:37 AM, demerphq  wrote:
>> On 4 April 2012 09:31, William A. Rowe Jr.  wrote:
>>>
>>> When was the last time you built perl with no threading support?  It's
>>> certainly a 5%-15% win.
>>
>> Not certainly. We did that and saw almost no difference.
> 
> I've done two perlbench sets of comparisons with threaded/non-threaded
> across a couple different versions of perl. I don't have the results
> posted on the web anymore, but non-threaded was up to 20% faster for
> some operations.
> 
> As far as real world differences go, I don't think you are likely to
> see differences with mod_perl in production environments with threaded
> vs non-threaded.  That 20% increase probably only affects 1% of your
> application.

Right.  The missing detail/point was that a well-tuned pool of single
threaded PHP, or Perl, or assembly coded worker processes running under
fcgid is going to outperform the in-process model, given finite cpu and
memory resources.

Re: New segfault with 2.4.20 with mod_perl

[William A Rowe Jr]

Re-sending to include the correct perl.a.o dev list.

On Thu, Apr 14, 2016 at 1:25 PM, William A Rowe Jr 
wrote:

> The defect appears to be in t/protocol/TestProtocol/pseudo_http.pm...
>
> First, the handler is registered using
>
>   PerlProcessConnectionHandler TestProtocol::pseudo_http
>
> so its activities are outside of the request handling phase.
>
> Note that this logic has been broken, for a long time;
>
>2.4.1>
>   
>   Order Deny,Allow
>   Allow from @servername@
>   
>   
>
> Where @servername@ is a hostname, this module defect was
> identified in version 2.4.20 when we began using the per-req
> hostname in comparison (based on r->useragent_addr, which
> is obviously is null during part of the read_request phase).
>
> But this module using mod_access_compat during the connection
> phase has been broken for much longer, since Allow from {ip-addr}
> would already have failed since 2.4.1 was released, due to the
> same null r->useragent_addr.
>
> Effectively, mod_access_compat.c never supported per-connection
> IP addresses since it was added.  The fact that it supported
> per-connection hostname comparison was a quirk, and that the
> pseudo_http tests only looked at hostname and not ip comparisons
> was an oversight.
>
> But the module will fail in other manners if attempting to use
> http request_rec processing since that record is never fleshed
> out with the proper read/post_read request hook phases.
>
> My thought is to simply decouple access_compat from this
> module test... opinions?
>
> See also; https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=820824;msg=5
>
>
> On Thu, Apr 14, 2016 at 11:55 AM, William A Rowe Jr 
> wrote:
>
>> We can be more vigilant about unexpectedly null values, however...
>>
>> how are you running request processing in the connection callback
>> of mod_perl?  That makes no sense, and probably signals a deeper
>> logic error.
>>
>> The access checker is configured per-dir, so until the request rec
>> is completely initialized during read_request, this doesn't make
>> much sense to me (full backtrace .. including frames #6-#10, for
>> those who are curious...)
>>
>> Either the callback list registered for modperl_callback_connection,
>> or the Perl_runops_standard, or the Perl_pp_entersub invoking the
>> run_access_checker hook seem the most suspect here.
>>
>> #0  apr_getnameinfo (hostname=hostname@entry=0x7fd4461ee368, sockaddr=0x0, 
>> flags=flags@entry=0)
>> at /tmp/buildd/apr-1.5.2/network_io/unix/sockaddr.c:663
>> #1  0x55feaf0f513a in ap_get_useragent_host (r=r@entry=0x7fd4461ee0a0, 
>> type=type@entry=3,
>> str_is_ip=str_is_ip@entry=0x7fd44740c9c4) at core.c:990
>> #2  0x7fd4519d7212 in find_allowdeny (r=r@entry=0x7fd4461ee0a0, 
>> method=method@entry=0, a=,
>> a=) at mod_access_compat.c:279
>> #3  0x7fd4519d74b2 in check_dir_access (r=0x7fd4461ee0a0) at 
>> mod_access_compat.c:332
>> #4  0x55feaf0f8f30 in ap_run_access_checker (r=r@entry=0x7fd4461ee0a0) 
>> at request.c:87
>> #5  0x7fd448a6f7dd in XS_Apache2__RequestRec_run_access_checker 
>> (my_perl=0x55feb2964a20, cv=)
>> at HookRun.c:235
>> #6  0x7fd44f5f7e6a in Perl_pp_entersub () from 
>> /usr/lib/x86_64-linux-gnu/libperl.so.5.22
>> #7  0x7fd44f5f0ca6 in Perl_runops_standard () from 
>> /usr/lib/x86_64-linux-gnu/libperl.so.5.22
>> #8  0x7fd44f575f06 in Perl_call_sv () from 
>> /usr/lib/x86_64-linux-gnu/libperl.so.5.22
>> #9  0x7fd44f91ec28 in modperl_callback 
>> (my_perl=my_perl@entry=0x55feb2964a20, handler=0x7fd4461f2750,
>> p=p@entry=0x7fd4461f2028, r=r@entry=0x0, s=s@entry=0x7fd453ddc628, 
>> args=0x55feb3beebd0)
>> at modperl_callback.c:100
>> #10 0x7fd44f91f576 in modperl_callback_run_handlers (idx=0, 
>> type=type@entry=1, r=r@entry=0x0,
>> c=, s=0x7fd453ddc628, pconf=pconf@entry=0x0, plog=0x0, 
>> ptemp=0x0, run_mode=MP_HOOK_RUN_FIRST)
>> at modperl_callback.c:236
>> #11 0x7fd44f91fd4f in modperl_callback_connection (idx=, 
>> c=,
>> run_mode=) at modperl_callback.c:359
>> #12 0x55feaf10cdf0 in ap_run_process_connection 
>> (c=c@entry=0x7fd4461f22b8) at connection.c:42
>> #13 0x55feaf10d340 in ap_process_connection (c=c@entry=0x7fd4461f22b8, 
>> csd=csd@entry=0x7fd4461f20a0)
>> at connection.c:226
>> #14 0x7fd4523f3e6b in process_socket (bucket_alloc=0x7fd4461f0028, 
>> my_thread_num=1, my_child_num=0,
>> sock=0x7fd4461f20a0,

Re: New segfault with 2.4.20 with mod_perl

[William A Rowe Jr]

On May 29, 2016 01:02, "Jie Gao"  wrote:
>
> Hi All
>
> I wonder if anybody is looking at this issue. At the moment, the build
cores even at the end of generating a Makefile.
>
> If not, I would like to get my hands dirty in an attmpt to get the ball
rolling. Any help on how to get a handle on the "ip comparisons"
recommended by W. Rowe Jr would be much appreciated.

Hi Jie,

At the moment, I'm still on the fence of whether this is a supportable use
case (in the faux-handler for the modperl alt protocol example.)

If it is not, the fix is to drop the test from modperl.

Otherwise, the fix is also straightforward, I can provide hints, but you
can cause the fault by changing the domain name in the test case config
from example 'hostname' to example 'ip addr'.  The offending code is in the
backtrace.  Both ip and host lookups would test if the useragent_addr is
null, and use the corresponding lookups from the conn_rec.

I sort of expect the modperl test to continue to be broken because the
req_rec simply has not been fully initialized... it is not until the entire
read_req hook phase is complete that all these req_rec field members have
meaningful values.

But if enough folks agree we can fix the lookup to refer to the conn_rec
values until useragent_addr is initialized.

Re: New segfault with 2.4.20 with mod_perl

[William A Rowe Jr]

On Tue, May 31, 2016 at 7:35 AM, William A Rowe Jr 
wrote:

> On May 29, 2016 01:02, "Jie Gao"  wrote:
> >
> > Hi All
> >
> > I wonder if anybody is looking at this issue. At the moment, the build
> cores even at the end of generating a Makefile.
> >
> > If not, I would like to get my hands dirty in an attmpt to get the ball
> rolling. Any help on how to get a handle on the "ip comparisons"
> recommended by W. Rowe Jr would be much appreciated.
>
> Hi Jie,
>
> At the moment, I'm still on the fence of whether this is a supportable use
> case (in the faux-handler for the modperl alt protocol example.)
>
> If it is not, the fix is to drop the test from modperl.
>

Alternately, the test could be fixed, but that is non-trivial...

A non-request oriented alt protocol simply never examines the req_rec,
and must not use request oriented modules like auth.  That should be
pretty obvious.

To create a pseudo -request- handler, you would have your connection
hook handler populate the appropriate fields and insert the appropriate
protocol-specific input and output filters below the request/body filters
and run the request through the rest of the phases, performing the
auth validation at the appropriate phase of the request (post_read
would be one obvious choice.)

Otherwise, the fix is also straightforward, I can provide hints, but you
> can cause the fault by changing the domain name in the test case config
> from example 'hostname' to example 'ip addr'.  The offending code is in the
> backtrace.  Both ip and host lookups would test if the useragent_addr is
> null, and use the corresponding lookups from the conn_rec.
>
> I sort of expect the modperl test to continue to be broken because the
> req_rec simply has not been fully initialized... it is not until the entire
> read_req hook phase is complete that all these req_rec field members have
> meaningful values.
>
> But if enough folks agree we can fix the lookup to refer to the conn_rec
> values until useragent_addr is initialized.
>

Re: ApacheCon: Getting the word out internally

[William A Rowe Jr]

It isn't undergoing significant changes, but 2.0.9 fixed several bugs and
brought it up-to-date with then-current perl releases a year ago June, and
I understand there is some activity to have it build well with 5.24.

On Jul 18, 2016 10:17 PM,  wrote:

> Hi,
>
> Is Apache modperl still in active development?
>
> thanks.
>
> On 2016/7/19 3:54, Melissa Warnkin wrote:
>
>> ApacheCon: Getting the word out internally
>>
>> Dear Apache Enthusiast,
>>
>> As you are no doubt already aware, we will be holding ApacheCon in
>> Seville, Spain, the week of November 14th, 2016. The call for papers
>> (CFP) for this event is now open, and will remain open until
>> September 9th.
>>
>> The event is divided into two parts, each with its own CFP. The first
>> part of the event, called Apache Big Data, focuses on Big Data
>> projects and related technologies.
>>
>> Website: http://events.linuxfoundation.org/events/apache-big-data-europe
>> CFP:
>>
>> http://events.linuxfoundation.org/events/apache-big-data-europe/program/cfp
>>
>> The second part, called ApacheCon Europe, focuses on the Apache
>> Software Foundation as a whole, covering all projects, community
>> issues, governance, and so on.
>>
>> Website: http://events.linuxfoundation.org/events/apachecon-europe
>> CFP:
>> http://events.linuxfoundation.org/events/apachecon-europe/program/cfp
>>
>> ApacheCon is the official conference of the Apache Software
>> Foundation, and is the best place to meet members of your project and
>> other ASF projects, and strengthen your project's community.
>>
>> If your organization is interested in sponsoring ApacheCon, contact Rich
>> Bowen
>> at e...@apache.org   ApacheCon is a great place to
>> find the brightest
>> developers in the world, and experts on a huge range of technologies.
>>
>> I hope to see you in Seville!
>> ==
>> **//___^
>>
>> Melissa
>> on behalf of the ApacheCon Team**//___^
>>
>

Re: [mp2] Test failures in mod_perl 2.0.9 (Apache 2.2.31, perl 5.24.0)

[William A Rowe Jr]

On Jul 21, 2016 8:24 PM, "William Ward"  wrote:
>
> OK I will give that a try. Unfortunate, as 5.24.0 has been blessed with
LTS status by the Perl gods. Hopefully a new mod_perl will come out that
includes this fix.

Note that httpd 2.4.23 announcement warned of the imminent end of httpd 2.2
as well. You would do well to build your httpd 2.4 / perl 5.24 / mod
perl.next that should be tagged soon as your next stack.

Re: Bug - Strange issue with mod_perl 2.0.10 / Apache 2.4 corrupting nfreeze data

[William A Rowe Jr]

On Sun, Aug 7, 2016 at 8:37 AM, Alex Masidlover 
wrote:

> On Sun, 2016-04-03 at 17:03 +0200, Vincent Veyron wrote:
> > On Sun, 03 Apr 2016 14:11:23 +0100
> > Alex Masidlover  wrote:
> >
> > > This has all worked perfectly up until I upgraded to Apache 2.4 /
> > > mod_perl 2.0.10 -
> > After upgrading to Apache 2.4 and mod_perl 2.0.9, I had to make those
> > two changes to my application :
> >
> > In a PerlOutputFilterHandler, change '$content .= $buffer' to
> > '$content .= decode_utf8($buffer)'
> >
> > And in response handlers, change '$args{$_} = $req->param($_)' to
> > '$args{$_} = decode_utf8($req->param($_))'
> >
> > Not sure it applies to your case, but something changed in Apache 2.4
> > concerning UTF-8 data.
> >
> > If I understood correctly, anything that goes through APR::Table is
> > considered UTF-8, however the SvUTF8 flag is not set, so you get
> > double encoding when processing your data.
>

Just to be clear, everything in APR::Table is expected to be ASCII
(or EBCDIC, on those oddball architectures)... and "opaque text",
e.g. characters 128-255 on ASCII architectures is permitted but
not defined.

It's easy to verify that they qualify as UTF-8, because the coding is very
predictable.  E.g. 0xFE or 0xFF are not characters, and others are valid
only when in the correct sequence, c.f. the validation logic in;

  http://svn.apache.org/repos/asf/apr/apr/trunk/misc/win32/utf8.c


> What a browser sends is not guaranteed, it may be sending ISO-8859-1,
or UTF8 (or even problematic ISO-2022-JP where the ASCII char ' ' or '\'
may occur as a continuation character causing parsing issues. Modern
browsers appear to all be defaulting to UTF-8 finally, but you may have
many legacy browsers out there.

In your decode_utf8 logic, ensure that your app checks for failure!  And
where the output fails, try treating it in a code page such as 8859-1.

Absorb win32-apxs into httpd distro?

[William A Rowe Jr]

Randy wrote http://www.apache.org/dist/perl/win32-bin/ - but I'm wondering
who else here at httpd is interested in helping maintain and get this code
into our own distribution? I've shipped this for a decade for my commercial
customers, for every wrinkle and wart, I think many of our win32 users
would appreciate this.

I trust the perl pmc and Randy would be good with this adoption?

Cheers,

Bill

Re: Absorb win32-apxs into httpd distro?

[William A Rowe Jr]

On Wed, Dec 14, 2016 at 2:20 AM, Steve Hay 
wrote:

> On 14 December 2016 at 08:13, William A Rowe Jr 
> wrote:
> > Randy wrote http://www.apache.org/dist/perl/win32-bin/ - but I'm
> wondering
> > who else here at httpd is interested in helping maintain and get this
> code
> > into our own distribution? I've shipped this for a decade for my
> commercial
> > customers, for every wrinkle and wart, I think many of our win32 users
> > would appreciate this.
> >
> > I trust the perl pmc and Randy would be good with this adoption?
> >
>
> Randy sadly passed away some years ago, but I for one would welcome
> the adoption.
>

I was aware. Seemed like one more small appropriate tribute.

The latest version that I'm aware of lives in
> https://svn.apache.org/repos/asf/perl/apxs/trunk
>

Thanks for the pointer, and support of bringing this into the httpd distro.
Hoping you (and other perl-folk who know the code) might help review
the patches and ensure it is working well, moving forwards.

Re: Where is the mod_perl development repo?

[William A Rowe Jr]

Explore the idea of wrapping your app as an fcgid endpoint. Httpd has two
options (mod_fcgid managing the pool, and mod_proxy_fcgi with your own
choice of independent pool management.)

This offers the best of both... Larger number of httpd endpoints and less
contention between fcgi processes. It is now the recommended approach to
PHP and other scripting endpoints.

On Feb 19, 2017 06:50, "Tom Browder"  wrote:

On Sun, Feb 19, 2017 at 00:44 Randal L. Schwartz 
wrote:

> > "Tom" == Tom Browder  writes:

...

>
Randall, I do know that, and I love Perl 6!  I also feel comfortable
writing CGI programs, so how can I use both most efficiently with my apache
web server.?

Best regards,

-Tom

P.S. I enjoyed meeting you and shaking hands with you at YAPC::NA::2016.
Thanks for all your contributions to the Perl community!

Re: Question about Apache 2.4 and libapreq2 (Apache2::Request)

[William A Rowe Jr]

On Thu, Mar 9, 2017 at 9:53 PM, JW  wrote:
>
> It's been over a month since moving to Apache 2.4. It was fairly
> straightforward and required
> little code to be updated, most of it Apache config. Everything runs as it
> did before the update and I've
> had no problems. The one function that didn't 'work' is described below.
>
> This mod_perl server is behind a proxy on the same machine. Under Apache
> 2.2, $r->remote_ip()
> returned 127.0.0.1 and not the user's actual IP.  So, a
> PerlPostReadRequestHandler extracted the user's
> IP address from the X-Forwarded-For header and set it with $r->remote_ip(
> $ip ).
>
> In Apache 2.4 (and mod_perl now) $c->remote_ip is split into
> $r->useragent_ip and $c->client_ip:
> http://httpd.apache.org/docs/2.4/developer/new_api_2_4.html
> But, $r->useragent_ip (wrongly) gives me 127.0.0.1. Perhaps this'll be fixed
> at some point (unless
> I'm doing something wrong). So, for now, as above, the IP is extracted from
> X-Forwarded-For
> and set with $r->useragent_ip( $ip ).

Keep in mind you can't use r->useragent_ip until the request is created, e.g.
the create request hook is not a good place to try this (we actually had to
work around a crash related to this behavior in httpd's sources.) After the
read_request phase, this information will be finalized (provided that the
mod_remoteip config is correct).

It seems some code was expecting to read the useragent_ip in a very early
phase of connection handling, although the headers to populate it for the
request had not even been read off the wire :) So now, all attempts to read
this too-early will result in the c->client_ip values.

Here's when the action happens;
ap_hook_post_read_request(remoteip_modify_request, NULL, NULL, APR_HOOK_FIRST);

Re: Question about Apache 2.4 and libapreq2 (Apache2::Request)

[William A Rowe Jr]

This has occurred in multiple contexts, including throwing segfaults in the
modperl test framework (connection handler, so no req_rec.)

Wondering if remoteip might be able to run a little bit earlier? This is all
relevant to what we are discussing about PROXY protocol enhancements.

On Mon, Mar 13, 2017 at 6:28 PM, JW  wrote:
> 
> From: William A Rowe Jr 
> To: JW 
> Cc: "modperl@perl.apache.org" 
> Sent: Friday, March 10, 2017 1:44 PM
> Subject: Re: Question about Apache 2.4 and libapreq2 (Apache2::Request)
>
> On Thu, Mar 9, 2017 at 9:53 PM, JW  wrote:
>>
>> It's been over a month since moving to Apache 2.4. It was fairly
>> straightforward and required
>> little code to be updated, most of it Apache config. Everything runs as it
>> did before the update and I've
>> had no problems. The one function that didn't 'work' is described below.
>>
>> This mod_perl server is behind a proxy on the same machine. Under Apache
>> 2.2, $r->remote_ip()
>> returned 127.0.0.1 and not the user's actual IP.  So, a
>> PerlPostReadRequestHandler extracted the user's
>> IP address from the X-Forwarded-For header and set it with $r->remote_ip(
>> $ip ).
>>
>> In Apache 2.4 (and mod_perl now) $c->remote_ip is split into
>> $r->useragent_ip and $c->client_ip:
>> http://httpd.apache.org/docs/2.4/developer/new_api_2_4.html
>> But, $r->useragent_ip (wrongly) gives me 127.0.0.1. Perhaps this'll be
>> fixed
>> at some point (unless
>> I'm doing something wrong). So, for now, as above, the IP is extracted
>> from
>> X-Forwarded-For
>> and set with $r->useragent_ip( $ip ).
>
>
> Keep in mind you can't use r->useragent_ip until the request is created,
> e.g.
> the create request hook is not a good place to try this (we actually had to
> work around a crash related to this behavior in httpd's sources.) After the
> read_request phase, this information will be finalized (provided that the
> mod_remoteip config is correct).
>
> It seems some code was expecting to read the useragent_ip in a very early
> phase of connection handling, although the headers to populate it for the
> request had not even been read off the wire :) So now, all attempts to read
> this too-early will result in the c->client_ip values.
>
> Here's when the action happens;
> ap_hook_post_read_request(remoteip_modify_request, NULL, NULL,
> APR_HOOK_FIRST);

Yes, it seems PerlPostReadRequestHandler was too early. $r->useragent_ip()
gives the remote ip with the PerlTransHandler and later stages. Thanks!

Re: Question about Apache 2.4 and libapreq2 (Apache2::Request)

[William A Rowe Jr]

Yes, that's an artifact of the phase in which we handle the remoteip
transposition. It could be slightly earlier which is why I raised the
question to the httpd dev community.

On Tue, Mar 14, 2017 at 12:31 AM, JW  wrote:
>
> Don't know the answer to your question about remoteip ...
>
> However, what I noted is that the Apache remoteip module,
> when configured with "RemoteIPHeader X-Forwarded-For", deletes the
> X-Forwarded-For header.
> In the PerlPostReadRequestHandler stage, the X-Forwarded-For header
> exists and it seems Apache has yet to use the X-Forwarded-For value as
>  $r->useragent_ip gives 127.0.0.1.
> In the next stage, PerlTransHandler, a call to $r->useragent_ip() gives the
> correct remote ip, but the X-Forwarded-For header is no longer available.
>
>
> 
> From: William A Rowe Jr 
> To: httpd ; modperl@perl.apache.org
> Cc: JW 
> Sent: Monday, March 13, 2017 4:53 PM
>
> Subject: Re: Question about Apache 2.4 and libapreq2 (Apache2::Request)
>
> This has occurred in multiple contexts, including throwing segfaults in the
> modperl test framework (connection handler, so no req_rec.)
>
> Wondering if remoteip might be able to run a little bit earlier? This is all
> relevant to what we are discussing about PROXY protocol enhancements.
>
> On Mon, Mar 13, 2017 at 6:28 PM, JW  wrote:
>> 
>> From: William A Rowe Jr 
>> To: JW 
>> Cc: "modperl@perl.apache.org" 
>> Sent: Friday, March 10, 2017 1:44 PM
>> Subject: Re: Question about Apache 2.4 and libapreq2 (Apache2::Request)
>>
>> On Thu, Mar 9, 2017 at 9:53 PM, JW  wrote:
>>>
>>> It's been over a month since moving to Apache 2.4. It was fairly
>>> straightforward and required
>>> little code to be updated, most of it Apache config. Everything runs as
>>> it
>>> did before the update and I've
>>> had no problems. The one function that didn't 'work' is described below.
>>>
>>> This mod_perl server is behind a proxy on the same machine. Under Apache
>>> 2.2, $r->remote_ip()
>>> returned 127.0.0.1 and not the user's actual IP.  So, a
>>> PerlPostReadRequestHandler extracted the user's
>>> IP address from the X-Forwarded-For header and set it with $r->remote_ip(
>>> $ip ).
>>>
>>> In Apache 2.4 (and mod_perl now) $c->remote_ip is split into
>>> $r->useragent_ip and $c->client_ip:
>>> http://httpd.apache.org/docs/2.4/developer/new_api_2_4.html
>>> But, $r->useragent_ip (wrongly) gives me 127.0.0.1. Perhaps this'll be
>>> fixed
>>> at some point (unless
>>> I'm doing something wrong). So, for now, as above, the IP is extracted
>>> from
>>> X-Forwarded-For
>>> and set with $r->useragent_ip( $ip ).
>>
>>
>> Keep in mind you can't use r->useragent_ip until the request is created,
>> e.g.
>> the create request hook is not a good place to try this (we actually had
>> to
>> work around a crash related to this behavior in httpd's sources.) After
>> the
>> read_request phase, this information will be finalized (provided that the
>> mod_remoteip config is correct).
>>
>> It seems some code was expecting to read the useragent_ip in a very early
>> phase of connection handling, although the headers to populate it for the
>> request had not even been read off the wire :) So now, all attempts to
>> read
>> this too-early will result in the c->client_ip values.
>>
>> Here's when the action happens;
>> ap_hook_post_read_request(remoteip_modify_request, NULL, NULL,
>> APR_HOOK_FIRST);
>
> Yes, it seems PerlPostReadRequestHandler was too early. $r->useragent_ip()
> gives the remote ip with the PerlTransHandler and later stages. Thanks!
>
>

Re: CPAN will shutdown

[William A Rowe Jr]

On Tue, May 22, 2018 at 10:41 PM, Practical Perl 
wrote:

> *search.cpan.org  is shutting down*
> For details read Perl NOC
> .
> After June 25th this page will redirect to MetaCPAN.org
> 
>
>
> So does as well as Perl?
>

In this day and age, seamless delegation is so trivial, but I was heartened
to read;

*"Update #1 (2018-05-19)*:  There's some confusion around whether or not
existing search.cpan.org URLs will continue to work.  They will!  The vast
majority of of them will be transparently served by MetaCPAN pages.  You do
not need to update any links right now."

Provided that eases away 95% of maintenance headaches, it seems sysadmins
and users all get to have our cake.

Re: Upgrading a mod_perl application from Apache 2.2 to Apache 2.4

[William A Rowe Jr]

On Thu, Dec 6, 2018 at 9:25 AM Andrew Green  wrote:

> Hi all,
>
> Huge thanks to everyone for your replies on this.  I’ve now been able to
> work through everything, and I thought I’d post a quick update with some
> additional notes in case there’s anyone else in the same boat searching the
> archives in the future!
>
> 1. I was able to use the following as a way of determining which version
> of Apache is in use at runtime:
>
> my $server_version = Apache2::ServerUtil::get_server_banner();
> my $is_old_apache = ($server_version =~ /Apache\/2\.2/) ? 1 : 0;
>

Just a little warning, the server_banner is controlled by the admin, and
may not include
the entire Apache/2.2 token. The server_description fleshed this out beyond
the control
of the admin, but isn't meant for transmission;

/**
 * Get the server banner in a form suitable for sending over the
 * network, with the level of information controlled by the
 * ServerTokens directive.
 * @return The server banner
 */
AP_DECLARE(const char *) ap_get_server_banner(void);

/**
 * Get the server description in a form suitable for local displays,
 * status reports, or logging.  This includes the detailed server
 * version and information about some modules.  It is not affected
 * by the ServerTokens directive.
 * @return The server description
 */
AP_DECLARE(const char *) ap_get_server_description(void);

But you are better off looking at;
http://perl.apache.org/docs/2.0/api/Apache2/ServerUtil.html#C_get_server_version_

which returns nothing except exactly what you are asking.

Re: Upgrading a mod_perl application from Apache 2.2 to Apache 2.4

[William A Rowe Jr]

On Thu, Dec 6, 2018 at 3:34 PM Andrew Green  wrote:

> Hi William,
>
> But you are better off looking at;
>
> http://perl.apache.org/docs/2.0/api/Apache2/ServerUtil.html#C_get_server_version_
>
> which returns nothing except exactly what you are asking.
>
>
> I did try this (and it worked fine) — but I kept seeing the following
> error pop up in the logs:
>
> *ap_get_server_version() is deprecated since httpd/2.3.0 try using
> ap_get_server_(description|banner)() instead*
>
> So I switched to banner.  I’ll see about switching again to description.
>

Ahhh, ok, just be aware the get_server_description call doesn't exist in
2.2, you need
to perform a little eval() magic to guard against that expected failure.

Re: HTTP and MPM support

[William A Rowe Jr]

On Fri, Jan 25, 2019 at 11:35 AM John Dunlap  wrote:

> I'm in the process of optimizing our web application for performance and
> one thing that I was really excited to try was mod_http2 because it allows
> the browser to send multiple requests through the same TCP connection with
> compressed headers. However, when I enabled it and restarted apache I was
> greeted with this:
>
> [Fri Jan 25 12:30:57.813355 2019] [http2:warn] [pid 10186] AH10034: The
> mpm module (prefork.c) is not supported by mod_http2. The mpm determines
> how things are processed in your server. HTTP/2 has more demands in this
> regard and the currently selected mpm will just not do. This is an advisory
> warning. Your server will continue to work, but the HTTP/2 protocol will be
> inactive.
>

To this question, the answer should be blatantly obvious; http2 doesn't
simply support multiple requests (connection: keepalive solved that)
but supports parallel requests. This clearly isn't compatible with any
single-threaded/single-worker per connection strategy.

A hybrid mod_prefork could be coded to dispatch all worker requests
across to distinct worker processes for a single connection, but I
don't anticipate anyone interested in doing such development.


> The last time I tried to use either mpm_worker or mpm_event my application
> was plagued by seemingly random segfaults. Are there any plans to support
> other MPM's? If not, the benefits of HTTP2 appear to be permanently out of
> reach for our mod_perl applications and that, honestly, might force us into
> seriously reevaluating our technology stack. :(
>

Your compatibility with the worker MPM is likely much stronger than
with the event MPM; however... all request workers can behave in a
"free threaded" manner under mod_http2, eliminating the relative
simplicity of the worker MPM. Working out each and any of these
specific segfaults occurs is the only way to improve the situation.

For the general mod_perl activity to increase, the Apache Perl Project
needs active volunteers and contributions. Consider this entire thread
an open invitation to participate.

Foolish Q - 2.0_RC4?

[William A. Rowe, Jr.]

I can't seem to locate the source repository point for _RC4...

Looked in;

http://svn.apache.org/repos/asf/perl/modperl/tags/

as well as

http://cvs.apache.org/viewcvs.cgi/
(which I see modperl2 is now gone.)

Any pointers?  Would like to give this a thorough drubbing
so I can toss my ++ into the ring for release :)

Bill

Re: Foolish Q - 2.0_RC4?

[William A. Rowe, Jr.]

At 07:05 PM 3/9/2005, Geoffrey Young wrote:

>> official releases are also always on
>> 
>>   http://svn.apache.org/viewcvs.cgi/perl/modperl/
>
>blarg, cut and paste error.  I meant
>
>  http://perl.apache.org/dist/

I hope you ment http://www.apache.org/dist/perl/ since that's
what our mirrors capture.

That said, I always work from the repositories, so thanks for
the pointer :)

Tagging svn modperl2 releases?

[William A. Rowe, Jr.]

svn co http://svn.apache.org/repos/asf/perl/modperl/tags/1_999_21 modperl2

Fetching external item into 'modperl2\docs'

actually fetches from https:// - it jumps scope, breaks non-ssl clients.

Fetching external item into 'modperl2\Apache-Test'
svn: URL 
'https://svn.apache.org/repos/asf/httpd/test/trunk/perl-framework/Apache-Test' 
doesn't exist

also fetches from https:// but worse, Apache-Test moved.

This isn't a workable scenario, since 1_999_21 is a tag, but tries to grab
these moving targets which can't be traced back at the time.

I'm not certain what the right answer is, but I suspect it involves
breaking the 'checkout other' association and making an svn copy of these
dependencies into the release tag.  This seems like the purest solution,
and such tag copies are cheap.  If the desire is to use some specific
version of Apache-Test or docs, it's simply to copy that tags/ tree
instead of the trunk/.

I did check https://svn.apache.org/repos/asf/httpd/test/tags/ and
https://svn.apache.org/repos/asf/perl/Apache-Test/tags/ and did not
see anything corresponding to 1_999_21 (although earlier releases
obviously did tag these files appropriately.)

If I had a vote, it would be most definitely -1 for the RC4 tarball,
simply due to this inability to track what it contained.  I'm working
from 1_999_21 and yesterday's Apache-Test, and will evaluate the
general results in anticipation of an RC5.

Definitely think 2.0 is overdue, but these versioning issues aught
to be resolved first.

Bill

[Patch WIN32 apxs]

[William A. Rowe, Jr.]

For users of Randy's apxs win32 (v 0.2) here's my gross hack to get
it working again for 2.1-dev, 2.2.  The binary has changed from
apache.exe to httpd.exe, causing some pain.  However, it's specific,
I started generic but ran out of time (libapr-1.dll for example.)

Sorry for the crosspost, expect a few on each list to be most
interested in this.

Would like to see this in httpd 2.2 final.  It looks like a wee bit
of overkill, and apr / apr-util / httpd really should each deposit
their own droppings in bin/, build/.  Just no time to refactor this
week (hmmm... vacation time ahead ;-)

Bill

diff -u3 apxs/Configure.pl apxs-win32/Configure.pl
--- apxs/Configure.pl   Tue Mar 16 17:42:30 2004
+++ apxs-win32/Configure.pl Fri Jul 22 13:14:04 2005
@@ -13,8 +13,9 @@
 die 'This script is intended for Win32' unless $^O =~ /Win32/i;
 }
 
-my ($apache, $help);
+my ($apache, $progname, $help);
 GetOptions( 'with-apache2=s' => \$apache,
+   'with-apache-prog=s' => \$progname,
'help' => \$help,
) or usage($0);
 usage($0) if $help;
@@ -22,7 +23,10 @@
 my @path_ext;
 path_ext();
 $apache ||= search(); 
+$progname ||= "Apache.exe";
 
+push @ARGV, "--with-apache-prog=$progname";
+
 for my $file (qw(apxs_win32.pl apr_win32.pl apu_win32.pl) ) {
 push @ARGV, "--with-apache2=$apache";
 unless (my $return = do $file) {
@@ -34,10 +38,20 @@
 
 sub search {
 my $apache;
-if (my $bin = which('Apache')) {
-(my $candidate = dirname($bin)) =~ s!bin$!!;
-if (-d $candidate and check($candidate)) {
+my $candidate;
+my $bin;
+if ($bin = which('Apache.exe')) {
+($candidate = dirname($bin)) =~ s!bin$!!;
+if (-d $candidate and check($candidate, "Apache.exe")) {
+$apache = $candidate;
+$progname = "Apache.exe";
+}
+}
+elsif ($bin = which('httpd.exe')) {
+($candidate = dirname($bin)) =~ s!bin$!!;
+if (-d $candidate and check($candidate, "httpd.exe")) {
 $apache = $candidate;
+$progname = "httpd.exe";
 }
 }
 unless ($apache and -d $apache) {
diff -u3 apxs/README apxs-win32/README
--- apxs/README Fri Jul 22 14:56:33 2005
+++ apxs-win32/README   Tue Mar 16 22:36:36 2004
@@ -10,14 +10,3 @@
 Randy Kobes <[EMAIL PROTECTED]>
 March 17, 2004
 
-
-If you are building for Apache 2.1-dev/2.2, you will discover
-that it's now httpd.exe, not Apache.exe.
-
-   perl Configure.pl --with-apache-prog=httpd.exe
-
-will provide the results you hoped for.
-
-Bill Rowe 
-July 22, 2005
-
diff -u3 apxs/apr_win32.pl apxs-win32/apr_win32.pl
--- apxs/apr_win32.pl   Tue Mar 16 21:55:52 2004
+++ apxs-win32/apr_win32.pl Fri Jul 22 12:13:28 2005
@@ -45,7 +45,7 @@
 $prefix);
 }
 die "Can't find a suitable Apache2 installation!" 
-unless (-d $prefix and check($prefix));
+unless (-d $prefix and check_apr($prefix));
 
 $prefix = Win32::GetShortPathName($prefix);
 
diff -u3 apxs/apu_win32.pl apxs-win32/apu_win32.pl
--- apxs/apu_win32.pl   Tue Mar 16 21:56:52 2004
+++ apxs-win32/apu_win32.pl Fri Jul 22 12:13:47 2005
@@ -45,7 +45,7 @@
 $prefix);
 }
 die "Can't find a suitable Apache2 installation!" 
-unless (-d $prefix and check($prefix));
+unless (-d $prefix and check_apu($prefix));
 
 $prefix = Win32::GetShortPathName($prefix);
 
diff -u3 apxs/apxs_win32 apxs-win32/apxs_win32
--- apxs/apxs_win32 Tue Mar 16 22:25:16 2004
+++ apxs-win32/apxs_win32   Fri Jul 22 13:18:24 2005
@@ -687,7 +687,7 @@
 
 #   the used tools
 APXS=apxs
-APACHECTL=Apache.exe -k
+APACHECTL=$progname -k
 
 #   additional defines, includes and libraries
 #DEFS=-Dmy_define=my_value
diff -u3 apxs/apxs_win32.pl apxs-win32/apxs_win32.pl
--- apxs/apxs_win32.pl  Tue Mar 16 22:13:44 2004
+++ apxs-win32/apxs_win32.plFri Jul 22 13:16:45 2005
@@ -7,8 +7,9 @@
 use ExtUtils::MakeMaker;
 use File::Spec::Functions;
 require 'util.pl';
-my ($apache, $help);
+my ($apache, $progname, $help);
 GetOptions( 'with-apache2=s' => \$apache,
+   'with-apache-prog=s' => \$progname,
'help' => \$help,
) or usage($0);
 usage($0) if $help;
@@ -18,7 +19,7 @@
 $apache);
 }
 die "Can't find a suitable Apache2 installation!" 
-unless (-d $apache and check($apache));
+unless (-d $apache and check_httpd($apache, $progname));
 
 $apache = Win32::GetShortPathName($apache);
 
@@ -166,7 +167,7 @@
 ab_LTFLAGS =
 checkgid_LTFLAGS =
 APACHECTL_ULIMIT =
-progname = Apache.exe
+progname = httpd.exe
 MPM_LIB = server/mpm/winnt/
 OS = win32
 OS_DIR = win32
diff -u3 apxs/util.pl apxs-win32/util.pl
--- apxs/util.plWed Aug 20 22:59:52 2003
+++ apxs-win32/util.pl  Fri Jul 22 13:19:56 2005
@@ -3,11 +3,13 @@
 print <<"END";
 
  Usage: perl $script [--with-apache2=C:\Path\to\Apache2]
+perl $script [--with-apache-prog=httpd.exe]
 perl $script --help
 
 Options:
 
   --with-apache2=C:\Path\to\Apache2 : specify the

Re: [Patch WIN32 apxs]

[William A. Rowe, Jr.]

Randy,

  thanks for all you efforts on this!  Question before folks trip, was
your 0.3 specific to httpd.exe and the apr-1 layout, or did you finish
making this generic to both Apache 2.0 and 2.1-dev+?

  A warning on the website might be in order, if 0.3 applies right now
only to httpd-2.1

Bill

Randy Kobes wrote:

On Fri, 22 Jul 2005, William A. Rowe, Jr. wrote:


For users of Randy's apxs win32 (v 0.2) here's my gross hack to get
it working again for 2.1-dev, 2.2.  The binary has changed from
apache.exe to httpd.exe, causing some pain.  However, it's specific,
I started generic but ran out of time (libapr-1.dll for example.)

Sorry for the crosspost, expect a few on each list to be most
interested in this.

Would like to see this in httpd 2.2 final.  It looks like a wee bit
of overkill, and apr / apr-util / httpd really should each deposit
their own droppings in bin/, build/.  Just no time to refactor this
week (hmmm... vacation time ahead ;-)

Bill



Thanks, Bill! I've incorporated these changes in a
new version, apxs_win32-0.3.tar.gz, at
   http://www.apache.org/dyn/closer.cgi/perl/win32-bin/
Please let me know of any problems.

Re: [mp2] make test fails to start httpd on AIX 5.2, IHS 2.

[William A. Rowe, Jr.]

Question, any hope you could use something more recent than a 2 year old
distribution of httpd, and let us know if the modern version reproduces
the problem?

http://httpd.apache.org/dev/dist/ happens to contain what we hope will
become an official 2.0.55 release, with some new AIX build fixes, give
it a whirl if you can find some time to test, and see if this remains
a problem.

Thanks!

Bill

[EMAIL PROTECTED] wrote:

1. Problem Description:

  make test fails to start httpd on AIX 5.2 Maintenance Level 2 with IBM 
HTTP Server 2.0.47.1. The HTTP startup process times out.

Re: nmake test problem on Windows

[William A. Rowe, Jr.]

Goehring, Chuck wrote:

modperlers,


Firstly apxs does not apply on Windows, right?  


see http://www.apache.org/dist/perl/win32-bin/apxs_win32.tar.gz

Re: restart_count() on Win32

[William A. Rowe, Jr.]

Foo Ji-Haw wrote:
 
I am trying my luck again on this issue, which I never quite understood/ 
resolved.
 
The log file shows this when Apache starts:

1  (parent/healthcheck process)
2  (parent/healthcheck process)
1  (child/real server process)
2  (child/real server process)


In 1.3, the child 'owned' the logs and overwrote everthing.  2.0 uses locking
to allow the parent's log entries to be preserved.

The win32 'parent' never serves a request.  It's resources are also not really
inherited by the child, so each child must 'do it's own thing' with respect to
fully initializing the server.


And the log file shows this when Apache restarts:
3 (parent/healthcheck process)
1 (child/real server process)
2 (child/real server process)


The parent signals the 'old child' to begin to shut down (and quit listening
for new connections) while it spawns up a new full blown child process, with
the same child behavior as you noted on first-start.

Re: restart_count() on Win32

[William A. Rowe, Jr.]

Foo Ji-Haw wrote:

Hello William,

Thanks for the insight into the inner workings of mp2 on Win32. I'd like to
read up more on the parent-child setup, and digging through perl.apache.org
(mostly in http://perl.apache.org/docs/2.0/) I don't seem to be able to get
any information on mp2 on Win32.

Can you share your source of information on this issue? Thanks.


Sure, the httpd source code, server/mpm/win32/*.c files - well that and I've
committed and fixed a rather large chunk of code to that tree.

As far as modperl, and how win32 mpm impacts modper, the modperl team actually
is sharper than I am.

Bill

Re: identifying mod_perl process at runtime

[William A. Rowe, Jr.]

Daniel McBrearty wrote:
If I have a library which is used for both mod_perl and standard cgi 
processes, and I want to know at runtime which, how can I do that?


does ARGV[0] tell you?  I'd expect it to be 'httpd' for apache/modperl.

Re: Reading post data from separate handlers

[William A. Rowe, Jr.]

Blayne Bayer wrote:
I have a problem that hopefully somebody has encountered or can point me 
in the right direction.


We use the latest embperl 1.xxx release on linux. I have created a 
handler to do authentication before the embperl handler is run. This new 
handler needs to read data from the post each request. However once read 
is called on the Apache object you cannot call it again. This in turns 
cripples embperl because it no longer has the post data. Is there any 
way to be able to read the post data from multiple handlers?


If you are part of the filter stack, you can 'sniff' - read ahead and set
aside - the data coming in from the client.  Other filters installed after
your filter will repeatedly call, and you return the set-aside data.

You can look at the apreq2 library with httpd-2 to assist you with this.

Syntax issue in Apache/TestConfig.pm TestUtil.pm

[William A. Rowe, Jr.]

Both lib/Apache/TestConfig.pm and lib/Apache/TestUtil.pm twist off their
own shebang lines from $Config{perlpath}, which is wrong.

They should simply pull $Config{startperl} which defines the shebang/command
on a platform basis.  See startperl= assignment from Config.pm.

Please ack / discuss / commit?

Thanks,

Bill

Re: Syntax issue in Apache/TestConfig.pm TestUtil.pm

[William A. Rowe, Jr.]

Geoffrey Young wrote:


ack and discuss :)  let's hold off on making any changes until we are really
sure we won't be breaking old platforms.  speaking of breakage, which
platform is giving your grief with this?  randy reported success with win32
so it's something else?


Something else.  My perl/bin/perl script fixes up the libpath info to openssl,
the current install location of perl, etc.  So without the $Config{startperl}
location to invoke perl-as-shell (I had a horrid time with shebang syntax on
non-bash older /bin/sh shells using perlscript) - I'll continue to have
difficulty testing parallel installs.

Your point to perl versions is good; the make_shebang is a hack around something
that can be trivially hacked into the base perl instead (in Config.pm).  Since
perl 'figures this out', my preference is for perl to get it right (or wrong,
and therefore fixed once per platform/deployment strategy.)

So the question; how far back?  I just went to a box with an honest to goodness
5.005.03 sun4-solaris distribution of perl and lo and behold,
startperl='#!/usr/bin/perl' is there.

Which brings up another aspect of tweaking startperl, that is, when meaning to
test several parallel flavors of perl.  But coming back on point, yes I quite
believe this will work across the board.

Bill

Re: Syntax issue in Apache/TestConfig.pm TestUtil.pm

[William A. Rowe, Jr.]

I don't think the reporter understood the concept of

#!/usr/bin/perl
eval 'exec $Config{perlpath} -S \$0 \${1+"\$@"}'
  if \$running_under_some_shell;

which is a noop under perl, and invokes a shell exec command under shell.  Perl
never invokes the exec ($running_under_some_shell is undef and therefore noop).

In this case, /usr/bin/perl is running their script, even if perlpath pointed
to /usr/local/perl5.8/bin/perl - and that's the last possible scenario we want.

If the reporter wanted this hack to work, #!/bin/sh  was the proper line one.

In any case, this sort of hack should be left to the value of $Config{startperl}
where it belongs, not a dozen workarounds in a dozen different projects.

Bill


Stas Bekman wrote:

Geoffrey Young wrote:



William A. Rowe, Jr. wrote:


Both lib/Apache/TestConfig.pm and lib/Apache/TestUtil.pm twist off their
own shebang lines from $Config{perlpath}, which is wrong.




I think part of this stems from this

  http://www.gossamer-threads.com/lists/modperl/dev/86017



Mike's patch used the original $Config{perlpath}, so no change there.


They should simply pull $Config{startperl} which defines the
shebang/command
on a platform basis.  See startperl= assignment from Config.pm.



You mean using $Config{startperl} instead of the hardcoded 
#!/usr/bin/perl  when the path is too long? I think that value makes no 
difference. At least not according to these resources:


# see: http://en.wikipedia.org/wiki/Shebang
# http://homepages.cwi.nl/~aeb/std/shebang/

If you have better ideas that would be wonderful :)

Re: Syntax issue in Apache/TestConfig.pm TestUtil.pm

[William A. Rowe, Jr.]

Stas Bekman wrote:

William A. Rowe, Jr. wrote:


I don't think the reporter understood the concept of

#!/usr/bin/perl
eval 'exec $Config{perlpath} -S \$0 \${1+"\$@"}'
  if \$running_under_some_shell;

which is a noop under perl, and invokes a shell exec command under shell.  Perl
never invokes the exec ($running_under_some_shell is undef and  therefore noop).

In this case, /usr/bin/perl is running their script, even if perlpath pointed
to /usr/local/perl5.8/bin/perl - and that's the last possible scenario we want.

If the reporter wanted this hack to work, #!/bin/sh  was the proper line one.


You mean:

sub make_shebang {
# if perlpath is longer than 62 chars, some shells on certain
# platforms won't be able to run the shebang line, so when seeing
# a long perlpath use the eval workaround.
# see: http://en.wikipedia.org/wiki/Shebang
# http://homepages.cwi.nl/~aeb/std/shebang/
my $shebang = length $Config{perlpath} < 62
? "#!$Config{perlpath}\n"
: <

Good point ;-)


In any case, this sort of hack should be left to the value of $Config{startperl}
where it belongs, not a dozen workarounds in a dozen different projects.


I'm not following you, how $Config{startperl} solves the problem of the 
long path, if just as you say it makes the script run under the wrong perl?


$Config{sh}, $Config{perlpath}, and $Config{perl} comes from -this- perl, right?
#/usr/bin/perl is a hardcode to an arbitrary perl installed at that location.

What I'm trying (failing?) to point out is that on BSD and other platforms, if
they have a bug, they can munge *PERL*, not ApacheTest, not each and every perl
script which creates perl files, with an effective value of $Config{startperl}.
I don't have a BSD box in front of me; but if ApacheTest used $Config{startperl}
rather than all of this other mechanics, then it would be up to BSD folks
to help the entire Perl community by fixing this ONCE with MakeMaker, and be
done with it.  By messing with constructing what MakeMaker's done since 5.0005
we are putting more work on ourselves, no?


Bill, mind to post a patch of what you think should work?


Yes, revert this patch, and replace these lines with = $Config{startperl}.
When I have a clean patch against head I'll post it.  I'll also look at the
state of MakeMaker to see if this issue -was- addressed there.

Bill

Re: Syntax issue in Apache/TestConfig.pm TestUtil.pm

[William A. Rowe, Jr.]

Stas Bekman wrote:

William A. Rowe, Jr. wrote:


What I'm trying (failing?) to point out is that on BSD and other platforms, if
they have a bug, they can munge *PERL*, not ApacheTest, not each and every perl
script which creates perl files, with an effective value of $Config{startperl}.


What you are missing Bill, is that there is no bug in perl or perl 
installation. It's a shell limitation documented here:


# see: http://en.wikipedia.org/wiki/Shebang
# http://homepages.cwi.nl/~aeb/std/shebang/


Right - I'm not disagreeing with the problem, I'm stating $Config{startperl}
when used by every program against your perl is either right, or it's wrong.
When Wrong, it's wrong for every program.  Ergo; bug is MakeMaker's to fix,
not ours, and...

I don't have a BSD box in front of me; but if ApacheTest used 
$Config{startperl}

rather than all of this other mechanics, then it would be up to BSD folks
to help the entire Perl community by fixing this ONCE with MakeMaker, 
and be
done with it.  By messing with constructing what MakeMaker's done 
since 5.0005

we are putting more work on ourselves, no?


I think there are two somewhat unrelated issues that are being discussed 
here -


1) using $Config{startperl} vs $Config{perlpath},

2) the issue with shebang code generation


...startperl is declared with a shebang, perl -e "print $Config{startperl};"
in your own environment :)  So the two are -one-in-the-same-

I think Geoff is thinking that Bill is suggesting to tackle #1, whereas 
Bill is only talking about #2.


I'm stating use startperl; both of you want the shebang bug (not ours) fixed,
so as I...


Bill, mind to post a patch of what you think should work?


Yes, revert this patch, and replace these lines with = $Config{startperl}.
When I have a clean patch against head I'll post it.  I'll also look at the
state of MakeMaker to see if this issue -was- addressed there.


...propose to throw away the gross hack, it's only fair if I show you also the
perl patch to create a *valid* MakeMaker $Config{startperl} result for those
on these shebang-constrained platforms.  Let's fix the bug, not a symptom.

Bill

Re: How is modperl 2 working with apache 2 under worker mpm?

[William A. Rowe, Jr.]

Khai Doan wrote:
How is modperl 2 working with apache 2 under worker mpm?  Has anyone 
successfully deploy modperl2 using worker mpm?  I recently wrote a 
script in perl using ithread and it kept failing.  Is there any 
guideline for writing modperl 2 handler using worker mpm?


Use the same threading model as httpd/worker; generally this is pthreads.
You will have to look at your apr.h generated file for information about
which threading model was chosen.  Ensure you build perl and httpd to
match one another.

Re: Concurrency with mod_perl 2.01 on Windows

[William A. Rowe, Jr.]

One thing that causes a significant performance degredation on Win32 is
fixed, we are looking at the second issue.

In APR, unbuffered writes were system-level flushing.  I believe this
had to do with some early network testing and multiple-writer concurrency
issues, but the end result is unacceptable, and you may be seeing this.
2.0.56 and 2.2.1 will likely incorporate this fix.

The other is multi-process concurrency using file level locking from byte
0 to -1 (unlimited).  This too has proven very slow, although I'm not yet
sure how much the previous issue impacted this apparent performance.

Effectively, on Unix write() is atomic, and in append mode, safe across
processes/threads.  On win32, we need to emulate this behavior.  That said,
just be aware that we are researching this.

The patch to the already committed quirk for 2.0 windows is here;

http://svn.apache.org/viewcvs?rev=378055&view=rev

Let us know if this alters your observed performance.

Yours,

Bill


Rod Morris wrote:

Hi all,

I'm porting some old perl code to a new installation of Apache/2.0.54 
(Win32) mod_perl/2.0.1 on Windows 2003 Server. In testing some file 
locking code, I noticed that response seemed very slow when I dumped in 
multiple jobs via multiple browsers to the server. I added a timer and 
saw the scripts waiting for one to finish before the next started as if 
they were queued waiting for the server.


I've got another server running freeBSD and it's set up to run mutilple 
instance of Apache which seems to deal with this. But on Windows, I 
haven't added anything for this and it comes up by default with 2 
instances of Apache.


It's my impression that threading should be used to deal with mutilple 
requests for one script, but that's not what I'm seeing. I'm seeing one 
script wait and then start when the last one finishes. MY script just 
gets the time, sleeps and then gets the time again.


Am I missing a configuration option or do I need a different version of 
perl? I installed for the standard combined Apache/mod_perl distribution.


Thanks,
Rod Morris

Re: Where's M_HEAD?

[William A. Rowe, Jr.]

Tyler MacDonald wrote:


My question is why HEAD == M_GET and not HEAD == M_HEAD. :-) It's
not a problem or anything, it just seems odd and I'm curious. I guess I'll
subscribe to Yet Another Mailing List and ask the httpd developers
themselves. ;-)


They are identical in terms of preparing the response / response headers,
until the answer is flushed at the client.  Since apache core is responsible
for that action, it takes responsibility for discarding the response body.

This dates back eons, when and if they ever differed, it probably created
many subtle bugs where code ignored HEAD v.s. GET, and therefore didn't
provide the same response to a GET resource as it had to the HEAD request.

Re: Where do the "warn" message go? (Ap2 & MP2 on Win32)

[William A. Rowe, Jr.]

Lionel MARTIN wrote:

Hi,
 
I'm currently running Apache 2.0.54 with MP 2.0.2, on Win32.
 
When I'm doing a
 
print STDERR "Hello\n";

warn "Hello\n";
 
at server startup, i.e.in a >Perl> block in httpd.cong, both messages go 
to the console, and to error.log as well.
 
But when I'm doing the same thing within a script (handleed by 
ModPerl::Registry), these message don't appear anywhere. So, I'm 
wondering where they get redirected? The fact I'm running that under 
Win32 (threaded MPMs) may be important?


http://httpd.apache.org/docs/2.0/mod/mod_cgi.html#scriptlog

Bill

Re: testing Apache/2.2 on Win32

[William A. Rowe, Jr.]

We recently removed cli-[dev/[EMAIL PROTECTED] and moved that traffic straight
to the general [EMAIL PROTECTED]/[EMAIL PROTECTED] lists.

I mention it because announcements like this could be very useful to [EMAIL 
PROTECTED]
folks.

Bill

Randy Kobes wrote:

For those Win32 users using ActivePerl 8xx, I've
placed at http://theoryx5.uwinnipeg.ca/ppms/
ppm packages suitable for use with Apache/2.2:
mod_perl-2.2, for mod_perl-2, and libapreq-2.2,
for libapreq2 (Apache2::Request and friends).
Note that if you're using Apache/2.2 you should
use these packages; the mod_perl and libapreq2
packages also available in this repository
were compiled against Apache/2.0, which aren't
compatible with Apache/2.2.

Re: mod_perl - make test fails on Solaris 10

[William A. Rowe, Jr.]

Sheila R. Bryant wrote:

Apache wouldn't compile with Sun compiler


It should, no troubles here.  You might need gmake, although we've tryed
to eliminate any gmake-isms.

If you have both installed, ensure SunStudio cc is in your path (oh please
oh please tell us you have cc 10.x or later!) and just export CC=cc before
you run ./configure.

Bill

Re: Apache2::AuthenNTLM + mod_perl 2.0.2 + Apache 2.2.2 -- problems

[William A. Rowe, Jr.]

Pease, Kevin wrote:

[Thu Jun 08 19:45:50 2006] [error] Bad/Missing
NTLM/Basic Authorization Header for /cgi-bin/whoami


This is interesting, consider that NTLM is a connection oriented protocol,
so you can't proxy it, and who knows what headers come along for the first
or second request in the sense that HTTP/1.1 expects them


So it seems as if the NTLM lookup is working, but it's reporting
these errors.  Here's the AuthenNTLM config from my httpd.conf:

AuthType ntlm,basic

Can anybody shed any light on the nature of this message?  I've
been trying different things to no avail for the past 2 days, so I'm
hoping somebody out there will have some idea of what I'm overlooking.


Since it says 'missing headers', what happens if you drop basic from your
list of supported auth types and require ntlm explicitly?

Re: STDERR with Apache2 and mod_perl 1.99 ?!

[William A. Rowe, Jr.]

It was a broken design pattern that worked in a single threaded server, but
under a multithread server, you can't switch around STDERR's handle and expect
not to break the reporting on the other threads.

True CGI is sending the output of the detached process that was exec'ed to one
specific handle.

It might be possible to reimplement stderr as a pipe which determines which
thread is doing the writing, or handling STDERR much like STDOUT is overridden.

Chris Hagglund wrote:
I am looking for information on how to get mod_perl 1.99 under apache2 
(is this a screwball setup? Its with plesk 7.5 on redhat) to send STDERR 
to the vhost error_log instead of the main apache error_log.


I have mod_cgi scripts which write to the vhost error_log via STDERR 
with no problem, but for some reason the mod_perl code is putting stuff 
into the main error_log. On my old server, mod_perl 1.29 and apache 1.3, 
mod_perl STDERR output goes to the vhost error_log with no problems. Any 
information is on how to deal with this is appreciated. Also if there is 
a searchable archive of this list can someone please point me to it? 
Thanks for any information.


Best,
Chris Hagglund.

.

Re: I swear, [idiots unsubscribe help request]

[William A. Rowe, Jr.]

Sorry, that's just hotmail making you feel like an idiot, they stopped
forwarding unsubscribe requests.

We've unsub'bed you, sorry bout the confusion.

Bill

Josh Narins wrote:
> I've sent a dozen messages to [EMAIL PROTECTED]
> 
> I never get a response.
> 
> I try, and try, and try again.
> 
> Please help.
> 
> Thanks in advance,
> 
> Josh
> 
> _
> Got something to buy, sell or swap? Try Windows Live Expo 
> ttp://clk.atdmt.com/MSN/go/msnnkwex001001msn/direct/01/?href=http://expo.live.com/
> 
> 
> 
> .
> 

Re: MapToStorageHandler and custom config

[William A. Rowe, Jr.]

Fred Moyer wrote:
> On Fri, 27 Oct 2006, John ORourke wrote:
> 
>> Hi folks,
>>
>> I've implemented some custom config directives, works fine.
>>
>> However, when my MapToStorage handler asks for the per_dir_config
>> hash, it seems to be getting the server config - all other handlers
>> get the per-dir no problem.
> 
> My guess is that you cannot access MapToStorage because at this phase
> the request has not yet been associated with a particular filename or
> directory [1].
> 
> [1]
> http://perl.apache.org/docs/2.0/user/handlers/http.html#PerlMapToStorageHandler

Note that MapStorageToHandler does this association, so hook ordering plays
a huge role.  It's critical that if you plan to morph the entity you do so
BEFORE the core directory_walk occurs, if you are inspecting it that should
happen AFTER to core directory_walk.

It's pretty simple; you shouldn't be modifying resources after they are vetted
by directory_walk.

That's why translations occur in the TranslateName hook.  MapToStorage really
should only be used to identify the URL to a resource, and if you are overriding
the default, then a resource not in the filesystem.

Re: SV: JOB [CONTRACT] + Re: Windows + MP2 in a production environment

[William A. Rowe, Jr.]

Foo JH wrote:
> Yes! It's really (in)famous! :) The more detailed error message seems to
> be captured in the Event Application log instead. I wonder why error.log
> wasn't more verbose on this one.

Because, once it crashes it's no longer logging?

Re: JOB [CONTRACT] + Re: Windows + MP2 in a production environment

[William A. Rowe, Jr.]

Foo JH wrote:
> 
> By 'bad code' you're referring to code written by app developers? I
> suspected I fall into that category, but even when I throw in all the
> eval traps, the .dll errors still come to crash (and automatically
> restart) apache.

By bad code, I mean flaws in apr, httpd, modperl, perl applications...
anywhere that brings you a segfault.

Keep in mind, using the official build of httpd you have .pdb debug
files that can be downloaded that exactly match the .exe/.dll's/.so's
that we ship.  That means you can -debug- these segfaults.

I'd hope that modperl would do the same for their module (and the whole
bundle if they ship httpd.)  They are invaluable.  Of course, you also
need the .pdb file from perl58.dll itself, I'd expect.

Re: JOB [CONTRACT] + Re: Windows + MP2 in a production environment

[William A. Rowe, Jr.]

Philip M. Gollucci wrote:
> William A. Rowe, Jr. wrote:
>> Keep in mind, using the official build of httpd you have .pdb debug
>> files that can be downloaded that exactly match the .exe/.dll's/.so's
>> that we ship.  That means you can -debug- these segfaults.
> Am I able to make these from UNIX ?
> Where can I read about this?
> 
> Randy/Steve ?

I do -not- know what sort of debugging symbol tables are emitted from mingw
or cyg toolchains, but VC compile flag /Zi shoves out the symbols into a
compiler database (/Fd directs the output to a particular database name)
and the link flags /debug /opt:ref /incremental:no creates an .exe and
run time symbol database by the same name as the linked file (httpsd.exe
gains httpsd.pdb).

Here's where things get confusing and why devs disable or throw these .pdb
files away.  1 - compiler .pdb's aren't runtime symbol databases (different
formats, even - although both are named .pdb).  You would only hang onto
a compiler .pdb that corresponds to a distributed link .lib binary.  And
2 - the /Zi flag doesn't inhibit or change the optimization, and 3 - the
link flags /debug /opt:ref /incremental:no only differ from a /release
build by a couple of PE flags that identify the emitted .pdb.  Finally,
4 - you must keep the exact .pdb's that correspond to the binaries.  You
can't regenerate them reliably, and especially cannot generate them after
the fact with a slightly different version of the compiler.

Think of .exe + .pdb as an unstripped unix pe binary, the symbols in this
case -are- stripped, over to the .pdb.  Users don't need the .pdb, but the
original binaries and .pdb file(s) must be present to open a user.dmp crash
file in a debugger, or for Dr Watson to produce truly intelligible output.

If you don't have a .pdb, and the compiler flag /Oy- is given, you can still
unwind the backtrace (with very limited clues).  But /O2 (without /Oy-) will
optimize the calling frames - so without a .pdb such backtraces are illegible.

Hope this offers a few clues; I've started to toggle /Oy- always since it
makes a Dr Watson backtrace offer a few clues about a crash without having
to grab the user.dmp file.  More hints are here;

  http://httpd.apache.org/dev/debugging.html#backtrace-win

See

Re: JOB [CONTRACT] + Re: Windows + MP2 in a production environment

[William A. Rowe, Jr.]

Issac Goldstand wrote:
> CC-ing to [EMAIL PROTECTED] in the hopes that someone 
> (**cough**wrowe?**cough**)
> might shed some deeper insight into why things were/are done the way
> they are, and what, if anything, would be needed to be done to make
> things better.
> 
> I don't think that the problem is mod_perl, as much as the winnt MPM in
> Apache2.  The bottom line is that if anything goes wrong, you need the
> singleton child process to recycle itself, and very often in the case of
> mod_perl that can take a long time.  But the essential problem still
> exists with PHP, mod_python, even theoretically in a minimal vanilla
> httpd install.

As Mladen hints, this was just 'the way it was done' since the Apache 1.3
MPM was first created.  I began to set up more of the structures for having
parallel running httpd's and Mladen took this one step further with his
winxp mpm, but the bottom line is that resource sharing just doesn't work
the same way on windows as unix, and things like interlocking parallel
writes by two processes to a log file, for example, still need additional
work to behave without a huge performance hit.

So you are strictly asking if winxp will ever become more tolerant of the
processes crashing due to bad code?  Well, the answer is yes, either parallel
running child processes and/or hot standby have always been on the table; if
someone has time to design (as Mladen did with winxp mpm) and enough win folk
have time to review (something that hasn't happened with Mladen's design.)

That will never solve the problem that your dead process just took down dozens
of parallel requests in the process.  And no - windows will never perform all
that well with 1 worker/process.  If you want a very insecure MPM, it would
be possible to defer the process exit after a fault on one thread (suspending
that thread while the others run out) but this makes root exploits far easier
to design.

Re: SV: JOB [CONTRACT] + Re: Windows + MP2 in a production environment

[William A. Rowe, Jr.]

Foo JH wrote:
> William A. Rowe, Jr. wrote:
>> Foo JH wrote:
>>  
>>> Yes! It's really (in)famous! :) The more detailed error message seems to
>>> be captured in the Event Application log instead. I wonder why error.log
>>> wasn't more verbose on this one.
>>
>> Because, once it crashes it's no longer logging?
>>   
> Yet it is able to restart itself automatically? I think there may be a
> piece of code that catches the fault. I just don't know if that piece of
> code can still log at that point in time.

Nope - the faulted child process simply dies.  The -parent- process is the
one which detects this event and launches a replacement child process.

Look in task manager - and choose to show #threads.  One will be running
only a few threads - that's the parent, and one will have dozens or even
hundreds of threads depending on MaxClients.

Ugly build scenario...

[William A. Rowe, Jr.]

On a very fast dual cpu xeon box, configuring and then running make under
linux gives me;

make[1]: Warning: File `Makefile.PL' has modification time 3.7e+03 s in the 
future
Makefile out-of-date with respect to Makefile.PL
Cleaning current config before rebuilding Makefile...
make -f Makefile.old clean > /dev/null 2>&1

This isn't very funny.

Is there any magic in the modperl2 or Apache-Test configurations that would
be dinking the datestamps?  Has anyone seen similar?

Re: Ugly build scenario...

[William A. Rowe, Jr.]

Nevermind

 - no, it's not fun - and the project really should rethink failing
   with an error or offering an override to bypass this error.

In this case it was svn's bogus use checkout/export time and crossing timezones
that have screwed up my datestamps.  For a project with extreme dedication to
metadata, this screwball default always trips up.

Bill


William A. Rowe, Jr. wrote:
> On a very fast dual cpu xeon box, configuring and then running make under
> linux gives me;
> 
> make[1]: Warning: File `Makefile.PL' has modification time 3.7e+03 s in the 
> future
> Makefile out-of-date with respect to Makefile.PL
> Cleaning current config before rebuilding Makefile...
> make -f Makefile.old clean > /dev/null 2>&1
> 
> This isn't very funny.
> 
> Is there any magic in the modperl2 or Apache-Test configurations that would
> be dinking the datestamps?  Has anyone seen similar?
> .
> 

Re: Segmentation fault(11) on AIX - searching the archive couldn't so lve my problem

[William A. Rowe, Jr.]

[EMAIL PROTECTED] wrote:
> 
> I've searched a lot throug the archive of this mailinglist and found lot's
> of postings also pointing to Segmentation fault (11), but usually the
> suggested solution was to have a look in the SUPPORT-file in the mod_perl
> directory.

Actually, the suggested solution is always the same, get a crash dump (core)
and unwind it in gdb (or dbx on AIX).  Lots of google links will tell you
more.  When you have the backtrace/stack dump, we'd be interested.

Most likely, your httpd and perl builds aren't compatible.  If it's some
other issue, the backtrace is essential to help you further.

Re: supported modperl? [was Zend PHP]

[William A. Rowe, Jr.]

If you are looking for a commercially supported modperl distribution
for 1.3/2.0/2.2, and you happen to fall into one of Windows Server,
Linux x86, Solaris x86 or sparc, hpux parisc2 or aix ppc/power you might
want to investigate http://www.covalent.net/solutions/ers/index.html
[Disclaimer: I'm the build mgr

Sometimes it's just next to impossible to get your preferred technology
solution past upper management when "which vendor?" comes up  :(

PHP, Perl, Python and Ruby each have their own technology issues which
your choice of vendor really won't address.  So focus on the technology
that best fits your development team - and toss out the questions to
the lists and some vendor/consulting firm will make it possible for you
to use the technology you really need :)

Bill

Martin Moss wrote:
> I just had a demo of the Zend Platform and framework
> for php.
> It's got some really nice stuff, but ultimately the
> reason we may decide to ditch perl and move to php
> (h I know booo) will be down to support. OR
> lackthereof for Perl...
> 
> So my question is, given I'm not a php fan, Is there
> an equivalent PERL based commercial entity who will
> provide support for a medium sized web outfit?
> 
> Marty
> 
> 
> 
>   
> ___ 
> Copy addresses and emails from any email account to Yahoo! Mail - quick, easy 
> and free. http://uk.docs.yahoo.com/trueswitch2.html
> 
> 

Re: Mod_Perl2 vs. Mod_Perl1, MPM_WORKER....

[William A. Rowe, Jr.]

Perrin Harkins wrote:
> On 3/26/07, Frank Wiles <[EMAIL PROTECTED]> wrote:
>> > Further, what success have people had using threading with mod_perl2,
>> > using MPM_WORKER?
>>
>>Other than for some testing of modules I haven't found a need to use
>>either the threaded or worker MPMs.
> 
> I'd second that.  The general advice is to avoid using threads if you
> are on a unix-like system.  They are slower and use more memory than
> the prefork MPM on those systems.

Hmmm, been using it here for about 6 years.

Careful with FUD, threading by definition is lighter weight than processes,
although the older Linux threads certainly didn't measure up.

Bill

Re: Fw: Re: mod_perl closes apache's stdin and/or stdout

[William A. Rowe, Jr.]

Stas Bekman wrote:
> 
> But which file to open as a place holder? In this example I use
> /dev/null and it works as you wish. AFAIK, windows doesn't have
> /dev/null, unless you run on cygwin.

Of course, it does, but it has the classic MS-DOS name of "NUL"
present in the context of any directory (so \dev\nul works if you
have a dev directory.)

Re: Fw: Re: mod_perl closes apache's stdin and/or stdout

[William A. Rowe, Jr.]

Stas Bekman wrote:
> William A. Rowe, Jr. wrote:
>> Stas Bekman wrote:
>>> But which file to open as a place holder? In this example I use
>>> /dev/null and it works as you wish. AFAIK, windows doesn't have
>>> /dev/null, unless you run on cygwin.
>>
>> Of course, it does, but it has the classic MS-DOS name of "NUL"
>> present in the context of any directory (so \dev\nul works if you
>> have a dev directory.)
> 
> I guess this can be ifdef'ed then.
> 
> Bill, so /dev/null and NUL should cover all grounds Apache runs on, or
> are there other odd cases? And if so do you have a better idea for a
> file to open that will work everywhere? [also notice that it has to be
> rw - and if not, we need two files then, one for < and another for >,
> otherwise open will fail.

AFAIK - [EMAIL PROTECTED] might be an interesting collection of folks to ask.

Re: Apxs not installed

[William A. Rowe, Jr.]

Martijn wrote:
> Hello.
> 
> While rebuilding our webserver, I am trying to install modperl 2.0.3
> under Apache 2.0.52 on RHEL4. However, when I run 'perl Makefile.PL',
> it says it can't find apxs. I am quite sure it isn't installed -find
> doesn't find it, so it definitely doesn't exist under its own name-
> but if I understand things correctly, it is standard part of Apache.
> Am I missing something?

That would be a question for a RH list, no?  We don't even try to grok
w.t.f. vendors do with their distributions.

But just as an observation, apxs might have been chucked at an /sbin
path, or renamed to disambiguate apxs-1.3 from apxs-2.0, or not be
installed at all unless you install some httpd-devel package.  This
isn't really the right place to find out why redhat did what and why :)

Bill

Re: Where is Perl compilation output when using modperl ?

[William A. Rowe, Jr.]

Alvar Freude wrote:
> Hi,
> 
> -- Jens Helweg <[EMAIL PROTECTED]> wrote:
> 
>> Is there a way to get the compilers output from perl, so I can get
>> details on what is wrong in the code ?
> 
> usually you get the errors in the apache's error log. I don't know where
> it is stored on Windows, you may look in your httpd.conf.

Starts out recorded in the Application Event Log as 'Apache' events, until
we have an error log open and usable.

Starting bin\httpd.exe from the command line is sometimes more educational
than launching the Apache service.  At least errors have a console to land
in and inform you what's going on.

Re: apache and php

[William A. Rowe, Jr.]

Eli Shemer wrote:
> 
> I have installed mod_perl 1.3 statically to apache while using php as a DSO
> 
> After I've gracefully reloaded apache, php stopped working
> 
> What is the best way to get them both working together ?
> 
> Should I statically link php as well or do I have to use mod_perl as a DSO ?

Did you forget to build mod_so into 1.3?

Bill

Re: [mp2+Win32] Frustration over Apache 2.0/ 2.2 restart failure

[William A. Rowe, Jr.]

Foo JH wrote:
> Hi all,
> 
> I am rather disappointed (and a little frustrated as well) on modperl's
> inability to survive an Apache restart on the Windows platform. The
> platform combo tested are Windows 2003 + Apache 2.2 (and Apache 2.0) +
> modperl2 + libapreq2

Foo - I'm honesty clueless.  I've seen no issues.  Issues with running
very crufty perl or php over time, but not restart issues.

This probably has nothing to do with either Apache, Perl or mod_perl.

It's most likely DB clients or something you've instantiated that is
still running/shutting down for that minute you observed.  If you crank
down your loglevel to debug, can you determine anything more about your
particular situation?

Re: SV: [mp2+Win32] Frustration over Apache 2.0/ 2.2 restart failure

[William A. Rowe, Jr.]

> Apache/ modperl starts up fine, but if I try to restart the service, it
> will not survive.
> 
> Please share with me any tips to improve the situation. I'm open to any
> ideas.

Foo, you missed my point all together.

Something in YOUR PERL APP is opening resources that are "locked" and will
prevent another process from obtaining them for approx 60 seconds.

What, why and how are your puzzles, I'm afraid.  There's nothing in the
"generic" apache/perl/modperl that did this to you.

More debugging logs, finer debugging details might help you pin it down.

Re: Scripts works under CGI but not under mod_perl (and thread stack size)

[William A. Rowe, Jr.]

Perrin Harkins wrote:
> On 8/14/07, Manoj Bist <[EMAIL PROTECTED]> wrote:
>> Is it possible to change the stack size in mod_perl(Similar to ulimit -s
>> unlimited etc.)?
> 
> The stack size?  What are you trying to do?  I'm not aware of anything
> special about stack size in mod_perl that would be different from any
> other compiled C program.

http://httpd.apache.org/docs/2.2/mod/quickreference.html

  ^F stack

> Also, why do you mention threads?  Are you running a threaded MPM?
> Unless you're on Windows, I'd advise you to run prefork.

Few issues here running threaded, but that depends on a host of other
decisions (ancient library bindings, different host contexts, etc).

Re: Scripts works under CGI but not under mod_perl (and thread stack size)

[William A. Rowe, Jr.]

Perrin Harkins wrote:
> 
> It definitely could be the cause of issues with a C library using
> sockets that isn't written to be threadsafe.  The general reason to
> use prefork though is the more efficient use of memory due to
> copy-on-write.

I'm familiar with copy-on-write.  Could you elaborate?  From httpd's
perspective, those same gains are true of worker as well.

One of my more favorite features of the pre-SMS apr pools was my patch
to permit "locking" a pool read-only.  This let us see that folks were
not jinxing the copy on write behavior of the process and config pools
in httpd by writing back data (and breaking the read-only paged copy).

Of course two iterations later, my hacks were ripped from APR.  Another
round-tuit to restore that behavior :)

Bill

Re: Scripts works under CGI but not under mod_perl (and thread stack size)

[William A. Rowe, Jr.]

Manoj Bist wrote:
> 
> That's why I want to try bumping up the stack size for
> apache/mod_perl. So far I have not been able to find out if that is
> possible in apache2. 0.

Dude - I gave you the answer hours ago

http://httpd.apache.org/docs/2.0/mod/quickreference.html

search for the word "stack" and answer your own question

Re: Scripts works under CGI but not under mod_perl (and thread stack size)

[William A. Rowe, Jr.]

William A. Rowe, Jr. wrote:
> 
> http://httpd.apache.org/docs/2.0/mod/quickreference.html
> 
> search for the word "stack" and answer your own question

So... testing against worker mpm, the answer is no; ThreadStackSize
is not a supported directive.

Sorry - I'm not often in the internals of prefork/worker, so I'm
going on other MPM's.  But I thought this one was already common :(

Bill

Re: Using Apache 2.2 from ApacheLounge for Win32 modperl

[William A. Rowe, Jr.]

Randy Kobes wrote:
> On Sun, 19 Aug 2007, Foo JH wrote:
>>
>> My recommendation:
>> 1. Use the Apache2.2.x binary from ApacheLounge
>> 2. Use the MSI version of ActivePerl, NOT the AS version
>> 3. Use the mod_perl library from theoryx5, NOT from ApacheLounge
>> 4. Use the libapreq2 library from theoryx5
>>
>> Tested on Windows XP SP2 x86
> 
> This might be a result of what was mentioned before about possible
> problems using the binaries from http://www.apachelounge.com/download/
> (which is compiled with VC++ 2005) with ActivePerl and
> ActivePerl-compatible ppm packages (which are compiled with VC++ 6).
> Mixing these can lead to conflicts, as discussed at, eg,
>  http://search.cpan.org/src/SHAY/Win32-UTCFileTime-1.46/INSTALL

This is the primary reason that Apache 2.0 and 2.2 ship based on VC 6
builds.  In order to maintain binary compatibility, they depend on the
more reliable (at that time) VC 6 C Runtime.

I wouldn't mix and match at all.  Expect from one provider a solid set
of binaries, either all VC 6 as found from AS and the ASF.  Or entirely
use another vendors build entirely built with VC 2005.  Either way, if
you mix and match you will find surprises.

> Also, note that the apache-2.2.5 release available from
> http://www.apachelounge.com/download/ is based on sources
> which have not officially been released by the ASF:
>   http://marc.info/?l=apache-httpd-dev&m=118747498301087&w=2

Actually note that it isn't a release and is being rerolled.  Seems
Apachelounge is doing themselves and their users a disservice, again.
You'll be keeping your eye out for a 2.2.6 (or later in the event of
some calamity with that reroll).

Bill

Re: Disconnection from basic auth

[William A. Rowe, Jr.]

Geoffrey Young wrote:
> 
> Matthieu FEREYRE wrote:
>> I use a basic authentification (Apache2::Access) wich works fine, but my 
>> question is :
>> How do I disconnect users ?
> 
> the short answer is that you can't.  this is why you don't see popup
> authentication anywhere anymore :)
> 
> "When you determine that the client should stop using the
> credentials/session key, the server can tell the client to delete the
> cookie. Letting users "log out" is a notoriously impossible-to-solve
> problem of AuthBasic."

Or more to the point, you can never log into HTTP either ;-)

HTTP is stateless.  Each request comes in with (optionally) a cookie,
user, and/or password.  The request has nothing to do with the last
request unless the server told the client to present a cookie.

With HTTP auth such as basic, when it sees someone it doesn't know, the
server returns NOT AUTHORIZED.  The client offers a popup, and provides
a user and password.  If those don't work, again, NOT AUTHORIZED.

Cookie-based auth remembers a session in a cookie.  When the cookie is
missing, the server sends an HTTP auth or a form based auth page, until
the user successfully "connects".

But the idea of "disconnecting" the user?  Not Applicable :)  The client
may immediately send the request with the required user/password fields,
so you would want to keep keep-alives enabled.  The only "disconnect"
is to tell the client to forget it's cookie (which certainly isn't any
sort of "security").

Bill

Re: PerlRequire executed 4 times on apache startup

[William A. Rowe, Jr.]

Tobias Zeising wrote:
> Hi all,
> 
> I have a weird problem: on startup apache executes 4 times a Perl Script
> I included via
> 
>  PerlPostConfigRequire startup.pl

Yes, as Foo observed, this will happen 2x on Unix, 4x on Windows due to the MPM.

Notice that 1x and 2x (and 5x and 8x and 11x upon restarts) are all occurring
in the parent.  They aren't in the worker process at all, they were only pre-
tested to ensure your script compiles and runs.

The 3x and 4x times are in the child process that serves your request.  First
to pretest the config (yes, again!) and then the copy that will persist until
the worker process terminates.

Upon a graceful restart, that copy dies, the config is reprocessed in the parent
1x only again, and then 2x in the child.

We could (obviously) dump the extra success-test in the child.  But doing so
would break a huge assumption by coders like yourselves that rely on the pre
test followed by the actual run.

On Unix, you will see it run 1x for config test, followed by the 2x for the
worker children.  On a graceful restart, you'll see it happen a 3x time, etc.

Bill

Re: seg faults when running modperl and GD::Graph

[William A. Rowe, Jr.]

Manoj Bist wrote:
> One option would to be run apache under single threaded mode(option
> -X) under gdb  and see where it is crashing.  Once you identify the
> .so where it is crashing, you can try reproducing the crash outside
> apache context.

See also http://httpd.apache.org/dev/debugging.html

Re: seg faults when running modperl and GD::Graph

[William A. Rowe, Jr.]

Matt Williamson wrote:
> So I got apache to run under gdb, but I still am somewhat non-the-wiser.
> It appears to happen the second time that the handler is used to process
> the request, so I guess one workaround would be to call my script as a
> plain cgi. 

FYI compiling with -g will often give more more intelligible results
from gdb.  This should include the way you build both perl and httpd,
and therefore mod_perl.

Re: Child processes/cache question

[William A. Rowe, Jr.]

David Willams wrote:
> Condition: I'm pre-load sharable data at apache start, but I also have
> different data that is caching itself within child processes. 
> Goal: to pre-cache within each process, the data that cannot be cached
> within the shared space.
> 
> Not sure if I'm asking this correctly, but is there a method by which
> child processes may do their own start-up routine ( i.e. pre-cache) at
> fork time from the parent? Now, each process basically does this on
> first use.

child_init hook?

Re: resend: Bug report re: Apache 2.2.6 on Windows

[William A. Rowe, Jr.]

Tom Donovan wrote:
> 
> -8<-- Start Bug Report 8<--
> 1. Problem Description:
> 
>   perl-script handler fails with Apache 2.2.6 on Windows
>   due to changes in stdin/stdout/stderr handles in mpm_winnt
> 
>   Problem occurs with mod_perl 2.0.3 or with
>  current (9/14/2007) SVN trunk.

>   This is similar to, but not the same as, Apache bug 43329
> http://issues.apache.org/bugzilla/show_bug.cgi?id=43329
>   which concerns the APR 1.2.11 process-creation changes.
> 
>   This problem can be avoided if \server\mpm\winnt\mpm_winnt.c
>   from Apache 2.2.4 is used - even with APR 1.2.11.

Yes; definately a different problem although a side effect of the same
attempt to fix the issue.  What is interesting

>   Failure is at line 128 in modperl_io.c
> (function modperl_io_perlio_override_stdin)
> 
> modperl_io.c - in function modperl_io_perlio_override_stdin
> 124/* open my $oldout, "<&STDIN" or die "Can't dup STDIN:
> 125status = do_open(handle_save, "<&STDIN", 7, FALSE,
> 126 O_RDONLY, 0, Nullfp);
> 127if (status == 0) {
 128Perl_croak(aTHX_ "Failed to dup STDIN: %" SVf,

is that mod perl is attempting to protect us from ourselves even before
the fixes went into win32.  Of all of the adjustments in version 2.2.6,
try backing out only this single effect of the patch, which closed stdin
on both the parent and child, and please confirm if this alone is enough
to placate mod_perl?  (This would be patch -R to revert the following.)

--- httpd/httpd/branches/2.2.x/server/mpm/winnt/mpm_winnt.c 2006/09/15 
13:19:25
446606
+++ httpd/httpd/branches/2.2.x/server/mpm/winnt/mpm_winnt.c 2007/08/24 
22:04:23
569541
@@ -1297,6 +1297,9 @@
0, TRUE, DUPLICATE_SAME_ACCESS)) {
 SetStdHandle(STD_OUTPUT_HANDLE, nullstdout);
 }
+
+/* Close the original handle, we used the duplicate */
+apr_file_close(nullfile);
 }
 }
 }
@@ -1635,6 +1638,9 @@

 /* Set up the listeners */
 get_listeners_from_parent(s);
+
+/* Done reading from the parent, close that channel */
+CloseHandle(pipe);

 ap_my_generation = ap_scoreboard_image->global->running_generation;
 }

Re: resend: Bug report re: Apache 2.2.6 on Windows

[William A. Rowe, Jr.]

William A. Rowe, Jr. wrote:
> 
> is that mod perl is attempting to protect us from ourselves even before
> the fixes went into win32.  Of all of the adjustments in version 2.2.6,
> try backing out only this single effect of the patch, which closed stdin
> on both the parent and child, and please confirm if this alone is enough
> to placate mod_perl?  (This would be patch -R to revert the following.)
> 
> --- httpd/httpd/branches/2.2.x/server/mpm/winnt/mpm_winnt.c   2006/09/15 
> 13:19:25
> 446606
> +++ httpd/httpd/branches/2.2.x/server/mpm/winnt/mpm_winnt.c   2007/08/24 
> 22:04:23

Belay that request :)  I missed something.

I'll follow up with a patch that opens /device/null for stdio/faux-posix
as well as MS filehandles, and shoot that to the list in a bit (along with
post my concept to that other bug, so we can look at all of it.)

Re: resend: Bug report re: Apache 2.2.6 on Windows

[William A. Rowe, Jr.]

Tom Donovan wrote:
> Michael Lackhoff wrote:
>> On 23.12.37378 20:59 Tom Donovan wrote:
>>
>>> 1. Problem Description:
>>>
>>>   perl-script handler fails with Apache 2.2.6 on Windows
>>>   due to changes in stdin/stdout/stderr handles in mpm_winnt
>>>
>>>   Problem occurs with mod_perl 2.0.3 or with
>>>  current (9/14/2007) SVN trunk.
>>
>> I noticed the same problem with Apache 2.0.61.

This is consistent at least.  In fact the same changes were applied
to both.

>>>   This problem can be avoided if \server\mpm\winnt\mpm_winnt.c
>>>   from Apache 2.2.4 is used - even with APR 1.2.11.
>>>   Note that server\log.c line 411 also needs to be changed to
>>>   work with this older mpm_winnt.
>>
>> I would like to try this but since I am not a C programmer, can you say
>> what the changed line in log.c should look like?
>> And is there a similar fix for 2.0.61? I would prefer to stay with the
>> 2.0.x branch for the time being.
>>
>> - Michael
> 
> The change I made in 2.2.6 was to line 411 in server\log.c
> --
> CHANGED:
> 
> rv = apr_file_dup2(stderr_log, s_main->error_log, stderr_p);
> 
> TO:
> 
> if (stderr_log)
> rv = apr_file_dup2(stderr_log, s_main->error_log, stderr_p);
> else
> rv = apr_file_dup(&stderr_log, s_main->error_log, stderr_p);
> --
> 
> Note the '&' character before 'stderr_log' in the call to apr_file_dup.
>  This differs from the call to apr_file_dup2, and it's easy to miss.

Yes, of course.  However in the second case, you do not have an inheritable
file handle.  apr_file_dup simply dups the handle in the current process,
so the patch can't possibly have the desired effect.

There is a real concern; under what conditions would stderr_log not be
initialized.  *therein* lies the bug.

> The line to change in server\log.c for version 2.0.61 is line 413.
> You must also replace server\mpm\winnt\mpm_winnt.c with the one from
> Apache 2.0.59.  I haven't tried this with Apache 2.0 and AFAIK nobody
> else has, so please test carefully.
> 
> Also note that this reverses the changes which improved piped logging
> for 2.2.6 (2.0.61).

And, I believe, breaks piped logging processes again, although this would
be noticed in 2.2.6 not 2.0.61, because we launch a pipe log process in
2.0, while we launch a pipe log cmd shell in 2.2.

Re: resend: Bug report re: Apache 2.2.6 on Windows

[William A. Rowe, Jr.]

Michael Lackhoff wrote:
> On 18.09.2007 15:47 William A. Rowe, Jr. wrote:
> 
> Hmm, I don't understand this, so I cannot say how serious it could be.
> My question is: Should I stick with 2.0.59 or upgrade with a patched
> 2.0.61/2.2.6?
> This is a production server and the change log lists quite a few
> security fixes for the new versions.
> As long as all that could be broken is logging, I think I would like to
> upgrade or could the change effect other parts as well (security)?

Read the security fixes.  Primarily, unix-environmental changes.  Nothing
high severity if you trust the authors of web content dispatched by your
server.

Solution to apr stdio/msvc crt/service handles and logging

[William A. Rowe, Jr.]

Presented in two parts, the first;

http://people.apache.org/~wrowe/apr-1.x-win32-nohandle.patch

contains several changes that I believe will help the modperl community,
the mod_fcgid folks and virtually anyone attempting to do handle mashups
of different posix based engines on Win32.

In the previous fixes to APR 1.2.11, we stopped setting unused pipes
(where some were used) to the INVALID_HANDLE value.  We started in 1.2.11
to replicate stdin/out/err, where set to APR_NO_PIPE, as the parent's
standard handles.  This conforms to the unix implementation.

If this affected only compiled modules, fine, we'll just ask users to
absorb that pain.  But in fact every fcgid-style binary is compiled on
assumptions on windows about these handles.  We need a way for any
mod_fcgid style server to permit all of these compiled apps to continue
with their assumption, while not disrupting the typical case of using
APR to ensure portability.

The patch permits a new value to apr_procattr_io_set for any of the
three pipe creation mechanisms.  APR_NO_PIPE continues the new 1.2.11
behavior and replicates the parent's stdin/out/err where it's used.
APR_NO_FILE is a special case for *windows* APR 1.2, and would become a
portable feature in APR 1.3.  In the unix case, the designated NO_FILE
handles would be closed after fork, before exec.  In the windows case,
they are not inherited, and the child process sees INVALID_HANDLE_VALUE.

Now your obvious questions, what happens if an APR_NO_FILE is seen by
an older binary of APR?  APR_NO_PIPE, it simply inherits the old handle,
which is the default unix behavior, and new-1.2.11 default win32 behavior.
I've checked each code path, and on all platforms this is true.  I picked
the value 8 just to keep it out of the way of any bitmask we might choose
to apply.  And of course, where's the unix implementation for 1.3?  Just
haven't gotten to it yet, it's trivial to implement and I'll hack that
up shortly after we decide if we are on the right track.

Comments?

The second piece of this patch is trivial.  It's possible that a given
standard windows handle is either NULL, or INVALID_HANDLE_VALUE.  It was
impossible to apr_file_stderr_open() so it becomes impossible to then
apr_file_dup2(stdhandle, sourcehandle, pool) with out the apr_file_t of
stdhandle.  We coerce any NULL handle into an INVALID_HANDLE_VALUE and
add an internal ->flags tag corresponding to the stdXXX handle opened.
This lets us replace the std apr_file_t with no pain, no comparison to
the unassigned standard handle.

Comments?

On the third piece of this patch, the calls to apr_file_dup2() become
MSVC-aware, and correctly wire up the plumbing of the CRT.  Now this is
still not going to solve every problem, because there are local artifacts
per-CRT version, and in an httpd server using one version for apr/httpd,
another for a compiled module, and perhaps another for the language linked
in (e.g. AS python or perl) these can become disjoint.  Regrettable, but
also unavoidable.

Since day 1, APR only contended with the Win32 API layer standard handles.
This patch changes that behavior, and I believe it has a direct impact on
the modperl module.  Since modperl is emitting noise of it's troubles into
the stderr (CRT-style) stream, we dumped that on the floor on Win32.  With
this patch, we should be able to capture emits from modules, libraries etc
which are filling the stderr stream with useful diagnostics.

We also need to consider the impact of the _O_BINARY flag, an atypical
win32 use.  But we don't want piped in/out/err to be subject to random
or malicious emits of ^Z and other strange side effects beyond \n handling.

The exciting news, modperl startup failures and syntax diagnostics will land
in the error log.

Comments?

Continuing on to the second part;

http://people.apache.org/~wrowe/httpd-2.x-logging.patch

Another third trouble for modperl and this patch was lurking in mpm_winnt
from the 2.2.6 release, and the apr patch above isn't sufficient.  I've
simplified the processing of stdin/stdout handling and nt_eventlog stderr
handling, based on these existing apr features.  One patch doesn't work
terribly well without the other, due to these cart-before-the-horse issues.

Also we held open the first piped logger by sharing it's fd with the
child process, since we hadn't torn down the stale plog pool before we
invoke the new logger.  This is by-design, but because there were two
copies of the fd the logger wouldn't go away.  Attached is the Rudgier's
proposed patch (as we were hacking away to the same solution at the same
time, but his comments are more filling).

We had been fixing up the Win32 STANDARD_INPUT to the \device\null channel
without the corresponding stdio pseudo-posix fix, and this caused pain to
modperl in particular.  Because APR is now used for all of these issues,
future issues will be solved hopefully with apr-specific fixes only.

Comments?

That's it, long post, two modestly large (much of it triplica

Re: Solution to apr stdio/msvc crt/service handles and logging

[William A. Rowe, Jr.]

> http://people.apache.org/~wrowe/apr-1.x-win32-nohandle.patch
FYI - that one does not apply cleanly to apr-1.2 (it's trunk)

if you want the easily applied flavor, that would be;

http://people.apache.org/~wrowe/apr-1.2-win32-nohandle.patch

The httpd patch applies with little pain.

Re: Solution to apr stdio/msvc crt/service handles and logging

[William A. Rowe, Jr.]

Randy Kobes wrote:
> 
> I'm currently rebuilding everything with VC 8 (the free
> version), and will report on that later.

Yea - I discovered it's quite impossible to get msvcrt-linked activestate
to cooperate with openssl compiled against msvcr80, and probably not against
httpd+mod_perl against msvcr80.

Even errors silently ignored before cause segfaults now when activestate
tries to touch pseudo-posix files and visa versa because msvcr80 has all
of the additional parameter checking.

Really, building exclusively against either msvcr80 or msvcrt is the only
way to go, and that includes all the bits.

Bill

Re: Solution to apr stdio/msvc crt/service handles and logging

[William A. Rowe, Jr.]

Randy Kobes wrote:
> 
> The patched version built fine, and with the svn mod_perl2
> sources, and perl-5.8.8 (ActivePerl 822), all the mp2
> tests passed using VC++ 6. Great work!

FYI I'm waiting on a third set of eyeballs before this is all committed.
I'd especially appreciate any input from Tom w.r.t. the ease of adding
APR_NO_FILE flags to apr_procattr_io_set() members whom are not allowed
to have a handle at all, eg. how this works out with mod_fcgid and similar
modules.

Once that is done, I've been ready to commit.

Bill

Re: Best version of Apache for Win32 deployment

[William A. Rowe, Jr.]

Foo JH wrote:
> Hi all,
> 
> Just want to share something I read today (fairly old news) at
> ApacheLounge:
> http://www.apachelounge.com/forum/viewtopic.php?t=1907
> 
> Since many (most?) people who use Apache from Apache Lounge also use
> mod_fcgid and/or mod_perl, it seems that 2.2.5 will remain the best
> Apache version to use until Apache 2.2.7 comes out.

Right.  Except there is no 2.2.5; you are best staying with 2.2.4 IF you
can live without 'rotatelogs' or other piped logs, AND you need mod_perl
or mod_fcgid.  If you don't use these modules you are best off using 2.2.6
which was released.

> It is expected that new versions of mod_fcgid and mod_perl will be
> needed for Apache 2.2.7, because the proposed changes will not be
> backward-compatible with Apache 2.2.5 and earlier.
> 
> My point is that for Win32 modperlers, you may want to check out 2.2.5,
> and hold out for 2.2.7 (and a potentially new release of modperl to
> support it).

Again, there is no 2.2.5, so there is no purpose to your struggling with
it and any associated bugs.  Also Tom Donovan has cautioned users against
using the hacks they applied to 2.2.6 to get it to work, use it if you
must but it's apropos of nothing to the final corrections.

Of course 2.2.4 essentially worked, while 2.2.7 will give the modperl'ers
on Windows something they have BEGGED for forever, the chance to see parsing
errors at startup from their httpd.conf file(!!!)

ALL 2.x versions of Apache on Windows had never hooked up the pseudo-posix
stderr of MSVCRT, which is why fprintf(stderr...) constructs from within
modperl rarely did what they were expected to do.  With the 2.2.6 version,
things broke further as stdin went away after it was consumed (it was replaced
with NULL, but not at the MSVCRT layer).

If you update to svn.apache.org/repos/asf/apr/apr/branches/1.2.x/ today,
you'll find the 80/20 has been resolved; we now plug into pseudo-posix
handles.  There are still some lingering issues to be fixed in httpd itself.
Tom Donovan and Randy have already approved with Win32 fixes, but we still
are waiting on an httpd'er to review the essential fix to log.c.  I'll
send another note to the modperl community when we believe that the
svn.apache.org/repos/asf/httpd/httpd/branches/2.2.x/ is ready for intensive
review and testing, after that patch is applied (same applies to 2.0.x, needs
patch review, while apr/branches/0.9.x/ has already been patched).

Bill

Re: Best version of Apache for Win32 deployment

[William A. Rowe, Jr.]

Foo JH wrote:
> 
>> Right.  Except there is no 2.2.5; 
> 2.2.5 is not released on the Apache web site. Those who want this
> version can get it at ApacheLounge.

They can get it from SVN too, that doesn't mean it's an ASF version.

The ASF specifically rejected it, which makes it's persistence a pretty
sorry state of affairs for the hoster :)

Bill

Re: Best version of Apache for Win32 deployment

[William A. Rowe, Jr.]

Octavian Rasnita wrote:
> 
> I tried Apache 2.2.4 with and without SSL support, and Apache 2.2.6 from
> apachelounge, but they still don't work.

Simply put; Apache 2.2.4 did work.

The one-off build at AL of 2.2.6 isn't 2.2.6; 2.2.5 represents an aborted
attempted at a release, none of the above represents what will be in 2.2.7
for you to move forward.  In light of this;

You are best off, needing this today, to see the earlier posts on this
list of which combinations of binaries for 2.2.4 were known to work.

Bill

Re: Best version of Apache for Win32 deployment

[William A. Rowe, Jr.]

Foo JH wrote:
> Octavian Rasnita wrote:
>> Regarding the best Apache for Windows, I have a problem running Apache
>> under
>> windows and I think this thread might help me.
>>
>> I tried Apache 2.2.4 with and without SSL support, and Apache 2.2.6 from
>> apachelounge, but they still don't work.
> I'm using 2.2.4 now on Win32, and it's running good for me. Much much
> better than the 2.x.x series from the Apache site. Works on XP and W2k3.
> 
> A point to note though is that you should not use the modperl
> compilation from AL. Use the standard-issue one from theoryx5. Install
> libapreq2 from theoryx5 also.

EXACTLY.

Because you used theoryx5's perl/modperl/libapreq2 built for VC8, along with
the AL build of 2.2.4 ALSO built for VC8, everything is dandy.

Equally if you used ActiveState perl (built VC6) + a VC6 build of modperl and
libapreq2 with the ASF distribution of httpd 2.2.4, everything is dandy.

Mix and match at your own risk.

Re: Best version of Apache for Win32 deployment

[William A. Rowe, Jr.]

Octavian Rasnita wrote:
> 
> And I tried starting the server, but it appeared an error window "Visual
> Studio just in time debugger" and it also printed the following errors
> in the command prompt:

That's a crash.  Studio will give you all the info but it's harder to
navigate, for some information on obtaining the dr watson backtrace see
http://httpd.apache.org/dev/debugging.html

Note you probably want to unpack

http://archive.apache.org/dist/httpd/binaries/win32/symbols/apache_2.2.4-win32-x86-no_ssl-symbols.zip
(or
http://archive.apache.org/dist/httpd/binaries/win32/symbols/apache_2.2.4-win32-x86-openssl-0.9.8d-symbols.zip
if you had installed the ssl version)

directly into your apache 2.2 tree.  I don't know of availability of the
ActiveState symbols, nor TheoryX's, but if they exist it will make reading
that backtrace sooo much clearer.

Bill

Re: Best version of Apache for Win32 deployment

[William A. Rowe, Jr.]

Octavian Rasnita wrote:
> 
> Well, I've uninstalled VS6 and VS.net, but this message still appears,
> so I have no where to go in Tools/Options/...

You didn't bother to finish reading;

>> http://httpd.apache.org/dev/debugging.html

Which tells you how to enable/override drwtsn32 as your default error handler
(-i flag I think, offhand).