Re: Calling another URL from output filter
Hi Sorin Can you share your code for this cae so that I can take a look to get an understanding. Can I call a uri on a different server before the proxy to the requested server ? Rgds Bhaskar On 03/05/2012 04:26 AM, Sorin Manolache wrote: On 2012-03-04 19:19, Swaminathan Bhaskar wrote: Hello, How can I call another url from an output filter - here is the scenario: when a client accesses abc.mydomain.com/signon, this url autheticates the user and we dont want the response going back to the client rather call another url xyz.mydomain.com/fetchdata which will return some data ... we want to send the data from the second url and response headers from first url merged back to the client. So my thought is to intercept the response from the first url in an output ffilter and make a call from the output filter to the second url. What function call would allow me to make th call to the second url Any help appreciated Hello, We did something similar but we didn't issue the 2nd request from the output filter of the first. The first request was made by the apache subrequest API (the ap_sub_req_lookup_uri and ap_run_sub_req functions). The output filter ran until it encountered an end-of-stream. It did not make any other request. The output filter of the subrequest did not pass any brigade to downstream filters. It simply parsed the response, stored relevant data in some structure and returned APR_SUCCESS to its upstream filters. Next, after ap_run_sub_req returned, we invoked the 2nd URL via the proxy module. The useful data returned by the 1st URL was taken from the structure in which the subrequest stored it. Calling a 2nd URL from output filters is a bit tricky, as you have filter-chains invoked from within a filter-chain, so we preferred to call the 2nd URL only after the request to the first completed. Regards, Sorin
one question about HTTP response header Content-Length
hi, I have a private module which want to get the ultimate value of Content-Length , and I hook this module in fixups. However, result shows that Content-Length is NULL when I get it. Which process should I hook if I want to get Content-Length's ultimate value? Any suggestion? Many thanks! Vic -- Best regards, Rui Hu State Key Laboratory of Networking Switching Technology Beijing University of Posts and Telecommunications(BUPT) MSN: tchrb...@gmail.com -
Re: A push for 2.4.2
On 15/03/2012 07:29, William A. Rowe Jr. wrote: On 3/14/2012 2:36 PM, Jim Jagielski wrote: In the attempts to keep the momentum going, I'd like to push for a httpd 2.4.2 release Real Soon Now. Then this afternoon I'll propose a 'really small patch' around 'the win32 issue' and ask folks who have had problems, and those who have not, to test it out. It appears MSDN documentation was not our friend and their directives were misplaced, and the patch should drop some code (not used back in 2.2) which might be the underlying cause of Steffan and crew's issues. We would probably hear back within the day, so windows folks would be very happy with a TR sometime Friday-Monday. I just can't recall offhand if all the win32 quirks in apr were resolved in 1.4.6, or a new TR is still needed on that side bill++ :) Any chance you can elaborate on It appears MSDN documentation was not our friend... etc? Issac
Re: A push for 2.4.2
On 15/03/2012 07:29, William A. Rowe Jr. wrote: On 3/14/2012 2:36 PM, Jim Jagielski wrote: In the attempts to keep the momentum going, I'd like to push for a httpd 2.4.2 release Real Soon Now. Then this afternoon I'll propose a 'really small patch' around 'the win32 issue' and ask folks who have had problems, and those who have not, to test it out. It appears MSDN documentation was not our friend and their directives were misplaced, and the patch should drop some code (not used back in 2.2) which might be the underlying cause of Steffan and crew's issues. We would probably hear back within the day, so windows folks would be very happy with a TR sometime Friday-Monday. I just can't recall offhand if all the win32 quirks in apr were resolved in 1.4.6, or a new TR is still needed on that side bill++ :) Any chance you can elaborate on It appears MSDN documentation... etc? Issac
Re: A push for 2.4.2
On 3/15/2012 4:07 AM, Issac Goldstand wrote: Any chance you can elaborate on It appears MSDN documentation was not our friend... etc? From MSDN and my understanding of the new wait-on-event API, it appeared that MSDN suggested these would be defaults and we would have to adjust for apr's assumptions (in server/mpm/winnt/child.c); /* Restore the state corresponding to apr_os_sock_make's default * assumption of timeout -1 (really, a flaw of os_sock_make and * os_sock_put that it does not query to determine -timeout). * XXX: Upon a fix to APR, these three statements should disappear. */ ioctlsocket(context-accept_socket, FIONBIO, zero); setsockopt(context-accept_socket, SOL_SOCKET, SO_RCVTIMEO, (char *) zero, sizeof(zero)); setsockopt(context-accept_socket, SOL_SOCKET, SO_SNDTIMEO, (char *) zero, sizeof(zero)); but no, apparently this is not the case, and these can't be assumed to be appropriate for both AcceptEx and accept style logic.
Re: A push for 2.4.2
Bill, Us Windows folk would be ecstatic! It is affecting a few noisy users, then there's the silent masses :) Not sure what APR quirks, refresh my memory. I'm +1 for a APU 1.4.2 also, crypto not building for static lib throws a decent sized monkey wrench into the httpd build. Then maybe we can connect the dots in the .dsw files and in makefile.win (which you have started sort of). Gregg On 3/14/2012 10:29 PM, William A. Rowe Jr. wrote: On 3/14/2012 2:36 PM, Jim Jagielski wrote: In the attempts to keep the momentum going, I'd like to push for a httpd 2.4.2 release Real Soon Now. Then this afternoon I'll propose a 'really small patch' around 'the win32 issue' and ask folks who have had problems, and those who have not, to test it out. It appears MSDN documentation was not our friend and their directives were misplaced, and the patch should drop some code (not used back in 2.2) which might be the underlying cause of Steffan and crew's issues. We would probably hear back within the day, so windows folks would be very happy with a TR sometime Friday-Monday. I just can't recall offhand if all the win32 quirks in apr were resolved in 1.4.6, or a new TR is still needed on that side?
Re: A push for 2.4.2
Gregg, I believe these overrides are either not needed at all, or are not needed in specific cases, and have yet to determine which is the case that the users are experiencing. Is anyone complaining about AcceptFilter data or connection? If not, then these lines of code simply need to be dodged for AcceptFilter none. On 3/15/2012 6:06 AM, Gregg Smith wrote: Bill, Us Windows folk would be ecstatic! It is affecting a few noisy users, then there's the silent masses :) Not sure what APR quirks, refresh my memory. I'm +1 for a APU 1.4.2 also, crypto not building for static lib throws a decent sized monkey wrench into the httpd build. Then maybe we can connect the dots in the .dsw files and in makefile.win (which you have started sort of). Gregg On 3/14/2012 10:29 PM, William A. Rowe Jr. wrote: On 3/14/2012 2:36 PM, Jim Jagielski wrote: In the attempts to keep the momentum going, I'd like to push for a httpd 2.4.2 release Real Soon Now. Then this afternoon I'll propose a 'really small patch' around 'the win32 issue' and ask folks who have had problems, and those who have not, to test it out. It appears MSDN documentation was not our friend and their directives were misplaced, and the patch should drop some code (not used back in 2.2) which might be the underlying cause of Steffan and crew's issues. We would probably hear back within the day, so windows folks would be very happy with a TR sometime Friday-Monday. I just can't recall offhand if all the win32 quirks in apr were resolved in 1.4.6, or a new TR is still needed on that side?
Re: A push for 2.4.2
On 15 Mar 2012, at 1:06 PM, Gregg Smith wrote: Us Windows folk would be ecstatic! It is affecting a few noisy users, then there's the silent masses :) Not sure what APR quirks, refresh my memory. I'm +1 for a APU 1.4.2 also, crypto not building for static lib throws a decent sized monkey wrench into the httpd build. Then maybe we can connect the dots in the .dsw files and in makefile.win (which you have started sort of). Happy to RM an apr-util release. Am I right in understanding the issues are fixed and we're good to go? Regards, Graham -- smime.p7s Description: S/MIME cryptographic signature
Re: A push for 2.4.2
On Mar 15, 2012, at 7:06 AM, Gregg Smith wrote: Bill, Us Windows folk would be ecstatic! It is affecting a few noisy users, then there's the silent masses :) Not sure what APR quirks, refresh my memory. I'm +1 for a APU 1.4.2 also, crypto not building for static lib throws a decent sized monkey wrench into the httpd build. Then maybe we can connect the dots in the .dsw files and in makefile.win (which you have started sort of). +1 for APU 1.4.2 (adding APR to this thread)... I can RM if need be.
mod_dav_fs does not check for return value on stream_close
Could somebody review the patch below for 2.2, 2.4, and trunk?
A better error message could be sent, but I am more worried about how the
return will effect the code after it.
I am thinking the file needs to be removed either via a apr_file_remove call or:
apr_pool_cleanup_kill(stream-p, stream, tmpfile_cleanup);
call, but I don't know the code well enough to know which is right and
2.4/trunk adds even more complexity compared to 2.2.x.
Thoughts/Comments?
Thanks,
Brian
- I am still getting more details why close is failing, but for some reason it
is happening enough to cause issues. (responding 200, but no file)
-
2.2:
Index: modules/dav/fs/repos.c
===
--- modules/dav/fs/repos.c (revision 1300964)
+++ modules/dav/fs/repos.c (working copy)
@@ -881,6 +881,10 @@
{
apr_file_close(stream-f);
+if (status != APR_SUCCESS) {
+ return dav_new_error(stream-p, MAP_IO2HTTP(status), 0, There was a
problem closing the stream);
+}
+
if (!commit) {
if (apr_file_remove(stream-pathname, stream-p) != APR_SUCCESS) {
/* ### use a better description? */
2.24 and trunk:
Index: modules/dav/fs/repos.c
===
--- modules/dav/fs/repos.c (revision 1300964)
+++ modules/dav/fs/repos.c (working copy)
@@ -970,6 +970,10 @@
apr_file_close(stream-f);
+if (status != APR_SUCCESS) {
+ return dav_new_error(stream-p, MAP_IO2HTTP(status), 0, There was a
problem closing the stream);
+}
+
if (!commit) {
if (stream-temppath) {
apr_pool_cleanup_run(stream-p, stream, tmpfile_cleanup);
Re: A push for 2.4.2
Bill, not that pages are not showing up, the only problem with AcceptFilter data has been the AcceptEx error/becoming unresponsive. I admit to never suggesting trying AcceptFilter connect. Of course, the problem is on the https side so I never tell them to go to none for https. I leave mine at the default (data) for https, have a script that monitors the error log and sends a graceful restart when it detects a new AcceptEx error. I do not think I have ever recieved a blank/partial page with the default. If you have a patch, I'll be glad to patch 2.4 head and try it out. On 3/15/2012 4:13 AM, William A. Rowe Jr. wrote: Gregg, I believe these overrides are either not needed at all, or are not needed in specific cases, and have yet to determine which is the case that the users are experiencing. Is anyone complaining about AcceptFilter data or connection? If not, then these lines of code simply need to be dodged for AcceptFilter none. On 3/15/2012 6:06 AM, Gregg Smith wrote: Bill, Us Windows folk would be ecstatic! It is affecting a few noisy users, then there's the silent masses :) Not sure what APR quirks, refresh my memory. I'm +1 for a APU 1.4.2 also, crypto not building for static lib throws a decent sized monkey wrench into the httpd build. Then maybe we can connect the dots in the .dsw files and in makefile.win (which you have started sort of). Gregg On 3/14/2012 10:29 PM, William A. Rowe Jr. wrote: On 3/14/2012 2:36 PM, Jim Jagielski wrote: In the attempts to keep the momentum going, I'd like to push for a httpd 2.4.2 release Real Soon Now. Then this afternoon I'll propose a 'really small patch' around 'the win32 issue' and ask folks who have had problems, and those who have not, to test it out. It appears MSDN documentation was not our friend and their directives were misplaced, and the patch should drop some code (not used back in 2.2) which might be the underlying cause of Steffan and crew's issues. We would probably hear back within the day, so windows folks would be very happy with a TR sometime Friday-Monday. I just can't recall offhand if all the win32 quirks in apr were resolved in 1.4.6, or a new TR is still needed on that side?
Re: Cannot start httpd v2.4.1 with mpm_build on AIX
Hi Jeff, Am 07.03.2012 13:27, schrieb Jeff Trawick: On Tue, Mar 6, 2012 at 8:00 PM, Guenter Knauffua...@apache.org wrote: Hi Jeff, Am 26.02.2012 22:44, schrieb Jeff Trawick: I guess the problem is that those MPM APIs are not decorated with AP_DECLARE() so they don't get added to httpd.exp so they don't get exported from httpd on AIX. Can you try the attached patch to mpm_common.h? it seems that this breaks the NetWare build now; I've not looked into it myself since I'm swamped currently with other stuff, but Norm just sent me this mail: Hi, Tried to send this to devAThttpd-apache but it got bounced; how peasant compared to other lists I've sent issues to. I'll watch for fixes. r1294936 causes extra export symbols. Hi, Re httpd-trunk: r1294936 added AP_DECLARE_xxx() to a number of func prototypes/vars in mpm_common.h. These are now found by the 'build/nw_exp_var.awk' script, which causes the NetWare apache2 link to fail for missing exports. As these functions are NOT common to NetWare or likely other non-Unix OS (all seem to be in mpm_unix or related mpm's such as event and worker), should these prototypes/vsrs now be in ap_mpm.h instead? Norm Thanks; I'll look into that. any news on that? Sorry, but unless you give a clear statement on how to proceed with these I'm unable to fix it self; if you say that these functions need to be extported by every platform then fine - we must then either provide dummies for those platforms which dont have them, or ifdef; or we need to move these into a unix-only header; its IMO not ok to suddenly decide to export these functions in order to fix one platform and break another one for that; and also I'm curious how Windows builds can cope with that, and wonder that nothing yet came from this end ... here are the sysmbols in question: LINK obj_release/Apache2.nlm ### mwldnlm Linker Error: # Undefined symbol: ] in # Export list ### mwldnlm Linker Error: # Undefined symbol: ap_fatal_signal_child_setup in # Export list ### mwldnlm Linker Error: # Undefined symbol: ap_fatal_signal_setup in # Export list ### mwldnlm Linker Error: # Undefined symbol: ap_mpm_safe_kill in # Export list ### mwldnlm Linker Error: # Undefined symbol: ap_process_child_status in # Export list ### mwldnlm Linker Error: # Undefined symbol: ap_reclaim_child_processes in # Export list ### mwldnlm Linker Error: # Undefined symbol: ap_register_extra_mpm_process in # Export list ### mwldnlm Linker Error: # Undefined symbol: ap_relieve_child_processes in # Export list ### mwldnlm Linker Error: # Undefined symbol: ap_unregister_extra_mpm_process in # Export list where the 1st one is a quirk from the awk script ... Gün.
CVE requested for mod-fcgid 2.3.6 (possible DoS vulnerability)
Hi Apache folks-- Just a heads-up to let you know that i've requested a CVE for mod_fcgid's 2.3.6 (the current release) due to possible DoS based on the module not respecting administrator-configured limits: http://www.openwall.com/lists/oss-security/2012/03/15/10 The issue is fixed in r1037727, but apparently not yet released. The issue is also in the bugtracker as: https://issues.apache.org/bugzilla/show_bug.cgi?id=49902 Thanks for your work on apache! Regards, --dkg PS please keep me in the CC if there's more discussion; i've subscribed to http-dev to give this heads-up, but can't cope with yet another e-mail firehose for the long term. :/
Re: A push for 2.4.2
Graham, Current APU 1.4 head builds fine. It looks like your fix for this is the only thing in changes. On 3/15/2012 4:13 AM, Graham Leggett wrote: On 15 Mar 2012, at 1:06 PM, Gregg Smith wrote: Us Windows folk would be ecstatic! It is affecting a few noisy users, then there's the silent masses :) Not sure what APR quirks, refresh my memory. I'm +1 for a APU 1.4.2 also, crypto not building for static lib throws a decent sized monkey wrench into the httpd build. Then maybe we can connect the dots in the .dsw files and in makefile.win (which you have started sort of). Happy to RM an apr-util release. Am I right in understanding the issues are fixed and we're good to go? Regards, Graham --
Fwd: Working Group Last Call: httpbis p4 / p5 / p6 / p7
In case some folks want to check our compliance and fix the spec (or the code) if we aren't ... now is the time. Roy Begin forwarded message: Resent-From: ietf-http...@w3.org From: Mark Nottingham m...@mnot.net Subject: Working Group Last Call: httpbis p4 / p5 / p6 / p7 Date: March 15, 2012 12:20:50 AM PDT To: HTTP Working Group ietf-http...@w3.org After discussion with the editors and ADs, I believe the following documents are ready for Working Group Last Call (WGLC): HTTP/1.1, part 4: Conditional Requests http://tools.ietf.org/html/draft-ietf-httpbis-p4-conditional-19 HTTP/1.1, part 5: Range Requests and Partial Responses http://tools.ietf.org/html/draft-ietf-httpbis-p5-range-19 HTTP/1.1, part 6: Caching http://tools.ietf.org/html/draft-ietf-httpbis-p6-cache-19 HTTP/1.1, part 7: Authentication http://tools.ietf.org/html/draft-ietf-httpbis-p7-auth-19 To encourage implementers to review and provide feedback on the documents, we're doing a four-week WGLC, ending on April 12, 2012. However, early reviews are appreciated, as that will give us the opportunity to discuss potential changes at our Paris meeting. *** Providing Feedback Your input should be sent to this mailing list, clearly marked with WGLC and the appropriate part. E.g., with Subject lines such as: Subject: WGLC review of p4-conditional Subject: WGLC issue: foo in p5 Issues that you believe to be editorial in nature (e.g., typos, suggested re-phrasing) can be grouped together in a single e-mail. Substantive issues (what we call design issues) that may need discussion should be sent one per e-mail, with a descriptive subject. If you disagree with the resolution of a previously discussed issue, you're encouraged to note that at this time. *** What's Next The Working Group will discuss these issues, re-issuing drafts as necessary. Tickets raised on these drafts will have a severity of In WG Last Call , and once they are disposed of, we'll see if there's consensus on going to IETF Last Call on them (as Chair, I'll judge this for each document except p6, where I'll defer to Mark Baker, the document shepherd, since I've edited a substantial part of that specification). p1, p2 and p3 should join them in WGLC at or shortly after our Paris meeting. We anticipate sending all of the documents to IETF LC together. Thanks to the editors for their hard work in getting to this point. -- Mark Nottingham http://www.mnot.net/ Begin forwarded message: Resent-From: ietf-http...@w3.org From: Julian Reschke julian.resc...@gmx.de Subject: Re: Working Group Last Call: httpbis p4 / p5 / p6 / p7 Date: March 15, 2012 1:23:00 AM PDT To: HTTP Working Group ietf-http...@w3.org Hi there, please also note that we have HTML versions at https://svn.tools.ietf.org/svn/wg/httpbis/draft-ietf-httpbis/19/p4-conditional.html https://svn.tools.ietf.org/svn/wg/httpbis/draft-ietf-httpbis/19/p5-range.html https://svn.tools.ietf.org/svn/wg/httpbis/draft-ietf-httpbis/19/p6-cache.html https://svn.tools.ietf.org/svn/wg/httpbis/draft-ietf-httpbis/19/p7-auth.html which come with feedback links that should make it really simple to provide quick comments. Also, we'll continue to work on the drafts as comments come in; you can always find the latest and greatest at https://svn.tools.ietf.org/svn/wg/httpbis/draft-ietf-httpbis/latest/p4-conditional.html https://svn.tools.ietf.org/svn/wg/httpbis/draft-ietf-httpbis/latest/p5-range.html https://svn.tools.ietf.org/svn/wg/httpbis/draft-ietf-httpbis/latest/p6-cache.html https://svn.tools.ietf.org/svn/wg/httpbis/draft-ietf-httpbis/latest/p7-auth.html For trivial corrections, if you suspect that somebody else might already have reported the bug, you may want to check here whether it's fixed already. Looking forward to review comments. Julian
Re: Cannot start httpd v2.4.1 with mpm_build on AIX
On 3/15/2012 1:47 PM, Guenter Knauf wrote: any news on that? Sorry, but unless you give a clear statement on how to proceed with these I'm unable to fix it self; if you say that these functions need to be extported by every platform then fine - we must then either provide dummies for those platforms which dont have them, or ifdef; or we need to move these into a unix-only header; its IMO not ok to suddenly decide to export these functions in order to fix one platform and break another one for that; and also I'm curious how Windows builds can cope with that, and wonder that nothing yet came from this end ... here are the sysmbols in question: I believe the NW implementation is probably an abuse of that macro. You are responsible for ignoring anything that wasz #if[n]def'ed away. Here's a thought; can we cleverly do something to run those headers through the cpp to drop all of the not-netware defined declarations, picking up only the remaining declarations in the netware code path?
Re: Cannot start httpd v2.4.1 with mpm_build on AIX
On Thu, Mar 15, 2012 at 2:47 PM, Guenter Knauf fua...@apache.org wrote: Hi Jeff, Am 07.03.2012 13:27, schrieb Jeff Trawick: On Tue, Mar 6, 2012 at 8:00 PM, Guenter Knauffua...@apache.org wrote: Hi Jeff, Am 26.02.2012 22:44, schrieb Jeff Trawick: I guess the problem is that those MPM APIs are not decorated with AP_DECLARE() so they don't get added to httpd.exp so they don't get exported from httpd on AIX. Can you try the attached patch to mpm_common.h? it seems that this breaks the NetWare build now; I've not looked into it myself since I'm swamped currently with other stuff, but Norm just sent me this mail: Hi, Tried to send this to devAThttpd-apache but it got bounced; how peasant compared to other lists I've sent issues to. I'll watch for fixes. r1294936 causes extra export symbols. Hi, Re httpd-trunk: r1294936 added AP_DECLARE_xxx() to a number of func prototypes/vars in mpm_common.h. These are now found by the 'build/nw_exp_var.awk' script, which causes the NetWare apache2 link to fail for missing exports. As these functions are NOT common to NetWare or likely other non-Unix OS (all seem to be in mpm_unix or related mpm's such as event and worker), should these prototypes/vsrs now be in ap_mpm.h instead? Norm Thanks; I'll look into that. any news on that? Sorry, but unless you give a clear statement on how to proceed with these I'm unable to fix it self; The short form is that I'm going to revert the trunk commit(s) today, and when there's a good solution I'll put them back with the fix and propose them for backport to 2.4.x. I acknowledge wrowe's comment later in the thread, but wonder first how practical it is to ensure that the declarations are visible only if there is an implementation without going back to an equivalent of the old AP_MPM_WANT_thisfunction, AP_MPM_WANT_thatfunction. if you say that these functions need to be extported by every platform then fine - we must then either provide dummies for those platforms which dont have them, or ifdef; or we need to move these into a unix-only header; its IMO not ok to suddenly decide to export these functions in order to fix one platform and break another one for that; and also I'm curious how Windows builds can cope with that, and wonder that nothing yet came from this end ... here are the sysmbols in question: LINK obj_release/Apache2.nlm ### mwldnlm Linker Error: # Undefined symbol: ] in # Export list ### mwldnlm Linker Error: # Undefined symbol: ap_fatal_signal_child_setup in # Export list ### mwldnlm Linker Error: # Undefined symbol: ap_fatal_signal_setup in # Export list ### mwldnlm Linker Error: # Undefined symbol: ap_mpm_safe_kill in # Export list ### mwldnlm Linker Error: # Undefined symbol: ap_process_child_status in # Export list ### mwldnlm Linker Error: # Undefined symbol: ap_reclaim_child_processes in # Export list ### mwldnlm Linker Error: # Undefined symbol: ap_register_extra_mpm_process in # Export list ### mwldnlm Linker Error: # Undefined symbol: ap_relieve_child_processes in # Export list ### mwldnlm Linker Error: # Undefined symbol: ap_unregister_extra_mpm_process in # Export list where the 1st one is a quirk from the awk script ... Gün. -- Born in Roswell... married an alien...
Re: Cannot start httpd v2.4.1 with mpm_build on AIX
Jeff, Am 15.03.2012 22:32, schrieb Jeff Trawick: The short form is that I'm going to revert the trunk commit(s) today, and when there's a good solution I'll put them back with the fix and propose them for backport to 2.4.x. if we are fine with few '#ifndef NETWARE' in mpm_common.h then I commit this - I have it already here for testing ... and dont get my ping a rant - I only wanted to know how to proceed with this issue. Gün.
Re: Cannot start httpd v2.4.1 with mpm_build on AIX
On Thu, Mar 15, 2012 at 5:48 PM, Guenter Knauf fua...@apache.org wrote: Jeff, Am 15.03.2012 22:32, schrieb Jeff Trawick: The short form is that I'm going to revert the trunk commit(s) today, and when there's a good solution I'll put them back with the fix and propose them for backport to 2.4.x. if we are fine with few '#ifndef NETWARE' in mpm_common.h then I commit this - I have it already here for testing ... More fixes are needed besides NETWARE... and dont get my ping a rant - I only wanted to know how to proceed with this issue. no offence taken Gün. -- Born in Roswell... married an alien...
Re: Cannot start httpd v2.4.1 with mpm_build on AIX
Jeff, Am 16.03.2012 00:33, schrieb Jeff Trawick: On Thu, Mar 15, 2012 at 5:48 PM, Guenter Knauffua...@apache.org wrote: Jeff, Am 15.03.2012 22:32, schrieb Jeff Trawick: The short form is that I'm going to revert the trunk commit(s) today, and when there's a good solution I'll put them back with the fix and propose them for backport to 2.4.x. if we are fine with few '#ifndef NETWARE' in mpm_common.h then I commit this - I have it already here for testing ... More fixes are needed besides NETWARE... I know, as I assumed Windows is broken either - Gregg just comfirmed ... I proceed, and commit some fixes for both NetWare and Windows, so no need to revert; and BTW if I would build the NetWare MPM as a module instead of statically linking I would certainly face similar issues ... Gün.
Re: Cannot start httpd v2.4.1 with mpm_build on AIX
On Thu, Mar 15, 2012 at 7:47 PM, Guenter Knauf fua...@apache.org wrote: Jeff, Am 16.03.2012 00:33, schrieb Jeff Trawick: On Thu, Mar 15, 2012 at 5:48 PM, Guenter Knauffua...@apache.org wrote: Jeff, Am 15.03.2012 22:32, schrieb Jeff Trawick: The short form is that I'm going to revert the trunk commit(s) today, and when there's a good solution I'll put them back with the fix and propose them for backport to 2.4.x. if we are fine with few '#ifndef NETWARE' in mpm_common.h then I commit this - I have it already here for testing ... More fixes are needed besides NETWARE... I know, as I assumed Windows is broken either - Gregg just comfirmed ... I proceed, and commit some fixes for both NetWare and Windows, so no need to revert; and BTW if I would build the NetWare MPM as a module instead of statically linking I would certainly face similar issues ... whoops, just reverted :)
