Re: Proposal: adoption of mod_combine subproject
Looks like a very interesting module! i'd love to see this adapted. ~Jorge On Tue, Dec 13, 2011 at 7:27 PM, Graham Leggett minf...@sharp.fm wrote: Hi all, As with mod_firehose and mod_policy, I have concluded negotiation with the BBC to open source some httpd modules that I wrote under the AL, and the BBC have very kindly agreed to donate the code to the ASF[1], which I believe would fit well as a subproject of httpd, and would like to know whether httpd would accept these. To be clear, this isn't a code dump, my intention is to continue to develop and support this moving forward, and hopefully expand the community around them. - mod_combine: Response concatenation As a page gets more complex, and eventually parts of the page like the header and footer become maintained by separate teams, the elements that make up a page can become fragmented. In the process, you can end up with a page that takes ages to load, because lots of fragments of javascript or fragments of CSS files are being downloaded separately by the browser. mod_combine is a handler that allows multiple URLs hosted by the server to be concatenated together and delivered as a single response, cutting down on the number of requests, and in turn the page loading time. At the same time, mod_combine attempts to behave sensibly when one or more of the files is missing, so as not to amplify a failure. The handler also properly supports conditional requests, creating a super ETag, and then reversing it to apply conditional requests on each element being concatenated. The code is currently packaged as an RPM, wrapped in autotools, and a snapshot is available here: http://people.apache.org/~minfrin/bbc-donated/mod_combine/ The corresponding README documenting in more detail is here: http://people.apache.org/~minfrin/bbc-donated/mod_combine/README The code itself is here: http://people.apache.org/~minfrin/bbc-donated/mod_combine/mod_combine.c Obviously the expectation is for the documentation to be completed and fleshed out. [1] https://issues.apache.org/bugzilla/show_bug.cgi?id=52322 Regards, Graham --
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
FOSDEM
Any httpd people coming to FOSDEM in Brussels, Belgium this weekend? If so Saterday or Sunday? I hope to go on Saterday... But need to clear something first :( Kind regards Jorge -- ~Jorge
Re: official httpd VC9 builds
Hi If I remember correctly wrowe said it was because a lot of 3rd party modules use VC6. Although that was a while ago so I could be wrong. If I'm indeed correct maybe 2.4 is a good time to switch to VC9? ~Jorge On Mon, Jan 31, 2011 at 10:06 AM, Ferenc Kovacs tyr...@gmail.com wrote: Hi. I'm a php developer, and I'm using VC9 php builds on windows(PHP 5.3 doesn't support ), hence I'm using the apache httpd builds from apachelounge.com, because you guys only offer VC6 windows builds, and I'm too lazy to build myself. My question is: why is this the case? as far as I can tell, the project builds fine with VC9, so why don't you support the VC9 builds? I would prefer the official builds for VC9, if that would be an option. If I missed something obvious there, then please bear with me, I tried to find the answer in the windows section of the download page, the wiki, and the mailing lists, but without much luck. Tyrael
Re: official httpd VC9 builds
Right, command line builds where part of the reason for still using VC6. Alteast that rings a vague bell. If we provide VC9 builds for 2.4+, we could do a 32-bit and 64-bit one then... But that would mean 3 (or 2) binary packages for windows which could result in a lot of extra work :( How are the current binaries for windows made? Script or manual? ~Jorge On Mon, Jan 31, 2011 at 11:05 AM, Issac Goldstand mar...@beamartyr.net wrote: I believe also that wrowe mentioned to me that we wanted to support command line (make) builds, and VC9 doesn't allow us to export makefiles. I'm +1 for making both VC6 and VC9 builds from 2.4 and on, like PHP does. Issac On 31/01/2011 11:21, Jorge Schrauwen wrote: Hi If I remember correctly wrowe said it was because a lot of 3rd party modules use VC6. Although that was a while ago so I could be wrong. If I'm indeed correct maybe 2.4 is a good time to switch to VC9? ~Jorge On Mon, Jan 31, 2011 at 10:06 AM, Ferenc Kovacs tyr...@gmail.com wrote: Hi. I'm a php developer, and I'm using VC9 php builds on windows(PHP 5.3 doesn't support ), hence I'm using the apache httpd builds from apachelounge.com, because you guys only offer VC6 windows builds, and I'm too lazy to build myself. My question is: why is this the case? as far as I can tell, the project builds fine with VC9, so why don't you support the VC9 builds? I would prefer the official builds for VC9, if that would be an option. If I missed something obvious there, then please bear with me, I tried to find the answer in the windows section of the download page, the wiki, and the mailing lists, but without much luck. Tyrael
Windows installer package, missing modules
Hey, I downloaded the latest windows msi (with ssl) because I had no time to manually compile. I noticed mod_reqtimeout.so is missing but it is available in the default httpd.conf Maybe it should be removed (or the module included) so users don't accidentally enable it. Well, if it something that can be easily done. Most usually will probably figure out the error when they uncomment it. Kind regards Jorge
Re: [vote] Release mod_ftp 1.0.0 as GA
~Jorge On Fri, Oct 8, 2010 at 4:23 AM, William A. Rowe Jr. wr...@rowe-clan.net wrote: After some discussion on list about the numbering and quality of mod_ftp today, it seems this is an appropriate time to consider GA, candidate tarballs are up at http://httpd.apache.org/dev/dist/mod_ftp/ - so please vote... +/-1 [X] Release mod_ftp 1.0.0 as GA Seems good, not load tested it though.
Re: [vote] Release mod_ftp 1.0.0 as GA
~Jorge On Fri, Oct 8, 2010 at 7:55 AM, Jorge Schrauwen jorge.schrau...@gmail.com wrote: ~Jorge On Fri, Oct 8, 2010 at 4:23 AM, William A. Rowe Jr. wr...@rowe-clan.net wrote: After some discussion on list about the numbering and quality of mod_ftp today, it seems this is an appropriate time to consider GA, candidate tarballs are up at http://httpd.apache.org/dev/dist/mod_ftp/ - so please vote... +/-1 [X] Release mod_ftp 1.0.0 as GA Seems good, not load tested it though. Oops forgot: Using gentoo
Re: Reducing number of mod_lua hook directives
+1 ~Jorge On Mon, May 10, 2010 at 9:41 PM, Jeff Trawick traw...@gmail.com wrote: On Mon, May 10, 2010 at 3:25 PM, Brian McCallister bri...@skife.org wrote: On Mon, May 10, 2010 at 11:02 AM, Dan Poirier poir...@pobox.com wrote: mod_lua has 8 separate directives for adding hooks using external files with Lua code (LuaHookX) and 8 more for adding the same hooks using inline Lua code (LuaHookX). Most of the code to implement these is common. I think it'd be easier to understand - and document - the module if we cut these down to two directives, with an additional argument to indicate which hook is involved. E.g. change LuaHookAccessChecker /path/to/script.lua funcname LuaHookAuthChecker /path/to/script.lua funcname LuaHookCheckUserID /path/to/script.lua funcname ... to LuaHook AccessChecker /path/to/script.lua funcname LuaHook AuthChecker /path/to/script.lua funcname LuaHook CheckUserID /path/to/script.lua funcname This makes a ton of sense to me. +1
Re: AVG gives warning unpacking 2.2.15-win32 source
On Fri, Mar 12, 2010 at 7:10 PM, William A. Rowe Jr. wr...@rowe-clan.net wrote: On 3/12/2010 12:06 PM, Jorge Schrauwen wrote: I'm about to build the x64 binaries for on my website and AVG on my development machine throws this at me. Warning: XML Bomb: srclib/apr-util/test/data/billion-laughs.xml See attached screenshots, most likely harmless but not a nice welcome when unpacking the source. You would rather we not warn you of the vulnerability, when you compile against your existing expat? So it's AVG's that's broke? Still sucks that AVG makes it appear that the xml file is bad. On Fri, Mar 12, 2010 at 7:20 PM, Gregg L. Smith li...@glewis.com wrote: On Windows? My suggestion originally was to remove it only from the Win32 zip. Gregg Yep, this was with the windows source zip On Fri, Mar 12, 2010 at 7:16 PM, Gregg L. Smith li...@glewis.com wrote: Hi Jorge, I brought this up quite some time ago, which is why I have been moving away from AVG since I was basically ignored here :-) That and AVG's many false positives. What is worse is, that XML bomb wont hurt anything anymore, and it can be gotten around AVG as well just by adding a certain amount of more recursions. I will not post the exact number, but at some point it will be bypassed. My thoughts on this is if this problem is fixed, why does there need to be a test against it anymore other than breaking said fix in the future and therefore becoming vulnerable again. Gregg Oh didn't notice it back then, any recommendation for a for a free AV product for windows? Don't feel like forking over money to just run it on my test system which runs like... maybe 3h per httpd release to get my x64 binaries build. Well if it's harmless and posted before, sorry for not noticing the original post. Jorge
Re: Apache devs attending FOSDEM 2010?
On Wed, Jan 27, 2010 at 11:58 PM, Alex Wulms alex.wu...@scarlet.be wrote: Op donderdag 14 januari 2010 14:28:42 schreef Martin Langhoff: On Mon, Jan 11, 2010 at 8:49 PM, Nick Kew n...@webthing.com wrote: I've booked into the renaissance hotel - http://www.marriott.com/hotels/travel/brubr-renaissance-brussels-hotel/ Cool -- that's in my neighbourhood, though a tad long to walk from home :-) If so, it'd be great to get together +1. Will you be at the Friday beer event? Were you thinking in terms of an apache-specific get-together on Saturday or Sunday evening? Or other ??? I'll probably miss the Friday beer (I'll be returning from a trip that very night), but Saturday afternoon or Sunday anytime we can stage a get together. I'll be the guy running around with laptops with green ears ;-) Hi, I prefer Saturday afternoon or evening. Kind regards, Alex I'm 90% certain I'll be there on Saturday. Would be a nice ending to my exam period :)
Re: Apache devs attending FOSDEM 2010?
Thats actually not to far for me to drop by one of the days. 1 bit of relaxing after the exams! Would be nice to finally meet some people I only know from online and irc. ~Jorge On Mon, Jan 11, 2010 at 8:49 PM, Nick Kew n...@webthing.com wrote: Martin Langhoff wrote: Hi list, are any developers of apache (core, modules) coming to FOSDEM in Brussels? Yeah, me. I keep thinking we should consider an apache room there, but each year I'm too late to do anything. Bah. I've booked into the renaissance hotel - http://www.marriott.com/hotels/travel/brubr-renaissance-brussels-hotel/ Stayed there last year and was well-impressed. Walkable both to the city centre and to FOSDEM. Recommended if you haven't already booked somewhere to stay. If so, it'd be great to get together +1. Will you be at the Friday beer event? Were you thinking in terms of an apache-specific get-together on Saturday or Sunday evening? Or other ??? -- Nick Kew
Re: [VOTE] Formal deprecation of 1.3.x branch
On Mon, Jan 4, 2010 at 11:03 PM, Rich Bowen rbo...@rcbowen.com wrote: Speaking from the community that provides end-user support for these products, a big +1 on that proposal. Sadly, questions will keep on showing up for a long time :( On Tue, Jan 5, 2010 at 3:11 PM, Noirin Shirley noi...@apache.org wrote: On Tue, Jan 5, 2010 at 3:18 AM, Dan Poirier poir...@pobox.com wrote: Colm MacCárthaigh c...@allcosts.net writes: Because ... stealing an idea from wrowe@ ... how about we formally deprecate the 1.3.x branch? Make one more release, but attach a notice to the effect that it will be the final release, and that in future we'll be distributing security updates by other means :-) +1! Yes please :-) +1 (non-binding) There are still to many questions about the 1.3 branch on the support channels IMHO While we're at it, how about issuing a statement regarding how much longer 2.0.x will be supported? It doesn't seem to get much maintenance attention these days either. Also +1 +1 (non-binding) N
Re: [VOTE] Formal deprecation of 1.3.x branch
On Wed, Jan 6, 2010 at 12:30 AM, William A. Rowe Jr. wr...@rowe-clan.net wrote: Res wrote: On Tue, 5 Jan 2010, Jorge Schrauwen wrote: On Mon, Jan 4, 2010 at 11:03 PM, Rich Bowen rbo...@rcbowen.com wrote: Speaking from the community that provides end-user support for these products, a big +1 on that proposal. Sadly, questions will keep on showing up for a long time :( I agree, however if it is EOL'd (yes Jeff, I agree this is likely more of an appropriate term :) ) you more or less can advise the requestor they are using a very old and unsupported version and that they should use the current stable version 2.2.xx These questions aren't a bother on an established 1.3 server, we all have to support legacy systems. What is frightening is the number of users who are clearly deploying their httpd server with 1.3, for the first time, and trying to learn that. Almost want to suggest to them that they go take a community college class on COBOL while they are at it, since they are clearly trying to improve their technical knowledge. Heh You could just put a anti troll like system where you ask a question only someone who's used 1.3 for a long time would know before letting them download. New users wouldn't be able to answer it and would be pointed to 2.2 branch ;) /sarc It's understandable that you can't just magicly update a legacy 1.3 to a 2.x series without breaking a whole lot of stuff. But's sadly as you say, a lot users seem to be new to httpd and still grab 1.3 for some insane reason! Maybe adding some form of color coding (for the non-colorblind) on the download page, green - current, orange/yellow - old stable, red - EOL Then again that would probably not have a big effect :( I also think punch cards COBAL course! That will teach em to proof read there code before hitting compile ;) /me off to more studying Jorge
Re: A fundamentally secure Apache server, any interest?
On Mon, Nov 16, 2009 at 5:11 PM, Sander Temme scte...@apache.org wrote: Hi Kevin, Definitely not the right list: this is where we discuss development of the Apache HTTP Server code. us...@httpd.apache.org may be a better forum within apache.org. Outside Apache, several initiatives exist to look into hardening web servers. The Center for Internet Security http://www.cisecurity.org/ is one of them. On Nov 16, 2009, at 8:42 AM, Sweere, Kevin E CTR USAF AFRL/RYT wrote: I work for the US Air Force. We have a prototype that dramatically, fundamentally increases a web server's security. We run an Apache server within a minimized, user-level-only, Linux variant only within RAM and from only a DVD (no harddrive). With no shells, hackers have nowhere to go. With no persistent memory, malware has no place to reside. A simple reboot restores the website to a pristine state within minutes. I agree. Putting the entire OS and content on a read-only device (whether DVD or otherwise) significantly reduces your exposure to attacks for all these reasons. The OS will need *some* writable space (like /tmp and /var/run), but I assume you made like Knoppix and Ubuntu Live and their ilk, and use RAM disks for that. Because a LiveDVD holds the OS, apps and content, its best for static, non-interactive, low-volume, high-value, highly-targeted websites. Any change means burning a new DVD, but this also makes testing easier and less noisy. Logs are tricky to extract. You could write logs to a RAM disk, with obvious implications on retention. Or you could spool them to another server either through a network mount or mod_log_spread. The httpd configuration language allows you to put log files in any place you like, and there are several approaches to rotating log files if space is an issue. Or you can use a third party module to write logs like the aforementioned mod_log_spread, which is not part of httpd itself. While it has worked well, some of us believe its usability drawbacks (e.g. limited ability to receive input from users, every change needs a new DVD) outweigh its great security benefits making it unmarketable (in govt or industry) and thus just another prototype to leave on the shelf. You are in for a perpetual war between Operations (whose pager goes off when things break) and dev (whose time-to-market is implicated by the fixed environment). You could mitigate that problem by reading site content from a remote machine, either continuously over a network mount or by copying it into a RAM disk on boot. The former might be slower, but would allow for more frequent site updates. It's a trade-off, as usual. Keeping the remote mount read-only (even for root) will allow you achieve your goal of a read-only environment. More comprehensive upgrades that would involve adding modules or changing configuration parameters should trigger a change management process that would lead to an update of the boot image. You could just mount everything ro from a remote host then, even the config for example, could be mounted from a remote host. I guess a rw usb key with OS + config would work too if you can somehow force it ro only when booting from it. I'm curious what your group thinks. Thanks in advance -- I don't quite know with whom to discuss this idea. As Mark points out, this would be very secure but very hard to manage, and my impression is that time-to-market pressure and available expertise frequently cause ideas like this to fall by the wayside. Fundamentally, booting web heads from a read-only medium like an optical drive or PXE is a sound idea. Any initiative, installation method or distribution that makes this easier to manage might increase adoption. S. bikeshedI'd base it on BSD though/bikeshed -- Sander Temme scte...@apache.org PGP FP: 51B4 8727 466A 0BC3 69F4 B7B8 B2BE BC40 1529 24AF Thats all that comes to mind atm. Jorge
Re: Httpd 3.0 or something else
I'm with Jim, Head for 2.4 first. IIRC there was some talk about moving to a 'd' project, since httpd now does ftp (mod_ftp), echo, pop3,... and some other protocols. I don't remember much from it though. I did like the idea back then but thats about the only thing I remember from that. Maybe we could also poll the user base? I know there was a restart on the debate about the current conf and lua/perl/whatever not so long ago so maybe these are all things to look into again for a 3.0? Just my .2 cents /me off to studying windows 2008 server -_- ~Jorge On Wed, Nov 4, 2009 at 8:30 PM, Jim Jagielski j...@jagunet.com wrote: Let's get 2.4 out. And then let's rip it to shreds and drop buckets/brigades and fold in serf. On Nov 4, 2009, at 1:26 PM, Akins, Brian wrote: So, after several conversations at Apachecon and on the list, we still have no real vision of how we want to move ahead with httpd 3.0. Or, if we do, it's not communicated very well. Some have suggested we just create a new server project. Others want to keep hacking away at the current code base. Thoughts? -- Brian Akins
Re: [VOTE] release httpd mod_ftp-0.9.6 beta?
~Jorge [X] +1 to release as 0.9.6-beta Works ok here on linux (gentoo) On Tue, Sep 29, 2009 at 5:28 AM, William A. Rowe, Jr. wr...@rowe-clan.netwrote: Following Rainer's Solaris discoveries and our DISTDIR suggestions, Please fetch up the newly prepared mod_ftp-0.9.6.tar.gz (or .bz2), or the win32/netware/os2 suitable package mod_ftp-0.9.6-crlf.zip from; http://httpd.apache.org/dev/dist/mod_ftp/ review, take it for a spin, and cast your choice [ ] -1 for any release of 0.9.6 (regressed from 0.9.2 or earlier?) [X] +1 to release as 0.9.6-beta [ ] +1 to release as 0.9.6 GA For getting started, http://httpd.apache.org/mod_ftp/ and http://svn.apache.org/repos/asf/httpd/mod_ftp/tags/0.9.6/README-FTP Bill
Re: [Fwd: Re: vote on concept of ServerTokens Off]
I'm not too fond of being able to remove it either. It can always be set to Apache with the current configuration options and that should keep people worried about exploits somewhat satisfied. Even if you where able to hide it completely a good script could figure out if it's a 1.3 2.0 or 2.2 based on how it handles retain requests and on the Directory listing for example. As ~Jorge On Tue, Sep 1, 2009 at 11:36 PM, William A. Rowe, Jr.wr...@rowe-clan.net wrote: Why attach email doesn't work in thunderbird is beyond me... This was Jeff's starting point for documenting ServerTokens Off. Original Message Subject: Re: vote on concept of ServerTokens Off Date: Wed, 6 Dec 2006 13:43:49 -0500 From: Jeff Trawick traw...@gmail.com Reply-To: dev@httpd.apache.org To: dev@httpd.apache.org References: 200612061412.kb6ecwb10...@devsys.jagunet.com cc67648e0612060620p4980c023l5b71a1d733fa5...@mail.gmail.com e498c1660612060654j47bd93cbjdc5d02002ba04...@mail.gmail.com 4576f73a.3020...@force-elite.com On 12/6/06, Paul Querna c...@force-elite.com wrote: This thread is making me sad. No tears ;) The somewhat bright side is that pushing on this tender spot until it hurts should at the very least avoid having the same discussion here for the next couple of years, and at the most can avoid a lot of other wasteful discussions permanently ;) The middle ground of document explicitly why you can't directly turn it off should also be achievable. Proposed documentation for the ServerTokens directive. Special note: Apache HTTP Server users suggest from time to time that the ServerTokens directive allow the Server response header to be eliminated completely. This feature suggestion is rejected for the following reasons: * The Apache HTTP Server project wants surveys of web server usage, such as the well-known Netcraft survey, to more accurately represent the actual use of Apache httpd. While some web server administrators currently modify the Apache HTTP Server source code or install third-party modules which can remove the Server header, too few administrators do this to significantly alter the results. The same may not be true if it is an easily-accessible feature. * The Apache HTTP Server project believes that most people who want to avoid sending the Server header mistakenly think that doing so may protect their server from attacks based on known flaws in older Apache HTTPD releases, when in fact the only reasonable way to address these flaws is to upgrade to new Apache HTTPD releases which correct security problems affecting your configuration. By restricting the ability to configure Apache in this manner, we wish to raise awareness of the need to upgrade when critical vulnerabilities are addressed. (what other reasons go here?) .
Re: HTTP mode on Apache not working
Hi Madhuri, Please direct your question towards us...@httpd.apache.org, include more information than this too. Part of your config would be helpful. Kind regards ~Jorge On Thu, Aug 27, 2009 at 1:11 PM, Madhurimadhuri.say...@gmail.com wrote: Hi All - This is the first time I am setting up apache server. It works fine on SSL mode with https://XX/, however it does not work with http://XX/. Will really appreciate any help. Thanks Madhuri -- View this message in context: http://www.nabble.com/HTTP-mode-on-Apache-not-working-tp25167526p25167526.html Sent from the Apache HTTP Server - Dev mailing list archive at Nabble.com.
Re: Apache HTTP Server development
Speaking of fastCGI, wasn't a fastCGI module donated to the incubator? Maybe it's time to look more into it if people aren't already. ~Jorge On Mon, Aug 24, 2009 at 8:24 PM, Akins, Brianbrian.ak...@turner.com wrote: On 8/24/09 1:58 PM, Paul Querna p...@querna.org wrote: They then switch to lighttpd, because it is so much faster, mostly because it runs all the dynamic langauges via FastCGI, like we should. +1 I still like the idea (maybe it was yours, Paul) of running basically everything externally using HTTP as the protocol. Especially, if we supported things like basic external process management (like fcgid ) and ability to use domain sockets as well as TCP (it may be academic, but there can be some nice performance gains). I still like lua embedded, though. (Or something similar) -- Brian Akins Chief Operations Engineer Turner Digital Media Technologies
Re: A single IP address and Domain name serving many servers
You can do this with mod proxy. # Proxy Forwarding IfModule !mod_proxy.c LoadModule proxy_module modules/mod_proxy.so LoadModule proxy_http_module modules/mod_proxy_http.so /IfModule ProxyRequests Off Proxy * Order allow,deny Allow from all /Proxy #forward /siteX to backend server ProxyPass /site1/ http://10.0.0.2/ ProxyPassReverse /site1/ http://10.0.0.2/ ProxyPass /site2/ http://10.0.0.3/ ProxyPassReverse /site2/ http://10.0.0.3/ Alternatively you can use sub-domains too if you have control over both dns and apache. site1.example.org --- WAN IP -- LAN IP where apache does namevirtualhosting site2.example.org --- ... Also support questions should go to us...@httpd.apache.org and not dev@, this mailing list is for development related discussion. Jorge Schrauwen On Wed, Aug 12, 2009 at 6:01 PM, Branquimalebr...@hotmail.com wrote: I want to know if its possible and how to do it... I have one valid ip address and one internet domain. What I want to do is: - when a client access my domain with: www.mydomain.com on his web browser he access my apache server apache1.localnetwork 10.0.0.1 (I already do this through nat in iptables). - when he types www.mydomain.com/site1 I serve him with another apache server inside my local network (apache2.localnetwork 10.0.0.2). - when he types www.mydomain.com/site2 he access another server apache3.localnetwork 10.0.0.3. How can I do this redirection with the client passing me just another uri and I serving him with different apache servers, having only an external ip and domain name? Thanks. -- View this message in context: http://www.nabble.com/A-single-IP-address-and-Domain-name-serving-many-servers-tp24939564p24939564.html Sent from the Apache HTTP Server - Dev mailing list archive at Nabble.com.
Re: Main httpd web site page: update needed for 2.2.13
On Tue, Aug 11, 2009 at 7:40 PM, Guenter Knauffua...@apache.org wrote: all, Guenter Knauf schrieb: good idea! Based on this here modified samples: http://people.apache.org/~fuankg/testhttpd/releases.txt http://people.apache.org/~fuankg/testhttpd/main_index.txt and final result: http://people.apache.org/~fuankg/testhttpd/main_index.html before it again vanishes from radar - should I proceed and check-in the SSI stuff into svn? should be easy to revert if it turns out as bad, or? Not that I have anything to say on this but I agree with the if it's bad, you can revert so I say go for it. Gün.
Re: William Rowe Jr. is now V.P., Apache HTTP Server
Congrats Bill! ... although my internal understanding of the ASF is limited I seem to recall this is rather huge :) ~Jorge
Re: FTP open questions
On Tue, Jul 14, 2009 at 2:28 AM, William A. Rowe, Jr.wr...@rowe-clan.net wrote: Just finished the last showstopper. I would be happy to advance this to release / general availability vote with the next release, if we can determine just a few oddball issue resolutions. Jim and I have already gone ahead and moved many internal interfaces out of the private headers, which was my motivation for holding off a year ago. Should we advertise the commands we have not implemented, or remove them? Yes, It's always useful to know for a more advance user. Should we alert the user to the ServerAdmin address in the HELP contents? Maybe reuse ServerTokens for this? Full/OS = serveradmin + unimplemented commands Minimal = unimplemented commands Minor = only list implemented commands Major = only list allowed commands Prod = no help? That way the server admin still has a say in it? Not sure the extra coding is worth it though. Right now HELP offers up; 214-The following commands are recognized (* ='s unimplemented). FEAT TYPE RMD QUIT RNTO PORT *MODE APPE *ALLO STOR PWD *STOU *REIN AUTH MDTM SYST XMKD *SITE XCWD PASS PASV DELE *ACCT EPRT SIZE XRMD NOOP LIST REST PBSZ XCUP NLST *SMNT XPWD ABOR PROT HELP CDUP *STRU RNFR MKD *STAT RETR CWD EPSV USER 214 Direct comments to [no address given] Just for reference, three popular linux servers respond with no unimplemented features, one offers Direct comments to admin address, one offers the website address of it's project, and one just ends with the result Help OK The admin has little control over which commands are supported (although which commands are -allowed- is another matter entirely :) So it just strikes me as odd to direct comments with respect to the HELP inquiry.
Re: Help with worker.c
If I'm not mistaken it's FIFO (First In, First Out). ~Jorge On Wed, Jul 8, 2009 at 12:39 PM, ricardo13ricardoogra...@gmail.com wrote: Hi, I'm trying understand worker.c module. My doubt is about operation push() and pop(). Push() add a socket in array fd_queue_t-data and Pop() retrieve a socket for processing. But what's the order of PUSH() ?? It adds in final queue ?? And POP() ?? Retrieve a socket only before (elem = queue-data[--queue-nelts];) ?? Thank you Ricardo -- View this message in context: http://www.nabble.com/Help-with-worker.c-tp24389140p24389140.html Sent from the Apache HTTP Server - Dev mailing list archive at Nabble.com.
Re: Please Review! Path for os/win32/os.h - new reports Win64 when build for 64-bit
I thought I did but couldn't find it. I've create a new bug report: https://issues.apache.org/bugzilla/show_bug.cgi?id=47418 ~Jorge On Wed, Jun 24, 2009 at 9:40 PM, Jorge Schrauwen jorge.schrau...@gmail.comwrote: I can't remember, I'll open one tomorrow when I have access to my updated patch. ~Jorge On Wed, Jun 24, 2009 at 7:55 PM, Mario Brandtjbl...@gmail.com wrote: Hi Jorge, did you also open a bug in bugzilla? Mario On Fri, Jun 19, 2009 at 6:30 PM, Jorge Schrauwenjorge.schrau...@gmail.com wrote: Sorry to dig up this old thread again but some users of my unofficial binary have been complaining that it still says Win32. So any chances somebody could look at this again. It's a rather trivial change I think. ~Jorge
Re: Please Review! Path for os/win32/os.h - new reports Win64 when build for 64-bit
Sorry to dig up this old thread again but some users of my unofficial binary have been complaining that it still says Win32. So any chances somebody could look at this again. It's a rather trivial change I think. ~Jorge On Wed, Jul 26, 2006 at 11:00 PM, Jorge Schrauwen jorge.schrau...@gmail.com wrote: I just tried lots of diferent comment styles like #, ', ... till i found one that worked. never though there would be more that one... makes sence though, especially for larger blocks of comment. So here is an updated diff file. On 7/26/06, Ruediger Pluem rpl...@apache.org wrote: On 07/26/2006 10:10 PM, Jorge Schrauwen wrote: Ok this is my first path so please bare with me and review. Since I'm rather new to C I did a lot of research and testing on this. More information regarding the changes: http://msdn.microsoft.com/msdnmag/issues/06/05/x64/default.aspx#S4 --- os\win32\os.h --- --- os.h.orig2006-04-22 03:53:06.0 +0200 +++ os.h2006-07-26 21:22:24.000516000 +0200 @@ -38,7 +38,11 @@ #include io.h #include fcntl.h +//Checking the architecture we are compiling for (Itanium 64-bit, x64 (AMD64/EM64T) or x86) I cannot comment on the subject itself as I am not a windows man, but only on the style: Please do not use C++ style comments like //. Please use always /* */. Regarding style the following page is very helpful: http://httpd.apache.org/dev/styleguide.html Regards Rüdiger -- ~Jorge os.h.diff Description: Binary data
Re: [VOTE] release httpd mod_ftp-0.9.4 beta?
[X] +1 to release as 0.9.4-beta I didn't have time to test the EPSV EPRT, nor do I have enough knowledge on the rfc to do so atm. It does compile and is functional in my config, so it's certainly usable at the moment. So I'd like to see it hit beta. ~Jorge On Tue, Jun 9, 2009 at 1:07 AM, William A. Rowe, Jr.wr...@rowe-clan.net wrote: mod_ftp fans; Let's try this one more time, here's a 0.9.4 candidate which should have none of the 2.0 or 2.2 compatibility problems of the previous attempt. Thanks to everyone who spent the effort reviewing that package! Please fetch up the newly prepared httpd-mod_ftp-0.9.4.tar.gz (available now), or the win32/netware/os2 suitable package httpd-mod_ftp-0.9.4-crlf.zip http://httpd.apache.org/dev/dist/mod_ftp/ review, take it for a spin, and cast your choice [ ] -1 for any release of 0.9.4 (regressed from 0.9.2?) [ ] +1 to release as 0.9.4-beta [ ] +1 to release as 0.9.4-beta, and ready to tag GA (1.0.0) Please let us know if you test the two significant issues; CURRENT RELEASE NOTES: * EPSV and EPRT need real world testing for different routing and DMZ cases and validating a range of IPv6-enabled clients' interop. Note many IPv4-only NAT routers appear to ignore EPRT commands, even as they would fix up NAT addresses from PORT commands. * Extra attention should be paid to PORT and EPRT connections, especially when assigned low numbered ports, e.g. FTPActiveRange 20 These are my serious hesitations in blessing the release 1.0.0 just yet. Please be brutal in respect to testing both aspects :) Other protocol and API related showstoppers have been added with respect to the FEAT and OPTS extensions, which need small modifications to the API for cooperation between extension modules. For getting started, http://httpd.apache.org/mod_ftp/ and http://svn.apache.org/repos/asf/httpd/mod_ftp/tags/0.9.4/README-FTP Bill
Re: Some ramblings on httpd config
As long as the current system isn't replaced by an entire runtime like
program approach I'd be okay with it.
But why not take it a step further than just lua?
Wouldn't it be possible to expose a standardized set of commands,
functions, objects, whatnot to any language?
That start with mod_lua as the initial implementation but if at a
later date someone makes mod_lisp/mod_java/.. they all share about the
same objects where just the syntax would be different. Also the glue
would then also extend to not just lua.
That would also help to make it documenting it language independently
more doable. (wow thats a word?)
you could then talk about a request object having properties x,y and
z and it doesn't matter if you manipulate it via lua,java,perl
Then again this would probably cause a whole lot of overhead and would
force mod_lua to be rewriting a lot I guess.
~Jorge
On Tue, Jun 9, 2009 at 2:49 PM, Akins, Brianbrian.ak...@turner.com wrote:
On 6/5/09 11:31 PM, Graham Dumpleton graham.dumple...@gmail.com wrote:
This last example wasn't even related to driving configuration. It was
in practice an actual handler hook implementation for request
processing, not configuration phases.
The way I see it, we have artificially separated configuration from request
processing. If you squint and tilt your head just right, you can see that
virtualhosts today are really just syntactical sugar over the if/else logic
inside of core:
Some pseudo request processing code to do same thing:
if listening_port == 80 then
if r.hostname == 'www.foo.com' then
elseif r.hostname =~ /www\d.bar.[org|net]/
end
end
Of course this could be further hidden from users with
macros/functions/libraries/modules...
Now, on the practical side, do we completely ditch the current config
system. Part of me says yes, but I know that will be -1'd to death. So,
I'd just like the ability to do something like this:
LoadModule lua_module mod_lua.so
Listen 80
LuaRequestHandler /path/to/my/lua/handler.lua
(or it can be inline Lua but have found that to be somewhat cumbersome)
Because I don't want to rewrite mod_proxy in lua, it'd be nice to have just
a little bit of glue that would allow me to use it in a more scripty sort
of way:
LoadModule proxy_module mod_proxy.so
LoadModule proxy_http_module mod_proxy_http.so
require httpd.proxy -- provided by mod_proxy glue
p = httpd.proxy.get_url('http://blah')
(Of course, that example could be handled like we do in mod_rewrite)
Currently, we can sorta do most request processing in lua. (FWIW, do the
request phases make any sense in a world where the entire request process is
handled by a script??) What is missing is the glue to the other, useful
parts of httpd - like cache, mod_dbd, proxy, etc.
Sure, one of us could hack together some example glue here and there, but
until we as a whole get why this is useful/important, it will be just
another list of patches waiting to be reviewed.
--
Brian Akins
Chief Operations Engineer
Turner Digital Media Technologies
Re: Some ramblings on httpd config
On Thu, Jun 4, 2009 at 1:55 PM, Akins, Brian brian.ak...@turner.com wrote: On 6/3/09 7:50 PM, Plüm, Rüdiger, VF-Group ruediger.pl...@vodafone.com wrote: 1. There are many and large and complex configurations out in the world. Which is exactly why I want/need a better way to do them. I'm currently using a template system to generate them. However I wind up with dozens (and dozens) of vhosts that sometimes only vary by a statement or too. On this I completely agree! Currently say fetching 100+ hosts from a database that are basicly the same except domain, documentroot and maybe 3 options like has php, has cgi,.. is a PITA. mod_perl with database backend... works I guess but it's like taking a nice car, strip the engine and gut donkey and cram the engine in the donkey. Ok not what I wanted to write but can't describe it. Like Graham mentioned mod_macro can be of some use here. however since I'm looping in perl I may as well push the 4 lines needed to httpd instead of a one line macro replacemen. A contrived example: -- lots of stuff if r.hostname == www.domain.com then -- a couple of things specific to this domain elseif r.hostname == www.domain2.com then ... Of course, this example may could have a little lua glue to handle this situation. Also, I'm not just talking about lua being the config language, I want lua to drive the httpd process. Ie, the above code gets ran on every request. 2. I admit that some improvements are needed. How about an approach that allows to embed a macro / scripting language into the current configuration system that allows you to do more advanced things if you need to. If we provided enough glue within our modules for lua, this this would be fairly easy. I already fake this a bit with mod_lua and handlers that do most of the work. -- Brian Akins Chief Operations Engineer Turner Digital Media Technologies Maybe we're looking at it the wrong way? Why not go more modular with this as well? From what I've understood from wrowe's explenation the internal config tree seems very flexible so why not create multiple ways to manipulate it? module register parameters,blocks,... with the internal config mangement thingy, front ends then configure the modules using those interfaces. It being a flat file, xml file, lua script, perl script,... having little relevance to httpd itself. Flat file would turn that info say for the command into something like Documentroot /some/path Lua format would turn that in something else, whilst an xml format way turn it into Documentroot/some/path/documentroot You could keep the current method for legacy use, implement an lua one for more advance use, xml one because somebody was bored and wanted it. Heck even a lolcode one because you could. even mixing could be possible, have some general stuff in flatfile, include a lua script to generate hosts which in its turn include a flat file with shared config for each host. Then again it would be hard to write documentation for this. Since documenroot could then have many ways to be set from a users POV :( so maybe not a great idea. But I'm just trowing out the whacky brain twists I have. Jorge
Re: Some ramblings on httpd config
I know I'm playing with fire now but... XML based config could solve a few of the problems, XML can also be validated. I have to admit lua would be more flexible but I think most server admins have atleast come into contact with XML... while not necessarily the case with lua. of course a sort of code lang=luasome lua config stuff/code would be possible to if httpd would export some binding glue module for example lua,c,perl,... could be provided so complex configurations can potentially be done in a language the admin is familiar with. puts down the oil and matches and waits for the blaze to start. ~Jorge On Wed, Jun 3, 2009 at 8:39 PM, Akins, Brian brian.ak...@turner.com wrote: On 6/3/09 2:09 PM, Joachim Zobel jzo...@heute-morgen.de wrote: This does IMHO not address any of the problems users usually have and that are mainly due to a lack of validation. First of all, I don't really care about normal users, to be honest. Admit it, I'm not the only one. However, I do know that we can't just break everything for them. See http://people.apache.org/~rbowen/presentations/apacheconEU2005/hate_apache.pdf for what I consider a good description of the current problems. It solves most of the Missing page, I think. Also, if the lua doesn't compile, it's not a valid config. A few of the other points are addressed by using lua with some helper libraries. We could ease into this by having modules provide some lua glue for use in the lua handlers (proxy and cache in particular). -- Brian Akins Chief Operations Engineer Turner Digital Media Technologies
Re: Some ramblings on httpd config
On Wed, Jun 3, 2009 at 9:07 PM, Akins, Brian brian.ak...@turner.com wrote: On 6/3/09 2:45 PM, Jorge Schrauwen jorge.schrau...@gmail.com wrote: I have to admit lua would be more flexible but I think most server admins have atleast come into contact with XML... while not necessarily the case with lua. XML with conditionals. Please, make it stop... I think we are going to have to choose one way (the current way, lua, something else) and just go with it. Nice thing about lua is that the configuration is the runtime script. There is no external and internal representation of things. (Well, not exactly, but close...). Lua is fast enough to just run every request - most of the hard stuff is still in C. I think going with a language X based config system will just give us more horrible questions and make it even harder to trouble shoot things like request X works but request Y doesn't. You might as well provide a building block method and the config c based, will scare off the more casual users just like lua and only allow the oncs who know what they are doing write a decent configuration. (ok that last one is maybe a bit over exaggerated but going pure program language based is a very big learn before usage curve) Jorge Mod_rewrite goes away, which is a good thing :) -- Brian Akins Chief Operations Engineer Turner Digital Media Technologies
Re: Some ramblings on httpd config
On Wed, Jun 3, 2009 at 10:55 PM, Niklas Edmundsson ni...@acc.umu.se wrote:
On Wed, 3 Jun 2009, Jorge Schrauwen wrote:
I know I'm playing with fire now but...
XML based config could solve a few of the problems, XML can also be
validated.
I have to admit lua would be more flexible but I think most server
admins have atleast come into contact with XML... while not
necessarily the case with lua.
Fire indeed.
I've never seen lua except for Brians examples just now, and lua seems
usable. XML is just as horrible as our current config scheme and wouldn't
add much IMHO.
well I have to admit XML == fixing a few problems and probably adding lots more.
The example Bertrand Mansion posted does look acceptable to me and
like Rich I could probably live with it quite easly. But also looking
at some other examples I do fear for the madness that will ensure in
users@ and irc.
I could add more fire to this, just to stir things up a bit:
Those who can't grasp lua probably couldn't grasp our current config scheme
either. I reckon those would be better served with a shiny web-based
pointy-clicky config interface, and those people probably couldn't bother
less what was happening under the covers...
True, I haven't looked much a lua before and it does seems acceptable.
I never thought of current method of being difficult to understand.
Then again I am a programmer and been using apache since it's early
1.3 days so most of my troubles in the past are probably covered under
a think layer of dust.
But I don't see how good documentation and some very well thought out
examples could not fix this for lua.
But also try to remember a lot of users@ and IRC PITA's are because
different distro (*cough*debian) ship horribly modified configs to
make it easier for the users.
I fear that if we make a bad choose now, we will see more of these
horrors in the near future.
That being said that me talking and the user who wants a simple web
server/crazy person who tries to help people do that, the server
admin/developer in me screams yes yes yes! bye bye ugly mod_perl
driven config. (Well if we have DBD support at least :p)
/Nikke
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Niklas Edmundsson, Admin @ {acc,hpc2n}.umu.se | ni...@acc.umu.se
---
Acetone = What you do in exercise class...
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Re: [VOTE] release httpd mod_ftp-0.9.3 beta?
Trunk builds fine now. Just something that I noticed. when the u...@domainx is used and domainX doesn't exist it will default to the default vhost. could it be possible to make that configurable to say go to default or deny connection? ~Jorge On Sun, May 31, 2009 at 10:58 AM, William A. Rowe, Jr. wr...@rowe-clan.net wrote: Guenter Knauf wrote: William A. Rowe, Jr. schrieb: Are you certain NetWare should be building the ftp_lowportd.c? (It can, no, it cant. How can we workaround this? it seems that sys/un.h is found for unix pipe support). argh! That's the reason why the APR_HAS_ is defined! I see no related APR_HAS_ Have worked around this, testing explicitly for one of the variants of socket passing msghdr support. (Actually, someone who cares about the mod_proxy_fdpass should really borrow this code). Fixed several other [miss-]detections, give this another shot.
Re: [VOTE] release httpd mod_ftp-0.9.3 beta?
That would do just fine. Maybe worth documentation somewhere. Honestly it was a oh that would be usefull for a lot of users kind of idea that I didn't spend time researching much. Are there actually any user statistics for mod_ftp? ~Jorge On Sun, May 31, 2009 at 8:04 PM, William A. Rowe, Jr. wr...@rowe-clan.net wrote: Jorge Schrauwen wrote: Trunk builds fine now. Just something that I noticed. when the u...@domainx is used and domainX doesn't exist it will default to the default vhost. could it be possible to make that configurable to say go to default or deny connection? I don't want to solve in code what the code already solves. What about, in the default ftp vhost, using the VirtualHostByUser, configure for basic auth with an empty user list (or for your convenience you could have an admin here). Require valid-user at Location / and we should be done. In the named hosts, using VirtualHostByUser plus optionally the StripHostname feature, set the appropriate access control. How would that do for solving the puzzle?
Re: [VOTE] release httpd mod_ftp-0.9.3 beta?
~Jorge On Sat, May 30, 2009 at 2:27 AM, William A. Rowe, Jr. wr...@rowe-clan.net wrote: Guenter Knauf wrote: Sure that its possible to specify the full path at commandline, but tell me a reason why we should make it harder for users than needed? The question is; which forks are we accommodating? What scope? .1% of installed userbase? (whoops - better restore win9x quick!) Seriously, if someone is using the fork, and grabbing packages, they just grab the mod_ftp package, so no big deal. Totally cool with adding a note to README-FTP about the APXS=apxs2 trick for those affected. I'm for this as well. People using the modded distro packages will most likely also install mod_ftp from that distro. The people that use say a distro's 1.3 package or a alt vendor package in combination with a manual compile/vanilla implementation will most hopefully be smart enough to understand the little changes that are needed. Personally I think that if distro's want to modify httpd to fit their needs it also their job to modify modules to work with there modified version. I'm not saying we shouldn't make it easy to provide and alternative path for apxs it being a little config mod or be it a parameter. I'm not disagreeing that it's potentially stupid for us to ship 'apxs'. I'm disagreeing that the appropriate place to fix conventions is here. And if folks don't want to play in such an open ecosystem, there is next to nothing we are going to fix in this, but we don't have to become party to perpetuating it. Watching the good folks at users@, #httpd etc tear their hair out at vendor stupidity or cleverness is not 'fun'.
Re: [VOTE] release httpd mod_ftp-0.9.3 beta?
On Sun, May 31, 2009 at 12:06 AM, William A. Rowe, Jr. wr...@rowe-clan.net wrote: Jorge Schrauwen wrote: I'm not saying we shouldn't make it easy to provide and alternative path for apxs it being a little config mod or be it a parameter. Neither was I :) As Guenter pointed out, distros were forced to rename apxs to apxs2 because we failed to do so. But what about the distinction between apxs2 and apxs22? Or some apxs24 or apxs3 in the future? We should help people in this, but without distributors coming back and hollering whoa! problem! how do they expect to provide us with some standardized solution? So they each invent their own, and then gripe when accommodating each of their their forks is rejected by the project? Guenter - your first challenge on httpd trunk is to convince the project that /usr/bin/apxs for 2.4/3.0 would be a stupid mistake to repeat, so that we change our ways :) If your proposal involves naming it apxs2 or apxs3, then you might kill two birds in one stone. Personally I'd go for renaming (backwards aswel to apxs13 apxs20 apxs22 apxs30 ... and having apxs being a symlink of sorts like apxs -s 22 will set 22 as the default but also providing na one time overwrite something like apxs -v 22 will use it only for this runtime instance. Not ideal but it does provide a long term solution but probably not ideal.
Re: [VOTE] release httpd mod_ftp-0.9.3 beta?
Didn't have much time to tinker with it being exams and all but it fails to build for me. I do what I always do untar, ./configure.apxs, make, (make install) Below you'll find the failed output. I'm not sure when I have time to look into it. But I guess some feedback is better than no feedback. Jorge --- shirayuki mod_ftp # ./configure.apxs Configuring mod_ftp for APXS in /srv/httpd/bin/apxs rm -f *.o *.lo *.slo *.obj *.a *.la conftest_fchmod.c conftest_arpa_ftp_h.c conftest_netinet_ip_h.c *.loT conftest_fchmod conftest_arpa_ftp_h conftest_netinet_ip_h rm -rf .libs /srv/lib/build-1/libtool --silent --mode=compile gcc -g -O2 -pthread -DLINUX=2 -D_REENTRANT -D_GNU_SOURCE-I/srv/httpd/include -I. -I/srv/lib/include/apr-1 -I/srv/lib/include -prefer-non-pic -static -c conftest_arpa_ftp_h.c touch conftest_arpa_ftp_h.lo rm -f *.o *.lo *.slo *.obj *.a *.la conftest_fchmod.c conftest_arpa_ftp_h.c conftest_netinet_ip_h.c *.loT conftest_fchmod conftest_arpa_ftp_h conftest_netinet_ip_h rm -rf .libs /srv/lib/build-1/libtool --silent --mode=compile gcc -g -O2 -pthread -DLINUX=2 -D_REENTRANT -D_GNU_SOURCE-I/srv/httpd/include -I. -I/srv/lib/include/apr-1 -I/srv/lib/include -prefer-non-pic -static -c conftest_fchmod.c touch conftest_fchmod.lo /srv/lib/build-1/libtool --silent --mode=link gcc -g -O2 -pthread -L/srv/lib/lib -o conftest_fchmod conftest_fchmod.lo rm -f *.o *.lo *.slo *.obj *.a *.la conftest_fchmod.c conftest_arpa_ftp_h.c conftest_netinet_ip_h.c *.loT conftest_fchmod conftest_arpa_ftp_h conftest_netinet_ip_h rm -rf .libs /srv/lib/build-1/libtool --silent --mode=compile gcc -g -O2 -pthread -DLINUX=2 -D_REENTRANT -D_GNU_SOURCE-I/srv/httpd/include -I. -I/srv/lib/include/apr-1 -I/srv/lib/include -prefer-non-pic -static -c conftest_netinet_ip_h.c touch conftest_netinet_ip_h.lo rm -f *.o *.lo *.slo *.obj *.a *.la conftest_fchmod.c conftest_arpa_ftp_h.c conftest_netinet_ip_h.c *.loT conftest_fchmod conftest_arpa_ftp_h conftest_netinet_ip_h rm -rf .libs rm -f .deps Makefile Finished, run 'make' to compile mod_ftp Run 'make FTPPORT=8021 install' to install mod_ftp (The default FTPPORT is 21 if not specified) The manual pages ftp/index.html and mod/mod_ftp.html will be installed to help get you started. The conf/extra/ftpd.conf will be installed as an example for you to work from. In your configuration file, /srv/httpd/conf/httpd.conf uncomment the line '#Include conf/extra/ftpd.conf' to activate this example mod_ftp configuration. shirayuki mod_ftp # make Making all in modules/ftp make[1]: Entering directory `/srv/.src/modules/mod_ftp/modules/ftp' /srv/lib/build-1/libtool --silent --mode=compile gcc -g -O2 -pthread -DFTP_APXS_BUILD -DLINUX=2 -D_REENTRANT -D_GNU_SOURCE -I/srv/.src/modules/mod_ftp/modules/ftp -I/srv/.src/modules/mod_ftp/modules/ftp -I/srv/.src/modules/mod_ftp/include -I/srv/httpd/include -I. -I/srv/lib/include/apr-1 -I/srv/lib/include -prefer-pic -c ftp_commands.c touch ftp_commands.slo /srv/lib/build-1/libtool --silent --mode=compile gcc -g -O2 -pthread -DFTP_APXS_BUILD -DLINUX=2 -D_REENTRANT -D_GNU_SOURCE -I/srv/.src/modules/mod_ftp/modules/ftp -I/srv/.src/modules/mod_ftp/modules/ftp -I/srv/.src/modules/mod_ftp/include -I/srv/httpd/include -I. -I/srv/lib/include/apr-1 -I/srv/lib/include -prefer-pic -c ftp_data_filters.c touch ftp_data_filters.slo /srv/lib/build-1/libtool --silent --mode=compile gcc -g -O2 -pthread -DFTP_APXS_BUILD -DLINUX=2 -D_REENTRANT -D_GNU_SOURCE -I/srv/.src/modules/mod_ftp/modules/ftp -I/srv/.src/modules/mod_ftp/modules/ftp -I/srv/.src/modules/mod_ftp/include -I/srv/httpd/include -I. -I/srv/lib/include/apr-1 -I/srv/lib/include -prefer-pic -c ftp_filters.c touch ftp_filters.slo ftp_commands.c: In function ‘ftp_cmd_pass’: ftp_commands.c:1080: error: ‘ap_loaded_modules’ undeclared (first use in this function) ftp_commands.c:1080: error: (Each undeclared identifier is reported only once ftp_commands.c:1080: error: for each function it appears in.) ftp_commands.c:1083: error: ‘ap_top_module’ undeclared (first use in this function) make[1]: *** [ftp_commands.slo] Error 1 make[1]: *** Waiting for unfinished jobs make[1]: Leaving directory `/srv/.src/modules/mod_ftp/modules/ftp' make: *** [all-recursive] Error 1 --- ~Jorge On Fri, May 29, 2009 at 10:14 AM, William A. Rowe, Jr. wr...@rowe-clan.net wrote: mod_ftp fans; We seem to have identified and solved our remaining 0.9.2 beta issues, so it's time for another, perhaps the final try on the way to GA! Please fetch up the newly prepared mod_ftp-0.9.3.tar.gz (available now), or the win32/netware/os2 suitable package mod_ftp-0.9.3-crlf.zip (still needs to sync in the next hour) from: http://httpd.apache.org/dev/dist/mod_ftp/ review, take it for a spin, and cast your choice [ ] -1 for any release of 0.9.3 (regressed from 0.9.2?) [ ] +1 to release as 0.9.3-beta [ ] +1 to release as 0.9.3-beta, and ready to tag GA (1.0.0) Please let us know if you test the two significant
Re: mod_ftp alpha/beta?
I've been using it as fallback when I can't conenct to mine via webdav. So far it's working ok, even vhosts but thats still a bit tricky but works non-the-less. I'd love to see it included for a 2.2.x but 2.4.x would be nice aswel. ~Jorge On Tue, May 5, 2009 at 5:56 PM, William A. Rowe, Jr. wr...@rowe-clan.net wrote: Jim Jagielski wrote: I'd like to work on a mod_ftp release to go along with the 2.2.12 release... I think baselining mod_ftp for only 2.2.x makes sense, and I'd really like to get a release out. What's the status? I've done some prelim tests and they look good. See STATUS?
Re: what is in modules vs what is in the core
Maybe a more layered approach would be something to consider for 3.0? Seems to me that the layers and groups of modules keeps expanding and expanding. 2.0 - 2.2 had the whole auth move over so maybe it's time to rethink the current module system for 3.0? ~Jorge On Tue, Mar 31, 2009 at 4:25 AM, M. Brian Akins br...@akins.org wrote: On Mar 30, 2009, at 7:37 PM, Paul Querna wrote: mod_watchdog is the latest offender in a series of modules that expose additional functions to the API. (mod_proxy and mod_cache do too!) What happened to all functions that are not inside server/* must be either dynamic optional functions or hooks? Some modules (mostly 3rd party??) allow it either way - optional function or just linkage. I'm personally a fan of hooks and providers. (With providers, I usually just do the lookup once in, say, post-config, and cache the results in the subscribing module - this saves some hash lookups on potentially every single request.) As I hack on some lua stuff, it's useful to have the symbols for functions. That may just be because I'm lazy, because I could do optional function lookups in library opens, I suppose. OT, but I like my Lua glue in a lua module and just use require 'apache2.memcache' (or whatever) to do the linking. This works really well with per thread lua states that are all loaded at startup... (hint, hint) --Brian
Re: accept mod_fcgid codebase into httpd project
On Mon, Jan 12, 2009 at 12:59 PM, traw...@gmail.com wrote: On Jan 11, 2009 10:53pm, William A. Rowe, Jr. wr...@rowe-clan.net wrote: Based on the enthusiasm of the module authors to adopt the AL and offer the mod_fcgid code to the httpd community, please vote +/-1 [+1] Accept mod_fcgid into httpd not that my vote counts but I think mod_fcgid's inclusion in the main httpd will be a good think. +1 And Thanks! to the mod_fcgid author and contributors! +1 to this as wel!
Re: [VOTE] Release Apache HTTP server 2.2.11
Also note that the x64 versions of windows do run 32-bit binaries without a problem. I've been providing x64 binaries of httpd 2.2 because people want them. I've moved from running windows on my servers to running linux. Even an old 128mb, P3 800mhz will run linux + httpd without a hitch. I also like to see some nicer build stuff for windows. But if a change does happen (I'd like to see it in 2.3 rather than 2.2). As wrowe has pointed out to me in earlier discussions. The .net series of vs are horrible in upgrade/downgrade wise. It would be awsome to have a build platform thats cross platform like ant but for c(++) I'm not sure that exists though. Never look. As of now compiling x64 bit httpd binaries isn't easy. But it's doable. ~Jorge On Fri, Dec 19, 2008 at 9:01 PM, William A. Rowe, Jr. wr...@rowe-clan.netwrote: bing swen wrote: As made clear sometime earlier, Windows 2008 R2 will only have 64-bit versions. The clock is ticking Has built fine (with edits) from command line without visual studio, and .sln's won't be the sole mechanism as long as I have a veto; 1) MS needlessly introduces breaking changes into each successive VS product release in a vain attempt to lock-in and force-upgrade (e.g. the .vcproj formats, manifest etc etc), and 2) There's no way out of an .sln into a procedural makefile build. Not even cmake or msbuild, at least the last time I looked. It's lock-in, ergo it's locked out (as the sole resource). You are right, it's time to dump dsp/dsw but not because they will be replaced with vcproj/sln, although it would be nice to get there for all the reasons we discussed. Much like simplifying the 64 bit build (which you can already get out of APR, APR-util etc). Your last observation was fun... have you actually ran Microsoft Vista SP1 x64 edition on a collection of assorted hardware? As cool as it would be to replace 32 bit with only 64 bit binaries, there is a performance penalty and it will be years before this is robust enough for the vast majority. Notice 2008 Server R1 was released in 32 bits? Wouldn't have happened if the world was ready. Bill
Re: [VOTE] Release Apache HTTP server 2.2.11
Looks like you haven't run cvtdsp.pl to convert the vc6 dsp's to once that upgrade. There is a more detailed explenation here: http://www.blackdot.be/?inc=apache/knowledge/tutorials/x64 ~Jorge On Thu, Dec 18, 2008 at 10:14 AM, Bing Swen bs...@pku.edu.cn wrote: Jorge Schrauwen jorge.schrau...@gmail.com wrote on 2008年12月17日, 19:07 For the early httpd-2.2.x series it has compiled on Win64. Then again it's very picky in which platform you use. Win XP x64 + VS2005/8 works best. Vista x64 is has some problems with platform SDK (not sure they are fix now). How long will they be compilable? I don't know. I think it has more to do with the makefile(s) than with the code it self. There seems to be a bug in the project updating functions of VS2005/08: embedded \ char's in the .rc files always made a fatal error to the resource compiler (rc.exe), e.g., ... LONG_NAME=Apache HTTP Server ... If all the inner \ are replaced with \' (namely, quot; to apos;), then the updated project files (.vcproj) will be OK to compile. Was this part of the problems with the makefile(s)? Bing
Re: Revise VC6 .dsp files -- was: [VOTE] Release Apache HTTP server 2.2.11
IIRC there where problems with this. The update dsp doesn't compile clean on vc6. vc6 is still the compiler used for all office asf httpd binaries. ~Jorge On Thu, Dec 18, 2008 at 3:00 PM, Bing Swen bs...@pku.edu.cn wrote: Jorge Schrauwen wrote on 2008年12月18日 20:10 On Thu, Dec 18, 2008 at 10:14 AM, Bing Swen bs...@pku.edu.cn wrote: Jorge Schrauwen jorge.schrau...@gmail.com wrote on 2008年12月17日, 19:07 For the early httpd-2.2.x series it has compiled on Win64. Then again it's very picky in which platform you use. Win XP x64 + VS2005/8 works best. Vista x64 is has some problems with platform SDK (not sure they are fix now). How long will they be compilable? I don't know. I think it has more to do with the makefile(s) than with the code it self. There seems to be a bug in the project updating functions of VS2005/08: embedded \ char's in the .rc files always made a fatal error to the resource compiler (rc.exe), e.g., ... LONG_NAME=Apache HTTP Server ... If all the inner \ are replaced with \' (namely, quot; to apos;), then the updated project files (.vcproj) will be OK to compile. Was this part of the problems with the makefile(s)? Looks like you haven't run cvtdsp.pl to convert the vc6 dsp's to once that upgrade. There is a more detailed explenation here: http://www.blackdot.be/?inc=apache/knowledge/tutorials/x64 ~Jorge I already read your nice tutorial there, and many thanks. But I just meant whether it is possible to just revise the makefiles (VC6 .dsp files) in the official httpd Win32 release package to make the updated Win64 project files directly compilable? Bing
Re: Update on status of mod_wombat
I think to tie it to a version is bad too. And could be very confusing. On Wed, Dec 17, 2008 at 8:48 AM, Greg Stein gst...@apache.org wrote: I think it would be a bad idea to tie it to a specific version. On Tue, Dec 16, 2008 at 19:59, Brian McCallister bri...@skife.org wrote: Another suggestion from the lua mailing list, and not a bad one... On Tue, Dec 16, 2008 at 5:53 PM, Jeff Pohlmeyer yetanotherg...@gmail.com wrote: Just a thought... The Apache PHP module is named mod_php5 and a quick google search for mod_lua5 returned no results here. - Jeff
Re: [VOTE] Release Apache HTTP server 2.2.11
On Wed, Dec 17, 2008 at 9:01 AM, Bing Swen bs...@pku.edu.cn wrote: Jim Jagielski j...@jagunet.com wrote on 2008-12-14 23:24 On Dec 13, 2008, at 9:32 AM, Ruediger Pluem wrote: 2. A number of non binding positive votes and positive feedback. 3. Binding votes: 0 -1 0 +0 8 +1 (Colm, Sander Temme, Brad, Jim, Bill, Lars, Jeff, Ruediger) So the vote has passed. I will copy the release files to the dist directory now and give the mirrors about 24 hours to catch up. I plan to announce the release officially by tomorrow evening CET. Don't forget to update the various site files, announcements, etc... as of this morning, 'http://httpd.apache.org/' and 'http://httpd.apache.org/download.cgi' still refer to 2.2.10 with smatterings of 2.2.11 around It may seem to be an out of fashion question, but I hope anyone can give a clear answer: How long will we have a compilable Windows x64 httpd-x.y.z release? Infinitely long? ;-) Bing For the early httpd-2.2.x series it has compiled on Win64. Then again it's very picky in which platform you use. Win XP x64 + VS2005/8 works best. Vista x64 is has some problems with platform SDK (not sure they are fix now). How long will they be compilable? I don't know. I think it has more to do with the makefile(s) than with the code it self. ~ Jorge
Re: changing mod_wombat's name
I'd prefer mod_core_lua over mod_script_lua. I don't really see a problem with mod_luau either, LoadModule directives are usually added to the config if the module is built so I don't think typo's will be a big issue. ~Jorge On Wed, Dec 17, 2008 at 1:33 AM, Eric Covener cove...@gmail.com wrote: On Tue, Dec 16, 2008 at 7:17 PM, Greg Stein gst...@apache.org wrote: Yeah, that can be confusing with the natural language directives/concepts. mod_script_lua mod_embedded_lua (me likee this one) mod_core_lua? -- Eric Covener cove...@gmail.com
Re: changing mod_wombat's name
wouldn't something like mod_lang_lua be better. Since not all future modules could be script language. Then again mod_lang_xx does look a bit odd. ~Jorge On Tue, Dec 16, 2008 at 10:46 PM, Graham Leggett minf...@sharp.fm wrote: Graham Dumpleton wrote: Given that there could be a class of such scripting language modules over time, why not: mod_script_lua to make it more clear for what purpose it may be. Then fits in with auth and proxy related modules having common prefix. +1. Regards, Graham --
Re: todos for 2.3.1-alpha
On Sat, Dec 13, 2008 at 6:10 PM, Frank fr...@x09.de wrote: Paul Querna wrote: [...] Anything else anyone thinks would be good to get in? I would like to see a better ErrorLog-handling/implementation. It should be similar to the LogFormat/CustomLog! There are others who want this too: https://issues.apache.org/bugzilla/show_bug.cgi?id=29190 (I wrote a patch for Apache which writes the servername in front of each error line so I can use a central errorlog file for solving the problem with the file descriptors. But a more flexible way should be implemented.) https://issues.apache.org/bugzilla/show_bug.cgi?id=29538 would be nice, too. Have fun, frank Speaking of logs. Maybe a system like we have the auth(n|z) now be used too. Make it pluggable. Say a file version, maybe one that logs to a db. A syslog one... then again this maybe should go in trunk and no 2.3.x series. I was thinking something like that could come in handy when dealing with a lot of host. (you could easly export logs per host from a table ;)) Just my 2 Cents
Re: changing mod_wombat's name
On Mon, Dec 8, 2008 at 9:04 AM, Roy T. Fielding [EMAIL PROTECTED] wrote: On Dec 7, 2008, at 1:07 PM, Paul Querna wrote: Brian McCallister wrote: I know some folks are attached to the wombat moniker, but the name is likely to confuse users, particularly now that it is in trunk. The obvious name, mod_lua, is a bit tricky as there are about half a dozen projects named mod_lua -- most of which are dead. I don't have a really good alternative, which is why the working name mod_wombat came into being, but I think leaving that name will cause user confusion. +1 to renaming, but I'm not sure we can or should call it mod_lua. Any other ideas? mod_luau http://en.wikipedia.org/wiki/Luau +1 on mod_luau, I like it! Roy
Re: [VOTE] Release Apache HTTP server 2.2.11
Custom compile on Gentoo (x86) +1 ~Jorge On Sat, Dec 6, 2008 at 11:04 PM, Res [EMAIL PROTECTED] wrote: On Sat, 6 Dec 2008, Ruediger Pluem wrote: +1 Tested on the following environments: Solaris 8 SPARC Solaris 9 SPARC Solaris 10 SPARC Red Hat AS 4 32 Bit (x86) Red Hat AS 4 64 Bit (x86_64) Red Hat AS 5 32 Bit (x86) Red Hat AS 5 64 Bit (x86_64) SuSE Linux 10.2 32 Bit (x86) SuSE Linux 11.0 32 Bit (x86) SuSE Linux 10.1 64 Bit (x86_64) +1 Slackware 12.0 (x86) Slackware 12.1 (x86) -- Res If you are not part of the solution, then you are part of the problem!
Re: changing mod_wombat's name
+1 on renaming. I still have to look up what it is every now and then. (Mostly due to forgetting what it does all the time though) mod_lua_handler, mod_lua_config meh I'm not good with names. metal note: look at lua and mod_soonnottobewombat to replace to replace buggy mod_perl stuff. ~Jorge On Sun, Dec 7, 2008 at 11:36 PM, Tony Stevenson [EMAIL PROTECTED] wrote: Paul Querna wrote: Brian McCallister wrote: +1 to renaming, but I'm not sure we can or should call it mod_lua. Any other ideas? mod_pony:-) Cheers, Tony
Re: Intent to Roll 2.3.0-alpha
mod_perl comes to mind too. To a lesser extend mod_security and mod_macro. ~Jorge On Fri, Nov 28, 2008 at 10:06 PM, Ruediger Pluem [EMAIL PROTECTED] wrote: On 11/28/2008 06:58 PM, Sander Temme wrote: On Nov 28, 2008, at 9:04 AM, Paul Querna wrote: FYI, I intend to roll 2.3.0-alpha, our first release from trunk in about 3 years, on Saturday December 6th. +1, let's get that code out there. As part of this process, I would like us (the group) to identify *early* which third party modules are popular with our userbase, and pro-actively approach their vendors so that they know what we're doing. Then they can make their plans to release without being blindsided. Off the top of my head I'm thinking: * PHP * Oracle (WebLogic) * Breach (ModSecurity) Let's throw this on the user list once the Alpha is out and see what's important to them. +1 to this approach. Regards Rüdiger
Re: Time for 2.2.11?
I'd prefere to have stable bug free (well as little as possible) release, New feature are nice, but they can wait IMHO. Just my 2 cents ~Jorge On Sat, Nov 15, 2008 at 9:50 PM, Ruediger Pluem [EMAIL PROTECTED] wrote: Not that much time has passed since we released 2.2.10 (one month), but I would like to see a release of 2.2.11 in the near future. Why? 2.2.10 has two regressions, one against 2.2.8 (crashes caused by the proxy) which is already backported and one against 2.2.9 (errors in openssl detection) which is currently proposed for backport and misses two votes. There are two further changes in the STATUS file that only miss one additional vote. With these 3 changes in the pipeline and the 10 changes already done for 2.2.11 I think we have enough stuff for a release given the two regressions above. I even volunteer to be the RM for this release and if the remaining proposals get in I would like to TR on 29th / 30th of November and release on 6th / 7th of December if the voting passes. And yes I know some of us will be disappointed that some things will miss the boat again (especially SNI), but they wouldn't be in a 2.2.x release even if we do not release 2.2.11 at the beginning of December. Opinions? Regards Rüdiger
Re: httpd win64 binaries
On Mon, Nov 3, 2008 at 8:10 AM, William A. Rowe, Jr. [EMAIL PROTECTED] wrote: Jorge Schrauwen wrote: The subject of not having an official binary package was brought up. We couldn't think of a reason why not except no body wants or has the time to do it. That's not it. The problem is MS's creation. We can either ship an 'official' msvcrt.dll based, DDK-built flavor, or the crap of the month 2005 or 2005sp1 or 2008 or 2008sp1 binary. Let's face it, flavor of the week doesn't work for an approach to a C runtime. Now that you mention it I do seem to vaguely remember something about this. So unless the MS gets there act together (which I doubt will happen in anytime soon) we won't see any 64-bit binaries? I'm likely to ship that DDK built flavor if only to help ensure compatibility, and let the Studio team know that they don't know what they are doing. They deliver a fun product for building something. I know, I used it almost for 2 decades. So selecting a version that is most popular say 2005(sp1) and only using that one is out of the question? They are entirely clueless at delivering a product to be used across multiple developers from multiple organizations to accomplish multiple purposes. They just can't grok that much multiplicity, and observe the central MS tenant of forcing to upgrade early and upgrade often. This isn't compatible with open source binaries. Just look at how frequently gcc is willing to bump the ver major like next to never. But I have to agree, MS's vs 2005+ series is a mess with all the .manifest and .local and bah! ~Jorge
Re: httpd win64 binaries
On Mon, Nov 3, 2008 at 10:23 AM, Bing Swen [EMAIL PROTECTED] wrote: Jorge Schrauwen [EMAIL PROTECTED] wrote on 2008-11-3 16:26 On Mon, Nov 3, 2008 at 8:10 AM, William A. Rowe, Jr. wrote: Jorge Schrauwen wrote: The subject of not having an official binary package was brought up. We couldn't think of a reason why not except no body wants or has the time to do it. That's not it. The problem is MS's creation. We can either ship an 'official' msvcrt.dll based, DDK-built flavor, or the crap of the month 2005 or 2005sp1 or 2008 or 2008sp1 binary. Let's face it, flavor of the week doesn't work for an approach to a C runtime. Now that you mention it I do seem to vaguely remember something about this. So unless the MS gets there act together (which I doubt will happen in anytime soon) we won't see any 64-bit binaries? Though we are eager to see an 'official' 64-bit Windows httpd release, but if not binaries, why shouldn't there be an x64 configured Apache.sln? It will be already great to let people have the chance to do their own x64 compilation. Currently there is only a .dsw and no sln's, they get generated on import. For some project on import there is a x64 platform available but not all. I'm not sure how doable that would be? If it was easy I'm sure someone (wrowe) would probably have done this already. Easiest way to do it with the current dsw/sln is to remove the project that have and x64 targets, then create a new x64 target for the entire solution. It was made clear that 32-bit will soon be over at the Windows server end (http://blogs.technet.com/windowsserver/archive/2008/10/28/announcing-windows-server-2008-r2.aspx). I guess most of us still think that Windows Server remains as an important platform for Apache. So it's really time to make this little step further. So selecting a version that is most popular say 2005(sp1) and only using that one is out of the question? Jorge's Win64 binaries already seem to work perfectly on mainstream Windows versions. Shouldn't it be able to improve to be offical? (I just found it can not load some modules built with VS005/Win008, though). I compiled them on vs2008 IIRC (not sure only boot into the vm when need to compile) Sadly the exact same version is needed or else it refuses to load. That is what wrowe mentioned above with all the minor version bumps here and there. Bing Jorge
Re: httpd win64 project sources/makefiles [was:...binaries]
cmake seems very interesting. I'd like to help if you go that path, not sure I'll be of much use though. ~Jorge On Mon, Nov 3, 2008 at 6:42 PM, Roy T. Fielding [EMAIL PROTECTED] wrote: On Nov 3, 2008, at 6:06 AM, Marc Noirot wrote: What about going one step further and using a tool able to generate Makefiles and IDE files for [name some of your favorite IDEs] ? I'm thinking about something like CMake ... http://lwn.net/Articles/188693/ http://www.cmake.org/ +1 But it still requires folks to do the work. Hackathon? Roy
httpd win64 binaries
Hi All, I was running a bit late about compiling the 64-bit windows binaries I have on my site this month and mentioned on #apache-helpdesk how much a pain it was. The subject of not having an official binary package was brought up. We couldn't think of a reason why not except no body wants or has the time to do it. Today I was checking some stats on my server and i though i'd share them: Filename - downloads - last download httpd/httpd-2.2.4_x64.exe 4859 2008/02/02 10:37:53 httpd/httpd-2.2.9-win64.zip 2666 2008/10/26 12:10:08 httpd/httpd-2.2.8-win64.zip 2181 2008/06/18 12:21:25 httpd/httpd-2.2.10-win64.zip 186 2008/11/02 22:59:47 httpd/httpd-2.2.9-win64_debug_symbols.rar 296 2008/10/25 21:20:37 httpd/httpd-2.2.8-win64_debug_symbols.zip 226 2008/06/18 12:21:32 httpd/httpd-2.2.10-win64_debug_symbols.zip 21 2008/11/02 08:59:34 httpd/mod_security2.1.1_x64.zip 1444 2008/11/02 08:59:57 httpd/mod_auth_xml_x64.zip 1408 2008/11/02 09:00:14 httpd/mod_jk1.2.22_x64.zip 1356 2008/11/02 09:00:04 httpd/mod_macro1.1.8_x64.zip 948 2008/02/02 07:44:45 httpd/mod_log_rotate_x64.zip 763 2008/11/02 09:00:21 httpd/mod_macro1.1.10_x64.zip 400 2008/11/02 08:59:49 I'm not sure what the 32-bit binaries have as download count but I think around 2000-2500 isn't bad for binaries I host on my personal website*. So the question is... why are there no official binaries? There definitely is some interest in this. Also the fact that people mail and complain why I haven't released the latest version when I'm late seems to suggest they do want them bad and they are to lazy or can't compile them, themselves. * sadly these binaries aren't complete and things like the apr-util mysql driver are still missing. mod_deflate and mod_ssl are included though. Jorge Schrauwen
Re: Simple MPM is in trunk
On Thu, Oct 30, 2008 at 5:37 AM, Bing Swen [EMAIL PROTECTED] wrote: Paul Querna wrote on 2008-10-30 12:10 Bing Swen wrote: Paul Querna wrote on 2008-10-28 15:12 Hope you've included 64-bit Windows in mind. Make x64 Windows a first-class citizen in httpd-2.4.x, please. How is it not a first class citizen in 2.2.x? Here are some reasons: 1. Currently Win-x64 compilation is a painstaking mission (hopeless for us), still no go to a 64-bit httpd.exe; I have to admit it isn't easy to do so. But it certainly is possible! Due to lack of time on my part I've not updated the httpd wiki but you can find how to do it here: http://www.blackdot.be/?inc=apache/knowledge/tutorials/x64 First few times are the hardest but once you setup a nice build environment its all good. Vista + vs 2005/2008 is generally bad. XP x64 + 2005 currently works the best, although 2008 works too. If you can't be bothered with the trouble, there are unofficial binaries on there too if you want to play with it. 2. Many stock modules have no 64-bit configuration. Again it's a matter of recompiling, most windows users are spoiled and thing everything comes in nice binaries. libphp5, mod_macro, mod_jk, mod_security,... can all be recompiled for 64-bit, most are easier to do than httpd itself. 3. For some that compiles, there are lots of warnings of dangerous conversions. Win-64 uses P64 (only pointers are 64 bits), instead of PL64 like Linux. 4. Suboptimal network i/o and so second-class performance. Native support of IOCP (completion port) needs a mapping from requests (not connections) to worker threads, so requires httpd to do some connection scheduling (suspendable connections as discussed before). Bing Personally I'd love to see the httpd project release 64-bit binaries themselves. But it's a lot of work for not much gain!* * tests with the early 2.2 branch show little to no improvements. ~Jorge
Re: Simple MPM is in trunk
On Thu, Oct 30, 2008 at 10:44 AM, Bing Swen [EMAIL PROTECTED] wrote: Jorge Schrauwen [EMAIL PROTECTED] wrote on 2008-10-30 17:03 On Thu, Oct 30, 2008 at 5:37 AM, Bing Swen [EMAIL PROTECTED] wrote: Paul Querna wrote on 2008-10-30 12:10 Bing Swen wrote: Paul Querna wrote on 2008-10-28 15:12 Hope you've included 64-bit Windows in mind. Make x64 Windows a first-class citizen in httpd-2.4.x, please. How is it not a first class citizen in 2.2.x? Here are some reasons: 1. Currently Win-x64 compilation is a painstaking mission (hopeless for us), still no go to a 64-bit httpd.exe; I have to admit it isn't easy to do so. But it certainly is possible! Due to lack of time on my part I've not updated the httpd wiki but you can find how to do it here: http://www.blackdot.be/?inc=apache/knowledge/tutorials/x64 First few times are the hardest but once you setup a nice build environment its all good. Vista + vs 2005/2008 is generally bad. XP x64 + 2005 currently works the best, although 2008 works too. If you can't be bothered with the trouble, there are unofficial binaries on there too if you want to play with it. 2. Many stock modules have no 64-bit configuration. Again it's a matter of recompiling, most windows users are spoiled and thing everything comes in nice binaries. libphp5, mod_macro, mod_jk, mod_security,... can all be recompiled for 64-bit, most are easier to do than httpd itself. Thanks for the nicely presented tutorial. I'll try to follow it and to understand what that 600+ PERL lines have fixed. So we have to get AWK, Bison, Flex and Sed to work, which are not required for a 32-bit build. And, we need a Perl Interpreter to run some magic conversions to get it built. That already made Win-x64 httpd a second-class citizen;) the perl file doesn't do it's job completely though, you still need a modified Makefile.win to fix some odd x64/release stuff that it wants in release. biggest problem atm is getting the apr dbd drivers for mysql and such. (never got that to work) 3. For some that compiles, there are lots of warnings of dangerous conversions. Win-64 uses P64 (only pointers are 64 bits), instead of PL64 like Linux. 4. Suboptimal network i/o and so second-class performance. Native support of IOCP (completion port) needs a mapping from requests (not connections) to worker threads, so requires httpd to do some connection scheduling (suspendable connections as discussed before). Bing Personally I'd love to see the httpd project release 64-bit binaries themselves. But it's a lot of work for not much gain!* * tests with the early 2.2 branch show little to no improvements. The improvement is httpd's virtual memory -- and actually very significant: we need to map a 500+ GB index into the memory space of httpd's child process. 64-bit space is our only choice;) Well a proxy with a mem_cache would definatly benifit from it. Bing
Re: MPMs, COW vs Child Process Spawning
On Wed, Oct 29, 2008 at 8:28 PM, Graham Leggett [EMAIL PROTECTED] wrote: Paul Querna wrote: One of the things I would like to do on the Simple MPM is unify how child processes are created on win32 and unix. On Win32, there is no fork, so roughly speaking what the current winnt MPM creates a new process, and feeds the configuration over a pipe to the new child. On Unix, all of the current MPMs use fork, and do not execute a new process, but instead then drop privileges and continue running. What I would like to do, is change Unix to use the same pattern as on Windows. Hmmm. I think for a large configurations, the copy on write is a significant optimisation - you can have large numbers of processes, and a large configuration, and get away with it, as practically the configuration is only memory resident once. I think it would be important to still support both, but certainly the code to support both shouldn't be at all complex. Perhaps the choice of which to choose could be configurable, so that Leopard users could choose config via pipe. If you are going to implement both methodes... fork() should be used and exec and pipe the config as a fallback. Then I know nothing about mpm's so I'll keep quite now. Although the MPM should be simple, it should ideally not be so simplified to become simplistic. Regards, Graham -- ~ Jorge
Re: [VOTE] Release Apache HTTP server 2.2.10
Running stable in a production environment here. Haven't notice any problems +1 Jorge
Re: Apache httpd 2.2.10 test tarballs available...
Running fine for 1 day on gentoo. Can't test on windows due to having no machine available. ~Jorge On Wed, Oct 8, 2008 at 3:33 PM, Eric Covener [EMAIL PROTECTED] wrote: On Wed, Oct 8, 2008 at 9:17 AM, Ruediger Pluem [EMAIL PROTECTED] wrote: On 10/07/2008 08:37 PM, Jim Jagielski wrote: ... at the usual location: http://httpd.apache.org/dev/dist/ The availability of these test tarballs does not constitute an official release, however please download and test as a VOTE will be called for in the next few days regarding their release. +1 sles9/s390 (31-bit) all tests pass sles9/ppc (32-bit) all tests pass solaris 10/amd64 (64-bit, sun studio) all tests pass -- Eric Covener [EMAIL PROTECTED]
Building minimal (static) httpd
Hi There was a discussion on IRC on building minimal static httpd to reduce memory footprint. You need a lot of --disable-xyz to do this. Would it be a lot of work to include something like --minimal-static ? This may also cater to people who want a simple webserver that only does some static things. It could be build without much hassle. If nobody has time for this could someone provide some tips on where I should look to create a patch myself? So I can submit it (once I find time)? Kind regards ~Jorge
Re: Dropping mod_sed into /trunk/ ?
On Thu, Aug 21, 2008 at 1:53 PM, Jeff Trawick [EMAIL PROTECTED] wrote: On Wed, Aug 20, 2008 at 6:53 PM, Nick Kew [EMAIL PROTECTED] wrote: Any thoughts on dropping it in to trunk Is it best to preserve the current files/filenames (sed.h, libsed.h, sed0.c, etc.) to better reflect the history of that code, or should the files be combined/renamed to something that makes more sense for an Apache module that shares space with a lot of other modules? (I'm assuming this goes into modules/filters and not its own modules/sed.) Renaming them to fit better in for the apache file tree seems a good idea. If its not done it will probably get done at some point in the future anyway. ~Jorge
Re: SNI in 2.2.x (Re: Time for 2.2.10?)
I like the idea of using --with-SNI and labeling it as experimental. Maybe leave it of by default though? ~ Jorge On Wed, Aug 20, 2008 at 1:10 PM, Nick Kew [EMAIL PROTECTED] wrote: On Wed, 20 Aug 2008 12:06:33 +0200 Oden Eriksson [EMAIL PROTECTED] wrote: FYI: This patch is applied in Mandriva Linux. Any feedback? Bug reports coming from their users? If you'd said Debuntu or Deadrat+family, we might infer a user community big enough to rely on (FSreasonableVO rely). Not sure about Mandriva, but it's surely better than nothing. It seems clear that users *really* want it. I'd say that adds weight to the argument for including it and taking the risk. It might be worth a --with-SNI configuration option, which would label it as an experimental feature. -- Nick Kew
Re: WebDav MOVE/COPY between servers
Hi, Something like FXP (for ftp server) for WebDav would indeed be nice. Although if you are looking to syncronize servers (not sure you are though) rsync may be a better way. Jorge On 7/2/08, Rafa%u0142 [EMAIL PROTECTED] wrote: I imagine most will allow copying to and from local file systems... so you on your way. My purpose is to get rid of it in some cases. For example: I have my client system, and 2 webdav servers (dav1, dav2). I want to be able to copy/move files between dav1 and dav2 without copying them first to my client system. And I want to do it by Webdav commands, not by adding some other programs to servers. Best regards Rafał Malinowski Przedstawienie MEWA w wykonaniu Sanktpetersburskiego Teatru Baletu Borisa Ejfmana 17 lipca, godz.20:30 Opera Leśna-Sopot. Czytaj więcej http://klik.wp.pl/?adr=http%3A%2F%2Fcorto.www.wp.pl%2Fas%2Feifman.htmlsid=401 -- ~Jorge
Re: [VOTE] initial release of httpd-mod_ftp-0.9.0
Compiles fine and is working as before on gentoo... named vhosting still broken though [ X ] +1 to release as 0.9.2-beta ~Jorge On Sat, Jun 21, 2008 at 9:17 AM, Takashi Sato [EMAIL PROTECTED] wrote: On Tue, 17 Jun 2008 16:43:14 -0500 William A. Rowe, Jr. [EMAIL PROTECTED] wrote: [ ] -1 for any release of 0.9.2 [ ] +1 to release as 0.9.2-alpha [ ] +1 to release as 0.9.2-beta [ ] +1 to release as 0.9.2-beta, and ready to tag GA (1.0.0) -0 ftp_commands.c: In function 'ftp_cmd_pbsz': ftp_commands.c:1706: warning: comparison is always false due to limited range of data type If 'arg' is 2147483647 on the sizeof(int) == 4 == sizeof(long) system, fc-pbsz == LONG_MAX. But on the sizeof(int) == 4 sizeof(long) system, fc-pbsz != LONG_MAX. I have not read the code deeply, but I think this is not quite dangerous. There is no code using pbsz. I have found other assignments of resutl of strtol to int. mod_ftp.c line 406 *(int *) ((char *) fsc + offset) = strtol(arg, endptr, 10); line 436 umask = strtol(arg, endp, 8); line 459 umask = strtol(arg, endp, 8); My environment: FreeBSD 7-STABLE AMD64 gcc version 4.2.1 20070719 [FreeBSD]
Re: [RESULT] (Was: Re: [VOTE] Release Apache HTTP Server 2.2.9)
I'd say tomorrow so most mirrors will be synced by then... unless they sync very fast... no idea how fast that is. ~Jorge On Fri, Jun 13, 2008 at 9:12 PM, Jim Jagielski [EMAIL PROTECTED] wrote: The tarballs and site files are being pushed to the mirrors... Announce tonight or tomorrow??
Re: [VOTE] Release Apache HTTP Server 2.2.9
On Wed, Jun 11, 2008 at 5:22 AM, William A. Rowe, Jr. [EMAIL PROTECTED] wrote: Jim Jagielski wrote: Your votes please; +/-1 [+1] Release httpd-2.2.9 as GA I'll rely on others to review linux, solaris, et al, but based on Win32 I'm very happy and just waiting for feedback from my prior questions to post up the various files. Yes, windows seems fine... didn't test with ssl though. -- ~Jorge
Re: [VOTE] Release Apache HTTP Server 2.2.9
Ok did a new build with openssl on vs 2008 on vista. It still give me hell over ipv6... there is a patch that fixes it! https://issues.apache.org/bugzilla/attachment.cgi?id=21320action=edit with this patch it works fine following the basic steps of converting the source (lineends.pl), perl cvtdsp.pl -2005 devenv Apache.dsw (to get command line building to work with vs2008) for that point on it compiles fine from command line. I've placed my binaries here for anyone that wants to do some heavier testing on them (will be gone tomorrow): *http://cygnus.gotdns.org/ (note: pdb's are included - very slow upload... home server)* I only tested the out of box config. Jorge On Wed, Jun 11, 2008 at 10:08 AM, Jorge Schrauwen [EMAIL PROTECTED] wrote: On Wed, Jun 11, 2008 at 9:16 AM, Issac Goldstand [EMAIL PROTECTED] wrote: Jim Jagielski wrote: Test tarballs for Apache httpd 2.2.9 are available at: http://httpd.apache.org/dev/dist/ Your votes please; +/-1 [ ] Release httpd-2.2.9 as GA +1 Tested prefork + worker on linux with no problems. If I get a chance to test win32 before the vote closes, I will, but based on Jorge's tests + Bill's satisfaction with win32, I'm happy as long as noone -1s it. I did have some problems with using vs 2008... I had to grab back to 2005. I'll give it a spin with ssl later this evening if I got time. Issac -- ~Jorge -- ~Jorge
Re: Tagging 2.2.9...
Will try to test it tomorrow... win or linux? I can do both but will only have time to give it a quick peak on one (exames) On Tue, Jun 10, 2008 at 10:33 PM, Jim Jagielski [EMAIL PROTECTED] wrote: Still waiting for the sync... I had thought it was every hour... :/ On Jun 10, 2008, at 3:29 PM, Jim Jagielski wrote: 2.2.9 is tagged and rolled... Once www syncs with people, I'll provide the URL and start the voting On Jun 10, 2008, at 1:44 PM, Jim Jagielski wrote: I am tagging 2.2.9 in 1-2 hours... -- ~Jorge
VirtualHostMysql no hosted on google code... wiki safe?
Hi docs and dev list, In follow up to http://www.gossamer-threads.com/lists/apache/docs/350946 I posted this on the docs list: http://www.gossamer-threads.com/lists/apache/docs/351355 I still haven't gotten a reply or comments on this. Since its been quite a while I though i'd post it again and hopefull this time somebody will reply. Kind regards Jorge Schrauwen (sjorge on #apache)
Re: 2.2.9
On Tue, May 6, 2008 at 4:36 PM, Plüm, Rüdiger, VF-Group [EMAIL PROTECTED] wrote: -Ursprüngliche Nachricht- Von: Jim Jagielski Gesendet: Dienstag, 6. Mai 2008 15:51 An: dev@httpd.apache.org Betreff: Re: 2.2.9 I'm back from a few days away and offline, and like to get the momentum for 2.2.9 back up. 2 main things: 1. There are a number of backport proposals looking for and waiting for a 3rd +1... if you have time to look/review/vote, that would be good. 2. Consensus on whether we ship with APR 1.2.x or 1.3.x... My pref would be 1.3. Ship with 1.3, but do not make it depend on 1.3 yet. This makes it easy to swap in 1.2.x again if it turns out that there is something nasty in 1.3. We can can make it dependant on 1.3 in 2.2.10 or 2.2.11 depending on our experience. Regards Rüdiger I really like this proposal (my non counting +1 on this) -- ~Jorge
Re: Apache 3.0
Just out of curiosity... will 3.0 still be a fresh start or will the core of 2.3 be used? On Sun, Apr 13, 2008 at 8:31 AM, Roy T. Fielding [EMAIL PROTECTED] wrote: On Apr 12, 2008, at 7:10 PM, Paul Querna wrote: For those who were not there, slides from Roy's keynote at ApacheCon EU: http://roy.gbiv.com/talks/200804_Apache3_ApacheCon.pdf heh, good thing I managed to get the Internet connection to work long enough for the upload. The only reply I can really come up with is: Patches Welcome. Patches? We don't need no stinkin' patches. I don't agree with, or disagree with all of the topics Roy discusses, and I do think we should focus more on 'fun' things, but I'm not sure we have an active enough community to really toss everything out, and plunge head first into a 3.0 development sprint. We don't have to. The point is that we should stop worrying about what we have the time to do and just let whoever does have the time to do, just do, in a way that we can make use of it when we do have the time. If the result isn't worth adopting, then we don't adopt it as Apache 3. We can steer the project wherever the majority want to go, but someone has to provide the wheels. Roy -- ~Jorge
Re: Apache 3.0
The slide showing the protocols httpd supports is kind of dead on. Personaly I like it that I'm able to serve http, ftp,... with one server package. If this is they way to go I think in 3.0 a entire new design would benifit and remove a lot of workaround in forcing the protocols to work with the httpd core. Although then it can no longer be httpd but apached or something in the like. Although dropping back to waka/http is an other options but I think some users will be dissapointed. Why run 4 different daemons while one will do? (ok I can think of a lot of reasons but I can think of some no to do it either.) Just my 2 cents Jorge On Sat, Apr 12, 2008 at 7:10 PM, Paul Querna [EMAIL PROTECTED] wrote: For those who were not there, slides from Roy's keynote at ApacheCon EU: http://roy.gbiv.com/talks/200804_Apache3_ApacheCon.pdf The only reply I can really come up with is: Patches Welcome. I don't agree with, or disagree with all of the topics Roy discusses, and I do think we should focus more on 'fun' things, but I'm not sure we have an active enough community to really toss everything out, and plunge head first into a 3.0 development sprint. -Paul -- ~Jorge
Re: mod_ftp trunk
Thanks tom, I'll give that a swirl later today or tomorrow depending on when I have time. On Tue, Apr 8, 2008 at 4:38 AM, Tom Donovan [EMAIL PROTECTED] wrote: Whoops! I forgot - there's one more bug - 44653, for a total of three bugs. Making these 3 changes should let you build mod_ftp trunk to use with httpd trunk. If you are building mod_ftp to use with httpd 2.2, you only need to fix 44653. -tom- Tom Donovan wrote: Jorge Schrauwen wrote: I'l actually not sure if mod_ftp has a separate list... so I'll send it here. On the page it says to fetch the trunk and build it. But the trunk doesn't build! Adding a message saying it won't build or maybe keep a prelease branch that does compile and work on trunk so there is a working or atleast compiling version availble. I entered two minor bugs proposed patches for mod_ftp (trunk) last week - see bugs 44746 44747. mod_ftp trunk builds runs OK for me on Windows with these changes. -tom- -- ~Jorge
Re: Apache -MySQL module ??
You can allready do that using mod_perl. It's not exactly what you are looking for but its a nice start: http://wiki.apache.org/httpd/ApacheVirtualHostMysql Jorge On Tue, Apr 8, 2008 at 2:45 PM, Agnello George [EMAIL PROTECTED] wrote: Hi I would like to know if any one has worked on Apache -MySQL module Just like bind-dlz , i would like to know if it is possible of instead of storing the location of the website directory path in files could it be stored in a MySQL database. And if possible how do i query to that database through the httpd.conf file . Thank you Awaiting your reply -- Regards Agnello Dsouza -- ~Jorge
mod_ftp trunk
I'l actually not sure if mod_ftp has a separate list... so I'll send it here. On the page it says to fetch the trunk and build it. But the trunk doesn't build! Adding a message saying it won't build or maybe keep a prelease branch that does compile and work on trunk so there is a working or atleast compiling version availble. -- ~Jorge
Re: Configuration Issues to Address [was Re: Dynamic configuration for the hackathon?]
... if we had a config finalize, modules who were prepared to declare their config (e.g. mod_vhost declaring the per-host directory merges completed) then as-root, we can finish these out, opening logs with full privileges. Other merges will happen at run time (or be optimized when we can accomplish this) per-request. So does a setup like this make it possible for the processes/thread handling the request to change to the correct UID/GID before reading/writing files? Just something that popped into my head when reading this. -- ~Jorge
Re: 2.4 (Was: Re: Configuration Issues to Address [was Re: Dynamic configuration for the hackathon?])
On Thu, Apr 3, 2008 at 4:31 PM, Mads Toftum [EMAIL PROTECTED] wrote: On Thu, Apr 03, 2008 at 10:06:50AM -0400, Jim Jagielski wrote: Time for a 2.4 release? I wouldn't mind pushing that along and get some of the feature-set of 2.4 out before we do too much ripping with the inevitable delays associated with that :) Is there really enough news in trunk to warrant the overhead of maintaining yet another branch? tbh. I'd much rather see work going towards 3.x ;) vh Mads Toftum -- http://soulfood.dk I'm wondering the same. -- ~Jorge
Re: Dynamic configuration for the hackathon?
Let me try and summarize this then: Problem: The httpd configuration is to static for some users (e.g. large host providers) they want to have a more dynamic system. Where they can configure things on a request basis and add vhosts and such without restarting httpd. Solutions propose: - lua in the core or atleast in a module - mod_perl Downside: - perl isn't very easy and userfriendly - overhead of having this be re-evaluated a lot - lue - users to lazy to learn new language I'm sure I missed a lot since I seem to be missing some older messages so feel free to ignore this add to it or whatever. -- ~Jorge
Re: Dynamic configuration for the hackathon?
On Tue, Apr 1, 2008 at 4:13 PM, Issac Goldstand [EMAIL PROTECTED] wrote: Jorge Schrauwen wrote: Solutions propose: - lua in the core or atleast in a module - mod_perl mod_perl exists already. We're looking to replace it because... (see below) I'm quite aware that it exists, I ment that it is a possible solution to the problem. (I'm actually using it... although restarts are still needed to load the new vhosts) Downside: - perl isn't very easy and userfriendly I think that the downside is the fact that perl interpreters suck up RAM, not the easiness factor. It's probably not significantly easier/harder than lua, but it's big and clunky Well perl did scare the *bleep* out of my class mates when they where looking what I was doing during the break. Then again, I do most of my system scripts in perl ^^ Issac -- ~Jorge
Re: Dynamic configuration for the hackathon?
I used to use mod_macro, then I moved to mod_perl but like you said. mod_perl is great (well, more okay than great) for dynamic configurations that change/get generated on start and not per request. A new more flexible alternative would be awsome. Jorge (on vacation) On Thu, Mar 27, 2008 at 8:58 AM, Torsten Foertsch [EMAIL PROTECTED] wrote: On Wed 26 Mar 2008, Akins, Brian wrote: There seems to be a demand for dynamic per-request configuration, as evidenced by the number of users hacking it with mod_rewrite, and the other very limited tools available. Modern mod_rewrite usage commonly looks like programming, but it's not designed as a programming language. Result: confused and frustrated users. This is what I had in mind when I suggested having Lua blocks of code. No need to invent a new language when a perfectly fine one exists... As Issac pointed out something similar can be done with Perl blocks at the cost of having mod_perl in core. Those are not evaluated evaluated per-request. But based on mod_perl there is Apache2::Translation that does per-request configuration. It hooks uri translation, maptostorage and fixup to do the job. Again it needs a perl interpreter in core and hence doesn't work well with threaded MPMs. So I was going to reimplement it based on mod_wombat some time this year. I just wanted to add these $0.02 to the discussion. Torsten -- ~Jorge
Re: Experience with Visual Studio 2008 Professional Edition
I've had no problems building with VC9 either, unless you do it on vista since the new PSDK updates some files and a small edit is needed. Also x64 building is out of the question for some reason OpenSSL/Zlib nor httpd itself want to compile at all. On Wed, Mar 5, 2008 at 10:12 PM, Harry Holt [EMAIL PROTECTED] wrote: How about SSL over mod_ldap? On Wed, Mar 5, 2008 at 2:38 PM, Issac Goldstand [EMAIL PROTECTED] wrote: Steffen wrote: Just to inform you. We at Apache Lounge done the first build with Visual Studio 2008 Professional Edition. SDK 6.1 (latest as today) 2.2.8 source (plus dso and fix for DOS-box) Openssl was build with VC8 Zlib was build with VC8 Changed in apr.hw (otherwise errors): #define _WIN32_WINNT 0x0600 Further no changes. IDE build goes fine with no errors. First impression: Apache runs fine on my XP box, including mod_ssl. Only mod_deflate was not loading. Rebuilding Zlib (ms-asm) with VC9 and then build mod_deflate again and it starts and works. Also all the modules build with VC8, like mod_security 2.5.0, mod_watch, mod_fcgid, mod_vieuw are running. Cool! Issac -- Harry Holt, PMP -- ~Jorge
Re: ping on mod_dns
If the mod_dns mentioned before is different from the code... may I sugest mod_named? since a lot of people would be famileir with a name like htat. On Feb 18, 2008 8:22 PM, Erik Abele [EMAIL PROTECTED] wrote: On 18.02.2008, at 20:03, Roy T. Fielding wrote: On Feb 9, 2008, at 4:21 PM, Issac Goldstand wrote: Any volunteers to import mod_dns so I can eventually start hacking at it again (topic came up at work recently and I have a couple of feature ideas that I'd like to work on, but really don't want to have to work in my old svn + port changes to asf svn too)? AFAIK, we finished with the red tape already (please tell me off- list if I'm wrong) Actually, I'd rather do that on-list so that more people know what is required. We already had the proposal and enough +1 votes to add mod_dns as a subproject. http://markmail.org/message/juhrpyxq635mhy6n The next question is about the intellectual property. ... See also the thread 'Issac Goldstand / mod_dns' on board@ for some info re paper-work (02/10/2008)... Cheers, Erik -- ~Jorge
Re: ping on mod_dns
true but like Roy said if mod_dns is allready in use a new name will need to be found no? On Feb 18, 2008 8:42 PM, Issac Goldstand [EMAIL PROTECTED] wrote: Jorge Schrauwen wrote: If the mod_dns mentioned before is different from the code... may I sugest mod_named? since a lot of people would be famileir with a name like htat. True, but that would break naming conventions: mod_smtp mod_ftp (mod_proxy_ajp, mod_proxy_http, mod_proxy_ftp) and even the included http module that handles http... -0 Issac -- ~Jorge
Re: ping on mod_dns
Me too, If this gets in experimental I'll probably give it a try sounds really interesting On Feb 10, 2008 2:16 PM, Dirk-Willem van Gulik [EMAIL PROTECTED] wrote: On Feb 10, 2008, at 1:21 AM, Issac Goldstand wrote: Any volunteers to import mod_dns so I can eventually start hacking at it again (topic came up at work recently and I have a couple of feature ideas that I'd like to work on, but really don't want to have to work in my old svn + port changes to asf svn too)? I'd be quite interested to see this go in as 'experimental' or similar. Dw. -- ~Jorge
Re: Pre-release tarballs: Apache httpd 1.3.41, 2.0.63 and 2.2.8
+1 on win32 for me if I could vote libaprutil is still set to x64 instead of win32 when compiling under 2008 but I take this will get fixed in the win32 src package multicast.c is still broken using vs 2008 with the latest platform SDK, vs 2005 with the older platform SDK works fine! (there is a patch for this... IIRC its also in apr trunk but it was laten when I was talking about this with wrowe I can't remember for certain) FWIW: BuildBin's installdir is still set to /apache2 instead of /apache22 not that will effect anything just something I noticed. The /machine not set warnings are still there aswel but again no problem here since it defaults to x86 modules compiled and working: - mod_perl - mod_macro - mod_fcgid - mod_ftp (compiles not tested) Jorge On Jan 11, 2008 5:33 AM, Paul Querna [EMAIL PROTECTED] wrote: Jim Jagielski wrote: Pre-release tarballs of Apache HTTP Server 1.3.41, 2.0.63 and 2.2.8 are available for download and test at: http://httpd.apache.org/dev/dist/ Their availability does not constitute an official release. However, please download and test. I will be calling for a release VOTE in the next 24-48 hours, at most. eos.apache.org and aurora.apache.org, the machines that host www.apache.org, and most TLPs, have both been upgraded to 2.2.8: http://www.apache.org/server-status They are also now running with the Event MPM, previously the Worker MPM was used. I used an APR and APR-Util snapshot, from their respective trunks, due to issues with mod_mbox performance, that have been fixed in apr-util trunk[1]. Both machines are Solaris 10/SPARC, and I ran into no major issues getting it all working. If you notice any issues with any apache.org sites, please let me know :-) Thanks, -Paul [1] - http://svn.apache.org/viewvc?view=revrevision=513046 -- ~Jorge
Re: [VOTE] Apache HTTP Server 1.3.41, 2.0.63 and 2.2.8
[] Apache HTTP Server 1.3.41 [] Apache HTTP Server 2.0.63 [+1] Apache HTTP Server 2.2.8 (win32 + mac) -- ~Jorge
Re: Pre-release tarballs: Apache httpd 1.3.41, 2.0.63 and 2.2.8
On 1/11/08, William A. Rowe, Jr. [EMAIL PROTECTED] wrote: Jorge Schrauwen wrote: libaprutil is still set to x64 instead of win32 when compiling under 2008 but I take this will get fixed in the win32 src package No; you set it; that is to say that visual studio is bugged, and VC6 .dsw did not specify per-project dependencies, VS .sln migration makes foolish associations. This is even true when I introduce x64 targets to all projects, it has nothing to do with the source .dsw/.dsp files. You need to update these; there may be a separate package that offers .sln's at some point to fix VS bugs, haven't decided. (The src package is intended to be built from exported .mak files). multicast.c is still broken using vs 2008 with the latest platform SDK, vs 2005 with the older platform SDK works fine! (there is a patch for this... IIRC its also in apr trunk but it was laten when I was talking about this with wrowe I can't remember for certain) It's also on apr branches but not yet released; https://issues.apache.org/bugzilla/show_bug.cgi?id=40398 the patch applied to apr was the Cleaner and not Dirtier flavor. It will hit the next 1.2.x apr release, I'd presume there will be one sooner or later. FWIW: BuildBin's installdir is still set to /apache2 instead of /apache22 not that will effect anything just something I noticed. Yup - no impact, not likely to change. The /machine not set warnings are still there aswel but again no problem here since it defaults to x86 or defaults to x64 using that compiler/linker. Again, goofy win32 behaviors, and can't be fixed without x64 + win32 (x86) targets which would permit compilation using two-different targets. It was more than I wanted to mess with for this point bump, but will probably get back to that issue over the next several weeks. I'd be willing to generate and package vs 2008 sln and fix the apr-util goofyness. Say if solution files are created... do we want different packages for 2005, 2008,...? 2008 is said to be compatible with 2005 but opening a 2005 sln in 2008 it still randomly changes settings and such. Say if I create such a extended package based on the office 2.2.8 win32 src do you think that could be useful? I can always place it on my own website for interested people but I suspect it won't get much attention there and won't be worth the hassle. -- ~Jorge
Re: Pre-release test tarballs of httpd 1.3.40, 2.0.62 and 2.2.7 available
On Jan 7, 2008 3:03 PM, Jim Jagielski [EMAIL PROTECTED] wrote: From what I can tell, all 3 versions should be not-released and we should instead move ahead with 1.3.41, 2.0.63 and 2.2.8 to address the current concerns... 1.3.41 looks releasable with the current state of HEAD. 2.0.63 requires one more vote for the ssl lib stuff 2.2.8 requires more testing/review of the drip-feed, chunked patches, as well as an update by Rüdiger concerning his optimization status. +1 on not-releasing and moving on to 1.3.41, 2.0.63 and 2.2.8 but only if its in within a short time span. -- ~Jorge
Re: Pre-release test tarballs of httpd 1.3.40, 2.0.62 and 2.2.7 available
On Jan 5, 2008 11:36 AM, Steffen [EMAIL PROTECTED] wrote:
It crashes when apr_bucket_alloc() is called by modules
and also when eg. EnableMMAP off is set:
\srclib\apr-util\buckets\apr_buckets_alloc.c
+ list 0x00b71f10 {pool=0x00b6ff08 allocator=0x freelist=0x
...} apr_bucket_alloc_t *
libaprutil-1.dll!apr_bucket_alloc(unsigned int size=40, apr_bucket_alloc_t
* list=0x00b71f10) Line 135 C
Any pointers on reproducing it... everything on my development config
seems fine and I'm not getting errors.
--
~Jorge
Re: Pre-release test tarballs of httpd 1.3.40, 2.0.62 and 2.2.7 available
That could explain why I'm not seeing it... I don't have
Win32DisableAcceptEx in there.
I'll report back later once I add it.
On Jan 5, 2008 1:08 PM, Steffen [EMAIL PROTECTED] wrote:
Looks like that it happens only when add Win32DisableAcceptEx to the conf.
Steffen
- Original Message -
From: Ruediger Pluem [EMAIL PROTECTED]
To: dev@httpd.apache.org
Sent: Saturday, 05 January, 2008 12:12
Subject: Re: Pre-release test tarballs of httpd 1.3.40, 2.0.62 and 2.2.7
available
On 01/05/2008 11:36 AM, Steffen wrote:
Building fine with GUI on VS 2005 out of the box.
With the shipped httpd.conf It works!
It crashes when apr_bucket_alloc() is called by modules
and also when eg. EnableMMAP off is set:
\srclib\apr-util\buckets\apr_buckets_alloc.c
+ list 0x00b71f10 {pool=0x00b6ff08 allocator=0x
freelist=0x
...} apr_bucket_alloc_t *
With an allocator set to NULL
libaprutil-1.dll!apr_bucket_alloc(unsigned int size=40,
apr_bucket_alloc_t
* list=0x00b71f10) Line 135 C
A longer stack trace would be helpful here.
Regards
Rüdiger
--
~Jorge
Re: Pre-release test tarballs of httpd 1.3.40, 2.0.62 and 2.2.7 available
Indeed with Win32DisableAcceptEx in there is bombs out :(
Same location as Steffen
On Jan 5, 2008 1:08 PM, Steffen [EMAIL PROTECTED] wrote:
Looks like that it happens only when add Win32DisableAcceptEx to the conf.
Steffen
- Original Message -
From: Ruediger Pluem [EMAIL PROTECTED]
To: dev@httpd.apache.org
Sent: Saturday, 05 January, 2008 12:12
Subject: Re: Pre-release test tarballs of httpd 1.3.40, 2.0.62 and 2.2.7
available
On 01/05/2008 11:36 AM, Steffen wrote:
Building fine with GUI on VS 2005 out of the box.
With the shipped httpd.conf It works!
It crashes when apr_bucket_alloc() is called by modules
and also when eg. EnableMMAP off is set:
\srclib\apr-util\buckets\apr_buckets_alloc.c
+ list 0x00b71f10 {pool=0x00b6ff08 allocator=0x
freelist=0x
...} apr_bucket_alloc_t *
With an allocator set to NULL
libaprutil-1.dll!apr_bucket_alloc(unsigned int size=40,
apr_bucket_alloc_t
* list=0x00b71f10) Line 135 C
A longer stack trace would be helpful here.
Regards
Rüdiger
--
~Jorge
Re: Pre-release test tarballs of httpd 1.3.40, 2.0.62 and 2.2.7 available
On Jan 5, 2008 5:26 PM, Steffen [EMAIL PROTECTED] wrote: With 2.2.7 on windows mod_perl is still not working, 2.2.4 was the latest version where mod_perl was working. mod_perl with Apache as service crashes when starting Apache. mod_perl with Apache cmd-line Apache starts but does not dipslay a page, no signs in the logs. mod_perl compiled fine over here! and is loaded... I don't have an extensive config though to test. I'm using an older perl compiled vs.net 2003. -- # Perl Configuration IfModule mpm_winnt.c LoadFile /perl/bin/perl58.dll /IfModule LoadModule perl_module modules/mod_perl.so IfModule mod_perl.c #perl startup modules PerlModule ModPerl::Util; PerlModule Apache2::RequestRec; PerlModule Apache2::RequestIO; PerlModule Apache2::RequestUtil; PerlModule Apache2::ServerRec; PerlModule Apache2::ServerUtil; PerlModule Apache2::Connection; PerlModule Apache2::Log; PerlModule Apache2::Const:common; PerlModule APR::Const:common; PerlModule APR::Table; PerlModule Apache2::compat; #PerlModule CGI; PerlResponseHandler ModPerl::Registry; /IfModule -- with that config it seems to work fine over here if you want I can send you my binary + perl binary. Rather as with 2.2.6 we prefer not to make again a patch for the Apachelounge community. Btw. mod_fcgid looks now ok. Yep working over here aswel! Steffen - Original Message - From: Jim Jagielski [EMAIL PROTECTED] To: [EMAIL PROTECTED]; dev@httpd.apache.org Sent: Friday, 04 January, 2008 21:00 Subject: Pre-release test tarballs of httpd 1.3.40, 2.0.62 and 2.2.7 available Apache HTTP Server fans, The latest versions of all 3 variants of Apache HTTP Server (1.3.40, 2.0.62 and 2.2.7) have been tagged. The test tarballs are available for testing and feedback at the below location. Everyone is reminded that this does not constitute an official release of these tarballs yet; assuming these pass muster, the hope and intent is to release and announce early next week. All files in: http://httpd.apache.org/dev/dist/ -- ~Jorge
Re: Pre-release test tarballs of httpd 1.3.40, 2.0.62 and 2.2.7 available
I just recompiled with that patch. The crashes with are now indeed gone! So all is good it seems :) On Jan 5, 2008 5:09 PM, Ruediger Pluem [EMAIL PROTECTED] wrote: Although I have limited knowledge in the Windows MPM the patch looks reasonable. I assume you have already tested that the crash now disappears with your patch added. Thanks for investigating. Regards Rüdiger -- ~Jorge
Re: Pre-release test tarballs of httpd 1.3.40, 2.0.62 and 2.2.7 available
On Jan 5, 2008 7:45 PM, William A. Rowe, Jr. [EMAIL PROTECTED] wrote: Tom Donovan wrote: Yes, the crash dissappears. I built with MS Visual Studio 8 on win2k and tested on win2k, winxp, and vista. ab -n 10 -c 100 http://localhost/large_file.html Where large_file.html is 200kb. No continued memory growth observed (after the first few seconds), so I don't think it is leaking allocators. Fantastic. Code drift between the Win9x case (now pretty much irrelevant) and WinNT disabling acceptex really is unacceptable now, but I don't want to touch the 2.0/2.2 code again if we can avoid it. Best solution is a refactoring which I might find a weekend for in the next month or so. I'm going to propose we dump DisableWin32AcceptEx syntax entirely in 2.4, and instead use our new friendly syntax; AcceptFilter http ex-data (current acceptex, plus some data) AcceptFilter https ex (current acceptex, but no data) AcceptFilter http none(vanilla accept) Isn't AcceptFilter http ex the default now? Wouldn't : AcceptFilter http none (current acceptex, no data) AcceptFilter http data (current acceptex + data) AcceptFilter http no-ex (vanilla accept) be better? Just my 2 cents Does this sound like the right approach before I start hacking anything? Bill -- ~Jorge
Re: [VOTE] initial release of httpd-mod_ftp-0.9.1
I actualy like that the status files are packed, why aren't they packed for the other packages? But I'd say do what the others do. On Jan 5, 2008 8:14 PM, William A. Rowe, Jr. [EMAIL PROTECTED] wrote: Guenter Knauf wrote: See http://svn.apache.org/repos/asf/httpd/mod_ftp/tags/0.9.1/STATUS-FTP first line of STATUS reads: MOD_FTP 3.0 STATUS: a little bit strange the 3.0 while the module has now 0.9.1 version Fixed. I would be happy to reroll without STATUS if people agree that it should be omitted; we don't actually package STATUS in other httpd related packages. WDYT? -- ~Jorge
Re: [VOTE] initial release of httpd-mod_ftp-0.9.1
Sounds good to me. I compiled a few 3rd party modules on windows and most are not intree compiling. So I don't see it as a big loss if mod_ftpd doesn't compile in tree on windows. On Jan 5, 2008 8:36 PM, William A. Rowe, Jr. [EMAIL PROTECTED] wrote: Guenter Knauf wrote: I got a few notes on this though: 1) in the 2.0 tree is there a loggers subfolder in the source tree? I'm not sure been a long time since I looked at it. 2) APACHE2_HOME points to the install dir of apache and not to the source IIRC? so there wouldn't be a modules subfolder there anyway. sorry, yes, this only works for in-tree compile; somehow we have not thought yet about this; its not only for mod_log_config.h , but also mod_dav.h, mod_proxy.h an probably some more module headers are missing in the installed include dir... perhaps we should think of a subfolder 'module_headers' or such, and move these headers to there, or at least create such a folder with install and copy the module headers there OK - here's my thought for 0.9.2 (not really a showstopper for this alpha release); * it's supposed to be as simple as copying over an existing httpd source tree. For win32, that means (minimum) you touch Apache.dsw and Makefile.win. Maybe ship those as a patch? It's 2 small adds each, so even without patch.exe it isn't going to be hard to do it. patch -p0 build/win32-ftp-in-tree.patch -- and you are good to go. * out of tree on unix requires ./configure-apxs, so add a corresponding configure-win.bat to configure the mod_ftp.dsp (and example mod) to compile against a certain APACHE tree. Sound good? Bill -- ~Jorge
