Re: (resend) RE: mod_ssl
On Thu, Dec 13, 2007 at 09:50:46PM -0500, Hammer, Tim wrote: I am attempting to upgrade httpd from 1.3.x to 2.2.x for our web application. I have managed to get everything building and working, ... As you can see, the call from mod_ssl.so into the buckets/ code is passing a null pointer. None of our other modules have been modified to use buckets. Does mod_ssl require the use of buckets? Are you trying to port mod_ssl from 1.3.x to 2.2.x? That's been done long ago and 2.x includes a port of mod_ssl. vh Mads Toftum -- http://soulfood.dk
Re: Connection Pool Module
On Fri, 14 Dec 2007 08:35:12 -0500 Mike O'Leary [EMAIL PROTECTED] wrote: I am looking to write an Apache module that maintains a pool of socket connections to a back-end server. mod_proxy does that. Alternatively, you could look at mod_dbd, which maintains a pool of database connections. -- Nick Kew Application Development with Apache - the Apache Modules Book http://www.apachetutor.org/
Re: Specifying a different target directory for APXS
Hello folks, Has anyone come across a similar situation before? Can a target folder be specified or is that not possible? Any help is greatly appreciated. Subra On Dec 13, 2007 12:05 PM, Subra A Narayanan [EMAIL PROTECTED] wrote: Hello folks, I use the following command to compile my apache module: */usr/sbin/apxs -c mod_my.c* this creates a *.libs/* folder and my mod_my.so file is generated in that folder. My question is, is it possible to specify a different target folder for my .so file? I have gone through the man page for apxs and wasn't able to find anything. thanks in advance, Subra
RE: (resend) RE: mod_ssl
On Thu, Dec 13, 2007 at 09:50:46PM -0500, Hammer, Tim wrote: I am attempting to upgrade httpd from 1.3.x to 2.2.x for our web application. I have managed to get everything building and working, ... As you can see, the call from mod_ssl.so into the buckets/ code is passing a null pointer. None of our other modules have been modified to use buckets. Does mod_ssl require the use of buckets? Are you trying to port mod_ssl from 1.3.x to 2.2.x? That's been done long ago and 2.x includes a port of mod_ssl. No, I am trying to use the new (2.2.x) mod_ssl with our modules that have been ported from 1.3.x to 2.2.x. However, the port did not convert our modules to use buckets and I am wondering if the new mod_ssl is requiring the content generator(s) (our modules) to have created a brigade. vh Mads Toftum .Tim Xerox Corporation, Office Group Phone: 585/427-1684 Fax: 585/427-3244 Email: [EMAIL PROTECTED] Addr: M/S 0801-80A 1350 Jefferson Road Rochester, NY 14623 This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient(s) please contact the sender by reply e-mail and destroy all copies of the original message. Thank you.
Re: (resend) RE: mod_ssl
On Fri, Dec 14, 2007 at 11:01:09AM -0500, Hammer, Tim wrote: No, I am trying to use the new (2.2.x) mod_ssl with our modules that have been ported from 1.3.x to 2.2.x. However, the port did not convert our modules to use buckets and I am wondering if the new mod_ssl is requiring the content generator(s) (our modules) to have created a brigade. Ah. And everything works when mod_ssl is left out? vh Mads Toftum -- http://soulfood.dk
Re: Specifying a different target directory for APXS
Joe, Thanks for ur reply. Let me clarify somethingWhen I said I didnt get any helpful responses, I meant I didn't get any answers as to what is wrong with gcc and why the module was behaving the way it was. Anywayspoint taken.will use apxs for compiling the module. Subra On Dec 14, 2007 12:12 PM, Joe Lewis [EMAIL PROTECTED] wrote: Subra A Narayanan wrote: I didnt receive any helpful responses to that posting thats why I am trying to use apxs. You DID get helpful responses - I was one of those responders who said to use apxs. (We pointed you to the tool because there are too many changes across systems, platforms, etc, that it is faster, more efficient, and better quality to use a tool that also makes the end result more portable - go figure). Would you care to take a look at this issue = http://mail-archives.apache.org/mod_mbox/httpd-modules-dev/200711.mbox/[EMAIL PROTECTED] We need no more discussion on that - use apxs. If you need a Makefile, use the apxs tool in your Makefile. (It IS possible, after all.) For example, Makefile rules might look like : mod_test.so: apxs -c mod_test.so cp .libs/mod_test.so path/to/mod_test.so install: apxs -n mod_test -i mod_test.la That is how I have done all of my modules. It's easier to type make install rather than apxs -i -a -c mod_test.c. If you think you need help in your makefile, go to google, and type in makefile. Just copying a makefile from another package seriously limits your capabilities. Joe -- Joseph Lewis http://sharktooth.org/ Divide the fire, and you will sooner put it out. - Publius Syrus
Re: Specifying a different target directory for APXS
On Fri, 2007-12-14 at 08:07 -0500, Subra A Narayanan wrote: Hello folks, Hello folk, your problem has nothing to do with apxs. The .libs directory is created by libtool. You might want to contact the helpful dwellers on the libtool mailing list. Has anyone come across a similar situation before? Can a target folder be specified or is that not possible? Never needed to change that part of the build process. HTT Ralf Mattes Any help is greatly appreciated. Subra On Dec 13, 2007 12:05 PM, Subra A Narayanan [EMAIL PROTECTED] wrote: Hello folks, I use the following command to compile my apache module: */usr/sbin/apxs -c mod_my.c* this creates a *.libs/* folder and my mod_my.so file is generated in that folder. My question is, is it possible to specify a different target folder for my .so file? I have gone through the man page for apxs and wasn't able to find anything. thanks in advance, Subra
Re: Specifying a different target directory for APXS
On Fri, 2007-12-14 at 11:05 -0500, Subra A Narayanan wrote: Joe, Thanks for ur response. The reason I wanted to change the target directory was because my apache module is being compiled as one of the components of a much larger makefile. All the other shared libraries generated by this make file, are copied in a particular directory and hence I wanted my apache module to go in to that directory as well. As you suggested, I could copy the .so file to whatever directory I want later on, but I am not sure if such copying ig generally done in a makefile. That's the approach I would choose (I do for packaging my modules into Debian packages). Why wouldn't you copy in a Makefile? Just add another dependency: your_very_Special_path/your_module.so: your_module.slo cp .libs/your_module.so your_very_Special_path/your_module.so I did try to directly use gcc to compile my apache module so that I could specify any target directory but ran in to another issue which is detailed here = http://mail-archives.apache.org/mod_mbox/httpd-modules-dev/200711.mbox/[EMAIL PROTECTED] I didnt receive any helpful responses to that posting thats why I am trying to use apxs. I got the impression that everyone considered this a no-so-good idea HTH Ralf Mattes
Re: Specifying a different target directory for APXS
Ralf/Joe, Now I am trying to (just) compile my module using apxs and I see this warning *$ /usr/sbin/apxs -c -L /myprj/deps/axis2c/lib -L /myprj/lib/ -l axutil -l axis2_engine -l dl -l pthread -l client -l operations -c /myprj/obj/webservices/mod_my.o /myprj/obj/webservices/dispatcher.o /myprj/obj/webservices/parserequest.o /myprj/obj/webservices/response.o /usr/lib/apr/build/libtool --silent --mode=link gcc -o /myprj/obj/webservices/mod_my.la -L /myprj/deps/axis2c/lib -L/myprj/lib/ -laxutil -laxis2_engine -ldl -lpthread -lclient -loperations -rpath /usr/lib/httpd/modules -module -avoid-version /myprj/obj/webservices/mod_my.o /myprj/obj/webservices/dispatcher.o /myprj/obj/webservices/parserequest.o /myprj/obj/webservices/response.o *** Warning: Linking the shared library /myprj/obj/webservices/mod_my.la against the non-libtool *** objects /myprj/obj/webservices/mod_my.o /myprj/obj/webservices/dispatcher.o /myprj/obj/webservices/parserequest.o /myprj/obj/webservices/response.o is not portable!* Do you know what is causing this problem? Thanks for all the responses! Subra On Dec 14, 2007 1:30 PM, Ralf Mattes [EMAIL PROTECTED] wrote: On Fri, 2007-12-14 at 11:05 -0500, Subra A Narayanan wrote: Joe, Thanks for ur response. The reason I wanted to change the target directory was because my apache module is being compiled as one of the components of a much larger makefile. All the other shared libraries generated by this make file, are copied in a particular directory and hence I wanted my apache module to go in to that directory as well. As you suggested, I could copy the .so file to whatever directory I want later on, but I am not sure if such copying ig generally done in a makefile. That's the approach I would choose (I do for packaging my modules into Debian packages). Why wouldn't you copy in a Makefile? Just add another dependency: your_very_Special_path/your_module.so: your_module.slo cp .libs/your_module.so your_very_Special_path/your_module.so I did try to directly use gcc to compile my apache module so that I could specify any target directory but ran in to another issue which is detailed here = http://mail-archives.apache.org/mod_mbox/httpd-modules-dev/200711.mbox/[EMAIL PROTECTED] I didnt receive any helpful responses to that posting thats why I am trying to use apxs. I got the impression that everyone considered this a no-so-good idea HTH Ralf Mattes
Re: Specifying a different target directory for APXS
On Fri, 14 Dec 2007 16:57:28 -0500 Subra A Narayanan [EMAIL PROTECTED] wrote: PLEASE LEARN TO POST! In particular, don't append someone else's post to yours. Now I am trying to (just) compile my module using apxs and I see this warning *$ /usr/sbin/apxs -c -L /myprj/deps/axis2c/lib -L /myprj/lib/ -l Don't link that stuff in. You're compiling a module, not the kitchen sink. Use LoadFile if you need extra libs. axutil -l axis2_engine -l dl -l pthread -l client -l operations -c Some of those, like dl and pthread, should be accessed through APR. Using them directly loses portability. /myprj/obj/webservices/mod_my.o /myprj/obj/webservices/dispatcher.o Why have you called your source files [name].o? -- Nick Kew Application Development with Apache - the Apache Modules Book http://www.apachetutor.org/
Re: Memory issue in apache modules
On Dec 14, 2007 6:05 PM, John Zhang [EMAIL PROTECTED] wrote: When my module processes requests, I see a consistent memory increase. It is like the memories were never released. I am using the apr_* functions to allocate memory (most of the time from the request-pool). My understanding is that memories will be reclaimed by apache after the request is processed (so I do not need to free/delete). Anyone has any ideas? Does this have anything to do with keep alive? It should level out as each thread in the process has had a chance to run and allocate some memory for a range of requests. MaxMemFree can be used to return the heap memory that would otherwise be used by subsequent requests on that thread. -- Eric Covener [EMAIL PROTECTED]
Re: Memory issue in apache modules
--- Eric Covener [EMAIL PROTECTED] wrote: It should level out as each thread in the process has had a chance to run and allocate some memory for a range of requests. MaxMemFree can be used to return the heap memory that would otherwise be used by subsequent requests on that thread. Thanks Eric, But I see consistent memory increase when I load the SAME page repeatedly. So something is wrong with my module. But I do not know what. Thanks again. John
Re: Memory issue in apache modules
I am using the apr_* functions to allocate memory (most of the time from the request-pool). If there are few places where you allocate from othr than the reqquest pool, I'd look at those first. -- Ray B. Morris [EMAIL PROTECTED] Strongbox - The next generation in site security: http://www.bettercgi.com/strongbox/ On 12/14/2007 05:05:24 PM, John Zhang wrote: When my module processes requests, I see a consistent memory increase. It is like the memories were never released. I am using the apr_* functions to allocate memory (most of the time from the request-pool). My understanding is that memories will be reclaimed by apache after the request is processed (so I do not need to free/delete). Anyone has any ideas? Does this have anything to do with keep alive? Thanks, John
Re: mod_proxy in Apache 2.2 and HTTP_INTERNAL_SERVER_ERROR
-Ursprüngliche Nachricht- Von: Jiri Tulach - Position Gesendet: Freitag, 14. Dezember 2007 08:39 An: dev@httpd.apache.org Betreff: Re: mod_proxy in Apache 2.2 and HTTP_INTERNAL_SERVER_ERROR It's possible fault of mod_fastcgi which returns HTTP_INTERNAL_SERVER_ERROR in cases when server is overloaded or external fastcgi instances are unavailable. Unfortunately mod_fastcgi is not actively developed even thought lot of people use it in production sites. But I still don't understand why proxy which has an option to get proper data from another (probably) working server stops trying to failover. I think from proxy point of view it doesn't matter why server is unavailable. Or am I missing something? 1. HTTP_INTERNAL_SERVER_ERROR can be the result of an internal proxy problem. In this case it would be wrong failing over. 2. If HTTP_INTERNAL_SERVER_ERROR is returned it is possible that the backend processed at least parts of the request. And at least for non idempotent requests it would be entirely wrong to fail over. So please fix mod_fastcgi to return the correct error code. This is NO bug of the proxy. Regards Rüdiger Thanx for comments. Jiri Tulach William A. Rowe, Jr. napsal(a): Mladen Turk wrote: Jir wrote: is there any reason why HTTP_INTERNAL_SERVER_ERROR returned by proxy handler cannot failover to another worker? Because HTTP_INTERNAL_SERVER_ERROR is used to represent either misconfiguration or even worse things like memory allocation failures. In essence non recoverable error. However, I'm not saying some scheme handler doesn't have bug returning HTTP_INTERNAL_SERVER_ERROR instead something else. Considering we have... #define HTTP_BAD_GATEWAY 502 #define HTTP_SERVICE_UNAVAILABLE 503 #define HTTP_GATEWAY_TIME_OUT 504 it seems like most of the INTERNAL_SERVER_ERROR's should be considered for more explicit messages, eh?
Re: mod_proxy in Apache 2.2 and HTTP_INTERNAL_SERVER_ERROR
Jiri Tulach - Position wrote: It's possible fault of mod_fastcgi which returns HTTP_INTERNAL_SERVER_ERROR in cases when server is overloaded or external fastcgi instances are unavailable. Unfortunately mod_fastcgi is not actively developed even thought lot of people use it in production sites. But I still don't understand why proxy which has an option to get proper data from another (probably) working server stops trying to failover. I think from proxy point of view it doesn't matter why server is unavailable. Or am I missing something? The ajp proxy may have sent the request and get a partial response if you fail over after HTTP_INTERNAL_SERVER_ERROR you may duplicate a transaction. Cheers Jean-Frederic Thanx for comments. Jiri Tulach William A. Rowe, Jr. napsal(a): Mladen Turk wrote: Jir wrote: is there any reason why HTTP_INTERNAL_SERVER_ERROR returned by proxy handler cannot failover to another worker? Because HTTP_INTERNAL_SERVER_ERROR is used to represent either misconfiguration or even worse things like memory allocation failures. In essence non recoverable error. However, I'm not saying some scheme handler doesn't have bug returning HTTP_INTERNAL_SERVER_ERROR instead something else. Considering we have... #define HTTP_BAD_GATEWAY 502 #define HTTP_SERVICE_UNAVAILABLE 503 #define HTTP_GATEWAY_TIME_OUT 504 it seems like most of the INTERNAL_SERVER_ERROR's should be considered for more explicit messages, eh?
Re: mod_proxy in Apache 2.2 and HTTP_INTERNAL_SERVER_ERROR
On Fri, 14 Dec 2007 09:43:12 +0100 jean-frederic clere [EMAIL PROTECTED] wrote: But I still don't understand why proxy which has an option to get proper data from another (probably) working server stops trying to failover. I think from proxy point of view it doesn't matter why server is unavailable. Or am I missing something? The ajp proxy may have sent the request and get a partial response if you fail over after HTTP_INTERNAL_SERVER_ERROR you may duplicate a transaction. That argues that we might make want to identify idempotent requests and treat them differently. That's going to get a bit hairy: we may be using HTTP status codes in inconsistent ways here: - as errors propagated from a backend. - as errors generated in the proxy XYZ is unrecoverable. - as HTTP representations of errors from another protocol. I think the mod_proxy scheme handlers would need to decide whether a backend request can be retried, and return different statuses for when it is/isn't. That's what it does with the INTERNAL_SERVER_ERROR vs SERVICE_UNAVAILABLE distinction, albeit that's not really adequate if it's doubling up as what we return to the client. If the OP has in mind an improved scheme, perhaps he should think it through to the point where he can hack up a proposal? -- Nick Kew Application Development with Apache - the Apache Modules Book http://www.apachetutor.org/
Re: mod_proxy in Apache 2.2 and HTTP_INTERNAL_SERVER_ERROR
Hello, sorry, but I don't agree :(. 1. HTTP_INTERNAL_SERVER_ERROR can be the result of an internal proxy problem. In this case it would be wrong failing over. This means that current implementation mixes internal errors with errors on back end. I suggest to consider implementing different error status handling to distinguish what fails. 2. If HTTP_INTERNAL_SERVER_ERROR is returned it is possible that the backend processed at least parts of the request. And at least for non idempotent requests it would be entirely wrong to fail over. and jean-frederic clere wrote: The ajp proxy may have sent the request and get a partial response if you fail over after HTTP_INTERNAL_SERVER_ERROR you may duplicate a transaction. I believe most of the users want correct response from the server instead of partial. Also if server is in error state the partial response could be totally wrong or may contain inappropriate informations. /?q=inappropriatelang=en_cz If we talking about transactions how do you prevent user to don't repeat the same request if he see that his previous request failed? Ok maybe there is not user on other site but machine. So make this behavior configurable in cases where you can ensure specific environment conditions. So please fix mod_fastcgi to return the correct error code. This is NO bug of the proxy. a) I don't said there is a bug. I only asked why it is implemented in that way. b) I said mod_fastcgi is not in active development. There is almost no support for this module and I'm not a developer of this module. But this don't change the fact this is a popular module and widely used. c) You have configuration option in proxy for bad formated headers (ProxyBadHeader) so you probably assume not all back ends are correctly implemented. Why don't have another option to ensure correct responses from proxy? Sorry guys but you still didn't convinced me why proxy should care about one specific back end error - HTTP_INTERNAL_SERVER_ERROR. I rather think there is a problem with mixing internal status errors and back end errors mentioned in 1) above. But maybe I'm wrong. Regards Jiri Tulach Plüm napsal(a): -Ursprüngliche Nachricht- Von: Jiri Tulach - Position Gesendet: Freitag, 14. Dezember 2007 08:39 An: dev@httpd.apache.org Betreff: Re: mod_proxy in Apache 2.2 and HTTP_INTERNAL_SERVER_ERROR It's possible fault of mod_fastcgi which returns HTTP_INTERNAL_SERVER_ERROR in cases when server is overloaded or external fastcgi instances are unavailable. Unfortunately mod_fastcgi is not actively developed even thought lot of people use it in production sites. But I still don't understand why proxy which has an option to get proper data from another (probably) working server stops trying to failover. I think from proxy point of view it doesn't matter why server is unavailable. Or am I missing something? 1. HTTP_INTERNAL_SERVER_ERROR can be the result of an internal proxy problem. In this case it would be wrong failing over. 2. If HTTP_INTERNAL_SERVER_ERROR is returned it is possible that the backend processed at least parts of the request. And at least for non idempotent requests it would be entirely wrong to fail over. So please fix mod_fastcgi to return the correct error code. This is NO bug of the proxy. Regards Rüdiger Thanx for comments. Jiri Tulach William A. Rowe, Jr. napsal(a): Mladen Turk wrote: Jir wrote: is there any reason why HTTP_INTERNAL_SERVER_ERROR returned by proxy handler cannot failover to another worker? Because HTTP_INTERNAL_SERVER_ERROR is used to represent either misconfiguration or even worse things like memory allocation failures. In essence non recoverable error. However, I'm not saying some scheme handler doesn't have bug returning HTTP_INTERNAL_SERVER_ERROR instead something else. Considering we have... #define HTTP_BAD_GATEWAY 502 #define HTTP_SERVICE_UNAVAILABLE 503 #define HTTP_GATEWAY_TIME_OUT 504 it seems like most of the INTERNAL_SERVER_ERROR's should be considered for more explicit messages, eh?
Re: time for 1.3.40 and 2.2.7 ?
-Ursprüngliche Nachricht- Von: Jim Jagielski Gesendet: Freitag, 14. Dezember 2007 14:49 An: dev@httpd.apache.org Betreff: Re: time for 1.3.40 and 2.2.7 ? Anyone opposed to us shooting for a TR early next week? No. Let's rock. I offer to RM Thanks for doing so. Regards Rüdiger
Re: time for 1.3.40 and 2.2.7 ?
Anyone opposed to us shooting for a TR early next week? I offer to RM
Connection Pool Module
I am looking to write an Apache module that maintains a pool of socket connections to a back-end server. When a request for the module comes in, a connection from the pool would be grabbed and the data sent to the back-end server. I want persistent connections to the back-end server; constantly reconnecting would be very painful. Anyone know of how I could get this to work? From what I've read, I don't see that this is possible, but throwing it out in the hopes that someone here knows. I appreciate any help you can give. Mike
Re: Specifying a different target directory for APXS
Subra A Narayanan wrote: Hello folks, Has anyone come across a similar situation before? Can a target folder be specified or is that not possible? Any help is greatly appreciated. Subra The .libs directory is specified by the libtool command, not by the apxs tool. However, this is probably not what you really want. Perhaps running an apxs -i command to INSTALL the module. Your apxs -c command is merely compiling the module. The apxs -i command installs the module into the appropriate apache directory (configured when you compiled apache the first time [if RPM, when the RPM was built]). If you really must change the directory, then you can manually edit the file specified by the `apr-config --apr-libtool` command, and change the objdir parameter. But, don't ask us for any help if this causes your system to no longer compile apache or apache modules (or even run apache or compile other processes that require the libtool command, or things to blow up). No one in their right mind is going to touch that. It is easy enough to copy the .so file to where you need it once (unless you are installing it, then it's easy enough to just use a -i parameter to apxs to install the module). Good luck, Joe -- Joseph Lewis http://sharktooth.org/ Divide the fire, and you will sooner put it out. - Publius Syrus
Re: time for 1.3.40 and 2.2.7 ?
Jim Jagielski wrote: Anyone opposed to us shooting for a TR early next week? If we can get a couple of security-related-but-not-really patches committed to 2.0 I'd like to see that as well. I'm offering, but if you would enjoy it, I'll just focus on win32 src/binary packages all around. Bill
Re: time for 1.3.40 and 2.2.7 ?
On Dec 14, 2007, at 12:52 PM, William A. Rowe, Jr. wrote: Jim Jagielski wrote: Anyone opposed to us shooting for a TR early next week? If we can get a couple of security-related-but-not-really patches committed to 2.0 I'd like to see that as well. I'm offering, Sure... that would be great. Another three-for-all :) From what I can see, both 1.3 and 2.2 are backport free, so it's just 2.0 right now.
Re: time for 1.3.40 and 2.2.7 ?
Den Friday 14 December 2007 20.24.35 skrev Jim Jagielski: On Dec 14, 2007, at 12:52 PM, William A. Rowe, Jr. wrote: Jim Jagielski wrote: Anyone opposed to us shooting for a TR early next week? If we can get a couple of security-related-but-not-really patches committed to 2.0 I'd like to see that as well. I'm offering, Sure... that would be great. Another three-for-all :) From what I can see, both 1.3 and 2.2 are backport free, so it's just 2.0 right now. It's some obsession to release more than just one? I would rather see 2.2.7 released now. I don't care at all about 1.3.x or 2.0.x. -- Regards // Oden Eriksson
Re: time for 1.3.40 and 2.2.7 ?
Oden Eriksson wrote: Den Friday 14 December 2007 20.24.35 skrev Jim Jagielski: From what I can see, both 1.3 and 2.2 are backport free, so it's just 2.0 right now. Yup - and the review of significant 2.0 patches would only take an hour or two, it's not that complex - things that were already accepted and happily adopted for 2.2. It's some obsession to release more than just one? I would rather see 2.2.7 released now. I don't care at all about 1.3.x or 2.0.x. It's simply time consuming for the RM to package /anything/. Nevermind put it up for a vote, update the websites, send out the announcements and so forth. So it's really an RM's call what they want to proceed with, we all appreciate that. There are economies of scale; once you have to dig into 10 different places to update it all, changing 3 instead of just 1 is pretty trivial. Changing it all one at a time for one release over and over again is a PITA. I've RM'ed my share of httpd releases, and know this from experience. However, if just one of those three falls over, and can't be released, that should not stop any other good candidates from becoming released promptly, so RM'ing two extra tarballs really doesn't add as much work as you might expect. So I offered to package 2.0, because I don't want to force it on anyone else who doesn't care. I was guessing Jim might want to RM all three, but that's his call, I'm happy either way. Either Jim, or I, or any other RM who goes to the effort deserves our appreciation. There's a simple way of not-so-rudely saying what you just said above. Just don't test the package you don't care about, don't put in a vote either way, and certainly don't play peanut gallery if you have nothing productive to add. Bill
Re: time for 1.3.40 and 2.2.7 ?
William A. Rowe, Jr. wrote: There's a simple way of not-so-rudely saying ... Sorry if this came across harshly Odin, I watch those dialogs daily on php-dev, I'd hate to see httpd-dev polluted with the same volume of self interest and vitriol. Let me make sure I answered what you might have been asking... One thing I *wasn't* suggesting was to hold off 2.2 for some magical activity on 2.0; the security fix is already in, the sort-of-security-related fixes to methods are ready to commit, missing one last +1. There are a few others, but if people can't review them this weekend, I agree Jim shouldn't be pushed to change his game plan at all. Early next week really sounds great to me. Bill
RE: (resend) RE: mod_ssl
On Fri, Dec 14, 2007 at 11:01:09AM -0500, Hammer, Tim wrote: No, I am trying to use the new (2.2.x) mod_ssl with our modules that have been ported from 1.3.x to 2.2.x. However, the port did not convert our modules to use buckets and I am wondering if the new mod_ssl is requiring the content generator(s) (our modules) to have created a brigade. Ah. And everything works when mod_ssl is left out? Yes. .Tim Xerox Corporation, Office Group Phone: 585/427-1684 Fax: 585/427-3244 Email: [EMAIL PROTECTED] Addr: M/S 0801-80A 1350 Jefferson Road Rochester, NY 14623 This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient(s) please contact the sender by reply e-mail and destroy all copies of the original message. Thank you.
Re: time for 1.3.40 and 2.2.7 ?
On 12/14/2007 08:24 PM, Jim Jagielski wrote: On Dec 14, 2007, at 12:52 PM, William A. Rowe, Jr. wrote: Jim Jagielski wrote: Anyone opposed to us shooting for a TR early next week? If we can get a couple of security-related-but-not-really patches committed to 2.0 I'd like to see that as well. I'm offering, Sure... that would be great. Another three-for-all :) From what I can see, both 1.3 and 2.2 are backport There is one open for 2.2.x which seems to be a low hanging fruit and only missing one vote regarding mod_ssl. Would be nice to have this one in. Regards Rüdiger
Re: time for 1.3.40 and 2.2.7 ?
Hi, Jim Jagielski schrieb: From what I can see, both 1.3 and 2.2 are backport free, so it's just 2.0 right now. maybe a good candidate for inclusion in 2.0 would be http://issues.apache.org/bugzilla/show_bug.cgi?id=43943 shmcb crash on Sparc when compiled with gcc 4. It has been fixed with a noinline compiler attribute for 2.2.x in 2006 and the same fix applies and works for 2.0.x to: http://svn.apache.org/viewvc?view=revrevision=382799 Regards, Rainer
