Re: svn commit: r1234169 - in /httpd/mod_fcgid/trunk/modules/fcgid:
Bill,
In PR 50309, the submitted patch moved the apr_pool_cleanup_register() call
from procmgr_child_init to the tail end of procmgr_post_config in
fcgid_pm_win.c prior to returning APR_SUCCESS. You have simply removed it from
procmgr_child_init in r1234169.
https://issues.apache.org/bugzilla/attachment.cgi?id=27982action=diff
I am a little worried that without registering a cleanup somewhere (where the
patch proposes), there will be none. This patch has now been in use by Mario,
Steffen of Apachelounge and myself now for well over a year, and we know it
works as it was posted.
However, I will respect your knowledge if you say it is not needed. I just want
to make sure it was not missed.
Regards,
Gregg
Modified: httpd/mod_fcgid/trunk/modules/fcgid/fcgid_pm_win.c
URL:
http://svn.apache.org/viewvc/httpd/mod_fcgid/trunk/modules/fcgid/fcgid_pm_win.c?r
\
ev=1234169r1=1234168r2=1234169view=diff \
== \
--- httpd/mod_fcgid/trunk/modules/fcgid/fcgid_pm_win.c (original)
+++ httpd/mod_fcgid/trunk/modules/fcgid/fcgid_pm_win.c Fri Jan 20 22:02:50 2012
@@ -248,8 +248,8 @@ apr_status_t procmgr_peek_cmd(fcgid_comm
apr_status_t
procmgr_child_init(server_rec * main_server, apr_pool_t * pchild)
{
-apr_pool_cleanup_register(pchild, main_server,
- procmgr_stop_procmgr, apr_pool_cleanup_null);
+/* Noop on windows, but used by unix */
+
return APR_SUCCESS;
}
Re: STATUS file and BUGZ
On 1/20/2012 10:36 AM, William A. Rowe Jr. wrote: On 1/20/2012 7:07 AM, Jim Jagielski wrote: Just a friendly reminder... If reports have been submitted to BUGZ, could you list them in this thread please? https://issues.apache.org/bugzilla/show_bug.cgi?id=52476 Suspects identified, proceeding to judgement and execution when I wrap up my work-work today. Our other Windows bug is the balancer/shm and it is also in bugz https://issues.apache.org/bugzilla/show_bug.cgi?id=52402
Re: [VOTE] Release Apache httpd 2.4.0
On 1/20/2012 10:40 AM, William A. Rowe Jr. wrote: On 1/20/2012 7:01 AM, Jim Jagielski wrote: I will note, for the record, that despite my request, it does not look as if anyone has added the Windows issue(s) as either showstoppers in STATUS or created a BUGZ issue to enable us to track it. Apologies if this *was* done and I simply missed it. You simply missed it and apology accepted. I hope to spend time this weekend on the win32 build. I would like very much to dump .dsp/.dsw prior to your tag. That means some sort of .mak (simplified from the dsp output, I hope!) and certainly sln/vcproj files that are modestly portable across several more recent visual studio versions. Also expecting 2.3.7 mod_fcgid should be ready to tag by Monday. Would be great if they worked together :) Slow down please. -0.5 Which sln/vsproj? VC10? I think dsw/dsp should stay. They are compatible with VC6-9, so they cover many version , unlike VC10 that works only with VC10. Granted one could call VC6 7 surely dead though I still use VC6 for quick builds on occasion cause it compiles quickly (60-80 seconds) and needs no redist. I beg you to keep the dsw/dsp and just add in VC10 sln/vcproj. That covers everyone. A simple del /s *.sln *.vcp* will remove those VC10 files for those of us not ready to move to VC10 (till such time as php moves there).
Re: [VOTE] Release Apache httpd 2.4.0
On 1/20/2012 10:40 AM, William A. Rowe Jr. wrote: On 1/20/2012 7:01 AM, Jim Jagielski wrote: I will note, for the record, that despite my request, it does not look as if anyone has added the Windows issue(s) as either showstoppers in STATUS or created a BUGZ issue to enable us to track it. Apologies if this *was* done and I simply missed it. You simply missed it and apology accepted. I hope to spend time this weekend on the win32 build. I would like very much to dump .dsp/.dsw prior to your tag. That means some sort of .mak (simplified from the dsp output, I hope!) and certainly sln/vcproj files that are modestly portable across several more recent visual studio versions. Also expecting 2.3.7 mod_fcgid should be ready to tag by Monday. Would be great if they worked together :) Slow down please. -0.5 Which sln/vsproj? VC10? I think dsw/dsp should stay. They are compatible with VC6-9, so they cover many version , unlike VC10 that works only with VC10. Granted one could call VC6 7 surely dead though I still use VC6 for quick builds on occasion cause it compiles quickly (60-80 seconds) and needs no redist. I beg you to keep the dsw/dsp and just add in VC10 sln/vcproj. That covers everyone. a simple del /s *.sln *.vcp* will remove those VC10 files for those of us not ready to move to VC10 (till such time as php moves there). Thanks
Discuss: Dropping dsw/dsp files
On 1/20/2012 11:30 AM, William A. Rowe Jr. wrote: On 1/20/2012 1:03 PM, Gregg L. Smith wrote: On 1/20/2012 10:40 AM, William A. Rowe Jr. wrote: I hope to spend time this weekend on the win32 build. I would like very much to dump .dsp/.dsw prior to your tag. That means some sort of .mak (simplified from the dsp output, I hope!) and certainly sln/vcproj files that are modestly portable across several more recent visual studio versions. Also expecting 2.3.7 mod_fcgid should be ready to tag by Monday. Would be great if they worked together :) Slow down please. -0.5 Well - I'll commit something concrete to trunk and let people debate. Which sln/vsproj? VC10? I think dsw/dsp should stay. They are compatible with VC6-9, so they cover many version , unlike VC10 that works only with VC10. Right. Very foolish. Need studio 7+ compatible flavors. Morons. No fear; I was going to cover all GUI's not EOL'ed yet, at least. Granted one could call VC6 7 surely dead though I still use VC6 for quick builds on occasion cause it compiles quickly (60-80 seconds) and needs no redist. It makes no sense for the next version major. But the .mak files will build under VC6 + SDK, or DDK + SDK + mladen hacks, or whatever. There's nothing special dsp gives anyone anymore, except the export ability we will replace. You will still be able to compile. Would urge you to look at mladen's hacks if you want a modern compile plus classic msvcrt. I respectfully disagree, Due to the fact that right now, you have to convert to VC9 first, then convert to VC10, I have some insight here that I am sure you do as well. If you have done this, you may remember how long that last conversion takes to accomplish. I can convert in VC9 from dsw/dsp in under a minute. The last time I tried converting VC9 to VC10 it took a long, long time. Minutes, many minutes. I would have to assume converting up from VC7 would be same on VC9 as converting 9 to 10. Even if not, from 7 to 10 would again, be a slow process. This was my technical reason behind my request to keep the dsw/dsp files while also supplying VC10 sln/vcproj as well. This way, all are covered, and no one has to wait a long time for the conversion. Sure, many are EOL but none the less still in use. I beg you to keep the dsw/dsp and just add in VC10 sln/vcproj. That covers everyone. A simple del /s *.sln *.vcp* will remove those VC10 files for those of us not ready to move to VC10 (till such time as php moves there). We only lose the antique GUI. Nothing more. and time as stated above
Re: Discuss: Dropping dsw/dsp files
On 1/20/2012 12:14 PM, William A. Rowe Jr. wrote: On 1/20/2012 2:06 PM, Gregg L. Smith wrote: Due to the fact that right now, you have to convert to VC9 first, then convert to VC10, I have some insight here that I am sure you do as well. Good point... If you have done this, you may remember how long that last conversion takes to accomplish. I can convert in VC9 from dsw/dsp in under a minute. The last time I tried converting VC9 to VC10 it took a long, long time. Minutes, many minutes. I would have to assume converting up from VC7 would be same on VC9 as converting 9 to 10. Even if not, from 7 to 10 would again, be a slow process. That is troublesome. However, it only affects GUI interaction? It should not impact .mak based builds. True, but there are reasons I prefer the GUI, biggest is where one runs into trouble during a compile. I can rebuild any specific problem project/s, remove buildbin dependency from the installbin project, and when I have hammered out the specific problems, use said installbin to just copy the files into place. Good example is recent APR-Util 1.4.1 and the static lib not compiling w/ crypto. I was able to compile all but the few things linked to the static lib, remove the crypto switch in apu.hw, then built the static lib and the things like ab and abs that linked to it, none needed apr_crypto anyway. Not such an easy task to do via makefile. New people to the game also prefer the GUI, after all, why do we have Windows (ok, KDE. XServer, Gnome, same in the *nix world these days)? This was my technical reason behind my request to keep the dsw/dsp files while also supplying VC10 sln/vcproj as well. This way, all are covered, and no one has to wait a long time for the conversion. Sure, many are EOL but none the less still in use. Will consider this. Or provide a much more efficient transition. Thanks, I see Steffen has spoken up on this on the other thread as well. Regards, Gregg
Re: SSL and windows with AcceptFilter https none
On 1/17/2012 11:25 AM, Steffen wrote: It is line with our reports. Thanks, and this confirms again there is some broken serious. For me a showstopper 2.4, tons of win users going to deal with this. Work around is to use 2.2.21 SSL-only and minimal config in front of 2.4. Another possible workaround. Not to set the AcceptFilter to none for https and reduce the |MaxConnectionsPerChild so the server respawns new child processes more often. This should have the same effect (if you can get the number right) to scheduling a graceful restart every N minutes/hours|. I had done the latter (scheduling graceful restarts) to keep Apache answering when the AcceptFilter for both http https were broken since I would get the AcceptEx errors and eventually server would not respond. I second the Thanks to Daniel for taking the time to test this and give his opinion on the matter. Regards, Gregg Op 17 jan. 2012 om 15:37 heeft Daniel Ruggeridrugg...@primary.net het volgende geschreven: All; I have submitted PR 52476 to track and document this bug. I've uploaded the logs from my tests where I was able to duplicate the problem. http://people.apache.org/~druggeri/logs/WinSSL/ Initially I was just setting up my testbed and hitting 127.0.0.1 to make sure the small LWP script can duplicate the problem and help track it down... it was trival to reproduce the bug on this Winsows 7 x64 installation. Since I was able to reproduce quickly, I never got past testing on local IP's, though this should suffice since it's technically running through the TCP stack just as well. I was able to reproduce inconsistently in Firefox 8.0.1 and IE 8 after enabling AcceptFilter https none. I was able to consistently reproduce the error with openssl-based clients (LWP and openssl s_client). The common error across all clients is a complaint with the ClientHello message. I was not able to find a failure where partial content was served - it was all or nothing for me at an SSL connection level. I don't have the expertise to dig into this one, but since several folks have been unable to reproduce the problem, I'll be happy to serve as a testing ground. -- Daniel Ruggeri
Re: security patches and releases (was [VOTE] Release Apache httpd 2.4.0)
On 1/17/2012 11:56 AM, Eric Covener wrote: I'd suggest that patches/apply_to_x.y.z/ is a clumsy notation. It seems more efficient to set these up as patches/CVE--/ with individual files for actively (or semi-actively) maintained versions. If there is one patch which applies to 2.2.n 2.2.17, and a second patch for 2.2.17 and higher, it would be easier to differentiate these all within one directory. The current scheme has one benefit in that a responsible user on the latest release has a one-stop shop for What do I need to add?. With the CVE as the directory, they'd have to start with some other resource/hint or browse through the descriptions/patches 2 cents. I like the current way as well, know right where to look, do not have read something first then dig through a bunch of CVE numbers. Somewhat dyslexic people would be better served by the apply to vs. CVEs IMHO.
Re: documenting -deps
On 1/17/2012 12:15 PM, William A. Rowe Jr. wrote: On 1/17/2012 2:07 PM, Eric Covener wrote: * Are we committed to providing the -deps for 2.4's lifetime, or would we doc it with some weasel language? I'm +1 for dropping -deps, but you knew that ;-) * Does anyone care if we're not committed to it and just change the doc when we change our mind and stop providing a deps tarball? No... we need some doc to help users. Looking at the users@ list has been instructive. I really think we need 2.4.0-beta to iron out how hard it is now for users to adopt this package, and what we have to document in order to remedy that complexity 2 cents Why not just do it how it has always been done, that is to include the latest release of APR/APU(/APR-I on Win) for the httpd release? It seems to me if I recall this correctly, that the reason there was a separate -deps package was because APR 1.4 was not released, therefore could not be bundled yet was required for 2.3.x at the time of release. I know PCRE was axed and the reason is sound. APR however, is part of ASF and maintained by most of you anyway. The preferred needed APR APU are all in a released state, what's the problem bundling again? Regards, Gregg
Re: Looking for Windows testers for r1225199
On 1/13/2012 11:30 AM, Gregg L. Smith wrote: On 12/28/2011 6:57 AM, Stefan Fritsch wrote: Hi, Author: sf Date: Wed Dec 28 14:54:49 2011 New Revision: 1225199 URL: http://svn.apache.org/viewvc?rev=1225199view=rev Log: Check during configtest that the directories for error logs exist Testing under Windows is welcome PR: 29941 I think that the combination of ap_server_root_relative and ap_make_dirstr_parent should also work under Windows with backslashes as path separators. But it would be nice if somebody could test that before I backport to 2.4. Cheers, Stefan Stefan, Build at r1226558, post both these revisions. Missing main log directory shows up on console if started from there, or Eventlog (syslog) if started as service c:\Apache24\binhttpd (OS 2)The system cannot find the file specified. : AH02291: Cannot access directory 'c:/Apache24/lo gs/' for main error log AH00014: Configuration check failed vhost specific, shows in error log CustomLog \\some\\bogus\\path\\access.log common [Fri Jan 13 11:20:30.038382 2012] [log_config:error] [pid 420:tid 636] (OS 3)The system cannot find the path specified. : AH00649: could not open transfer log file c:/some/bogus/path/access.log. AH00015: Unable to open logs Looks fine! In the spirit of PR 229941 and for the vhost specific part, no it's not fine. It does not show to console and Apache does not just ignore that vhost and move on, it stops, so you need to dig into the logs. Being an enhancement PR no foul.
Re: Looking for Windows testers for r1225199
On 12/28/2011 6:57 AM, Stefan Fritsch wrote: Hi, Author: sf Date: Wed Dec 28 14:54:49 2011 New Revision: 1225199 URL: http://svn.apache.org/viewvc?rev=1225199view=rev Log: Check during configtest that the directories for error logs exist Testing under Windows is welcome PR: 29941 I think that the combination of ap_server_root_relative and ap_make_dirstr_parent should also work under Windows with backslashes as path separators. But it would be nice if somebody could test that before I backport to 2.4. Cheers, Stefan Stefan, Build at r1226558, post both these revisions. Missing main log directory shows up on console if started from there, or Eventlog (syslog) if started as service c:\Apache24\binhttpd (OS 2)The system cannot find the file specified. : AH02291: Cannot access directory 'c:/Apache24/lo gs/' for main error log AH00014: Configuration check failed vhost specific, shows in error log CustomLog \\some\\bogus\\path\\access.log common [Fri Jan 13 11:20:30.038382 2012] [log_config:error] [pid 420:tid 636] (OS 3)The system cannot find the path specified. : AH00649: could not open transfer log file c:/some/bogus/path/access.log. AH00015: Unable to open logs Looks fine! Cheers, Gregg
Re: Time for 2.4.0 GA??
On 1/12/2012 10:11 AM, Rainer Jung wrote: On 12.01.2012 11:24, Steffen wrote: We have at least 4 hard bugs in 2.3.16. Known for a long time, and no need to exposure more for these. Fine a GA, with a big note that it is not ready for Windows and advising to run 2.2.21 as proven stable. So not happy with 2.4. Understood, but we repeatedly asked whether you are anyone who can reproduce the problem could please provide an ErrorLog on LogLevel trace8 for one broken and one good request. We didn't get an answer to that. Can you provide it? Note that neither Bill nor me were able to reproduce on our local Windows systems. So we need some help to hunt the bug. Regards, Rainer Yes, and I currently have my logging of mod_ssl and the mpm at trace, unfortunately, I have not been lucky to see a failure (partial/blank screen) while trace logging is on, odd, but bad luck. It's not that I have not tried. I am seeing this though; [Thu Jan 05 14:59:55.161420 2012] [ssl:info] [pid 1232:tid 856] [client 192.168.1.1:62717] AH01964: Connection to child 57 established (server www.somedomain.tld:443) [Thu Jan 05 14:59:55.161420 2012] [ssl:trace3] [pid 1232:tid 844] ssl_engine_kernel.c(1840): [client 192.168.1.1:62716] OpenSSL: Loop: before/accept initialization [Thu Jan 05 14:59:55.161420 2012] [ssl:trace2] [pid 1232:tid 856] ssl_engine_rand.c(123): Seeding PRNG with 144 bytes of entropy [Thu Jan 05 14:59:55.161420 2012] [ssl:trace4] [pid 1232:tid 844] ssl_engine_io.c(2000): [client 192.168.1.1:62716] OpenSSL: I/O error, 11 bytes expected to read on BIO#12e0ef0 [mem: 27eb6a8] [Thu Jan 05 14:59:55.161420 2012] [ssl:trace3] [pid 1232:tid 844] ssl_engine_kernel.c(1869): [client 192.168.1.1:62716] OpenSSL: Exit: error in SSLv2/v3 read client hello A [Thu Jan 05 14:59:55.161420 2012] [ssl:trace4] [pid 1232:tid 844] ssl_engine_io.c(2000): [client 192.168.1.1:62716] OpenSSL: I/O error, 11 bytes expected to read on BIO#12e0ef0 [mem: 27eb6a8] [Thu Jan 05 14:59:55.161420 2012] [ssl:trace3] [pid 1232:tid 856] ssl_engine_kernel.c(1832): [client 192.168.1.1:62717] OpenSSL: Handshake: start [Thu Jan 05 14:59:55.161420 2012] [ssl:trace3] [pid 1232:tid 844] ssl_engine_kernel.c(1869): [client 192.168.1.1:62716] OpenSSL: Exit: error in SSLv2/v3 read client hello A [Thu Jan 05 14:59:55.161420 2012] [ssl:trace3] [pid 1232:tid 856] ssl_engine_kernel.c(1840): [client 192.168.1.1:62717] OpenSSL: Loop: before/accept initialization [Thu Jan 05 14:59:55.161420 2012] [ssl:trace4] [pid 1232:tid 856] ssl_engine_io.c(2000): [client 192.168.1.1:62717] OpenSSL: I/O error, 11 bytes expected to read on BIO#142eae0 [mem: 27f9158] [Thu Jan 05 14:59:55.161420 2012] [ssl:trace3] [pid 1232:tid 856] ssl_engine_kernel.c(1869): [client 192.168.1.1:62717] OpenSSL: Exit: error in SSLv2/v3 read client hello A [Thu Jan 05 14:59:55.161420 2012] [ssl:trace4] [pid 1232:tid 856] ssl_engine_io.c(2000): [client 192.168.1.1:62717] OpenSSL: I/O error, 11 bytes expected to read on BIO#142eae0 [mem: 27f9158] [Thu Jan 05 14:59:55.161420 2012] [ssl:trace3] [pid 1232:tid 856] ssl_engine_kernel.c(1869): [client 192.168.1.1:62717] OpenSSL: Exit: error in SSLv2/v3 read client hello A [Thu Jan 05 14:59:55.208311 2012] [ssl:trace4] [pid 1232:tid 848] ssl_engine_io.c(1989): [client 192.168.1.1:62713] OpenSSL: read 5/5 bytes from BIO#12c87f0 [mem: 133f643] (BIO dump follows) [Thu Jan 05 14:59:55.208311 2012] [ssl:trace7] [pid 1232:tid 848] ssl_engine_io.c(1922): +-+ I'll hammer on it as time permits the next couple of days. I'm using a real cert, not self-signed. I'm +1 for 2.4.0, as to GA or beta can be decided then. Regard, Gregg
Re: Time for 2.4.0 GA??
On 1/11/2012 5:52 PM, Daniel Ruggeri wrote: On 1/11/2012 6:26 PM, Noel Butler wrote: Also, in relation to the windows stuff, I think Jim's suggestion is most appropriate in the absence of more windows users to test. If all we need is testing and some logging, I'd be happy to assist. If someone can provide the compiled build and any non-standard config directives with an overview of how to duplicate, I have Win7, Server 2003 and Server 2008 I can test with. I fall a bit short in how much volume I could throw at an installation, though Hi Daniel, Either apachehaus.com or apachelounge.com have 2.3.16 binaries available for Windows. The problem is with the directive; AcceptFilter httpd none That is the only non-stardard config option. Cheers, Gregg
Re: Time for 2.4.0 GA??
On 1/12/2012 5:29 PM, Daniel Ruggeri wrote: On 1/12/2012 5:50 PM, Gregg L. Smith wrote: Either apachehaus.com or apachelounge.com have 2.3.16 binaries available for Windows. The problem is with the directive; AcceptFilter httpd none That is the only non-stardard config option. Greg; Thanks for the overview - if I understand correctly this seems to manifest with socket reuse and incomplete or empty responses - correct? And that this is a matter of recycling existing listening sockets rather than anything keepalive-related. If so, I'm guessing a simple perl LWP script to make request after request for a known-size resource (and verifying the size returned) would do. Any other pointers or things to look for? I seem to recall SSL being brought up, or is that a separate issue? Hi Daniel, I typo'd that again. I am bad at that, I should just copy and paste from my config. AcceptFilter https none SSL has everything to do with it. It is just in SSL with AcceptFilter for that protocol set to none I find with trace logging on it doesn't want to manifest itself. When I turn off the trace logging, it happens often. It's odd, I do not get it. Yes, incomplete or empty responses. The empty ones are easy to spot. Just an image here or there is a possible incomplete. It may be keepalive. On some windows flavors, we do not have a huge pool of connections and can be DOSed rather easy. I have seen some errors while trace logging was on, that may be suggesting that. Looking, Keepalive is high, at 30, the default has been whittled down since I configured the server the 1st time (and have kept these config files) . Timeout is at 60. Even at 60, I have seen this; [Thu Jan 12 15:38:31.812658 2012] [ssl:info] [pid 3504:tid 720] (OS 10060)A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond. : [client 192.168.1.1:51417] AH01991: SSL input filter read failed. However, I can say this does not happen to just me, Steffen has seen same behavior. It seems to happen more pronounced on my SNI hosts that the default SSL host. So maybe it is an artifact of SNI. A lot of possibilities I just cannot quite pin down. II do not really have much problems with *not* setting AcceptFilter to none on https, not like I have on standard http where it has to be set to none or the server just stops responding after some time.
Re: 2.4.0 GA This week?
0On 1/2/2012 3:06 PM, William A. Rowe Jr. wrote: On Sunday 01/01/2012 at 19:03, Mario Brandt wrote: The loadbalancer still crashes on windows. See https://issues.apache.org/bugzilla/show_bug.cgi?id=52402 We should try to get at least the rewrite/proxy issue resolved, first. About the Windows-onlly issues... Well, if there are not sufficient developers who have time and inclination to look into those, I would rather release 2.4.0 as GA on unix, beta on Windows, than delay it indefinitely. When we tag and roll 2.4.0, if it isn't up to snuff, it won't pass the vote for GA, but perhaps it will pass the vote for beta (or alpha). I'm not sure where the impetus came from to change the way the HTTP Project operates at this particular point in time. It certainly hasn't been discussed much on this list, or put up for a vote. The methodology for handling releases was all hashed out a number of years ago and was assembled from consensus. Has that consensus changed? I all for stop any and all API changes other than anything that may require fixing these. I am all for RCs if it means changing the -dev is to -rc# I'm sorry I signed off before I realized SSL with AcceptFilter httpd none was still a problem on Windoze. Yes, Mario's mod_proxy_balancer/slotmem shm errors I am also still getting/ Mario, I know you read this list ... chime in your PR# and any other possitivle showstopper that may be on any platform other than building ... not that I count :) Other than these few ... bummers ... guys ... this is one of the best servers I have seen. Cheets Gregg
Re: 2.4.0 GA This week?
Honesty, never tries with these on ... especially sendfile ... slows us wintards outbound down bigtime. On 1/2/2012 3:08 PM, William A. Rowe Jr. wrote: On 1/1/2012 12:30 PM, Steffen wrote: Also IMHO blocking GA: - SSL on windows not usable - Hanging logging workers Does disabling the EnableSendfile/EnableMMAP directives alter either of these cases? It really appears that socket reuse is to blame here. We know there are plenty of windows socket stack drivers who barf on disconnecting and recycling sockets through transmitfile.
Re: remove mod_heart* from 2.4?(was: 2.4.0 GA This week?)
Since I have been the most vocal about this watchdog/hearmonitor/heartbeats on windows ... I should chime in. I can tell someone what each do (as far as I have seen). There are, minimal docvs on all but watchdog (which is required for a couple) ... but ... look at my emails in the past ... am hardly the one to write docs :) G On 1/2/2012 10:12 PM, Sander Temme wrote: On Jan 2, 2012, at 8:09 PM, Eric Covener wrote: I will crank out docs for these tomorrow and ping paul to review. Thank you for getting this going: it seems to be the most constructive way to resolve this issue. S.
Re: 2.4.0 GA This week?
My vote ... Stefan, wherever it fits (depends on whom I speak to) , these are showstoppers. But, it can be said these are one OS specific ... which usually does not stop the press AFAIK. I can say however .. as a small time distributor ... this will be noted as the problems yet remaining on this one platform (windows) ... and if these few problems do not affect any of my distributees ... then they should move on to 2.4. Regards, Gregg On 1/2/2012 10:50 PM, Stefan Fritsch wrote: On Tuesday 03 January 2012, William A. Rowe Jr. wrote: On 1/2/2012 4:10 PM, Stefan Fritsch wrote: On Sunday 01 January 2012, Steffen wrote: Also IMHO blocking GA: - SSL on windows not usable - Hanging logging workers - Rewrite P On Sunday 01/01/2012 at 19:03, Mario Brandt wrote: The loadbalancer still crashes on windows. See https://issues.apache.org/bugzilla/show_bug.cgi?id=52402 We should try to get at least the rewrite/proxy issue resolved, first. About the Windows-onlly issues... Well, if there are not sufficient developers who have time and inclination to look into those, I would rather release 2.4.0 as GA on unix, beta on Windows, than delay it indefinitely. When we tag and roll 2.4.0, if it isn't up to snuff, it won't pass the vote for GA, but perhaps it will pass the vote for beta (or alpha). I'm not sure where the impetus came from to change the way the HTTP Project operates at this particular point in time. It certainly hasn't been discussed much on this list, or put up for a vote. The methodology for handling releases was all hashed out a number of years ago and was assembled from consensus. Has that consensus changed? No. The status of 2.4.0 will be determined by vote. I was just pointing out how I intend to vote in the face of the Windows issues and am lobbying for other people to consider this as a valid option, too.
Re: Win 2.3.16 :: SSL and AcceptFilter
On 12/27/2011 10:40 AM, Steffen wrote: Gregg reported it also: I've also found AcceptFilter https none to be problematic. First time you hit a site via https it usually comes up with a blank white nothing. Hitting reload and it comes up proper. That I did, fishing to see if others were seeing the same thing. It looks like they are. -Original Message- From: Steffen Sent: Tuesday, December 27, 2011 7:21 PM To: dev@httpd.apache.org Subject: Re: Win 2.3.16 :: SSL and AcceptFilter Hard to catch, but I was lucky. These are the steps with loglevel info: Start httpd.exe with AcceptFilter https none 1) In browser https://devxp 2) response browser not found in access log: nothing in error log: [ssl:info] [pid 2432:tid 1036] [client 192.168.1.13:2136] AH01964: Connection to child 63 established (server devxp:443) [ssl:info] [pid 2432:tid 1036] [client 192.168.1.13:2137] AH01964: Connection to child 63 established (server devxp:443) [ssl:info] [pid 2432:tid 1036] [client 192.168.1.13:2137] AH02008: SSL library error 1 in handshake (server devxp:443) [ssl:info] [pid 2432:tid 1036] SSL Library Error: error:140760FC:SSL routines:SSL23_GET_CLIENT_HELLO:unknown protocol -- speaking not SSL to HTTPS port!? [ssl:info] [pid 2432:tid 1036] [client 192.168.1.13:2137] AH01998: Connection closed to child 63 with abortive shutdown (server devxp:443) 3) In browser press refresh 4)Response is fine in accesslog: SSLv3 RC4-SHA GET / HTTP/1.1 200 46 - Mozilla/4.0 (compatible; MSIE 6.0;... in error log: [ssl:info] [pid 2432:tid 1036] [client 192.168.1.13:2138] AH01964: Connection to child 63 established (server devxp:443) [ssl:info] [pid 2432:tid 1036] (70014)End of file found: [client 192.168.1.13:2138] AH01991: SSL input filter read failed. [ssl:info] [pid 2432:tid 1036] [client 192.168.1.13:2139] AH01964: Connection to child 63 established (server devxp:443) [ssl:info] [pid 2432:tid 1036] (OS 10060)A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond. : [client 192.168.1.13:2139] AH01991: SSL input filter read failed. -Original Message- From: William A. Rowe Jr. Sent: Tuesday, December 27, 2011 5:42 PM To: dev@httpd.apache.org Subject: Re: Win 2.3.16 :: SSL and AcceptFilter On 12/27/2011 9:46 AM, Steffen wrote: Reported here already the issue. Also in the AL forum is one with the same issue. Still there definitly is an issue with Acceptfilter and SSL. When AcceptFilter https none: Sometimes page is not displayed, eg. in Chrome with errors Error 107 (net::ERR_SSL_PROTOCOL_ERROR): SSL protocol error. or Error 15 (net::ERR_SOCKET_NOT_CONNECTED): Unknown error. Nothing in the logs. --- almost always means you want to change LogLevel to debug --- (or maybe even info level will be sufficient). With the new methodology, you can toggle the mpm alone to debug level. Something like; LogLevel info ssl_module:debug mpm_winnt_module:debug
Re: Windows Laundry List pt3, mod_watchdog
On 12/5/2011 12:25 AM, Mladen Turk wrote: On 12/05/2011 08:41 AM, William A. Rowe Jr. wrote: On 12/5/2011 1:22 AM, Mladen Turk wrote: Like said on another thread, give me couple of days and I'll fix the issue. Well, as soon as I compile httpd-2.4 on windows which might be tricky cause build procedure is completely broken and it doesn't compile any more out of the box. It has been building for Gregg and I (at least somewhat recently) so please be specific? If this is your interesting psdk logic, that might be a contributing factor. Nope. Its VS2008 Put pcre, branches/apr-1.4.x, branches/apr-util-1.4.x, apr-iconv/trunk inside srclib Disabled deflate, ssl, lua, etc... Each project/module reports Microsoft (R) Windows (R) Resource Compiler Version 6.0.5724.0 Copyright (C) Microsoft Corporation. All rights reserved. fatal error RC1107: invalid usage; use RC /? for Help Project : error PRJ0002 : Error result 1 returned from 'C:\Program Files\Microsoft SDKs\Windows\v6.0A\bin\rc.exe'. Something that could probably be mentioned in compiling docs (if we have any) perl srclib/apr/build/cvtdsp.pl -2005 before converting the VC6 projects files Regards
Re: Windows Laundry List pt3, mod_watchdog
On 12/5/2011 5:15 AM, Mladen Turk wrote: Fixed in the trunk and 2.4.x Willing to retest? Regards I see the change which was what I had suggested in the beginning, granted I did not have a real good technical reason other than it then works :) I have not built trunk recently but making the exact modification to my 2.4 and yes, it is fixed, does not crash and the module works as it should. Please backport to 2.4. Thanks Mladen! I now revert my vote to drop this and heartbeat/heartmonitor modules from 2.4 on Windows. Regards, Gregg
Re: Are we there yet?
On 12/4/2011 1:02 AM, Stefan Fritsch wrote: On Saturday 03 December 2011, William A. Rowe Jr. wrote: On 12/3/2011 1:32 AM, Gregg L. Smith wrote: On 12/2/2011 3:48 PM, Stefan Fritsch wrote: - the follwing modules added since 2.2 lack documentation - mod_socache_dbm - mod_socache_memcache - mod_socache_shmcb These are required for SSL AFIAK, they must stay! Mentioned in the mod_ssl docks should be sufficient IMHO. It isn't. Someone trimming their LoadModule lines will undoubtedly hit the wall trying to figure out why they couldn't just switch from memcache or dbm back to shmcb. Someone else will break there server simply removing unfamiliar modules from the list, particularly one which appears nowhere in the ASF HTTP Server module documents lists. This, and the mod_slotmem_* objects, really make lousy modules. Isn't the answer to this that all consumers of slotmem and socache should simply point to the mod_slotmem_*/mod_socache_* modules in the error message if the configured provider is not found? Then the user would immediately know that another module is required. +1, great idea
Re: Are we there yet?
On 12/3/2011 2:28 PM, William A. Rowe Jr. wrote: On 12/3/2011 1:32 AM, Gregg L. Smith wrote: On 12/2/2011 3:48 PM, Stefan Fritsch wrote: - the follwing modules added since 2.2 lack documentation - mod_socache_dbm - mod_socache_memcache - mod_socache_shmcb These are required for SSL AFIAK, they must stay! Mentioned in the mod_ssl docks should be sufficient IMHO. It isn't. Someone trimming their LoadModule lines will undoubtedly hit the wall trying to figure out why they couldn't just switch from memcache or dbm back to shmcb. Someone else will break there server simply removing unfamiliar modules from the list, particularly one which appears nowhere in the ASF HTTP Server module documents lists. Which is why I said mention them in the mod_ssl docs Say under the SSLSessionCache Directive For dbm, add a note that mod_socache_dbm is required. for .. well ... I see shm .. assuming shmdb tho I use and have configured as shmdb, that mod_socache_shmdb is required .. etc. I see nothing for memcache .. so looks like this needs some updating before GA However I am looking at the trunk docs ... since 2.4 is not online yet .. in the URL I assume they will be eventually be Cheers, Gregg
Re: Are we there yet?
On 12/3/2011 7:54 PM, Gregg L. Smith wrote: On 12/3/2011 2:28 PM, William A. Rowe Jr. wrote: On 12/3/2011 1:32 AM, Gregg L. Smith wrote: On 12/2/2011 3:48 PM, Stefan Fritsch wrote: - the follwing modules added since 2.2 lack documentation - mod_socache_dbm - mod_socache_memcache - mod_socache_shmcb These are required for SSL AFIAK, they must stay! Mentioned in the mod_ssl docks should be sufficient IMHO. It isn't. Someone trimming their LoadModule lines will undoubtedly hit the wall trying to figure out why they couldn't just switch from memcache or dbm back to shmcb. Someone else will break there server simply removing unfamiliar modules from the list, particularly one which appears nowhere in the ASF HTTP Server module documents lists. Which is why I said mention them in the mod_ssl docs Say under the SSLSessionCache Directive For dbm, add a note that mod_socache_dbm is required. for .. well ... I see shm .. assuming shmdb tho I use and have configured as shmdb, that mod_socache_shmdb is required .. etc. I see nothing for memcache .. so looks like this needs some updating before GA What seems to have not made it in there .. I am not against adding them to mod_ssl, since I see no other use for these specific modules. I like that stuff has been ripped out of core and modularized , that is, what I believe, makes the 2.4 footprint so small, load what you need and nothing more. Cheers, Gregg
Re: Are we there yet?
On 12/2/2011 3:48 PM, Stefan Fritsch wrote: - modules docs - the follwing modules added since 2.2 lack documentation - mod_watchdog - mod_heartbeat - mod_heartmonitor - mod_lbmethod_heartbeat I vote these off the Windows boat, mod_watchdog crashes the child processes on Win and is basically required for the rest of them, in a round about way. I even asked Steffen at Apache Lounge to check it for me. I have more detail, but I have spoken up about it long ago and I have seen no movement from original author. However, if someone wants to know, feel free to ask. - mod_socache_dbm - mod_socache_memcache - mod_socache_shmcb These are required for SSL AFIAK, they must stay! Mentioned in the mod_ssl docks should be sufficient IMHO. Cheers, Gregg
RE: svn commit: r1203859 [2/2] - in /httpd/httpd/trunk/modules/proxy: mod_proxy.c ...
Modified: httpd/httpd/trunk/modules/proxy/mod_proxy_scgi.c
URL:
http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/proxy/mod_proxy_scgi.c?rev=1203859r1=1203858r2=1203859view=diff
==
--- httpd/httpd/trunk/modules/proxy/mod_proxy_scgi.c (original)
+++ httpd/httpd/trunk/modules/proxy/mod_proxy_scgi.c Fri Nov 18 21:41:09 2011
@@ -511,12 +506,12 @@ static int scgi_handler(request_rec *r,
if (strncasecmp(url, SCHEME ://, sizeof(SCHEME) + 2)) {
ap_log_rerror(APLOG_MARK, APLOG_DEBUG, 0, r,
- proxy: PROXY_FUNCTION : declining URL %s, url);
+ declining URL %s, url);
return DECLINED;
}
/* Create space for state information */
-status = ap_proxy_acquire_connection(PROXY_FUNCTION,backend, worker,
+status = ap_proxy_acquire_connection(__FUNCTION__,backend, worker,
r-server);
if (status != OK) {
goto cleanup;
@@ -532,10 +527,10 @@ static int scgi_handler(request_rec *r,
}
/* Step Two: Make the Connection */
-if (ap_proxy_connect_backend(PROXY_FUNCTION, backend, worker, r-server)) {
-ap_log_error(APLOG_MARK, APLOG_ERR, 0, r-server,
- proxy: PROXY_FUNCTION : failed to make connection
- to backend: %s:%u, backend-hostname, backend-port);
+if (ap_proxy_connect_backend(__FUNCTION__, backend, worker, r-server)) {
+ap_log_rerror(APLOG_MARK, APLOG_ERR, 0, r,
+ failed to make connection to backend: %s:%u,
+ backend-hostname, backend-port);
status = HTTP_SERVICE_UNAVAILABLE;
goto cleanup;
}
@@ -551,7 +546,7 @@ static int scgi_handler(request_rec *r,
cleanup:
if (backend) {
backend-close = 1; /* always close the socket */
-ap_proxy_release_connection(PROXY_FUNCTION, backend, r-server);
+ap_proxy_release_connection(__FUNCTION__, backend, r-server);
}
return status;
}
While googling why one of my compilers would error out on this, it
revealed that the __FUNCTION__ macro is C99 and not ANSI nor C89, and
for now westillwant to support C89 AFAIK. I do not remember a go-ahead
with C99 code. Did I miss that?
Cheers,
Gregg
Re: Icons for 2.4
I did this a couple weeks ago, it's close, but not perfect. Best on white/light background. On 11/27/2011 8:18 AM, Rich Bowen wrote: On Nov 27, 2011, at 10:49, Rainer Jungrainer.j...@kippdata.de wrote: On 27.11.2011 10:50, Stefan Fritsch wrote: Hi, docs/icons/apache_pb2* contain the version number (2.2), in the case of docs/icons/apache_pb2_ani.gif it's even an animation. Any volunteers for changing these to 2.4? Anyone knows the right or at least a similar font? No, but I remember that we discussed this around the 2.2 release so you might be able to find something in the archives. attachment: apache_pb24.gif
Re: Icons for 2.4
No, I looked it up after, it's one of the Swiss fonts from MS Office, couldn't grab back the mail. On 11/27/2011 4:48 PM, Rainer Jung wrote: Hi Gregg, In 28.11.2011 01:12, Gregg L. Smith wrote: I did this a couple weeks ago, it's close, but not perfect. Best on white/light background. Which font did you use for the digits? Is it a freely avaiable font? Regards, Rainer
Re: [VOTE] Release 2.3.15-beta as beta
Stefan, Which build problem? mod_lua?, I've never seen release blocked on a a alpha/beta nor do I remember screaming and blocking a release by a simple problem with a module, libhttpd is a whole different matter, as that means nothing builds, therefore nothing works. mod_watchdog still crashes the child process when it hits that code, I've never -1 it that I can remember. That reminds me, I need to rehash this with Mladen tho I still stand on my same conclusion, but I can put some reasoning behind it now other than it makes the module crash. Cheers, Gregg On 11/11/2011 1:28 PM, Stefan Fritsch wrote: On Wed, 9 Nov 2011, Jim Jagielski wrote: The 2.3.15-beta (prerelease) tarballs are available for download at test: http://httpd.apache.org/dev/dist/ I'm calling a VOTE on releasing these as 2.3.15-beta BETA and, with luck, this will be our last beta and the next release in ~2weeks or less will be 2.4.0 GA!! Vote will last the normal 72 hours... +1 for beta, tested on Debian stable, test suite passes without error. Are the build problems on Windows a blocker?
Re: [VOTE] Release 2.3.15-beta as beta
On 11/9/2011 6:24 AM, Jim Jagielski wrote: I'm calling a VOTE on releasing these as 2.3.15-beta BETA and, with luck, this will be our last beta and the next release in ~2weeks or less will be 2.4.0 GA!! Vote will last the normal 72 hours... +1 for beta
RE: svn commit: r1183475 - in /httpd/httpd/trunk: include/ap_mmn.h
Hi Stefan, I am getting type errors on these in MSVC, can we please move the * after PROXY_DECLARE_DATA? Cheers, Gregg --- httpd/httpd/trunk/modules/proxy/proxy_util.c2011/10/14 19:48:03 1183474 +++ httpd/httpd/trunk/modules/proxy/proxy_util.c2011/10/14 19:51:17 1183475 @@ -65,6 +65,8 @@ /* Global balancer counter */ int PROXY_DECLARE_DATA proxy_lb_workers = 0; static int lb_workers_limit = 0; +const apr_strmatch_pattern * PROXY_DECLARE_DATA ap_proxy_strmatch_path; +const apr_strmatch_pattern * PROXY_DECLARE_DATA ap_proxy_strmatch_domain; static int proxy_match_ipaddr(struct dirconn_entry *This, request_rec *r); static int proxy_match_domainname(struct dirconn_entry *This, request_rec *r); --- httpd/httpd/trunk/modules/proxy/mod_proxy.h 2011/10/14 19:48:03 1183474 +++ httpd/httpd/trunk/modules/proxy/mod_proxy.h 2011/10/14 19:51:17 1183475 @@ -907,6 +905,8 @@ extern module PROXY_DECLARE_DATA proxy_module; extern int PROXY_DECLARE_DATA proxy_lb_workers; +extern const apr_strmatch_pattern * PROXY_DECLARE_DATA ap_proxy_strmatch_path; +extern const apr_strmatch_pattern * PROXY_DECLARE_DATA ap_proxy_strmatch_domain; #endif /*MOD_PROXY_H*/ /** @} */
Re: ******** Re: 2.0.65 and 2.3.15-dev
On 10/28/2011 8:00 AM, Eric Covener wrote: On Fri, Oct 28, 2011 at 10:42 AM, Steffeni...@apachelounge.com wrote: Great, time to make 2.3.15 available to test. It would be most useful to be tested ahead of being part of an attempted release. For the pre-mentioned AcceptFilter+windows+vhost thing I have been running the fix now for a few weeks using AcceptFilter none and all has been very good.
Re: Windows 2.3.13 :: Win32DisableAcceptEx
Bill, I was using nothing, so by docs, the default is/was data. XP SP3, IPv6 Proto loaded Yes, APR_HAVE_IPV6 ==1 NVIDIA nForce 10/100/1000 v. 67.8.9.0 8/1/2008 This box originally came with Symantic, and I would assume it was able to sniff, but that was removed and it is just MSSE now, however, Symantic may not be completely gone, or anything replaced reverted. In 2.2, said error signified the need for Win32DisableAcceptEx, which when used, I would never see it again. I would like to start with a clean and not preloaded system on the box, but at this time, that is not possible. Cheers, Gregg On 10/11/2011 3:53 AM, William A. Rowe Jr. wrote: On 7/7/2011 3:39 AM, Gregg L. Smith wrote: I have an error log full of these; [Thu Jul 07 00:15:58.010625 2011] [mpm_winnt:warn] [pid 2840:tid 1572] (OS 64)The specified network name is no longer available. : winnt_accept: Asynchronous AcceptEx failed. Greg... were you using AcceptFilter 'connect' or AcceptFilter 'data' in this particular case? The bugs I resolved in the AcceptFilter 'none' case shouldn't touch this. What is your Listen directive? Did you build with APR_HAS_IPV6 == 1? What drivers are on your network stack? Are you running a network layer antivirus sniffer? This exception doesn't appear to be related to socket reuse, which is why I'm especially interested in your config and anything unusual about your environment.
Re: Notice: Intent to TR httpd 2.3.15 this week.
Bill, is this on a Windows box? I wouldn't say this is new, I had run into this back in May, I just thought it was more my misconfiguration from lack of understanding than anything. One thing I have learned since then, is that slotmem_shm works properly when running as a service, but not when running from the console, at least in the UAC flavors of Windows. I have not since retested the balancer after finding this out. Just saying, Gregg On 10/10/2011 9:26 PM, William A. Rowe Jr. wrote: On 10/10/2011 3:10 PM, William A. Rowe Jr. wrote: On 10/4/2011 12:18 PM, Jim Jagielski wrote: I plan to TR Apache httpd 2.3.15-beta this week… My intent is that this is the last beta before GA. What about the newly introduced; [Mon Oct 10 14:56:40.551571 2011] [proxy_balancer:emerg] [pid 11444:tid 436] (22)Invalid argument: worker slotmem_grab failed Configuration Failed with mod_slotmem_shm + mod_proxy_balancer both loaded? Retested w/ mod_proxy_balancer, mod_slotmem_shm and mod_slotmem_plain... still fails.
Re: svn commit: r1178079 - in /httpd/httpd/trunk: CHANGES
It looks as if ap_max_mem_free was not originally intended to be exported. But if it is going to be used in mod_ssl, it's is going to need to be no? Linking... Creating library .\Release/mod_ssl.lib and object .\Release/mod_ssl.exp ssl_engine_init.obj : error LNK2001: unresolved external symbol _ap_max_mem_free .\Release\mod_ssl.so : fatal error LNK1120: 1 unresolved externals This seems to work for Win Netware Index: include/mpm_common.h === --- include/mpm_common.h(revision 1178660) +++ include/mpm_common.h(working copy) @@ -314,7 +314,7 @@ int ap_signal_server(int *, apr_pool_t *); void ap_mpm_rewrite_args(process_rec *); -extern apr_uint32_t ap_max_mem_free; +AP_DECLARE_DATA apr_uint32_t ap_max_mem_free; extern const char *ap_mpm_set_max_mem_free(cmd_parms *cmd, void *dummy, const char *arg); Cheers, Gregg Author: sf Date: Sat Oct 1 19:48:14 2011 New Revision: 1178079 URL: http://svn.apache.org/viewvc?rev=1178079view=rev Log: If MaxMemFree is set, set SSL_MODE_RELEASE_BUFFERS in mod_ssl. Always set SSL_MODE_RELEASE_BUFFERS in ab. PR: 51618 Submitted by: Cristian RodrÃguezcrrodriguez opensuse org, Stefan Fritsch Modified: httpd/httpd/trunk/CHANGES httpd/httpd/trunk/modules/ssl/ssl_engine_init.c httpd/httpd/trunk/support/ab.c Modified: httpd/httpd/trunk/modules/ssl/ssl_engine_init.c URL: http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/ssl/ssl_engine_init.c?rev=1178079r1=1178078r2=1178079view=diff == --- httpd/httpd/trunk/modules/ssl/ssl_engine_init.c (original) +++ httpd/httpd/trunk/modules/ssl/ssl_engine_init.c Sat Oct 1 19:48:14 2011 @@ -27,6 +27,7 @@ see Recursive.'' -- Unknown */ #include ssl_private.h +#include mpm_common.h /* _ ** @@ -574,6 +575,12 @@ static void ssl_init_ctx_protocol(server */ SSL_CTX_set_options(ctx, SSL_OP_NO_SESSION_RESUMPTION_ON_RENEGOTIATION); #endif + +#ifdef SSL_MODE_RELEASE_BUFFERS +/* If httpd is configured to reduce mem usage, ask openssl to do so, too */ +if (ap_max_mem_free != APR_ALLOCATOR_MAX_FREE_UNLIMITED) +SSL_CTX_set_mode(ctx, SSL_MODE_RELEASE_BUFFERS); +#endif } static void ssl_init_ctx_session_cache(server_rec *s,
Re: Windows 2.3.13 :: Win32DisableAcceptEx
Bill, I think it's been realized that the APR/IPv6 has no bearing on this but I can confirm that 2.3.15-dev at r1177210 with apr 1.4.2 and ipv6 set to 0 does the exact same thing. Cheers, Gregg On 9/29/2011 11:58 AM, William A. Rowe Jr. wrote: On 7/7/2011 3:39 AM, Gregg L. Smith wrote: I have an error log full of these; [Thu Jul 07 00:15:58.010625 2011] [mpm_winnt:warn] [pid 2840:tid 1572] (OS 64)The specified network name is no longer available. : winnt_accept: Asynchronous AcceptEx failed. This might be http://svn.apache.org/viewvc?view=revisionrevision=1091826 confusing the issue if you build with Win32 IPv6 toggled on, depending on your operating system and the SDK you used to build... it was introduced in 1.4.3, you might want to try reverting this patch after first working through the ticket below... Thanks to Steffen's bringing this up, I now know how I should be fixing this. The problem is, if I set AcceptFilter http none I lose all my vhosts and everything reverts to the main host. If I use Implies that the host headers are not queried for ***normal*** sockets, and reviewing http://svn.apache.org/viewvc?view=revisionrevision=1088569 it looks like this was optimized (read:bugged) away. Could you please revert this APR 1.4.3 change and report back what you observe? Another option is to simply try APR 1.4.2 binaries. It seems AcceptEx() crap still pollutes APR. We can't optimize for the AcceptEx() case because that is handled in httpd. The flag simply prevents us from querying twice (and this becomes stranger because getpeername() simply fails for an AcceptEx'ed socket anyways). The unknown flag can only be tripped if we can affirmatively set the correct value.
Re: [Vote] httpd 2.2.21 release
On 9/9/2011 9:10 AM, William A. Rowe Jr. wrote: Candidate binaries are available from http://httpd.apache.org/dev/dist/ which do not yet constitute ASF releases. win32-x86 binary distribution will follow shortly. This will be a 72 hour vote, which ends no later than Noon ET Monday +/-1 [ ] Release httpd 2.2.21 as GA +1 Win XP, Vista x86 +1 2008 R2 x64
Re: next steps for range fix in 2.2.x
On 9/5/2011 12:44 AM, Plüm, Rüdiger, VF-Group wrote: -Original Message- From: Jeff Trawick [mailto:traw...@gmail.com] Sent: Sonntag, 4. September 2011 17:30 To: Apache HTTP Server Development List Subject: next steps for range fix in 2.2.x Can anyone fill in any details for the following? 1. Any known regressions not yet fixed in trunk? 2. Any other issues not yet fixed in trunk? a. r1163833 needs to be modified/reverted so that 200 is sent instead of 206 (see discussion for that commit) 3. Need patch for 2.2.x to review/test; needs r1163833 (or modification) and following from http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/http/by terange_filter.c?sortby=dateview=log 4. Wait to see if more regressions pop up in the next couple of days I guess we should wait until mid week for further regression. After that we should create a backport starting from r1163197 until current of byterange_filter.c Regards Rüdiger +1 regressions suck, but the killer is silenced as far as I can tell at this point, the script fails it's internal test, no need to rush and gain more regressions hurrying to fix the regressions from hurrying to silence the killer. My meager view anyway :) Regards, Gregg
Re: [VOTE] Release httpd-2.3.14 as beta
+1 for beta Windows x86 x64 XP, Vista x86 Server 2008 R2
Re: [NOTICE] Intent to TR httpd 2.3.14
No, but this is not a regression from any prior version (AcceptFilter issue), I just tested on 2.3.5 and the issue is there. I don't see this as holding up another Beta should folks want one. It surely needs to addressed asap before GA. Gregg On 7/25/2011 8:03 AM, Steffen wrote: Reported Windows issue fixed ? - Original Message - From: Jim Jagielski j...@jagunet.com To: dev@httpd.apache.org Sent: Monday, July 25, 2011 4:49 PM Subject: [NOTICE] Intent to TR httpd 2.3.14 Just a heads up that my plan is to TR httpd 2.3.14 later on this week (like Thursday), now that the LDAP issues have been reverted. Let's polish up trunk and rebuild the momentum to 2.4.0!
Re: Please test the build
Built this last night against APR/APU 1.4 HEAD, all went well. Thanks Stefan for getting things moving again. Cheers Gregg On 7/24/2011 12:51 PM, Stefan Fritsch wrote: Please test the recent changes of the module selections, especially if you use non-Linux Unix flavors and/or non-default library locations. Don't forget to do ./buildconf first. The ldap revert also affects Windows/Netware. It would be nice if someone could confirm that mod_ldap+mod_authnz_ldap build correctly on these platforms.
Re: Windows 2.3.13 :: Win32DisableAcceptEx
Hi, I have an error log full of these; [Thu Jul 07 00:15:58.010625 2011] [mpm_winnt:warn] [pid 2840:tid 1572] (OS 64)The specified network name is no longer available. : winnt_accept: Asynchronous AcceptEx failed. Thanks to Steffen's bringing this up, I now know how I should be fixing this. The problem is, if I set AcceptFilter http none I lose all my vhosts and everything reverts to the main host. If I use AcceptFilter https none I have no ssl because of the same reason, it reverts to the main host which is not https and I get this in Firefox An error occurred during a connection to servertwo.tld. SSL received a record that exceeded the maximum permissible length. (Error code: ssl_error_rx_record_too_long) http://servertwo.tld:443 works, but isn't https, and doesn't serve the right document, it serves the document of the main host. Win32DisableAcceptEx never suffered this horrendous problem. What I am seeing in the error log is bizarre; [Thu Jul 07 01:25:28.419000 2011] [core:error] [pid 3332:tid 1532] [client 127.0.0.1:52880] request failed: invalid characters in URI What's invalid about https://servertwo.tld Vista or XP, same thing. Gregg On 7/4/2011 8:52 PM, William A. Rowe Jr. wrote: On 7/4/2011 9:46 AM, Steffen wrote: The widely used Win32DisableAcceptEx is not anymore in 2.3. Can someone confirm that this has the same effect: AcceptFilter http none AcceptFilter https none Maybe an idea to update the upgrading docu on this subject ? http://httpd.apache.org/docs/2.3/mod/core.html#acceptfilter AcceptEx() is supported with AcceptFilter data, or connect, per the documentation. AcceptEx() is not used for AcceptFilter none.
Re: Re: reallyall vs. all vs. most
I was just pondering this mod_log_debug myself on the Windows side. There, we have only what I would guess as the equivalents of Most and All. If I were the one who could make the decision I'd want it in Most (BuildBin). just my 2 pesos, Gregg -Original Message- From: Daniel Ruggeri drugg...@primary.net To: dev@httpd.apache.org Date: Tue, 05 Jul 2011 21:39:16 -0500 Subject: Re: reallyall vs. all vs. most I would also see a case for mod_log_debug to be in MOST. It's one of those modules that one wouldn't care too much about until it's needed. -- -- Daniel Ruggeri
mod_log_debug
Hi Stefan, You're declaring this module as extern module log_debug_module; This is causing a failure to compile on Windows. Obviously every other single compiler but MSVC doesn't care. However, every single other extern module (ssl, proxy,dbd,dav, etc) is declared like so extern module AP_MODULE_DECLARE_DATA log_debug_module; This does build fine on MSVC and the module does work with my very limited testing. [Wed Jul 06 00:09:16.987200 2011] [log_debug:info] [pid 5188:tid 1528] [client ::1:50629] /foo/ has been requested (log_transaction hook, C:/Apache23/conf/httpd.conf:179) Can this be changed? Cheers, Gregg
Re: Re: [VOTE] Release Apache httpd-2.3.13 as beta
Hi Bill, Steffen, et all, It's Jeffs r1103595 Cheers, Gregg -Original Message- From: William A. Rowe Jr. wr...@rowe-clan.net To: dev@httpd.apache.org Date: Fri, 01 Jul 2011 00:33:34 -0500 Subject: Re: [VOTE] Release Apache httpd-2.3.13 as beta On 6/30/2011 11:08 PM, Gregg L. Smith wrote: Hi Bill, Steffen, All I can add to this at the moment is this is happening in XP, I am running in Vista x86 just fine. I have not built on 2008 R2 x64 yet but I will assume (ouch) for now it will work fine there as well. That's an incredibly useful hint, thanks Gregg!
Re: Re: [VOTE] Release Apache httpd-2.3.13 as beta
Hi Jeff, I can confirm this does fix the problem. Thanks, Gregg -Original Message- From: Jeff Trawick traw...@gmail.com To: dev@httpd.apache.org Date: Sat, 2 Jul 2011 14:54:10 -0400 Subject: Re: Re: [VOTE] Release Apache httpd-2.3.13 as beta On Sat, Jul 2, 2011 at 2:09 AM, Gregg L. Smith g...@gknw.net wrote: Hi Bill, Steffen, et all, It's Jeffs r1103595 cool! can you confirm that r1142264 fixes it for you?
Re: Re: Windows Laundry List pt3, mod_watchdog
Hi Mladen, Ok, I'm just a dumb guy but for me, if it drops to the hard drive (it's built on my platform) it should at minimum load without crashing the server. I personally have no use for any of this (watchdog, heartmonitor,heartbeat,lbmethod_heartbeat) that I know of at this time, they do all seem to be connected though so let those that do have use on Windows get it actually working. That said, works may not be correct, but with this code in, it crashes the child every time the child tries to load the module. Without this code, the module loads and I start seeing this in my debug log; [Thu Jun 30 23:15:38.003000 2011] [watchdog:debug] [pid 3428:tid 988] mod_watchdog.c(164): SingletonWatchdog (_heartmonitor_) running (3428) Parent PID is 3992, not 3428. When I shut down Apache I do not see any processes laying around in a zombie state. There is logs/httpd.pid as well. Not a great way to get this info but it is there in Windows and since you are doing something differently for windows, it's another option. How does the whatever writes that PID file get the parent PID, as of yet still a mystery to me. Ok, now since there is zero docs on this module, I am winging it a little. But looking at the TAKE1 there is only one directive, WatchdogInterval, being Watchdog interval in seconds, not a hard stretch. Leaving this Win32 specific code in however, the module will not work for whatever reason. Bed time. Cheers, Gregg -Original Message- From: Mladen Turk mt...@apache.org To: dev@httpd.apache.org Date: Fri, 01 Jul 2011 07:26:14 +0200 Subject: Re: Windows Laundry List pt3, mod_watchdog On 07/01/2011 06:31 AM, Gregg L. Smith wrote: Hi folks, Well, this is the same chunk of Win32 specific debugging code causing this module to crash yet again. I remember suggesting it be removed before, now I am a little more adamant about it because it is really not needed, IMO of course. If you really got to have it there, please a _DEBUG to the #ifdef WIN32. This module is needed for heartmonitor (which has it's own problems coming under separate cover). So, either it crashes on win32 or it works, your choice :-) If your choice is let it fail, then get rid of it all, heartbeat, heartmonitor, lb_method_heartmonitor watchdog on Windoze. Of course, if there is no improvement on documentation, most of it will go bye bye come GA anyway, per what is stated in STATUS. Attached patch just gets rid of it. This cannot be omitted. Getting the parent pid means we we are in the child process, so we must not init the parent watchdog thread (see 'return OK;') Parent watchdog thread is windows specific and allows to have a watchdog registered in parent process since the way how parent and child cooperate is different then on unixes since there's no fork() available. How exactly does it crash? You say either it crashes on win32 or it works with a smiley, is not very informative. Regards -- ^TM
Gental Reminder Re: Windows Laundry List pt2, mod_authn_socache
Well? :-) See original email for patch to Win build stuff. I nagged Nick to fix this module to not crash on Windows, let's get it in the build, pretty please. Cheers, Gregg -Original Message- From: Gregg L. Smith g...@gknw.net To: dev@httpd.apache.org Date: Tue, 17 May 2011 18:13:38 -0700 Subject: Windows Laundry List pt2, mod_authn_socache Hello folks, I promised this long ago and I think I forgot to follow up. Here is the Windows build stuff for this module. Cheers, Gregg
Re: Re: [VOTE] Release Apache httpd-2.3.13 as beta
Hi Bill, Steffen, all, My prior RE: to this has not shown up, so if it eventually does, sorry for the double. This seems to be specific to pre-Vista versions of Windoze. I am having no problem in Vista x86 yet same build crashes (child only) on XP. I have not tried 2008 R2 x64 yet. I have not been able yet to get Dr. Watson to spit out a backtrace yet, will try some more. Cheers, Gregg -Original Message- From: William A. Rowe Jr. wr...@rowe-clan.net To: dev@httpd.apache.org Date: Thu, 30 Jun 2011 15:38:38 -0500 Subject: Re: [VOTE] Release Apache httpd-2.3.13 as beta On 6/30/2011 3:19 PM, Steffen wrote: Found the following in drwatson when it crashes at start up: * State Dump for Thread Id 0x1e48 * eax=7c90da1a ebx= ecx=00c0ffa8 edx=00c0ffb0 esi=0094c198 edi=6ff43294 eip=6eed568f esp=00c0ff88 ebp=00c0ffec iopl=0 nv up ei pl nz na pe nc cs=001b ss=0023 ds=0023 es=0023 fs=003b gs= efl=0202 function: libapr-1!apr_os_thread_put Did it happen to provide a backtrace for that thread? These are the registers and faulting function, but need to know the callers of apr_os_thread_put() to understand why it was called with invalid arguments and second guess which invocation this was.
Windows Laundry List pt4, mod_heartmonitor
Hello again, This one is quite simple in that there are simply no Unix file permissions in Windows for sure, Netware and OS/2 assumed. Attached patch keeps this module from failing to load due to unix permission setting. This is a interesting one, if one is using slotmem_shm there is no problem, but it does have a file based backup mode (wish most using slotmem_shm did since I am having problems in proxy_balancer with slotmem_shm) and that is when us Windows folks run into a problem. Cheers, Gregg heartmonitor_win32_noperms.diff Description: Binary data
Windows Laundry List pt3, mod_watchdog
Hi folks, Well, this is the same chunk of Win32 specific debugging code causing this module to crash yet again. I remember suggesting it be removed before, now I am a little more adamant about it because it is really not needed, IMO of course. If you really got to have it there, please a _DEBUG to the #ifdef WIN32. This module is needed for heartmonitor (which has it's own problems coming under separate cover). So, either it crashes on win32 or it works, your choice :-) If your choice is let it fail, then get rid of it all, heartbeat, heartmonitor, lb_method_heartmonitor watchdog on Windoze. Of course, if there is no improvement on documentation, most of it will go bye bye come GA anyway, per what is stated in STATUS. Attached patch just gets rid of it. Cheers, Gregg watchdog_debug_remove.diff Description: Binary data
Re: Re: [VOTE] Release Apache httpd-2.3.13 as beta
Hi Bill, Steffen, All I can add to this at the moment is this is happening in XP, I am running in Vista x86 just fine. I have not built on 2008 R2 x64 yet but I will assume (ouch) for now it will work fine there as well. I'll try to see if I cannot track this down a little closer to the source, no promises though :-) So I suppose I am a non-binding -1 since there is a problem ... pre-Vista. The child is crashing over and over while the parent survives. It's actually quite a struggle to remove all the crash dialogs from the screen they come so many so fast. I have not gotten Dr. Watson to give me a backtrace, that may require a different computer, maybe not, we'll see. I can always try to log before every call to this APR function if worse comes to worse. Cheers, Gregg -Original Message- From: William A. Rowe Jr. wr...@rowe-clan.net To: dev@httpd.apache.org Date: Thu, 30 Jun 2011 15:38:38 -0500 Subject: Re: [VOTE] Release Apache httpd-2.3.13 as beta On 6/30/2011 3:19 PM, Steffen wrote: Found the following in drwatson when it crashes at start up: * State Dump for Thread Id 0x1e48 * eax=7c90da1a ebx= ecx=00c0ffa8 edx=00c0ffb0 esi=0094c198 edi=6ff43294 eip=6eed568f esp=00c0ff88 ebp=00c0ffec iopl=0 nv up ei pl nz na pe nc cs=001b ss=0023 ds=0023 es=0023 fs=003b gs= efl=0202 function: libapr-1!apr_os_thread_put Did it happen to provide a backtrace for that thread? These are the registers and faulting function, but need to know the callers of apr_os_thread_put() to understand why it was called with invalid arguments and second guess which invocation this was.
Re: Re: http_protocol.h, ap_rputs inline spells disaster on MSVC
Hi Stefan, Yes, switching to APR_INLINE did the trick, thanks. Cheers, Gregg -Original Message- From: Stefan Fritsch s...@sfritsch.de To: dev@httpd.apache.org Date: Mon, 27 Jun 2011 19:57:50 +0200 Subject: Re: http_protocol.h, ap_rputs inline spells disaster on MSVC Hi Gregg, On Monday 27 June 2011, Gregg L. Smith wrote: looking at the submitted by in r1131465 this is a part of all the code cleanup I have been seeing in bugzilla of late. It seems however that inlining ap_rputs is causing problems on MSVC. I am using VC9 and here is what I am seeing everywhere the header is included. please check if r1140249 fixes it. Bill and Joe have also made commits which should fix the other two issues you pointed out (thanks!). Cheers, Stefan
http_protocol.h, ap_rputs inline spells disaster on MSVC
Hello,
looking at the submitted by in r1131465 this is a part of all the code cleanup
I have been seeing in bugzilla of late. It seems however that inlining ap_rputs
is causing problems on MSVC. I am using VC9 and here is what I am seeing
everywhere the header is included.
C:\build3\httpd-HEAD_r1139549\include\http_protocol.h(337) : error C2054:
expected '(' to follow 'inline'
C:\build3\httpd-HEAD_r1139549\include\http_protocol.h(338) : error C2085:
'ap_rputs' : not in formal parameter list
C:\build3\httpd-HEAD_r1139549\include\http_protocol.h(338) : error C2143:
syntax error : missing ';' before '{'
Cheers,
Gregg
r1130022 oops
Hi Bill, makefile.win line 80 You're missing a closing quote. Cheers, Gregg
mod_ldap doesn't build
Hello again, MSVC 2008 I've been trying to follow along this shift of ldap from APU to httpd to remove it from APR2, so my question is; Does http trunk now have ldap in it? If it does, why am I running into this? util_ldap.c line 41 #if !AP_HAS_LDAP #error mod_ldap requires httpd to detect LDAP support #endif AP_HAS_LDAP is defined in ap_ldap.h, the only problem is, this header is not included in util_ldap.c. It is included in util_ldap.h but only if AP_HAS_LDAP is defined. Is this just needing to be define in the CFLAGS for the mod_ldap project? If I do this I get redefinition warnings but mod_ldap builds. util_ldap_cache_mgr.c c:\build3\httpd-head_r1139549\include\ap_ldap.h(185) : warning C4005: 'AP_LDAP_IS_SERVER_DOWN' : macro redefinition c:\build3\httpd-HEAD_r1139549\include\util_ldap.h(35) : see previous definition of 'AP_LDAP_IS_SERVER_DOWN' Also, I am building with APU 1.4 HEAD, as far as I can see, apr_ldap is still there. Something just seems a bit wonky here. Cheers, Gregg
Re: [Discuss] -deps package revisioning
I agree, we've been waiting this long, a little longer doesn't hurt;-) It is in place for 2.2.19 and I've already built 2.3.12 with this and the new apr/apu .. so all is good in the world. Gregg -Original Message- From: William A. Rowe Jr. wr...@rowe-clan.net On the subject of your post, totally agree, we can wait a bit longer for httpd-2.3.13(Win64) signatures :) Not many changes here since beta tag.
Re: Re: Windows Laundry List
Bill, Yes there is a PR 47418 by Jorge for it. I've flagged as depending on 49997. Gregg -Original Message- From: William A. Rowe Jr. wr...@rowe-clan.net To: dev@httpd.apache.org Date: Tue, 17 May 2011 14:19:37 -0500 Subject: Re: Windows Laundry List About the patch, yes this should go in. I'm busy for a day or few but flagged your message to come back to it, if there is a bugzilla incident please tag it 'depends on' PR 49997.
Re: Re: Windows Laundry List
Jorge, That's hard to measure considering how many people supply x64 builds of Apache on Win. I only know of 3. I can tell you Apache Haus' stats for 2.2.17 x64: 1864 x86: 1471 x64 overtook x86 the first x64 build that was offered. I'd love to see your kind of numbers at AH. Gregg -Original Message- From: Jorge Schrauwen jorge.schrau...@gmail.com To: dev@httpd.apache.org Date: Tue, 17 May 2011 18:10:33 +0200 Subject: Re: Windows Laundry List I'm still all for this, But do many people use a 64-bit variant of httpd it self? I've long since switched to linux for both my server and my development environment but still provide binaries I compile on my website. (If I'm lazy I get about 2-3 mails per day asking for the newest release) So here are some statistics from blackdot.be: httpd/httpd-2.2.18-win64.rar101 (went up yesterday) httpd/httpd-2.2.17-win64.rar16212 httpd/httpd-2.2.15-win64.rar15750 httpd/httpd-2.2.14-win64.rar10403 httpd/httpd-2.2.13-win64.rar3110 httpd/httpd-2.2.12-win64.zip801 httpd/httpd-2.2.11-win64.zip14347 httpd/httpd-2.2.10-win64.zip1521 httpd/httpd-2.2.9-win64.zip 2666 httpd/httpd-2.2.8-win64.zip 2181 httpd/httpd-2.2.4_x64.exe 4859 I wonder about the overall usage, more people seem to be compiling them themselves recently and some other websites probably offer them. Do the argument from a few year back still hold for the ASF not providing them themselves still hold true for 2.3/2.4? IIRC it had to due with VC6 being used for 3rd party module compatibility. With the release of 2.4 series around the corner maybe now is a good time to discuss this again? Kind regards ~Jorge On Tue, May 17, 2011 at 7:17 AM, Gregg L. Smith g...@gknw.net wrote: Hi folks, This was originally asked for by Jorge of blackdot.be back in July of 2006. http://marc.info/?l=apache-httpd-devm=115394468128469w=2 With the simple fact that every Windows computer I have seen being sold for some time now being x64, I do not see any reason to hold back on this since there is no functional change. His patch looks like it would give out a redefinition warning, so here's my version. I'm using WIN64 where he uses _WIN64, the reason is both are being used, the former is used in numerous files throughout httpd APR, the latter in mpm/winnt/child.c. My x64 conversion script defines WIN64 and the compiler _WIN64 so for me both are covered. Feel free to use whichever you prefer. It would be nice to see this in both trunk 2.2. Patch is against trunk, and patches 2.2 with fuzz due to following lines being different. Thanks for your consideration in this matter. Gregg
Re: Re: Windows Laundry List
Ugh, me again, forgot to leave my say on this. Call me whatever, I prefer the IDE for a few reasons; It's simpler to rebuild one project if need be, faster too. It helps delay the onset of Carpal Tunnel. Maybe not great reasons, but frankly it's easier for noobs too. However you do it, please keep them. Since I see no make files but a few, what are your plans there? I personally like dsp/dsw's since they are much easier to read and edit even though I have pretty much retired my VC6. I have used it to export makefiles for 2.3 back a few versions. I build vc9 so conversion is no problem. That's all I'll say on that subject ;-) Gregg -Original Message- From: William A. Rowe Jr. wr...@rowe-clan.net To: dev@httpd.apache.org Date: Tue, 17 May 2011 14:19:37 -0500 Subject: Re: Windows Laundry List We may have reached the fork in the road where it no longer makes sense to maintain both a gui dsp/vcproj and makefiles from the studio solution. VC 7/2002 dropped support for exporting makefiles; VC 10 drops support for converting dsp/dsw into vcproj files. So if we want either dsp/dsw or vcproj/sln files, we may be at the point of adopting the subversion approach to generating these gui representations from makefiles or resources common to the unix build, as the apr project generates from the .
Windows Laundry List pt2, mod_authn_socache
Hello folks, I promised this long ago and I think I forgot to follow up. Here is the Windows build stuff for this module. Cheers, Gregg mod_authn_socache_winbuild.diff Description: Binary data
Windows Laundry List
Hi folks, This was originally asked for by Jorge of blackdot.be back in July of 2006. http://marc.info/?l=apache-httpd-devm=115394468128469w=2 With the simple fact that every Windows computer I have seen being sold for some time now being x64, I do not see any reason to hold back on this since there is no functional change. His patch looks like it would give out a redefinition warning, so here's my version. I'm using WIN64 where he uses _WIN64, the reason is both are being used, the former is used in numerous files throughout httpd APR, the latter in mpm/winnt/child.c. My x64 conversion script defines WIN64 and the compiler _WIN64 so for me both are covered. Feel free to use whichever you prefer. It would be nice to see this in both trunk 2.2. Patch is against trunk, and patches 2.2 with fuzz due to following lines being different. Thanks for your consideration in this matter. Gregg win32_64_os.diff Description: Binary data
Re: Re: LoadLibrary failures? (Was: RE: MinGW status)
Bill, Please roll an r2 source. Since PHP is VC9, and more people will be going outside the ASF for binaries, it would be nice for those distros as this creates a lot of litter. That or just announce in this thread the commit and I at least can patch on my own. Thanks, Gregg -Original Message- From: Jeff Trawick traw...@gmail.com To: d...@apr.apache.org, dev@httpd.apache.org Date: Wed, 11 May 2011 17:21:17 -0400 Subject: Re: LoadLibrary failures? (Was: RE: MinGW status) On Wed, May 11, 2011 at 4:44 PM, William A. Rowe Jr. wr...@rowe-clan.net wrote: On 5/11/2011 9:23 AM, Jeff Trawick wrote: Running myapp.exe against libapr-2-0.dll can result in a myapp.exe.### droplet that looks like this: 75B3 0001 1774 LoadLibraryA() misc/win32/misc.c:175 This affects httpd 2.2.18, released. ??One per pid each time httpd is launched. I am of the mind to remove the offending #include and roll an -R2.msi binary package, if nobody much minds. ??I'd leave the -win32-src packages unmolested unless people feel strongly. Rolling the binary with the patch, leaving the source alone, and providing a patch separately seems reasonable. You added this; https://svn.apache.org/viewvc/apr/apr/branches/1.4.x/misc/win32/misc.c?r1=1084322r2=1084323; which was spawned from; https://svn.apache.org/viewvc/apr/apr/trunk/misc/win32/misc.c?r1=892177r2=892176pathrev=892177 Did you intend to? Did I intend to? Yes /* Declared in include/arch/win32/apr_dbg_win32_handles.h */ APR_DECLARE_NONSTD(HANDLE) apr_dbg_log(char* fn, HANDLE ha, char* fl, int ln, int nh, /* HANDLE hv, char *dsc */...) Should I have meant to? Apparently Not!! I read the comment and not the header file. I'll suggest a better fix separately.
Re: Re: LoadLibrary failures? (Was: RE: MinGW status)
I have not received your reply on this address yet to quote but yes, that is trivial, Thank you, Gregg
Re: RE: Cannot build httpd on Win 7 + VS2010
Hi Bing, This seems more like a user support question than for the dev list but here goes; As of the last releases (2.2.17 2.3.11) there were no .sln or .vcproj files shipped in the sources. There are only the VC6 workspace project files (.dsw .dsp). These are what the cvtdsp.pl -2005 modifies and it must be used. VC 2010 will not inport convert these VC6 files. The last VC version to do so was 2008 (VC9). Therefore, at this stage you need to have a copy of VC 2008 also to do that. It will convert these VC6 files. After that import you just Save all, then open in VC2010. It will then convert them to VC 2010 which is a slow process compared to the conversion from VC6 in VC 2008. Quite frankly the best way to build on VC 2010 is on the command line with nmake. I prefer the IDE myself, but I'm using VC2008 and am not fond of VC 2010 anyway. Cheers, Gregg -Original Message- From: bswen bs...@pku.edu.cn To: dev@httpd.apache.org Date: Sun, 17 Apr 2011 16:47:45 +0800 Subject: RE: Cannot build httpd on Win 7 + VS2010 I also tried the method suggested by http://www.blackdot.be/?inc=apache/knowledge/tutorials/x64 that uses perl cvtdsp.pl -2005 to first make VS2005 project files, but all the *.vcproj files cannot converted to VS2010. Does anybody know the reason? (VS2008 had no problem, though.) Regards, Bing -Original Message- From: Gabriel Petrovay [mailto:gabipetro...@gmail.com] Sent: Wednesday, October 27, 2010 4:56 AM To: dev@httpd.apache.org Subject: Re: Cannot build httpd on Win 7 + VS2010 I am still experimenting. I don't think it's a permission problem. I am on a separate partition with all the necessary rights. I managed though to build it with nmake only with the click one more time approach. So, by running nmake (NMAKE /f Makefile.win installd) several times I managed to get over the 'tempfile.bat' errors. Does this ring a bell? In VS, they are errors. Trying to built according to: http://httpd.apache.org/docs/2.2/platform/win_compiling.html#workspacebuild - during the first build, I got header not found errors complaining about apr.h - (I tried one more time) starting from the 2nd build onwards, the errors are LINK errors. cannot find external symbol With the nmake build above i could finally build/debug the problem mentioned in the other post (slow shutdown waiting for treads) (I see that you already replied to that, and I am curious ;) ) Regards, Gabriel On Tue, Oct 26, 2010 at 10:41 PM, Gregg L. Smith li...@glewis.com wrote: Hello Gabriel, I've run into this on xp, vista 2008. Somehow source folders get put in read only mode. Make them writable again and it will build. On Win7 if that means putting it in Documents, so be it. As far as errors in IDE, you sure they are not warnings? 2 warnings per project is what I see on 2010. I do not like 2010 so I haven't compiled Apache with since I gave it a try after it's release. Gregg Original Message --- Hi, Can you make Apache build on Windonws 7 and Visual Studio 2010? Neither the nmake nor the IDE builds work: NMAKE: nmake -f Makefile.win installd Error: aprutil.mak(1459) : fatal error U1054: cannot create inline file 'tempfile.bat' IDE: building project InstallBin = thousands of errors Are these build scripts/project maintained? Thanks! -- MSc Gabriel Petrovay Mobile: +41(0)787978034 www.28msec.com -- MSc Gabriel Petrovay Mobile: +41(0)787978034 www.28msec.com
Re: Re: svn commit: r1086756 - in /httpd/httpd/trunk: docs/manual/developer/new_api_2_4.xml include/ap_mmn.h include/http_config.h modules/lua/mod_lua.c server/config.c server/util.c
Hello, To add to this, I can confirm this breaks at least mod_macro, which I use and am stuck either reconfiguring (which defeats the purpose of this highly useful module) or am stuck at 2.3.12-dev pre this revision. Not that this adds any weight to the discussion. At least if this is depreciated but left in tact as is was, it relieves my stress and gives module authors a warning as to what's coming. Module authors of course may or may not decide to follow along, we'll just have to see. As a sidebar note, module compatibility is the #1 reason I hear when I ask people why they have not upgraded to 2.2 from a prior version in various help forums. If there were no need for 3rd party modules it would be a different story, but alas it's not. I think there should be some backwards compatibility till Apache 3, but that's just my opinion of course. Thanks for listening. Cheers, Gregg -Original Message- From: Guenter Knauf fua...@apache.org To: dev@httpd.apache.org Date: Wed, 13 Apr 2011 04:02:08 +0200 Subject: Re: svn commit: r1086756 - in /httpd/httpd/trunk: docs/manual/developer/new_api_2_4.xml include/ap_mmn.h include/http_config.h modules/lua/mod_lua.c server/config.c server/util.c Stefan, Am 29.03.2011 23:29, schrieb s...@apache.org: Author: sf Date: Tue Mar 29 21:29:34 2011 New Revision: 1086756 URL: http://svn.apache.org/viewvc?rev=1086756view=rev Log: Change the ap_cfg_getline() and ap_cfg_getc() to return an error code. Also: - Make ap_cfg_getline() return APR_ENOSPC if a config line is too long. - Add ap_pcfg_strerror() function to convert ap_cfg_getline's return value into a nice message. - Adjust definition of ap_configfile_t accordingly. Not bumping MMN because it has already been bumped today. Modified: httpd/httpd/trunk/docs/manual/developer/new_api_2_4.xml httpd/httpd/trunk/include/ap_mmn.h httpd/httpd/trunk/include/http_config.h httpd/httpd/trunk/modules/lua/mod_lua.c httpd/httpd/trunk/server/config.c httpd/httpd/trunk/server/util.c ... /* Read one character from a configfile_t */ -AP_DECLARE(int) ap_cfg_getc(ap_configfile_t *cfp) +AP_DECLARE(apr_status_t) ap_cfg_getc(char *ch, ap_configfile_t *cfp) ... I'm not yet convinced that this API change is a good idea ... we have this API already since httpd 1.3 times: http://httpd.apache.org/dev/apidoc/apidoc_ap_cfg_getc.html and a couple of modules may rely on it ... I think we should only declare the original function as deprecated, and add a new one, f.e.: AP_DECLARE(apr_status_t) ap_cfg_getchar(char *ch, ap_configfile_t *cfp) G??n.
Re: Re: slotmem_plain slotmem consumers
Nor would I expect you to. At minimum a hint in the consumers that mod_slotmem_shm should be loaded. The current error message is not very clear to a user IMO. mod_heartmonitor does this, explicitly says mod_watchdog is needed should it not be loaded also. There are other problems in at least mod_heartmonitor for us Windows folk should a slotmem provider not be available at all, mainly unix file permissions being set by the module and the module then errors when it receives the not implemented message. Originally I was on the probably erroneous thought process that mainly, we have this provider here but no, zero, zilch consumers. Seems odd no? Cheers, Gregg -Original Message- From: Jim Jagielski j...@jagunet.com On Apr 1, 2011, at 8:28 PM, NormW wrote: If they *do* then I'm +1 on the patch, but adding the patch w/o verification is just silly...
slotmem_plain slotmem consumers
Hello, It seems that slotmem_plain is not being found by the consumers which then causes a configuration error. Attached patch fixes this and makes the error message a little more friendlier for users by hinting to load slotmem which is currently not documented as a requirement of these modules. Regards, Gregg slotmem_consumers_fix.diff Description: Binary data
mod_watchdog crashes Apache on Windows
Hello, After r1070317 a block of code got moved below the block of Win32 debug code that starts now at line 447. The code that was above it is now just directly below but this has caused a crash on Windows for whatever reason (still unknown to me). The attached patch moves this block of debugging code down where it should be to correspond to where it used to be pre r1070317. The other alternative is to remove the block of debugging code completely should someone feel that might be more appropriate. Regards, Gregg watchdog_win32_fix.diff Description: Binary data
Re: Re: HEAD on trunk broken
Thanks R??diger, Jim,
This fixes the crash on Window's I had reported couple week ago. Ping Nick.
Regards,
Gregg
-Original Message-
From: Jim Jagielski j...@jagunet.com
To: dev@httpd.apache.org
Date: Thu, 10 Mar 2011 11:51:14 -0500
Subject: Re: HEAD on trunk broken
On Mar 10, 2011, at 11:43 AM, Pl??m, R??diger, VF-Group wrote:
I guess the following patch should fix that:
Index: mod_authn_socache.c
===
--- mod_authn_socache.c (revision 1080266)
+++ mod_authn_socache.c (working copy)
@@ -126,11 +126,12 @@
}
static void authn_cache_child_init(apr_pool_t *p, server_rec *s)
{
-const char *lock = apr_global_mutex_lockfile(authn_cache_mutex);
+const char *lock;
apr_status_t rv;
if (!configured) {
return; /* don't waste the overhead of
creating mutex cache */
}
+lock = apr_global_mutex_lockfile(authn_cache_mutex);
rv = apr_global_mutex_child_init(authn_cache_mutex, lock, p);
if (rv != APR_SUCCESS) {
ap_log_error(APLOG_MARK, APLOG_CRIT, rv, s,
Feel free to commit if it resolves the issue as I won't have a chance to do
so today or tomorrow morning.
It does... no idea yet why this started happening though,
unless it's due to some changes w/ default modules??
Re: Re: mod_authn_socache was Re: Time to start planning for ...
Hi Nick, If I remove the test at 92-94 it moves along to the next step. On Windows we do not have a default provider for the platform so the server stops there, logs the configuration error but it doesn't crash. I should have mentioned that, sorry I didn't. LoadModule authn_socache_module modules/mod_authn_socache.so LoadModule socache_dbm_module modules/mod_socache_dbm.so AuthnCacheSOCache dbm [1] This may not be important but as is with the above config the module still crashes, it doesn't seem to satisfy as being configured. With 92-94 removed however, I've found it is enough to get us up and running. Hope this helps. [1] minor docs nit, in the usage example AuthnCacheSOCache is shown in a directory context but this is a server only directive. Gregg -Original Message- From: Nick Kew n...@webthing.com Sounds like a long shot, but does the problem go away if you configure the module, or if you remove the test at lines 92-94?
mod_authn_socache was Re: Time to start planning for ...
Hi Nick, Bill,
I am in the position to give some detail, I think this module has flushed
out a bug in apr. It crashes at startup, seems to be windows specific AFAIK.
socache/nocache makes no difference, it causes a crash in libapr.
Unhandled exception in httpd.exe (LIBAPR-1.DLL):
0xC005: Access Denied, (DEP) specifically;
apr/locks/win32/proc_main.c line 189
APR_DECLARE(const char *)
apr_proc_mutex_lockfile(apr_proc_mutex_t *mutex)
{
--return mutex-fname;
}
Context: apr_proc_mutex_lockfile(apr_proc_mutex_t *mutex)
mutex 0x
|- pool CXX0030: Error: expression cannot be evaluated
|- handle CXX0030: Error: expression cannot be evaluated
|- fname CXX0030: Error: expression cannot be evaluated
Poking around the other platforms I notice beos, netware os2 simply
return NULL. Even in unix it will return NULL if it doesn't meet a
conditional test. Modifying line 189 to return NULL the server starts,
serves up my index page with includes to perl scripts, phpinfo() and
does what I generally expect it to do.
I'm not sure that's the right way to go about it but it seems there should be
some kind of test before blindly returning mutex-fname, so if
there needs to be a NULL returned as in this case, it can be. What test
exactly I don't know.
Is this happening because a mutex is being registered in the module but
never created since we are bailing out of post config before doing that?
Gregg
-Original Message-
From: Nick Kew n...@webthing.com
On Mon, 14 Feb 2011 09:20:49 -0800
Gregg L. Smith g...@gknw.net wrote:
Hi folks,
In the spirit of beta, could we get the last missing module that I know of,
mod_authn_socache, in the Windows build? Reading it's doc it sounds like a
good module to have if using dbd for authentication.
Should be a useful module for dbd-authn users on any platform!
But I don't have a windows platform to test on.
It currently crashes if loaded without any configuration in Windows, it may
even crash with configuration for all I know but I do not have a setup to use
to configure it for at the moment.
When does it crash? At startup, or when processing requests?
Are you in a position to send any diagnostic information
like a traceback that could help us find a bug?
Are you running any other modules that use socache?
Re: Time to start planning for httpd 2.3.11-BETA ?
Hi folks, In the spirit of beta, could we get the last missing module that I know of, mod_authn_socache, in the Windows build? Reading it's doc it sounds like a good module to have if using dbd for authentication. It currently crashes if loaded without any configuration in Windows, it may even crash with configuration for all I know but I do not have a setup to use to configure it for at the moment. So if there are no objections I'd like to have it added. Regards, Gregg -Original Message- From: Jim Jagielski j...@jagunet.com To: dev@httpd.apache.org Date: Thu, 10 Feb 2011 09:27:32 -0500 Subject: Time to start planning for httpd 2.3.11-BETA ? Let's commit to pushing for a 2.3.11-BETA... mod_authn_socache_winbuild .diff Description: Binary data
Re: Time to start planning for httpd 2.3.11-BETA ?
Hello again, This get's our httpd.conf file in Windows up to date with what is actually being put on the file system with respect to modules. Applies with offset -1 if applied before mod_authn_socache addition in my prior email. Regards, Gregg -Original Message- From: Jim Jagielski j...@jagunet.com To: dev@httpd.apache.org Date: Thu, 10 Feb 2011 09:27:32 -0500 Subject: Time to start planning for httpd 2.3.11-BETA ? Let's commit to pushing for a 2.3.11-BETA... awk_full_module_list.diff Description: Binary data
Re: Re: mod_proxy_balancer build failure
Hi Jim, r1069381 works, thank you. Cheers, Gregg -Original Message- From: Jim Jagielski j...@apache.org To: dev@httpd.apache.org Date: Thu, 10 Feb 2011 08:24:12 -0500 Subject: Re: mod_proxy_balancer build failure PROXY_DECLARE(apr_status_t) ap_proxy_update_members is what I want and what I meant. On Feb 9, 2011, at 11:07 PM, Gregg L. Smith wrote: Hi Jim, Thank you, yet I'm more concerned about the former one honestly as it's a no-go. I looked up the error and you can not declare a function internal to the dll as a dll import. Because of PROXY_DECLARE the function gets an import tag, so the function needs to be exported or made static. If it is your intention to export this function, things are further complicated by the fact if you /D PROXY_DECLARE_EXPORT, all functions in mod_proxy.h switch to export, so this function needs to be separated from the rest of the PROXY_DECLAREs. The attached patch does just that, allowing the function to be exported without exporting everything else, allowing this to build for Win32. If it was never your intention to export it, just make it static. Cheers, Gregg -Original Message- From: Jim Jagielski j...@apache.org To: dev@httpd.apache.org Date: Wed, 9 Feb 2011 09:26:05 -0500 Subject: Re: mod_proxy_balancer build failure On Feb 8, 2011, at 9:11 PM, Gregg L. Smith wrote: Good evening, -- Build started: Project: mod_proxy_balancer, Configuration: Release Win32 -- Compiling... mod_proxy_balancer.c .\mod_proxy_balancer.c(1332) : error C2491: 'ap_proxy_update_members' : definition of dllimport function not allowed .\mod_proxy_balancer.c(1343) : warning C4018: '' : signed/unsigned mismatch The latter fixed in r1068871 balancer.diff
Re: Re: mod_proxy_balancer build failure
Hi Jim, Thank you, yet I'm more concerned about the former one honestly as it's a no-go. I looked up the error and you can not declare a function internal to the dll as a dll import. Because of PROXY_DECLARE the function gets an import tag, so the function needs to be exported or made static. If it is your intention to export this function, things are further complicated by the fact if you /D PROXY_DECLARE_EXPORT, all functions in mod_proxy.h switch to export, so this function needs to be separated from the rest of the PROXY_DECLAREs. The attached patch does just that, allowing the function to be exported without exporting everything else, allowing this to build for Win32. If it was never your intention to export it, just make it static. Cheers, Gregg -Original Message- From: Jim Jagielski j...@apache.org To: dev@httpd.apache.org Date: Wed, 9 Feb 2011 09:26:05 -0500 Subject: Re: mod_proxy_balancer build failure On Feb 8, 2011, at 9:11 PM, Gregg L. Smith wrote: Good evening, -- Build started: Project: mod_proxy_balancer, Configuration: Release Win32 -- Compiling... mod_proxy_balancer.c .\mod_proxy_balancer.c(1332) : error C2491: 'ap_proxy_update_members' : definition of dllimport function not allowed .\mod_proxy_balancer.c(1343) : warning C4018: '' : signed/unsigned mismatch The latter fixed in r1068871 balancer.diff Description: Binary data
mod_proxy_balancer build failure
Good evening, -- Build started: Project: mod_proxy_balancer, Configuration: Release Win32 -- Compiling... mod_proxy_balancer.c .\mod_proxy_balancer.c(1332) : error C2491: 'ap_proxy_update_members' : definition of dllimport function not allowed .\mod_proxy_balancer.c(1343) : warning C4018: '' : signed/unsigned mismatch Build Time 0:00 Build log was saved at file://C:\build2\httpd-HEAD_r1068660\modules\proxy\Release\BuildLog.htm mod_proxy_balancer - 1 error(s), 1 warning(s) Cheers, Gregg
Re: Re: FYI - httpd-trunk build errors
Confirming all is fine is Windoze land as well. I'll post my project files and patch to the rest of the system soon for inclusion. Thanks, Gregg G/M Jim and Stefan, Can confirm recent updates cure the build problems noted (for NetWare folks at least - I'll let the Windows people speak for themselves.) Thanks! Regards, Norm ++goodness!
Re: FYI - httpd-trunk build errors
Hi, I'm seeing similar in Win as well looking at line numbers -- Build started: Project: mod_proxy_balancer, Configuration: Release Win32 -- Compiling... mod_proxy_balancer.c .\mod_proxy_balancer.c(739) : warning C4090: 'function' : different 'const' qualifiers -- Rebuild All started: Project: mod_slotmem_plain, Configuration: Release Win32 -- Deleting intermediate and output files for project 'mod_slotmem_plain', configuration 'Release|Win32' Compiling... mod_slotmem_plain.c .\mod_slotmem_plain.c(61) : error C2036: 'void *' : unknown size .\mod_slotmem_plain.c(110) : error C2036: 'void *' : unknown size .\mod_slotmem_plain.c(159) : error C2036: 'void *' : unknown size -- Rebuild All started: Project: mod_slotmem_shm, Configuration: Release Win32 -- Deleting intermediate and output files for project 'mod_slotmem_shm', configuration 'Release|Win32' Compiling... mod_slotmem_shm.c .\mod_slotmem_shm.c(240) : error C2036: 'void *' : unknown size .\mod_slotmem_shm.c(310) : error C2036: 'void *' : unknown size .\mod_slotmem_shm.c(338) : error C2036: 'void *' : unknown size .\mod_slotmem_shm.c(357) : error C2036: 'void *' : unknown size .\mod_slotmem_shm.c(423) : error C2036: 'void *' : unknown size .\mod_slotmem_shm.c(433) : error C2036: 'void *' : unknown size .\mod_slotmem_shm.c(460) : error C2036: 'void *' : unknown size Regards, Gregg -Original Message- From: NormW no...@gknw.net To: dev@httpd.apache.org dev@httpd.apache.org Date: Fri, 21 Jan 2011 14:21:13 +1100 Subject: FYI - httpd-trunk build errors Greetings All, Following updates yesterday httpd trunk (for NetWare folks anyway) has a few 'problems': Calling NWGNUproxybalancer Compiling mod_proxy_balancer.c ### mwccnlm Compiler: #File: mod_proxy_balancer.c # - # 739: ap_pstr2_alnum(pconf, balancer-name, balancer-sname); # Error: ^ # illegal implicit conversion from 'const char **' to # 'char **' Calling NWGNUslotmem_plain Generating obj_release\slotmem_plain_cc.opt Compiling mod_slotmem_plain.c ### mwccnlm Compiler: #File: mod_slotmem_plain.c # # 61: ptr += mem-size; # Error: ^ # illegal type ### mwccnlm Compiler: # 110: res-inuse = res-base + basesize; # Error: ^ # illegal type ### mwccnlm Compiler: # 159: ptr = score-base + score-size * id; # Error: ^ # illegal type Calling NWGNUslotmem_shm Generating obj_release\slotmem_shm_cc.opt Compiling mod_slotmem_shm.c ### mwccnlm Compiler: #File: mod_slotmem_shm.c # -- # 240: ptr += mem-desc.size; # Error: ^ # illegal type ### mwccnlm Compiler: # 310: ptr = ptr + AP_SLOTMEM_OFFSET; # Error: ^ # illegal type ### mwccnlm Compiler: # 338: ptr = ptr + AP_SLOTMEM_OFFSET; # Error: ^ # illegal type ### mwccnlm Compiler: # 357: res-inuse = ptr + basesize; # Error: ^ # illegal type ### mwccnlm Compiler: # 423: ptr = ptr + AP_SLOTMEM_OFFSET; # Error: ^ # illegal type ### mwccnlm Compiler: # 433: res-inuse = ptr + (desc.size * desc.num); # Error: ^ # illegal type ### mwccnlm Compiler: # 460: ptr = slot-base + slot-desc.size * id; # Error: ^ # illegal type Norm
Re: Fwd: util_expr_parce.c
Sorry if this breaks thread, had to subscribe a new address That is an extremely ugly solution: stdlib.h uses #ifndef _STDLIB_H internally, so this may negatively affect other plattforms or other source files which include util_expr_private.h. From reading util_expr_parse.c, I think something like #define YYMALLOC malloc #define YYFREE free in util_expr_private.h could help. Please test this. Maybe it should be surrounded by some suitable ifdef. Is _MSC_VER the correct ifdef for visual studio? Cheers, Stefan Hi Stefan, Thank you and yes that probably is not a good idea after all, I was unaware of that connection. Your suggestion does work, that removes the linkage warnings. Yes _MSC_VER is correct, the compilers do define that and our header file defines; #ifndef _INC_STDLIB #define _INC_STDLIB Thanks again, Gregg
Re: svn commit: r1055250 - in /httpd/httpd/trunk: CHANGES modules/proxy/mod_proxy_http.c modules/proxy/proxy_util.c
Hello,
minf...@apache.org wrote:
Author: minfrin
Date: Wed Jan 5 00:23:43 2011
New Revision: 1055250
Modified: httpd/httpd/trunk/modules/proxy/proxy_util.c
URL:
http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/proxy/proxy_util.c?rev=1055250r1=1055249r2=1055250view=diff
==
--- httpd/httpd/trunk/modules/proxy/proxy_util.c (original)
+++ httpd/httpd/trunk/modules/proxy/proxy_util.c Wed Jan 5 00:23:43 2011
@@ -348,16 +348,20 @@ PROXY_DECLARE(const char *)
PROXY_DECLARE(request_rec *)ap_proxy_make_fake_req(conn_rec *c, request_rec *r)
{
-request_rec *rp = apr_pcalloc(r-pool, sizeof(*r));
+apr_pool_t *pool;
+
+apr_pool_create(pool, c-pool);
+
+request_rec *rp = apr_pcalloc(pool, sizeof(*r));
MSVC idiosyncrasy, you cannot declare rp after doing something, in this
case something is calling apr_pool_create.
.\proxy_util.c(355) : error C2275: 'request_rec' : illegal use of this
type as an expression
c:\build\nresvn\include\httpd.h(730) : see declaration of
'request_rec'
.\proxy_util.c(355) : error C2065: 'rp' : undeclared identifier
to the tune of 36 total errors.
It looks like this apr_pool_create and apr_pcalloc lines were
specifically placed in this order so declare rp after pool.
apr_pool_t *pool;
request_rec *rp;
apr_pool_create(pool, c-pool);
rp = apr_pcalloc(pool, sizeof(*r));
Thanks,
Gregg
Re: Apache httpd 2.3.10-alpha pretest tarballs....
If the vote were to be held today I would +1 it. Built on VC6 XP VC9 Vista in x86 and VC9 on 2008 R2 in x64 Tested in various degrees with all the above and one live on x86 XP for over 24 hours now. Cheers, Gregg Mario Brandt wrote: +1 on Win7 (latest unix tarballs of APR, APR-Util and APR-Iconv, ossl 1.0.0c and pcre 8) On Mon, Dec 13, 2010 at 17:03, Jim Jagielski j...@jagunet.com wrote: The Apache httpd 2.3.10-alpha pre-test tarballs are available at: http://people.apache.org/~jim/httpd-2.3.10-alpha Please do a quick sanity check before I call for an official vote. tia.
Re: ditch NameVirtualHost directive?
Hi, Seems to me what users have the most problem groking is the duplicate of the main host in httpd.conf and it needing to be the first vhost. In the docs it is highlighted as Main server goes away. In reality, this is not always the case, sometimes people just get the main host and nothing else. There is not a month that goes by on the Apache Lounge forum that this does not get requests for help. It's explained on there many times but most seem incapable of using the search function. The docs are misleading cause right after they see the warning, which they do not understand in most cases, the example doesn't show it. How is a noob supposed to know that this is in reality the same hostname/docroot et al from httpd.conf or whatever the name of the file is on whatever flavor of OS; NameVirtualHost *:80 VirtualHost *:80 ServerName www.domain.tld ServerAlias domain.tld *.domain.tld DocumentRoot /www/domain /VirtualHost I see how it is explained and I understand it clearly, but I've been tinkering with Apache since 1.3.0 before that warning was ever added to the docs. I also can not think of any better to way to explain it other than literally showing it in in example. If in your httpd.conf file you have; ServerName bla.bla ... DocumentRoot /path/to/bla then in your virtual host file you need; NameVirtualHost *:80 # Duplicate of our main host is needed so that virtual hosting # works as it is supposed to VirtualHost *:80 ServerName bla.bla DocumentRoot /path/to/bla /VirtualHost # Now we can add all other hosts below VirtualHost *:80 ServerName foo.foo DocumentRoot /path/to/foo ... /VirtualHost VirtualHost *:80 ServerName bar.bar DocumentRoot /path/to/bar ... /VirtualHost Just my two cents since you brought the subject up :) Cheers, Gregg Eric Covener wrote: ... and assume overlaps are intentional opt-in to name-based vhosts? The selection algorithm would not change, meaning you'd still only be selecting from the best ip-based match. We'd lose the warning about overlapping vhosts, and maybe incur some overhead on mapping a vhost that was unintentionally showing up multiple times. Just kicking the idea around since NVH seems to be tough for users to grok.
Re: disk cache file rename errors on Windows
I'd say I am. Even though it is not a high traffic server, the last time I got one of those errors was October 8th. looking further back, it is always following one specific custom error doc that oops, didn't exist till now cause I forgot to generate a new on when I changed the look of the site. IfModule cache_module CacheIgnoreHeaders Set-Cookie IfModule disk_cache_module CacheEnable disk / CacheDirLevels 5 CacheDirLength 4 CacheRoot /path/to/cache /IfModule /IfModule Original Message --- Is anyone successfully using mod_disk_cache on Windows?
Re: httpd-2.3.9-alpha test tarballs
Jim Jagielski wrote: Anyone opposed if I declare 2.3.9 DOA and TR 2.3.10? No objections from the noisy guy in the peanut gallery. Gregg
Re: Head's up - TR of 2.3.9-alpha real soon and push for GA
Hi, It stopped my show :-) It's done, it builds (now) and I've seen it said a few times that version numbers are cheap. IIRC 2.3.7 got stopped for similar somewhere in the *nix world but why split hairs. The Lexical has moved from mod_ssl.dsp to libhttpd.dsp. A big thank you to all of you! Gregg William A. Rowe Jr. wrote: On 11/29/2010 1:06 PM, William A. Rowe Jr. wrote: On 11/22/2010 4:59 PM, Gregg L. Smith wrote: Hello, Post r1032073, trunk has not built in Windows as suggested in the log for r1032073. I see util_expr.c needs to go and util_expr_*.c/h need to be added to the build. What baffles me is the .y .l files. AFIAK, I have never built the lexical target that kicks in the custom build step using bison, flex sed on these files in mod_ssl. I tried, I failed. Not sure I am on the right page, but none the less, this will still not build on Windows as of The changes to the expr syntax aren't complete, I needed to update my toolchain to check that the new flavor will work on win32. I can likely look at this this evening, but I don't consider it a showstopper for alpha ;) Sorry, I meant changes to mod_ssl.dsp custom build steps, including file dependencies.
Re: httpd-2.3.9-alpha test tarballs
Hi Stefan, Yes, that did it. Builds vc6/9 and answers http/s. Thank you for your attention to this. While you commit win3.diff, it seems mod_disk_cache was changed to mod_cache_disk and I remember seeing mention of it. The patch attached is some clean ups needed for it. Cheers Gregg Stefan Fritsch wrote: Hi, On Thursday 25 November 2010, Gregg L. Smith wrote: Much better, results seem to be the same as Guenter's; \server\util_expr_eval.c(350) : error C2440: ':' : cannot convert from 'int (__stdcall *)(ap_expr_lookup_parms *)' to 'ap_expr_lookup_fn (__cdecl *)' \server\util_expr_eval.c(350) : error C2440: '=' : cannot convert from 'ap_expr_lookup_fn (__stdcall *)' to 'ap_expr_lookup_fn (__cdecl *)' ok, patch number three is attached. I have commited the other changes to trunk. Cheers, Stefan Index: makefile.win --- makefile.win2010-11-04 15:58:48.0 -0700 +++ makefile.win2010-11-25 23:01:31.049875000 -0800 @@ -377,8 +377,8 @@ cd ..\..\.. cd modules\cache $(MAKE) $(MAKEOPT) -f mod_cache.mak CFG=mod_cache - Win32 $(LONG) RECURSE=0 $(CTARGET) +$(MAKE) $(MAKEOPT) -f mod_cache_disk.mak CFG=mod_cache_disk - Win32 $(LONG) RECURSE=0 $(CTARGET) $(MAKE) $(MAKEOPT) -f mod_file_cache.mak CFG=mod_file_cache - Win32 $(LONG) RECURSE=0 $(CTARGET) -$(MAKE) $(MAKEOPT) -f mod_disk_cache.mak CFG=mod_disk_cache - Win32 $(LONG) RECURSE=0 $(CTARGET) $(MAKE) $(MAKEOPT) -f mod_socache_dbm.mak CFG=mod_socache_dbm - Win32 $(LONG) RECURSE=0 $(CTARGET) # $(MAKE) $(MAKEOPT) -f mod_socache_dc.mak CFG=mod_socache_dc - Win32 $(LONG) RECURSE=0 $(CTARGET) $(MAKE) $(MAKEOPT) -f mod_socache_memcache.mak CFG=mod_socache_memcache - Win32 $(LONG) RECURSE=0 $(CTARGET) @@ -637,8 +637,8 @@ copy modules\aaa\$(LONG)\mod_authz_user.$(src_so) $(inst_so) .y copy modules\arch\win32\$(LONG)\mod_isapi.$(src_so) $(inst_so) .y copy modules\cache\$(LONG)\mod_cache.$(src_so) $(inst_so) .y + copy modules\cache\$(LONG)\mod_cache_disk.$(src_so) $(inst_so) .y copy modules\cache\$(LONG)\mod_file_cache.$(src_so) $(inst_so) .y - copy modules\cache\$(LONG)\mod_disk_cache.$(src_so) $(inst_so) .y copy modules\cache\$(LONG)\mod_socache_dbm.$(src_so)$(inst_so) .y # copy modules\cache\$(LONG)\mod_socache_dc.$(src_so) $(inst_so) .y copy modules\cache\$(LONG)\mod_socache_memcache.$(src_so) $(inst_so) .y Index: build/installwinconf.awk --- build/installwinconf.awk2010-11-25 23:04:46.56550 -0800 +++ build/installwinconf.awk2010-11-26 00:12:02.487375000 -0800 @@ -112,6 +112,7 @@ print LoadModule authz_user_module modules/mod_authz_user.so dstfl; print LoadModule autoindex_module modules/mod_autoindex.so dstfl; print #LoadModule cache_module modules/mod_cache.so dstfl; + print #LoadModule cache_disk_module modules/mod_cache_disk.so dstfl; print #LoadModule cern_meta_module modules/mod_cern_meta.so dstfl; print LoadModule cgi_module modules/mod_cgi.so dstfl; print #LoadModule charset_lite_module modules/mod_charset_lite.so dstfl; @@ -121,7 +122,6 @@ print #LoadModule dbd_module modules/mod_dbd.so dstfl; print #LoadModule deflate_module modules/mod_deflate.so dstfl; print LoadModule dir_module modules/mod_dir.so dstfl; - print #LoadModule disk_cache_module modules/mod_disk_cache.so dstfl; print #LoadModule dumpio_module modules/mod_dumpio.so dstfl; print LoadModule env_module modules/mod_env.so dstfl; print #LoadModule expires_module modules/mod_expires.so dstfl; Index: os/win32/baseaddr.ref --- os/win32/baseaddr.ref 2010-11-25 23:58:41.25300 -0800 +++ os/win32/baseaddr.ref 2010-11-25 23:58:57.393625000 -0800 @@ -45,7 +45,7 @@ mod_setenvif.so 0x6FC00x0001 mod_userdir.so 0x6FBF0x0001 mod_cache.so0x6FBE0x0001 -mod_disk_cache.so 0x6FBD0x0001 +mod_cache_disk.so 0x6FBD0x0001 mod_buffer.so 0x6FBC0x0001 mod_deflate.so 0x6FBA0x0002 mod_ext_filter.so 0x6FB90x0001
Re: httpd-2.3.9-alpha test tarballs
Hello Stefan, Much better, results seem to be the same as Guenter's; \server\util_expr_eval.c(350) : error C2440: ':' : cannot convert from 'int (__stdcall *)(ap_expr_lookup_parms *)' to 'ap_expr_lookup_fn (__cdecl *)' \server\util_expr_eval.c(350) : error C2440: '=' : cannot convert from 'ap_expr_lookup_fn (__stdcall *)' to 'ap_expr_lookup_fn (__cdecl *)' Regards, Gregg Original Message --- Stefan, Am 25.11.2010 08:14, schrieb Stefan Fritsch: On Tuesday 23 November 2010, Gregg L. Smith wrote: Here we go, cannot test beyond libhttp warning aren't a big deal but showing them anyway with errors Thanks. Please try the attached patch in addition to all changes so far. please go ahead and commit; it looks good so far, I get now only the one error in util_expr_eval.c line 350, but I have not yet a rule to recreate the file in my OpenWatcom makefile ... Gün.
RE: httpd-2.3.9-alpha test tarballs
Original Message --- Pre-test tarballs of httpd-2.3.9-alpha are available at: http://people.apache.org/~jim/httpd-2.3.9-alpha/ Please try 'em out and I'll make them official test tarballs... -1, does not build on Windows. Libhttpd - Cannot find util_expr.c No problem, but then there is util_expr_scan.c, which must be Flexed with what looks like Flex 2.5.35. It is unfortunate that the GNUWin32 version of Flex is still back at 2.5.4a. C:\buildprep\httpd-2.3.8flex -Putil_expr_yy -s -B .\server\util_expr_scan.l .\server\util_expr_scan.l, line 32: unrecognized %option: reentrant .\server\util_expr_scan.l, line 33: unrecognized %option: bison-bridge The alternative is a MinGW or Cygwin version, which will require Cygwin at the least. If we now have this requirement, might as well scrap Visual Studio and go with MinGW/GCC. Gregg
RE: httpd-2.3.9-alpha test tarballs
Original Message --- Pre-test tarballs of httpd-2.3.9-alpha are available at: http://people.apache.org/~jim/httpd-2.3.9-alpha/ Please try 'em out and I'll make them official test tarballs... -1, does not build on Windows. Libhttpd - Cannot find util_expr.c No problem, but then there is util_expr_scan.c, which must be Flexed with what looks like Flex 2.5.35. It is unfortunate that the GNUWin32 version of Flex is still back at 2.5.4a. C:\buildprep\httpd-2.3.8flex -Putil_expr_yy -s -B .\server\util_expr_scan.l .\server\util_expr_scan.l, line 32: unrecognized %option: reentrant .\server\util_expr_scan.l, line 33: unrecognized %option: bison-bridge The alternative is a MinGW or Cygwin version, which will require Cygwin at the least. If we now have this requirement, might as well scrap Visual Studio and go with MinGW/GCC. Gregg
Re: httpd-2.3.9-alpha test tarballs
Hi Stefan, I too have no problem if I do not need to regenerate these files. I thought the ones there were skeletons, not buildable files. My mistake. I'll patch build. There will be other problems. In util_expr_scan.c line 612 there is an #ifndef YY_NO_UNISTD_H around a include to unistd.h, where would you suggest putting a #ifdef WIN32 #define YY_NO_UNISTD_H #endif util_expr_private.h? Thanks, Gregg Hoping this webmail doesn't send twice again. Original Message --- On Tuesday 23 November 2010, Gregg L. Smith wrote: Original Message --- Pre-test tarballs of httpd-2.3.9-alpha are available at: http://people.apache.org/~jim/httpd-2.3.9-alpha/ Please try 'em out and I'll make them official test tarballs... -1, does not build on Windows. Based on pure guesswork, I have produced the attached diff. Libhttpd - Cannot find util_expr.c No problem, but then there is util_expr_scan.c, which must be Flexed with what looks like Flex 2.5.35. It is unfortunate that the GNUWin32 version of Flex is still back at 2.5.4a. C:\buildprep\httpd-2.3.8flex -Putil_expr_yy -s -B .\server\util_expr_scan.l .\server\util_expr_scan.l, line 32: unrecognized %option: reentrant .\server\util_expr_scan.l, line 33: unrecognized %option: bison-bridge The alternative is a MinGW or Cygwin version, which will require Cygwin at the least. The generated .c and .h files are also provided in the tarball. There should be not need to regenerate them unless you want to change the .y or .l file. If we now have this requirement, might as well scrap Visual Studio and go with MinGW/GCC. IMHO it is completely acceptable if the the generated files can only be re-generated on unix, as long as the result can be compiled under Windows.
Re: httpd-2.3.9-alpha test tarballs
\server\util_expr_eval.c(43) : warning C4180: qualifier applied to function type has no meaning; ignored \server\util_expr_eval.c(96) : warning C4180: qualifier applied to function type has no meaning; ignored \server\util_expr_eval.c(109) : warning C4018: '' : signed/unsigned mismatch \server\util_expr_eval.c(350) : error C2440: ':' : cannot convert from 'int (__stdcall *)(ap_expr_lookup_parms *)' to 'ap_expr_lookup_fn (__cdecl *)' \server\util_expr_eval.c(350) : error C2440: '=' : cannot convert from 'ap_expr_lookup_fn (__stdcall *)' to 'ap_expr_lookup_fn (__cdecl *)' \server\util_expr_eval.c(661) : warning C4180: qualifier applied to function type has no meaning; ignored \server\util_expr_eval.c(661) : warning C4090: 'initializing' : different 'const' qualifiers \server\util_expr_eval.c(673) : warning C4180: qualifier applied to function type has no meaning; ignored \server\util_expr_eval.c(673) : warning C4090: 'initializing' : different 'const' qualifiers \server\util_expr_eval.c(1276) : error C2440: 'function' : cannot convert from 'apr_status_t (__stdcall *)(void *)' to 'apr_status_t (__cdecl *)(void *)' \server\util_expr_eval.c(1276) : warning C4024: 'apr_pool_cleanup_register' : different types for formal and actual parameter 3 log.c \server\log.c(452) : error C2440: 'function' : cannot convert from 'apr_status_t (__stdcall *)(void *)' to 'apr_status_t (__cdecl *)(void *)' \server\log.c(452) : warning C4024: 'apr_pool_cleanup_register' : different types for formal and actual parameter 3 \server\log.c(1020) : warning C4018: '' : signed/unsigned mismatch config.c \server\config.c(480) : error C2440: 'function' : cannot convert from 'apr_status_t (__stdcall *)(void *)' to 'apr_status_t (__cdecl *)(void *)' \server\config.c(480) : warning C4024: 'apr_pool_cleanup_register' : different types for formal and actual parameter 3 Original Message --- On Tuesday 23 November 2010, Gregg L. Smith wrote: In util_expr_scan.c line 612 there is an #ifndef YY_NO_UNISTD_H around a include to unistd.h, where would you suggest putting a #ifdef WIN32 #define YY_NO_UNISTD_H #endif util_expr_private.h? Yes, exactly. Maybe it should be #ifndef APR_HAVE_UNISTD_H #define YY_NO_UNISTD_H #endif though.
Re: Head's up - TR of 2.3.9-alpha real soon and push for GA
Hello, Post r1032073, trunk has not built in Windows as suggested in the log for r1032073. I see util_expr.c needs to go and util_expr_*.c/h need to be added to the build. What baffles me is the .y .l files. AFIAK, I have never built the lexical target that kicks in the custom build step using bison, flex sed on these files in mod_ssl. I tried, I failed. Not sure I am on the right page, but none the less, this will still not build on Windows as of Revision: 1037772 Node Kind: directory Schedule: normal Last Changed Author: fuankg Last Changed Rev: 1037609 Last Changed Date: 2010-11-21 22:12:14 -0800 (Sun, 21 Nov 2010) I do not know if it matters that this version builds on Windows, but some of us would like it too. Regards, Gregg Jim Jagielski wrote: Time got away from me... Since 2.3.9 is alpha, I feel no real hesitation in pushing it out this week, which is a holiday week for US people... Plan to TR on tues (11/23) so get your stuff in ;) On Nov 2, 2010, at 10:13 AM, Jim Jagielski wrote: I plan to TR 2.3.9-alpha within 2 weeks (not sure how much free time I'll have this week @ ACNA). Ideally, my plan is to then release a beta the start of Dec and a GA Jan of 2011.
RE: Cannot build httpd on Win 7 + VS2010
Hello Gabriel, I've run into this on xp, vista 2008. Somehow source folders get put in read only mode. Make them writable again and it will build. On Win7 if that means putting it in Documents, so be it. As far as errors in IDE, you sure they are not warnings? 2 warnings per project is what I see on 2010. I do not like 2010 so I haven't compiled Apache with since I gave it a try after it's release. Gregg Original Message --- Hi, Can you make Apache build on Windonws 7 and Visual Studio 2010? Neither the nmake nor the IDE builds work: NMAKE: nmake -f Makefile.win installd Error: aprutil.mak(1459) : fatal error U1054: cannot create inline file 'tempfile.bat' IDE: building project InstallBin = thousands of errors Are these build scripts/project maintained? Thanks! -- MSc Gabriel Petrovay Mobile: +41(0)787978034 www.28msec.com
Re: Clean shutdown on Windows
Jeff,
In the next day or two while doing this, could please have a look at PR 48949.
TIA,
Gregg
Original Message ---
On Mon, Oct 25, 2010 at 10:30 AM, Gabriel Petrovay
gabipetro...@gmail.com wrote:
Hi,
Maybe this gives you some hints. I have looked a little in the code of
mod_fcgi. In fcgid_pm_main.c (361) you have:
/* Kill gracefully */
for (i = 0; i proctable_get_table_size(); i++) {
if (proc_table[i].proc_pool)
proc_kill_gracefully(proc_table[i], main_server);
}
apr_sleep(apr_time_from_sec(1));
/* Kill with SIGKILL if it doesn't work */
for (i = 0; i proctable_get_table_size(); i++) {
if (proc_table[i].proc_pool) {
if (apr_proc_wait((proc_table[i].proc_id), exitcode, exitwhy,
APR_NOWAIT) != APR_CHILD_NOTDONE) {
proc_table[i].diewhy = FCGID_DIE_SHUTDOWN;
proc_print_exit_info(proc_table[i], exitcode, exitwhy,
main_server);
apr_pool_destroy(proc_table[i].proc_pool);
proc_table[i].proc_pool = NULL;
}
else
proc_kill_force(proc_table[i], main_server);
}
}
-
You can see that mod_fcgi tries to gracefully kill the child processes
(proc_kill_gracefully).
Than it waits 1 second. (probably hoping that the process finishes,
case in which the assumption is wrong; assume that we need 2 seconds
to shut-down).
Than it starts to kill all the still running processes (/* Kill with
SIGKILL if it doesn't work */). Since my process is not finished, it
returns in line 371 APR_CHILD_NOTDONE (70006) so proc_kill_force() is
called in line 380.
So that is why my process is killed at random times during shutdown.
Is this a bug? or am I missing something?
IMO this should work in a similar manner to the
ap_reclaim_child_processes functions used by Unix MPMs:
kill-gracefully
wait
kill-gracefully
wait
kill-gracefully
wait
kill-forcefully (this starts at about 9 seconds)
wait
giveup
though mod_fcgid doesn't necessarily need so many iterations or as
large a delay.
I'll plan to code up a patch for this in the next day or so.
Re: ScriptLog
Hi Stefan, Not in my book it shouldn't go away. It is the only place I can get good debug info on perl scripts ... OK, not the only place but it is easiest place to find the needed info. Since perl is not 100% dead and gone, please keep it. It seems fine as-is, as I've been using it 10 years now. Please take of radar. Regards, Gregg Stefan Fritsch wrote: On Sunday 26 September 2010, Rich Bowen wrote: Another question on this thread - is ScriptLog also going away? It hasn't been on my radar so far. Should it? pros: - per dir config instead of per vhost - possibly finer control with different trace levels cons: - data would use more space in error log because of the log prefix on every line - ScriptLogLength would go away, too
Re: [PRERELEASE TARBALLS] httpd-2.3.8
A loud resounding Amen to Guenter from the Windows balcony. I have reservations however. 1. I have a patch that let's me build trunk with the PCRE 5.0 from 2.2, but I do not want to stay at PCRE 5.0 cause you have to have something newer to link mod_security 2.5.12+ against, so I have to build something newer regardless (not that any 3rd party module even works in 2.3.x at the moment). 2. I have no problems building PCRE 8 on Windows w/ CMake and dropping the 4 files in srclib/pcre. The annoyance is makefile.win wanting to copy the non-existing pcre.pdb and barfing there. Another patch ;-) 3. I have not been able to get pcre 8 (current 8.10) to build in tree like pcre 5 on 2.3.x, in 2.2.x yes. The static lib seems to not export some needed symbols (pcre_free comes to mind as one). I have not tried building in tree as DLL however. While not ignoring Paul's comments included with his NO vote, as I see it, there are three different build systems included in the tarballs, Windows, Netware and one for most flavors of Unix. We get the code for mod_suexec which in not built on Windows and just sits there dormant, why could PCRE not be included (for Windows and Netware and OS/2 and ?) and just simply not be included in the makefiles and sit there dormant in the different flavors of Unix as mod_suexec does on Windows/Netware? So if I could vote, I'd vote +0.5 till I knew what version you were planning on including and it would only go to a full 1 if pcre was not built on Unixs' and was newer than 6.5 (the mod_security minimum IIRC). Regards, Gregg Guenter Knauf wrote: Hi all, Am 24.08.2010 18:42, schrieb Jim Jagielski: The pre-release test tarballs for httpd-2.3.8 (alpha) are available for download, test and fun: http://httpd.apache.org/dev/dist/ Will call for a release vote in a coupla days... I know that this topic was already up here, but nevertheless I think we should re-think about including PCRE again. Other than openssl or zlib PCRE is a mandatory dependency like APR/APU, and I see no benefit in dropping it from our dependencies deliveries other than making tarballs smaller, and that is nowadays certainly not an issue anymore. We want Apache to build form source on at many platforms as possible - sure the main target is Linux / Unix, but we have a couple of other platforms where PCRE is not installed by default, that are at least Win32, NetWare, most likely OS/2, and probably a couple of others too. I tried to build 2.3.7 already for NetWare and Win32, and while NetWare went fine only because I have an (self) adapted makefile (from previous times when we shipped PCRE), the Win32 stuff is horrible: there comes some suggestion up that I should build PCRE with CMake with xxx option; 1st I have to download CMake and depend on another build tool (ok, not that big issue), but whats even more worse is that the CMake build failed for me, and thats really bad - you cant just go and build httpd as you do on Linux, no! Your build process is always interupted, and probably as in my case finally broken at all. Hey, friends, we do much better with 2.2.x where we ship PCRE: we have our own makefile, and the build goes through in one go without need for other tools like CMake - just the compiler and probably a platform PDK are enough (and thats how it shoud be). Therefore I want to start a vote here again where we vote for including PCRE again with the dependencies - just as we (now) do with APR/APU; and everyone who votes against should give some good reasons what speaks against -- the fact that every Linux comes with PCRE is certainly no good reason - it only leads finally to the fact that we might end up with 50 builds of httpd 2.after-2.x with different PCE versions which makes then nice bug hunting, and we cant even tell someone who faces a prob to 'use our shipping PCRE which is known to be good'. Here we go: [ ] YES - include recent PCRE again with dependencies (means we create a PCRE repo in svn, check in a recent version, and add platform-dependent makefiles which are fully integrated into main build process). [ ] NO - dont include PCRE (as currently) because of reason: ... thanks, Gün.
Re: svn commit: r981060 - /httpd/httpd/branches/2.2.x/STATUS
Hello Rainer, I am +1 for this, as a matter of fact I lobbied for this 10 months ago. http://marc.info/?l=apache-httpd-devm=125421199606305w=2 If it is going to be done however, please do it completely. Attached is the rest of what is needed. [mod_proxy_scgi_project.patch] mod_proxy_scgi.dsp - must be there for the module to really build in IDE, otherwise if you add to Apache.dsw and do not include the project file, vc++ is going to complain and never build the module. Instead, it will just show the project as unloaded I think. I do see you covered installwinconf.awk which was overlooked when adding this module to trunk. Big thanks, this is one less patch I need to use and maintain. Gregg rj...@apache.org wrote: Author: rjung Date: Sat Jul 31 13:49:52 2010 New Revision: 981060 URL: http://svn.apache.org/viewvc?rev=981060view=rev Log: Add proposal. Modified: httpd/httpd/branches/2.2.x/STATUS Modified: httpd/httpd/branches/2.2.x/STATUS URL: http://svn.apache.org/viewvc/httpd/httpd/branches/2.2.x/STATUS?rev=981060r1=981059r2=981060view=diff == --- httpd/httpd/branches/2.2.x/STATUS (original) +++ httpd/httpd/branches/2.2.x/STATUS Sat Jul 31 13:49:52 2010 @@ -250,6 +250,11 @@ PATCHES PROPOSED TO BACKPORT FROM TRUNK: 2.2 patch: trunk patch works with offset +1: sf, rpluem + * mod_proxy_scgi: Add module to build on Windows. + It already gets build for other platforms and for Windows in trunk. + 2.2 patch: http://people.apache.org/~rjung/patches/mod_proxy_scgi-win-build-2_2.patch + +1: rjung + PATCHES/ISSUES THAT ARE STALLED * core: Support wildcards in both the directory and file components of Index: modules/proxy/mod_proxy_scgi.dsp === --- modules/proxy/mod_proxy_scgi.dsp (No File) +++ modules/proxy/mod_proxy_scgi.dsp (Working Copy) @@ -0,0 +1,123 @@ +# Microsoft Developer Studio Project File - Name=mod_proxy_scgi - Package Owner=4 +# Microsoft Developer Studio Generated Build File, Format Version 6.00 +# ** DO NOT EDIT ** + +# TARGTYPE Win32 (x86) Dynamic-Link Library 0x0102 + +CFG=mod_proxy_scgi - Win32 Release +!MESSAGE This is not a valid makefile. To build this project using NMAKE, +!MESSAGE use the Export Makefile command and run +!MESSAGE +!MESSAGE NMAKE /f mod_proxy_scgi.mak. +!MESSAGE +!MESSAGE You can specify a configuration when running NMAKE +!MESSAGE by defining the macro CFG on the command line. For example: +!MESSAGE +!MESSAGE NMAKE /f mod_proxy_scgi.mak CFG=mod_proxy_scgi - Win32 Release +!MESSAGE +!MESSAGE Possible choices for configuration are: +!MESSAGE +!MESSAGE mod_proxy_scgi - Win32 Release (based on Win32 (x86) Dynamic-Link Library) +!MESSAGE mod_proxy_scgi - Win32 Debug (based on Win32 (x86) Dynamic-Link Library) +!MESSAGE + +# Begin Project +# PROP AllowPerConfigDependencies 0 +# PROP Scc_ProjName +# PROP Scc_LocalPath +CPP=cl.exe +MTL=midl.exe +RSC=rc.exe + +!IF $(CFG) == mod_proxy_scgi - Win32 Release + +# PROP BASE Use_MFC 0 +# PROP BASE Use_Debug_Libraries 0 +# PROP BASE Output_Dir Release +# PROP BASE Intermediate_Dir Release +# PROP BASE Target_Dir +# PROP Use_MFC 0 +# PROP Use_Debug_Libraries 0 +# PROP Output_Dir Release +# PROP Intermediate_Dir Release +# PROP Ignore_Export_Lib 0 +# PROP Target_Dir +# ADD BASE CPP /nologo /MD /W3 /O2 /D WIN32 /D NDEBUG /D _WINDOWS /FD /c +# ADD CPP /nologo /MD /W3 /O2 /Oy- /Zi /I ../../include /I ../../srclib/apr/include /I ../../srclib/apr-util/include /D NDEBUG /D WIN32 /D _WINDOWS /FdRelease\mod_proxy_scgi_src /FD /c +# ADD BASE MTL /nologo /D NDEBUG /win32 +# ADD MTL /nologo /D NDEBUG /mktyplib203 /win32 +# ADD BASE RSC /l 0x809 /d NDEBUG +# ADD RSC /l 0x409 /foRelease/mod_proxy_scgi.res /i ../../include /i ../../srclib/apr/include /d NDEBUG /d BIN_NAME=mod_proxy_scgi.so /d LONG_NAME=proxy_http_module for Apache +BSC32=bscmake.exe +# ADD BASE BSC32 /nologo +# ADD BSC32 /nologo +LINK32=link.exe +# ADD BASE LINK32 kernel32.lib ws2_32.lib mswsock.lib /nologo /subsystem:windows /dll /out:.\Release\mod_proxy_scgi.so /base:@..\..\os\win32\BaseAddr.ref,mod_proxy_scgi.so +# ADD LINK32 kernel32.lib ws2_32.lib mswsock.lib /nologo /subsystem:windows /dll /incremental:no /debug /out:.\Release\mod_proxy_scgi.so /base:@..\..\os\win32\BaseAddr.ref,mod_proxy_scgi.so /opt:ref +# Begin Special Build Tool +TargetPath=.\Release\mod_proxy_scgi.so +SOURCE=$(InputPath) +PostBuild_Desc=Embed .manifest +PostBuild_Cmds=if exist $(TargetPath).manifest mt.exe -manifest $(TargetPath).manifest -outputresource:$(TargetPath);2 +# End Special Build Tool + +!ELSEIF $(CFG) == mod_proxy_scgi - Win32 Debug + +# PROP BASE Use_MFC 0 +# PROP BASE Use_Debug_Libraries 1 +# PROP BASE Output_Dir Debug +# PROP BASE Intermediate_Dir Debug +# PROP BASE Target_Dir +# PROP Use_MFC 0 +# PROP Use_Debug_Libraries 1 +# PROP Output_Dir Debug +# PROP Intermediate_Dir Debug +# PROP
Re: svn commit: r981060 - /httpd/httpd/branches/2.2.x/STATUS
I see this statement I made to be incorrect now since you added this today. Regards, Gregg Gregg L. Smith wrote: installwinconf.awk which was overlooked when adding this module to trunk.
Re: [VOTE] Release httpd 2.2.16
Peanut Gallery vote: [+1] Release httpd-2.2.16 XP SP3, VC6 SDK 2003 R2 ... ~24 hours live w/ no problems seen XP SP3/Vista SP1, VC9 ... no problems noticed w/ light testing Server 2008 R2 (x64), SDK 7 ... no problems noticed w/ light testing Cheers Beers Gregg
