Re: ping on mod_dns
On Tue, Feb 19, 2008 at 09:30:30AM -0500, Jim Jagielski wrote: > I propose mod_domain to match the IANA port number > assignment. +1, especially since that way we don't have to listen to Paul Vixie ;) -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: tcp_get_info()....
On Thu, Feb 07, 2008 at 12:39:14PM +0100, Dirk-Willem van Gulik wrote: > Have a look at the ntp protocol - it is fairly effective at this - > and I would not rule out that you'd be able to do something similar > (abeit less accurate) on a keep-alive connection. NTP does it via phase-lock loop, and it's pretty clever alright, a PLL could be applied to the back and forth traffic for HTTP alright, as long as the implementor took great care to work around things like accept filters (so throw away the first session). It'd be interesting, mod_youre_on_sattellite_broadband ;-) -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: tcp_get_info()....
On Thu, Feb 07, 2008 at 03:38:38PM +0700, Niko Wilfritz Sianipar Sianipar wrote: > Can I use tcp_get_info() function from Linux C library in my Apache code to > get information about the TCP connection? Yep, you can, though obviously it will be completely unportable. > I need it to estimate the transfer time of last packet sent in my Apache > code? Is Apache can do that?? That's effectively unknowable information without something at both ends though. tcp_get_info will give you an incling, but not much of a useful one IMO. For this kind of stuff it's more typical to use tools like netstat, tcpdump, lft (layer four traceroute) and so on - instrumenting Apache directly seems unusual, but it would work :-) -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: store_headers in memcache and diskcache
On Tue, Feb 05, 2008 at 01:49:43PM -0500, Garrett Rooney wrote: > On Feb 5, 2008 1:45 PM, Dirk-Willem van Gulik <[EMAIL PROTECTED]> wrote: > > Caching experts -- why do memcache and diskcache have seemingly quite > > different caching strategies when it comes to storing the headers ? > > E.g. the cache_object_t * is populated with the status/date/etc data > > in memcache - but not in disk-cache. Is this work in progress or > > subtle design ? > > > > I am trying to understand (got a working mod_memcached_cache.c* -- > > and cannot quite get the right VARY behaviour). > > If I had to guess I'd say it's because people have actually been > working on disk cache, while mem cache has been largely ignored for a > while. Definitely! I remember the original patches tried to create some nice abstractions so that more logic would move into mod_cache propery than in mod_*_cache, but there turned out to be so many corner cases within mod_disk_cache itself - and noone seems to /use/ mod_mem_cache - that that fell by the wayside :/ -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: My hacked mod_xsendfile
On Sun, Jan 27, 2008 at 10:46:12AM +0100, Niklas Edmundsson wrote: > Using subrequests means that mod_cache won't bite, right? At least > that's the reason for mod_ftp-requests not being handled by the cache > from what I've understood. This seems like a good thing to me; the file must be local anyway, or we wouldn't be able to use sendfile to begin with, so it's not going to benefit from caching (even mod_mem_cache really, since all of the OS's with sendfile cache the file in ram anyway). And since the point of X-Sendfile is to allow for /dynamic/ choice of file to send, caching would be inappropriate. I guess the marginal case might be when mod_cache would do a better of job of negotiating the Vary: semantics than any backend cgi/whatever might. -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: High security
On Thu, Jan 24, 2008 at 01:10:23PM +0100, Nick Gearls wrote: > You specify one directive, and the only thing you have to put in the > jail is your htdocs and logs directories; all other files (conf, > modules, httpd, libraries, etc.) are outside of the jail. This is really > top security - it's almost impossible to find something to hack. Well don't kid yourself, it makes privilege escalation by certain routes much harder, but it's not even clost to almost impossible. There are many forms of IPC available between the children and the root-level Apache process anyway, and if you manage to exploit that it's game over anyway (including breaking out of the jail). > Unfortunately, the only thing that does not work is a graceful restart, > as the process has no more access to all normal files. > Couldn't it be possible to separate the main process in 2 - one real > master performing the start/stop/restart, and one "almost main" chrooted > process which would spawn the listening children processes ? > The chrooted process could be implemented in the core, or it could be > left to ModSecurity. It'd be a new MPM. > That would be the top security, much more secure than any solution based > on IIS for instance. > Do you think this could be envisioned ? Can't see it happening personally. -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: Is async the answer
On Fri, Jan 18, 2008 at 04:17:16PM -0500, Akins, Brian wrote: > For dynamic stuff, "X-sendfile" works well. (Just really starting to play > with that, liking it so far). It's not a solve-all though, I mean even though CGI's or whatever /could/ write their output to a file and then call X-sendfile, it'd be a disaster latency-wise. Ironically enough the only way to solve that is ... async ;-) > The proxy that the LiveJournal folks wrote, I think, copies all the data > from the origin server into a file and then uses sendfile to send to the > client... Erm, so does the one we wrote, mod_disk_cache ;p -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: Is async the answer
On Fri, Jan 18, 2008 at 02:31:11PM -0500, Akins, Brian wrote: > On 1/18/08 2:20 PM, "Colm MacCarthaigh" <[EMAIL PROTECTED]> wrote: > > > I think so, in some environments anyway. If you have a server tuned for > > high throughput accross large bandwidth-delay product links then you > > have the general problem of equal-priority threads sitting around with > > quite a lot of large impending writes. > > Doesn't sendfile (and others) help in that case? Also RAM is cheap, > bandwidth isn't :) Oh if you can use sendfile, you use it sure, and whether its used async or not isn't going to make a big deal, all of the benefits are the zero copy, the DMA, the TOE, and so on. That's not even a consideration, async is really for dynamic content, proxies, and other non-sendfile content. -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: Is async the answer
On Fri, Jan 18, 2008 at 01:52:02PM -0500, Akins, Brian wrote: > On 1/18/08 12:18 PM, "Colm MacCarthaigh" <[EMAIL PROTECTED]> wrote: > > Hmmm, it depends what you mean by scale really. Async doesn't help a > > daemon scale in terms of concurrency or throughput, if anything it might > > even impede it, but it certainly can help improve latency and > > responsivity greatly. On the whole, it's easy to see how it might make > > the end user experience of a very busy server much more pleasant. > > I also wonder is that has actually been tested or if it's just a "factoid"? I've tested, and it met my expectations on Linux 2.6 on Itanium, but I can't guarantee that the experiments were free from my own bias I guess. > >> Response time never increased in any measurable amount. > > > > I suspect it might though if the scheduler became bound, async would > > route the interupts more efficiently. > > But, I wonder if the scheduler would become bound in a "reasonable" amount > of traffic. I think so, in some environments anyway. If you have a server tuned for high throughput accross large bandwidth-delay product links then you have the general problem of equal-priority threads sitting around with quite a lot of large impending writes. Having them all in the polling loop is inefficient, and async is going to reduce the latency a little, though granted these days we may be talking about nanoseconds. And I guess responsivity and high BDP don't go together anyway, due to the speed of light. > > The scalability wars should really be over, > > everyone won - kernel's rule :-) > > Which is why I hate to see a ton of work go into async core if it actually > does very little to help performance (or if it hurts it) and makes writing > modules harder. It braindead simple nowadays to write well behaved high > performance modules (well, mostly) bcs you rarely worry about threads, > reads/writes, etc. Full async programming is just as challenging as > handling a ton of threads yourself. I think if it interests people and they want to work on it, cool stuff, but don't neccessarily expect any actual pay-off in terms of performance. One of the great things about an open source project is that sometimes what gets worked on isn't driven by considerations other than what people feel like working on. I'd be less worried about the effect on modules, many module authors already can't be bothered to make their modules thread-safe, but prefork still exists (and scales quite well, on many platforms). -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: Is async the answer?
On Fri, Jan 18, 2008 at 12:03:02PM -0500, Akins, Brian wrote: > Most of us seem to have convinced our self that high performance network > applications (including web servers) must be asynchronous in order to scale. > Is this still valid? For that matter, was it ever? Hmmm, it depends what you mean by scale really. Async doesn't help a daemon scale in terms of concurrency or throughput, if anything it might even impede it, but it certainly can help improve latency and responsivity greatly. On the whole, it's easy to see how it might make the end user experience of a very busy server much more pleasant. > It seems that modern OS's (this was Linux 2.6.something) deal with the > "thread overhead" and all the context switches very well. All the stuff > mentioned in the "the c10k problem" ( http://www.kegel.com/c10k.html) didn't > seem to apply. We could have easily doubled the amount of connections to > the server, I think. The c10k page has been hopelessly out of date for a long long time, I wrote to Dan Kegel some time about (maybe 3 or 4 years) pointing this out, but there's been no update :/ > Response time never increased in any measurable amount. I suspect it might though if the scheduler became bound, async would route the interupts more efficiently. > Yes, we are using sendfile, mmap, etc., so zero-copy helps us a lot. > > So, do we need apache 3 (or whatever it's called) to be fully asynchronous? > Is that just us reacting to "the market" trends, ie, lighttpd? Who knows, no harm in doing it anyway, if it's what interests people, cool. Personally I find comparisons between webservers and most discussions on scalability baffling, the reality is that modern hardware can outscale pretty much any amount of bandwidth you can buy regardless of the software. And to that end, the software is all near identical in the pipelines of syscall's used (hell even IIS) - which is what really matters. Most discussions seem to centre on some mindlessly ignorant comparison based on the suitable of defaults to a particular set of circumstances coupled with religion. The scalability wars should really be over, everyone won - kernel's rule :-) > All the apache httpd "is bloated and slow" is just plain horse crap. It's > not that hard to configure apache to be "fast." C programming is my > "hobby," and it's not that hard to write modules that don't do stupid things > and kill the performance. Yep! -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: Integrity of Apache source code
On Mon, Dec 17, 2007 at 11:22:37PM +, Andrew Beverley wrote: > I am currently working within the UK Ministry of Defence, and am trying to get > Apache web server accredited as software able to be installed on one of our > defence networks. However, one of the barriers I am coming up against is the > argument that, because it is open source, that someone could contribute a > Trojan > horse to the code and that the code could be included in the official product. This is true - they could, but the same is true of any software development methodology. > What I would like to know, so that I can dispel this, is what procedures are > in > place to prevent this happening? Imo it boils down to; 0. Committers are only granted commit status after a period of peer review and demonstrated period of competency and trustworthiness. Noone is given commit access merely because they were employed yesterday. 1. All committed code changes are mailed to a public list which many people actively monitor and read. 2. A smaller number, but still enough, committers - likely including the eventual release manager - regularly update their local copy of the source tree and each have reasonable potential to notice a change which was not mailed to the list (e.g. an attacker may manage to commit to the source tree, and disable the mails about commits - but this would probably still be noticed). > I know that all downloads are digitally signed, > but what other procedures are in place? For example, how is code signed-off > for > inclusion in production releases? In the case of modifications to released versions of Apache; at least 3 committers must review the changes and agree to their inclusion, unreviewed commits to these versions of Apache are virtually guaranteed to be noticed. At the time of release - once the release manager nominates a release candidate it is subjected to even wider review and testing by the Apache community and must be reviewed by at least 3 members of the Project Management Committee. In the case of pre-release or versions of Apache still in development; the code is subject to general peer review and there is typically a period of months to years between time of commit and time of release during which problems may be noticed. -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: fixing graceful-stop with event mpm
On Mon, Aug 20, 2007 at 04:00:48PM -0700, Paul Querna wrote: > Short: We need to call ap_close_listeners() earlier or more aggressively. > > Question: Where/How? > > Looking at the Event MPM in both trunk and 2.2.x, the listener_thread is > where we call ap_close_listeners(). This does not seem to be working > quickly enough, per PR 43081: > http://issues.apache.org/bugzilla/show_bug.cgi?id=43081 Crap :( When I test it on my linux box, it works for me, it's pretty fast, I'm guessing I have the wrong sort of load to see this, any idea how to replicate? > I haven't quite got my head around how the listener thread is apparently > blocking for so long, but I can't figure out another way that the > listeners would stay online for so long either. The listener thread isn't neccessarily the only thread with a copy of the fd, I remember cgid catching me out before (which I fixed iirc). > Solution: Add call to ap_close_listeners() in wakeup_listener(). I > think this would pop out all of the listening sockets quickly from the > listener pollset. How would you signal it? > Solution: Actually start working on 3.0 with a sane event/start/shutdown > model? That'd be nice alright :-) -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: patched sources v.s. release candidates
On Sun, Aug 19, 2007 at 03:05:14PM -0500, William A. Rowe, Jr. wrote: > You specifically mentioned how many distros have patched sources, and > that's true (and not an issue). What I asked was, are there distros which > ship our release candidates before they are released, and if so, are they > labeled as such? I've had ports trees that carried odd-numbered trains, (2.1, 2.3), and even yesterdays-svn (from nightly builds)! > > Our candidates are 100% redistributable and licensed in accordance with > > AL2.0, just like our svn trees. > > So you can make anything out of any combination of our svn trees, with > whatever patches you like, as long as you give them your own name. Right? > They are not, for example, a "release 2.2.5" until the project approves them. Yes, and to repeat again; as long as it is made clear that it is not an ASF release :-) > E.g. I might have a binary "BetterScript, based on PHP sources 5.2.4 RC2", > but I better not ship that as *the* "PHP 5.2.4". Do we agree on this, > or not? Or are we in the mode of playing devil's advocate to spend list > bandwidth? (Sometimes I don't know with you, Colm :-) I'm not trying to split hairs, but the tarballs we create as RCs are licensed AL2.0 , and there's no way we can change that. That's all I mean, third parties can take those tarballs and redistribute them as they wish - as long as they take all of the precautions and steps redistributors usually should. I'm told it would be a bad idea for them to mis-represent things by claiming it was an ASF release, what kind of naming practises that translates into is probably best consulted with a lawyer :/ > I'd hate to find the RC process closed, as Jim's suggested, because of > misunderstandings about this subtle difference of opinion. The only > thing we lose is quality of our releases. This is not some subtle difference of opinion. You said; "Without an announce, /dev/ tarball build doesn't belong on any external site." This is simply at odds with the AL2.0, so I'm saying the complete opposite. I don't think that's subtle :-) /dev/ tarballs *are* re-distributable, it says so right there in them, and this is irrevokably the case. -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: Apachelounge problems
On Sun, Aug 19, 2007 at 01:15:21PM -0400, Joe Schaefer wrote: > > It's called "dist", clearly they are for any level distribution anyone > > feels like. Unless you want us to re-license! > > But the "dist" should be limited to people who are on/pay attention to > this mailing list [1]. This is simply at odds with the license :-) > Anything else increases the personal liability of anyone involved in > putting that tarball up on the website for download. That's a side effect, yes. It's never stopped me, but that window of liability does exist in our procedures. There all sorts of other holes in that "shield" too anyway :/ > If putting files into dev/dist conveys the implication that you intend > for people to be *redistributing* those artifacts, then I think it is > a mistake, It's not about implications, it's about the simple fact that the very license contained in those very files grants everyone an irrevocable right to distribute it. > and you'd be better off using people.apache.org/~foo for putting up > candidates to test. That doesn't stop people from redistributing > candidates, but it doesn't conflate the fact that the ASF/this PMC has > done nothing to endorse them. it also makes them slightly harder to scrape :-) -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: Apachelounge has to remove Apachelounge Feather, be warned
On Sun, Aug 19, 2007 at 02:40:39PM -0500, William A. Rowe, Jr. wrote: > The bottom line is that nobody took issue with Jeff's or my comments. They > are free to do so. Colm has this time around. His points don't quite jive, > if you offered a patch set and said "hey, this is the difference between > the ASF's 2.2.4 and my binaries here", then his point would be spot-on and > we'd all agree there is no issue. I have absolutely no idea what you're talking about here, and what points jive or not. > I couldn't find the argument for releasing our *candidates* on > external sites from Colm's observations. Our candidates are 100% redistributable and licensed in accordance with AL2.0, just like our svn trees. It says so right there in them, and we're pretty familiar with that the AL permits. If someone wants to take our candidates and put it on another site, they are plainly free to do so. -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: Apachelounge problems
On Sun, Aug 19, 2007 at 12:16:03PM -0400, Jim Jagielski wrote: > Colm MacCarthaigh wrote: > > Like I said, as long as ApacheLounge makes clear that the versions it > > carries are not ASF releases, it's certainly permitted by the license > > and not the least bit out of the ordinary. > > That's the point, isn't it?? Yes! And I think they should make it more clear :-) But I don't think we should be requesting them not to make RC tarballs or arbitrary checkouts from svn available, that's their choice. I think it's a bad idea for them, but ultimately their own problem. On principle I think it's wrong for us to request them not to - it's at odds with the OSI definition of open-source for one thing. -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: Apachelounge problems
On Sun, Aug 19, 2007 at 10:57:10AM -0400, Jim Jagielski wrote: > Released s/w is very very different from s/w that people can > obtain from trunk via svn themselves. The former is an > official distribution of a software project from the PMC (and > hence the ASF). The latter is not. So what though? The *vast* majority of Apache users use versions which were not released by us. There's the Debian/Ubuntu version, the RedHat versions, the BSD versions, the Covalent versions and so on and on. Like I said, as long as ApacheLounge makes clear that the versions it carries are not ASF releases, it's certainly permitted by the license and not the least bit out of the ordinary. -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: Apachelounge problems
On Sat, Aug 18, 2007 at 09:46:50PM -0400, Tom Donovan wrote: > Maybe not threatening - but it is an eye-opener for some of us that the > Apache2 license protects "released" versions of Apache differently. It doesn't. > My (possibly faulty) understanding was that the whole "Redistribution" > and "Disclaimer of Warranty" parts applied to *any* Apache software - > even if it was built from today's bug-ridden head revision of the trunk, It does. In order the protect *comitters* (not distributors) the ASF have some practises that allow it to (potentially) absorb some of the liability on releases. Because there's a vote and a chain of authority from the board yada yada yada in theory the release is made by the ASF as a corporate entity - not any single person. >From the point of view of a distributor, this practise may incline you to accept that a release is more "clean" but it makes no difference to your liability. As always though, if distributors have legal concerns about anything, then they should consult *their* lawyers. -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: Apachelounge problems
On Sat, Aug 18, 2007 at 06:31:01PM -0500, William A. Rowe, Jr. wrote: > * does it correspond to the tag? > * is it correctly licensed? > * is it correctly packaged? > * are any additions that appear to have IP encumbrances? > * does it build? > * does it run? > * does it pass the perl-framework regression tests? > > Since it isn't a release, you don't want to 'ship' it. Who are we to impose our practises on someone else? ApacheLounge clearly does *want* to ship it, as is manifestly evident by the fact it does it so regularly. ApacheLounge can use whatever aribtrary criteria it likes for creating its releases - as long as it makes sure there is no confusion that they are ASF releases. The BSD ports trees regularly contain builds that don't meet the above btw. And I don't think I've *ever* come accross a Linux package that corresponded to the tag. -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: Apachelounge has to remove Apachelounge Feather, be warned
On Sun, Aug 19, 2007 at 11:49:10AM +0200, Steffen wrote: > Correct me if I wrong, but sometimes I have the feeling that ASF and/or > Covalent Technologies are not happy with the Apache Lounge. You're wrong in that the ASF (and probably Covalent) are groups of people that don't act with a single concerted will. I have no problem with ApacheLounge. When I did windows dev, it was a great help. -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: Apachelounge problems
On Sat, Aug 18, 2007 at 05:09:08PM -0500, William A. Rowe, Jr. wrote: > Hmmm... seems that - even though we've *repeated* this multiple times, > we have to state this again. Contents of http://httpd.apache.org/dev/dist/ > are *development* tarballs and not for any distribution. It's called "dist", clearly they are for any level distribution anyone feels like. Unless you want us to re-license! > Since it's not an ASF release, *you* are absorbing all the liability > and risk that any released ASF package would carry. It's an > apachelounge release, so you would personally answer to any IP issues. > Not smart. Oh come on, our processes are better than that, people can have a reasonably degree of assurance that our trees are licensable with the AL at any given time. -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: PID table changes (was Re: svn commit: r547987 - in /httpd/httpd/trunk)
On Thu, Jun 21, 2007 at 05:51:34PM +0100, Joe Orton wrote: > On Sat, Jun 16, 2007 at 09:29:25PM -, Jim Jagielski wrote: > Secondly: I think this approach is unnecessarily complex. I think it's > sufficient to simply check whether the target process is in the right > process group before sending a signal, i.e. getpgid(pid) == getpgrp(). > This ensures that the parent will only kill things it created. I actually thought avoiding this was a design goal, to prevent someone from killing piped loggers and cgi processes ? -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: [Fwd: Apache httpd vulenrabilities]
On Fri, Jun 01, 2007 at 10:50:09AM -0400, Jim Jagielski wrote: > >Should we get rid of it from the table here? Can we get away without > >removing stale pids in general? What if they are recycled by the OS > >for something else? > > > > No, that's a good point. We should likely remove the > pid from our table once the child goes away. I think we need to do it with an actual table unset call too, not just set the entry to "0" or whatever, so that we don't exhaust our table. On that point, instead of initialising with ap_make_table(pglobal, 100) , it should probably use HARD_SERVER_LIMIT (if that's not in scope, it may even justify making it in scope) instead of 100 too, to avoid potential immediate exhaustion. Nice simple fix though, using a simple table seems like a way better approach than trying to replicate a paralell scoreboard. -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: [Fwd: Apache httpd vulenrabilities]
On Fri, Jun 01, 2007 at 10:05:26AM -0400, Jim Jagielski wrote:
> - if (ap_scoreboard_image->servers[n].status != SERVER_DEAD &&
> - kill((pid = ap_scoreboard_image->parent[n].pid), 0) == -1) {
> - ap_update_child_status(n, SERVER_DEAD, NULL);
> - /* just mark it as having a successful exit status */
> - bzero((char *) status, sizeof(ap_wait_t));
> - return(pid);
> - }
> +pid = ap_scoreboard_image->parent[n].pid;
> +if (ap_scoreboard_image->servers[n].status != SERVER_DEAD) {
> +if (in_pid_table(pid)) {
> +if (kill(pid, 0) == -1) {
> +ap_update_child_status(n, SERVER_DEAD, NULL);
> +/* just mark it as having a successful exit
> status */
> +bzero((char *) status, sizeof(ap_wait_t));
> +return(pid);
> +}
Should we get rid of it from the table here? Can we get away without
removing stale pids in general? What if they are recycled by the OS
for something else?
--
Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: [Issue] External links @ the wiki, aka pagechange wars
On Thu, May 24, 2007 at 06:47:49PM -0500, Webmaster wrote: > Say whatever you want, I'm not going to argue when the evidence is online > for everyone to examine. Go look at the wiki at my posting history, you > will see how unfairly I have been treated. I've done just that today, never having looked at it before. In my opinion, you have been treated fairly and have been given substantial leeway. > Why not respond like you are supposed to and actually SHOW me what is wrong, > misleading, or poorly written? You do not allow us to do so in the most efficient, convenient, accessible and collaborative manner - to edit them directly with comments. The people here are not free consultation for your personal website. > Isn't that what the wiki is for? How can we > improve content when it just gets deleted right away? I don't have time to > try to make a couple people like me.. thats silly, I go to the wiki to > contribute, share ideas, and learn about my favorite software. So why do you post so much "content" only in the form of links? you are mis-representing the problem here. -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: [Issue] External links @ the wiki, aka pagechange wars
On Thu, May 24, 2007 at 08:05:30AM -0400, Joshua Slive wrote: > External links are encouraged where they add substantial value, but > you may not link to your own pages or otherwise seek private benefits > from external links. I like the elegance of this rule, because if it's your page and you words, well you can just add the content to the wiki anyway. But at the same time it may invite even more awkward and inappropriate behaviour, e.g. paying someone else to add the links on your behalf. I think this problem is always going to fall into the "We know abuse when we see it" category, it requires a vague kind of rule-making which only humans can apply. I'm in favour of banning these links in this instance, though not all external links. -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: [vote] Piped loggers and APR_SHELLCMD_ENV
On Wed, May 23, 2007 at 06:39:48PM -0500, William A. Rowe, Jr. wrote: > So I brought up to the list 'fixing' this with an additional meta > character to follow | that would distinguish sh from non-sh invocations, > and permit both. Wouldn't "| exec logger" work? -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: What do you think about Lighttpd?
On Wed, Feb 28, 2007 at 01:32:44PM -0800, Paul Querna wrote: > steve wrote: > > On 2/27/07, Arnold Daniels <[EMAIL PROTECTED]> wrote: > >> Nick already told you, that Apache allows you to choose. So simply use > >> the fast-cgi/mpm-event combo, if you like that best. And if you want to > >> evangelize the combo, nobody is stopping you. > > > > I use this and it works fine. However: > > > > 1. The event MPM is EXPERIMENTAL. No telling when it will be deemed as > > production ready. > > . I dunno. I use it. (I also helped write it, soo...) I use it too, and have meddled with it enough at a source level to feel comfortable running it. It has obvious, documented, problems (don't use it with mod_ssl), but it's pretty good at what it's supposed to be pretty good at :-) -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: What do you think about Lighttpd?
On Tue, Feb 27, 2007 at 12:05:08AM +0800, howard chen wrote: > 1. single-threaded, event-based, (powered by epoll) httpd supports epoll() and event-based polling to the extent that the system-call chains for handling a request by Apache httpd and lighttpd are near-identical, it's hard to tell them apart using strace. The time it takes the system calls to return completely dwarfs the CPU time spent in actual code in my experience. Even with the worker MPM. using epoll gets Apache httpd and lighttpd similar enough to the point that any difference is statistical noise - though lighttpd is nearly always better for memory consumption. That said, httpd ships with poor configuration defaults for achieving this kind of performance (though are good reasons why those defaults are suitable generally) compared to lighttpd (which does it practically out of the box). In general, the extent of any performance difference is pretty hard to substantiate (and I've tried, though a systematic bias is that I'm vastly more familiar with httpd code and know how to tune it better!) and definitely over-stated. Either way, both servers are performant on regular hardware to an extent that they will never prove to be the problem in any scalability scenario. Each is capable of 100k and more concurrent requests and tens of thousands of requests per second, if really really pushed. Other kinds of limits will kick in *long* before the code in either httpd or lighttpd is a problem, at the end of the way a webserver just boils down to a handful of system calls. In the context of web-servers, performance comparisons are basically bar-chart pornography, and of little real-world utility. Hell, even IIS is usable these days. Better to concentrate on the feature-set and how each server helps you do whatever it is you want better. > 2. fast cgi support lighttpd's is better. httpd's is improving all the time though. -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: 3.0 - Proposed Goals
On Wed, Feb 14, 2007 at 01:57:27PM -0500, Brian Akins wrote: > Would be nice if we could do HTTP over unix domain sockets, for example. > No need for full TCP stack just to pass things back and forth between > Apache and "back-end" processes. Or over standard input, so that we can have an admin debug mode. Type HTTP on standard in, see corresponing log messages on standard out. Exim has this feature and it is very useful. -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: 2007 DST changes, and a "non-issue" statement...
On Wed, Jan 24, 2007 at 05:28:49PM -0500, Victor J. Orlikowski wrote: > I've been getting some questions (from my new employer) on the > impact of the upcoming Daylight Saving Time issues for the httpd. > > My natural response was: "There are none! It's an OS issue." Whatever about DST, this reminds me that there may actually be some real problems in our code with negative leap seconds, and there is still a chance there will be a negative leap second in late 2007. We have a few code-paths that will fail for that I think (like trying to calculate bandwidth rates, or times of downloads and so on). -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: vote on concept of ServerTokens Off
On Wed, Dec 06, 2006 at 01:43:49PM -0500, Jeff Trawick wrote: > * The Apache HTTP Server project believes that most people who want to > avoid sending the Server header mistakenly think that doing so may > protect their server from attacks based on known flaws in older Apache > HTTPD releases, when in fact the only reasonable way to address these > flaws is to upgrade to new Apache HTTPD releases which correct > security problems affecting your configuration. By restricting the > ability to configure Apache in this manner, we wish to raise awareness > of the need to upgrade when critical vulnerabilities are addressed. > > (what other reasons go here?) I think the more important thing about the "security" reason, is that it actually *degrades* security, because it impedes the ability to audit. Finding out-of-date installations is an nmap one-liner if you leave the Server header alone. If you disable it, you have to start logging in to the boxes (and getting that access and so on) and check things locally. I'd make that point. Personally I think we should include the functionality, I'm always in favour of allowing people to shoot themselves in the foot. Sometimes it's the only way they learn ;-) -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: httpd 2.2 cache - disable and enable
On Wed, Oct 11, 2006 at 05:04:21PM +0200, Matthieu Estrade wrote: > Hi, > > I would like to make disable and enable work with regular expression. > Something like CacheDisableMatch and CacheEnableMatch or working with > location tags. > > Does somebody have more preferences to one method ? I'd be -1 to anything that needed to perform a regular expression test to check the cache, it'd be a huge CPU hit on something that we're supposed to be doing as quickly as possible. If the regex can be applied only at cache time, then sure, but that's pretty hard to achieve! I think it would end up with the cache being checked for every URI served. As for implementation, I had a patch about a year ago to make CacheEnable work within regular and tags, can't find it right now though, and it'd be widly out of date, but iirc they can be made work together. -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: [PATCH] mod_disk_cache working LFS (filecopy)
On Tue, Sep 26, 2006 at 12:45:39PM +0300, Issac Goldstand wrote: > Forgive me for missing the obvious, but why not just use mod_file_cache > for this? > I recall you mentioning that your use of mod_cache was for locally > caching very large remote files, so don't see how this would help that > in any case since the file doesn't exist locally when being stored, and > if the file is otherwise known to be on the file system, there's no > reason to keep it in mod_disk_cache's cache area (in any case, it > wouldn't improve performance - only mod_file_cache would). So what am I > missing? There are plenty of instances in which moving it to a cache area may well improve performance. For example if you have several terabytes of cheap storage, but a nice U360 RAID-0 as a cache area. Of course the move will end up being a byte by byte copy anyway, since you can't just re-link the inode accross filesystems, but still. -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: porstfs bug t2000 and 2.2
On Wed, Aug 30, 2006 at 09:20:52AM -0400, Brian Akins wrote: > We tested a Sun t2000 with httpd 2.2. It did "okay." Now, Sun says > there is an issue with 2.2 and "portfs" on Solaris 10 on the t2000. It didn't do very well for me with Solaris 10 either. > Not real sure what this means. Anyone else heard this? Yep, it's event ports, which we support. How their implementation handles it, who knows :-) -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: perchild
On Wed, Aug 30, 2006 at 12:59:02PM +0200, Enrico Weigelt wrote: > The whole idea of passing *sockets* (instead of requests) between > processes only works on very few systems, ie. Linux, BSD and > perhaps some others. So the whole portability issue is useless - > those MPMs only work some Unix'es, and there evrythere the same. None of our MPMs offers that kind of portability. -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: [Vote] product name - for shipping versions
On Thu, Aug 10, 2006 at 12:26:23PM -0700, William A. Rowe, Jr. wrote: > Pretty darned quiet - either "it's summer" or nobody feels like > joining the fray when Roy and Will go at it? Well, Paul's talk in San Diego got me thinking. We're not really "just" about HTTP any more, it's a misnomer. We're about delivering information using many different protocols accross the internet. I don't know, something like Internet Information Server just seems more appropriate somehow. -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: load balancer "cluster" set
On Mon, Jul 31, 2006 at 12:22:03PM -0400, Guy Hulbert wrote: > The simple solution is to buy a bigger piece of hardware or outsource > the problem to the relevent experts. > > Trying to do meaningful load-balancing within an application will not be > simple. At the router it is simple. All the required data is present > in one spot. Load-balancing can be implemented at any arbitrary point in the stack (Ethernet/IP/DNS/TCP/HTTP/Application) and each has its own problems and features. There is nothing particularly appealing about doing it at the routing layer (though it does present a few novel options like using anycast or a TCP redirect), and doing it there has a few problems of its own. Either way, the more options and the more flexibility, the better. In the real world, you may find that many operations use multiple load-balancing techniques toghether (e.g. Google uses DNS, L2, L3 and L4 load-balancing). -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: svn commit: r426143 - /httpd/httpd/branches/2.2.x/NOTICE
On Thu, Jul 27, 2006 at 01:20:51PM -0700, Roy T. Fielding wrote:
> Well, the docs project consensus is wrong. Our main product is httpd
> (one of several products) and our project is Apache HTTP Server Project.
Our announcements say ``Apache HTTP Server ("Apache")'', I'd prefer if
we used that as the product name (and it really a matter of preference).
That way, we can't be accused of not having a valid notification for an
ssl-linked ab binary, when distributed as part of that product (which it
is) and our notification is consistent with our own release announcments.
--
Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: svn commit: r424693 - in /httpd/httpd/branches/2.2.x: CHANGES configure.in
On Sun, Jul 23, 2006 at 04:25:41AM -0500, William A. Rowe, Jr. wrote: > [EMAIL PROTECTED] wrote: > > > >* configure.in: Add --with-included-apr flag to force use of the > >bundled copies of APR and APR-util. > > Any desire to have a consistent syntax? --with-expat=builtin happens > to be that dependencies' flag to accomplish similar. I suggested that before and it got -1'd because of the potential conflict with a directory named ./builtin/ . -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: [PATCH] revamped mod_disk_cache directory structure
On Thu, Jul 20, 2006 at 06:16:26PM -0300, Davi Arnaut wrote: > >I'm not sure it goes far enough though. What if an admin has two > >filesystems/disks they can to store the cache on, or what if it's 7? > > "CacheDirLevels n 256" for n = 1,2,...,7,... Ahh, now I get it, cool. > >What if one is a 160GB filesystem and the other only 10GB? > > This was not the scope of the patch but it's one step towards. I > think we can add load balancing later. I think we'll need to change our syntax too, to "mount" cache areas individually. Can be messy. > >If we're going to tackle these kind problems, we need to look at how > >things like diablo (which gets it right IMO) do it. > > > > diablo ? the game ? :-) Diablo the news server :-) http://www.openusenet.org/diablo/ -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: [PATCH] revamped mod_disk_cache directory structure
On Thu, Jul 20, 2006 at 11:58:01AM -0300, Davi Arnaut wrote: > Also, with this patch it is possible to designate directories to separate > partitions because the temporary files are created on the destination > directory. I'm not sure it goes far enough though. What if an admin has two filesystems/disks they can to store the cache on, or what if it's 7? What if one is a 160GB filesystem and the other only 10GB? If we're going to tackle these kind problems, we need to look at how things like diablo (which gets it right IMO) do it. -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: [TALLY] Release mod_aspdotnet build 2004?
On Thu, Jul 20, 2006 at 01:09:19PM +0200, Trent Nelson wrote: > 1. Download and install latest Win32 2.2.2 Apache binary. o.k., well that's a bad start, but I can handle building an Apache binary :-) > 2. Download .netCHARTING 4.0 evaluation version for .NET 1.1 from > http://www.dotnetcharting.com/download.aspx. They want my email address, so that's a non-starter. Are there any other ASP applications, liberally licensed, that would serve as a good test? > 3. Unzip somewhere, e.g. c:\dotnetcharting. > > 4. Edit httdp.conf and add the following: > > # ASP.NET Configuration > LoadModule aspdotnet_module modules/mod_aspdotnet.so How did you compile it? > AddHandler asp.net asax ascx ashx asmx aspx aspxauth axd config cs > csproj \ >licx rem resources resx soap vb vbproj vsdisco > webinfo > > > > AspNetVersion v1.1.4322 > > AspNetMount /dotnetcharting "C:/dotnetcharting" > > Alias /dotnetcharting "C:/dotnetcharting" > > > Options FollowSymlinks ExecCGI > Order allow,deny > Allow from all > DirectoryIndex Default.htm Default.aspx > > > # For all virtual ASP.NET webs, we need the aspnet_client files > # to serve the client-side helper scripts. > AliasMatch /aspnet_client/system_web/(\d+)_(\d+)_(\d+)_(\d+)/(.*) \ > "C:/Windows/Microsoft.NET/Framework/v$1.$2.$3/ASP.NETClientFiles/$4" >"C:/Windows/Microsoft.NET/Framework/v*/ASP.NETClientFiles"> > Options FollowSymlinks > Order allow,deny > Allow from all > > > > > 5. Restart httpd and visit http://localhost/dotnetcharting. Cool :) -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: [TALLY] Release mod_aspdotnet build 2004?
On Wed, Jul 19, 2006 at 01:21:12PM -0400, WDaquell wrote: > So, the whole mod is just going to die? It's not like the source will cease to exist or become impossible to maintain. If no developers can be convinced to volunteer their time and effort on the maintainence part, then you can always pay someone to do it :-) > Just because we didn't submit bugs or feature requests? Isn't there a > problem with a system that assumes software is unwanted if there > aren't any bugs found or features that need to be added? -1 for > opensource from me... I guess I'll have to move on to more expensive > options. Thank you William Rowe for trying; that's more than most of > the rest can say. And we owe you what exactly? :) Feel free to chip in, I'd be more than happy to vote +1 for the module if I knew how to get it up and running and test it with even a hello world ASP. I had a brief look, and it seemed like a lot of effort. You could document that, and it might make it easier for testers. -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: 2.2.3
On Wed, Jul 19, 2006 at 11:11:53AM +0300, Eli Marmor wrote: > Thanks to your great efforts, there are exciting new features in the > trunk, and it would be great to bring them to the masses... Don't expect new features in trunk to form the part of any 2.2.3 release. For the most part, they will first appear in a 2.3.x alpha release :-) -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: IPV6 enabled on supplied Windows 32 binary?
On Thu, Jul 13, 2006 at 10:47:15AM -0500, Jess Holle wrote: > So what's the story with IPv6 on Windows? Works fine in every version of windows since 2000, although 2000 itself needs a kit and patching installed. > Are there some versions of Windows which always support it, but the > headers we use for Windows don't detect this at build time? We don't use an autoconf-like system on Windows, so although we could detect this at build time, it's just something which has been left as a build option. > We bundle our own Apache builds for a number of Windows OS levels and > have customers who really want IPv6... I don't want to break anything > for the rest of the customers, though. That's at your own risk :-) -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: IPV6 enabled on supplied Windows 32 binary?
On Wed, Jul 12, 2006 at 08:12:41PM +0200, Jorge Schrauwen wrote: > Indeed i can't get mine to bind on IPv6 aswel... strange since i was sure i > had it listening on IPv6! > > I get a > [Wed Jul 12 20:10:16 2006] [crit] (OS 11004)The requested name is valid, but > no data of the requeste > d type was found. : alloc_listener: failed to set up sockaddr for > [fe80::211:d8ff:fe94:8881%4] Why are you trying to listen on a link-local address? Is this intentional :-) If you try it with [::1], does it work? -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: debug apache
On Mon, Jun 19, 2006 at 12:03:57AM +0200, Alexander Lazic wrote: > Sorry for that, which list is the right one from your point of view? dev@apr.apache.org :-) -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: [EMAIL PROTECTED] Re: debug apache
On Sun, Jun 18, 2006 at 10:25:27PM +0200, Mathieu CARBONNEAUX wrote: > but using strace directly by attaching to processus can be risky in > production (like gdb!)... and with apache with 256 or 512 processuss > all working can be hard to debug... *shrug*, I regulary attach tracers to apache with well into the thousands of processess/threads. Never had a problem in years of doing that. Anyway, as others have pointed out, this topic is off-topic here. -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: svn commit: r413861 - /httpd/httpd/trunk/support/ab.c
On Tue, Jun 13, 2006 at 12:11:38PM +0100, Joe Orton wrote: > On Tue, Jun 13, 2006 at 10:51:55AM -, [EMAIL PROTECTED] wrote: > > Author: colm > > Date: Tue Jun 13 03:51:54 2006 > > New Revision: 413861 > > > > URL: http://svn.apache.org/viewvc?rev=413861&view=rev > > Log: > > A keepalive response need not neccessarily have included any content-length > > header, handle this case properly for 304 responses. PR39789 > > This looks wrong, the patch in the PR was a bit better. If a response > doesn't have a C-L/T-E the body is read till EOF. [23]04 are special > cases which have zero length bodies regardless of the message headers. 204 is why I didn't conditionalise it on 304, my comment was a bit misleading there. My change has the same effect as the patch in the PR for 304 responses, but also for any other keep-alive request which doesn't include a C-L. Should I restrict to more specific response codes? or is there another problem I'm just not seeing :) -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: restructuring mod_ssl as an overlay
On Fri, Jun 09, 2006 at 12:29:06PM +0200, Plüm, Rüdiger, VF EITO wrote: > > -Ursprüngliche Nachricht- > > Von: Joe Orton [ > > > > Would only committers count as "participating" in the project > > for this > > purpose, do you think? Random people submitting patches would not? > > Stupid question: How can someone who is not allowed to download the sources > can submit patches? :-). There is *nothing* preventing them from downloading and using our sources. That's a non-issue :-) -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: restructuring mod_ssl as an overlay
On Thu, Jun 08, 2006 at 02:47:59PM -0700, Roy T. Fielding wrote: > If anyone can think of another option, I'd like to hear it before > proposing a vote. Another option is that we could ask the ASF to formally consider upping roots and changing jurisdiction. I have little doubt over what the answer would be, but I'd prefer that we exhaust all of the alternative options before doing anything which would intentionally prohibit developer participation. After that, based on your excellent summary, I'm begining to see the wisdom of a subproject - despite the overhead, maximising developer involvement and the potential community size is much more important. -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: AW: restructuring mod_ssl as an overlay
On Thu, Jun 08, 2006 at 11:07:51AM -0700, Justin Erenkrantz wrote: > On 6/8/06, Colm MacCarthaigh <[EMAIL PROTECTED]> wrote: > >There are quite a few reasonable alternative strategies for dealing with > >that kind of scenario. Does the ASF have such a policy as a matter of > >course, regardless of the severity of such an action? > > As that hasn't happened yet, there is no set policy - except that we > would take it very seriously. Absolutely, I'm just hoping we'd explore things like licensing for nominal fee and so on. It hardly matters, it's for another day :-) One way in which it may be related though, is that in the past we've made some changes to openssl to get it to compile, and we wondered if that meant we'd have to put the resulting OpenSSL on tarball on a.o. We need to be careful about the patent-encumbant source code those tarballs contain too. Just something to watch out for. -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: AW: restructuring mod_ssl as an overlay
On Thu, Jun 08, 2006 at 12:16:02PM -0500, William A. Rowe, Jr. wrote: > Colm MacCarthaigh wrote: > > > >Suffice it to say that even a cursory glance at a patents register > >would likely reveal many ludicrous patents which httpd may infringe. > > Yup; if the claimant to any such -legitimate- patent comes knocking, > it *will* be removed from svn and the project, in case you had any > doubts. There are quite a few reasonable alternative strategies for dealing with that kind of scenario. Does the ASF have such a policy as a matter of course, regardless of the severity of such an action? -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: AW: restructuring mod_ssl as an overlay
On Thu, Jun 08, 2006 at 12:01:16PM -0500, William A. Rowe, Jr. wrote: > Colm MacCarthaigh wrote: > >What's next, do we start stripping patented methods from our tarball > >and making that available too? > > Uhm which patent *encumbered* methods? If I were to identify any or perform a patent search, that would make matters about a hundred times worse for all you US-based contributors, so I'm going to decline that particular honour ;-) Suffice it to say that even a cursory glance at a patents register would likely reveal many ludicrous patents which httpd may infringe. -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: AW: restructuring mod_ssl as an overlay
On Thu, Jun 08, 2006 at 08:16:48AM -0500, William A. Rowe, Jr. wrote: > The group of people who concern me are not those in T-8, they are those who > live in jurisdictions where *they* would be breaking local law by possessing > crypto. Leave them a) in the backwaters / b) in fear / c) in violation, or > give them a silly httpd-2.2.x-no-ssl.tar.gz? The later seems sane to me. The personal liabilites of users are not our concern. That's strictly a matter for users and their legal counsel. What's next, do we start stripping patented methods from our tarball and making that available too? If the no-ssl tarballs are to be of any use it is in aiding the ASF in presenting a reasonable best-effort defence in relation to US export controls. -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: restructuring mod_ssl as an overlay
On Wed, Jun 07, 2006 at 06:58:27PM -0700, Roy T. Fielding wrote: > "We" is anyone representing the ASF. How (or who) would determine > that is anyone's guess. eek. Who is burdened with that liability? I'm guessing it's the ASF as a body corporate and possibly its directors personally. If that's the case, then the Foundation needs to decide if it's comfortable with a legal release policy that depends on the continued voluntary non-promotion of our software by ASF members and (probably) PMCs within those countries intersected with the goodwill of whoever makes the determination we're talking about. As the ASF lacks, afaik, a method of keeping anyone in-line, so to speak, that would seem dubious at best and completely untennable at worst. The vagueness of the regulation, and I'm guessing an absense of case-law, means that ultimately it's a complex judgement call as to what level of risk people are willing to accept, and to me it looks like it's up to the foundation to come back to us and tell us whether or not they are comfortable with that. >From the httpd point of view, it does seem a potentially very unstable policy requirement, but probably workable in the real world. Still, it gets murky around the edges, like should we stop letting linuxiran.org know when we make releases? There are all sorts of ways in which this policy could never be anything close to watertight. One thing which is important though is that I'd hope that if we ever had developers based in any of those countries, that we'd encourage their involvement regardless - which could be extremely awkward within such a policy. This isn't so unlikely as it may seem, iirc it came very close to at least one PMC member's nation being on the list a while back. Thanks for the links, good reading! -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: restructuring mod_ssl as an overlay
On Wed, Jun 07, 2006 at 04:32:40PM -0700, Roy T. Fielding wrote: > We also cannot go to one of those countries and agitate for people > to download a copy of httpd and run their own web server Who's "we"? Members of the ASF? Members of the PMC? committers? developers? I'd like to know. My "Apache Mirrored Worldwide" t-shirt is quite nice for Cuban weather :-) -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: restructuring mod_ssl as an overlay
On Wed, Jun 07, 2006 at 04:02:01PM -0700, Roy T. Fielding wrote: > we would have to provide our own copy of the distribution or include > the source code directly in our product, just to comply with EAR. > My preference is to not distribute OpenSSL. +1 -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: restructuring mod_ssl as an overlay
On Wed, Jun 07, 2006 at 02:51:12PM -0700, Cliff Schmidt wrote: > Here's the page that I've put together right now: > http://apache.org/dev/crypto.html. Unfortunately, it needs a little > more detail. Thank you very much, that's already answered a few of my questions and given me some good pointers. > The US export laws do not require us to offer a non-crypto version of > products we place on the web that do include export-controlled crypto. > The only thing we cannot do is knowingly export to a handful of > particular countries; however, placing an item on the web does not > qualify as knowingly exporting to any particular country. That would be excellent. > However, if there are httpd users in countries that have *import* > restrictions that would like to use the non-ssl version of httpd, that > might be a reason to do what is being suggested here. But there is no > U.S. regulation that I am aware of that requires us to distribute a > non-SSL versionbut maybe I'm not understanding the concern. >From the sound of things, we could put up ssl-capable downloads right now with no liability for the ASF or anyone other than users in countries with such restrictions, which is useful to know. > >So, I'm wondering how effective a liability shield it is for a US-based > >corporation to export such content via non-US-based distributors. It > >seems odd that this would work legally, but that SPI/Debian did it for > >so long sparks my interest; maybe there is a path through. > > I have no idea what the Debian story is, but that is not an option for > a number of reasons. Here's the biggest reason, the same U.S. > government entity that controls our exports also controls reexport > from any other country of goods that were previously exported from the > U.S. I've been reading http://www.debian.org/legal/cryptoinmain and it looks like they shifted the liability to their developers personally, who exported-by-proxy. -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: restructuring mod_ssl as an overlay
On Wed, Jun 07, 2006 at 02:03:33PM -0700, Roy T. Fielding wrote: > The point is that they may want to download a web server which doesn't > have that problem, and right now they are limited to 1.3.x. I consider > Web servers to be something we would want people in those countries > to be able to download without concern. Freedom of the press. I'm in favour of everyone being able to download httpd :-) > >If a person happens to live in a country which is on > >the USA's banned list, there's nothing illegal (purely from their > >perspective) about their act of download, US law does not apply to > >them. > > Right, but it does apply to us (and to Ireland as well, AFAIK) if we > encourage people in those countries to download the web server but > do not also provide a non-crypto alternative. > > >Surely the illegality is that the ASF exports the code to those > >countries, and if anyone is answerable to those particular laws it is > >any US-based exporter of the code. I just want to be clear about this > >distinction, if it's correct. > > Mostly. The banned countries are also banned by the EU (the > anti-terrorism laws), so it isn't as simple as you might think. It's not nearly so simple as that either. There's a complicated intersection of national laws, the Wassenaar Arrangement and local interprettation. Here in Ireland, we are extremely liberal on crypto export due to lobbying by the local software and crypto industry. Indeed, it's even a selling point at attracting some multinationals here. Afaik, very few - if any - countries share the US list of designated countries, Cuba being a near-universal counter-example. But that hardly matters anyway :-) > 1) retain the status quo, forbid distributing ssl binaries, and > include > in our documentation that people in banned countries are not > allowed > to download httpd 2.x. > > 2) split the distribution into plain and crypto parts and only have to > deal with the export controls within the crypto distribution. > > 3) delete mod_ssl from httpd > > Pick one. I'm fine with number 2. But I'd prefer if we achieved it via modifying release.sh/roll.sh rather than creating a subproject or two and all of the overhead that entails. > The ASF is within US borders and is a US corp. And, no, whatever it > was that Debian was trying to do is not even remotely sufficient for > the US because it just makes each developer the exporter. Hmm, are they really that crazy? -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: restructuring mod_ssl as an overlay
On Wed, Jun 07, 2006 at 03:53:51PM -0500, William A. Rowe, Jr. wrote: > Before we take -any- action, we need to have one policy across the ASF. *shrug*, this is [EMAIL PROTECTED], so I'm going to stick to httpd specifically for now, and that can feed in or not to any policy the ASF desires to later impose :-) > Our research hopefully contributes substantially to that policy. But > we can't enable per-project balkanization when it comes to complying > with US law. Sure, but I don't have the legal advice, and I'm trying to ask some targetted questions to see what other options there are. I've been studying law, for my sins ;-) Anyway, I'm not taking responsibility for monitoring any paralell discussions elsewhere within the ASF and trying to ensure coherency. > As I've said, I'm ok with two seperate (full) tarballs, e.g. two (full) > corresponding binary distributions; I'm ok with a core tarball and an > add-on crypto component. I'm not really ok with the status quo as there > is no way to not download crypto in a restricted jurisdiction if one wants > httpd, unless some party has retarred the release for us sans mod_ssl. I'm fine with that too, it's a sensible pragmatic thing which makes life easier for a lot of people. Re-organising our subversion tree and development practices seems a bit extreme though, I mean do we also split out mod_auth_digest? Where do we stop? I don't want to have to RM, test or vote on two or three tarballs every time we make what is really one release because of some dumb laws. > >Is the mere legal registration of the ASF within US borders a solid > >stumbling block here? As in, could the situation be remedied by > >forbiding US-based distributors? (Similar to what Debian used to do with > >it's non-US repositories). > > Dude, we are a Deleware, US foundation. Sure, I realise that, and SPI is a New York, US foundation, but Debian managed to distribute non-US for years. But I'm not privy to their legal advice either. So, I'm wondering how effective a liability shield it is for a US-based corporation to export such content via non-US-based distributors. It seems odd that this would work legally, but that SPI/Debian did it for so long sparks my interest; maybe there is a path through. -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: restructuring mod_ssl as an overlay
On Wed, Jun 07, 2006 at 01:03:48PM -0700, Roy T. Fielding wrote: > c) each redistributor (re-exporter) of our packages must do the same > [I am unsure if that means every mirror is supposed to file as > well, but for now I am guessing that they don't]; They don't :) > e) people who are in the banned set of countries and people in > countries that forbid encryption cannot legally download the current > httpd-2 packages because they include mod_ssl even when it won't be > used. I don't see how this can possibly be the case. If crypto code is illegal locally, then it is illegal locally and people need to figure that out from themselves. If a person happens to live in a country which is on the USA's banned list, there's nothing illegal (purely from their perspective) about their act of download, US law does not apply to them. Surely the illegality is that the ASF exports the code to those countries, and if anyone is answerable to those particular laws it is any US-based exporter of the code. I just want to be clear about this distinction, if it's correct. Or is there a suggestion that the situation invalidates the user's license? (contracts can be invalidated when a law is broken, but it's complex stuff). > I think the best way to accomplish that is to separate mod_ssl into a > subproject that is capable of producing overlay releases for each > release of httpd. yuck! -1 > Thoughts? Anyone have any better ideas? Is the mere legal registration of the ASF within US borders a solid stumbling block here? As in, could the situation be remedied by forbiding US-based distributors? (Similar to what Debian used to do with it's non-US repositories). -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: svn commit: r409942 - in /httpd/httpd/trunk: CHANGES modules/cache/mod_disk_cache.c
On Sun, May 28, 2006 at 10:32:04AM -, [EMAIL PROTECTED] wrote:
> rv = apr_file_rename(dobj->tempfile, dobj->datafile, r->pool);
> if (rv != APR_SUCCESS) {
> -/* XXX log */
> +ap_log_error(APLOG_MARK, APLOG_DEBUG, rv, r->server,
> + "disk_cache: rename tempfile to datafile failed:"
> + " %s -> %s", dobj->tempfile, dobj->datafile);
> +apr_file_remove(dobj->tempfile, r->pool);
> }
A significant source of this kind of error is that the filesystem
suddenly becomes read-only. Either to a protective automative re-mount
by the kernel, a log journal becoming full, in which case the remove
will also fail :/
--
Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: 1.3.36 Released...
On Thu, May 18, 2006 at 11:38:53AM -0400, Jim Jagielski wrote: > What I'm saying is that there is a BIG difference between actively > *supported* and actively *developed*. As far as I'm concerned, we > still support 1.3.x, for our huge install base of legacy users. What does "support" mean in this context? Are we talking about responding to security notices, producing security-related patches and security-related releases? Why would we ever stop doing that as long as someone was willing to write the patch? Just genuinely curious :) -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: [PATCH] aborting on OOM
On Thu, May 11, 2006 at 04:01:50PM +0100, Joe Orton wrote: > +#if APR_HAVE_UNISTD_H > +#include > +#endif > + We might need io.h on win32, but we can easily figure that out :) > +#define OOM_MESSAGE "[crit] Memory allocation failed, aborting process.\n" APR_EOL_STR instead of \n, but apart from that, +1 -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: [PATCH] aborting on OOM
On Wed, May 10, 2006 at 11:22:25AM -0700, Garrett Rooney wrote: > Which is likely to be redirected to /dev/null in most cases... We redirect standard error to the main error log :) See ap_open_logs in server/log.c :-) httpd -E also causes stderr redirection for the start-up phase, /dev/null is the usually the exception :) -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: [PATCH] aborting on OOM
On Wed, May 10, 2006 at 11:11:27AM -0700, Garrett Rooney wrote: > On 5/10/06, Colm MacCarthaigh <[EMAIL PROTECTED]> wrote: > >On Wed, May 10, 2006 at 10:53:50AM -0700, Garrett Rooney wrote: > >> I would personally prefer abort to exit... > > > >is write()'ing a static error message an option too? > > Perhaps, but where would you write() to? STDERR_FILENO :) -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: [PATCH] aborting on OOM
On Wed, May 10, 2006 at 10:53:50AM -0700, Garrett Rooney wrote: > I would personally prefer abort to exit... is write()'ing a static error message an option too? -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: Problem with mod_cgid and large POST queries
On Tue, May 09, 2006 at 03:45:20AM +0530, Mendonce, Kiran (STSD) wrote: > If I use TCP socket instead of the default unix doman socket for the > Scriptsock directive, How are you doing that? Are you hacking the source? > before httpd can send it all of the data. But the CGI process has sent > out the Content Length and another message expected of it to the > httpd. Httpd while reading the pipe that it has with the CGI script > reads the data sent by the CGI process. However, the next read() fails > because with an ECONNRESET. If it's hanging around doing nothing for a while, then your kernel will usually kill a TCP socket after some default keepalive time. Seems reasonable. > Given that the CGI process has done what > is expected of it and that the response has reached httpd, isnt this a > bug with mod_cgid ? IMO, ECONNRESET should be ignored in this case and > the response should reach the client. How exactly is mod_cgid supposed to re-establish a connection with the CGI? -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: Dealing with Regressions
On Mon, May 08, 2006 at 03:45:21PM +0100, Colm MacCarthaigh wrote: > Yep, my bad, I never had such a block in my testing largely because I > didn't even know 1.3.x had that feature, *sigh*, it's not even > documented and I can't see it in a changelog and it didn't have that > functionality when I first wrote that patch. Turns out it is documented. I should have caught it from inspection anyway. -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: Dealing with Regressions
On Mon, May 08, 2006 at 10:12:58AM -0400, Jim Jagielski wrote:
> That is an unexpected and unwelcome regression.
Yep, my bad, I never had such a block in my testing largely because I
didn't even know 1.3.x had that feature, *sigh*, it's not even
documented and I can't see it in a changelog and it didn't have that
functionality when I first wrote that patch.
> If I had known about it I would have vetoed the patch. I'd be willing
> to actually release a 1.3.36 simply to address that.
Patch attached, courtesy of Matthijs van der Klip. Or simply revert the
whole change.
--
Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
diff -Bru apache_1.3.35/src/main/http_config.c
apache_1.3.35-include/src/main/http_config.c
--- apache_1.3.35/src/main/http_config.c2006-05-05 12:00:14.0
+0200
+++ apache_1.3.35-include/src/main/http_config.c2006-05-05
12:00:39.0 +0200
@@ -1214,16 +1214,19 @@
return strcmp(f1->fname,f2->fname);
}
-CORE_EXPORT(void) ap_process_include_config(server_rec *s, char *fname, pool
*p, pool *ptemp,
+CORE_EXPORT(void) ap_process_include_config(server_rec *s, char *fname, pool
*p, pool *ptemp,
cmd_parms *parms)
{
const char *errmsg;
struct stat finfo;
-
+int ispatt;
fname = ap_server_root_relative(p, fname);
-if (stat(fname, &finfo) == -1)
+if (!(strcmp(fname, ap_server_root_relative(p, RESOURCE_CONFIG_FILE))) ||
+ !(strcmp(fname, ap_server_root_relative(p, ACCESS_CONFIG_FILE {
+ if (stat(fname, &finfo) == -1)
return;
+}
/*
* here we want to check if the candidate file is really a
@@ -1231,12 +1234,36 @@
* horrible loops). If so, let's recurse and toss it back into
* the function.
*/
-if (ap_is_rdirectory(fname)) {
+ispatt = ap_is_fnmatch(fname);
+if (ispatt || ap_is_rdirectory(fname)) {
DIR *dirp;
struct DIR_TYPE *dir_entry;
int current;
array_header *candidates = NULL;
fnames *fnew;
+ char *path = ap_pstrdup(p,fname);
+ char *pattern = NULL;
+
+if(ispatt && (pattern = strrchr(path, '/')) != NULL) {
+*pattern++ = '\0';
+if (ap_is_fnmatch(path)) {
+fprintf(stderr, "%s: wildcard patterns not allowed in Include "
+"%s\n", ap_server_argv0, fname);
+exit(1);
+}
+
+if (!ap_is_rdirectory(path)){
+fprintf(stderr, "%s: Include directory '%s' not found",
+ap_server_argv0, path);
+exit(1);
+}
+if (!ap_is_fnmatch(pattern)) {
+fprintf(stderr, "%s: must include a wildcard pattern "
+"for Include %s\n", ap_server_argv0, fname);
+exit(1);
+}
+}
+
/*
* first course of business is to grok all the directory
@@ -1244,11 +1271,15 @@
* for this.
*/
fprintf(stderr, "Processing config directory: %s\n", fname);
+#ifdef NETWARE
dirp = ap_popendir(p, fname);
+#else
+ dirp = ap_popendir(p, path);
+#endif
if (dirp == NULL) {
perror("fopen");
fprintf(stderr, "%s: could not open config directory %s\n",
- ap_server_argv0, fname);
+ ap_server_argv0, path);
#ifdef NETWARE
clean_parent_exit(1);
#else
@@ -1259,9 +1290,11 @@
while ((dir_entry = readdir(dirp)) != NULL) {
/* strip out '.' and '..' */
if (strcmp(dir_entry->d_name, ".") &&
- strcmp(dir_entry->d_name, "..")) {
+ strcmp(dir_entry->d_name, "..") &&
+(!ispatt ||
+ !ap_fnmatch(pattern,dir_entry->d_name, FNM_PERIOD)) ) {
fnew = (fnames *) ap_push_array(candidates);
- fnew->fname = ap_make_full_path(p, fname, dir_entry->d_name);
+ fnew->fname = ap_make_full_path(p, path, dir_entry->d_name);
}
}
ap_pclosedir(p, dirp);
Re: [PATCH 5/6] hard restart on Linux #38737
On Mon, May 08, 2006 at 06:19:59AM -0400, Jeff Trawick wrote: > >Question: what other side-effects might this have? > > unpredictable if somebody/something sends AP_SIG_GRACEFUL to the child > process; it will land on random worker thread > > (it might be nice for debugging if you could make processes gracefully > exit by sending them the signal; sending LISTENER_SIGNAL to a child should do that anyway :) -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: [PATCH 1/6] scoreboard over-sized
On Fri, May 05, 2006 at 11:20:14PM +0100, Nick Kew wrote: > Looks right for ap_init_scoreboard, and there's nothing else relevant > in scoreboard.c. A quick grep suggests it's globally right, so +1. Same here, afaict the patch gets it right. -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: [PATCH 3/6] generation number unset
On Thu, May 04, 2006 at 01:36:54PM -0400, Chris Darroch wrote: >This may not be necessary, but I notice that prefork and most of > the other MPMs set ap_my_generation to an initial value of zero. > The worker and event MPMs don't, though. Yes, we don't have any consistency in the actual code here but the result is always the same as the compiler will make sure that they are zero-initialised. Although I did hit a curious compiler optimisation bug which destroyed this assumption a few months back (that bug has since been fixed though). It's no mark making the initialisations explicit though anyway. -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: Joint Release of all branches
On Sat, Apr 29, 2006 at 08:43:05AM -0700, Sander Temme wrote: > I think we have three releasable tarballs on our hands. Let's throw > them over the wall. 2.0.58 has already hit the mirrors, I'll update the website with announcements once Paul has mailed the 2.2.2 announcements. That seems closest to what consensus was suggesting. -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: Joint Release of all branches
On Mon, Apr 24, 2006 at 01:49:29PM -0500, William A. Rowe, Jr. wrote: > What I'd like to propose is 1) wait for the unified announce on Wed night, > 2) cease pushing out any 1.3 or 2.0 specific product announcements. Whatever way we end up cutting this, can we agree to at least let packagers@httpd.apache.org know about the 3 different releases? Either all in one go, or seperately. -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: [VOTE] Apache HTTP Server 1.3.35 Candidate
On Mon, Apr 24, 2006 at 01:55:37PM -0400, Jim Jagielski wrote: > Please test and vote on releasing Apache httpd 1.3.35 +1, tested on Solaris Sparc and Ubuntu x64 -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
[VOTE] 2.0.58 Candidate
O.k., for the last time, hopefully :) A candidate for 2.0.58 is available for testing and voting at; http://httpd.apache.org/dev/dist/ The MD5sums are; ac732a8b3ec5760baa582888f5dbad66 httpd-2.0.58.tar.bz2 a03eeefee78c01ec24c8671380763860 httpd-2.0.58.tar.gz The code is identical to the previous 2.0.57 candidate save the ap_release.h version numver change. The only material change is the revert of the copyright years. -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: Joint Release of all branches
On Mon, Apr 24, 2006 at 05:40:45PM +0100, Colm MacCarthaigh wrote: > If you feel that strongly about it, veto the code change, and I'll tag > and roll 2.0.58. O.k., this is coming anyway :) -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: Joint Release of all branches
On Mon, Apr 24, 2006 at 09:15:01AM -0700, Justin Erenkrantz wrote: > > -1, there's been enough back and forth on this. The current status is > > that the existing candidate is good for release unless people start > > reverting their +1's, which so far - has not happened. > > As I have stated before, I believe it's completely inappropriate for > us to be releasing files with bogus copyright years. I don't think there's any dispute over that. The question is whether this is important enough to waste another release cycle over. Faced with that, I don't see how a legal nit over the copyright line should cause people to have to go to the trouble of testing yet another candidate tarball. As we saw with APR, there are only so many unreleased candidates a group can take before they just stop bothering to test them. There is a complete lack of direction from ASF board/legal on this btw, despite your assertion. If you feel that strongly about it, veto the code change, and I'll tag and roll 2.0.58. -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: [VOTE] 2.2.2 Candidate
On Fri, Apr 21, 2006 at 09:35:23PM -0700, Paul Querna wrote: > Download from: > http://httpd.apache.org/dev/dist/ +1, and in production on ftp.heanet.ie for a day now with no problems. -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: Joint Release of all branches
On Sun, Apr 23, 2006 at 11:20:59PM -0700, Sander Temme wrote: > It looks like the 2.2.2 RC is the closest to being ready for release, > with the 72 hour window on www.a.o running out Monday night Pacific. > However, I would like to urge holding back the release until the > branches can catch up. Tbh, I'm -0.5 on this. It's complex enough as it is trying to get releases out, and 1.3 hasn't even tagged yet. > For 2.0, we probably should re-roll 2.0.58 with the copyright > statement reversion and take a new vote -1, there's been enough back and forth on this. The current status is that the existing candidate is good for release unless people start reverting their +1's, which so far - has not happened. -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: [VOTE] 2.0.57 candidate
On Fri, Apr 21, 2006 at 10:31:25PM -0500, William A. Rowe, Jr. wrote: > Appears to be Colm's choice of 1. nothing extra, 2. revert date > changes/reroll, or 3. revert date changes (w/ any other changes he > wishes), bump and reroll. That's my preference, in descending order, > but support whichever he chooses. My preference is similar, I'd prefer to ship 2.0.57 as it is now rather than either confuse the whole process by introducing another candidate. So, unless people revert their votes for release, we can release the present candidate very shortly after 2.2.2. -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: [VOTE] 2.0.57 candidate
On Fri, Apr 21, 2006 at 01:46:21PM -0500, William A. Rowe, Jr. wrote: > which is all well and good, but doesn't assert copyrights. And that's fine, there is no need to assert a copyright :) > I'm really completely unclear how this protects the files we author, > the files authored by others (which we have appropriately > appropriated) and the files on which no copyright is claimed (e.g. > apr/ examples public domain.) A line such as "Copyright Colm MacCarthaigh" gives me no protection copyright didn't already afford me in the absense of that line. The only thing it does do is serve as a courtesy to potential licensees letting them know who to contact if they wish to license the work. It's an advertisement. At a stretch, the inclusion of the line might allow you to argue the "Wow you must be really dumb not to have seen the copyright notice" argument, but that wouldn't hold much weight, since if it were absent there would still be an assumption of copyright. A line such as "Copyright 2004-2006 Colm MacCarthaigh" serves as a courtesy to the world, letting them figure out when the copyright will expire. -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: [VOTE] 2.0.57 candidate
On Fri, Apr 21, 2006 at 12:51:19PM -0500, William A. Rowe, Jr. wrote: > Justin Erenkrantz wrote: > > > >It matters that we've now said on a public list that we know the > >notices are incorrect. Before, we actually believed that those > >changes were right. That's a huge difference. -- justin > > You've said so. Roy's said so. Colm said it's irrelevant. I've seen no > statement by the ASF (board of directors, VP legal affairs) so it's well > written, stylishly composed hot air until the ASF asserts an explicit > policy. O.k., I'll try and give some background, IANAL and I'm just trying to fill in, based on my own understanding here. Justin is entirely correct that we shouldn't be saying "Copyright N-2006" where those files lack significant changes within the latter year. This is fraud, and us knowing about it makes it willful fraud which a) can have an effect on damages in some jurisdictions, b) harms our credibility, both in the context of any related legal cases and just in general. However the nature of the fraud isn't exactly a big deal from a risk-assessment point of view. Because it's very hard to identify any harm caused by the error. After all, we publish the code under a very liberal license. In theory, in about 60 years time, someone could argue that we deprived them of the correct notice as to when they could start using the code in non-ASL compliant ways, but could they really show that they had made any effort to mitigate the problem? After all, there's already published voluminous discussion about it in the list archive? So really, what it does boil down to is the PR/credibility aspect of it. For starters, if the ASF ever did have a case in the IP law area (not all unlikely), they opposing side can point to things like this and use it to create an impression of general sloppiness and use it as supporting evidence of a kind. In the public arena, well it just looks bad to knowlingly mess things up. So, that's why it's important that it be fixed, and presumably why the ASF legal team are working on it. So, I think our real options are; 's/-//' and simply delete the latter year entirely. This is minimal change, but assumes that I actually have a clue here and get what the legal issue is. And this hasn't been approved by ASF legal. Migrate to the jackrabbit notice, because at least it has been approved and we judge the inconvience of seemingly slightly adversarial to users less bad than the inconvience of having less credibility in legal matters. Personally, I'd prefer the latter, though I'm also entirely happy to live with the risk/credibility issue of the existing text, this really is hair-splitting hypotheticial territory. -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: [VOTE] 2.0.57 candidate
On Fri, Apr 21, 2006 at 12:39:12PM -0500, William A. Rowe, Jr. wrote: > I don't concur with Colm, the tarball is the release and changing the legal > text is more significant, perhaps, than even the code itself. So it's yet > another bump that strikes me as silly. Just to be clear, I didn't mean it that way. I was going to start an explicit vote on the mailing list for changing the notice-of-license text, accross all branches and future releases, for the sake of efficiency and clarity. But in the last few minutes even more options have emerged that make me question if it's that's sensible, as there's no consensus on what options to vote on. -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: [VOTE] 2.0.57 candidate
On Fri, Apr 21, 2006 at 10:21:18AM -0700, Justin Erenkrantz wrote: > I'm -1 due to the copyright notice changes. A bunch of files > magically added years to copyright notices (i.e. from -2004 to -2006) > when those files didn't actually substantively change during that > period. That's a no-no. We know that now, but those commits went through before it became so clear that our previous practise was so wrong. > Let's just add Jackrabbit's disclaimer and be done with the whole year > thing forever. The best thing of course would be to not have done > anything at all (); but that train left the station when all of > those commits got made prematurely... o.k., I think we can change the notice without a version bump too and without erasing the existing votes, since it's a non-code change, but we should probably have a clear vote on changing the notice, I'll start one now :) -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: What are we doing about...
On Wed, Apr 19, 2006 at 03:34:34PM -0700, Roy T. Fielding wrote: > In any case, it requires great care -- you actually changed at least > one (maybe more) copyright lines belonging to other people, which is > somewhat illegal. I really like all the energy you have going right > now, but we can't do a release until the commits are checked and stuff > like > > --- httpd/httpd/trunk/server/util_pcre.c (original) +++ > httpd/httpd/trunk/server/util_pcre.c Wed Apr 19 05:23:42 2006 @@ -12,7 > +12,7 @@ > > Written by: Philip Hazel <[EMAIL PROTECTED]> > > - Copyright (c) 1997-2004 University of Cambridge + > Copyright (c) 1997-2006 University of Cambridge > > reverted. Argh, I spotted that in srclib/pcre/ and fixed it in trunk, but not the one in server/. in any event this didn't effect the branches as I fixed my dumb regex to be much tighter. -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
[VOTE] 2.0.57 candidate
Candidate tarballs for 2.0.57 are now available for testing/voting at; http://httpd.apache.org/dev/dist/ This doesn't include a changed notice-of-license text though, which is a potential open issue. -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: What are we doing about...
On Wed, Apr 19, 2006 at 08:31:25AM -0700, Justin Erenkrantz wrote: > On 4/19/06, Jim Jagielski <[EMAIL PROTECTED]> wrote: > > Before I t/r 1.3, I'll be updating the files to reflect the > > new copyright. We can determine some better way of doing it > > post-release :) > > No. Please do not update any copyright years. Eek, This has already been done, for trunk and for the 3 branches. > We are only supposed to indicate the year of *first* publication. That won't have changed, so I don't think the update will have caused any harm. > Please let's just stick with what we have until Cliff gives a > definitive ruling. I really would like to get this resolved soon, but > we're also going to be altering the license block as well. (What > Jackrabbit just used is fairly close to what we should use, but I'd > like legal review before we switch all projects to it.) -- justin Out of curiousity, have you got a pointer to what jackrabbit use? -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: Fold mod_proxy_fcgi into trunk (and maybe 2.2...)
On Wed, Apr 19, 2006 at 11:06:56AM -0400, Jim Jagielski wrote: > > +1 on merging to trunk, +0 on 2.2.x. I'd love to see someone actually > > using it for something real before it goes into any release, and at > > this point I'm not sure it has... > > Hence my desire to get it into a branch that people are actively > playing with :) Would an alpha 2.3 release solve that problem? -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: What are we doing about...
On Wed, Apr 19, 2006 at 09:42:29AM +0100, Colm MacCarthaigh wrote:
> > and autofixes them on commit? Is that doable?
>
> I never thought of that, it probably is, I'll take a look.
This can be made work, but we'd have to give a bot karma on the whole
httpd tree.
> > Alternately, if svn can dump us a list of files touched in the present year,
> > we might be able to script that through our usual copyright update pass. It
> > would be a pre-roll process, e.g. we would touch them as we roll a release.
>
> That I like.
"svn -r {DATE}" seems to eat quite a bit of resources on the server side
:/
--
Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: What are we doing about...
On Wed, Apr 19, 2006 at 03:19:39AM -0500, William A. Rowe, Jr. wrote: > Whoa - that's not correct(!) Although the details are tricky, and although > copyright no longer requires 'registration' of the copyrighted material, you > still must claim it or lose it, afaik. (IANAL) Nope, not in any signatory to the Berne convention. The Copyright is the personal property of the author, or the author's employer if the author is acting as an agent of the employer (usually, but that's going into employment law). In most countries, apart from a strict copyright assignment to some other person (in the legal sense, including a company), there is no way to "lose it", very few jurisdictions have the concept of a public domain (the US is an exception here, rather than a rule) and even when they do there is no automatic assignment to the PD just because you fail to "mark" it as copyrighted. So where I live, it's simply impossible to extinguish the copyright, the best someone could hope for is that I publish a covenant saying anything can do anything with it, and that the courts would enforce it as a unilateral contract (C.f. Carbolic Smoke Ball for the common law precedent - it's a fun case to read). That's pretty much how the ASL works here. IANAL either, but I am studying copyright law ;) > >The dates don't matter except as to establish > >a minimum term for the copyright, but the real copyright is related to > >when the author dies - not when the code was written (so we should > >encourage young healthy committers! ;). > > Uhmmm... yes and no, the maximum (not minimum) term is interrelated to the > death of the copyright holder, AIUI. Nope, in all cases where there is one - it's the lifetime of the original author. There are small exceptions, like in the case of automated computer generated works, the term is limited from the time of creation. So, where I live, our "configure" script copyright would last 70 years from the time of creation, rather than 70 years after the death of the last author of configure.in. Otherwise the ownership could keep being re-assigned and the copyright would simply never expire. > Maybe a post-commit that looks at sources for expected patterns, e.g. > /* Copyright - > > and autofixes them on commit? Is that doable? I never thought of that, it probably is, I'll take a look. > Alternately, if svn can dump us a list of files touched in the present year, > we might be able to script that through our usual copyright update pass. It > would be a pre-roll process, e.g. we would touch them as we roll a release. That I like. -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: What are we doing about...
On Wed, Apr 19, 2006 at 12:09:35AM -0500, William A. Rowe, Jr. wrote: > AFAICT, sources are -all- still copyright 2005. That's not right. The 1.3 branch is 2004, and it had a 2005 release ;) > Even if we determine we'll -quit- updating the copyrights until they > are modified, we need to update them when we modify them. Everytime we add a change we are updating the actual copyright. I don't know about policy, but the copyright notice itself doesn't really matter from a legal perspective, it merely serves as a courtesy of where to find potential licensors. The dates don't matter except as to establish a minimum term for the copyright, but the real copyright is related to when the author dies - not when the code was written (so we should encourage young healthy committers! ;). Also there isn't a lack of material which would establish when some code was written. Updating the copyright notice in each file sounds like way too much work :) I hate both the old yearly massive diff, and trying to remember to change the value every time. How about we embed $Date$ and leave it at that? We can either just do something like; /* * Copyright the Apache Software Foundation or its licensors, as * applicable. * * $LastChangedDate$ * * Licensed ... Or include the start date too. Well, by some means, I'm -0 on anything which isn't automated :) -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: [VOTE] 2.0.56 candidate
Since there's little sense in not including the Expect header fix, I'll roll 2.0.57 in 24 hours with that fix in, and potentially a mod_deflate fix too. Also, what are people's thoughts on including sha1 signatures in our official dist? We havn't heretofore, is there any benefit? The PGP signatures are there to confirm veracity, the simple checksums are really only to detect corrupted downloads, but some users do make the md5 = insecure equation very readily. -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: Suggestion to significanlty improve performance of apache httpd
Hey Phil, we're always responsive to such suggestions, but I think we've beaten you to it, at least somewhat, see below for what may be useful resources. On Mon, Apr 17, 2006 at 04:16:45PM -0400, Rodent of Unusual Size wrote: > Much Better Solution: > *** > > * Modify Apache so that the entire header is read before the socket (or > possibly just header data) are passed to an Apache process (kind of like > a lingerd in reverse) Apache httpd 2.2 has support for kernel-level accept filters which do exactly that; http://httpd.apache.org/docs/2.2/mod/core.html#acceptfilter That way the kernel buffers the request until it's ready. > * Modify Apache so that once a worker process has generated the > response data, it passes the socket (or possibly just the response > data) back to a single process to finish off (rather like lingerd > does) See the event mpm; http://httpd.apache.org/docs/2.2/mod/event.html It is still under development, but is relatively stable and functional in non-SSL (or other situations in which input filtering is required) environments. -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: It's that time of the year again
On Mon, Apr 17, 2006 at 10:15:09AM -0700, Garrett Rooney wrote: > Perhaps, but AFAICT infra@ doesn't have this kind of thing lying > around at the moment, so unless someone is going to step up with > hardware people can use it's kind of a showstopper. It's biased towards a single vendor, but SUN are opening up their QA system to any open source projects interested. They have over 1000 boxes of various different specs and some non-Sun OS's too. So that's a potential option. -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: It's that time of the year again
On Mon, Apr 17, 2006 at 12:34:29PM -0400, Rian A Hunter wrote: > I think a SoC project that profiles Apache (and finds out where we > fall short) so that we are able to compete with other lightweight HTTP > servers popping up these days would be a good endeavor for any CS > student. Right now, I'm getting 22k reqs/sec from Apache httpd, and 18k/sec from lighttpd. Simple things like using epoll, or the way the worker balancing is done have huge effects compared to the tiny improvements refactoring code can have. > This seems to be more viable for our threaded MPMs. For the prefork > MPM, maybe a goal for 10,000 connections might be impractical. With prefork I can generally push about 27,000 concurrent connections before things get hairy. With worker, I have a usable system up to 83,000 concurrent connections, without much effort. > I haven't done any benchmarks myself, I've just read results so anyone > correct me if I'm wrong. Dan Kegels page is years out of date, and was uninformed even when it wasn't :) -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: Large file support in 2.0.56?
On Mon, Apr 17, 2006 at 09:09:12AM -0400, Jeff Trawick wrote: > On 4/15/06, Brandon Fosdick <[EMAIL PROTECTED]> wrote: > > I might have asked this before, but I've forgotten the answer, and so has > > google. Has any of the large file goodness from 2.2.x made it into 2.0.x? > > Will it ever? > > Different answer than you got before, but I think this is more accurate > (Joe?): > > Turn on your OS's large file flags in CFLAGS > > make distclean && CFLAGS=-D_something ./configure That works, but does need Joe's split patch; http://people.apache.org/~jorton/ap_splitlfs.diff :) -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
