[jira] Updated: (MODPYTHON-78) No support for Apache 2.2 yet
[ http://issues.apache.org/jira/browse/MODPYTHON-78?page=all ] Nicolas Lehuen updated MODPYTHON-78: Summary: No support for Apache 2.2 yet (was: No support for Apache 2.1 yet) Now that Apache 2.2 is out, and mod_python 3.2 close to release, maybe it's time to have a look at this for mod_python 3.3 ? No support for Apache 2.2 yet - Key: MODPYTHON-78 URL: http://issues.apache.org/jira/browse/MODPYTHON-78 Project: mod_python Type: Bug Components: core Versions: 3.2 Reporter: Nicolas Lehuen Fix For: 3.3 See http://article.gmane.org/gmane.comp.apache.mod-python.devel/1425 for some remarks by Jorey Bump, raised during the 3.2.1-BETA tests. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] Updated: (MODPYTHON-78) No support for Apache 2.2 yet
Nicolas Lehuen (JIRA) wrote: [ http://issues.apache.org/jira/browse/MODPYTHON-78?page=all ] Nicolas Lehuen updated MODPYTHON-78: Summary: No support for Apache 2.2 yet (was: No support for Apache 2.1 yet) Now that Apache 2.2 is out, and mod_python 3.2 close to release, maybe it's time to have a look at this for mod_python 3.3 ? +1
Re: What's in a URL ?
Hi Jim,1. I chose the colours to aid in reading, but I tried to regroup items logically. For example I chose a weird orange for environment variables. Anyway, I'm thinking that I could use colors to represent the dependencies (what data comes from the client, what data comes from the server, and after this dichotomie, a set of colors for Apache-level APIs, CGI env-vars, and mod_python). That's a work in progress... 2. I don't know - I did not made this to distribute, just to fuel our discussion about the various way to get information about the request, and the mess it can cause. But if you guys find it worth publishing, why not. Regarding 2c, I solved the problem by dropping OpenOffice and doing it in HTML (I exported from OO to HTML and cleaned up the mess manually). I've checked in the result in the Doc directory.Regards,Nicolas 2005/12/3, Jim Gallacher [EMAIL PROTECTED]: Nicolas Lehuen wrote: Hi, Following last week's discussion about the various parts composing an URL and how to get them from Apache and/or mod_python, here is my first try at a chart that sums up what we know. It show a sample URL and how different components of the application server see it or contribute to it.Interesting view. Couple of questions:1. Any significance to the colours or are they just to aid in reading?2. How do you envisage this being distributed? a. On the mod_python website?b. Once it's complete, rewrite it in LateX so it's integrated withthe generated html-docs?c. Bundle with html-docs but generate the file (html or pdf) fromthe ods source? From the perspective of creating the releases 2.b is likely best, butmaking this kind of table in LaTeX goes *way* beyond my skills.If you see us using 2.c then we need to think about how to automate openoffice to create the file during the packaging.Jim
Re: Apache 2.2 released - apparently breaks the mod API compatibility with 2.0
I'll have to wait for the Win32 source code tree to be released to build it and test your patch. Hopefully it'll be out soon.Is there a wait to use macro directives so that we don't need to maintain two separate branches ? A define that we could pass when building mod_python to select the Apache version we're building against, maybe ?
Regards,Nicolas2005/12/3, Jorey Bump [EMAIL PROTECTED]:
Nicolas Lehuen wrote: http://httpd.apache.org/download.cgi Apache 2.2 add-in modules are not compatible with Apache 2.0 or 1.3 modules. If you are running third party add-in modules, you will need to
obtain new modules written for Apache 2.2 from that third party before you attempt to upgrade from Apache 2.0. Great, now we're having to support three separate version : mod_python
2.7 for Apache 1.3.x (though it's a bit unsupported now, isn't it ?), mod_python 3.2 for Apache 2.0.x and mod_python 3.2.x for Apache 2.2... It's not a big surprise, though, since we already have this issue :
http://issues.apache.org/jira/browse/MODPYTHON-78 Does anyone knows anything about the API changes ?I've attached a source tree patch against
3.2.5b that will work withapache 2.2.0. It still fails one test in the test suite, but seems toload fine in apache and run modules in Publisher.To apply the patch, move into the source code directory and issue the
following command: patch -p1 /path/to/mod_python-3.2.5b.patchSorry, I don't do Apache on Windows. Could someone follow up withinstructions for that platform (beyond install Cygwin)? :)
Here are some key points:APR_STATUS_IS_SUCCESS is gone.apr_sockaddr_port_get is gone.mod_auth is now mod_auth_basic.auth_module is now auth_basic_module.Affected files are:src/connobject.c
src/filterobject.ctest/test.pyTo fix the APR_STATUS_IS_SUCCESS issue, I deleted the code that used it,without replacement. That may be suboptimal, if the code serves a usefulpurpose. :)
To fix the apr_sockaddr_port_get issue, I restored makesockaddr fromconnobject.c in 3.2.1b. This was obviously replaced for a reason inlater versions, with the unfortunate choice of a deprecated functionfrom the API. The original issue needs to be revisited to determine a
more compatible solution.I'm unable to diagnose the remaining failure in the test suite: * Testing internally (status messages go to error_log)F==
FAIL: test_internal (__main__.PerRequestTestCase)--Traceback (most recent call last): File test.py, line 1249, in test_internal
self.fail(Some tests failed, see error_log)AssertionError: Some tests failed, see error_log--Ran 43 tests in 61.161s
FAILED (failures=1)FStopping Apache.../usr/local/apache2.2.0/bin/httpd -k stop -f/home/jorey/src/mod_python-3.2.5b/test/conf/test.conf==
FAIL: testPerRequestTests (__main__.PerInstanceTestCase)--Traceback (most recent call last): File test.py, line 1805, in testPerRequestTests
self.failUnless(result.wasSuccessful())AssertionError--Ran 6 tests in 107.536sFAILED (failures=1)The error log includes this line at the end:
logs/error_log:[Sat Dec 03 15:31:15 2005] [error] [client 127.0.0.1]..F.\n==\nFAIL:test_server_members
(tests.SimpleTestCase)\n--\nTraceback(most recent call last):\nFile/home/jorey/src/mod_python-3.2.5b/test/htdocs/tests.py, line 446, in
test_server_members\nself.fail(server.keep_alive_timeout should be15.0)\nAssertionError: server.keep_alive_timeout should be15.0\n\n--\nRan
8 tests in 0.336s\n\nFAILED (failures=1)\ndiff -uNr mod_python-3.2.5b/src/connobject.c mod_python-3.2.5b.new/src/connobject.c--- mod_python-3.2.5b/src/connobject.c2005-11-12 13:59:35.0
-0500+++ mod_python-3.2.5b.new/src/connobject.c2005-12-03 15:26:27.0 -0500@@ -78,12 +78,6 @@ rc = ap_get_brigade(c-input_filters, bb, mode, APR_BLOCK_READ, bufsize); Py_END_ALLOW_THREADS;
-if (! APR_STATUS_IS_SUCCESS(rc)) {-PyErr_SetObject(PyExc_IOError,-PyString_FromString(Connection read error));-return NULL;-}- /*
* loop through the brigade reading buckets into the string*/@@ -312,24 +306,17 @@***utility func to make a socket address*/- static PyObject *makesockaddr(struct apr_sockaddr_t *addr)
-{+{ PyObject *addrobj = makeipaddr(addr); PyObject *ret = NULL; if (addrobj) {-apr_port_t port;-if(apr_sockaddr_port_get(port, addr)==APR_SUCCESS) {-ret = Py_BuildValue(Oi, addrobj, port );
-}-else {-PyErr_SetString(PyExc_SystemError,apr_sockaddr_port_get failure);-}+ret = Py_BuildValue(Oi, addrobj,
Re: Apache 2.2 released - apparently breaks the mod API compatibility with 2.0
Nicolas Lehuen wrote: Is there a wait to use macro directives so that we don't need to maintain two separate branches ? A define that we could pass when building mod_python to select the Apache version we're building against, maybe ? If it's possible to make the code in connobject.c filterobject.c compatible with both Apache 2.0 2.2, then the only unavoidable incompatibility is in test.py (with the auth stuff). Since that script already calls httpd, it could discover the version with httpd -v (unless mod_python has an internal record of this, already) and adapt accordingly. These diffs were really tiny to get a seemingly working version to run with Apache 2.2. Finding compatible alternatives to the deprecated items will deliver better results than version sniffing, IMHO. I just wish I was bright enough to comprehend what the lines in question actually do. :P
Re: Apache 2.2 released - apparently breaks the mod API compatibility with 2.0
Nicolas Lehuen wrote: I'll have to wait for the Win32 source code tree to be released to build it and test your patch. Hopefully it'll be out soon. Is there a wait to use macro directives so that we don't need to maintain two separate branches ? A define that we could pass when building mod_python to select the Apache version we're building against, maybe ? I'm sure there must be. If not perhaps we roll our own using some configure option, eg --with-apache2.2. I think it would be a big mistake to try and maintain 2 branches for apache 2.0 and 2.2. They can't be *that* different (and judging by Jorey's patch they are not). Jim
Upload hooks
I am trying to use the UPLOAD_HOOK in 2.06 to track the progress of the
upload. I understand the api doc. is out of sync, but from the Changes notes
I gathered something like the following should work:
my $req = Apache2::Request-new($r ,
UPLOAD_HOOK = sub {
$log-info(PARAMS: . join(',',
@_));
my ($upload, $data_len) = @_;
$size_received = $size_received +
$data_len;
})
|| $log-error(UP: could not create Apache2::Request);
Unfortunately it looks like my hook receives only one argument, the name of
the file being uploaded. The log_info above generates this:
[info] [client 192.168.0.117] PARAMS: 10M.bin,,
I have also tried accessing $upload-size in the hook, without success -
$upload seems to be a scalar.
Any hint on how to achieve this would be greatly appreciated!
Thanks,
Franck
RE: Upload hooks
Had a look at the glue source code, and it looks like the hook gets passed a
Param, and a data buffer. Using
my ($upload, $buffer) = @_;
$received = $received + length($buffer);
solved my problem...
Regards,
Franck
-Original Message-
From: Franck Mangin [mailto:[EMAIL PROTECTED]
Sent: Saturday, December 03, 2005 3:38 PM
To: apreq-dev@httpd.apache.org
Subject: Upload hooks
I am trying to use the UPLOAD_HOOK in 2.06 to track the
progress of the upload. I understand the api doc. is out of
sync, but from the Changes notes I gathered something like
the following should work:
my $req = Apache2::Request-new($r ,
UPLOAD_HOOK = sub {
$log-info(PARAMS: .
join(',',
@_));
my ($upload, $data_len) = @_;
$size_received =
$size_received +
$data_len;
})
|| $log-error(UP: could not create Apache2::Request);
Unfortunately it looks like my hook receives only one
argument, the name of the file being uploaded. The log_info
above generates this:
[info] [client 192.168.0.117] PARAMS: 10M.bin,,
I have also tried accessing $upload-size in the hook,
without success - $upload seems to be a scalar.
Any hint on how to achieve this would be greatly appreciated!
Thanks,
Franck
Re: svn commit: r351702 - /httpd/httpd/branches/2.2.x/Makefile.win
* Joshua Slive wrote: I highly doubt that many people use the bundled docs. They are not browsable on a default configuration and certainly require the server to be running before they are usable, which means they are of little help to upgraders. We also build windows-help format docs, which would be much more appropriate for win32 users, but I don't think we have those for 2.2 yet. Ah yes. This is, because my box crashed some time ago and I don't have a working windows installation yet. Anyone around here with about an hour to spare for booting (!) into each language (de, en, es, ja, ko) and building the chm docs? I'm happy to help through the process. (The necessary settings and requirements are also described the `build` help). 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: buildconf against installed APR
Luc Pardon wrote: Both apr and httpd ship with generic spec files included. The apr spec files are designed so that you can install apr-0.x and apr-1.x side by side without conflicts, As far as the included apr spec files are concerned, this is simply not true. Last time I looked, the spec files for 0.9.7 and 1.2.2 use the same package names, i.e. apr and apr-util. To install two major versions of the same package, use the following to install: rpm -i packagename.rpm Packages in the v0.x branch and the v1.x branches are designed not to conflict with each other. For examples of another RPM package that is installed by default in this way, see the kernel RPMs. But because of the name, rpm will consider apr-1.2.2 simply a later version of apr-0.9.7, exactly as told. Therefore if you install 1.2.2 it will obligingly _remove_ all the 0.9.7 stuff, including all the apr-0 dirs and their content. Bye-bye side-by-side. This will only happen if you use the rpm -U (meaning upgrade) instead of rpm -i (meaning install). tell me that, as a workaround, I can install with rpm --install instead of the normal rpm --upgrade or rpm --freshen but that is not standard, normally only used for kernel installs, and dangerous in just about all other cases. It's not dangerous at all, and quite standard. See the RPM docs for details. And there is no need for a workaround either. The apr is not the only one that must be able to support multiple versions side-by-side. Standard practice is to use different package names by including the version number _in_ the package name (eg apr0 and apr1), as Oden correctly did. This is an ugly kludge. There are two techniques to handle this. One is the kernel way, the second is by publishing a -compat library for the old version. As -compat libraries typically don't have -devel packages, the kernel style install was chosen. As to the included httpd.spec, that is not generic either, if I may say so. As I pointed out a few weeks ago, it does not even build out of the box on a clean machine. To reiterate: it mandates a separate, pre-existing install of apr/apr-util or else it dies. That is the intention. The APR is a completely separate library, it has no business being binary packaged with httpd. If it is, how do you install a binary package of httpd+apr with a binary package of subversion+apr? You don't, as you get conflicts. APR is packaged in the httpd tarball for historical and convenience reasons for people building from source. The apr code is right there in the httpd tarball but it has no purpose as you can't use it, you have to go get apr rpm packages elsewhere. Either apr is bundled or it is not bundled, one can't have it both ways. You can. I know (or at least have the impression) that you feel strongly about the spec files that you contributed, and I don't want to offend. But there is definitely room for improvement, to say the least. A good spec file - especially if it comes with the product - should build everywhere, under any circumstances, not just on the author's machine (and please don't take this as a personal attack, it is not meant as one). If it doesn't build on your machine, I definitely want to hear about it, but so far it seems that it does build, the package just isn't arranged how you want it. I can assure you that a lot of thought has gone into the APR and the Solaris packaging, for the purpose of launching APR as the standalone package that it should be. There is a lot of precedence for the current layout (the RPMs were originally Redhat RPMs, with the patches and a lot of the file moving removed). Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: Directions for Win32 binary httpd
Ok, I've come to a conclusion; for the coming release, only msvcrt.dll builds under Visual C++ 6.0 make sense as our binary distribution. I'm not suggesting we dismiss the potential win of supporting our Studio 2005 compiler users(!) But let's quickly compare... . binary users generally aren't building modules, they need to plug into widely distributed binary components. . source users generally can build anything from source, if they need to. If they want to interface several components, they can build our source tarball with any compiler they like, including the 1 year free license of Studio 2005. . it's pretty trivial to build/install httpd with one of several pretty minimal unix toolchains available. It seems that most of the communites are still in VC 6. Remember the key reason we keep using it, MS dropped support for exporting makefiles. With no makefiles, you are roped into supporting only version x or newer Studio products. With .dsp/.dsw solutions, we can export makefiles on the old reliable VC 6, and users can load/convert these into Studio 2000/03/05. So I'll move ahead with all the msi tweaks required for our changed files, and we can reevaluate the state of things 6 mos or a year from now when we are almost ready to ship Apache X :) That's my conclusion, I'm still more than happy to hear out dissenting opinions. Speak up quick, though, planning to have a package up in /dev/dist by Sunday night for review, and push it out sometime early next week. Bill
apr_socket_sendfile not found on OS/X?
Hi. I just checked out the latest trunk of apr httpd on my mac, and can't build it anymore. it is complaining about apr_socket_sendfile not being defined. so I checked .. and apr.h has APR_HAS_SENDFILE as 0. the problem is sendfile_nonblocking calls apr_socket_sendfile ;(
Re: Comments on Authz_Provider implementation (was: Re: svn commit: r351547 - in /httpd/h)
Require directives in the form of: require user joe bob jane require ldap-user jmanager require ldap-group bigboys require valid-user I might have misunderstood something here, but this sounds like you are proposing to move all directives into the specific files for the authproviders. (This sounds like a good idea btw, as it most likely will make the auth system easier to follow since all provider specific routines are in the providers own file.) If this is indeed what is intended, then the thing that should be needed in mod_auth_basic and mod_auth_digest is some kind of wrapper function that determines which provider that is active and then calls the functions that are provider specific. Or possibly a function that retrieves the result from the provider and then applies it in an authtype specific way. The last one is probably the way to go (if possible) as it will mean less authtype specific code in the provider files. However, if you want to run several auth providers you will probably need some kind of Satisfy directive somewhere. An idea i previously brought up was to place the directive in mod_authn_alias (that probably should change name then, perhaps mod_authn_instance or something) and use a syntax similar to Satisfy ((instance1 instance2) | instance3) !passwd as this will add a great deal of flexibility to the auth system. If you leave mod_authn_alias to work as it does atm (as an optional part) you could still declare the access checks directly in the location that needs it, and you wouldnt need to use Satisfy for that either if the design is made carefully to allow interswapping to occur between the Satisfy directive in the alias module and the Require directive from the provider files (or some check in basic, depending on how you design it). If the auth providers all handle their own verification of users based on the require directives all this satisfy directive would need to do is get the results from the auth providers own checks and run the operations on it (if any). This would effectively make it possible to use several different authproviders and declare them as instances (pretty much the same syntax as mod_authn_alias uses now) and then use the satisfy directive to just calculate the access rights. Possibly these instances could be made specific to an authtype as well, which would allow users of httpd to mix different auth types and then only use the satisfy directive to check if the user has access or not. This would also make the config file less complicated to read as all instances could be declared in one place and then referenced from the Virtual Hosts or wherever you want to use them. It would also make it possible to add a specific file or other provider with users you DONT want to be able to log in, for example the passwd file where all system wide users and others are entered, or possibly just a new provider where you enters all the users that has been banned or whatever. Something like: AuthBasicProvider ldap1 file1 sql1 passwd AuthDigestProvider prov2 Satisfy ((ldap1 | file1 | sql1) | prov2) !passwd or: AuthProvider ldap1 file1 sql1 passwd prov2 Satisfy ((ldap1 | file1 | sql1) | prov2) !passwd would be all thats needed to exist in the folder/file/location that the access rules apply for. (Depending on if the auth type is defined in the instances or if the modules for auth_basic/auth_digest will define which instances are of which type.) How could we fit IP restrictions into this? require ip !192.168.0.0/24 10.0.1.5 Possibly have deny/allow from semantics 'silently' convert into require directives? Might be able to salvage backwards compat this way. As for the ip access, it could be made into a pure bread auth module if there was the will for it to happen as they would all handle their own auth checks (or possibly a common auth function in some common lib for all providers if theres alot of them that uses the same rules for checking access. (this would make for less duplicate code, but possibly make it less straightforward as well) Another idea for ip access instances might be an idea to use Allow and Deny, but in a different way: Allow 10.0.1.5 Deny 192.168.0.0/24 Deny 100.0.0.0 255.255.255.255 or something like the above. This would allow one instance of the ip access to include as many or as few of those directives as needed. (And possibly also make it easier for users to understand the usage of the ip access checker.) The instances of providers would be handy here too as all provider specific things would be gathered at one place, easier to get an overlook over the auth rules and much less scrolling of potentially (very!) long Virtual Host declarations (especially if you have some rewrite rules in it). As for the ip access it would most likely need the possibility of using several requires (or, see allow, deny above) in one instance (shouldnt be a problem if the provider themselves handle the authorization) or you could just use one
mod_auth[nz]_dbd password caching
Dear All, First of all, congratulation on the release of 2.2. I use mod_auth_pgsql at http://anyterm.org/my.html, and found a problem earlier in the year. To get reasonable performance you need to use the module's caching mechanism, but this cache is not flushed or updated when the database changes. So things don't work properly when the user changes their password. I started to think about fixing it myself but quickly realised that both the database and authentication frameworks were changing in 2.1+ and decided to wait before doing anything. I now see that 2.2 has mod_auth[nz]_dbd - great! However, as far as I can see from http://httpd.apache.org/docs/2.2/mod/mod_authn_dbd.html and the source, this new module doesn't do any caching. Is this true? To get the sort of performance that I need for my site I really need in-memory caching of passwords, but I also need to solve mod_auth_pgsql's non-updating problem. The solution to this is to use PostgreSQL's asynchronous notification mechanism: the module issues a LISTEN command and is then notified when the password table changes. I don't know if the APR DB interface has any support for this (it doesn't seem to be documented at all at http://apr.apache.org/docs/apr-util/modules.html); even if it does, it is not portable to other databases. Has anyone looked at this? If no-one is working on this and you think it would be a useful feature to add, I may be able to write something with a bit of help. Cheers, --Phil.
Re: mod_auth[nz]_dbd password caching
On Saturday 03 December 2005 11:39, Phil Endecott wrote: Has anyone looked at this? If no-one is working on this and you think it would be a useful feature to add, I may be able to write something with a bit of help. This is beyond the scope of what we've done, which is why you didn't find it:-) Please do go ahead and look at it. I look forward to your improvements. -- Nick Kew
Re: Directions for Win32 binary httpd
From a build standpoint I agree. But VC++ 2005 has improvements in Performance, MemoryManagement etc. The optimizer seems to improve the performance quite significantly. Contrary to what Microsoft would like, you can built the server with the needed DLLs statically so there is nothing to ship and nothing to install. The Sambar Server( www.sambar.com ) uses this approach. Steffen - Original Message - From: William A. Rowe, Jr. [EMAIL PROTECTED] To: dev@httpd.apache.org Sent: Saturday, December 03, 2005 10:17 AM Subject: Re: Directions for Win32 binary httpd Ok, I've come to a conclusion; for the coming release, only msvcrt.dll builds under Visual C++ 6.0 make sense as our binary distribution. I'm not suggesting we dismiss the potential win of supporting our Studio 2005 compiler users(!) But let's quickly compare... . binary users generally aren't building modules, they need to plug into widely distributed binary components. . source users generally can build anything from source, if they need to. If they want to interface several components, they can build our source tarball with any compiler they like, including the 1 year free license of Studio 2005. . it's pretty trivial to build/install httpd with one of several pretty minimal unix toolchains available. It seems that most of the communites are still in VC 6. Remember the key reason we keep using it, MS dropped support for exporting makefiles. With no makefiles, you are roped into supporting only version x or newer Studio products. With .dsp/.dsw solutions, we can export makefiles on the old reliable VC 6, and users can load/convert these into Studio 2000/03/05. So I'll move ahead with all the msi tweaks required for our changed files, and we can reevaluate the state of things 6 mos or a year from now when we are almost ready to ship Apache X :) That's my conclusion, I'm still more than happy to hear out dissenting opinions. Speak up quick, though, planning to have a package up in /dev/dist by Sunday night for review, and push it out sometime early next week. Bill
Re: Directions for Win32 binary httpd
On 12/3/05, William A. Rowe, Jr. [EMAIL PROTECTED] wrote: It seems that most of the communites are still in VC 6. Remember the key reason we keep using it, MS dropped support for exporting makefiles. With no makefiles, you are roped into supporting only version x or newer Studio products. With .dsp/.dsw solutions, we can export makefiles on the old reliable VC 6, and users can load/convert these into Studio 2000/03/05. So why not distribute the VC6 dsp/dsw files but (officially) build with VS05 yourself?
Re: apr_socket_sendfile not found on OS/X?
Ian Holsman wrote: Hi. I just checked out the latest trunk of apr httpd on my mac, and can't build it anymore. it is complaining about apr_socket_sendfile not being defined. so I checked .. and apr.h has APR_HAS_SENDFILE as 0. the problem is sendfile_nonblocking calls apr_socket_sendfile ;( mac/darwin doesn't support sendfile at all. I don't know how you are getting sendfile_nonblocking called at all, since it is all wrapped by #if APR_HAS_SENDFILE -Paul
Re: What's in a URL ?
Nicolas Lehuen writes: As for the colophon : I initially built this chart on Excel 2003, then feeling a bit guilty, I decided to switch to OpenOffice 2 (developer Guilt is good for the soul, my son. Shun the M$ beast...this is good for the soul. As for your pdf...after opening it in xpdf it was approximately the size of a pencil eraser. Zooming 400% makes it somewhat readable. Any possibility of spitting it out to html and posting it somewhere? Daniel Popowich --- http://home.comcast.net/~d.popowich/mpservlets/
Re: Directions for Win32 binary httpd
As someone who knows all of the Windows build platforms well... my 2 cents jives with your decision, Bill. Using MSVC 6.0 at this point and keeping the makefiles is the only 'sane' thing to do at this point. There are ISSUES with just about any of the newer platforms including the obvious "where o where did the makefiles go" stuff. Someone said it a few messages ago ( I think it was you, Bill ). httpd is an OPEN SOURCE project ( --keyword=source ). Let other people who need/must/or just want to use some other build environment have at it with other and find/solve the issues and post solutions back to the project. That's how it's supposed to work. I know Apache is pretty much your "full time job", Bill... but that still doesn't mean you're supposed to do EVERYTHING. Yours... Kevin PS: Whatever became of that nifty perl script nmake makefile-to-project-file conversion script you were working on? It was almost working fine at one point? Maybe you should post that into a distribution and let some other Perl wizard take it into the end zone. Might be needed later. In a message dated 12/3/2005 3:19:17 AM Central Standard Time, [EMAIL PROTECTED] writes: Ok, I've come to a conclusion; for the coming release, only msvcrt.dll builds under Visual C++ 6.0 make sense as our binary distribution. I'm not suggesting we dismiss the potential win of supporting our Studio 2005 compiler users(!) But let's quickly compare... . binary users generally aren't building modules, they need to plug into widely distributed binary components. . source users generally can build anything from source, if they need to. If they want to interface several components, they can build our source tarball with any compiler they like, including the 1 year free license of Studio 2005. . it's pretty trivial to build/install httpd with one of several pretty minimal unix toolchains available. It seems that most of the communites are still in VC 6. Remember the key reason we keep using it, MS dropped support for exporting makefiles. With no makefiles, you are roped into supporting only version x or newer Studio products. With .dsp/.dsw solutions, we can export makefiles on the old reliable VC 6, and users can load/convert these into Studio 2000/03/05. So I'll move ahead with all the msi tweaks required for our changed files, and we can reevaluate the state of things 6 mos or a year from now when we are almost ready to ship Apache X :) That's my conclusion, I'm still more than happy to hear out dissenting opinions. Speak up quick, though, planning to have a package up in /dev/dist by Sunday night for review, and push it out sometime early next week. Bill
Re: Directions for Win32 binary httpd
Steffen wrote: From a build standpoint I agree. But VC++ 2005 has improvements in Performance, MemoryManagement etc. The optimizer seems to improve the performance quite significantly. Contrary to what Microsoft would like, you can built the server with the needed DLLs statically so there is nothing to ship and nothing to install. The Sambar Server( www.sambar.com ) uses this approach. Steffan, you aren't considering the structure of httpd(!) Loading three dozen modules and several libraries, each with embedded Clib functions is quite sub-optimal ;-) For a monolithic program, I agree with your assessment. Of course, feel free to build under VC 2005 (freely for the next year!). We are talking about maximum flexibility for distribution purposes, only. Bill
Re: Directions for Win32 binary httpd
Olaf van der Spek wrote: On 12/3/05, William A. Rowe, Jr. [EMAIL PROTECTED] wrote: It seems that most of the communites are still in VC 6. Remember the key reason we keep using it, MS dropped support for exporting makefiles. With no makefiles, you are roped into supporting only version x or newer Studio products. With .dsp/.dsw solutions, we can export makefiles on the old reliable VC 6, and users can load/convert these into Studio 2000/03/05. So why not distribute the VC6 dsp/dsw files but (officially) build with VS05 yourself? Because, as noted, it's not compatible with binaries precompiled for most languages that users would like to load into the running server, chief amoung them being perl. (The PHP module is far less invasive, and generally follows the portability rules I set forth in another note, w.r.t. not handing off clib resources from httpd to modphp and back.) Bill
Re: Directions for Win32 binary httpd
[EMAIL PROTECTED] wrote: As someone who knows all of the Windows build platforms well... my 2 cents jives with your decision, Bill. Using MSVC 6.0 at this point and keeping the makefiles is the only 'sane' thing to do at this point. Couple of months ago I've proposed a 'hand-written' nmake system containing of a single common .inc file and actual implementation (for APR). It can be used to build the APR as dll/lib on any platform/cpu/compiler starting from vc6 up. The major fear was the maintenance. Well, the number of modules or files that gets added to the core is so small, and I found it's easier to copy/paste/rewrite_few_lines rather then open .dsw and the point-click couple of hundred times. Since the similar system works just fine for Netware I see no reason why that can not be implemented for windows too. The days when there was only win32/i386 are long time gone. Regards, Mladen.
Re: Directions for Win32 binary httpd
[EMAIL PROTECTED] wrote: PS: Whatever became of that nifty perl script nmake makefile-to-project-file conversion script you were working on? It was almost working fine at one point? Maybe you should post that into a distribution and let some other Perl wizard take it into the end zone. Might be needed later. I believe the subversion project uses this model (it's actually in Python.) Some of that was, IIRC, checked into the apr tree.
Re: apr_socket_sendfile not found on OS/X?
Paul Querna wrote: Ian Holsman wrote: Hi. I just checked out the latest trunk of apr httpd on my mac, and can't build it anymore. it is complaining about apr_socket_sendfile not being defined. so I checked .. and apr.h has APR_HAS_SENDFILE as 0. the problem is sendfile_nonblocking calls apr_socket_sendfile ;( mac/darwin doesn't support sendfile at all. I don't know how you are getting sendfile_nonblocking called at all, since it is all wrapped by #if APR_HAS_SENDFILE -Paul Meh. Someone didn't wrap sendfile_nonblocking itself under APR_HAS_SENDFILE when they re-factored it :-) Fixed in trunk/r351997. -Paul
What do you want in HTTPD 2.4/3.0/X/GREEN?
My intention is for this to be a wide open brainstorming thread. I expect that we will be able to discuss several ideas in much more detail at the Hackathon next week, but I really want to get all ideas 'on the table'. I have a few things I would like to see, but I am sure there are perhaps hundreds of other major features that other people want. It helps to know what everyone else is thinking about new features, rather than one person going off an doing it all by themselves. (not that I'll stop anyone from that either). Here is my list: * Async/Event MPM: Complete Async pipeline for static files. I believe we can seriously give every existing single-threaded-event-based server a run for their money on every existing benchmark. Toss in some dynamic content, and a hybrid Event/Worker has serious potential. Some of this work is ongoing in the async-read dev branch, but there is plenty more to do. * A Perchild MPM/replacement: The SoC perchild-replacement project didn't work out. We have a basic design that is sound, but we need to actually write the code. * HTTP Removed from the core: I would like to be able to build with --disable-http. Sounds crazy, but it will hopefully shrink the core, and help us improve other protocol handlers like mod_ftp and mod_smtpd.
Re: What do you want in HTTPD 2.4/3.0/X/GREEN?
Paul Querna wrote: * Async/Event MPM: Complete Async pipeline for static files. I believe we can seriously give every existing single-threaded-event-based server a run for their money on every existing benchmark. Toss in some dynamic content, and a hybrid Event/Worker has serious potential. Some of this work is ongoing in the async-read dev branch, but there is plenty more to do. Depending on the final impl, whether this is 2.4 or 3.0 would depend on the required API changes. But +1 as the next logical step. * A Perchild MPM/replacement: The SoC perchild-replacement project didn't work out. We have a basic design that is sound, but we need to actually write the code. +1 as a VERY useful thing for 2.2/2.4 * HTTP Removed from the core: I would like to be able to build with --disable-http. Sounds crazy, but it will hopefully shrink the core, and help us improve other protocol handlers like mod_ftp and mod_smtpd. :) -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ If you can dodge a wrench, you can dodge a ball.
Re: What do you want in HTTPD 2.4/3.0/X/GREEN?
On Saturday 03 December 2005 19:36, Paul Querna wrote: My intention is for this to be a wide open brainstorming thread. I expect that we will be able to discuss several ideas in much more detail at the Hackathon next week, but I really want to get all ideas 'on the table'. Alas, I shall be remote. Here is my list: * Async/Event MPM: Sounds fine for a 2.4. * A Perchild MPM/replacement: Ditto. But we don't have a track record of round tuits. * HTTP Removed from the core: Probably a 3.0 thing. What's the request_rec - and everything that revolves around it - going to look like? One thing we really should avoid is another big API break like 1.x-2.x. Third-party modules should continue to work with little or no rewriting. Some more thoughts; * Authz cleanup (already started in authz-dev) * Flexible handlers using ap_provider c.f. http://marc.theaimsgroup.com/?l=apache-httpd-devm=112843906920434w=2 * Configuration revamp - enable reconfiguration (ideally per-vhost) without a server restart. -- Nick Kew
httpd 2.2 missing as product in bugzilla
Hi all, I just worked on a bug report and noticed that there is no setting for Apache http-2.2 in the product selection box of bugzilla. I think this should be either added or the current text for Apache http-2.0 should be exchanged against Apache http-2.x to avoid confusing to the user. Regards Rüdiger
Re: What do you want in HTTPD 2.4/3.0/X/GREEN?
On Sat, Dec 03, 2005 at 11:36:10AM -0800, Paul Querna wrote: * A Perchild MPM/replacement: The SoC perchild-replacement project didn't work out. We have a basic design that is sound, but we need to actually write the code. +1. Could you dig out a reference to the design? I kind of lost track of where he was going with it. For modules I'd like to see some re-ordering of what we ship in the tarball and what we don't. Another thing I'd like to see is the proxy refactored to use a proper http client lib. As an added benefit, an http client lib would be useful in creating something like CPAN for modules. vh Mads Toftum -- `Darn it, who spiked my coffee with water?!' - lwall
Re: httpd 2.2 missing as product in bugzilla
Ruediger Pluem wrote: Hi all, I just worked on a bug report and noticed that there is no setting for Apache http-2.2 in the product selection box of bugzilla. I think this should be either added or the current text for Apache http-2.0 should be exchanged against Apache http-2.x to avoid confusing to the user. Done. It's simply Apache httpd-2 now. Bill
Re: What do you want in HTTPD 2.4/3.0/X/GREEN?
On Sat, Dec 03, 2005 at 11:36:10AM -0800, Paul Querna wrote: * Async/Event MPM: Complete Async pipeline for static files. I believe we can seriously give every existing single-threaded-event-based server a run for their money on every existing benchmark. Toss in some dynamic content, and a hybrid Event/Worker has serious potential. Some of this work is ongoing in the async-read dev branch, but there is plenty more to do. * A Perchild MPM/replacement: The SoC perchild-replacement project didn't work out. We have a basic design that is sound, but we need to actually write the code. * HTTP Removed from the core: I would like to be able to build with --disable-http. Sounds crazy, but it will hopefully shrink the core, and help us improve other protocol handlers like mod_ftp and mod_smtpd. Ideas based on prior discussions and personal desires; * A threaded MPM to become the default: I would like mod_cgid to die, and for there to be a mod_execd, with an optional ap_exec() provider. Every place that would have a fork()/exec() can then use some ap_ function which takes an environment pointer (or NULL for unchanged), some structure for option suexec stuff, and returns filehandles for out/in/err. On non-unix/non-threaded it's a noop or just forks and exec. On threaded, we use a mod_execd (possible with pre-forking) and pass file descriptors over a local socket. Weed out other thread-safety nits like the lexx/yacc generated stuff. * Configurable buffer sizes; This work is really in apr, and some of it is done, but buckets need to be tackled next and then it needs to be hacked in-httpd. But it would be nice to be able to configure the buffer size used for reading files, both when we read() them and when we call sendfile() on them, because that's how we get to scalable TCP flows. Setting txqueuelen on an interface isn't much use without application support for buffering similar ammounts - but that's what admins are starting to need with the ultra-large Window-sizes neccessary to get really good flow-performance out of say a 10G link. * A small protocol module that lets an admin interface apache via a unix domain socket. To give the admin an out-of-band channel to query mod_status when their link is full, or when they've gracefully stopped. * Optional XML-ised output for things like mod_status * Build upon the aaa framework to do some more useful things. Two in particular I'd like, but they are awkward and contentious. First, is that we have a lot of third-party providers coming up with ways of storing state for authentication via http. Most often via cookies, but sometimes via url-encoded session ID's and so on. It's messy and ugly, but ignoring the reality of One-Time Passwords isn't good either, so it might be justifiable to come with a framework for a united approach. Making say mod_authnz_secureid only a small bit of work. The other thing I think is missing from the aaa framework is a way for an admin to mandate that aaa happen over an encrypted session only. Some magic directive that doesn't extend into per-dir/htaccess land that helps them out a little in making sure that https is being used. Some of those I have concrete ideas on and plan to code away at, others are a bit nebulous :) -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: What do you want in HTTPD 2.4/3.0/X/GREEN?
--On December 3, 2005 8:52:38 PM + Colm MacCarthaigh [EMAIL PROTECTED] wrote: * A threaded MPM to become the default: I would like mod_cgid How about making the MPMs DSOable? * Build upon the aaa framework to do some more useful things. Two in particular I'd like, but they are awkward and contentious. First, is that we have a lot of third-party providers coming up with ways of storing state for authentication via http. Most often via cookies, but sometimes via url-encoded session ID's and so on. It's messy and ugly, but ignoring the reality of One-Time Passwords isn't good either, so it might be justifiable to come with a framework for a united approach. Making say mod_authnz_secureid only a small bit of work. The other thing I think is missing from the aaa framework is a way for an admin to mandate that aaa happen over an encrypted session only. Some magic directive that doesn't extend into per-dir/htaccess land that helps them out a little in making sure that https is being used. Huh. Cool. I'd like to hear more about this... -- justin
Re: What do you want in HTTPD 2.4/3.0/X/GREEN?
Justin Erenkrantz wrote: --On December 3, 2005 8:52:38 PM + Colm MacCarthaigh [EMAIL PROTECTED] wrote: * A threaded MPM to become the default: I would like mod_cgid How about making the MPMs DSOable? ++1!
Re: What do you want in HTTPD 2.4/3.0/X/GREEN?
Nick Kew wrote: On Saturday 03 December 2005 19:36, Paul Querna wrote: My intention is for this to be a wide open brainstorming thread. But we don't have a track record of round tuits. Sort of the reason the thread is interesting, but I'd rather see code to comment on. Interesting ideas, I have some that I'd rather share as code once they are ready. Bill
Re: What do you want in HTTPD 2.4/3.0/X/GREEN?
William A. Rowe, Jr. wrote: Nick Kew wrote: On Saturday 03 December 2005 19:36, Paul Querna wrote: My intention is for this to be a wide open brainstorming thread. But we don't have a track record of round tuits. Sort of the reason the thread is interesting, but I'd rather see code to comment on. Interesting ideas, I have some that I'd rather share as code once they are ready. Thats the part of the point of this thread. To get the other developers interested in your ideas, so that the code can be done sooner. -Paul
Making MPMs DSOs
I am trying to sketch out the issues with allowing MPMs to be loaded as DSOs, specified from the conf file. 1) AP_MPM_WANT_*. These defines come from the mpm.h, and are used all over the core. A significant number of them are for adding configuration directives. The rest are generally changing the behavior of the mpm_common stuff. Here is the full list from trunk: AP_MPM_WANT_FATAL_SIGNAL_HANDLER AP_MPM_WANT_PROCESS_CHILD_STATUS AP_MPM_WANT_RECLAIM_CHILD_PROCESSES AP_MPM_WANT_SET_ACCEPT_LOCK_MECH AP_MPM_WANT_SET_COREDUMPDIR AP_MPM_WANT_SET_GRACEFUL_SHUTDOWN AP_MPM_WANT_SET_LOCKFILE AP_MPM_WANT_SET_MAX_MEM_FREE AP_MPM_WANT_SET_MAX_REQUESTS AP_MPM_WANT_SET_PIDFILE AP_MPM_WANT_SET_SCOREBOARD AP_MPM_WANT_SET_STACKSIZE AP_MPM_WANT_SIGNAL_SERVER AP_MPM_WANT_WAIT_OR_TIMEOUT 2) Build system issues. Need to make the MPMs build as .so 3) The scoreboard. Each group of MPMs handles it differently. The Event MPM is also re-shaping what a 'connection' means, and this will likely lead to more scoreboard changes. We need a better common API to reading and writing to the scoreboard. It would also be nice for other modules, like mod_ldap and mod_dbd, which might want to keep global state/stats around. 4) mpm_common.c uses ap_server_conf, which is a global variable in each MPM. It needs to be moved to be completely inside mpm_common.c. 5) Where to put the DSO Loading code? I sketched out putting it into mod_so.. I am not sure if it would be easier to just stick it into the core. Those are the the big ones that I see. I will try to tackle them one at a time, and when its all done, I think it will work. -Paul
Re: What do you want in HTTPD 2.4/3.0/X/GREEN?
An idea, although I have no idea whether this can be done at all, or whether this has been discussed before: MaxMemoryPerChild. Especially with things like PHP, occasionally a child process can 'explode' and grow very large. As far as I'm aware, the only way to limit child processes is currently the number of requests. But since it's rather hard to predict when a child can grow very large (it theoretically could happen in the first request), I'd rather have a memory limit: Once a child process grows beyond that limit, kill the child (after the current request finishes of course). I've had boxes where the average child was 12 MB, but once in a while, a child would grow upto 140MB. Normally, MaxClients of 70 would be quite safe, but with the growing children, even that was too high. But if I could set MaxMemoryPerChild 20 MB, this would be no problem, as these children would be killed before they grew too large. Joost
Re: What do you want in HTTPD 2.4/3.0/X/GREEN?
--On December 3, 2005 11:57:08 PM +0100 Joost de Heer [EMAIL PROTECTED] wrote: An idea, although I have no idea whether this can be done at all, or whether this has been discussed before: MaxMemoryPerChild. http://httpd.apache.org/docs/2.2/mod/core.html#rlimitmem HTH. -- justin
Re: What do you want in HTTPD 2.4/3.0/X/GREEN?
Justin Erenkrantz wrote: --On December 3, 2005 11:57:08 PM +0100 Joost de Heer [EMAIL PROTECTED] wrote: An idea, although I have no idea whether this can be done at all, or whether this has been discussed before: MaxMemoryPerChild. http://httpd.apache.org/docs/2.2/mod/core.html#rlimitmem This applies to processes forked off from Apache children servicing requests, not the Apache children themselves. So not exactly what I proposed, unless I am understanding that wrong? Joost
Re: What do you want in HTTPD 2.4/3.0/X/GREEN?
On Sunday 04 December 2005 00:14, Justin Erenkrantz wrote: --On December 4, 2005 12:06:40 AM +0100 Joost de Heer [EMAIL PROTECTED] wrote: This applies to processes forked off from Apache children servicing requests, not the Apache children themselves. So not exactly what I proposed, unless I am understanding that wrong? If you want to limit the children themselves, then you want the standard ulimit controls available in your shell or whatnot. -- justin hm, together with a perchild-like mpm I could imagine a memory limitation per child process ... kess
Question about memory in httpd
When going thrue the code, looking at apr_palloc and friends, one can see that : * in some places (few of them) , the returned pointer is checked against NULL * in other places (most of them), it is not. I've always been told that checking return value is a good idea, (especially with memory allocation in order to avoid disasters) so should all the apr_palloc (and friends) calls be checked or are they special reasons in httpd not to care about short in memory situation ? CJ.
Re: What do you want in HTTPD 2.4/3.0/X/GREEN?
On Sun, Dec 04, 2005 at 12:31:31AM +0100, Astrid 'Kess' Keßler wrote: hm, together with a perchild-like mpm I could imagine a memory limitation per child process ... Not really necessary given that the whole point of a perchild-like mpm is to run vhosts under different user ids, so it should be fairly simple to handle that at the os level. vh Mads Toftum -- `Darn it, who spiked my coffee with water?!' - lwall
Re: apr_socket_sendfile not found on OS/X?
Thanks Paul, I didn't realize the trunk wasn't 2.2.x.. otherwise I would have just fixed it myself ;-) Paul Querna wrote: Paul Querna wrote: Ian Holsman wrote: Hi. I just checked out the latest trunk of apr httpd on my mac, and can't build it anymore. it is complaining about apr_socket_sendfile not being defined. so I checked .. and apr.h has APR_HAS_SENDFILE as 0. the problem is sendfile_nonblocking calls apr_socket_sendfile ;( mac/darwin doesn't support sendfile at all. I don't know how you are getting sendfile_nonblocking called at all, since it is all wrapped by #if APR_HAS_SENDFILE -Paul Meh. Someone didn't wrap sendfile_nonblocking itself under APR_HAS_SENDFILE when they re-factored it :-) Fixed in trunk/r351997. -Paul
Re: mod_auth[nz]_dbd password caching
Hi Phil, A while back I wrote a auth wrapper which used a MD5 hash inside a cookie to determine if the user was authenticated. If the cookie was invalid or not present it would fall back to the regular auth method (in your case a DB hit). It also had a bit which sat just after the authentication section which would create the cookie on successful authentication. If you would like I could see if I can find this.. I don't think I actually made use of it after I wrote it ;( Phil Endecott wrote: Dear All, First of all, congratulation on the release of 2.2. I use mod_auth_pgsql at http://anyterm.org/my.html, and found a problem earlier in the year. To get reasonable performance you need to use the module's caching mechanism, but this cache is not flushed or updated when the database changes. So things don't work properly when the user changes their password. I started to think about fixing it myself but quickly realised that both the database and authentication frameworks were changing in 2.1+ and decided to wait before doing anything. I now see that 2.2 has mod_auth[nz]_dbd - great! However, as far as I can see from http://httpd.apache.org/docs/2.2/mod/mod_authn_dbd.html and the source, this new module doesn't do any caching. Is this true? To get the sort of performance that I need for my site I really need in-memory caching of passwords, but I also need to solve mod_auth_pgsql's non-updating problem. The solution to this is to use PostgreSQL's asynchronous notification mechanism: the module issues a LISTEN command and is then notified when the password table changes. I don't know if the APR DB interface has any support for this (it doesn't seem to be documented at all at http://apr.apache.org/docs/apr-util/modules.html); even if it does, it is not portable to other databases. Has anyone looked at this? If no-one is working on this and you think it would be a useful feature to add, I may be able to write something with a bit of help. Cheers, --Phil.
Re: Question about memory in httpd
Christophe Jaillet wrote: When going thrue the code, looking at apr_palloc and friends, one can see that : * in some places (few of them) , the returned pointer is checked against NULL * in other places (most of them), it is not. I've always been told that checking return value is a good idea, (especially with memory allocation in order to avoid disasters) so should all the apr_palloc (and friends) calls be checked or are they special reasons in httpd not to care about short in memory situation ? Actually, on most operating systems, including Linux and FreeBSD, you will NEVER get returned NULL. Instead when your operating system is truly out of memory, it will kill your process, and you won't have any chance of handling it. Read a whole blog post about it: http://baus.net/memory-management -Paul
Re: What do you want in HTTPD 2.4/3.0/X/GREEN?
Paul Querna wrote: My intention is for this to be a wide open brainstorming thread. I expect that we will be able to discuss several ideas in much more detail at the Hackathon next week, but I really want to get all ideas 'on the table'. I have a few things I would like to see, but I am sure there are perhaps hundreds of other major features that other people want. It helps to know what everyone else is thinking about new features, rather than one person going off an doing it all by themselves. (not that I'll stop anyone from that either). Here is my list: * Async/Event MPM: Complete Async pipeline for static files. I believe we can seriously give every existing single-threaded-event-based server a run for their money on every existing benchmark. Toss in some dynamic content, and a hybrid Event/Worker has serious potential. Some of this work is ongoing in the async-read dev branch, but there is plenty more to do. I've always wanted to (but not had free time) to write a SEDA-type mpm. the SEDA is slightly different to the async/event mpm in that a given hook/filter would process multiple events/requests at the same context switch. This is what the apr_queue stuff was initially designed for. I'd also like to brainstorm a better solution to running Rails/Django applications inside of the httpd process than the SCGI/FastCGI solution which most people use. Configuration .. make it configurable. by that I mean allowing people to use LDAP or a DB to hold the configuration files, and not a flat file. This is mainly intended for large server farms. Currently the main reason for logging onto a webserver is to change it's configuration (and bounce) .. if we could reduce that to just 'bounce' it might make life easier. (or some method where it checks configs every X minutes and autobounces..removing the need to log onto the machine at all ;-) Configuration .. make it easier..I can't think of anything on how to do this off the top of my head, but it seems to be a common complaint. Logging/debugging .. changing the log system to use something like Log4C for errors.. this way the module developer can easily turn on/off various information on a live system when he is having issues. wish I could attend the ApacheCon.. if there was a ApacheCon OZ I'd be there ;-) regards Ian
Re: What do you want in HTTPD 2.4/3.0/X/GREEN?
On 12/3/05, Ian Holsman [EMAIL PROTECTED] wrote: I'd also like to brainstorm a better solution to running Rails/Django applications inside of the httpd process than the SCGI/FastCGI solution which most people use. Out of curiosity, what do you think is wrong with the current FastCGI method of running them? -garrett
Re: What do you want in HTTPD 2.4/3.0/X/GREEN?
Garrett Rooney wrote: On 12/3/05, Ian Holsman [EMAIL PROTECTED] wrote: I'd also like to brainstorm a better solution to running Rails/Django applications inside of the httpd process than the SCGI/FastCGI solution which most people use. Out of curiosity, what do you think is wrong with the current FastCGI method of running them? configuration. for example in order for me to get typo running on my blog, I need 4 rewrite rules. (and when I tried to do something slightly different, it took me a good hour to configure it properly with all the rewrite magic) also when applications 'experts' like scott (the creator of typo) have issues like http://scottstuff.net/blog/articles/2005/07/20/apache-tuning-for-rails-and-fastcgi i think it isn't easy enough to run. what I am after is something as simple as RailsApp /foo/ rails-controller.rb [cache] [ENV=production] which would just work as a in-process application... making it as simple as running a PHP application is the goal. I don't like the trend i see with rails django people saying apache is hard to use and switching to other web servers. -garrett
Re: Making MPMs DSOs
Paul Querna wrote: 3) The scoreboard. Each group of MPMs handles it differently. The Event MPM is also re-shaping what a 'connection' means, and this will likely lead to more scoreboard changes. We need a better common API to reading and writing to the scoreboard. It would also be nice for other modules, like mod_ldap and mod_dbd, which might want to keep global state/stats around. Big +1 here... while working on the proxy balancer stuff, having better scoreboard interaction has been an obvious aspect that could be better and more useful. -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ If you can dodge a wrench, you can dodge a ball.
