Re: [VOTE] release httpd mod_fcgid-2.3.1?
Rainer Jung wrote: > > Some people seem to indicate, that the implementation of pgp is safer, > on the other hand md5sum etc. have a builtin check option (-c), so you > can run them directly against the checksum file to compares the checksum > in the checksum file with a freshly computed checksum of the base file. > This seems handy to me. It looks like gpg is not able to do that, i.e. > you have to compare the sums by staring at them. Of course with gpg you > can check using the signature file. That is frustrating. I wish we didn't illustrate it in our release.sh scripts :( But a SHA1 or MD5 or whatever result is a specific value, the "Safety" argument is complete drivel (and I didn't complete it, either). I regenerated all the mod_fcgid .md5/sha1 artifacts and then verified they had not changed. This was necessary anyways due to the -beta rename, and I'll be doing the same for mod_ftp if we get that far.
Re: [VOTE] release httpd mod_fcgid-2.3.1?
William A. Rowe, Jr. wrote: > [ ] +1 to release as 2.3.1-beta With +1's recorded from chrisd, trawick and wrowe, the package is released as-beta (due principally to the more experimental auth issues and terse documentation). I've staged the release, and in response to the details from Rainer, I regenerated the .md5/.sha1 tags in the process, using appropriate tools. The embedded filenames now reflect -beta tags. At 2pm EDT we can go ahead and sync the entire site, but I won't be at the office for an hour or so after that, so if anyone beats me to it, terrific :) I've synced the module doc area for mod_fcgid and the configuration is also updated to bridge all our links across into the httpd trunk docs. Feel free to test this out before the entire site is synced; http://httpd.apache.org/mod_fcgid/ you may be waiting for up to 45 minutes after this message for minotaur to sync to the live server.
Re: svn commit: r815527 - /httpd/mod_ftp/trunk/modules/ftp/ftp_commands.c
Guenter Knauf wrote: > sorry, didnt look closely enough, please forgive - fixed with r815577. No bother :) Not sure it's worth rerolling for, but the other item you pointed out might be more significant. Looking at it.
Re: svn commit: r815527 - /httpd/mod_ftp/trunk/modules/ftp/ftp_commands.c
Hi,
William A. Rowe, Jr. schrieb:
> Wouldn't this be
>
> if (!is_list && ((fsc->options & FTP_OPT_NLSTISLIST) || dashl)) {
>
> as there is no point otherwise? Actually we could drop the !is_list test,
> considering that forced-override isn't harmful.
sorry, didnt look closely enough, please forgive - fixed with r815577.
Gün.
Re: svn commit: r815527 - /httpd/mod_ftp/trunk/modules/ftp/ftp_commands.c
fua...@apache.org wrote:
> /* Special FTPOption that maps NLST directly to LIST */
> -if (!is_list && (fsc->options & FTP_OPT_NLSTISLIST) || dashl) {
> +if ((!is_list && (fsc->options & FTP_OPT_NLSTISLIST)) || dashl) {
> is_list = 1;
> }
Wouldn't this be
if (!is_list && ((fsc->options & FTP_OPT_NLSTISLIST) || dashl)) {
as there is no point otherwise? Actually we could drop the !is_list test,
considering that forced-override isn't harmful.
Re: [VOTE] release httpd mod_ftp-0.9.5 beta?
Bill, William A. Rowe, Jr. schrieb: >> William A. Rowe, Jr. wrote: >>> [X] +1 to release as 0.9.5-beta >> But with a single vote, I'll declare this vote DOA on Tuesday night, after >> seven days of voting. > > And in 18 hours, with no other voters, it seems appropriate to begin a vote > for dissolving mod_ftp from the httpd project. Please share your thoughts > on the topic. here's a first result for a build on Linux (OpenSuSE 10.3): ftp_commands.c: In function ‘common_list’: ftp_commands.c:694: warning: suggest parentheses around && within || .. ftp_protocol.c: In function ‘ftp_read_line’: ftp_protocol.c:244: warning: comparison is always false due to limited range of data type ftp_protocol.c:246: warning: comparison is always false due to limited range of data type ftp_protocol.c:246: warning: comparison is always true due to limited range of data type ftp_protocol.c:255: warning: comparison is always false due to limited range of data type ftp_protocol.c:258: warning: comparison is always false due to limited range of data type ftp_protocol.c:258: warning: comparison is always true due to limited range of data type we should fix these first, and re-roll ... Gün.
Re: [VOTE] release httpd mod_ftp-0.9.5 beta?
William A. Rowe, Jr. wrote: > > But I wouldn't like to see any new roadblocks to getting out the first > alpha/beta of 2.3.x, at long last. (and that goes for mod_fcgid as well, which should also go to trunk once we've got just one release from trunk, and I'm guessing that vote will fly with broad and unanimous support.)
Re: [VOTE] release httpd mod_ftp-0.9.5 beta?
Gregg L. Smith wrote: > > Problems I see in no particular order; > > 1. Two subproject votes called simultaneously totaling 3 concurrent open > votes (fcgid, ftp, ServerTokens OFF), and a one "let's get this ready to > vote" (httpd 2.3.3). That's a lot to chew on, especially with all the > other important concerns floating about at this time (mod_proxy, CVE's > against mod_proxy_ftp, bug smashing in current branch). I mentioned on another thread; the builds are very closely related, so it's pretty simple to check them out side by side or put them into the same server. mod_ftp's installation is much simpler (although configuration is much harder) just because we drop in a conf/extra/ftpd.conf. > 2. Lack of knowledge of existence at user base level! Not really a release issue at all. But something we might do more to promote. I'd think moving from beta to GA might help that? I'd been stubborn about GA mostly due to protocol issues (almost entirely now solved) and versioning, but have come to the conclusion that 0.9.X might be a perfectly good GA, while 1.0.0 might introduce some API version expectations and consistency for user/developers. > 3. Policy that may be simply too restrictive on something at this stage > of development. That's not it, see the other note. That simply isn't what the ASF is. Code with a developer community is welcome, code without a developer community is not (and user community is not relevant to the decision). > 4. FTP servers are a dime a dozen. Yup :) I find it funny the number of them you can yum install/apt get from any distro. Certainly mod_ftp has a unique place in that spectrum and doesn't really overlap any of the unix-user-account oriented flavors. > Then again, maybe I should shut up. There's no need; we are happy to explain why the policies exist. Feel free to ask "why?" > Gut feeling tells me that if binaries were available, and were announced > prominently in the user haunts, there would be quite a bit of noise on > this module pro and con. Some folks however will understandably not > touch anything labeled beta, worse yet, some people (like me) are lazy. > I currently have this module sitting on two hard drives compiled (vc6 & > vc9) but have not found an opportune time to learn how to configure and > use it as I have other priorities that unfortunately at this point and > time supersede it. I personally think it is a great idea regardless and > plan to make said time for it in the near future. The problem isn't binaries though, although we'll certainly make those available. But **we don't vote on binaries** :) We vote on source code, and people can do whatever with those sources. We happen to compile them, but so do others outside of the foundation. Our votes are not even as much about the quality, as the legitimacy of the release; that it is properly extracted, packaged, licensed, that if it breaks the users can truly keep both halves and do with it whatever they will. And that our statement that it is "the best version available" (not perfect version) is accurate. That isn't to say users aren't valued, or that binaries wouldn't be helpful. The first problem with fcgid was clearly docs. We are working on that and could use more folks' help. When they become as expansive as the docs at http://httpd.apache.org/mod_ftp/ I'll feel much better about the health of the module here at httpd :) You are right, while things live strictly at dev@ they don't tend to grow a following. Once we have a beta (and we now have the votes for beta) I'm starting to plug together that structure for the fcgid module as well, much like /mod_ftp/ pages. (In fact, tagging 2.3.0 without putting it to a vote and releasing it was a mistake, IMHO - we should have released early and often as the custodians of this code ;-) The problem with ftp is that two releases were scuttled for various reasons and the code has not been released in over a year. Kicking it back to the incubator is unlikely to help. FtpServer faced similar obstacles, the Apache MINA community ultimately adopted it. Although there are very few developers, the PMC is committed to reviewing and voting on releases. Apache httpd has the largest PMC of any project at the foundation. And yet in spite of the number of -users- and existence of good documentation, we booted mod_aspdotnet out of here, because we didn't have a PMC who had an interest in voting up or down any releases. I'd hate for this to happen to mod_ftp, and hope PMC folks are interested. But if not, that is the fate of abandonware; the ASF is not structured to ship code that has a community of one or two. And the ASF measures community by the developers, not by the users, because we are a foundation of coders. The one home for solo projects at the ASF, the Apache Labs, creates no releases whatsoever. That doesn't seem like a good solution either. I'm glad to hear there is interest by a handful of PMC folks to test the mod_ftp rel
Re: [VOTE] release httpd mod_ftp-0.9.5 beta?
Bill, Mario just told me that there's no mod_ftp Win32 binary yet: http://httpd.apache.org/dev/dist/mod_ftp/ maybe you can one upload? Gün.
Re: svn commit: r814091 - in /httpd/httpd/trunk: CHANGES support/htcacheclean.c
Jeff Trawick wrote:
> You misunderstood my comment (possibly because I didn't write it
> clearly). What I meant by
>
> "Why not simply zap all these checks of the form
>
> if (silly user specified no-argument option again) {
> remind them who is boss
> }
>
> to avoid code bloat?"
>
> is that I didn't think it was important to check for the user specifying
> the same option more than once.
I interpreted you as saying:
zap == remove completely
"silly user specified no-argument option again" != "silly user specified
option again"
which made no sense to me at all, thus I asked for clarification.
Instead of clarification I get "Ignoring the opinion that it isn't worth
writing this code code for a moment, isn't it a sign that something
needs further work when the same exact string occurs 9 times in the code?"
The goal of the patch was to fix the fact that every error case resulted
in the same output behaviour, it wasn't to make a call as to whether an
error message was necessary or not. All 9 error cases had the same
string because a sane compiler would have optimised this to just one string.
As it turned out, I didn't remove the 9 cases, even though they are
probably overkill, because I didn't want to get beaten up by somebody
asking me why I was making two changes in one patch. Oh well.
Regards,
Graham
--
smime.p7s
Description: S/MIME Cryptographic Signature
Re: [VOTE] release httpd mod_ftp-0.9.5 beta?
On Tue, Sep 15, 2009 at 4:57 PM, Guenter Knauf wrote: > Sander Temme schrieb: > > So, rather than threatening to get rid of the module, I move to fold it > > into trunk. > +1 > mod_ftp currently supports Apache 2.0 and 2.2 as well. I think the natural order is to first establish a stable, unbundled release that will support 2.0 and 2.2 as long as necessary, and think about folding it into httpd trunk once there has been a decent chance to resolve any common issues in the one tree. (same for mod_fcgid)
Re: [VOTE] release httpd mod_ftp-0.9.5 beta?
Sander Temme wrote: > > So, rather than threatening to get rid of the module, I move to fold it > into trunk. You read my mind; not that ftp needs to be in trunk (that would be cool), but that trunk has not been released in 4 years, which is a far more serious issue than mod_ftp's 15 months :) So at this point, I'm for releasing the separate mod_ftp, until trunk has a successful release, and then we can decide as a committee if mod_ftp should be in the 2.4.0/3.0.0 release. If so, it moves. If not, we wait until we get all the way to 2.4.0/3.0.0 before merging it in. But I wouldn't like to see any new roadblocks to getting out the first alpha/beta of 2.3.x, at long last. Does that make good sense?
Re: [VOTE] release httpd mod_ftp-0.9.5 beta?
On Tue, Sep 15, 2009 at 12:43 AM, William A. Rowe, Jr. wrote: > William A. Rowe, Jr. wrote: > > William A. Rowe, Jr. wrote: > >> [X] +1 to release as 0.9.5-beta > > > > But with a single vote, I'll declare this vote DOA on Tuesday night, > after > > seven days of voting. > > And in 18 hours, with no other voters, it seems appropriate to begin a vote > for dissolving mod_ftp from the httpd project. Please share your thoughts > on the topic. > My thoughts? mod_ftp seems generally useful, though perhaps not to me. I think it is a Good Thing for us to give it a home. I agree completely that it is a bad sign that we didn't get votes within a week, and it is fair to state the possible conclusion. Please give me another day to play with it ;)
Re: [VOTE] release httpd mod_ftp-0.9.5 beta?
Sander Temme schrieb: > So, rather than threatening to get rid of the module, I move to fold it > into trunk. +1 Gün.
Re: [VOTE] release httpd mod_ftp-0.9.5 beta?
Guenter Knauf wrote: > I'd suggest you just let the vote stay, and once mod_cgid is out maybe > some more get to mod_ftp ... I'm happy to do so, if Sander, yourself or others are interested in voting. I'm unwilling to have an open ended vote thread dangling forever, of course. A decision should be made, users should not be struggling with /dev/dist/ artifacts ;-) So if PMC are interested in testing, just give a shout of how long you want until you can review and vote. FWIW - they were released in parallel because they use the same build schema, and there is a high probability of an ftp issue reflecting the same issue in fcgid, and visa versa. There were more build changes to both than actual code changes this cycle :)
Re: [VOTE] release httpd mod_ftp-0.9.5 beta?
Headline: Policy kills and up-and-coming star Problems I see in no particular order; 1. Two subproject votes called simultaneously totaling 3 concurrent open votes (fcgid, ftp, ServerTokens OFF), and a one "let's get this ready to vote" (httpd 2.3.3). That's a lot to chew on, especially with all the other important concerns floating about at this time (mod_proxy, CVE's against mod_proxy_ftp, bug smashing in current branch). 2. Lack of knowledge of existence at user base level! 3. Policy that may be simply too restrictive on something at this stage of development. 4. FTP servers are a dime a dozen. Yes, I think calling this vote in the very next email written after the call to vote for mod_fcgid is a problem, especially when it is called along side a module that had been in use by a large number of users prior to ASF taking it over. mod_fcgid also had the benefit of a voting member whom backed it and was *very* active in getting it into the system and getting other members to look at it. Obviously this stole the show. The ultimate users of this module while may be PMC members is per capita going to be the people whom do not know they have a voice (albeit not binding) in the matter. Due to it's stealthy nature (only being discussed at the dev@ level AFAIK) there is probably a whole range of users that do not even know of it's existence. It also takes some guts to come on this list and make your opinion known. I am *not* saying that user input is ignore, I know full well it is not ignored as I can point to three things in the past month that prove as much. Policy is policy, I understand it and in most cases I think it is a very sound policy, however as Gunter points out, maybe things at a certain stage need to be able to go outside of policy, or have a place that whereby anything under a certain category has an exception to this stringent policy due to it's level of maturity (not the right word but the right one alludes me at the moment). Maybe this should be a topic of discussion and vote. Then again, maybe I should shut up. Gut feeling tells me that if binaries were available, and were announced prominently in the user haunts, there would be quite a bit of noise on this module pro and con. Some folks however will understandably not touch anything labeled beta, worse yet, some people (like me) are lazy. I currently have this module sitting on two hard drives compiled (vc6 & vc9) but have not found an opportune time to learn how to configure and use it as I have other priorities that unfortunately at this point and time supersede it. I personally think it is a great idea regardless and plan to make said time for it in the near future. Just my 2 cents Regards, Gregg William A. Rowe, Jr. wrote: Guenter Knauf wrote: Also, since its beta state we should probably also take test results of non-commiters into account, f.e. Mario and Jorge? We *always* (that is all of us, PMC members) consider everyone's votes and commentary on all releases. Although they are not binding, they are very important too :) But from a foundation process, policy and legal perspective, the 3 +1's rule serves an important purpose, and requires the votes of individuals who the ASF board has installed as PMC members (even though the PMC had chosen them in the first place).
Re: [VOTE] release httpd mod_ftp-0.9.5 beta?
On Sep 14, 2009, at 9:43 PM, William A. Rowe, Jr. wrote: William A. Rowe, Jr. wrote: William A. Rowe, Jr. wrote: [X] +1 to release as 0.9.5-beta But with a single vote, I'll declare this vote DOA on Tuesday night, after seven days of voting. And in 18 hours, with no other voters, it seems appropriate to begin a vote for dissolving mod_ftp from the httpd project. Please share your thoughts on the topic. I disagree. I have personally found no cycles to test this particular go-around: I am mind-bogglingly busy and about to get busier. However, I am convinced mod_ftp is viable. However, it looks as if it is not getting the attention it deserves as a subproject. Nick's remark about the testsuite is highly pertinent: I think the module would receive more exercise, attention and coverage if it were in trunk and touched by the perl-framework. So, rather than threatening to get rid of the module, I move to fold it into trunk. S. -- Sander Temme scte...@apache.org PGP FP: 51B4 8727 466A 0BC3 69F4 B7B8 B2BE BC40 1529 24AF smime.p7s Description: S/MIME cryptographic signature
Re: Logging command line at startup
On 9/15/09 3:18 PM, "Paul Querna" wrote: > I would prefer to just put it into the log file like Dan did.. not > everyone uses apachectl :) +1 -- Brian Akins
Re: Logging command line at startup
On Tue, Sep 15, 2009 at 11:58 AM, William A. Rowe, Jr. wrote: > Dan Poirier wrote: >> I'd like to log the server command line and server root at startup. >> >> The reason is: sometimes when debugging a problem I'm given some logs >> and a directory full of various revisions of the server configuration >> file, and can only guess which of the configuration files was actually >> being used. >> >> Logging the path to the configuration file would be complicated, since >> when it's opened, we don't know where the logs are going to go yet, and >> we don't save the configuration file path for later use. >> >> But with the command line and the server root, it won't be hard to tell >> which configuration file got used. >> >> I've put a first pass at implementing this at >> http://people.apache.org/~poirier/log_command_line_at_startup.patch.txt >> and welcome comments. > > I do something similar in my local startup script; alongside httpd.pid, > the httpd.last is written with the command invoked (as a shell activity). > > This allows a hard-restart with the precise args and flags the user passed > via the startup script command. > > If you like, Jim or I could propose that change to apachectl; it wouldn't > be in the error.log, but might solve half the battle? > I would prefer to just put it into the log file like Dan did.. not everyone uses apachectl :)
Re: Logging command line at startup
Dan Poirier wrote: > I'd like to log the server command line and server root at startup. > > The reason is: sometimes when debugging a problem I'm given some logs > and a directory full of various revisions of the server configuration > file, and can only guess which of the configuration files was actually > being used. > > Logging the path to the configuration file would be complicated, since > when it's opened, we don't know where the logs are going to go yet, and > we don't save the configuration file path for later use. > > But with the command line and the server root, it won't be hard to tell > which configuration file got used. > > I've put a first pass at implementing this at > http://people.apache.org/~poirier/log_command_line_at_startup.patch.txt > and welcome comments. I do something similar in my local startup script; alongside httpd.pid, the httpd.last is written with the command invoked (as a shell activity). This allows a hard-restart with the precise args and flags the user passed via the startup script command. If you like, Jim or I could propose that change to apachectl; it wouldn't be in the error.log, but might solve half the battle?
Logging command line at startup
I'd like to log the server command line and server root at startup. The reason is: sometimes when debugging a problem I'm given some logs and a directory full of various revisions of the server configuration file, and can only guess which of the configuration files was actually being used. Logging the path to the configuration file would be complicated, since when it's opened, we don't know where the logs are going to go yet, and we don't save the configuration file path for later use. But with the command line and the server root, it won't be hard to tell which configuration file got used. I've put a first pass at implementing this at http://people.apache.org/~poirier/log_command_line_at_startup.patch.txt and welcome comments. -- Dan Poirier
Re: svn commit: r814091 - in /httpd/httpd/trunk: CHANGES support/htcacheclean.c
On Tue, Sep 15, 2009 at 1:52 PM, Graham Leggett wrote:
> Jeff Trawick wrote:
>
> > Just zap the check since it is unnecessary.
>
> So first you suggest that all the checks be collapsed down to one check,
>
I don't recall doing that, though I did suggest that if we keep the checks
we don't need to duplicate the error message 9 times ;)
> and after being asked for an example of how the one check might work,
> you're now suggesting that the checks be removed entirely?
>
You misunderstood my comment (possibly because I didn't write it clearly).
What I meant by
"Why not simply zap all these checks of the form
if (silly user specified no-argument option again) {
remind them who is boss
}
to avoid code bloat?"
is that I didn't think it was important to check for the user specifying the
same option more than once.
> > Ignoring the opinion that it isn't worth writing this code code for a
> > moment,
>
> It isn't worth writing code that makes an end user's life easier?
>
Sure; I hope we can also agree independent of this particular example that
sometimes the amount of code can exceed the real value to the end user. (I
assume we still disagree about whether or not in this particular case the
code grew to exceed its real value ;) )
Or are you suggesting that all our end users should have gdb installed,
> a copy of httpd installed with full debug symbols, and the ability to
> read C code just to find a typo on a command line?
>
What do you consider the likelihood that I was suggesting that?
You made a code change with superfluous casting, bogus duplication of error
messages, and another issue which is a matter of taste but IMO valid fodder
for discussion. Somehow I was able to raise these issues without being a
smart ass.
Re: DO NOT REPLY [Bug 47184] Feature request: DirectoryHandler
bugzi...@apache.org wrote: https://issues.apache.org/bugzilla/show_bug.cgi?id=47184 --- Comment #12 from Will Rowe 2009-09-15 09:58:13 PDT --- It would be good not to add new grammar to the config (e.g. FrontController). Default has the issues raised on the dev@ list discussion thread. Fallback is good. But Fallback alone seems awfully general and hard for the administrator who comes across it to predict what it does when they first encounter it. Is it a Handler, Action or Mapping? I found Nick's choice amusing ;-) Since the syntax and behavior mirror the Action directive (without a first argument, of course) and we do not specify a handler name, it seems that FallbackAction is the most easy-to-comprehend choice. I'd accept that. But I was never 100% convinced by any of the second-word candidates. What's actually implemented is an internal URL, and the nearest (very close) analogy is DirectoryIndex. DrBacchus and I are both on IRC, where we discussed this a couple of hours ago. Why don't you join us? I'm sure if anyone else were so concerned about it as to have a problem with us chatting off-list, they'd have contributed to the subject by now. -- Nick Kew
Re: accept mutex failure causes fork bomb
On Tue, Sep 15, 2009 at 8:07 AM, Jeff Trawick wrote: > On Mon, Sep 14, 2009 at 4:27 PM, Greg Ames wrote: > >> I'm trying to debug a problem where apparently the accept mutex went bad >> on a z/OS system running the worker MPM. I'm guessing that some memory that >> we use for the semaphore got clobbered but don't have proof yet. The error >> log looks like: >> >> [Mon Sep 07 08:01:59 2009] [emerg] (121)EDC5121I Invalid argument.: >> apr_proc_mutex_unlock failed. Attempting to shutdown process gracefully. >> > > Could it be some system limit exceeded, like max waiters on a mutex? (IIRC > some OSs require tuning of SysV semaphores. (Older Solaris comes to mind.)) > it's possible. but the very first error was for unlock, so the lock must have worked. I would think most of the SysV tuning stuff is more critical for getting a lock than releasing it. > * Should we do clean_child_exit(APEXIT_CHILDSICK or CHILDFATAL) for this >> error? We have a previous fix to detect accept mutex failures during >> restarts and tone down the error messages. I don't recall seeing any false >> error messages after that fix. We could also use requests_this_child to >> detect if this process has ever successfully served a request, and only do >> the clean_child_exit if it hasn't. >> > > So nasty failures prior to successfully accepting a connection bypass > squatting? Good. > yep, that's the idea. any of the exit() calls should bypass setting ps->quiescing and disable squatting. > > CHILDSICK or CHILDFATAL in that case? In this example it probably wasn't > going to get any better. However, I think it is reasonably likely that > child process n+1 encounters some sort of resource limit, so CHILDSICK seems > better. > I agree. we have existing logic in the parent which will shut down the server if it can't find any healthy worker threads. > * Should we yank the squatting logic? I think it is doing us more harm > than good. IIRC it was put in to make the server respond faster when the > workload is spikey. A more robust solution may be to set Min and > MaxSpareThreads farther apart and allow ServerLimit to be enforced > unconditionally. disclaimer: I created ps->quiescing, so I was an > accomplice. > > My understanding is that squatting is required to deal with long-running > requests that keep a child trying to exit from actually exiting, thus tying > up a scoreboard process indefinitely. > you are right. thanks for the reminder. > > Is it reasonable to have up to MaxClients worth of squatting like we have > now? (I think that is what we allow.) No, I don't think so. > I think it's worse than that. it's more like (MaxClients - threads in fully active processes) / (avg. number of threads that p_i_s_m thinks are healthy per quiescing process). so if we have an average of one thread per quiescing process downloading a DVD over dialup, you are exactly right. if we have zero healthy threads in quiescing processes because the worker threads have exited but the process isn't completely gone, the denominator can get pretty small and there isn't any limit on squatting. > Should we axe squatting, respect ServerLimit, and thus make the admin raise > ServerLimit > or make the admin increase the difference between MinSpareThreads and MaxSpareThreads to reduce the oscillations between shutting down worker processes and forking more. > to accommodate exiting processes which are handling long-running requests > (and waste a bit of shared memory at the same time)? Maybe ;) That change > seems a bit drastic, but I'm probably just scared of another long period of > time before I halfway understand how it behaves in the real world. > yeah this is a sensitive and difficult to grok piece of code. I hope anything we do here simplifies it. I don't want to have to write the doc for how ServerLimit and squatting interact. Greg
Re: svn commit: r814091 - in /httpd/httpd/trunk: CHANGES support/htcacheclean.c
Jeff Trawick wrote: > Just zap the check since it is unnecessary. So first you suggest that all the checks be collapsed down to one check, and after being asked for an example of how the one check might work, you're now suggesting that the checks be removed entirely? > Ignoring the opinion that it isn't worth writing this code code for a > moment, It isn't worth writing code that makes an end user's life easier? Or are you suggesting that all our end users should have gdb installed, a copy of httpd installed with full debug symbols, and the ability to read C code just to find a typo on a command line? Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: svn commit: r795451 - /httpd/httpd/branches/2.2.x/STATUS
2009/9/15 Rich Bowen :
> FallbackHandler and FrontController both make a lot of sense to me.
> FrontController seems like it might be more "correct", in terms of accepted
> usage in the larger world out there, but either one makes me happy.
Looks like a name was found (or not). :-)
Besides the name I'd like to propose two features to that directive
- the possibility to override a previous setting back to default (e.g.
for subdirectories, Fallback disabled). I don't know if this is useful
but it was implemented into DirectoryIndex as well
- the possibility to disable the setting for subrequest lookups to
address Rüdiger's comment
http://www.mail-archive.com/dev@httpd.apache.org/msg44257.html
(Fallback fooressource nosub)
(- some debug logging+docs)
Bob
Index: modules/mappers/mod_dir.c
===
--- modules/mappers/mod_dir.c (revision 815380)
+++ modules/mappers/mod_dir.c (working copy)
@@ -41,6 +41,7 @@
apr_array_header_t *index_names;
slash_cfg do_slash;
const char *dflt;
+const char *nosub;
} dir_config_rec;
#define DIR_CMD_PERMS OR_INDEXES
@@ -73,6 +74,28 @@
return NULL;
}
+static const char *config_fallback(cmd_parms *cmd, void *dummy, const char *uri,
+char *nosub)
+{
+dir_config_rec *d = dummy;
+const char *t, *w;
+
+t = uri;
+if (!strcasecmp(t, "disabled")) {
+d->dflt = "\0";
+}
+else {
+d->dflt = t;
+}
+
+w = nosub;
+if (w != NULL) {
+d->nosub = "true";
+}
+
+return NULL;
+}
+
static const char *configure_slash(cmd_parms *cmd, void *d_, int arg)
{
dir_config_rec *d = d_;
@@ -83,9 +106,8 @@
static const command_rec dir_cmds[] =
{
-AP_INIT_TAKE1("Fallback", ap_set_string_slot,
- (void*)APR_OFFSETOF(dir_config_rec, dflt),
- DIR_CMD_PERMS, "Set a default handler"),
+AP_INIT_TAKE12("Fallback", config_fallback, NULL, DIR_CMD_PERMS,
+ "Set a fallback ressource"),
AP_INIT_RAW_ARGS("DirectoryIndex", add_index, NULL, DIR_CMD_PERMS,
"a list of file names"),
AP_INIT_FLAG("DirectorySlash", configure_slash, NULL, DIR_CMD_PERMS,
@@ -99,6 +121,8 @@
new->index_names = NULL;
new->do_slash = SLASH_UNSET;
+new->dflt = NULL;
+new->nosub = NULL;
return (void *) new;
}
@@ -112,6 +136,8 @@
new->do_slash =
(add->do_slash == SLASH_UNSET) ? base->do_slash : add->do_slash;
new->dflt = add->dflt ? add->dflt : base->dflt;
+/* override nosub if Fallback was present */
+new->nosub = add->dflt ? add->nosub : base->nosub;
return new;
}
@@ -125,12 +151,13 @@
return DECLINED;
}
name_ptr = d->dflt;
-if (name_ptr == NULL) {
+if (name_ptr == NULL || name_ptr[0] == '\0'
+|| (r->main != NULL && d->nosub != NULL)) {
return DECLINED;
}
/* XXX: if Fallback points to something that doesn't exist,
* this may recurse until it hits the limit for internal redirects
- * before returning an Internal Server Error.
+ * before returning an Internal Server Error if nosub was not set.
*/
/* The logic of this function is basically cloned and simplified
@@ -143,6 +170,9 @@
if (rr->status == HTTP_OK
&& ( (rr->handler && !strcmp(rr->handler, "proxy-server"))
|| rr->finfo.filetype == APR_REG)) {
+ap_log_rerror(APLOG_MARK, APLOG_DEBUG, 0, r,
+ "Fallback: Fallback to filename %s (%s) for %s",
+ rr->filename, rr->uri, r->filename);
ap_internal_fast_redirect(rr, r);
return OK;
}
@@ -154,11 +184,17 @@
rr->headers_out);
r->err_headers_out = apr_table_overlay(r->pool, r->err_headers_out,
rr->err_headers_out);
+ap_log_rerror(APLOG_MARK, APLOG_DEBUG, 0, r,
+ "Fallback: Fallback of URI-path %s resolved to "
+ "an external redirect to URI %s.", r->uri, rr->filename);
error_notfound = rr->status;
}
else if (rr->status && rr->status != HTTP_NOT_FOUND
&& rr->status != HTTP_OK) {
error_notfound = rr->status;
+ap_log_rerror(APLOG_MARK, APLOG_DEBUG, 0, r,
+ "Fallback: Ressource %s returned %s for "
+ "fallback of URI-path %s.", rr->filename, rr->status, r->uri);
}
ap_destroy_sub_req(rr);
Index: docs/manual/mod/mod_dir.xml
===
--- docs/manual/mod/mod_dir.xml (revision 815380)
+++ docs/manual/mod/mod_dir.xml (working copy)
@@ -166,8 +166,8 @@
Fallback
Define a default URL for requests that don't map to a file
-Fallback local-url
-None - httpd will return 404 (Not Found)
+Fallback local-url [nosub]
+disabled - httpd will retu
Re: [VOTE] release httpd mod_ftp-0.9.5 beta?
Guenter Knauf wrote: > Also, since its beta state we should probably also take test results of > non-commiters into account, f.e. Mario and Jorge? We *always* (that is all of us, PMC members) consider everyone's votes and commentary on all releases. Although they are not binding, they are very important too :) But from a foundation process, policy and legal perspective, the 3 +1's rule serves an important purpose, and requires the votes of individuals who the ASF board has installed as PMC members (even though the PMC had chosen them in the first place).
Re: [VOTE] release httpd mod_ftp-0.9.5 beta?
Nick Kew wrote: > > Bill, I'd be happy to support this in principle, but I have no use case to > motivate me. In other words, sorry I'm lazy. Nick, it's not targetted at you, or any other specific PMC member. It's more of a concern that we need three people in the project who -are- interested to keep the code alive ;-) > Is there a mod_ftp test suite? If so, I'll be happy to run it, and give > you a vote based on the outcome. There was some initial work done. I will research (it was prepared for integration into httpd's (so of course it would not run if the module is not installed). Bill
Re: DAV Option Patch
Brian J. France wrote: ... There is one draw back to this patch in that there could be duplicated values in the headers. Both mod_dav_acl and mod_caldav want to add the REPORT in the Allow header, so it would show up twice in the list. I am not sure if this is a major problem, but wanted to make a note of it. ... It shouldn't be a problem, but on the other hand: is there any particular reason for the new code not to enforce each value is only reported once? BR, Julian
Re: [VOTE] release httpd mod_ftp-0.9.5 beta?
Hi Mario, Mario Brandt schrieb: > On Tue, Sep 15, 2009 at 6:43 AM, William A. Rowe, Jr. > wrote: >> Please share your thoughts on the topic. > > I like that module.Since I have only one sever to configure / > maintain. I use 0.9.2 from Günther since 2007 on my windows dev > server. 0.9.5 compiles fine on VS9 and runs well. can you please in addition also give Bill's Win32 binary build a try after you have successfully tested the sources? thanks, Gün.
Re: [VOTE] release httpd mod_ftp-0.9.5 beta?
Hi Bill, William A. Rowe, Jr. schrieb: > And in 18 hours, with no other voters, it seems appropriate to begin a vote > for dissolving mod_ftp from the httpd project. Please share your thoughts > on the topic. please dont do that! Maybe that currently folks are otherwise busy (me too), but that shouldnt be a reason drop mod_ftp just now ... I'd suggest you just let the vote stay, and once mod_cgid is out maybe some more get to mod_ftp ... Also, since its beta state we should probably also take test results of non-commiters into account, f.e. Mario and Jorge? Gün.
Re: svn commit: r795451 - /httpd/httpd/branches/2.2.x/STATUS
On Sep 11, 2009, at 5:53 PM, William A. Rowe, Jr. wrote: Can we compromise on the name NotFoundHandler, MissingFileHandler, NotFoundAction, MissingFileAction, or any of a dozen other possible variations that don't contain the misleading word "Default"? FWIW, I preferred your earlier suggestion of Fallback[Handler| Action]. your input please? It would be nice to fix rather than revert, but I'll personally do either on Monday, because we can't tag a 2.3 alpha with an veto still open. Sorry for my lack of response. Travel, work. Usual excuses. Sorry. FallbackHandler and FrontController both make a lot of sense to me. FrontController seems like it might be more "correct", in terms of accepted usage in the larger world out there, but either one makes me happy. -- Rich Bowen rbo...@rcbowen.com
Re: svn commit: r795451 - /httpd/httpd/branches/2.2.x/STATUS
FWIW, I preferred your earlier suggestion of Fallback[Handler| Action]. If this mirrors the behavior of Action (in the way variables are presented to the fallback resource) then FallbackAction makes the most sense. If it is restricted to a filespec at the same dir level, then perhaps FallbackFilename makes the most sense. (If it can be at the same level or in another path, FallbackFile or FallbackResource might be better). Rich? Pipe up - you know we programmers are useless for naming things. You make short, sweet and to the point choices. E.g., ponies. FallbackHandler sounds good to me. I can't say I'm particularly concerned about the name, as long as the functionality does what we want, but FallbackHandler makes a lot of sense. Sorry for the delay. -- Rich Bowen rbo...@rcbowen.com
Re: accept mutex failure causes fork bomb
On Mon, Sep 14, 2009 at 4:27 PM, Greg Ames wrote: > * Should we yank the squatting logic? I think it is doing us more harm > than good. IIRC it was put in to make the server respond faster when the > workload is spikey. It finally occurred to me what you meant by spikey: triggering MaxSpareThreads (duh). The other conditions with squatting are graceful restart and MaxRequestsPerChild. > A more robust solution may be to set Min and MaxSpareThreads farther > apart and allow ServerLimit to be enforced unconditionally. and not use graceful restart or MaxRequestsPerChild and hope you don't get any child-fatal errors while long-running requests are being handled and/or set ServerLimit "enough higher" than MaxClients / ThreadsPerChild to allow ServerLimit to be enforced unconditionally even while some number of processes hang around while a few dangling requests complete --/-- slightly?-over-generalization: The real problem is that processes are so expensive on some platforms in terms of real memory or swap space or something else that real pain is inevitable when you have more than a few processes only handling a small number of requests. The use of an array for the scoreboard exacerbates this because it artificially limits the number of requests that can be handled in new (squatting) processes.
Re: svn commit: r814091 - in /httpd/httpd/trunk: CHANGES support/htcacheclean.c
On Tue, Sep 15, 2009 at 9:45 AM, Graham Leggett wrote:
> Jeff Trawick wrote:
>
> > Why does opt need to be cast to (int)?
>
> >From the printf man page:
>
> c The int argument is converted to an unsigned char, and the
> resulting character is written.
>
That's what happens inside printf(). On the caller side, my understanding
is that the compiler already promotes the argument to int because of the ...
.
Sanity check: Why aren't we explicitly promoting char parameters in other
calls to *printf?
> > Why not simply zap all these checks of the form
> >
> > if (silly user specified no-argument option again) {
> > remind them who is boss
> > }
> >
> > to avoid code bloat?
>
> Can you give an example?
>
Just zap the check since it is unnecessary.
Index: support/htcacheclean.c
===
--- support/htcacheclean.c (revision 815331)
+++ support/htcacheclean.c (working copy)
@@ -811,44 +811,26 @@
else {
switch (opt) {
case 'i':
-if (intelligent) {
-usage(apr_psprintf(pool, "The option '%c' cannot be
specified more than once", (int)opt));
-}
intelligent = 1;
break;
case 'D':
-if (dryrun) {
-usage(apr_psprintf(pool, "The option '%c' cannot be
specified more than once", (int)opt));
-}
dryrun = 1;
break;
case 'n':
-if (benice) {
-usage(apr_psprintf(pool, "The option '%c' cannot be
specified more than once", (int)opt));
-}
benice = 1;
break;
and so on.
--/--
Ignoring the opinion that it isn't worth writing this code code for a
moment, isn't it a sign that something needs further work when the same
exact string occurs 9 times in the code?
Re: Data are send in reverse order
Petr Hracek wrote: I have found mod_nntp_like where is mention in ap_pass_brigade(c->output_filters,bb); and in smtp_core is usage the same. Those are protocol modules. So anything-HTTP is not relevant to them. Unfortunatelly when I am using ap_pass_brigade(r->output_filter,bb); then it is not working. Web page is not show. Do you need to use anything more complex than the ap_r* family (ap_rputs, etc)? If so (and if what Graham already told you isn't enough) you might want my book - details at http://www.apachetutor.org/ -- Nick Kew
Re: Data are send in reverse order
On Tue, Sep 15, 2009 at 9:45 AM, Petr Hracek wrote: > I have found mod_nntp_like where is mention in > ap_pass_brigade(c->output_filters,bb); > and in smtp_core is usage the same. These are both modules that provide a non-HTTP protocol over the connection. If that doesn't match your module, you're better off using other code as a reference. -- Eric Covener cove...@gmail.com
Re: Data are send in reverse order
Petr Hracek wrote: > I have found mod_nntp_like where is mention in > ap_pass_brigade(c->output_filters,bb); > and in smtp_core is usage the same. Neither of these modules implement http, so don't use them as examples of how an http module should be implemented. > Unfortunatelly when I am using ap_pass_brigade(r->output_filter,bb); > then it is not working. Web page is not show. Can you post some code as an example? > Is it neccessary to configure Apache for using brigade and buckets? Yes. Take a look in the httpd code for modules that implement handlers, and use them as examples of how to write to the filter stack. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: Data are send in reverse order
I have found mod_nntp_like where is mention in ap_pass_brigade(c->output_filters,bb); and in smtp_core is usage the same. Unfortunatelly when I am using ap_pass_brigade(r->output_filter,bb); then it is not working. Web page is not show. Is it neccessary to configure Apache for using brigade and buckets? regards Petr 2009/9/15 Graham Leggett > Petr Hracek wrote: > > > I do not understand of this thing. > > Could you please tell me if I have already connection between browser > > and apache server why I should use request_rec->output_filters instead > > of request_rec->connection->output_filters? > > > > I thought that if connection is established than request_rec->connection > > should be used, right? > > Unfortunately not, no. > > The HTTP protocol allows many requests to occur over the same > connection, and httpd models this by having a connection filter stack, > in which is created a per-request filter stack, one for each request. > > The connection filter stack knows virtually nothing about HTTP, all the > filters that do know about HTTP - most specifically the filter that > writes headers - are part of the request filter stack. > > If you write to the connection filter stack, you are bypassing all the > HTTP filters, and what you wrote appears on the socket immediately. > Later on in your code, something else is writing to the request filter > stack, and this causes the headers filter to output the headers, after > the data you've just written. > > Regards, > Graham > -- >
Re: svn commit: r814091 - in /httpd/httpd/trunk: CHANGES support/htcacheclean.c
Jeff Trawick wrote:
> Why does opt need to be cast to (int)?
>From the printf man page:
c The int argument is converted to an unsigned char, and the
resulting character is written.
> Why not simply zap all these checks of the form
>
> if (silly user specified no-argument option again) {
> remind them who is boss
> }
>
> to avoid code bloat?
Can you give an example?
In theory, "silly user specified no-argument option again" is one big
case statement, which in theory means we would then have two big case
statements, one after the other, and that's way more bloated than a
single string constant used over and over again (but that produces
different messages), and a single apr_psprintf() call per option.
Regards,
Graham
--
smime.p7s
Description: S/MIME Cryptographic Signature
Re: svn commit: r814091 - in /httpd/httpd/trunk: CHANGES support/htcacheclean.c
On Fri, Sep 11, 2009 at 7:57 PM, wrote:
> Author: minfrin
> Date: Fri Sep 11 23:57:48 2009
> New Revision: 814091
>
> URL: http://svn.apache.org/viewvc?rev=814091&view=rev
> Log:
> htcacheclean: 19 ways to fail, 1 error message. Fixed.
>
> Modified:
>httpd/httpd/trunk/CHANGES
>httpd/httpd/trunk/support/htcacheclean.c
>
>
> Modified: httpd/httpd/trunk/support/htcacheclean.c
> URL:
> http://svn.apache.org/viewvc/httpd/httpd/trunk/support/htcacheclean.c?rev=814091&r1=814090&r2=814091&view=diff
>
> ==
> --- httpd/httpd/trunk/support/htcacheclean.c (original)
> +++ httpd/httpd/trunk/support/htcacheclean.c Fri Sep 11 23:57:48 2009
> @@ -802,48 +806,48 @@
> break;
> }
> else if (status != APR_SUCCESS) {
> -usage();
> +usage(NULL);
> }
> else {
> switch (opt) {
> case 'i':
> if (intelligent) {
> -usage();
> +usage(apr_psprintf(pool, "The option '%c' cannot be
> specified more than once", (int)opt));
>
Why does opt need to be cast to (int)?
Why not simply zap all these checks of the form
if (silly user specified no-argument option again) {
remind them who is boss
}
to avoid code bloat?
Re: accept mutex failure causes fork bomb
On Mon, Sep 14, 2009 at 4:27 PM, Greg Ames wrote: > I'm trying to debug a problem where apparently the accept mutex went bad on > a z/OS system running the worker MPM. I'm guessing that some memory that we > use for the semaphore got clobbered but don't have proof yet. The error log > looks like: > > [Mon Sep 07 08:01:59 2009] [emerg] (121)EDC5121I Invalid argument.: > apr_proc_mutex_unlock failed. Attempting to shutdown process gracefully. > Could it be some system limit exceeded, like max waiters on a mutex? (IIRC some OSs require tuning of SysV semaphores. (Older Solaris comes to mind.)) > [Mon Sep 07 08:02:01 2009] [emerg] (121)EDC5121I Invalid argument.: > apr_proc_mutex_lock failed. Attempting to shutdown process gracefully. > [Mon Sep 07 08:02:02 2009] [emerg] (121)EDC5121I Invalid argument.: > apr_proc_mutex_lock failed. Attempting to shutdown process gracefully. > [Mon Sep 07 08:02:02 2009] [emerg] (121)EDC5121I Invalid argument.: > apr_proc_mutex_lock failed. Attempting to shutdown process gracefully. > [...] > > The rest of the error log is filled with lock failures. Looking at the > time stamps, you can see that perform_idle_server_maintenance went into > exponential expansion, maxing out at about 24 lock failures per second. > Unfortunately the fork()s were faster than z/OS could terminate the > processes that had detected the mutex problem, so after forking 978 httpd > children, the system ran out of real memory and had to be IPLed. > > One of my colleagues asked why ServerLimit 64 didn't stop the fork bomb. > Good question. The reason is that the error path calls signal_threads() > which causes the child to exit gracefully. The listener thread sets > ps->quiescing on the way out, which allows the "squatting" logic in > perform_idle_server_maintenance to take over the scoreboard slot before the > previous process has completely exited, bypassing the ServerLimit throttle. > > This raises several ideas for improvement: > > * Should we do clean_child_exit(APEXIT_CHILDSICK or CHILDFATAL) for this > error? We have a previous fix to detect accept mutex failures during > restarts and tone down the error messages. I don't recall seeing any false > error messages after that fix. We could also use requests_this_child to > detect if this process has ever successfully served a request, and only do > the clean_child_exit if it hasn't. > So nasty failures prior to successfully accepting a connection bypass squatting? Good. CHILDSICK or CHILDFATAL in that case? In this example it probably wasn't going to get any better. However, I think it is reasonably likely that child process n+1 encounters some sort of resource limit, so CHILDSICK seems better. > > * Should we yank the squatting logic? I think it is doing us more harm > than good. IIRC it was put in to make the server respond faster when the > workload is spikey. A more robust solution may be to set Min and > MaxSpareThreads farther apart and allow ServerLimit to be enforced > unconditionally. disclaimer: I created ps->quiescing, so I was an > accomplice. > My understanding is that squatting is required to deal with long-running requests that keep a child trying to exit from actually exiting, thus tying up a scoreboard process indefinitely. (We've had the assumption that we didn't want to drastically overallocate scoreboard to accommodate a bunch of children with only a few threads handling requests.) Is it reasonable to have up to MaxClients worth of squatting like we have now? (I think that is what we allow.) No, I don't think so. Should we axe squatting, respect ServerLimit, and thus make the admin raise ServerLimit to accommodate exiting processes which are handling long-running requests (and waste a bit of shared memory at the same time)? Maybe ;) That change seems a bit drastic, but I'm probably just scared of another long period of time before I halfway understand how it behaves in the real world. > * Does it make sense to fork more than MaxSpareThreads worth of child > processes at a time? MaxSpareThreads was 75 in this case, but we tried to > fork at least 600 threads (same as MaxClients) worth of child processes in > one pass of perform_idle_server_maintenance. > That's a good idea. > > This applies to worker and event; some of it may also apply to prefork. > I'd appreciate thoughts and suggestions before committing anything. > > Thanks, > Greg > -- Born in Roswell... married an alien...
Re: Data are send in reverse order
Petr Hracek wrote: > I do not understand of this thing. > Could you please tell me if I have already connection between browser > and apache server why I should use request_rec->output_filters instead > of request_rec->connection->output_filters? > > I thought that if connection is established than request_rec->connection > should be used, right? Unfortunately not, no. The HTTP protocol allows many requests to occur over the same connection, and httpd models this by having a connection filter stack, in which is created a per-request filter stack, one for each request. The connection filter stack knows virtually nothing about HTTP, all the filters that do know about HTTP - most specifically the filter that writes headers - are part of the request filter stack. If you write to the connection filter stack, you are bypassing all the HTTP filters, and what you wrote appears on the socket immediately. Later on in your code, something else is writing to the request filter stack, and this causes the headers filter to output the headers, after the data you've just written. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: Data are send in reverse order
I do not understand of this thing.
Could you please tell me if I have already connection between browser and
apache server why I should use request_rec->output_filters instead of
request_rec->connection->output_filters?
I thought that if connection is established than request_rec->connection
should be used, right?
regards
Petr
2009/9/15 Graham Leggett
> Petr Hracek wrote:
>
> > in my apache module (written in C) are sended data to the client side
> > over buckets and brigades.
> > Function for send these date is:
> > apr_status_t send_data_to_client(request_rec *r, char * data_to_send,
> > int length_data)
> > {
> > apr_bucket_brigade * bb =
> > apr_brigade_create(r->pool,r->connection->bucket_alloc);
> > apr_bucket * b =
> >
> apr_bucket_immortal_create(data_to_send,length_data,r->connection->bucket_alloc);
> > APR_BRIGADE_INSERT_TAIL(bb,b);
> > ap_pass_brigade(r->connection->output_filters,bb);
> ^
> > return OK;
> > }
> >
> > It is working but in the traces of application which receive the data
> > from apache module the HTTP data are in reverse order.
>
> At a quick glance, I would blame the line highlighted above - you are
> trying to write your data directly to the connection filters, rather
> than to the request filters. By doing that, your data is sent before the
> request, not after, and so you see your data before the headers, not after.
>
> Regards,
> Graham
> --
>
Re: DAV Option Patch
Brian J. France wrote: > Jari is the original author of mod_dav_acl, which requires patches to > httpd to work. I need the same functionality added to httpd to get a > mod_dav_acl type module working, so I have split up his patch into > smaller pieces. Can a patch be under a different license than the > original code? Yes it can, but only the author of the original code can do that, as only the original author (the copyright holder) can set the terms by which his patch can be used. The way forward is to ask Jari to submit his httpd-2.2.8-ju.patch to us, granting us permission to use the Apache software license on it. At that point you are free to chop up the patch and submit it to us. Long answer: A person who creates some code owns the copyright on that code, and can set any terms they like on it's use. The copyright holder can also change their mind as to the terms at some future date, and they can also give one group of people the code under terms A (like bundled with mod_dav_acl under the LGPL) and simultaneously give another group of people the same code under terms B (like giving httpd-2.2.8-ju.patch to the ASF under the ASL). The reason all this matters is the terms of the LGPL - any derivative work of LGPL code (ie your patches, derived from Jari's patches), has to also be licensed under the LGPL. And LGPL code cannot be imported into other code that isn't itself LGPL. Because httpd isn't LGPL, the LGPL license doesn't allow it, so we (the httpd project) are legally obliged in terms of the LGPL not to accept it. The solution is for Jari to release httpd-2.2.8-ju.patch to us under the ASL, and that clears the way legally for all the code to be officially incorporated into the httpd codebase, removing the need for the special patch on your side, and that can be done by Jari submitting the httpd-2.2.8-ju.patch on this mailing list, and confirming his permission to release it under the ASL. Jari is still free to include the httpd-2.2.8-ju.patch within mod_dav_acl under the LGPL, because he is free to license his code in as many ways as he likes. The existing mod_dav_acl is not affected in any way. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: Data are send in reverse order
Petr Hracek wrote:
> in my apache module (written in C) are sended data to the client side
> over buckets and brigades.
> Function for send these date is:
> apr_status_t send_data_to_client(request_rec *r, char * data_to_send,
> int length_data)
> {
> apr_bucket_brigade * bb =
> apr_brigade_create(r->pool,r->connection->bucket_alloc);
> apr_bucket * b =
> apr_bucket_immortal_create(data_to_send,length_data,r->connection->bucket_alloc);
> APR_BRIGADE_INSERT_TAIL(bb,b);
> ap_pass_brigade(r->connection->output_filters,bb);
^
> return OK;
> }
>
> It is working but in the traces of application which receive the data
> from apache module the HTTP data are in reverse order.
At a quick glance, I would blame the line highlighted above - you are
trying to write your data directly to the connection filters, rather
than to the request filters. By doing that, your data is sent before the
request, not after, and so you see your data before the headers, not after.
Regards,
Graham
--
smime.p7s
Description: S/MIME Cryptographic Signature
crash caused by SSL_free in ssl_filter_io_shutdown
I see a crash caused by SSL_free in ssl_filter_io_shutdown: #0 0x002a96b42879 in kill () from /lib64/tls/libc.so.6 #1 #2 0x002a959dcc97 in ASN1_template_free () from /lib64/libcrypto.so.4 #3 0x002a959dcc11 in ASN1_primitive_free () from /lib64/libcrypto.so.4 #4 0x002a959dccf7 in ASN1_template_free () from /lib64/libcrypto.so.4 #5 0x002a959dcc11 in ASN1_primitive_free () from /lib64/libcrypto.so.4 #6 0x002a959dcd32 in ASN1_item_free () from /lib64/libcrypto.so.4 #7 0x002a95816592 in ssl_cert_free () from /lib64/libssl.so.4 #8 0x002a9581550a in SSL_free () from /lib64/libssl.so.4 #9 0x002a97fb74d2 in ssl_filter_io_shutdown (filter_ctx=0x552adcb890, c=0x552adcb040, abortive=0) at /usr/src/debug/WAO-apache-2.2.13/httpd-2.2.13/modules/ssl/ssl_engine_io.c:987 #10 0x002a97fb849b in ssl_io_filter_output (f=0x552adcb8c0, bb=0x552add4518) at /usr/src/debug/WAO-apache-2.2.13/httpd-2.2.13/modules/ssl/ssl_engine_io.c:1449 #11 0x00552aaeefaf in ap_lingering_close (c=0x552adcb040) at /usr/src/debug/WAO-apache-2.2.13/httpd-2.2.13/server/connection.c:84 #12 0x00552aafb51e in worker_thread (thd=0x552ad1c230, dummy=Variable "dummy" is not available. ) at /usr/src/debug/WAO-apache-2.2.13/httpd-2.2.13/server/mpm/worker/worker.c:545 #13 0x002a96901137 in start_thread () from /lib64/tls/libpthread.so.0 #14 0x002a96bdd883 in clone () from /lib64/tls/libc.so.6 (gdb) bt full #0 0x002a96b42879 in kill () from /lib64/tls/libc.so.6 No symbol table info available. #1 No symbol table info available. #2 0x002a959dcc97 in ASN1_template_free () from /lib64/libcrypto.so.4 No symbol table info available. #3 0x002a959dcc11 in ASN1_primitive_free () from /lib64/libcrypto.so.4 No symbol table info available. #4 0x002a959dccf7 in ASN1_template_free () from /lib64/libcrypto.so.4 No symbol table info available. #5 0x002a959dcc11 in ASN1_primitive_free () from /lib64/libcrypto.so.4 No symbol table info available. #6 0x002a959dcd32 in ASN1_item_free () from /lib64/libcrypto.so.4 No symbol table info available. #7 0x002a95816592 in ssl_cert_free () from /lib64/libssl.so.4 No symbol table info available. #8 0x002a9581550a in SSL_free () from /lib64/libssl.so.4 No symbol table info available. #9 0x002a97fb74d2 in ssl_filter_io_shutdown (filter_ctx=0x552adcb890, c=0x552adcb040, abortive=0) at /usr/src/debug/WAO-apache-2.2.13/httpd-2.2.13/modules/ssl/ssl_engine_io.c:987 ssl = (SSL *) 0x552adceda0 type = 0x2a97fc84ac "unclean" sslconn = (SSLConnRec *) 0x552adcb778 shutdown_type = Variable "shutdown_type" is not available. Not sure if httpd is the culprit or openssl (openssl 0.9.7a RHEL4). Has somebody seen this before? Regards Rüdiger
Re: [VOTE] release httpd mod_ftp-0.9.5 beta?
On 15 Sep 2009, at 05:43, William A. Rowe, Jr. wrote: William A. Rowe, Jr. wrote: William A. Rowe, Jr. wrote: [X] +1 to release as 0.9.5-beta But with a single vote, I'll declare this vote DOA on Tuesday night, after seven days of voting. And in 18 hours, with no other voters, it seems appropriate to begin a vote for dissolving mod_ftp from the httpd project. Please share your thoughts on the topic. Bill, I'd be happy to support this in principle, but I have no use case to motivate me. In other words, sorry I'm lazy. Is there a mod_ftp test suite? If so, I'll be happy to run it, and give you a vote based on the outcome. -- Nick Kew
Re: DAV Option Patch
Brian J. France wrote: > While Jari's mod_dav_acl is licensed under LGPL, can the patches to > httpd be licensed that way? > > What would we need to do to get them added if Jari's patches (or even > mod_dav_acl) would fall under LGPL? All Jari would need to do is email the list to confirm that he is happy that these patches can be licensed under the ASF license and included within httpd, and that's it. Jari's confirmation would not affect mod_dav_acl in any way, he can license mod_dav_acl any way he feels comfortable with. It's only the patches that are imported into httpd - ie these patches you are submitting - that are affected. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: [VOTE] release httpd mod_ftp-0.9.5 beta?
On Tue, Sep 15, 2009 at 6:43 AM, William A. Rowe, Jr. wrote: >Please share your thoughts on the topic. I like that module.Since I have only one sever to configure / maintain. I use 0.9.2 from Günther since 2007 on my windows dev server. 0.9.5 compiles fine on VS9 and runs well. Mario
