Re: mod_actions 1.32 patch never made it to 2.0
André Malo wrote: * Cliff Woolley wrote: So why is this same general behavior unconditional in httpd 1.3 but non-existant in 2.0 and requires a virtual flag on 2.1? Andre? Thoughts? The virtual thing was your doing... see STATUS file. It's already voted for backport, just didn't make it yet... The reason for the virtual flag is that it should be a user decision whether the httpd should generate the 404 (with errordocument and all) or not. IMHO the unconditional behaviour in 1.3 was a mistake (made in version 1.3.10). 2.x was forked in 1.3.9 :-) I agree. Action was designed to enable processing files via CGI scripts, not to handle arbitrary URLs. Ryan's example (and most others that want this behavior) would be more cleanly handled with a simple ScriptAlias /foo /full/path/to/cgi-bin/printenv Joshua.
Re: Apache HTTP Server 2.1.2 tagged...
+1, lets get something out there for the community to test. If we have to go through a bunch of 2.1.x-betas before we feel comfortable with branching, so be it. Brad [EMAIL PROTECTED] Monday, December 13, 2004 4:30:29 PM --On Monday, December 13, 2004 2:40 PM -0700 Paul Querna [EMAIL PROTECTED] wrote: This would be 2.1.2-beta right? Not 2.2.0-beta1? Correct. Our first 'beta' release doesn't necessarily mean that it'd be 2.2.0-beta1. We can have as many 2.1.x betas as we want. However, I think it was said that the 2.2.0 branch will start with some 2.1.x beta - I just don't think we're quite at the branch point yet, but, IMHO, we should try to get some folks pounding on 2.1.x... -- justin
Re: Proposal: Listen sections
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 For some reason I bounced enough email to get booted off of the list. Bah. Anyways, I was looking at Rici's proposal, and I think I really like it. It seems more to match the way that people think about vhosts, and it seems to be in the spirit of what the NameVirtualHost directive tries to mean now. Seems like this would be easier to explain to people. Of course, lots of folks are going to want their existing configuration to keep working, which could be a bit of a pain. Although probably nothing that a few Perl scripts couldn't solve. - -- Rich Bowen - [EMAIL PROTECTED] As we trace our own few circles around the sun We get it backwards and our seven years go by like one Dog Years (Rush - Test for Echo - 1999) -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBvweyXP03+sx4yJMRAsMQAJ9SDT/W37xJCc0d2IJ6kmbfC6YjWgCeLST1 zSqCe1fzi5xcs+Ti/MVNlAI= =bVEm -END PGP SIGNATURE-
RE: [EMAIL PROTECTED] RE: Apache SSL Feature - Please Advise (PATCH for mod_ssl)
Thanks for the explanation, Joe. Here is the modified patch. Should I open a bug report and/or create doc? Whatever will facilitate incorporation into the soonest possible release, please advise. regards, tt -Original Message- From: Joe Orton [mailto:[EMAIL PROTECTED] Sent: Monday, December 13, 2004 11:59 AM To: TAYLOR, TIM (CONTRACTOR) Cc: [EMAIL PROTECTED] Subject: Re: [EMAIL PROTECTED] RE: Apache SSL Feature - Please Advise (PATCH for mod_ssl) On Fri, Dec 10, 2004 at 04:33:15PM -0500, TAYLOR, TIM (CONTRACTOR) wrote: Thanks, Joe. Neither of the backwards-incompatible solutions look particularly desirable. I can't think of a better way than Patch 3 really. It would be nice if there was some way of just picking out the DNs by name from the already configured SSLCACertificate* chain e.g. SSLCADNRequest /C=US/O=Blah/OU=... to avoid the chance of having a mismatch where the client is sent the wrong DNS, but you get into syntax issues and I don't know if OpenSSL even supports parsing dnames like that. I thought about that too. It seems like a lot to do to get a stack of DNs built. But you know the OpenSSL code handles the I/O so well as is, I chose the lazy (smart) code reuse route. I haven't even bothered to look at the FindCAList code. Also, yes a person can, with this patch, in place shoot themself in the foot by requested CAs that he doesn't configure for trust. Yup, it's not a big deal and your patch is pretty simple. A directive like SSLCADNRequest would probably be hard to document coherently anyway. I don't think there's any need for the SSLCAProxyDN* you added in your patch, there is no equivalent point where the client sends DNs, but otherwise it looks OK. Could you resubmit the patch without that bit? I am not sure I understand. The func ssl_init_proxy_ctx() calls the same ssl_init_ctx() that ssl_init_server_ctx() does. And ssl_init_ctx() calls ssl_init_ctx_verify() which loads client auth cert stuff. To take the proxy directive support out would cascade into more changes to see if a function is executing for a proxy or not. Please clarify and I'll update the patch. The SSLProxy* directives control the operation of mod_ssl when it is acting as an SSL *client* in the case where mod_proxy is used to proxy a request to a remote SSL server. But these new directives have no meaning for an SSL client, only for an SSL server. The existing SSL_init_FindCAList() call from ssl_init_proxy_ctx() is indeed already superfluous (but harmless); that part of your patch is OK, it's just the addition of the new SSLProxy* directives which should not be done. Regards, joe
Re: [PATCH] fixing broken gnu ld (mis)detection problem
* Joe Orton [EMAIL PROTECTED] wrote: Yeah, that was fixed in 1.5.10. For an autoconf 2.59-generated configure script the only reference to grep -E is in the test to see whether grep -E works or not, so that looks fixed to me too. well, i've tried to regenerate configure with the newest autoconf, but without any effect. new and old files dont differ. ergo problem remains unsolved, a clean build is nearly impossible. btw: i've tried the --with-gnu-ld option, but also without any noticable effect. 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: autoshit addiction [WAS: [PATCH] fixing broken gnu ld (mis)detection problem]
* Patrick Welche [EMAIL PROTECTED] wrote: snip Does this mean the following macro should appear somewhere in httpd's configury? -- Macro: AC_PROG_EGREP Check whether `$GREP -E' works, or else search the user's `PATH' for `egrep', and `gegrep', in that order, and set output variable `EGREP' to the one that accepts the longest input lines. partially. we could check if egrep is working with extended regex. trying to detect the right grep command and setting up an variable wouldn't help much, since the rest of the autoconf stuff simply doesn't use it. i had exactly this problem in a couple of other packages. 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: 2.1.2-alpha http/ftp proxy/cache problems
Mladen Turk wrote: Since the fix is trivial, I'll commit the changes ASAP. Will you be able to retest upon the commit? No problem, if you let me know the svn id(s), as I currently don't have svn installed and thus will need to extract the changes through the web interface.
Re: svn commit: r111837 - in httpd/httpd/trunk/modules: debug test
Paul Querna wrote: [EMAIL PROTECTED] wrote: snip httpd/httpd/trunk/modules/debug/.deps httpd/httpd/trunk/modules/debug/Makefile I thought these should both be generated, not checked into svn? Yep, but how does one tell SVN to ignore them?? :/ -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ There 10 types of people: those who read binary and everyone else.
Re: Why bundling 3rd-party packages anyway ? [WAS: A zLib Update....?]
* André Malo [EMAIL PROTECTED] wrote: * Enrico Weigelt wrote: * André Malo [EMAIL PROTECTED] wrote: * Enrico Weigelt wrote: Why is pcre bundled anyway ? Other packages (ie zlib or expat) are also not bundled, so why pcre ? vendor branch. how does it answer my question ? It gives you a piece of information, that you perhaps didn't know yet. Here's another one: expat is bundled with apr-util. I already knew that maintaining own branches for just a single client package someday makes troubles - in case you meant this. zlib is optional. So is openssl. right. and thats good. why not the same with expat and 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: svn commit: r111837 - in httpd/httpd/trunk/modules: debug test
Jim Jagielski wrote: Paul Querna wrote: [EMAIL PROTECTED] wrote: snip httpd/httpd/trunk/modules/debug/.deps httpd/httpd/trunk/modules/debug/Makefile I thought these should both be generated, not checked into svn? Yep, but how does one tell SVN to ignore them?? :/ svn pedit svn:ignore modules/debug The svn:ignore property on a directory is like the .cvsignore file, a newline separated list of patterns to ignore. -garrett
Re: WebDAV and reading / writing files as system users
* Graham Leggett [EMAIL PROTECTED] wrote: Hi, I am busy researching the idea of an Apache + DAV server that would do the job of what a typical Samba server does now - file sharing. An Apache server would have the advantage of native SSL support, flexible authentication configuration, etc. If you just want I fileserver, you'll probably like to have a look at Coda or Intermezzo. They both support strong authentication, clustering and replication. And if commercial stuff is an option, Novell Netware also does a good job. snip The perchild mpm seems to be the closest thing to what I am looking for, but the manual warns that it is not functional. Is this still the case? Perchild doesn't really work - its conceptionally insecure. (users can ptrace their processes and so can - with a given chance - catch also other people's requests) You're probably interested in http://www.metux.de/mpm/ We currently only work based on vhost-name, not yet on auth-credentials, but this is planned. There're some issues to think about, ie. we must ensure that mod_auth gets in before we fetch the request in the multiplexer *or* we have to do authentication by ourselves. We've got similar problems with SSL by the way ... 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: svn commit: r111837 - in httpd/httpd/trunk/modules: debug test
Jim Jagielski wrote: Paul Querna wrote: [EMAIL PROTECTED] wrote: snip httpd/httpd/trunk/modules/debug/.deps httpd/httpd/trunk/modules/debug/Makefile I thought these should both be generated, not checked into svn? Yep, but how does one tell SVN to ignore them?? :/ Nevermind... used 'svn propset svn:ignore' on the debug dir using the props for the loggers dir as a base :) -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ There 10 types of people: those who read binary and everyone else.
Re: WebDAV and reading / writing files as system users
* Sander Temme [EMAIL PROTECTED] wrote: snip Could you mount the DAV filesystem on the local box, so that all access would go through DAV? That way all access would go through Apache and it could have its own sandbox. a) are there *working* DAV filesystem drivers for several OS'es b) performance ? 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: WebDAV and reading / writing files as system users
* Graham Leggett [EMAIL PROTECTED] wrote: snip But if this proper filesharing concept is to work properly, then at some point the DAV server will have to support some kind of interaction with the filesystem along far better lines than the current one user owns all. Another point: why not using the kernel's access control when its proven for decades ? btw: probably apache is not really the right tool for an fileserver. aren't there other DAV servers out there ? 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: WebDAV and reading / writing files as system users
* Joshua Slive [EMAIL PROTECTED] wrote: Hi, Yes. I don't know of anyone successfully using perchild. There is another group working on a successor called something like mpmmux, but they've been rather quite too. metuxmpm has been reported to be running successfully in production environments. snip Can perchild support the idea of becoming a user specified via an auth module using something like basic authentication? Not with its current design. For one thing, it needs to have a pool of child threads available for each possible user, which would make it rather inappropriate for a large number of users. For another thing, it currently only supports different users on a per-vhost basis. But I suppose that last restriction would be easy enough to relax. We've exactly the same problems in metuxmpm for now :( (see my last posting) But we're already working on demand-starting. 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: svn commit: r111895 - in httpd/httpd/trunk: modules/cache modules/debug modules/experimental support
[EMAIL PROTECTED] wrote: Author: nd Date: Tue Dec 14 15:01:47 2004 New Revision: 111895 URL: http://svn.apache.org/viewcvs?view=revrev=111895 Log: svn:eol-style = native Thanks!! -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ There 10 types of people: those who read binary and everyone else.
Re: 2.1.2-alpha http/ftp proxy/cache problems
Andreas Steinmetz wrote: 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. Hi, As Justin said it has nothing to do with the cache. The problem is with the single forward/reverse proxy worker that is not thread safe for backend address cache. Address cache is a great thing offering up to 20% higher performance compared with previous implementation, but for workers that does not use it (like using Rewrite), it has a address cache reusage bug. Since the fix is trivial, I'll commit the changes ASAP. Will you be able to retest upon the commit? Regards, Mladen.
Re: [PATCH] fixing broken gnu ld (mis)detection problem
On Tue, Dec 14, 2004 at 03:20:26AM -0600, William A. Rowe, Jr. wrote: Of course we could do that. However, it's entirely against the first principal of httpd, which is that this project builds against more old and crufty operating systems installs than most utilities, sans 'cat' :) Seriously, we could target only latest-n-greatest, but that goes against the grain of many participants. I think we should be much stricter for the releases we make and rather leninent at buildconf-time. I think Joe's proposed bumping up to a mandatory autoconf 2.5x (for everyone) because we keep getting nailed on autoconf 2.13 bugs. That's goodness. And, I think we should enforce libtool 1.5.10 for any future release that we produce (i.e. in httpd-dist/tools/releasecheck.sh). If a developer has anything above libtool 1.3, it'll work (for some definition of 'work') - but they're on their own if they run into problems. Of course, if we posted 2.1.2 as a 'public' beta, then we could start to get feedback if the ac2.59/lt1.5.10 combo breaks anyone. =) -- justin
Re: [PATCH] fixing broken gnu ld (mis)detection problem
Quoting Enrico Weigelt [EMAIL PROTECTED] (2004-12-14 04:50:36 GMT): * Patrick Welche [EMAIL PROTECTED] wrote: snip Is part of the problem automake avoidance? AFAIR httpd just uses No, autoconf is bad enough, automake will make it even worse. Dont expect apache to remain in so many distros if you switch to automake and bring distributor's life ten steps nearer to hell. That's pure, undiluted FUD, and you know it. -- SOUTH UTSIRE FORTIES SOUTHERLY OR SOUTHWESTERLY 6 TO GALE 8, VEERING NORTHWESTERLY 4 OR 5 IN NORTH LATER. OCCASIONAL RAIN. MODERATE OR GOOD
Re: autoshit addiction [WAS: [PATCH] fixing broken gnu ld (mis)detection problem]
On Tue, Dec 14, 2004 at 05:33:26AM +0100, Enrico Weigelt wrote: It is of these macros which are doing regex test. My build system runs the GNU grep v. 2.4.1. A short look the grep --help exposes, that the -E option has to be passed when using extendet regex. Simply calling egrep does not work here. On another system, running newer grep (2.5.1) evrything is fine. So it seems gnu grep changed its behaviour when called as egrep - in general a very bad thing. The only clean solutions are: a) use the old semantics b) encapsulate the grep command (into a shell function) and first check which version to use c) define grep-2.5.x as an build-tool dependency, check if its really installed and working an spit out at least an warning if it doesnt. Again its an autoconf problem. More than just a bug. Does this mean the following macro should appear somewhere in httpd's configury? -- Macro: AC_PROG_EGREP Check whether `$GREP -E' works, or else search the user's `PATH' for `egrep', and `gegrep', in that order, and set output variable `EGREP' to the one that accepts the longest input lines. Cheers, Patrick
Re: mod_actions 1.32 patch never made it to 2.0
* Cliff Woolley wrote: So why is this same general behavior unconditional in httpd 1.3 but non-existant in 2.0 and requires a virtual flag on 2.1? Andre? Thoughts? The virtual thing was your doing... see STATUS file. It's already voted for backport, just didn't make it yet... The reason for the virtual flag is that it should be a user decision whether the httpd should generate the 404 (with errordocument and all) or not. IMHO the unconditional behaviour in 1.3 was a mistake (made in version 1.3.10). 2.x was forked in 1.3.9 :-) nd -- Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook! Ook? Ook. Ook? Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook? Ook. Ook! Ook! Ook? Ook! Ook. Ook? Ook. Ook. Ook. Ook. Ook. Ook. Ook! Ook. Ook! Ook! Ook! Ook! Ook! Ook.
Re: [PATCH] fixing broken gnu ld (mis)detection problem
On Tue, Dec 14, 2004 at 03:58:42AM -0600, William A. Rowe, Jr. wrote: I would like to see ALOT of feedback to current-testers or dev or even apache-modules of the alpha before declaring first beta. Once beta - we should be very adverse to API changes - our module authors will want to fix once and be done. Or should we just trash the idea of alphas since not enough people are testing? Heck, while we are at it, lets just declare it GA. The alpha better work for a good number of folks before we go to beta. Then ya - as you say, the oddball kernel/distro issues will start popping up and be fixed pretty easily before GA. A brief reminder of what Paul brought up, and I agree with: Corporate project managers need a better sense of the release schedule before they build test-time into their schedules. I am not asking for hard-and-fast release dates, because httpd is released when it is ready and not on artificial deadlines. A completely open-ended release date -- as is currently the case -- is all but ignored by project managers. Why spend time testing something that is not going to be released for maybe another year and will probably change immensely between now and then? However, if releases were aimed for every, say, 6 months, with a tag and semi-freeze two months prior, then I think we would see a lot more testing by corporate users (who aren't already very involved in this list) on those tags. Cheers, Glenn
Re: svn commit: r111830 - /httpd/httpd/trunk/modules/proxy/mod_proxy.c /httpd/httpd/trunk/modules/proxy/mod_proxy.h /httpd/httpd/trunk/modules/proxy/proxy_ajp.c /httpd/httpd/trunk/modules/proxy/proxy_http
On Tue, 14 Dec 2004 [EMAIL PROTECTED] wrote: ap_rputs(apr_strfsize(worker-s-transfered, fbuf), r); trthWr/thtdNumber of bytes transfered/td/tr\n Furthermore, it's transferred. --Cliff
Re: Hackathon during Q1 2005?
Justin Erenkrantz wrote: 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. So if all the projects follow your lead, then instead they'll be too over-committed to attend (since they'll have to go to all these different hackathons for each project). I don't see how you can win this one - overcommitted people are overcommitted - they either want to give you their attention or they don't. If they don't you aren't going to engineer them into doing it. So, I'm opposed to project-specific hackathons - its inefficient and antisocial. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff
Re: Hackathon during Q1 2005?
William A. Rowe, Jr. wrote: At 06:19 AM 12/11/2004, Dirk-Willem van Gulik wrote: On Fri, 10 Dec 2004, 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. So, how many people would be interested, willing, and able to make it? Alternatively - I/www.asemantics.com is willing to arrange one in Europe - the Netherlands. Perhaps a lot later in the year -OR- at the SAME time(and wee then will link the two locations). Location will be easy to reach from Airport Schiphol by public transport. Need about 1 or 2 months lead time. In the quarters that ApacheCon/US and ApacheCon/Euro come together, this seems redundant. My other question - does it make sense to do both an EU and US in the same quarter? Or if we get 2 cons/year, should we just add 2 hackathons/year, one in each continent? There will be a hackathon at Apachecon/EU. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff
Re: svn commit: r111837 - in httpd/httpd/trunk/modules: debug test
[EMAIL PROTECTED] wrote: snip httpd/httpd/trunk/modules/debug/.deps httpd/httpd/trunk/modules/debug/Makefile I thought these should both be generated, not checked into svn? -Paul
Re: yet another autoconf torture
* Joe Orton [EMAIL PROTECTED] wrote: snip It is possible to support cross compilation with autoconf-based build systems. configure supports this by use of cache variables; standard practice is to build up a config.site file with the correct test results for the target (e.g. ac_cv_func_setpgrp_void=yes), and set CONFIG_SITE to point at that file. More work may be needed on the configure scripts to use AC_CACHE_CHECK appropriately. Ah, do I have to patch anything for that or does it run out of the box ? I had exactly the same problem with openssl. I fixed it by simply pulling off several checks (ie the file-exist-checks simply refused to work in crosscompile mode) and recreated configure. The tests I removed were meaningless for my platforms nevertheless. But the problem is another point: autoconf is not really made for crosscompiling. the support for different tool commands and the so called crosscompile support (simply disable a bunch of checks or refuse to work when it doesnt know what to do now) is just an ugly hack, neither are sysroot builds supported in any way. To get a really reliable solution for that, we need an new, well designed universal toolchain frontend. this of course could also be shipped with apache for a while (- vendor branch ... grrmpf). But the Makefiles still won't work since they have no separate of host and target $CC etc, yet need to build and run executables on the host system in several places. So there is definitely more work needed there. Right. I'm passing my crosstoolchain commands (CC,LD, ...). But this only works as long as the package doesnt bring its own host-side-tools. We need at least an *clear* distinction between host und and target compilation. These are all questions for the unitool, which I already announced here. For those who dont remember: Wiki: http://nibiru.borg.metux.de:7000/wiki/index.php/Universal_Toolchain Maillist: [EMAIL PROTECTED], subscribe via [EMAIL PROTECTED] 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: mod_actions 1.32 patch never made it to 2.0
* Ryan Bloom [EMAIL PROTECTED] wrote: On Tue, 14 Dec 2004 17:13:23 +0100, André Malo [EMAIL PROTECTED] wrote: * Ryan Bloom [EMAIL PROTECTED] wrote: I have a couple of pretty big issues with this response. 1) You have a configuration in Apache 1.3 that doesn't work in Apache 2.0, but the config directives don't have to be changed at all. This is something that we worked really hard not to do in 2.0. There should never be a config in 1.3 that just gives the wrong results in 2.0 without any way for the user to understand why. Ah? That's what one would call a bug. While breaking the behaviour in 1.3.9/1.3.10 nobody even thought about this issue. It's *still not documented that it was broken*. And a lot of users suffered of it, including me. Suffered how? How exactly did a change that made the code accept more configs break your config? Also, it isn't that nobody thought of this when making the change to 1.3. Looking through the mailing list archives, I see Ben Laurie specifically had a problem with Location and mod_actions that Manoj fixed. I haven't found the whole thread about the problem, just the RM notes about it. So, we have a bug that was fixed in 1.3 that was reintroduced in 2.0, and 2.0 is solving the problem the completely opposite way. Instead of defaulting to doing what 1.3 does, you default to the opposite position. That is what I am saying is so wrong here. Pick the same default as 1.3, and allow the option to override that default. Huh?! I *wanted* to get a 404 from the httpd. Did you really read my posting? There was introduced a bug, nothing more. What I'm doing now *is* to allow to use the same config for 1.3.9 and 2.0 and 2.1. 2) In choosing to default to the 404, you have broken anybody who wants to share 1.3 and 2.0 config snippets. No, see above. Additionally 1.3 and 2.0 *are* different, so this is null argument at all. I'm sorry, but no it is not. I know something about this, and we spent a lot of time and energy trying to ensure that a config that worked in 1.3 worked the same way in 2.0. Well, you had no luck, it seems. nd
Re: Towards a generic database connection API
big_snip / Aehm, what kind of database access are we talking about ? Full SQL quering or just something like sendmail's map-API ? If we really need full SQL, I would suggest something like unixodbc or perl DBI. But I'm not in favour of reinventing the wheel and having yet another SQL framework which redundantly eats up resources. An smaller api (ie sendmail-type) should also not directly go to apr, instead be an separate package which is simply imported by the apache stuff like others too. 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: svn commit: r111892 - /httpd/httpd/trunk/docs/manual/mod/mod_dumpio.html /httpd/httpd/trunk/docs/manual/mod/mod_dumpio.html.en /
[EMAIL PROTECTED] wrote: adjust properties: - svn:eol-style = native - svn:keywords = LastChangedRevision for mod_dumpio.xml Are these documented somewhere? Not what they mean, but what our standards are as far as these are concerned, etc...? I hate looking like an idiot :) -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ There 10 types of people: those who read binary and everyone else.
