Re: Hackathon during Q1 2005?
On Sun, 12 Dec 2004 00:37:49 -0600, William A. Rowe, Jr. [EMAIL PROTECTED] wrote: (Actually - all of this Euro talk reminds me how less-than-optimal the west coast really is for European participants. The east coast seems like a short hop by comparison.) east coast sounds much better to this North Carolinian perhaps California is the place that would result in the most people on site; not many people are chiming in on this thread, possibly because of the expectation of certain travel requirements???
Re: Hackathon during Q1 2005?
* Jeff Trawick wrote: On Sun, 12 Dec 2004 00:37:49 -0600, William A. Rowe, Jr. [EMAIL PROTECTED] wrote: (Actually - all of this Euro talk reminds me how less-than-optimal the west coast really is for European participants. The east coast seems like a short hop by comparison.) east coast sounds much better to this North Carolinian I'd guess, for a European there's not so much difference ;-) For the Asian folks the west may be the better choice. perhaps California is the place that would result in the most people on site; not many people are chiming in on this thread, possibly because of the expectation of certain travel requirements??? FWIW: At this time there's no way to get me into the States, regardless of which coast, sorry. nd -- Gefunden auf einer Webdesigner-Seite: Programmierung in HTML, XML, WML, CGI, FLASH # André Malo # http://www.perlig.de/ #
2.1.2-alpha http/ftp proxy/cache problems
Both problems described below relate to the http and the ftp proxy with cache enabled. URLs and proxy setup are given at the end of this mail. Problem 1 - http: It happens from time to time that when URL 1 is reloaded and then URL 2 is reloaded in Mozilla that /v2/ (URL 2) is requested by the proxy from a server related to URL 1, resulting in the following 404: Not Found The requested URL /v2/ was not found on this server. Apache/1.3.27 Server at www.bitmover.com Port 80 It seems from the tcpdump that img src=http://www.bitmover.com/gifs/bitkeeper-shadow.gif; is requested by the proxy resulting in a 304 and then the same tcp connection is erroneously reused to request the www.wetter.com URL. tcpdump excerpt: 15:11:51.745134 IP 80.140.165.47.1949 192.132.92.2.80: P 1:506(505) ack 1 win 5808 0x0020: 5018 16b0 f075 4745 5420 2f67 6966 Pu..GET./gif 0x0030: 732f 6269 746b 6565 7065 722d 7368 6164 s/bitkeeper-shad 0x0040: 6f77 2e67 6966 2048 5454 502f 312e 310d ow.gif.HTTP/1.1. 0x0050: 0a48 6f73 743a 2077 2e62 6974 6d6f .Host:.www.bitmo 0x0060: 7665 722e 636f 6d0d 0a55 7365 722d 4167 ver.com..User-Ag 0x0070: 656e 743a 204d 6f7a 696c 6c61 2f35 2e30 ent:.Mozilla/5.0 0x0080: 2028 5831 313b 2055 3b20 4c69 6e75 7820 .(X11;.U;.Linux. 0x0090: 6936 3836 3b20 656e 2d55 533b 2072 763a i686;.en-US;.rv: 0x00a0: 312e 372e 3329 2047 6563 6b6f 2f32 3030 1.7.3).Gecko/200 0x00b0: 3430 3931 380d 0a41 6363 6570 743a 2069 40918..Accept:.i 0x00c0: 6d61 6765 2f70 6e67 2c2a 2f2a 3b71 3d30 mage/png,*/*;q=0 0x00d0: 2e35 0d0a 4163 6365 7074 2d4c 616e 6775 .5..Accept-Langu 0x00e0: 6167 653a 2065 6e2d 7573 2c65 6e3b 713d age:.en-us,en;q= 0x00f0: 302e 372c 6465 3b71 3d30 2e33 0d0a 4163 0.7,de;q=0.3..Ac 0x0100: 6365 7074 2d45 6e63 6f64 696e 673a 2067 cept-Encoding:.g 0x0110: 7a69 702c 6465 666c 6174 650d 0a41 6363 zip,deflate..Acc 0x0120: 6570 742d 4368 6172 7365 743a 2049 534f ept-Charset:.ISO 0x0130: 2d38 3835 392d 3135 2c75 7466 2d38 3b71 -8859-15,utf-8;q 0x0140: 3d30 2e37 2c2a 3b71 3d30 2e37 0d0a 5265 =0.7,*;q=0.7..Re 0x0150: 6665 7265 723a 2068 7474 703a 2f2f 6c69 ferer:.http://li 0x0160: 6e75 782e 626b 6269 7473 2e6e 6574 3a38 nux.bkbits.net:8 0x0170: 3038 302f 6c69 6e75 782d 322e 352f 4368 080/linux-2.5/Ch 0x0180: 616e 6765 5365 7440 2d37 643f 6e61 763d [EMAIL PROTECTED] 0x0190: 696e 6465 782e 6874 6d6c 0d0a 4966 2d4d index.html..If-M 0x01a0: 6f64 6966 6965 642d 5369 6e63 653a 2053 odified-Since:.S 0x01b0: 6174 2c20 3238 2046 6562 2032 3030 3420 at,.28.Feb.2004. 0x01c0: 3137 3a32 313a 3033 2047 4d54 0d0a 4966 17:21:03.GMT..If 0x01d0: 2d4e 6f6e 652d 4d61 7463 683a 2022 3334 -None-Match:.34 0x01e0: 3433 332d 3230 3361 2d34 3034 3063 6466 433-203a-4040cdf 0x01f0: 6622 0d0a 4361 6368 652d 436f 6e74 726f f..Cache-Contro 0x0200: 6c3a 206d 6178 2d61 6765 3d30 0d0a 4d61 l:.max-age=0..Ma 0x0210: 782d 466f 7277 6172 6473 3a20 350d 0a0d x-Forwards:.5... 15:11:51.999590 IP 192.132.92.2.80 80.140.165.47.1949: P 1:187(186) ack 506 wi n 6432 0x0020: 5018 1920 805b 4854 5450 2f31 2e31 P[..HTTP/1.1 0x0030: 2033 3034 204e 6f74 204d 6f64 6966 6965 .304.Not.Modifie 0x0040: 640d 0a44 6174 653a 2053 756e 2c20 3132 d..Date:.Sun,.12 0x0050: 2044 6563 2032 3030 3420 3134 3a31 313a .Dec.2004.14:11: 0x0060: 3530 2047 4d54 0d0a 5365 7276 6572 3a20 50.GMT..Server:. 0x0070: 4170 6163 6865 2f31 2e33 2e32 3720 2855 Apache/1.3.27.(U 0x0080: 6e69 7829 2020 2852 6564 2d48 6174 2f4c nix)..(Red-Hat/L 0x0090: 696e 7578 2920 6d6f 645f 7373 6c2f 322e inux).mod_ssl/2. 0x00a0: 382e 3132 204f 7065 6e53 534c 2f30 2e39 8.12.OpenSSL/0.9 0x00b0: 2e36 6220 6d6f 645f 7065 726c 2f31 2e32 .6b.mod_perl/1.2 0x00c0: 360d 0a45 5461 673a 2022 3334 3433 332d 6..ETag:.34433- 0x00d0: 3230 3361 2d34 3034 3063 6466 6622 0d0a 203a-4040cdff.. 0x00e0: 0d0a .. 15:11:53.180488 IP 80.140.165.47.1949 192.132.92.2.80: P 506:995(489) ack 187 win 6432 0x0020: 5018 1920 172f 4745 5420 2f76 322f P/..GET./v2/ 0x0030: 3f53 4944 3d26 4c41 4e47 3d44 4526 4c4f ?SID=LANG=DELO 0x0040: 433d 3032 3830 264c 4f43 4652 4f4d 3d30 C=0280LOCFROM=0 0x0050: 3230 3226 7265 6769 6f6e 3d42 5920 4854 202region=BY.HT 0x0060: 5450 2f31 2e31 0d0a 486f 7374 3a20 TP/1.1..Host:.ww 0x0070: 772e 7765 7474 6572 2e63 6f6d 0d0a 5573 w.wetter.com..Us 0x0080: 6572 2d41 6765 6e74 3a20 4d6f 7a69 6c6c er-Agent:.Mozill 0x0090: 612f 352e 3020 2858 3131 3b20 553b 204c a/5.0.(X11;.U;.L 0x00a0: 696e 7578 2069 3638 363b 2065 6e2d
Re: Hackathon during Q1 2005?
But I'm wondering what this actually achieves? Social and fun :-) We're developing a global communications infrastructure. Let's b* well *use* it! Dw
Re: Hackathon during Q1 2005?
David Reid wrote: Justin Erenkrantz wrote: During ApacheCon, a number of us had talked about holding more frequent face-to-face meetings (or summits or whatever). Fred is willing to find a place for us at Apple with space and 'net access. Fred's suggested around the week of February 7th, 2005. That would work for me as well. I agree with the sentiment but this list is httpd specific - is this *really* the right place to debate having a hackathon? I thought this would be a 'httpd' hackathon, not a general hackathon at least thats the impression I got from Justin's original message and the fact that it was raised on httpd-dev. -Paul
Re: Hackathon during Q1 2005?
On Sun, 12 Dec 2004, Paul Querna wrote: I thought this would be a 'httpd' hackathon, not a general hackathon at least thats the impression I got from Justin's original message and the fact that it was raised on httpd-dev. Same here - a general hackaton is a bit more work - but also doable. DW.
Re: Hackathon during Q1 2005?
Justin Erenkrantz wrote: During ApacheCon, a number of us had talked about holding more frequent face-to-face meetings (or summits or whatever). Fred is willing to find a place for us at Apple with space and 'net access. Fred's suggested around the week of February 7th, 2005. That would work for me as well. I agree with the sentiment but this list is httpd specific - is this *really* the right place to debate having a hackathon? As Paul said, I meant only for this hackathon to be focused on httpd. If for example, we had an ASF-wide hackathon not held during ApacheCon, it'll just increase the 'distraction' on those that participate in multiple groups. During ApacheCon, I was frustrated that I kept getting pulled off to do infra@ or prc@ stuff instead of being able to focus solely on httpd stuff. (Sander and Greg kept getting pulled out for board stuff as well.) So, I'm very, very strongly in favor of having an httpd-only hackathon. Keep it small and focused to minimize distractions. -- justin
Re: Hackathon during Q1 2005?
On Sat, 11 Dec 2004, Dirk-Willem van Gulik wrote: Sounds a lot more feasible than travelling to .us for a hack. But I'm wondering what this actually achieves? Sure, it gets people to focus on Getting Things Done, but a *scheduled* IRC+pastebin-based hackathon could do that without the hassle and cost of travel. IMHO, a 'virtual hackathon' has been proven not to be effective for us. In the past when we've tried those, they've been a dismal failure as so few people show up. The communication latency is also so high (people get distracted, bored, conflicting schedules) that a 'virtual hackathon' is really little better than the mailing lists we use every day. I think forcing people to get in the same physical room free from other distractions a few times a year (certainly no more than once a quarter!) would have good benefits for us as a project. It'd serve as a forcing function for our focus as a group: and that'd be excellent to drive innovation here. As I just said to David, I think the ASF-wide hackathons aren't as effective because many people are too over-committed to be able to focus on one thing while they are there. -- justin
Re: Hackathon during Q1 2005?
Justin Erenkrantz wrote: Justin Erenkrantz wrote: During ApacheCon, a number of us had talked about holding more frequent face-to-face meetings (or summits or whatever). Fred is willing to find a place for us at Apple with space and 'net access. Fred's suggested around the week of February 7th, 2005. That would work for me as well. I agree with the sentiment but this list is httpd specific - is this *really* the right place to debate having a hackathon? As Paul said, I meant only for this hackathon to be focused on httpd. If for example, we had an ASF-wide hackathon not held during ApacheCon, it'll just increase the 'distraction' on those that participate in multiple groups. Well, the plans that were discussed at the Con were for that very type of event, NOT a project specific event along the lines you're discussing. During ApacheCon, I was frustrated that I kept getting pulled off to do infra@ or prc@ stuff instead of being able to focus solely on httpd stuff. (Sander and Greg kept getting pulled out for board stuff as well.) That's understandable. So, I'm very, very strongly in favor of having an httpd-only hackathon. Keep it small and focused to minimize distractions. -- justin Then may I'd suggest you not use the term hackathon :-) Organising an httpd developer get together is an excellent idea, but the hackathon is slowly turning into a brand and a series of events with all the baggage that goes with them... I'm hoping to arrange a hackathon in London sometime around the end of Feb/start of Mar 2005 (with hopefully another later in the year somewhere else in the UK). As it's a hackathon it'll be open to all and won't just be for one project or another. I realise people will think I'm splitting hairs, but as we move forwards I think these distinctions will become more and more important. Also I believe that there will be definately be a 2 day hackthon prior to ApacheCon europe. david
[STATUS] (apache-1.3) Wed May 5 23:45:54 EDT 2004
APACHE 1.3 STATUS: -*-text-*- Last modified at [$Date: 2004/04/19 18:53:57 $] Release: 1.3.31-dev: In development. Plan to TR week of April 19. 1.3.30: Tagged April 9, 2004. Not released. 1.3.29: Tagged October 24, 2003. Announced Oct 29, 2003. 1.3.28: Tagged July 16, 2003. Announced ?? 1.3.27: Tagged September 30, 2002. Announced Oct 3, 2002. 1.3.26: Tagged June 18, 2002. 1.3.25: Tagged June 17, 2002. Not released. 1.3.24: Tagged Mar 21, 2002. Announced Mar 22, 2002. 1.3.23: Tagged Jan 21, 2002. 1.3.22: Tagged Oct 8, 2001. Announced Oct 12, 2001. 1.3.21: Not released. (Pulled for htdocs/manual config mismatch. t/r Oct 5, 2001) 1.3.20: Tagged and rolled May 15, 2001. Announced May 21, 2001. 1.3.19: Tagged and rolled Feb 26, 2001. Announced Mar 01, 2001. 1.3.18: Tagged and rolled Not released. (Pulled because of an incorrect unescaping fix. t/r Feb 19, 2001) 1.3.17: Tagged and rolled Jan 26, 2001. Announced Jan 29, 2001. 1.3.16: Not released. (Pulled because of vhosting bug. t/r Jan 20, 2001) 1.3.15: Not released. (Pulled due to CVS dumping core during the tagging when it reached src/os/win32/) 1.3.14: Tagged and Rolled Oct 10, 2000. Released/announced on the 13th. 1.3.13: Not released. (Pulled in the first minutes due to a Netware build bug) 1.3.12: Tagged and rolled Feb. 23, 2000. Released/announced on the 25th. 1.3.11: Tagged and rolled Jan. 19, 2000. Released/announced on the 21st. 1.3.10: Not released. (Pulled at last minute due to a build bug in the MPE port) 1.3.9: Tagged and rolled on Aug. 16, 1999. Released and announced on 19th. 1.3.8: Not released. 1.3.7: Not released. 1.3.6: Tagged and rolled on Mar. 22, 1999. Released and announced on 24th. 1.3.5: Not released. 1.3.4: Tagged and rolled on Jan. 9, 1999. Released on 11th, announced on 12th. 1.3.3: Tagged and rolled on Oct. 7, 1998. Released on 9th, announced on 10th. 1.3.2: Tagged and rolled on Sep. 21, 1998. Announced and released on 23rd. 1.3.1: Tagged and rolled on July 19, 1998. Announced and released. 1.3.0: Tagged and rolled on June 1, 1998. Announced and released on the 6th. 2.0 : Available for general use, see httpd-2.0 repository RELEASE SHOWSTOPPERS: * mod_digest/nonce issue. Message-Id: [EMAIL PROTECTED] Patches: Already committed to CVS for ease of review and test. Developers should review these!! RELEASE NON-SHOWSTOPPERS BUT WOULD BE REAL NICE TO WRAP THESE UP: * PR: 27023 Cookie could not delivered if the cookie made before proxy module. * isn't ap_die() broken with recognizing recursive errors Message-Id: [EMAIL PROTECTED] +1: jeff, jim * Current vote on 3 PRs for inclusion: Bugz #17877 (passing chunked encoding thru proxy) (still checking if RFC compliant... vote is on the correctness of the patch code only). +1: jim, chuck, minfrin Bugz #9181 (Unable to set headers on non-2XX responses) +1: Martin, Jim Gnats #10246 (Add ProxyConnAllow directive) +0: Martin (or rather -.5, see dev@ Message [EMAIL PROTECTED]) * htpasswd.c and htdigest.c use tmpnam()... consider using mkstemp() when available. Message-ID: [EMAIL PROTECTED] Status: * Dean's unescaping hell (unescaping the various URI components at the right time and place, esp. unescaping the host name). Message-ID: [EMAIL PROTECTED] Status: * Martin observed a core dump because a ipaddr_chain struct contains a NULL-server pointer when being dereferenced by invoking httpd -S. Message-ID: [EMAIL PROTECTED] Status: Workaround enabled. Clean solution can come after 1.3.19 * long pathnames with many components and no AllowOverride None Workaround is to define Directory / with AllowOverride None, which is something all sites should do in any case. Status: Marc was looking at it. (Will asks 'wasn't this patched?') * Ronald Tschalär's patch to mod_proxy to allow other modules to set headers too (needed by mod_auth_digest) Message-ID: [EMAIL PROTECTED] Status: Available Patches (Most likely, will be ported to 2.0 as appropriate): * A rewrite of ap_unparse_uri_components() by Jeffrey W. Baker [EMAIL PROTECTED] to more fully close some segfault potential. Message-ID: [EMAIL PROTECTED] Status: Jim +1 (for 1.3.19), Martin +0 * Andrew Ford's patch (1999/12/05) to add absolute times to mod_expires Message-ID: [EMAIL PROTECTED] Status: Martin +1, Jim +1, Ken +1 (on concept) * Raymond S Brand's path to mod_autoindex to fix the header/readme include processing so the envariables are correct
[STATUS] (apache-1.3) Wed Apr 28 23:45:46 EDT 2004
APACHE 1.3 STATUS: -*-text-*- Last modified at [$Date: 2004/04/19 18:53:57 $] Release: 1.3.31-dev: In development. Plan to TR week of April 19. 1.3.30: Tagged April 9, 2004. Not released. 1.3.29: Tagged October 24, 2003. Announced Oct 29, 2003. 1.3.28: Tagged July 16, 2003. Announced ?? 1.3.27: Tagged September 30, 2002. Announced Oct 3, 2002. 1.3.26: Tagged June 18, 2002. 1.3.25: Tagged June 17, 2002. Not released. 1.3.24: Tagged Mar 21, 2002. Announced Mar 22, 2002. 1.3.23: Tagged Jan 21, 2002. 1.3.22: Tagged Oct 8, 2001. Announced Oct 12, 2001. 1.3.21: Not released. (Pulled for htdocs/manual config mismatch. t/r Oct 5, 2001) 1.3.20: Tagged and rolled May 15, 2001. Announced May 21, 2001. 1.3.19: Tagged and rolled Feb 26, 2001. Announced Mar 01, 2001. 1.3.18: Tagged and rolled Not released. (Pulled because of an incorrect unescaping fix. t/r Feb 19, 2001) 1.3.17: Tagged and rolled Jan 26, 2001. Announced Jan 29, 2001. 1.3.16: Not released. (Pulled because of vhosting bug. t/r Jan 20, 2001) 1.3.15: Not released. (Pulled due to CVS dumping core during the tagging when it reached src/os/win32/) 1.3.14: Tagged and Rolled Oct 10, 2000. Released/announced on the 13th. 1.3.13: Not released. (Pulled in the first minutes due to a Netware build bug) 1.3.12: Tagged and rolled Feb. 23, 2000. Released/announced on the 25th. 1.3.11: Tagged and rolled Jan. 19, 2000. Released/announced on the 21st. 1.3.10: Not released. (Pulled at last minute due to a build bug in the MPE port) 1.3.9: Tagged and rolled on Aug. 16, 1999. Released and announced on 19th. 1.3.8: Not released. 1.3.7: Not released. 1.3.6: Tagged and rolled on Mar. 22, 1999. Released and announced on 24th. 1.3.5: Not released. 1.3.4: Tagged and rolled on Jan. 9, 1999. Released on 11th, announced on 12th. 1.3.3: Tagged and rolled on Oct. 7, 1998. Released on 9th, announced on 10th. 1.3.2: Tagged and rolled on Sep. 21, 1998. Announced and released on 23rd. 1.3.1: Tagged and rolled on July 19, 1998. Announced and released. 1.3.0: Tagged and rolled on June 1, 1998. Announced and released on the 6th. 2.0 : Available for general use, see httpd-2.0 repository RELEASE SHOWSTOPPERS: * mod_digest/nonce issue. Message-Id: [EMAIL PROTECTED] Patches: Already committed to CVS for ease of review and test. Developers should review these!! RELEASE NON-SHOWSTOPPERS BUT WOULD BE REAL NICE TO WRAP THESE UP: * PR: 27023 Cookie could not delivered if the cookie made before proxy module. * isn't ap_die() broken with recognizing recursive errors Message-Id: [EMAIL PROTECTED] +1: jeff, jim * Current vote on 3 PRs for inclusion: Bugz #17877 (passing chunked encoding thru proxy) (still checking if RFC compliant... vote is on the correctness of the patch code only). +1: jim, chuck, minfrin Bugz #9181 (Unable to set headers on non-2XX responses) +1: Martin, Jim Gnats #10246 (Add ProxyConnAllow directive) +0: Martin (or rather -.5, see dev@ Message [EMAIL PROTECTED]) * htpasswd.c and htdigest.c use tmpnam()... consider using mkstemp() when available. Message-ID: [EMAIL PROTECTED] Status: * Dean's unescaping hell (unescaping the various URI components at the right time and place, esp. unescaping the host name). Message-ID: [EMAIL PROTECTED] Status: * Martin observed a core dump because a ipaddr_chain struct contains a NULL-server pointer when being dereferenced by invoking httpd -S. Message-ID: [EMAIL PROTECTED] Status: Workaround enabled. Clean solution can come after 1.3.19 * long pathnames with many components and no AllowOverride None Workaround is to define Directory / with AllowOverride None, which is something all sites should do in any case. Status: Marc was looking at it. (Will asks 'wasn't this patched?') * Ronald Tschalär's patch to mod_proxy to allow other modules to set headers too (needed by mod_auth_digest) Message-ID: [EMAIL PROTECTED] Status: Available Patches (Most likely, will be ported to 2.0 as appropriate): * A rewrite of ap_unparse_uri_components() by Jeffrey W. Baker [EMAIL PROTECTED] to more fully close some segfault potential. Message-ID: [EMAIL PROTECTED] Status: Jim +1 (for 1.3.19), Martin +0 * Andrew Ford's patch (1999/12/05) to add absolute times to mod_expires Message-ID: [EMAIL PROTECTED] Status: Martin +1, Jim +1, Ken +1 (on concept) * Raymond S Brand's path to mod_autoindex to fix the header/readme include processing so the envariables are correct
Re: Apache HTTP Server 2.1.2 tagged...
+1 for promoting it to beta status. I tested on NetBSD-2.0 and FreeBSD 5.2.1. I was able to duplicate the regressions in mod_rewrite and mod_proxy: http://issues.apache.org/bugzilla/show_bug.cgi?id=32459 However, the proxy related regressions are only a small part of the code. I believe we need a beta release to help find other issues. -Paul Justin Erenkrantz wrote: In the continuing string of 2.1.x releases, Apache HTTP Server 2.1.2 is now available at: http://httpd.apache.org/dev/dist/ Currently, this is only an alpha-quality release and is only meant for developers to provide feedback for the upcoming 2.2 series. New features with the 2.1/2.2 series are listed here: http://httpd.apache.org/docs-2.1/new_features_2_2.html Changes are here: http://httpd.apache.org/dev/dist/CHANGES_2.1 Please provide feedback, votes, etc. If you have any problems, as always, please bring them up on [EMAIL PROTECTED] Thanks! -- justin
Re: [PATCH] fixing broken gnu ld (mis)detection problem
* Jeff Trawick [EMAIL PROTECTED] wrote: snip we don't maintain configure; bad enough. an carefully hand-written configure would be much better. it is autogenerated; any fixes need to be in the input files; it looks like the portion you had to modify comes from libtool sources, not from Apache httpd sources; have you tried you probably meant autoconf ... installing a later libtool and running buildconf to regenerate configure? yes, tried it. but configure remains exactly the same. IMHO automake+frieds are a really bad joke - scripts for creating scripts, which somehow create scripts for building software in mysterious ways ... completely indeterministic. not really the incarnation of reliability. I dont count the days of autoconf-trouble anylonger - i'm counting the days when autoconfs really works, there're just a few. I've written down some concepts for an universal crossplatform compiling/building toolkit, which also supports crosscompiling and sysroot'ing as fundamental concepts and abstracts from platform or toolchain specific stuff (ie. universal parameter set for common things like compiler options, pathes, etc, etc). I really cant understand why it seems that I'm the first one really working on that ... cu -- - Enrico Weigelt== metux IT service phone: +49 36207 519931 www: http://www.metux.de/ fax: +49 36207 519932 email: [EMAIL PROTECTED] cellphone: +49 174 7066481 - -- DSL ab 0 Euro. -- statische IP -- UUCP -- Hosting -- Webshops -- -
Why bundling 3rd-party packages anyway ? [WAS: A zLib Update....?]
* Brad Nicholes [EMAIL PROTECTED] wrote: big_snip / Hi folks, Why bundling 3rd-party packages anyway ?! I personally *always* use sysetm libs instead of bundled libs when some packages do such bundling. But I'm really unhappy that apache2's configure does not provide an option for doing that on pcre. Especially in embedded systems (which is one of my focuses) its an really unnecessary wastal of resources. Why isn't there an option for using system's pcre ? Why is pcre bundled anyway ? Other packages (ie zlib or expat) are also not bundled, so why pcre ? cu -- - Enrico Weigelt== metux IT service phone: +49 36207 519931 www: http://www.metux.de/ fax: +49 36207 519932 email: [EMAIL PROTECTED] cellphone: +49 174 7066481 - -- DSL ab 0 Euro. -- statische IP -- UUCP -- Hosting -- Webshops -- -
Re: MPM with DYNAMICAL user switching?
* Dmitry Koteroff [EMAIL PROTECTED] wrote: Hi, Perchild MPM allows to run different vhost requests under different user accounts. But: no, it doesn't. but metuxmpm does: http://nibiru.borg.metux.de:7000/wiki.mpm/ snip 1. It does not support Windows at all. windows does not support passing sockets between processes. so without this, you can just use a proxy sitting in front of multiple severs. snip 2. It does not support child processes dynamic creation. For example, if we have 1000 vhosts under 1000 users, this MPM tries to create 1000 apache children first. Of course, it is very hard to do; creation on demand and killing after inactive timeout is more preferably. we're working on that. contributions are always welcomed. cu -- - Enrico Weigelt== metux IT service phone: +49 36207 519931 www: http://www.metux.de/ fax: +49 36207 519932 email: [EMAIL PROTECTED] cellphone: +49 174 7066481 - -- DSL ab 0 Euro. -- statische IP -- UUCP -- Hosting -- Webshops -- -
Re: Discover which MPM is loaded?
* Adam Tilghman [EMAIL PROTECTED] wrote: snip It seems to me that running in reverse proxy mode as you suggest would require one running instance per possible UID, which would be fine for tens or even hundreds of users, but not for the number we have to support. You're probably interested in metuxmpm, which is able to run different vhosts on different users. We could change it to use also auth credentials instead of vhost for the user selection. http://nibiru.borg.metux.de:7000/wiki.mpm/ cu -- - Enrico Weigelt== metux IT service phone: +49 36207 519931 www: http://www.metux.de/ fax: +49 36207 519932 email: [EMAIL PROTECTED] cellphone: +49 174 7066481 - -- DSL ab 0 Euro. -- statische IP -- UUCP -- Hosting -- Webshops -- -
Re: Towards a generic database connection API
* Nick Kew [EMAIL PROTECTED] wrote: snip I'd like the DBD API to be generic, and to work for other modules that use an SQL backend, ranging from specific modules such as SQL-based authentication and logging to general frameworks such as Perl, Python and PHP. I don't know to what extent that's going to prove feasible, but perhaps my current draft can serve as a startingpoint. What I'd really like at this stage is feedback from other developers connecting Apache to an SQL backend. http://www.unixodbc.org/ ? cu -- - Enrico Weigelt== metux IT service phone: +49 36207 519931 www: http://www.metux.de/ fax: +49 36207 519932 email: [EMAIL PROTECTED] cellphone: +49 174 7066481 - -- DSL ab 0 Euro. -- statische IP -- UUCP -- Hosting -- Webshops -- -
metux MPM, was RFC for a Perchild-like-MPM
Enrico Weigelt wrote: We've done a complete redesign of an multiplexer-based MPM, but it seems that no one's really interested in it here. We've supplied patches against various httpd2 releases. http://nibiru.borg.metux.de:7000/wiki.mpm/ I only see patches for 2.0.48 and .49. Do you have something against Subversion Trunk? Have you tried it against 2.1 yet? Many folks are using it quite sucessfully in production environments and SuSE (*the* major distributor in middle Europe is already shipping it for quite a while). Great. But here on httpd-dev it seems that no one's really interested it. Instead of shipping our multiplexer mpm at least as 'experimental' (remember: its already in production use for quite a long time), there's still just the misdesigned perchild. Then be active on this mailing list, never stop pushing the code, and it has a good chance of getting in. Honestly, I haven't seen a concerted effort to get metux mpm back into the mainline, but I welcome one. I cannot just take one of those patches from the website and commit it to subversion. What is the next step, I am not sure, but do not stop pushing to get your code in. -Paul
Re: PCRE in 2.1/2.2
* Joe Orton [EMAIL PROTECTED] wrote: snip Is there any reason to keep libpcre in the httpd tree? untar configure make must just work on any random Unix system. shot yourself. apache2 requires expat, which is less common than pcre. snip Those are bugs which can be fixed by optionally using an external PCRE library (configure --with-pcre) and/or properly namespacing the symbols Are you shure this option really exists ? defined by the bundled copy of PCRE. Removing the bundled PCRE is not necessary to that goal or otherwise desirable, though. The original question was exactly the opposite: is it necessary always to have a bundled pcre ? cu -- - Enrico Weigelt== metux IT service phone: +49 36207 519931 www: http://www.metux.de/ fax: +49 36207 519932 email: [EMAIL PROTECTED] cellphone: +49 174 7066481 - -- DSL ab 0 Euro. -- statische IP -- UUCP -- Hosting -- Webshops -- -
Re: PATCH: call aclocal for PCRE in buildconf
Enrico Weigelt wrote: * Max Bowsher [EMAIL PROTECTED] wrote: snip Actually aclocal belongs to automake. But then, it would be a weird system where autoconf/automake/libtool are not installed as a group, so I guess that's still ok. I personally prefer just install exactly these packages which are really needed and are declared as depencencies of those packages I want to use ... For example, today was the first time in my life when I ever installed libtool, since someone said installing it and rerunning buildconf could fix broken configure, which of course was not the case ... fwiw, you do not need to install libtool to use apache/apr/apr-util. Just compile APR --with-experimental-libtool, and then you will use jlibtool, a single C file written by Justin, instead of libtool itself. -Paul
Re: PCRE in 2.1/2.2
Enrico Weigelt wrote: * Joe Orton [EMAIL PROTECTED] wrote: snip Is there any reason to keep libpcre in the httpd tree? untar configure make must just work on any random Unix system. shot yourself. apache2 requires expat, which is less common than pcre. does not. APR-Util embeds expat. -Paul
Re: Towards a generic database connection API
Enrico Weigelt wrote: * Nick Kew [EMAIL PROTECTED] wrote: snip I'd like the DBD API to be generic, and to work for other modules that use an SQL backend, ranging from specific modules such as SQL-based authentication and logging to general frameworks such as Perl, Python and PHP. I don't know to what extent that's going to prove feasible, but perhaps my current draft can serve as a startingpoint. What I'd really like at this stage is feedback from other developers connecting Apache to an SQL backend. http://www.unixodbc.org/ ? LGPL`ed, and I have never seen it used from an Apache Module. It looks quite heavy... the APR DBD api is just a loose wrapper around the low level calls, its a different target than unixODBC, which looks to be much much more.
Re: PATCH: call aclocal for PCRE in buildconf
* André Malo [EMAIL PROTECTED] wrote: snip In fact you should tell that the library we distribute. *It* (PCRE) depends on automake (i.e. aclocal only!) in newer versions. The clean way seems to me either to shrug and accept it, or to leave the lib alone and use the one installed on the system. Simply using system pcre would probably be the cleanest way. I really cant see any (good) reason for not doing so. cu -- - Enrico Weigelt== metux IT service phone: +49 36207 519931 www: http://www.metux.de/ fax: +49 36207 519932 email: [EMAIL PROTECTED] cellphone: +49 174 7066481 - -- DSL ab 0 Euro. -- statische IP -- UUCP -- Hosting -- Webshops -- -
Re: PCRE in 2.1/2.2
Enrico Weigelt wrote: * Paul Querna [EMAIL PROTECTED] wrote: snip shot yourself. apache2 requires expat, which is less common than pcre. does not. APR-Util embeds expat. eh? uglier than i thouht! why isnt there an --with-expat=... option for enforcing use of external expat ? There is: srclib/apr-util/configure --help | grep expat --with-expat=DIRspecify Expat location btw: why is it a goal to put all dependencies into the package just to be able to do make make install w/o any preparations ?! dependencies are to be tracked by the computer, 100% automatically. Dependencies are to be tracked by a vendor, not by our users who download the source from us. I agree with you however, but this is the current state of httpd. Patches to allow using of external libs for everything we currently embed are extremely welcome. -Paul
Re: PCRE in 2.1/2.2
* Paul Querna [EMAIL PROTECTED] wrote: snip shot yourself. apache2 requires expat, which is less common than pcre. does not. APR-Util embeds expat. eh? uglier than i thouht! why isnt there an --with-expat=... option for enforcing use of external expat ? embedding standard libraries adds unnecessary complexity, wastes resources and limits flexibility. btw: why is it a goal to put all dependencies into the package just to be able to do make make install w/o any preparations ?! dependencies are to be tracked by the computer, 100% automatically. cu -- - Enrico Weigelt== metux IT service phone: +49 36207 519931 www: http://www.metux.de/ fax: +49 36207 519932 email: [EMAIL PROTECTED] cellphone: +49 174 7066481 - -- DSL ab 0 Euro. -- statische IP -- UUCP -- Hosting -- Webshops -- -
Re: Hackathon during Q1 2005?
FWIW: At this time there's no way to get me into the States, regardless of which coast, sorry. Same for me. :( So a hackaton in the Netherlands or during the European ApacheCon would be fine. Kess
Re: Hackathon during Q1 2005?
Justin Erenkrantz wrote: During ApacheCon, a number of us had talked about holding more frequent face-to-face meetings (or summits or whatever). Fred is willing to find a place for us at Apple with space and 'net access. Fred's suggested around the week of February 7th, 2005. That would work for me as well. I agree with the sentiment but this list is httpd specific - is this *really* the right place to debate having a hackathon? So, how many people would be interested, willing, and able to make it? I might actually be around, but regardless this isn't the correct venue to discuss having a hackathon event. david
Re: Hackathon during Q1 2005?
On Sun, 12 Dec 2004 00:37:49 -0600, William A. Rowe, Jr. [EMAIL PROTECTED] wrote: (Actually - all of this Euro talk reminds me how less-than-optimal the west coast really is for European participants. The east coast seems like a short hop by comparison.) east coast sounds much better to this North Carolinian perhaps California is the place that would result in the most people on site; not many people are chiming in on this thread, possibly because of the expectation of certain travel requirements??? Well, we've had concrete offers of a place on the West Coast and a place in Europe. We haven't heard anything regarding the East Coast (*nudge*). The East Coast would be fine with me and depending upon the time of year and the cost of flights, I'd be fine with traveling to Europe as well. What I think makes some sense is to try to shoot for httpd-specific hackathons 4x a year: once a quarter. Two of them would be covered by ApacheCon's, but in the other two quarters of the years: have one in the US and one in Europe. That way people who can't leave their neck of the woods have a shot at making it twice a year. My opinion is having two parallel hackathons at the same time wouldn't be very productive. -- justin
Re: RFC for a Perchild-like-MPM
* Paul Querna [EMAIL PROTECTED] wrote: Hi, I have had an idea for replacing the perchild MPM boggling around inside my head for awhile now. This is an idea for a different architecture to allowing different UIDs to serve httpd requests. I am looking for all feedback with my proposed approach. Probably I've missing something, but I've never seen that perchild was ever really working. It is vulnerable for an simple ptrace-attac, and that's not just a bug, its fundamental misdesign. So its dead-born child. We've done a complete redesign of an multiplexer-based MPM, but it seems that no one's really interested in it here. We've supplied patches against various httpd2 releases. http://nibiru.borg.metux.de:7000/wiki.mpm/ Many folks are using it quite sucessfully in production environments and SuSE (*the* major distributor in middle Europe is already shipping it for quite a while). But here on httpd-dev it seems that no one's really interested it. Instead of shipping our multiplexer mpm at least as 'experimental' (remember: its already in production use for quite a long time), there's still just the misdesigned perchild. Am I the only one who wonders about that ? snip First, we start with a concept I am calling 'Server Pools'. Each pool has specific limits. These can include a maximum number of processes, or other limits based on resource usage. A root server pool can contain other pools, or sub pools. (: perhaps 'server pools' is a bad word for this idea?) snip Since you need the ability to spawn more processes on demand when none exist, there will be a 'controller process' that manages all server pools, killing or using fork() to spawn new pools. In other words: improve the mother code of metuxmpm to allow more detailed configuration. Currently we have no on-demand-spawning, but its planned and we have some concepts for that. snip A frontend will parse the incoming request, and provide other services, like input filters, output filters, and logging. This frontend will logging of course, but why not filtering in the target UID ? pass the request back to a server pool by asking the control process for which server pool should service this request. bad idea. too slow. the frontend should know how to find the right processor child. if we also use statistical data for that, this can be sent from the mother to the multiplexer. snip If no server pool currently has any processes running, the control process will spawn one or more. Probably I misunderstood something in your pool concept, but shouldn't the pools be defined by the admin ? (ie. one pool per user ?) snip I disagree with the concept of passing a client socket directly to the back-end as perchild does. What's bad on this concept ? It performs very well. snip I believe it would be better to write a protocol handler for AJP or another binary type protocol and therefore, hopefully, faster for passing requests to a backend server pool via Unix Daemon Sockets. By passing the socket directly to the backend, we enter a hell related to input filters, keep alive requests, and http 1.1 pipelining. #1: filters belong into the processor child. we can assume that headers can always be read without filters. #2: keep alive *could* be a conceptional problem, since its simply not defined anywhere whether an persistent connection *may* carry requests to several vhosts. we did never see this (metuxmpm would shout very loud in this case) and it seems quite improbable that clients authors tend to bunch connections+requests together by IP instead of name. (of course it would be possible) I also believe that for most cases, an optimized AJP like protocol would You believe ... well there're folks who believe in little gray men from alpha centauri - so not a good argument ;-) It can be easily proven, that its slower, since the machine has much more to do, ie: + encapsulate the request + pass the (enc) request between processes + decapsulate the request + encapsulate the reply + pass the (enc) reply between processes + decapsulate the request You probably could get some speedups by using shared memory, but its still notacibly slower than simply passing the connection itself. snip What this Solves: - Keep Alive/Pipelining/SSL decoding.. etc. These are all handled by the fontend. AFAIK SSL/https is not suited for name based virtual hosting (what shall be the primary sense of this mpm). Also not a bug, but a design problem of the https protocol. snip - PHP Support. The backends could be process or threaded, it doesn't matter, but at the same time, the frontend could resemble the Event or Worker MPM. Already working in metuxmpm for a long time. snip Thoughts: - Hacking a demo via mod_proxy - Is this a better design than perchild MPM? evryting's better than perchild ;-) snip In some ways, this is just a more automated
Re: [PATCH] fixing broken gnu ld (mis)detection problem
Enrico Weigelt wrote: snip I dont count the days of autoconf-trouble anylonger - i'm counting the days when autoconfs really works, there're just a few. I've written down some concepts for an universal crossplatform compiling/building toolkit, which also supports crosscompiling and sysroot'ing as fundamental concepts and abstracts from platform or toolchain specific stuff (ie. universal parameter set for common things like compiler options, pathes, etc, etc). I really cant understand why it seems that I'm the first one really working on that ... You aren't. I agree auto* sucks, but there isn't a viable alternative that works today. We are the httpd server project, not the autoconf replacement project. -Paul
