Re: about setting r-headers_out
On 02/29/12 07:52, Rui Hu wrote: hi, I want to set Content-Type and Cache-Control fields in my private module. So I hooked fixups and used apr_table_setn to set r-headers_out but nothing happened. Was it thought through? Thanks for you help! Try to set r-err_headers_out. For content-type you could check the configuration directive DefaultType. You could also set Cache-Control with the Headers directive. Check its always option too. You can also combine the Headers directive with environment variables set in r-subprocess_env. Check http://httpd.apache.org/docs/2.0/mod/mod_headers.html#header Regards, Sorin
Re: about setting r-headers_out
Thanks! I tried to hook handler and it works well. Rui Hu 2012/2/29 Sorin Manolache sor...@gmail.com On 02/29/12 07:52, Rui Hu wrote: hi, I want to set Content-Type and Cache-Control fields in my private module. So I hooked fixups and used apr_table_setn to set r-headers_out but nothing happened. Was it thought through? Thanks for you help! Try to set r-err_headers_out. For content-type you could check the configuration directive DefaultType. You could also set Cache-Control with the Headers directive. Check its always option too. You can also combine the Headers directive with environment variables set in r-subprocess_env. Check http://httpd.apache.org/docs/** 2.0/mod/mod_headers.html#**headerhttp://httpd.apache.org/docs/2.0/mod/mod_headers.html#header Regards, Sorin -- Best regards, Rui Hu State Key Laboratory of Networking Switching Technology Beijing University of Posts and Telecommunications(BUPT) MSN: tchrb...@gmail.com -
one problem when calling ap_get_module_config
I use r-request_config to store module data as a substitute for global vars. One type_checker_hook function uses ap_get_module_config at its beginning. But what I got is NULL. Strangely, post_read_request_hook function works fine, whose codes is basically the same. Is there any caution in calling this function? Thanks! Best regards, Rui Hu State Key Laboratory of Networking Switching Technology Beijing University of Posts and Telecommunications(BUPT) MSN: tchrb...@gmail.com -
Re: Threads and signals in a module
On 2012-02-28 22:05, Ben Rockefeller wrote: Hello, I have a module which creates a thread using pthread_create and then registers for SIGRTMIN+4 signal from another process. Problem is I do not see a signal callback when the signal is sent to me. I only see it when I try to kill apache where just before dying it hits the signal callback. So something in Apache is blocking the signal. I am using worker MPM. What could be the issue. I do not have much leeway into changing the design of the module (the threading model comes from a separate lib which I link into the module)...but I can change to use a different signal than SIGRTMIN+4, etc. I can also change apache and recompile apache if needed. Please let me know if you have any suggestions. I have been stuck at this for a while now :-( Thanks In which hook do you create your thread and you register your signal handler? Right after executing the child_init callbacks, apache blocks the threads from receiving most signals. Check the list of blocked/ignored/caught signals using ps axs in a shell. Sorin
Re: one problem when calling ap_get_module_config
On 29 Feb 2012, at 10:47, Rui Hu wrote: I use r-request_config to store module data as a substitute for global vars. One type_checker_hook function uses ap_get_module_config at its beginning. But what I got is NULL. Strangely, post_read_request_hook function works fine, whose codes is basically the same. Any subrequests or internal redirects involved? Look carefully at the request object itself. Or tyops? -- Nick Kew
Intercepting HTTP 301/302 redirects
Hi Is there anyway to intercept HTTP 301/302 redirects ? I tried registering a very simple output filter (AP_FTYPE_RESOURCE) and the filter function did not get a callback. I would assume all output goes through the filter chain Rgds Bhaskar
Re: Intercepting HTTP 301/302 redirects
On 02/29/2012 06:01 PM, Swaminathan Bhaskar wrote: Hi Is there anyway to intercept HTTP 301/302 redirects ? I tried registering a very simple output filter (AP_FTYPE_RESOURCE) and the filter function did not get a callback. I would assume all output goes through the filter chain Rgds Bhaskar Did you hook the ap_hook_insert_error_filter function? For errors, you need that one. Joe -- http://www.silverhawk.net/
Re: Intercepting HTTP 301/302 redirects
Thanks for the quick response Joe. Just to make sure, here is what I did:
IfModule mod_myfilter.c
Location /
SetOutputFilter myfilter
/Location
/IfModule
and the code
#include stdio.h
#include httpd.h
#include http_protocol.h
#include http_config.h
#include util_filter.h
#define MY_FILTER_NAME myfilter
static int my_output_filter(ap_filter_t *f, apr_bucket_brigade *bb)
{
fprintf(stderr, mod_myfilter: status = %d, status-line = %s\n,
f-r-status, f-r-status_line);
ap_pass_brigade(f-next, bb);
return APR_SUCCESS;
}
static void my_filter_hooks(apr_pool_t *pool)
{
ap_register_output_filter(MY_FILTER_NAME, my_output_filter, NULL,
AP_FTYPE_RESOURCE);
fprintf(stderr, mod_myfilter: registered my_output_filter\n);
}
module AP_MODULE_DECLARE_DATA myfilter_module = {
STANDARD20_MODULE_STUFF,
NULL,
NULL,
NULL,
NULL,
NULL,
my_filter_hooks
};
I setup an intentional redirect for testing
Redirect 301 /red.htm http://localhost/green.htm
When I try http://localhost/, should I not see the output from myfilter ?
May be I am doing something wrong ?
Also you indicated I need to hook into ap_hook_insert_error_filter -
would you by any chance have any sample code ?
Rgds
Bhaskar
On 02/29/2012 08:06 PM, Joe Lewis wrote:
On 02/29/2012 06:01 PM, Swaminathan Bhaskar wrote:
Hi
Is there anyway to intercept HTTP 301/302 redirects ? I tried
registering a very simple output filter (AP_FTYPE_RESOURCE) and the
filter function did not get a callback. I would assume all output
goes through the filter chain
Rgds
Bhaskar
Did you hook the ap_hook_insert_error_filter function? For errors,
you need that one.
Joe
--
http://www.silverhawk.net/
Re: svn commit: r1294936 - in /httpd/httpd/trunk: CHANGES include/mpm_common.h include/scoreboard.h
On Tue, Feb 28, 2012 at 10:01 PM, William A. Rowe Jr. wr...@rowe-clan.net wrote: On 2/28/2012 8:11 PM, Jeff Trawick wrote: AP_DECLARE_DATA just affects visibility, but the switch to __stdcall for AP_DECLARE() is an API change. (important, since AIX needs this in 2.4.x) If they weren't AP_DECLARE()ed before, they weren't exported. Ergo they are only used internally. Sure, if someone has a checkout and doesn't rebuild-all, that would be an issue, but let's just assume that recompiling only half the sources between 2.4.1 and 2.4.2 is a non-starter. Remember function signatures need to match between the .h and .c. This commit was only half a change. Thanks so much! (d'oh :) )
Re: one problem when calling ap_get_module_config
thanks! Problem solved. It the problem with internal redirects. 2012/2/29 Nick Kew n...@apache.org On 29 Feb 2012, at 10:47, Rui Hu wrote: I use r-request_config to store module data as a substitute for global vars. One type_checker_hook function uses ap_get_module_config at its beginning. But what I got is NULL. Strangely, post_read_request_hook function works fine, whose codes is basically the same. Any subrequests or internal redirects involved? Look carefully at the request object itself. Or tyops? -- Nick Kew -- Best regards, Rui Hu State Key Laboratory of Networking Switching Technology Beijing University of Posts and Telecommunications(BUPT) MSN: tchrb...@gmail.com -
Windows builds available
All Windows builds for 2.2.22 and 2.4.1 Win32 are now in place at http://www.apachelounge.com/download/ Both VC10 and for the time being also VC9 builds, Win64 64 VC10 follows. Btw. No serious 2.4 bug reports received till now, which you do not already know. All runs fine.
Re: Windows builds available
On 29/02/2012 14:10, Steffen wrote: No serious 2.4 bug reports received till now, which you do not already know. All runs fine. Cool. You refer to reports from users on your forums, I assume? Issac
Re: Windows builds available
Yep and reported directly to me which are primarily companies using/testing the builds. On Wednesday 29/02/2012 at 14:06, Issac Goldstand wrote: On 29/02/2012 14:10, Steffen wrote: No serious 2.4 bug reports received till now, which you do not already know. All runs fine. Cool. You refer to reports from users on your forums, I assume? Issac
答复: Windows builds available
How did you make these builds, particularly those Windows 64 bits Binaries? Can we share the directives, or can your method be integrated into the official release? Bing 发件人: Steffen [mailto:i...@apachelounge.com] 发送时间: 2012年2月29日 21:13 收件人: dev@httpd.apache.org 主题: Re: Windows builds available Yep and reported directly to me which are primarily companies using/testing the builds. On Wednesday 29/02/2012 at 14:06, Issac Goldstand wrote: On 29/02/2012 14:10, Steffen wrote: No serious 2.4 bug reports received till now, which you do not already know. All runs fine. Cool. You refer to reports from users on your forums, I assume? Issac
Re: 答复: Windows builds available
On Wed, Feb 29, 2012 at 8:57 AM, Bing Swen bs...@pku.edu.cn wrote: How did you make these builds, particularly those Windows 64 bits Binaries? Can we share the directives, or can your method be integrated into the official release? The official release is the source code. Binaries are contributed and I think the Windows magic is already understood by a handful of potential contributors.
Re: Proposal: adoption of mod_policy subproject
On Wednesday 29 February 2012 04:11:35 William A. Rowe Jr. wrote: I withdraw this vote, reverting my position to -1, until collaboration and respect for options and insights of fellow committers as well as project decisions and votes can be consistently demonstrated. I always thought, you'd have to provide technical reasons for -1 votes (?). nd
Re: Proposal: adoption of mod_policy subproject
On 2/29/2012 8:59 AM, André Malo wrote: On Wednesday 29 February 2012 04:11:35 William A. Rowe Jr. wrote: I withdraw this vote, reverting my position to -1, until collaboration and respect for options and insights of fellow committers as well as project decisions and votes can be consistently demonstrated. I always thought, you'd have to provide technical reasons for -1 votes (?). No, only for a veto. My technical reason for this vote, although I don't need one, is that Jim is the only other person voting +1 for mod_policy. Technical conclusion is that if there are no developers voting +1, there are no developers committed to maintaining this code alongside minfrin and jim. Which is to say, I withdraw my offer to collaborate or even review this code based on minfrin's absolute inability to collaborate with a committee, as he had evidenced in the ldap code dump, and now in a module dump that he forgot to hold a vote. He had 2 months to revert the firehose mis-commit, he failed. This keeps me from work I need to be doing because I'm chasing out code dumps from httpd. Stupid. This leaves him with a single collaborator? 1-2 man shows aren't encouraged, and never acceptable in core repos/asf/httpd/httpd/. No more votes +1 shows there is no community behind these submissions, but we have subprojects and sandboxes to offer ideas the runway to attract collaborators and a community. It's the reason why mod_aspdotnet was ejected, and why mod_arm4, mod_ftp and perhaps even mod_fcgid are all on their way out of the project as it is, unless more committers participate in those subprojects. Putting more code dumps into core httpd is not going to help create communities, and it proves to be a major obstacle to getting any major.minor release out the door when we get around to noticing that code was never reviewed on the way in. Would I have anything to post if there were 10 +1's to accept minfrin's new modules? Of course not. But as it stands, there are not 10 +1's, so there is not sufficient trust in his submission to mainline it straight to core.
Re: Apache 2.4.1 Throughput compared with nginx
Why even bother... I simply posted a comment and moved on. On Feb 28, 2012, at 4:32 PM, Bing Swen wrote: Some Nginx people just made a performance test with Apache 2.4.1 at http://blog.zhuzhaoyuan.com/category/c10k/ Were the Event_MPM configuration parameters somewhere close to optimal? Regards, Bing Jim Jagielski [mailto:j...@jagunet.com] wrote on 2012年2月24日 20:57 w00t!!! On Feb 23, 2012, at 5:26 PM, MATSUMOTO Ryosuke wrote: Hi all, I evaluated the throughput of Apaceh 2.4.1. I compared apache(2.4.1, 2.2.3) with nginx. I used httperf benchmark 0.9.0 to measure thethroughput. http://blog.matsumoto-r.jp/?p=1812 I feel bad about writing this article in Japanese in my hurry ;) Regards, -- MATSUMOTO Ryosuke matsu1229 at gmail.com http://blog.matsumoto-r.jp/
Re: svn commit: r1215525 - in /httpd/httpd/trunk: ./ docs/manual/mod/ docs/manual/programs/ modules/debugging/ support/
On Feb 28, 2012, at 10:05 PM, William A. Rowe Jr. wrote: You have only three votes for mod_policy... please fix this today, before I withdraw what starts to look like an ill-cast vote for introducing code with dubious support of the community. only three votes??? How many does he need??
Re: Proposal: adoption of mod_policy subproject
On Feb 29, 2012, at 10:32 AM, William A. Rowe Jr. wrote: It's the reason why mod_aspdotnet was ejected, and why mod_arm4, mod_ftp and perhaps even mod_fcgid are all on their way out of the project as it is, unless more committers participate in those subprojects. The other way to approach it is to simply move them *into* the main project, and not as subprojects... We've seen that subprojects do NOT work. There is more activity when they are in the main tree. With the exception of mod_arm4 (which I've never looked at), I would be MORE than comfy having both mod_ftp and mod_fcgid moved into the main tree today.
Re: Apache 2.4.1 Throughput compared with nginx
I entirely agree with you on your comment. 2012/3/1 Jim Jagielski j...@jagunet.com: Why even bother... I simply posted a comment and moved on. On Feb 28, 2012, at 4:32 PM, Bing Swen wrote: Some Nginx people just made a performance test with Apache 2.4.1 at http://blog.zhuzhaoyuan.com/category/c10k/ Were the Event_MPM configuration parameters somewhere close to optimal? Regards, Bing Jim Jagielski [mailto:j...@jagunet.com] wrote on 2012年2月24日 20:57 w00t!!! On Feb 23, 2012, at 5:26 PM, MATSUMOTO Ryosuke wrote: Hi all, I evaluated the throughput of Apaceh 2.4.1. I compared apache(2.4.1, 2.2.3) with nginx. I used httperf benchmark 0.9.0 to measure thethroughput. http://blog.matsumoto-r.jp/?p=1812 I feel bad about writing this article in Japanese in my hurry ;) Regards, -- MATSUMOTO Ryosuke matsu1229 at gmail.com http://blog.matsumoto-r.jp/ -- MATSUMOTO Ryosuke matsu1229 at gmail.com http://blog.matsumoto-r.jp/
Re: Proposal: adoption of mod_policy subproject
+1 - Original Message - On Feb 29, 2012, at 10:32 AM, William A. Rowe Jr. wrote: It's the reason why mod_aspdotnet was ejected, and why mod_arm4, mod_ftp and perhaps even mod_fcgid are all on their way out of the project as it is, unless more committers participate in those subprojects. The other way to approach it is to simply move them *into* the main project, and not as subprojects... We've seen that subprojects do NOT work. There is more activity when they are in the main tree. With the exception of mod_arm4 (which I've never looked at), I would be MORE than comfy having both mod_ftp and mod_fcgid moved into the main tree today. -- Igor Galić Tel: +43 (0) 664 886 22 883 Mail: i.ga...@brainsware.org URL: http://brainsware.org/ GPG: 6880 4155 74BD FD7C B515 2EA5 4B1D 9E08 A097 C9AE
Re: svn commit: r1215525 - in /httpd/httpd/trunk: ./ docs/manual/mod/ docs/manual/programs/ modules/debugging/ support/
On 2/29/2012 9:41 AM, Jim Jagielski wrote: On Feb 28, 2012, at 10:05 PM, William A. Rowe Jr. wrote: You have only three votes for mod_policy... please fix this today, before I withdraw what starts to look like an ill-cast vote for introducing code with dubious support of the community. only three votes??? Correction, now two votes for, with one vote against. My vote was ill-cast, I no longer believe minfrin's behavior is correctable.
Re: Proposal: adoption of mod_policy subproject
On 2/29/2012 9:45 AM, Jim Jagielski wrote: On Feb 29, 2012, at 10:32 AM, William A. Rowe Jr. wrote: It's the reason why mod_aspdotnet was ejected, and why mod_arm4, mod_ftp and perhaps even mod_fcgid are all on their way out of the project as it is, unless more committers participate in those subprojects. The other way to approach it is to simply move them *into* the main project, and not as subprojects... Jim, I respectfully, but profoundly disagree. To have one or fewer active maintainers of a given module in the core distribution is far more problematic than having a stale subproject. The stale subproject cries out for attention if users or developers want to make a release. The core module languishes and impacts more and more users, and the very reputation of this project. We've seen that subprojects do NOT work. There is more activity when they are in the main tree. With the exception of mod_arm4 (which I've never looked at), I would be MORE than comfy having both mod_ftp and mod_fcgid moved into the main tree today. First you've made a blind assertion. Please document how subprojects do not work, so we can get on the same page? If ftp/fcgid should be in trunk (and I'm very, very close to agreeing with you) it is only *because* they lived seperate and distinct lives and have reached some level of collaboration and maturity. You and I and several bugzilla contributors have offered fixes to mod_ftp. Jeff and I and several bugzilla contributors have offered fixes to mod_fcgid. Small but measurable communities of contributors. What is proposed here is for mod_policy and two others to be blindly dropped into httpd trunk without contributors, no oversight, not even ip clearance. You and I aren't likely to come to agreement on this. That isn't how we are supposed to work. Therefore I'm -1 altogether to accepting any of these three contributions until minfrin demonstrates collaboration, apologizes for wasting an incredible amount of many of his colleagues' hours over the whole ldap mess of his creation, and now apologizes for either misinterpreting or misrepresenting the votes cast for these subprojects. If he had any credibility, I'd be immediately supportive of three subprojects, where he could prove his ability to both collaborate and find development support for these creations. Any other outcome is yet another code dump.
Technical reasons for -1 votes (?)
On 2/29/2012 8:59 AM, André Malo wrote: On Wednesday 29 February 2012 04:11:35 William A. Rowe Jr. wrote: I withdraw this vote, reverting my position to -1, until collaboration and respect for options and insights of fellow committers as well as project decisions and votes can be consistently demonstrated. I always thought, you'd have to provide technical reasons for -1 votes (?). Let's take Roy's position on the attached vote discussion, it's relevant. These new modules are certainly additions/deletions to httpd. It is crystal clear that a veto is valid. It is incumbent upon the coder who makes a proposal to overcome objections. In this previous vote, some dozen developers failed to make that case to Graham, and his veto stood. Now Graham comes to the project with three modules and a hope that this isn't a code dump, my intention is to continue to develop and support this moving forward, and hopefully expand the community around them. He said the same thing about completing the LDAP abstraction half a decade ago or more. Attempts to route around his failure were unsuccessful because of his obstructionism. We are at a design impass with the community blocked on some handwave and a commitment to redesign an api someday, but likely never. Nothing can be allowed in core on some hope of expanding a community. Either there is collaboration and the code belongs at httpd, or there is not collaboration and the code does not. There are sandboxes and there are subprojects to begin that justification. Graham was offered that resolution which HE originally proposed, and for two months, has refused to act or acknowledge the demand that he revert his misfiled contribution. My veto to all three modules stands. If three committers with track records of collaboration (meaning most everyone else here) step up with +1 votes that includes their commitment to review and maintain one of these modules, seek the software license grant, and to file the ip-clearance with general@incubator, I'm willing to relax my veto on creating that subproject. But not into a core module until the subproject is successful. ---BeginMessage--- On Jul 12, 2011, at 8:20 AM, Joe Orton wrote: On Sun, Jul 10, 2011 at 03:34:10PM -0700, Roy T. Fielding wrote: Regardless of anyone else's opinion, the addition or deletion of a new API to our product is a technical change that can be vetoed. Likewise, the API being an incomplete abstraction that isn't needed in httpd is a valid technical reason to veto it even if it had once been in apr-util. Other than the convoluted history of this particular argument, I don't see any reason for further frustration. Revert the commit. Yet again: if the objection is to extending the exported mod_ldap API, that objection can be resolved without wholesale revert; most of the stuff added does not need to be exposed in the API, it was just done for consistency. The objection can only be resolved by convincing the person who has objected to change *their* opinion or by removing the thing being objected to. The time for convincing has expired -- let's move on. I do not understand using incomplete abstraction as motivation for veto, because mod_ldap's API was already an incomplete abstraction. If this was OK before, it is not reason for veto now. The API was moved to *this* project and all of the names were changed. It is, effectively, a new public API for this project. We are doomed to revisit this argument time and again if we avoid actually discussing the technical issues. The whole point of having a set of voting guidelines is to avoid having a discussion about process which is colored by the particular issue being discussed and to avoid having discussions about technical issues which become poisoned because of perceived unfairness in the way people's opinions are being respected. Remove the process issue first and then the technical issues can be resolved one at a time as technical issues. Roy ---End Message---
[RFC] try to solidify feature adoption criteria
New features are a natural part of the software life-cycle, but they bring with it a greater product surface area to document and support, as well as more technical issues which could detract from other developer activities. For this reason, the httpd project as a whole has a vested interest in avoiding the inclusion of features which don't have adequate developer interest. This is especially true of the core Apache HTTP Server distribution, but extends also to sub-projects. Without adequate developer interest and oversight, the project cannot distribute and support the feature. Thus, features of a significant nature must be formally accepted. Judging whether or not a feature is significant is inherently subjective, but for the purposes of efficient consideration the following criteria have been established. Any of the following is a new feature which must be formally accepted: * any new plugin module, aside from those created as a result of refactoring existing code in the server * any new separately executable programs intended for end users Acceptance of new features is generally a non-technical issue subject to voting similar to that a release: at least three project members must vote affirmatively for the feature, and there must be more positive than negative votes for the feature. Acceptance can be considered for inclusion in the core server distribution, an existing sub-project, or a new sub-project. Note: Moving an existing feature from a sub-project to the core server distribution is also subject to formal acceptance. A feature may also have technical concerns which must be addressed and are subject to a veto; vetoed technical issues must be resolved before inclusion, even if inclusion of the feature has been accepted. The decision to implement a feature as a new module or part of the core or existing modules is also a technical consideration. As such, a veto against including tangential features in the core server or existing modules could result in approval being required by virtue of the requirement to implement the feature as a separate module. Acceptance of new features is separate from any necessary IP clearance.
Re: svn commit: r1294380 - in /httpd/httpd/branches/2.2.x: build/aix/ build/aix/README build/aix/aixinfo build/aix/buildaix.ksh build/aix/mkinstallp.ksh config.layout
Anyway, ran this live at a customer who is working with AIX5, AIX6 and AIX7. Good news: the package I had built on AIX5, Power5 ran (Syntax test OK) on AIX 7.1 on Power7. Less good news: ./configure did not work using gcc (they had a very old one installed) - embedded apr reported many errors and would not make. Learned something new about APR - a package only works in the same kind of environment. To my surprise, even though configure was finding xlc as a compiler with my vac v7 it returns cc as the compiler - so when I tried to get past the embedded apr compile errors - configure failed again - as cc != gcc and configure said it could not create output. Anyway, until I play with gcc on AIX - not having the scripts is probably safer for 2.2.22 considering it's status. Anyone coming to the devs mailing list will be able to contact me for assistance, should that be so desired. I shall continue looking for ways to resolve this - but now I see a need to have two APR external modules based on compiler used. On Tue, Feb 28, 2012 at 11:25 PM, Michael Felt mamf...@gmail.com wrote: License acceptance is one thing. I dunno what the copyright issue is. Again,m copyright is just something nice, such as: Michael, would it be possible to clarify? There is nothing in the license for httpd that obligates an end user to accept a license before installing, so if they don't need to now, there is no need to change that. If there is no requirement to accept, then it is easy - but the license will still be installed in the default location - should be IMHO. Install Software Type or select values in entry fields. Press Enter AFTER making all desired changes. [TOP] [Entry Fields] * LPP_SOURCE lpp_5307 * Software to Install[+ 4.5.0.5301 Open Se + Customization SCRIPT to run after installation [] + (not applicable to SPOTs) installp Flags PREVIEW only? [no]+ Preview new LICENSE agreements? [no]+ ACCEPT new license agreements? [no]+ COMMIT software updates? [yes] + SAVE replaced files? [no]+ AUTOMATICALLY install requisite software? [yes] + With the above settings, you could get a FAILURE with acceptance required like this: LICENSE AGREEMENT FAILURES -- The software you have selected for installation contains license agreement(s) that must be accepted before proceeding. Failure to accept the license terms will prevent the installation of the software. Accept the license agreement(s) by selecting yes in the Accept new license agreements field or by specifying the -Y option to the installp command. Filesets Requiring Software License Acceptance -- openssh.base.client Without it, or with yes specified anyway, a copyright message similar this could appear: ... © Copyright Jakob Schlyter, 2003. © Copyright Dug Song. 1995 © Copyright Kevin Steves. 1995 © Copyright Peter Stuge stuge-mdoc2...@cdy.org, 2003 © Copyright Todd C. Miller, 1998. © Copyright Darren Tucker 2004. © Copyright Simon Wilkinson, 2001, 2003. © Copyright Tatu Ylonen y...@cs.hut.fi, Espoo, Finland, 1995 All rights reserved. US Government Users Restricted Rights - Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp. . . . . . End of copyright notice for openssh.base . . . . In short - niceties. Regards, Graham --
Checking MPM name
With the new introduction in 2.3/2.4 of the mpm run time specification modules needing to detect which mpm is actually running cannot rely on the old preprocessor symbols once in mpm.h. I confess I've been unable to find a call to the core which returns the loaded mpm name: the module I'm mantaining won't support any mpm different from 'prefork' (until a bunch of issues are clarified and addressed) -- Massimo Manghi
Re: Proposal: adoption of mod_policy subproject
On Feb 29, 2012, at 12:19 PM, William A. Rowe Jr. wrote: On 2/29/2012 9:45 AM, Jim Jagielski wrote: On Feb 29, 2012, at 10:32 AM, William A. Rowe Jr. wrote: It's the reason why mod_aspdotnet was ejected, and why mod_arm4, mod_ftp and perhaps even mod_fcgid are all on their way out of the project as it is, unless more committers participate in those subprojects. The other way to approach it is to simply move them *into* the main project, and not as subprojects... Jim, I respectfully, but profoundly disagree. To have one or fewer active maintainers of a given module in the core distribution is far more problematic than having a stale subproject. The stale subproject cries out for attention if users or developers want to make a release. The core module languishes and impacts more and more users, and the very reputation of this project. mod_rewrite was an external subproject. I submit that it is doing better here, under the main tree. mod_proxy_html was the same. It is under the main. mod_sed... ditto mod_proxy was a subproject, but lives and thrives under the main. You mention that some modules aren't doing well. The ones you mention do not live under the main. The fact is that once a project lives under the main tree, it's part of our shared project...
Re: Technical reasons for -1 votes (?)
Wow... As far as I can tell, we have *never* been so tight arsed with anything else: not mod_proxy_html, mod_sed, mod_rewrite, mod_dumpio, mod_substitute, (add your favorite one here)... And especially not with someone who's been a PMC member for as long as Graham has (~10yrs). I reiterate my +1s for accepting the code and stress that my preference is right in the main tree. On Feb 29, 2012, at 12:42 PM, William A. Rowe Jr. wrote: On 2/29/2012 8:59 AM, André Malo wrote: On Wednesday 29 February 2012 04:11:35 William A. Rowe Jr. wrote: I withdraw this vote, reverting my position to -1, until collaboration and respect for options and insights of fellow committers as well as project decisions and votes can be consistently demonstrated. I always thought, you'd have to provide technical reasons for -1 votes (?). Let's take Roy's position on the attached vote discussion, it's relevant. These new modules are certainly additions/deletions to httpd. It is crystal clear that a veto is valid. It is incumbent upon the coder who makes a proposal to overcome objections. In this previous vote, some dozen developers failed to make that case to Graham, and his veto stood. Now Graham comes to the project with three modules and a hope that this isn't a code dump, my intention is to continue to develop and support this moving forward, and hopefully expand the community around them. He said the same thing about completing the LDAP abstraction half a decade ago or more. Attempts to route around his failure were unsuccessful because of his obstructionism. We are at a design impass with the community blocked on some handwave and a commitment to redesign an api someday, but likely never. Nothing can be allowed in core on some hope of expanding a community. Either there is collaboration and the code belongs at httpd, or there is not collaboration and the code does not. There are sandboxes and there are subprojects to begin that justification. Graham was offered that resolution which HE originally proposed, and for two months, has refused to act or acknowledge the demand that he revert his misfiled contribution. My veto to all three modules stands. If three committers with track records of collaboration (meaning most everyone else here) step up with +1 votes that includes their commitment to review and maintain one of these modules, seek the software license grant, and to file the ip-clearance with general@incubator, I'm willing to relax my veto on creating that subproject. But not into a core module until the subproject is successful. Attached Message.eml
Re: Technical reasons for -1 votes (?)
On Feb 29, 2012, at 9:42 AM, William A. Rowe Jr. wrote: On 2/29/2012 8:59 AM, André Malo wrote: On Wednesday 29 February 2012 04:11:35 William A. Rowe Jr. wrote: I withdraw this vote, reverting my position to -1, until collaboration and respect for options and insights of fellow committers as well as project decisions and votes can be consistently demonstrated. I always thought, you'd have to provide technical reasons for -1 votes (?). Let's take Roy's position on the attached vote discussion, it's relevant. These new modules are certainly additions/deletions to httpd. Yes, but they are modules. Hence, their mere existence in our tree is not a technical reason to exclude them. We have a modular architecture so that people who don't want a module don't have to build it. In fact, it was exactly this type of argument in 1995 that caused rst to focus on creating a modular architecture. If there were dependencies or license conditions brought in that somehow harmed the server without the module being active, then that would be a technical objection. Traditionally, we have allowed any module that has at least one willing volunteer committer to maintain it. And I agree with Jim, none of the subprojects have been as successful as just placing the code in the main tree. I have no idea why mod_fcgi is in a subproject. mod_ftp is there because it isn't an HTTP server. mod_aspdotnet had all sorts of licensing issues that I never quite figured out. I see no reason not to commit mod_firehose, though I haven't had a chance to look at the code myself. Nor am I willing to respect a veto war based on the impact of past vetos. Now, if you'll excuse me, I have at least two other walls to bang my head on today ... Roy
