http-mpm.conf.in versus docs and defaults
Being a new committer and, basically, just a documentation committer, I feel that I must bring this before the dev@ list before proceeding any further. There appears to be a mismatch between the mpm defaults in the configuration and the documentation surrounding it as well as the header definitions. An example is the worker and event mpm, where the configuration defines them so: StartServers 2 MinSpareThreads 25 MaxSpareThreads 75 ThreadsPerChild 25 MaxRequestWorkers 150 However, in both the documentation and the headers, these values can be read or calculated as: StartServers 3 MinSpareThreads 75 MaxSpareThreads250 ThreadsPerChild 25 MaxRequestWorkers 400 From what I can gather with my IRC chats with Igor Galic, this has been discussed quite a while back, and the consensus was to adopt these new values as default, but somehow it did not make it to the http-mpm.conf.in file. I have been asked to change the values in the conf.in file, but I'm very unsure if it is merited, so I therefor ask you, oh great people of the dev@ list, to give me an answer as to whether these new values should be adopted or not. The current stance we have taken in discussions regarding these values is that there is a difference between default configuration value and the default values hard-coded into the server, but it can seem a bit silly to use that explanation at times. With regards, Daniel.
Fwd: Document on developing modules for 2.4 and onwards
As per Igor's advice, I'm forwarding this message to the dev@ and modules-dev@ lists as well: Hello all httpd document lovers, As per our nifty little STATUS document, it came to my attention that we were missing an introductory segment on how to develop simple modules for httpd 2.4, so I took the liberty of drawing up a proposal for what we could put in place for this request. The draft is located at http://httpd.apache.org/docs/trunk/developer/modguide.html and I would much appreciate it if you guys could give me some feedback on whether this will fit in as an, at least for the time being, appropriate document to describe how to develop modules for the server. I plan to expand on the subject, probably add another 10 pages or so, during the summer, as well as letting it into the 2.4 fold, provided I get positive feedback from this mailing list. So, please do read the document and tell me what you think :) Any suggestions, critique etc you might have will be warmly accepted. With regards, Daniel.
Re: Fwd: Document on developing modules for 2.4 and onwards
On 11-04-2012 16:46, r...@tuxteam.de wrote: Nice work, and I bet it'll be helpful for new module authors. Just a small bug: in your example on configuration setting, in the function 'example_create_dir_conf(...)' your code returns 'dir' which isn't declared in function scope. Shouldn't this read 'return cfg;' ??? Cheers, Ralf Mattes Yes, of course it should - fixed, thanks! :) As per the strcpy, it's really not a concern, since the path isn't a file path per se, but instead gets to hold one of two values; Merged configuration or Newly created configuration at this point. But I should probably look at casting properly, yeah, so I'll go fix that next. With regards, Daniel.
Re: [VOTE] Release Apache httpd 2.4.2 as GA
On 15-04-2012 18:36, Guenter Knauf wrote: Am 15.04.2012 13:47, schrieb Noel Butler: On Sun, 2012-04-15 at 13:10 +0200, Guenter Knauf wrote: !--#echo var=REMOTE_ADDR-- Related to the removal of config option DefaultType perhaps? maybe ... however then I would assume that assigning text/html shtml shtm in conf/mime.types should fix it - but it doesnt - at least not for NetWare; and even a ForceType text/html for the directory doesnt work for me, and AddType text/html .shtml doesnt either ... so to me it looks as if either SSI or type assingment is currently broken - at least on NetWare, not yet tested on other platforms ... Gün. I have tested your SSI tag with 2.4.2 on Debian 6 and Fedora 16 with the following options set: Options +Includes AddType text/html .shtml AddOutputFilter INCLUDES .shtml Even without the html tags, this seems to work perfectly on the machines I have tested it on, so it might just be a NetWare issue. With regards, Daniel.
[Vote] Add commentary system to httpd docs
I'll be a bad boy and top-post on this reply, as well as add dev@ to the list of recipients. In docs@, we have been discussing the possibility of adding comments to the various pages in our documentation. As the discussion has progressed, we have settled on the idea of trying out Disqus as a commentary system for the documentation, and I have authored a proposal on the practical implementation of this. As this is a rather large change to the documentation (if passed), Eric Covener advised me to notify both mailing lists as well as give a bit more information on how exactly this will work and why we felt it was a good idea to try out a commenting system. That information is located at http://wiki.apache.org/httpd/DocsCommentSystem We have, to give it a test spin, rolled out these proposed changed to the rewrite section of the trunk documentation, http://httpd.apache.org/docs/trunk/rewrite/ (do note that the mod_rewrite reference document is NOT a part of this test), and we'd very much like you to review these changes and let us know what you think of this solution. If everybody is happy about it, we can try to roll it out on a bit more pages, and see how it is received by the general population. So, I am calling a vote on whether or not to proceed with rolling out this test to a portion of our trunk documentation for further testing. [+/-1] Add commentary system to the trunk documentation. With regards, Daniel. On 03-05-2012 15:54, Rich Bowen wrote: I've long been a fan of the PHP documentation - specifically, the way that they solicit commentary from readers, and then fold that commentary into the docs. Not only did it encourage me to comment on the docs, it also got me involved in the PHP documentation project, at least marginally. The barrier to entry is so low that all you have to do is be a writer. As I've said elsewhere, our process seems to require that you be a programmer. I'd like to see what we can do to change that. This is why the docs@ list was split from the dev@ list in the first place. And it was at least in part why we started doing stuff in a wiki, although that hasn't been nearly as successful as I wished. I'd like to brainstorm about how we can do something like the PHP docs - provide a way for end-users to comment on a given doc, and then have a process for moderating and folding those comments into the docs themselves. The PHP docs team have offered us, on several occasions, their entire documentation infrastructure. I haven't even bothered to mention that to this list, because it would be an *enormous* change. I've discussed it in person with several docs folks, and the response has consistently been, yeah, that would be cool, but it's too big a change. But I'd be glad to have Phil write up something if people are at all interested. I digress. Does anyone know of a way to integrate a third-party comment service like, say, disqus or whatnot, into our docs, so that we could get direct feedback from our audience? Or can you think of another way that we might do this? Shosholoza. -- Rich Bowen rbo...@rcbowen.com mailto:rbo...@rcbowen.com :: @rbowen rbo...@apache.org mailto:rbo...@apache.org
Re: [Vote] Add commentary system to httpd docs
On 04-05-2012 21:04, Igor Galić wrote: [+1] Add commentary system to the trunk documentation. This may be worth a separate thread, but I'll just ask it here, before I forget about it: Any chance we'll see a backport of this to /current/ ? If so, will we display the same comments as in /trunk/ ? So long, i I think the latter question, and others similar to it, needs to be answered before we answer the first one. I've compiled a preliminary list of questions that we should discuss before we start discussing bigger questions like backporting (we've only just begun discussing using it in trunk after all :) ). The questions I've gathered so far can be found at http://wiki.apache.org/httpd/DocsCommentSystem#Questions_for_further_discussion , and when this vote hopefully passes and we start rolling out comment sections to more pages in trunk, I'd appreciate if people would start getting the ball rolling on these questions. They're not life-or-death, as we can always change the options for our comments, but it would be nice to have this all sorted out before we start discussing issues like backporting it. So, give it a read and do let me/us know here on the list what you think about possible solutions to the questions outlined in the Wiki. With regards, Daniel.
[Result] Re: [Vote] Add commentary system to httpd docs
With an impressive 8 x +1 binding votes and no -1's, as well as +2 from other docs@ readers, I believe we can call this vote passed with flying colors :). We will begin rolling out the commentary system in the trunk docs shortly, and then we'll see where the wind of the web takes us. I suspect I'll be following up on this with some discussions on the more specific details of how we should run this comment system later this week, but for now, let's just enjoy it for a few days, and see how it plays out. The current questions we need to discuss can be found at http://wiki.apache.org/httpd/DocsCommentSystem#Questions_for_further_discussion so do give them a read-through and add a question or two if you have any. With regards and humble thanks for your support, Daniel On 04-05-2012 15:58, Daniel Gruno wrote: I'll be a bad boy and top-post on this reply, as well as add dev@ to the list of recipients. In docs@, we have been discussing the possibility of adding comments to the various pages in our documentation. As the discussion has progressed, we have settled on the idea of trying out Disqus as a commentary system for the documentation, and I have authored a proposal on the practical implementation of this. As this is a rather large change to the documentation (if passed), Eric Covener advised me to notify both mailing lists as well as give a bit more information on how exactly this will work and why we felt it was a good idea to try out a commenting system. That information is located at http://wiki.apache.org/httpd/DocsCommentSystem We have, to give it a test spin, rolled out these proposed changed to the rewrite section of the trunk documentation, http://httpd.apache.org/docs/trunk/rewrite/ (do note that the mod_rewrite reference document is NOT a part of this test), and we'd very much like you to review these changes and let us know what you think of this solution. If everybody is happy about it, we can try to roll it out on a bit more pages, and see how it is received by the general population. So, I am calling a vote on whether or not to proceed with rolling out this test to a portion of our trunk documentation for further testing. [+/-1] Add commentary system to the trunk documentation. With regards, Daniel.
Re: [VOTE] CMS site migration
On 08 May 2012, at 9:14 PM, Joe Schaefer wrote: Please cast your vote accordingly: [X] : +1 to migrate httpd-site to the CMS Since I'm the evil munchkin behind a lot of this, I should probably vote as well. So there :).
Re: svn commit: r1339313 - in /httpd/httpd/trunk/docs/manual/rewrite: access.html.en advanced.html.en avoid.html.en flags.html.en htaccess.html.en index.html.en intro.html.en proxy.html.en remapping.h
On 05/17/2012 07:53 AM, Kaspar Brand wrote: -1, please revert. Before starting to track users on httpd.apache.org with GA, I would expect two things to happen: a discussion/vote on httpd-dev (as was the case for the commentary system) and - provided that the vote passes - having a privacy policy for the HTTP server project in place [1]. Lack of the latter is a blocker even for tiny changes to http://httpd.apache.org/docs/trunk/ right now, which is the primary reason for my veto. My intentions were indeed to have a vote about this, and the small portion of tracking that I rolled out was never intended as more than a small one-day test to see if we could get it set up and working, since there seemed, at the time, to be no objections on doing it. I'm sorry if this seemed rash, and I have reverted it back to what is was before. One has to learn how to walk the line between voting on issues or just doing it, and I completely acknowledge your reasons for the -1 - lesson learned :) Since I still feel that this is something we could benefit from, I will report my message to docs@ below, so the dev@ people can have a look as well: I've been wondering for some time now, how we can improve the site to give the users a better experience and a faster flow from question to answer. In that search, the question of doing a proper facts-based analysis keeps popping up. What I would essentially like is to be able to look at the flow that happens from when a users has a problem till he/she finds a solution in our documentation (or on our IRC channel or mailing list). We should, as documentation writers, have some idea of whether our efforts are fruitful or not, and whether we can improve pages A, B or C to make it easier for users to search for an answer and find it, but without some form of log files or analytics tool, this becomes quite hard, if not impossible. I would therefore like to propose that we implement some form of anonymous analysis snippet on our documentation, so that we can figure out some facts: - What are users generally searching for when they wind up on our pages? - Which flow of content occurs when a user browses through the docs, looking for answers to problem A, B or C? Do they go through the guide as we intended for them to do, or do they pick a different path, and if so, why? - What are people generally reading about? Which pages are the most popular, and which are almost never touched (and does this reflect our own ideas of which pages are the most useful in various scenarios)? I believe that if we had these facts sorted out, we could more easily work towards improving our documentation and help people reach the answers to their questions faster. I'm looking forward to suggestions, comments and critique as always Also, if people know of some good ways to accomplish this, specifically which tools we could use, I'd appreciate some insight into that as well. -- With regards, Daniel.
Re: [Result] Re: [Vote] Add commentary system to httpd docs
Sending to docs@ as well, as this applies to that list too. Grumpiness may occur, so apologies in advance. On 05/19/2012 09:32 AM, Kaspar Brand wrote: Looking at the call for votes [retained below for reference] and at the votes, I'm not sure if the +1 voters were aware of the specific mechanics of the Disqus comment system which is now embedded into all HTML below http://httpd.apache.org/docs/trunk/ [1], however. The vote did refer to a proposal on the apache wiki that specifically mentioned Disqus as the method of choice. If people were unaware of how Disqus operates then, frankly and with respect, they should aim to work with due diligence or ask questions before voting. It should be a well known fact that using third party tools will eventually result in visitor tracking occurring one way or another. If people would rather see us use a comment system developed and housed by Apache, then I'm sure we can figure something out, but it requires that people say so. Effectively, using Disqus means that even visiting an innocent page like http://httpd.apache.org/docs/trunk/license.html will already result in all sorts of drive-by tracking requests [2], among them Google Analytics (pulled in via httpd.disqus.com/thread.js). Based on the fact that there's currently no privacy policy for httpd.apache.org - which would make visitors aware of being tracked (and link to both the Disqus privacy policy [3] and the GA privacy policy [4]) - I believe that the vote should be repeated, with being recast to: [+/-1] Add the Disqus commentary system to the trunk documentation. Meh, it makes me a sad panda that we have to discuss this once again, but you may have a point here. I suppose it would be in the Apache spirit to keep our intentions as open as possible, which merits a privacy policy. I have already written up a draft for such a policy, and included the GA and Disqus techs used in the proposed comment system and analytics for the docs. It can be found at http://wiki.apache.org/httpd/PrivacyPolicy . It is loosely based on the policies that are in place for other Apache projects such as Lucene and Directory (which also makes use of GA on their sites). This will effectively make for two (or three) new votes for adopting each piece: - Adopt a privacy policy for the docs and refer to the various tracking methods used as they get implemented - see the draft at http://wiki.apache.org/httpd/PrivacyPolicy - Implement the Disqus commentary system for the docs - see the proposal at http://wiki.apache.org/httpd/DocsCommentSystem - Implement visitor tracking for the docs so we can improve on them - see proposal at http://wiki.apache.org/httpd/DocsAnalyticsProposal I'll let this sink in for a few days, and then I will propose a vote for each segment in the order displayed above. If any of you have comments, suggestions, critique, anything, I urge you to please step forward and say so. I dislike the illusion of consensus just because people can't be bothered speaking up until something is actually committed to the repository. As an interim measure, I also think it would be wise to revert the changes applied in r1335029/r1335773, for the time being. We have already voted on adding _a_ commentary system to the documentation, so I'm not going to revert all the blood, sweat and tears that went into integrating a comment section in the docs, but what I can and will is add a JavaScript hack to disable the Disqus commentary system itself while we get this sorted out. Regardless of which method of commenting we eventually settle on, it will still require the same basic structure as is defined at the moment, so I see no point in scrapping all of it, just to reinstate it again. With regards, Daniel.
Comment system, take two
In light of recent concerns about the Disqus system, I've taken it upon myself to figure out an alternative we can use for adding comments to our pages. And so, through the better half of a day, I worked on creating a new system that is without any evil tracking mechanisms of any sort except for what people themselves will allow - that is, only information that is willingly entered will be stored, no IPs or such. The result (thus far) can be seen at a small test page I made for the http project at http://c.apaste.info/httpd.html - feel free to give it a test spin and see what you like. Quick primer: Click on add a comment to add a comment, or click on reply to add a reply to an existing comment. You can use the log in link to the far right to create a permanent account which will save you the trouble of having to type your name/email whenever you want to make a new comment. People that register an account can also be added as moderators/admins, and thus delete posts as they see fit. Furthermore, moderators receive notifications when a new comment has been made on a page, and can thus quickly react if something needs deleting. There is a small touring test in action when you submit a comment, so automated spamming should not be a huge problem. So, basically the same stuff as we had with Disqus, albeit on a smaller, less fancy scale and without a big disclaimer. If there are no objections, I intend to try this commentary system out on a portion of the trunk tomorrow, and then we'll wrap up with some QA on the ML to get the last few things sorted out, and finally vote on the matter sometime soon. Should any committer wish to become a moderator (not that there's a whole lot to do), just reply on the ML and you'll get added if you've created an account. With regards, Daniel.
Re: Comment system, take two
On 05/22/2012 11:25 PM, Rainer Jung wrote: I like it. +1 Concerning production readyness, some points come to mind: - Did you pay attention on escaping problematic input? I saw some escaping, but didn't thoroughly test it. We don't want XSS and such. Yes, because the text is inserted using Document.CreateTextNode, all that is injected is pure text - HTML tags and the likes should not be possible to inject in any way other than as pure text. Special tags like , , \ etc are escaped in advance, but this is just so it will display the characters and not make them invisible. No HTML should be injectable. - Is there some safety against brute force password hacking for the registered people, especially the moderators? E.g. locking accounts after a few wrong passwords. Yup, more than 5 bad attempts will start making it difficult for you to try logging in. - Since we want to host it later inside ASF infra: what are the infra requirements? It seems the server part is written in Lua? Is it based on httpd 2.4 with mod_lua, or just Lua in CGI scripts or similar? Gee, what gave it away? ;) Right now it's written in Lua yes (should anyone be interested in the source code, I'd be happy to provide a link to it), and run on 2.4.2 with mod_pLua (a distant cousin to mod_lua that offers me a bit more flexibility as well as access to POST data*hint hint*). One of the nice things about writing it in Lua is that it is quite easy to port it to other languages such as php or perl, should this be needed. The scripts themselves are quite small, since most of the work is done via JavaScript. I have already asked Tony if we could host this on httpd.a.o, and the answer was a kind no since it would require enabling php or mod_plua for the site, which would either (in the case of plua) be something new and untested or (in the case of php) bloat up the server. So, while we get all that sorted out, I'm more than happy to host it myself. Having said that, it would indeed be nice if we could find somewhere on infra where this could be hosted, so we could also share the tool with other sites wishing to incorporate comments in their system. Thanks! Rainer - To unsubscribe, e-mail: docs-unsubscr...@httpd.apache.org For additional commands, e-mail: docs-h...@httpd.apache.org With regards, Daniel.
Re: Comment system, take two
On 05/23/2012 09:15 AM, Tony Stevenson wrote: I said running php on the main webservers would very likely with a no, I didnt say it would do that. If the service doesnt have to run on the same vhost as the main httpd.a.o site then we could run the service elsewhere in our infrastructure. Sorry, yes, what I meant to say was that hosting on httpd.a.o would likely be a no, which is completely fine, as it doesn't need to be hosted in any specific location. I've talked to Joe this morning about the possibility of setting up a place within the Apache space for hosting it in the future, once the remaining kinks have been sorted out. I'll keep people apprised of how this progresses. I've also updated the wiki entry on the comments proposal ( http://wiki.apache.org/httpd/DocsCommentSystem ) to reflect the changes going on. Last but not least, I've rolled out the system to the entire trunk (so there's no more comments disabled notices), so let's see how things work out :) With regards, Daniel.
Re: Comment system, take two and a half
Most of the kinks in the new comment system have now been sorted, as has most of the question on the actual implementation of it. However, a few questions remain, that I'd like some input on if possible: - Should we keep the various translations separate, or should it be one unified commentary? i.e. should the French pages separate comments from the English pages, or should they all just roll with the same comments? We could insist that all comments be made in English unless they are related to a specific translations, and as long as we keep the translations up to date with the suggestions and delete comments as they are implemented, there shouldn't be much clutter. - When this moves to 2.4 and possibly 2.2, should we keep each branch separate, or should we unify it? That is, should f.x. core.html show the same comments for 2.2, 2.4 and trunk combined, or should they be kept separate? I'm leaning towards the latter myself, as a lot of pages really have changed quite a bit, and it'd become confusing if someone is suddenly commenting on a 2.2 issue and it shows up in the 2.4 docs. Any input would be greatly appreciated. With regards, Daniel. On 05/23/2012 08:07 PM, Daniel Gruno wrote: Since people have begun talking about the idea of hosting/using this system within the ASF, I've added some more kinks to the system now. Those of you who have created an account (or those who create one and let me know) will now see a moderate link when they are viewing comments while logged in. This will take them to a new moderator site, where it's possible to track the latest activity, delete threads and track specific origins (origin tracking only applies to posts made after I revamped the moderator system, so old posts can't be tracked). An origin is basically a digest of an IP address (to both preserve the privacy policy and get rid of any trouble with IPv4/IPv6 mingling), and it allows you to either ban an origin from posting, view and delete any comments made by that origin or simply nuke everything ever posted by that origin. You can also opt in or out of receiving email notifications when a new post is being made (and opting in/out on a specific page is in the works). If you like, you can also register new sites to be used with the comment system. If you want to test out the features, be my guest and spam away on the trunk pages, so you can nuke your own origin to bits :) If this moves to infra, the plan is to use the committer IDs as your new login, so all committers essentially become moderators, but will still have to opt in in order to receive email notifications of new posts on the site (unless it's a reply to their own post, in which case they'll get a reply anyway) With regards, Daniel. - To unsubscribe, e-mail: docs-unsubscr...@httpd.apache.org For additional commands, e-mail: docs-h...@httpd.apache.org
Re: Comment system, take two and a half
On 05/28/2012 09:38 PM, Gregg Smith wrote: Each branch different, 2.2 2.4 have some big differences between them in various areas. My 2 cents anyway. What I'm perhaps more curious to get sorted out is whether we should consider the trunk and the 2.4 documentation separate entities, or whether they should be linked, comment-wise. Currently, they are pretty much identical, but in the future it may be a good idea to keep them separate as we move towards 2.5/2.6. With regards, Daniel.
Re: [PATCH] mod_log_forensic security considerations
On 06/08/2012 12:13 PM, Graham Leggett wrote: On 08 Jun 2012, at 12:16 AM, Daniel Ruggeri wrote: I share Williams concern that this makes mod_forensic potentially less useful. Maybe making the forensic log mode 600 by default would be a better idea? Agreed as well. This module isn't enabled by default and is most likely to be enabled by a user that knows what they are trying to accomplish. To me, a clear and concise security warning in the documentation should be all that is needed. IMO, having unadulterated logging capability is what makes mod_dumpio/mod_log_forensic some of the most useful modules for troubleshooting in a proxy/crashing scenario (respectively). +1. Regards, Graham -- +1 to that. We already have the same kind of warnings in place for people setting up proxies, I see no reason why we can't do the same to mod_log_forensic. The module is, as the name says, for forensic logging, so it should be expected that as much as possible is logged by default, and any special considerations should be something you could change, but it shouldn't be the default behaviour to not include this and that because it may be potentially unsafe. We got bit by it, yes, but that was because we made the logs available to people, and that's what we should warn about if anything. With regards, Daniel.
Re: [PATCH] mod_log_forensic security considerations
On 06/08/2012 05:45 PM, Joe Schaefer wrote: Well not quite, we'd still have had a problem with storing and archiving those logs even if we hadn't made them available to committers, because they violate our password retention policies. My point was, that it should fall upon us to add a filter if we want to archive our logs with certain forensic details omitted, and not be a default assumption that people want forensic logs but not this, this and that stored. Thus, I'd be more in favor of either piping it through a filter or adding something like ForensicLogFilter option [,option...] With regards, Daniel.
Bugzilla and 2.4.2
As Stefan has pointed out on our dev IRC channel, we do currently not have a version entry for 2.4.2 in the bugzilla db. Can someone please fix this? With regards, Daniel.
Comment system, take three
As Professor Farnsworth would say; Great news everyone! Some time ago, I proposed we use a comment system for our trunk branch, that I had been developing for our site. This system has been tested during the entire month of June, and received 11 actual comments (not counting the 110 test comments made by committers) and no spam whatsoever. The serious comments have already led to documentation changes, which I'd like to say is a success, considering how few people actually read and use our trunk docs. The comment system has now been adopted by the ASF and is available at https://comments.apache.org - the documentation has already been changed to use this new service instead of the old site. Some time soon, this will be hooked up to LDAP, enabling any Apache committer to log on and moderate comments. The wiki article at http://wiki.apache.org/httpd/DocsCommentSystem has been updated accordingly. Once LDAP is set up (hopefully some time this weekend), I will propose a vote to add the comment system to both the 2.2 and the 2.4 branch of our documentation, so please read up on the proposal (in the wiki article) and try out posting comments and moderating them (once LDAP is set up). If you can't wait for committer authentication, you can still manually create an account and I can make you a moderator. This will only last till LDAP is set up, at which point you will have to use your committer id/password. So, read, test, manage, and I'll propose a vote as soon as we've got the system all set. With regards, Daniel.
[VOTE] Adopt the comments.a.o system to the 2.2 and 2.4 branch of the httpd docs
After many an attempt, we now have LDAP authentication for comments.apache.org set up, and the comment system is ready to roll. Any committer that wishes to moderate comments can now do so using their Apache credentials. With that in order, and with the comment system already tested in our trunk branch (as well as on the Apache Traffic Server site), I would propose that we also adopt this new system for the 2.2 and 2.4 branch of our documentation, so we can get some useful comments from the majority of people who don't normally visit the trunk docs. Voting will last the usual 72 hours, standard majority consensus applies. If you haven't already, I suggest you try out the system by either posting a comment somewhere or by logging onto the moderator control panel and familiarizing yourself with it. [ ] +1: Adopt the comments.a.o system in the 2.2 and 2.4 branch of docs [ ] 0: I don't care [ ] -1: Don't adopt the system, because With regards, Daniel.
Re: [VOTE] Adopt the comments.a.o system to the 2.2 and 2.4 branch of the httpd docs
On 07/08/2012 10:33 PM, Daniel Gruno wrote: [X] +1: Adopt the comments.a.o system in the 2.2 and 2.4 branch of docs [ ] 0: I don't care [ ] -1: Don't adopt the system, because Forgot to cast my own vote - so there.
Re: [VOTE] Adopt the comments.a.o system to the 2.2 and 2.4 branch of the httpd docs
On 07/09/2012 09:24 AM, Issac Goldstand wrote: On 09/07/2012 01:12, Mads Toftum wrote: On Sun, Jul 08, 2012 at 10:33:56PM +0200, Daniel Gruno wrote: [ ] +1: Adopt the comments.a.o system in the 2.2 and 2.4 branch of docs [ ] 0: I don't care [X] -1: Don't adopt the system, because Only trunk is CTR. Can you explain the rationale of that veto? Let me reiterate, in case I was being vague earlier on: This is a _majority_ vote issue just like with releases (and like we did with adopting the CMS system for our site), there is no veto, just +1, 0 and -1. I can, to some extent, understand Mads' reasons for voting -1, but I'd also like some elaboration, so I don't get the wrong impression. Personally, my rationale for adopting it to 2.2 and 2.4 is that _people will use it_ there, which is what we want. I have described this in the wiki proposal a while ago, at http://wiki.apache.org/httpd/DocsCommentSystem and I had really hoped that all the pros and cons had been discussed by now. With regards, Daniel.
Re: [VOTE] Adopt the comments.a.o system to the 2.2 and 2.4 branch of the httpd docs
On 07/10/2012 11:14 PM, Stefan Fritsch wrote: On Sun, 8 Jul 2012, Daniel Gruno wrote: [ ] +1: Adopt the comments.a.o system in the 2.2 and 2.4 branch of docs [ ] 0: I don't care [ ] -1: Don't adopt the system, because I am +1 in principle, providing that some issues are fixed: Currently, it is possible to make comments.a.o send mail to arbitrary recipients because the email addresses are not verified. IMHO comments.a.o should only send mail to addresses that have been verified. This would mean that the email notification service would require an account. Also, it may be problematic that URLs that lack the protocol part (e.g. www.spam-now.com) are accepted. But it may be enough if such spam comments are removed by the moderators (at least if the mail address problem is solved). Cheers, Stefan Thanks for your input, Stefan. I've added a check that will only allow registered users to be notified when someone replies to their comments. We also discussed email confirmation checks on IRC, and I will look into that tomorrow, as well as probably start a new thread on the ML for future suggestions to the comments system. We can enable/disable these features at any point in the future, if it becomes a hassle or any such thing. With regards, Daniel.
Re: [VOTE] Adopt the comments.a.o system to the 2.2 and 2.4 branch of the httpd docs
On 07/11/2012 08:24 AM, Kaspar Brand wrote: On 08.07.2012 22:33, Daniel Gruno wrote: [ ] +1: Adopt the comments.a.o system in the 2.2 and 2.4 branch of docs [ ] 0: I don't care [ ] -1: Don't adopt the system, because Thanks for enduring your work on this - glad to see that it has become comments.a.o. in the meantime! I'm in favor of enabling it for 2.2/2.4, generally speaking, but am having some concerns with regard to the proposed approval policy: it changed from the Comments will be moderated by appointed moderators to Comments will, in general, be allowed through without pre-approval. Comments with hyperlinks in them will require approval from a moderator before they are shown on the site [1]. Auto-approval of comments makes me feel somewhat uneasy - on the one hand, there's the risk of inappropriate/incorrect content appearing on httpd.apache.org and going unnoticed for some time, and on the other hand, this means that input validation (Name and Comment fields in particular) has to be very tight... is http://c.apaste.info/source/add_comment.lua the current version of the code which validates the input? (If so, it's e.g. missing checks for https URIs, and at least at first sight, I couldn't spot any further checks on the POST input you're processing [the site, page, thread variables etc.].) Kaspar [1] http://wiki.apache.org/httpd/DocsCommentSystem?action=diffrev1=6rev2=7 Hi Kaspar, No, I haven't updated that source repository since we moved it all to the infra SVN repo about a month ago. It is now in place at https://svn.apache.org/repos/infra/infrastructure/trunk/projects/comments/ and has been rewritten extensively. names and comments are checked for http(s) schemes, size (no more than 2500 characters allowed) and so on, and while comments require approval if a hyperlink is found that doesn't point to an official apache web site, names with hyperlinks are flat out denied. I think the general idea has, from the start, been to allow for comments to go through without pre-approval, at least for a period so we can see if that's what we want. If we later on decide that all comments needs approval before they are shown, then fine, we'll do so. The system is geared to respond to a lot of different wishes from different projects, for example, some may choose to enable Gravatar avatars for their comments, while others may not (this is not enabled for the httpd site by the way ;) ). As for comments going unnoticed, we currently have four people who automatically receive an email when someone posts on the site and we have the option to add *every single Apache committer* to this list of people moderating our site, so I think any 'bad' comments will be spotted rather fast and removed. We also have other options up our sleeves: 1) We can require that all posters be registered users first 2) We can ban the sorry people that try to spam out site 3) We can temporarily disable comments on the fly if something goes wrong I hope this answered your concerns, and if you have any other suggestions for how our little part of comments.a.o should work, please do say so, and I'll see if I can figure out a way to make it work. With regards, Daniel.
Current configuration of httpd site on comments.a.o
As to not clutter the vote with too much stuff, I'm posting a new thread here with some more in-detail information about how the httpd project is set up on comments.apache.org, and what will happen if the vote passes tonight: = Options that are enabled: = - Users have to register an account and validate their email in order to receive reply notifications (thanks for this idea, Stefan) - HTML is NOT allowed - Comments cannot be longer than 2,500 characters. This should be enough to write a couple of paragraphs and show some configuration examples. - Names cannot contain links - Comments that contain links other than those pointing to *.apache.org are flagged as 'not approved' and will need to be approved by a moderator before showing up on the site = Options that are not enabled, but can be: = - Posting a comment can require a registered account - Users can use Gravatar avatars next to their comments - Posting new comments can be disabled - Showing comments can be disabled Non-committer moderators Users that are not committers can be permitted to moderate our site. This can be a great way to allow new people to be semi-committers without having to actually invite, vote and set them up as committers just yet. Currently, we have one user, Sling (Mathijs) set up as a moderator for the httpd site, and I have full confidence that he'll do an excellent job, just as he is doing, helping out on our IRC channel. == Integration of comments.a.o into the docs: == Once the voting is done, and provided the vote passes, I will start integrating the comments system into the 2.2 and 2.4 branch. I won't be doing it tonight, but rather tomorrow when I am satisfied that any remaining kinks in the system has been dealt with. By holding off till tomorrow, we should have a fresh set of eyes on the launch, in case we start receiving many comments. I will start by adding the system to the 2.4 branch, and let it work for a day or two before adding it to the 2.2 branch, as 2.4 presumably has less traffic and thus would be easier to fix should anything be off about the system. If there are any other concerns or just curiosities, by all means, reply to this email and we'll discuss them in this thread. With regards, Daniel.
[Result] [VOTE] Adopt the comments.a.o system to the 2.2 and 2.4 branch of the httpd docs
The votes are in: +1: 9 (humbedooh, joes, issac, rpluem, druggeri, rjung, lgentis, sfritsch, rbowen) 0: 0 -1: 1 (mads) As this is a majority vote issue, the vote has passed and the integration of comments.a.o into the 2.2 and 2.4 branches will begin tomorrow (that is, 2.4 will start tomorrow, 2.2 will probably be Friday). We have a new feature on comments.a.o which is support for mailing list notifications, and I think that it might be a good idea for us to consider whether we should either create a separate mailing list for people who wish to follow new comments on the sites, or whether we should simply plug it into one of our existing lists, such as docs@ - ideas are welcome :) As with my previous letters, I encourage those of you who haven't tried out the comment system to take a glance at it, post an example comment in the trunk or check out the moderator panel. With regards, Daniel.
LuaSet: good or terrible idea?
Dear dev@, I've been looking into mod_lua for some time now, and have created an external library with lot of functions that make use of the AP/APR C API (such as ap_expr calls, scoreboard reading, sha1/md5/b64 functions, dbd and sendfile support etc). While doing so, I've also thought about how to improve mod_lua itself, but I now find myself doubting my own reasoning for committing a directive to the code. The directive would/could be called LuaSet, and would set a variable that is only accessible through Lua, much like mod_perl has PerlSetVar, and mod_php has...whatever it has. The idea was that you could do something like: LuaSet foo on Location /nothere LuaSet foo off /Location and then retrieve that value inside your Lua scripts using something like r:parseenv() to get a table of Lua-specific values that applied to that scope. However, this could also be managed by using SetEnv or SetEnvIf (if you hook something real early) and then fetched through r.subprocess_env. So the question is; Should I bother committing this directive, or is it just a redundant function? On the plus side, it makes it easy in the configuration to spot Lua specific values and ensures that it doesn't clash with other env variables that might have been set, and on the other hand, one could just do something like SetEnv Lua_foo on. So what say you, is it a good or a terribly redundant idea? With regards, Daniel.
Re: Fwd: svn commit: r1367725 - /httpd/httpd/trunk/modules/lua/mod_lua.c
On 08/01/2012 08:38 AM, Rüdiger Plüm wrote:
Original Message
Subject: svn commit: r1367725 -
/httpd/httpd/trunk/modules/lua/mod_lua.c
Date: Tue, 31 Jul 2012 19:43:30 GMT
From: humbed...@apache.org
Author: humbedooh
Date: Tue Jul 31 19:43:29 2012
New Revision: 1367725
URL: http://svn.apache.org/viewvc?rev=1367725view=rev
Log:
mod_lua: Add the (missing) LuaMapHandler directive to the fold.
This should work as the existing documentation describes.
Modified:
httpd/httpd/trunk/modules/lua/mod_lua.c
Modified: httpd/httpd/trunk/modules/lua/mod_lua.c
URL:
http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/lua/mod_lua.c?rev=1367725r1=1367724r2=1367725view=diff
==
--- httpd/httpd/trunk/modules/lua/mod_lua.c (original)
+++ httpd/httpd/trunk/modules/lua/mod_lua.c Tue Jul 31 19:43:29 2012
@@ -170,6 +170,35 @@ static ap_lua_vm_spec *create_vm_spec(ap
return spec;
}
+static const char* ap_lua_interpolate_string(apr_pool_t* pool, const
char* string, const
char** values)
+{
+char *stringBetween;
+const char* ret;
+int srclen,x,y;
+srclen = strlen(string);
+ret = ;
+y = 0;
+for (x=0; x srclen; x++) {
+if (string[x] == '
x != srclen-1 string[x+1]= '0'
string[x+1]= '9') {
+if (x-y 0) {
+stringBetween = apr_pstrndup(pool, string+y, x-y);
+}
+else stringBetween = ;
Style. Please review the style guide (code should be on the next line)
+int v = atoi(apr_pstrndup(pool,string+x+1, 1));
As this is only one digit you can convert directly, e.g. *(string+x+1) -
'0' and avoid
copying the string.
+ret = apr_psprintf(pool, %s%s%s, ret, stringBetween,
values[v]);
As you only concat strings here use apr_pstrcat here.
+y = ++x;
+}
+}
+
+if (x-y 0 y 0) {
+stringBetween = apr_pstrndup(pool, string+y+1, x-y);
+ret = apr_psprintf(pool, %s%s, ret, stringBetween);
As you only concat strings here use apr_pstrcat here.
+}
+else if (y==0) return string; /* If no replacement was made, just
return the original
str. */
Style. Please review the style guide (comment should be on a separate
line, code on the next line)
+return ret;
+}
+
+
Regards
Rüdiger
Thanks for the heads up :)
This also made me discover a bug in the string interpolation function,
that kept the number (fx 1 in $1) instead of discarding it in the
replacement string.
With regards,
Daniel.
Additional core functions for mod_lua
Hi dev@, I've gotten my paws all over mod_lua as of late, trying to find ways to expand the module to be more useful. In doing so, I have created a small library which binds several httpd core functions (and some from apr) to Lua, so as to both gain more control over httpd via mod_lua as well as gain access to some of the many useful components included in our server by default. The library, and its reference docs can be found at http://people.apache.org/~humbedooh/lua_ap/ and while it's easy to just compile it and thus use its functions, I was thinking maybe we should include some of them as core functions in mod_lua itself. Specifically, I am leaning towards functions such as the flush function (for flushing the output buffer) and possibly either the base64 encode/decode functions or the get_basic_auth_pw function, so mod_lua has access to both username and password in its auth hooks without having to reinvent the wheel. This would also make it easier to write example scripts for many of our hooks. Other functions might be useful to include as well, so if any of you have some free time to explore the reference document, please have a look at the possibilities, and if you spot something you think would be useful as a core function, please reply and let me know. For an example of what you _could_ do with mod_lua, I have used this library to recreate mod_status in Lua, at http://www.apaste.info/server-status/ Other possibilities like making a Lua version of mod_vhost_alias (which could be expanded upon and do complex logic) also exist, but they don't show very well since they run in the background With regards, Daniel.
Re: svn commit: r1367504 - /httpd/httpd/trunk/modules/lua/mod_lua.c
On 08/03/2012 04:47 PM, Stefan Fritsch wrote: On Tue, 31 Jul 2012, humbed...@apache.org wrote: Author: humbedooh Date: Tue Jul 31 11:47:04 2012 New Revision: 1367504 URL: http://svn.apache.org/viewvc?rev=1367504view=rev Log: mod_lua: The current way of getting the authz provider name doesn't seem to work. This approach should fix that. Modified: httpd/httpd/trunk/modules/lua/mod_lua.c Modified: httpd/httpd/trunk/modules/lua/mod_lua.c URL: http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/lua/mod_lua.c?rev=1367504r1=1367503r2=1367504view=diff == --- httpd/httpd/trunk/modules/lua/mod_lua.c (original) +++ httpd/httpd/trunk/modules/lua/mod_lua.c Tue Jul 31 11:47:04 2012 @@ -1006,8 +1006,7 @@ static const char *lua_authz_parse(cmd_p const char *provider_name; lua_authz_provider_spec *spec; -apr_pool_userdata_get((void**)provider_name, AUTHZ_PROVIDER_NAME_NOTE, - cmd-temp_pool); +provider_name = (const char*) ap_getword(cmd-temp_pool, cmd-directive-args, ' '); ap_assert(provider_name != NULL); spec = apr_hash_get(lua_authz_providers, provider_name, APR_HASH_KEY_STRING); Huh? I am very sure that I have tested this. In which configuration did it not work? And does your code work with negation like Require not foo bar? If your change is kept, the corresponding code in mod_authz_core should be removed, too. And the ap_assert() can't trigger anymore. But I think passing as pool userdata is preferable. Sorry, that was my bad. It seems I hadn't checked out the latest version of the auth core when I tested this, so I was effectively testing against the 2.4.2 version of it, which is why it failed. I had planned to write to the list (after I noticed the change) and ask about whether my fix was something that would normally work, or whether there was a reason why you had made the change in the auth module, but I got a bit sidetracked by my attempt to make a server scope for mod_lua, which made my head hurt a bit. Feel free to revert my changes if your way is better :) With regards and apologies, Daniel.
Re: Additional core functions for mod_lua
On 08/03/2012 04:51 PM, Igor Galić wrote: Right now, is your library meant to be linked with mod_lua or does it work with LoadFile? It's a Lua library, so it doesn't involve httpd per se. It would be included by mod_lua (or rather, by Lua) by writing the following in your script: local ap = require aplua function handler(r) ap.somestuff(r) -- do some AP stuff here end If you were planning to integrate it into the httpd project, would you as above, or would it become part of mod_lua? (From what I gather, it wouldn't make mod_lua more bloated) The only bloat you'd get is the extra microsecond it will take to register the functions in Lua. All the functionality is yanked straight from httpd (which has already loaded apr, pcre etc itself), so there's no additional memory use by including them. The only concern, if you will, is that there will be more functions to document. Finally, I'd like to say that all the httpd stuff is probably fine, the APR stuff though is a) Not namespaced as apr, and might be misplaced. I'm probably not competent enough to comment on this one, though. Yes, we could create a global table, ap, for the ap stuff, and apr for the apr stuff, or just make a table for apr, and have the rest registered within the request_rec table. I cannot seem to be able to find this stuff… The other examples I mentioned will be available in the developer docs, as soon as I've finished making it somewhat organized. With regards, Daniel.
Re: Additional core functions for mod_lua
On 08/03/2012 04:51 PM, Igor Galić wrote: I cannot seem to be able to find this stuff… I have put together some of the scripts I use myself at http://httpd.apache.org/docs/trunk/developer/lua.html but it's far from done (and thus not linked to from any index page). Most of the scripts are there, but I have yet to add actual explanations to the various examples as well as add the map handler examples and some other things. This page also holds all the functions that I have proposed to import into mod_lua (unless someone objects to specific functions), so this should answer Eric's question about documenting the functions as well. I have chosen to add the functions to the existing apache2 library, since the name makes sense. If there are no objections, I'll consider it a lazy consensus :) With regards, Daniel.
Re: Additional core functions for mod_lua
On 08/06/2012 12:17 AM, Stefan Fritsch wrote: On Sunday 05 August 2012, Daniel Gruno wrote: On 08/03/2012 04:51 PM, Igor Galić wrote: I cannot seem to be able to find this stuff… I have put together some of the scripts I use myself at http://httpd.apache.org/docs/trunk/developer/lua.html but it's far from done (and thus not linked to from any index page). Most of the scripts are there, but I have yet to add actual explanations to the various examples as well as add the map handler examples and some other things. This page also holds all the functions that I have proposed to import into mod_lua (unless someone objects to specific functions), so this should answer Eric's question about documenting the functions as well. I have chosen to add the functions to the existing apache2 library, since the name makes sense. If there are no objections, I'll consider it a lazy consensus :) Nice work. If you talk about the existing apache2 library, you mean it is existing in mod_lua? Or is it an external file? There is some overlap with the r table: These already exist: apache2.context_document_root apache2.context_prefix apache2.add_output_filter These can be done wit r.subprocess_env: apache2.getenv apache2.setenv (though subprocess_env could use an abbreviation). I may have missed some others. Wouldn't it make sense to add those new functions which are really related to the request (as opposed to just using the request pool) to the r table, too? Some other random notes: apache2.requestbody: This should take a size limit as argument. apache2.get_server_name: The example and the synopsis don't agree if this should have an argument apache2.get_server_name_for_url: This is missing but would be very useful. apache2.satisfies: This is obsolete, and should IMHO be removed. apache2.getenv/setenv: call them request environment variable in the docs, to distinguish from OS environment variables Cheers, Stefan Yes, you caught some thing that I should have mentioned. The redundant functions you mentioned have been scrapped, it is simply because I'm generating the source for the xml doc via xslt, and I haven't gotten around to change the original xml file just yet (I've been painting :3). I'll get some sleep and fix up the docs tomorrow, including some mislabelled return values and parameters. As stated, this is a work in progress. As for the requestbody, satisfies etc functions, it's been noted and I'll see to it that they get changed/removed/fixed before I start committing anything. With regards, Daniel.
Re: Fwd: svn commit: r1369656 - in /httpd/httpd/trunk/modules/lua: lua_vmprep.c lua_vmprep.h mod_lua.c mod_lua.h
On 08/06/2012 09:23 AM, Rüdiger Plüm wrote:
Original Message
Subject: svn commit: r1369656 - in /httpd/httpd/trunk/modules/lua:
lua_vmprep.c lua_vmprep.h mod_lua.c mod_lua.h
Date: Sun, 05 Aug 2012 19:57:45 GMT
From: humbed...@apache.org
Author: humbedooh
Date: Sun Aug 5 19:57:44 2012
New Revision: 1369656
URL: http://svn.apache.org/viewvc?rev=1369656view=rev
Log:
Add a server scope for Lua states (in LuaScope), which creates a pool
of states with manageable
minimum and maximum size.
Modified:
httpd/httpd/trunk/modules/lua/lua_vmprep.c
httpd/httpd/trunk/modules/lua/lua_vmprep.h
httpd/httpd/trunk/modules/lua/mod_lua.c
httpd/httpd/trunk/modules/lua/mod_lua.h
Modified: httpd/httpd/trunk/modules/lua/lua_vmprep.c
URL:
http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/lua/lua_vmprep.c?rev=1369656r1=1369655r2=1369656view=diff
==
--- httpd/httpd/trunk/modules/lua/lua_vmprep.c (original)
+++ httpd/httpd/trunk/modules/lua/lua_vmprep.c Sun Aug 5 19:57:44 2012
@@ -23,6 +23,15 @@
APLOG_USE_MODULE(lua);
+#if APR_HAS_THREADS
+apr_thread_mutex_t *ap_lua_mutex;
+
+void ap_lua_init_mutex(apr_pool_t *pool, server_rec *s)
+{
+apr_thread_mutex_create(ap_lua_mutex, APR_THREAD_MUTEX_DEFAULT,
pool);
+}
+#endif
+
Shouldn't you use the httpd mutex API here to keep the mutex type
configureable in a generic way?
See util_mutex.c / ap_mutex_register.
Regards
Rüdiger
Hi Rüdiger,
When I looked into how httpd works with mutexes, I looked at mod_dbd for
inspiration, and it used the apr_thread_mutex stuff for its handling of
the process pools, so that's what I used. Shame on me :)
I have changed it to use the ap_mutex functions/structs now, so all
should be well (unless I managed to mess that up too ;) ).
With regards and thanks as usual for your reviews,
Daniel.
Re: Fwd: svn commit: r1369656 - in /httpd/httpd/trunk/modules/lua: lua_vmprep.c lua_vmprep.h mod_lua.c mod_lua.h
On 08/06/2012 11:46 AM, Plüm, Rüdiger, Vodafone Group wrote:
-Original Message-
From: Daniel Gruno [mailto:rum...@cord.dk]
Sent: Montag, 6. August 2012 11:31
To: dev@httpd.apache.org
Subject: Re: Fwd: svn commit: r1369656 - in
/httpd/httpd/trunk/modules/lua: lua_vmprep.c lua_vmprep.h mod_lua.c
mod_lua.h
On 08/06/2012 09:23 AM, Rüdiger Plüm wrote:
Original Message
Subject: svn commit: r1369656 - in /httpd/httpd/trunk/modules/lua:
lua_vmprep.c lua_vmprep.h mod_lua.c mod_lua.h
Date: Sun, 05 Aug 2012 19:57:45 GMT
From: humbed...@apache.org
--- httpd/httpd/trunk/modules/lua/lua_vmprep.c (original)
+++ httpd/httpd/trunk/modules/lua/lua_vmprep.c Sun Aug 5 19:57:44
2012
@@ -23,6 +23,15 @@
APLOG_USE_MODULE(lua);
+#if APR_HAS_THREADS
+apr_thread_mutex_t *ap_lua_mutex;
+
+void ap_lua_init_mutex(apr_pool_t *pool, server_rec *s)
+{
+apr_thread_mutex_create(ap_lua_mutex, APR_THREAD_MUTEX_DEFAULT,
pool);
+}
+#endif
+
Shouldn't you use the httpd mutex API here to keep the mutex type
configureable in a generic way?
See util_mutex.c / ap_mutex_register.
Regards
Rüdiger
Hi Rüdiger,
When I looked into how httpd works with mutexes, I looked at mod_dbd for
inspiration, and it used the apr_thread_mutex stuff for its handling of
the process pools, so that's what I used. Shame on me :)
I have changed it to use the ap_mutex functions/structs now, so all
should be well (unless I managed to mess that up too ;) ).
With regards and thanks as usual for your reviews,
Sorry for pointing you in the wrong direction. The httpd mutex API is only for
proc mutexes not for thread mutexes like you used initially (I assume you
only wanted to
coordinate multiple threads within one process and not multiple child
processes).
I did not notice this initially. So you can just revert your last commit.
Sorry for the inconvenience.
Regards
Rüdiger
Oh well, gives me something to do today ;)
With regards,
Daniel.
Re: svn commit: r1364330 - /httpd/httpd/branches/2.4.x/STATUS
On 07/22/2012 05:32 PM, rj...@apache.org wrote: Author: rjung Date: Sun Jul 22 15:32:22 2012 New Revision: 1364330 URL: http://svn.apache.org/viewvc?rev=1364330view=rev Log: Propose. Modified: httpd/httpd/branches/2.4.x/STATUS Modified: httpd/httpd/branches/2.4.x/STATUS URL: http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/STATUS?rev=1364330r1=1364329r2=1364330view=diff == --- httpd/httpd/branches/2.4.x/STATUS (original) +++ httpd/httpd/branches/2.4.x/STATUS Sun Jul 22 15:32:22 2012 @@ -296,6 +296,13 @@ PATCHES PROPOSED TO BACKPORT FROM TRUNK: +1: rjung rjung: sf: you applied it to trunk, care to vote? + * mod_ssl: Work correctly with a development version of OpenSSL. + trunk patch: http://svn.apache.org/viewvc?view=revisionrevision=1358167 and + http://svn.apache.org/viewvc?view=revisionrevision=1358166 + 2.4.x patch: http://people.apache.org/~rjung/patches/ssl-support-uninstalled-openssl-2_4.patch + +1: rjung + rjung: ben: you applied it to trunk, care to vote? + A list of further possible backports can be found at: http://people.apache.org/~rjung/patches/possible-backports-httpd-trunk-2_4.txt If you want to propose one of those, please add them here. I can't seem to find http://people.apache.org/~rjung/patches/ssl-support-uninstalled-openssl-2_4.patch - did you forget to upload it? :) With regards, Daniel.
Re: Additional core functions for mod_lua
On 08/06/2012 12:17 AM, Stefan Fritsch wrote: Nice work. If you talk about the existing apache2 library, you mean it is existing in mod_lua? Or is it an external file? I meant the apache2 table we already have in place for return codes. Either that or we create a new table/library to hold them. There is some overlap with the r table: These already exist: apache2.context_document_root apache2.context_prefix apache2.add_output_filter Scrapped These can be done wit r.subprocess_env: apache2.getenv apache2.setenv Also scrapped Wouldn't it make sense to add those new functions which are really related to the request (as opposed to just using the request pool) to the r table, too? Yes, I had planned to add some of the functions that only apply to requests to the existing r structure, so we could do things like r:flush() and use r.port etc. If there's (lazy) consensus, I can just add all the functions pertaining to the request to that structure. Some other random notes: apache2.requestbody: This should take a size limit as argument. Done apache2.get_server_name: The example and the synopsis don't agree if this should have an argument Fixed apache2.get_server_name_for_url: This is missing but would be very useful. Added With regards, Daniel.
Re: Additional core functions for mod_lua
If no one objects, I'll start moving in some functions to the mod_lua core, starting with the ones that pertain to obtaining a static value from the request/server, as well as the flush and sendfile function, and making them part of the request_rec package. This includes the following (as they will appear when imported): r:flush() - Flushes the output buffer r:sendfile(filename) - Sends a file using sendfile if available r.port -the port in use by the request r.banner - the server banner r.options - the Options directive for the request r.allowoverrides - the AllowOverride directive for the request r.started - the time the server was (re)started r.basic_auth_pw - the basic auth password, if any was sent r.limit_req_body - The current request body limit (or 0 for none) r.server_built -The time the server was built r.is_initial_req - Whether this is the initial request or a subreq r.remaining - The remaining bytes in the request body r.some_auth_required - Whether some authorization is/was required r.server_name - The server name for the request r.auth_name - The realm used (if any) for authorization This leaves the following functions still in the apache2 package - If you'd rather see any of them moved to the request_rec package, do say so - : apache2.base64_encode - Encode a string in base64 apache2.base64_decode - Decode a base64 string apache2.md5 - Generate an MD5 hash apache2.sha1 - Generate a SHA-1 hash apache2.escape -URL-escape a string apache2.unescape - unescape an URL-encoded string apache2.mpm_query - Query the MPM for information apache2.expr - Evaluate an ap_expr string apache2.scoreboard_process -Query the process scoreboard apache2.scoreboard_worker - Query a worker scoreboard apache2.clock - Returns the current time in microseconds apache2.requestbody - Fetches (or saves) the request body apache2.dbopen -Opens up a database connection (supports both apr_dbd and mod_dbd) apache2.add_input_filter - Adds an input filter to the request apache2.module_info - Queries the server for info about a mod apache2.loaded_modules -Lists all the loaded modules apache2.runtime_dir_relative - Returns a path relative to runtime dir apache2.server_info - Returns information about the executable apache2.set_document_root - Sets the document root for a request apache2.add_version_component - Adds a version component apache2.os_escape_path -Escapes a path as a URL apache2.strcmp_match - Does a strcmp_match (the foo* kind) apache2.set_keepalive - Set the keepalive status for a request apache2.make_etag - Creates an entity tag apache2.send_interim_response - Sends an interim response (or does it?) apache2.custom_response - Sets a custom response for an error msg apache2.exists_config_define - Query whether a define was made apache2.state_query - Queries the server for state info apache2.stat - Stats a file and returns info as a table apache2.regex - Evaluates regular expressions apache2.sleep - Sleeps for N seconds (accepts floats) apache2.get_server_name_for_url Servername for URL purposes Full descriptions and examples are still available at http://people.apache.org/~humbedooh/lua_ap/ if you need more info. If anyone has any other requests for internal functions they'd like to use in mod_lua, just speak up, I'm always happy to include more functionality. With regards, Daniel.
Re: svn commit: r1364330 - /httpd/httpd/branches/2.4.x/STATUS
On 08/06/2012 11:11 PM, Rainer Jung wrote: On 06.08.2012 12:32, Daniel Gruno wrote: I can't seem to find http://people.apache.org/~rjung/patches/ssl-support-uninstalled-openssl-2_4.patch - did you forget to upload it? :) Yes :( Now there. By the way: I updated http://people.apache.org/~rjung/patches/possible-backports-httpd-trunk-2_4.txt yesterday, so it is pretty current. Regards, Rainer Thanks for your work on keeping that list updated - I just spotted an extra revision that I will include in my proposal for the LuaCodeCache backport (provided the authz provider gets backported first, but I'm sure we can figure that out). With regards, Daniel.
Re: svn commit: r1371932 - /httpd/httpd/branches/2.4.x/STATUS
On 08/11/2012 02:37 PM, humbed...@apache.org wrote: Author: humbedooh Date: Sat Aug 11 12:37:15 2012 New Revision: 1371932 URL: http://svn.apache.org/viewvc?rev=1371932view=rev Log: Comment Modified: httpd/httpd/branches/2.4.x/STATUS Modified: httpd/httpd/branches/2.4.x/STATUS URL: http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/STATUS?rev=1371932r1=1371931r2=1371932view=diff == --- httpd/httpd/branches/2.4.x/STATUS (original) +++ httpd/httpd/branches/2.4.x/STATUS Sat Aug 11 12:37:15 2012 @@ -149,6 +149,8 @@ PATCHES PROPOSED TO BACKPORT FROM TRUNK: 2.4.x patch: Trunk patch works (*provided the authz provider gets backported) +1: humbedooh, rjung rjung: docs missing? + humbedooh: It's in the 2.4 docs already, but commented out, as with a lot +of other functions that were never actually made. It's a mess ;) * mod_auth_digest: respect DefaultRuntimeDir for its unconfigurable shared memory file I'll be quick, as I'm needed elsewhere. Rainer, the mod_lua docs are a bit of a mess, since the original implementation of mod_lua was not done properly. A lot of Gee, if only we had this documentation made it past to the 2.4 docs, and have since been commented out. As a result, there's no real patch from trunk to 2.4, since the documentation already exists in both documents, in different forms. I'll personally make sure that whenever something does get backported, the documentation is then made up-to-date. I hope that's good enough :) Mostly, this just involves uncommenting a section. With regards, Daniel.
Re: svn commit: r1372054 - in /httpd/httpd/trunk: CHANGES server/util.c
On 08/12/2012 03:15 PM, Ruediger Pluem wrote:
humbed...@apache.org wrote:
Author: humbedooh
Date: Sun Aug 12 07:45:55 2012
New Revision: 1372054
URL: http://svn.apache.org/viewvc?rev=1372054view=rev
Log:
core:
Be less strict when checking whether Content-Type is set to
application/x-www-form-urlencoded
when parsing POST data, or we risk losing data with an appended charset.
PR 53698
Reported by: Petter Berntsen sluggr gmail.com
Modified:
httpd/httpd/trunk/CHANGES
httpd/httpd/trunk/server/util.c
Modified: httpd/httpd/trunk/server/util.c
URL:
http://svn.apache.org/viewvc/httpd/httpd/trunk/server/util.c?rev=1372054r1=1372053r2=1372054view=diff
==
--- httpd/httpd/trunk/server/util.c (original)
+++ httpd/httpd/trunk/server/util.c Sun Aug 12 07:45:55 2012
@@ -2406,7 +2406,7 @@ AP_DECLARE(int) ap_parse_form_data(reque
/* sanity check - we only support forms for now */
ct = apr_table_get(r-headers_in, Content-Type);
-if (!ct || strcmp(application/x-www-form-urlencoded, ct)) {
+if (!ct || ap_strcmp_match(ct, application/x-www-form-urlencoded*)) {
ap_strcmp_match seems to be a lot of overhead for just prefix matching a
string.
How about
strncmp(application/x-www-form-urlencoded, ct, 33)
instead.
Regards
Rüdiger
Yeah, that approach seems better. Took me a couple of tries to commit
the right version though - I blame the lack of coffee coupled with heavy
partying last night.
With regards
Daniel.
Re: svn commit: r1374185 - in /httpd/httpd/trunk: CHANGES modules/lua/mod_lua.c
On 08/17/2012 12:19 PM, Guenter Knauf wrote: Daniel, Am 17.08.2012 11:41, schrieb humbed...@apache.org: Author: humbedooh Date: Fri Aug 17 09:41:46 2012 New Revision: 1374185 URL: http://svn.apache.org/viewvc?rev=1374185view=rev Log: (empty) can you please also provide a log entry? Gün. I'm very sorry about that, something ate my log entry, it seems. I can provide one here if that will do the trick: mod_lua: Allow scripts handled by the lua-script handler to set a return code that will be sent to the client, such as 302, 500 etc. This will allow scripts to be able to f.x. redirect a user to another page by returning 302. If there's anything else I do (somewhere I need to provide this entry), I'm all ears. With regards, Daniel.
Re: svn commit: r1374185 - in /httpd/httpd/trunk: CHANGES modules/lua/mod_lua.c
On 08/17/2012 12:34 PM, Igor Galić wrote: - Original Message - Please change the svn:log revision property for this revision such that your comment is documented in Subversion properly. Because it's a FAQ ;) http://subversion.apache.org/faq.html#change-log-msg Thanks, Igor and Rüdiger, for the pointers - I'm still a bit new to svn in some regards :). It should be fixed now. With regards, Daniel.
Re: [VOTE] Release Apache httpd 2.4.3 as GA
On 08/17/2012 07:34 PM, Jim Jagielski wrote: The pre-release test tarballs for Apache httpd 2.4.3 can be found at the usual place: http://httpd.apache.org/dev/dist/ I'm calling a VOTE on releasing these as Apache httpd 2.4.3 GA. NOTE: The -deps tarballs are included here *only* to make life easier for the tester. They will not be, and are not, part of the official release. [ ] +1: Good to go [ ] +0: meh [ ] -1: Danger Will Robinson. And why. Vote will last the normal 72 hrs. [X] +1: Good to go Tested on Debian 6.0, Ubuntu 12.04 and FreeBSD 9.0 (all AMD64) Configured, compiled and installed without problems with all modules built. All (working) tests in the test framework went fine. A few of them may need to have their design checked, as they were run when they shouldn't have been, but this isn't related to 2.4.3, so that's for another day. With regards, Daniel.
Ideas for an output filter for mod_lua
Hi dev@, I've been wondering (and tinkering with) the idea of creating output filters through mod_lua. If this has already been discussed, it was before my time here, so please forgive any redundant ideas. Essentially, what I'd like to do is be able to do the following: LuaOutputFilter myTestFilter /www/filter.lua filter_handle FilesMatch \.txt$ SetOutputFilter myTestFilter /FilesMatch and then, through coroutines or some such, make the following filter in Lua: -- [[ A simple filter mechanism ]] -- function filter_handle(r) coroutine.yield() -- Yield and wait for buckets while (buffer) do -- buckets are sent through the global var 'buffer' -- and set to 'nil' when there are no more buckets local escaped = r:escape_html(buffer) coroutine.yield(escaped) -- pass on the bucket end return end I've already made and tested a prototype of this, and it seems like something that could be of use to the public. So, any feedback, comments, thoughts on this? With regards, Daniel.
Re: Ideas for an output filter for mod_lua
On 08/22/2012 01:36 PM, Nick Kew wrote: Basic concept looks fine. I guess we'd need more detail to say any more about it. Is the implementation 'clean' or does it involve hacks to core? If what you have is pure module then I'd see no reason not to drop mod_lua_filter (or is it mod_filter_lua?) into trunk on CTR. I don't see why it should be made a separate module - it relies and operates on the stuff already inside mod_lua, and making it a part of it only requires adding some 50-60 lines of code (ymmv). But ideas/opinions are of course welcome. As for the 'cleanliness' of the code, there are no hacks, it works similar to how the other hook functions in mod_lua work. Each call to a Lua(In|Out)putFilter would register a new filter with a callback to fx ap_lua_output_filter, which will then traverse a list of known scripts/handles, find the one associated with the filter name in question and run it, making the Lua script yield whenever it's parsed a bucket and sending it further down the chain. Apart from the actual bucket handling, the function and the directives behave just as the other hooks and the LuaMapHandler does. When called, it would register a file/function in an array, and when a call is made to that handler, it checks to see what is being called, and finds the file/function associated with it. i.e. if you had two directives: LuaOutputFilter filterA /www/filters.lua filter_a_func LuaOutputFilter filterB /www/filters.lua filter_b_func then an output, with any of those two filters attached, would call ap_lua_output_filter, which would look up the filter currently being run and then run the file/function mapped to that filter. I guess what separates this from the other hooks the most is that it relies on co-routines (aka non-blocking/event-based or whatever the newest buzz word for it is) to get the job done. Meanwhile, some random thoughts: Is there a deep reason to limit it to output filters, or is that just what you happen to have implemented? The same method could be applied to input filters as well, I just had an interest in trying it out for output filters, so that's what I hacked together before making this proposal. I'll try implementing an input filter tomorrow. Would your concept meaningfully generalise beyond application-level filters? I'm not entirely sure what you mean by this, could you elaborate? If you want some more sophisticated examples of what could be achieved with Lua filtering, I'd be happy to provide some more details on how this concept could be utilised. With regards, Daniel.
Re: Ideas for an output filter for mod_lua
On 08/23/2012 12:02 AM, Tim Bannister wrote: On 22 Aug 2012, at 22:25, Daniel Gruno rum...@cord.dk wrote: Would your concept meaningfully generalise beyond application-level filters? I'm not entirely sure what you mean by this, could you elaborate? If you want some more sophisticated examples of what could be achieved with Lua filtering, I'd be happy to provide some more details on how this concept could be utilised. I don't know if this is another way of phrasing Nick's question or not, but would I be able to implement gzip Transfer-Encoding: just using Lua and this new directive? I found (bug 52860) it a bit tricky to achieve in C, so I think it could be harder still with the extra limitations of the Lua environment. My C code uses AP_FTYPE_TRANSCODE which I think is the right choice but few modules get involved at this filtering stage. The filter phases are as follows (as with any other filter mod): 1) mod_lua calls a setup function before buckets are sent, to allow for headers to be changed and data to be inserted before the actual content, fx. appending an advertisment a'la old Geocities or some such. 2) The Lua function yields to let mod_lua know it's ready to receive buckets 3) Buckets are sent, one by one to the function, which processes them, and again yields with the new content for each bucket. 4) once all buckets have passed through, mod_lua makes a final call with an empty (nil) buffer, allowing the Lua script to add any additional tail calls/data to the filter (it adds tail data by yielding with whatever should be added). Thus, an example Lua function could be: --- function filter(r) -- Initial phase r.content_type = text/plain -- set up some stuff coroutine.yield() -- End initial phase -- bucket phase while (buffer) do -- for each bucket sent, do... local output = mangle(buffer) -- transformation coroutine.yield(output) -- Send the output down the chain end -- Final phase once all buckets have been sent clean_up() coroutine.yield(This line will be appended to all files) end --- So yes, theoretically you should be able to implement decompression this way, by doing something along the lines of this (totally just making it up): - local zip = require zlib -- or something... function gzip_handle(r) r.headers_out['Transfer-Encoding'] = gzip -- or ? do_magic_header_stuff_here() -- add header data coroutine.yield() -- yield and wait for buckets while (buffer) do -- for each bucket, deflate it local deflated = zip.deflate(buffer) coroutine.yield(deflated) -- pass on new data end append_tail_to_output() -- pass on a tail if needed end - I haven't tried this out with gzip, but I have tried with base64_encoding a lot of files through a test filter that works similar to what I wrote above. I'm using AP_FTYPE_RESOURCE for the testing, but surely we could either change that or add some additional optional argument to the directive to control where it should place itself. As a 'fun' side effect of doing this in Lua, you can use the same filter functions for both input and output filtering, as they work the same way, although I don't know of any filters that would benefit from it ;) In any case, I'll get started on adding an input filter hook as well, and see if I can get it working just as well as the output filter I have in place, and then commit something snazzy for review. With regards, Daniel.
Re: Ideas for an output filter for mod_lua
On 08/23/2012 11:32 PM, Tim Bannister wrote: On 23 Aug 2012, at 11:45, Daniel Gruno rum...@cord.dk wrote: On 08/23/2012 12:02 AM, Tim Bannister wrote: My patch is for implementing gzip compression by httpd, not decompression, but the code will look pretty similar. That's quite neat, then. I will try to make an actual implementation in Lua. The part I found difficult was the interaction with the second transfer-encoding, “chunked”. Using gzip Transfer-Encoding: implies using chunked, because we want to shorten the response and this means that the Content-Length definitely doesn't match the size of the HTTP response body. I took a shot at an actual compression filter in Lua today, that uses zlib to deflate buckets and sends it as chunked data to the client. The script I used can be found at http://apaste.info/OPHa and I've verified that it works well for compressing text (I compressed a 50kb html output from a Lua script down to a 5kb chunked message with 4 separate chunks due to calling r:flush() in the script) The documentation for these new filters can be temporarily found at http://www.humbedooh.com/mod_lua.html.en#modifying_buckets while I polish it off for final committing (I have a bad habit of committing stuff, then making 10 new revisions later on ;) ). I just need to finish off some final adjustments, and I'll be committing the Lua filter support to the trunk for review and nagging. With regards, Daniel.
Re: Fwd: svn commit: r1377475 - in /httpd/httpd/trunk: CHANGES docs/manual/mod/mod_lua.xml docs/manual/style/scripts/prettify.js modules/lua/lua_vmprep.h modules/lua/mod_lua.c modules/lua/mod_lua.h
On 08/27/2012 09:41 AM, Rüdiger Plüm wrote: +/* Clean up and pass on the brigade to the next filter in the chain */ Where do we do a cleanup here? +return APR_SUCCESS; +} + snip Regards Rüdiger Heh, I believe that's what is called a copypasto. Both cleanups and passing on content is done earlier in the chain, the specific comment is simply a remnant of creating the input filter based on the code used for the output filter (you'll see the same comment in the output filter code, where it actually makes sense). I'll remove the comment. With regards and thanks, Daniel.
Re: Fwd: svn commit: r1377475 - in /httpd/httpd/trunk: CHANGES docs/manual/mod/mod_lua.xml docs/manual/style/scripts/prettify.js modules/lua/lua_vmprep.h modules/lua/mod_lua.c modules/lua/mod_lua.h
On 08/27/2012 11:59 AM, Plüm, Rüdiger, Vodafone Group wrote: Thanks. I guess you noticed that I found more important issues with the code than this comment :-) Regards Rüdiger Haha, yeah, but that's a big mess to clean up (I'm not a programmer by trade, so I'm a bit slow in that regard ;) ), so it will take me a while to get through all that, but I will get through it...eventually. With regards, Daniel.
Re: Fwd: svn commit: r1377475 - in /httpd/httpd/trunk: CHANGES docs/manual/mod/mod_lua.xml docs/manual/style/scripts/prettify.js modules/lua/lua_vmprep.h modules/lua/mod_lua.c modules/lua/mod_lua.h
On 08/27/2012 11:59 AM, Plüm, Rüdiger, Vodafone Group wrote: Thanks. I guess you noticed that I found more important issues with the code than this comment :-) Regards Rüdiger I've tried my best to correct the errors you mentioned, but I'm having some trouble figuring out how the input filter should pass along data to the next in the chain. What I have currently is this: /* Get the output from Lua's yield() as a string */ const char* output = lua_tolstring(L, 1, olen); /* Make a bucket for it */ pbktOut = apr_bucket_heap_create(output, olen, 0, c-bucket_alloc); /* Add it to the brigade */ APR_BRIGADE_INSERT_TAIL(pbbOut, pbktOut); /* Do something more here involving cleanups or..?? */ But then what? Am I supposed to make a call to some ap_*_brigade function? I've checked some of the example filter modules, but I can't seem to find any suitable way of doing this other than finishing up the brigade and returning APR_SUCCESS in the end. Any pointers (or some code) would be much appreciated. I have plenty imagination, but my httpd C API knowledge can be somewhat lacking at certain points. With regards, Daniel.
Re: DNT IE10 (was svn commit: r1371878 - /httpd/httpd/trunk/docs/conf/httpd.conf.in)
On 09/13/2012 03:27 PM, Jeff Trawick wrote: On Thu, Sep 13, 2012 at 7:48 AM, Eric Covener cove...@gmail.com wrote: On Sat, Aug 11, 2012 at 3:51 AM, field...@apache.org wrote: Author: fielding Date: Sat Aug 11 07:51:52 2012 New Revision: 1371878 URL: http://svn.apache.org/viewvc?rev=1371878view=rev Log: Apache does not tolerate deliberate abuse of open standards I've come around on this one over time. While I appreciate the message/intent, I don't think this is reasonable for the default configuration because it errs on the side of ditching a privacy header and information loss for a (sensitive) header that we're not yet interpreting. IMO it's enough even without this specific DNT text: An HTTP intermediary must not add, delete, or modify the DNT header field in requests forwarded through that intermediary unless that intermediary has been specifically installed or configured to do so by the user making the requests. For example, an Internet Service Provider must not inject DNT: 1 on behalf of all of their users who have not selected a choice. I'd like to revert it, but this is not yet a veto. I'd like to hear what others think and would appreciate an ACK from Roy/Greg/Jim who voted for the backport to avoid any churn. I agree that it should be reverted. I don't think it is technically justifiable for the default conf to remove it for IE 10. I don't think any particular web server deployment that has the general intention of respecting DNT should unset it for IE 10. If the will exists within the group, an open letter to Microsoft could be posted on httpd.apache.org regarding IE 10 flouting the user choice intent of the DNT specification. I to agree that it should be reverted, if nothing else, then at least for the time being, till this has been thoroughly discussed. Technically speaking, as httpd may be used as an intermediary (more specifially, a proxy/reverse proxy), it is difficult to justify forcing backends to take into account that we are altering the DNT, as Eric pointed out in the RFC quote. As I understand it, the patch would apply to both httpd itself and any backend that it proxies to, who may or may not be of the same opinion about whether the DNT standard has been broken by IE. Furthermore, as we ourselves do not support or use this DNT header ourselves, there is the question of what the patch actually achieves for httpd. What Microsoft has done is, to say the least, disappointing from a technical aspect, as it muddies the waters, and I think Jeff's thoughts about an open letter would be a very good idea, but it is hard for me to technically justify editing the DNT header from within httpd, thus also denying DNT for those who explicitly want it on. The error, as I see it, lies with Microsoft, and in the end, it should be Microsoft that fixes it, not httpd that has to make a workaround. With regards, Daniel.
Bugzilla and 2.2.23
Hi, Can someone with access please add a version entry in Bugzilla for 2.2.23? With regards, Daniel.
Re: Powered by icon for httpd-2.4 needs update
On 10/02/2012 01:01 PM, Jan Kaluža wrote: Hi, I'm not sure who has done original ./docs/icons/apache_pb2.* icons, but I think they should be updated to show 2.4 version for httpd-2.4. We are using that icon in default index.html in Fedora and it would be really nice to see version 2.4 there instead of 2.2. I can probably try to fix the icon myself, but I'm pretty bad at graphic, so I hope the original author still reads this mailing list. Regards, Jan Kaluza Yes, this does seem to be something that needs fixing. I'm not the original author (t'was way before my time, back in 1999), but what I can do is approximate the original logo (I don't know which fonts were originally used) and create an SVG version of the powered-by logo: SVG version: http://www.humbedooh.com/apache/poweredby.svg PNG version: http://www.humbedooh.com/apache/poweredby.png The SVG version uses the new feather instead of the old, but that should really only be a plus, since we'll have a logo we can maintain and reproduce as we see fit. If people are content with this suggestion, I can turn it into png/gif images and put them in the docs folder in trunk as well as the svg version. Or if the original author still has the original material, he/she can make the necessary changes, I'm fine with whichever it is. With regards, Daniel.
Re: Powered by icon for httpd-2.4 needs update
On 10/02/2012 01:56 PM, Gregg Smith wrote: On 10/2/2012 4:41 AM, Daniel Gruno wrote: Yes, this does seem to be something that needs fixing. If people are content with this suggestion, I can turn it into png/gif images and put them in the docs folder in trunk as well as the svg version. Or if the original author still has the original material, he/she can make the necessary changes, I'm fine with whichever it is. Been there, done that, have it still. What stopped it then was the font. What license is the font under. It begs me to ask what the license of the font currently in use is. So this leads me to again ask the question, what font license is acceptable? I can get plenty close with a font from the Open Font Library, it is licensed under the SIL Open Font License 1.1 http://scripts.sil.org/OFL There is only one ugly blog font licensed under the Apache 2.0 License that I have found. So if we are going to hold out for the AL2.0, we should be fontless. Regards, Gregg Righto, ASL getting in the way ;) I have updated my suggestion for a powered-by logo using only ASL stuff: Powered by and 2.4 is done with Droid Sans, which is using ASL Apache is done with Syncopate, which is also using ASL. Take a look and see if the result is close enough for jazz, http://www.humbedooh.com/apache/poweredby.svg With regards, Daniel.
Re: Powered by icon for httpd-2.4 needs update
On 10/02/2012 03:42 PM, Gregg Smith wrote: On 10/2/2012 5:41 AM, Daniel Gruno wrote: Righto, ASL getting in the way ;) I have updated my suggestion for a powered-by logo using only ASL stuff: Powered by and 2.4 is done with Droid Sans, which is using ASL Apache is done with Syncopate, which is also using ASL. Take a look and see if the result is close enough for jazz, http://www.humbedooh.com/apache/poweredby.svg That's great Dan +1 +1 to a png that's as close to the 259x32 size like the 2.2 one too. Might I ask where the feather came from, that is a nice bold one. Regards, Gregg The feather came from Apache's press kit; http://www.apache.org/foundation/press/kit/feather_logo_RGB.svg I can do a 260x30, I hope that's close enough :) If there are no objections, I'll create the various png/gif versions and commit them to trunk later today. With regards, Daniel.
Re: Powered by icon for httpd-2.4 needs update
On 10/03/2012 08:20 AM, Jan Kaluža wrote:
Really thank for that. I see the images are already in trunk, would it
be possible to have them also in 2.4 branch?
Thanks,
Jan Kaluza
Even though this is under the jurisdiction of the docs project, it is
still commit-then-review, which is why I didn't just steamroll it
through to 2.4 right away. That being said, if no one objects, I'll
backport the new images to 2.4 today and get rid of the animated gif
('cause we really don't need that one, do we? ;) ).
With regards,
Daniel.
Re: Powered by icon for httpd-2.4 needs update
On 10/04/2012 03:35 AM, Guenter Knauf wrote: Hi Daniel, Am 03.10.2012 22:25, schrieb Guenter Knauf: Am 02.10.2012 15:58, schrieb Daniel Gruno: I can do a 260x30, I hope that's close enough :) If there are no objections, I'll create the various png/gif versions and commit them to trunk later today. go ahead - thats overdue! may I ask for another one? We got some time back discussions that httpd != Apache, and in this light it would probably more correct if the logo text would read: Powered by httpd 2.4 and this then perhaps right-aligned ... can you perhaps give that a try and show here how this looks? Thanks! Gün. Sure! here's how it looks with httpd instead of apache: http://www.humbedooh.com/apache/apache_pb.png I'm assuming that's what you meant? :) With regards, Daniel.
Re: Powered by icon for httpd-2.4 needs update
On 10/04/2012 04:45 AM, Guenter Knauf wrote: Am 04.10.2012 04:26, schrieb Gregg Smith: On 10/3/2012 6:49 PM, Jie Gao wrote: What about Apache HTTPD? +1 httpd != Apache , but this is still part of the (Apache)SF last I looked. Maybe write over the bottom-right of Apache the HTTPD justified right. Like so maybe? HTTPD is syncopate too http://people.apache.org/~gsmith/httpd/apache_pb2copy.png closer to what I meant; of course the colored APACHE should stay; but I would suggest to have: Powered by httpd 2.4 above APACHE just like Powered and 2.4 is already above: (feather) Powered by httpd 2.4 A P A C H E Gün. Okay, seems we have a lot of options to choose from then :) I'll paste the links to gregg's proposal, my initial (wrong) one and two more which says powered by httpd 2.4 in different ways: http://people.apache.org/~gsmith/httpd/apache_pb2copy.png http://www.humbedooh.com/apache/apache_pb.png http://www.humbedooh.com/apache/apache_pb2.png http://www.humbedooh.com/apache/apache_pb3.png Pick a card, any card ;) With regards, Daniel
Re: Powered by icon for httpd-2.4 needs update
On 10/04/2012 02:13 PM, Jim Jagielski wrote: Can I assume that all the logos being proposed are donated to the ASF? I'm sure they are, but we need some sort of paper-trail to ensure. If someone is a committer with an iCLA then it's not really needed, but any from non-committers need verification. On Oct 4, 2012, at 6:41 AM, Guenter Knauf fua...@apache.org wrote: Am 04.10.2012 05:15, schrieb Eric Covener: http://people.apache.org/~gsmith/httpd/apache_pb2copy.png http://www.humbedooh.com/apache/apache_pb.png http://www.humbedooh.com/apache/apache_pb2.png http://www.humbedooh.com/apache/apache_pb3.png pb3 has my vote yep, mine too, and is exactly what I had in mind! Gün. Heh, I'm quite sure both Gregg and I have filed our iCLAs and are donating all of the images to the ASF :) but heck, just to formalize it: I hereby donate any previously made and future Apache related logos to the ASF. All fonts/feathers used are also licensed under the Apache 2.0 license, so that ought to cover it all. Do we need to call a vote on this, or will all the pluses, that have been flying around in the thread, suffice? There seems to be an overwhelming majority supporting the use of http://www.humbedooh.com/apache/apache_pb3.png With regards, Daniel.
Re: Powered by icon for httpd-2.4 needs update
On 10/05/2012 04:25 PM, Daniel Ruggeri wrote: On 10/4/2012 4:04 AM, Nick Kew wrote: Oh dear, I have to go against the bandwagon. I like pb2 best, by a clear margin. The contrast to pb3 is that it separates the slogan visually from the name, which I find more comfortable. Pb3 jars when the text powered by ... turns out not to trip off the tongue, and the merged/lowercase httpd looks like trying to hide the name. And, just for grins, I'm against even that bandwagon :-) While I totally get the idea that this is an ASF product, shouldn't httpd be the part emphasized? Thinking along the lines of, I drive a Toyota strongCamry/strong rather the other way around of saying I drive a strongToyota/strong Camry... Therefore I like: http://www.humbedooh.com/apache/apache_pb.png (as it emphasizes httpd) http://people.apache.org/~gsmith/httpd/apache_pb2copy.png (as it has Apache but still gives emphasis to httpd) Care to share sources? Maybe I can monkey around a bit with the logo to see if I even like my the idea I mention above... I'm really fine with whatever you guys eventually decide on, I'm just happy we are actually doing an update of the icons now :D The source is the SVG file already committed to trunk ;) Just open it up in Inkscape or similar and edit it. It's using paths instead of actual font strings, but originally I (and gregg) have used Droid Sans for the Powered by text ans Syncopate Bold for the APACHE text. Both are ASL and easy to find on Google's font page. With regards, Daniel.
Re: svn commit: r1420377 - in /httpd/httpd/trunk: docs/manual/mod/mod_lua.xml modules/lua/lua_apr.c modules/lua/lua_apr.h modules/lua/mod_lua.c
On 12/14/2012 10:48 AM, Guenter Knauf wrote:
Am 12.12.2012 22:44, schrieb Marion Christophe JAILLET:
Here are a few things triggered by cppcheck.
Le 11/12/2012 21:08, humbed...@apache.org a écrit :
Author: humbedooh
Date: Tue Dec 11 20:08:24 2012
New Revision: 1420377
URL: http://svn.apache.org/viewvc?rev=1420377view=rev
Log:
mod_lua: Add a lot of core httpd/apr functionality to mod_lua
(such as regex matching, expr evaluation, changing/fetching server
configuration/info - see docs for a complete list).
This also includes a bunch of automatically scraped functions, which
may or may not be super useful.
Comments appreciated as always, especially on the more hacky bits.
Modified: httpd/httpd/trunk/modules/lua/lua_apr.c
URL:
http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/lua/lua_apr.c?rev=1420377r1=1420376r2=1420377view=diff
==
--- httpd/httpd/trunk/modules/lua/lua_apr.c (original)
+++ httpd/httpd/trunk/modules/lua/lua_apr.c Tue Dec 11 20:08:24 2012
I've put the parsed file on:
http://people.apache.org/~jailletc36/lua_apr.html
Check it from there. Things noticed by cppcheck are red-marked.
Except the 'The scope of the variable '...' can be reduced' that can be
ignored, all the other remarks are relevant.
Especially:
a useless apr_pcalloc (line 249)
a out of bound access (line 321) -- I don't know if Rsha1 should be
[20] or if the loop should be limited to 16
this seems to be a cut and paste error from lua_apr_md5
a uninitialized variable (line 430)
beside these probs there are type mismatches which break strict compilers:
AR obj_release/lua.lib
CC mod_lua.c
CC lua_apr.c
### mwccnlm Compiler:
#File: lua_apr.c
# --
# 278: apr_md5_final(digest.chr, md5);
# Error:^
# illegal implicit conversion from 'char[16]' to
# 'unsigned char *'
# Too many errors printed, aborting program
User break, cancelled...
make[2]: *** [obj_release/lua_apr.o] Error 2
CC lua_config.c
CC lua_request.c
### mwccnlm Compiler:
#File: lua_request.c
# --
# 230: if (lua_read_body(r, data, size) != OK) {
# Error: ^
# illegal implicit conversion from 'unsigned int *' to
# 'long long *'
# Too many errors printed, aborting program
User break, cancelled...
make[2]: *** [obj_release/lua_request.o] Error 2
Daniel, please check the used types more carefully and either change
them or cast.
Gün.
Thanks for the heads up, guys!
I didn't receive Christophe's email, which is why I didn't put these
fixes up till now. I will try to use that cppcheck program in the
future, it seems very nice, and catches some things that my regular
compiler warning settings don't. So thanks for that as well :)
With regards,
Daniel.
Re: svn commit: r1420377 - in /httpd/httpd/trunk: docs/manual/mod/mod_lua.xml modules/lua/lua_apr.c modules/lua/lua_apr.h modules/lua/mod_lua.c
On 12/14/2012 09:34 PM, Gregg Smith wrote: Evidently an unused variable. .\lua_request.c(227) : warning C4101: 'z' : unreferenced local variable On the Windows side of things; lua_apr.c in use all over are uint32_t and we do not have uint32_t available. apr_uint32_t works well. Then there is; .\lua_apr.c(567) : error C2440: 'function' : cannot convert from 'apr_os_thread_t' to 'lua_Number' In scoreboard.h, tms is declared if HAVE_TIMES is defined. I assume that is sys/times.h which we do not seem to have. It seems there may be an APR alternative to this that I saw in modules\dav\fs\repos.c which may or may not be usable here or Windows will just have to go without these if possible. .\lua_apr.c(575) : error C2039: 'times' : is not a member of 'worker_score' c:\build4\httpd-head-r1421953\include\scoreboard.h(90) : see declaration of 'worker_score' .\lua_apr.c(579) : error C2039: 'times' : is not a member of 'worker_score' c:\build4\httpd-head-r1421953\include\scoreboard.h(90) : see declaration of 'worker_score' Regards, Gregg Bloody Windows ;) But thanks a ton for your help, Gregg :) I have added an #ifdef for the tms stuff, as I saw mod_status did the same. If there is another way of making it work, I will change it as soon as I find a proper way to deal with it. With regards, Daniel.
Re: svn commit: r1424723 - /httpd/httpd/trunk/modules/lua/lua_request.c
On 12/21/2012 03:45 PM, Guenter Knauf wrote: Hi Daniel, Am 20.12.2012 22:52, schrieb humbed...@apache.org: Author: humbedooh Date: Thu Dec 20 21:52:03 2012 New Revision: 1424723 URL: http://svn.apache.org/viewvc?rev=1424723view=rev Log: mod_lua: Fix multipart post parsing, so it doesn't include random bytes at the end. Modified: httpd/httpd/trunk/modules/lua/lua_request.c Modified: httpd/httpd/trunk/modules/lua/lua_request.c URL: http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/lua/lua_request.c?rev=1424723r1=1424722r2=1424723view=diff == --- httpd/httpd/trunk/modules/lua/lua_request.c (original) +++ httpd/httpd/trunk/modules/lua/lua_request.c Thu Dec 20 21:52:03 2012 @@ -19,6 +19,7 @@ #include util_script.h #include lua_apr.h #include scoreboard.h +#include lua_dbd.h what's that? probably non-intended commit? ### mwccnlm Compiler: #File: lua_request.c # -- # 22: #include lua_dbd.h # Error: ^ # the file 'lua_dbd.h' cannot be opened # Too many errors printed, aborting program User break, cancelled... Gün. argh, yes - that's the database project I'm working on. Seems I forgot to remove all references to it, I'm sorry :/ I'll fix it right away! With regards, Daniel.
Re: [VOTE] accept mod_macro as standard module in httpd
On 01/03/2013 03:06 AM, Eric Covener wrote: I was preparing the IP clearance forms and noticed our original vote thread was more of a discussion. I wanted to record a formal vote here so I can link to it. Pending IP clearance... [+1] accept mod_macro as a standard module and responsibility for its maintenance [ +/- 0] don't care won't help [ -1] don't accept mod_macro as a standard module +1 With regards, Daniel.
[Discuss] mod_lua and database connectivity
Hello, fellow dev@ people, it's time for my monthly mod_lua rambling! This time, I have set my eyes on creating bindings for the apr_dbd features and mod_dbd in httpd. The purpose of this would be to both enable people to easily use databases for Lua scripts, as well as lua modules (hooks) in a way that both minimizes the need for external libraries and takes advantage of mod_dbd if the module is loaded and in use. While this could also be solved using an external library that was required()'d in the Lua scripts, I feel that it would greatly boost the usage and popularity of mod_lua if it were to be included as a core feature. Otherwise, people would have to go look for external libraries, which would both be redundant, since we already have db features inside httpd, as well as make it more difficult to get things running with mod_lua, as people would have to either resort to luarocks (which I find to be quite lacking) or write/compile libraries themselves. I do not wish to attempt to compare mod_lua to the likes of mod_php, mod_python etc, but the ease of which these modules are hooked up with databases of all sorts is perhaps one of the key elements in their popularity, and I want mod_lua to be just as accessible for the _basic_ needs of a programmer/sysadmin (no, I do not want to bloat it, but I want the core features that you need on a modern web site to be available, and as such, db connectivity is a must) The use-cases for this is many; Authenticating against a database with a different approach than mod_auth_dbd, mass virtual hosting using cached database lookups, web sites like our comments.a.o (which uses the exact same Lua bindings as the one I am proposing, so it's been tested and is working ;) ), my own paste bin site apaste.info (people from #httpd probably know and use this one) and other nifty sorts of hooks and scripts. Database objects will be assigned a metatable with a garbage collector routine that automatically frees database handles when they are no longer used, or they can be manually closed (which is preferred). The bindings I propose can roughly be summarized with these example snippets: - Connecting to a database: - function handler(r) local db, error = r:dbopen(mod_dbd) -- Open a mod_dbd connection if error then ... end -- or... local db, error = r:dbopen(mysql, server=localhost,user=root,database=somedb) -- essentially the same as mod_dbd's connection string. do_stuff() db:close() -- close the db handle (can also be done by GC) local still_running = db:active() -- returns false, since we closed -- the connection. end - Querying: - -- Run a command and get the no. of rows affected: local affected, err = db:do(r, DELETE FROM `table` WHERE 1) if err then print(DB error: .. err) else print(Deleted .. affected .. rows!) end -- Run a query and get the rows returned: local rows, err = db:query(r, SELECT `name` FROM `table` WHERE 1) if rows then r:puts(We got .. #rows .. results!) for k, row in pairs(rows) do print(Name: .. row[1] .. br/) end else r:puts(DB error: .. err) end -- Run a prepared statement and inject values into it: local rows, err = db:inject(r, SELECT `name` FROM `tbl` WHERE `id` = %u, 1234) if rows then else end -- Miscellaneous: -- -- escaping strings for use in db queries: local escaped = db:escape(r, [[foobar'|baz]]) So, any comments, suggestions, remarks, objections and so on is very much welcomed. If there are no big objections to implementing this feature, I will consider it as lazy consensus and commit the bindings to trunk sometime soon along with updated documentation. With regards, Daniel. PS: I _have_ checked and double checked the code properly this time, so it conforms to the style requirements and works with maintainer mode. I know I usually get something wrong, but this time I think it's as close to perfect as it can get :) (but then again, I always write something bad, so apologies in advance if you find a bug)
Re: [Discuss] mod_lua and database connectivity
On 01/04/2013 12:57 AM, Brian McCallister wrote: ... Supporting luasql would be a big bonus, though I understand if goal is to provide a quick and dirty api which is backed by mod_dbd Quick and dirty makes it sound so...dirty. But yes, essentially, the purpose is to provide very basic database features for those just getting started or those who either cannot be bothered (we know who you lot are!) or can't figure out how to use luasql or other external libraries. I'd want mod_lua to be something you can sit down and get started on without having to learn how to compile lua or install libraries, BUT if you wanted/needed the extra capabilities that fx luasql provides, you could simply switch. It is not in any way intended as a full replacement, rather as a 'starter kit' so people load the module and go 'okay, what can this mod_lua puppy do for me? and not have to think about the sometimes cumbersome process of extending Lua's capabilities. I suppose I can boil my reasoning down to two major points: 1) We have apr_dbd capabilities in httpd, so why not support it in Lua? This would mean a much smaller foot print when using databases in mod_lua compared to loading an external library into every VM. 2) We'd want something that can connect through mod_dbd, which is unlikely to be supported by third party database libraries. Shouldn't this be a method on the server representation, not the request representation? There is no server handle, only a request handle given to mod_lua scripts, you should know that ;). The server handle is obtained through the request handle, so all is well and good here. ... Hmm, if db here represents a handle, it should prolly be paired with acquire not open. Semantics ;) but sure, we could call it 'acquire' instead of 'open'. Check your errors :-) I don't need to check errors, I just need to check whether 'rows' is a table or a nil value in the case of an error. I could've checked if 'err' was anything, but the result is the same. Also, be careful what you return, you don't want to the API to force you to realize all results from a query eagerly. Currently, it works that way - it fetches everything at once, which I grant can be something you may or may not want. I am considering adding a metatable to the 'rows' object with an __index hook that fetches new rows only when needed. Good call! I will hold off on this for a while though, as there are some memory pool concerns. Imagine if one runs a query and uses the request pool for fetching data, then waits till another request comes through before iterating through the rows, that would cause an error, unless the query was stored in the global server pool, in which case it could not get released (and then I'd have to, instead, use another pool for allocating memory, which would have to be tied to the db object - so much to do!). The global pool option is what lua-apr does with everything, which is not something I'd want mod_lua to do. -- Run a prepared statement and inject values into it: local rows, err = db:inject(r, SELECT `name` FROM `tbl` WHERE `id` = %u, 1234) Hmm, I would expect an API like local pstmt, err = h:prepare(...) ... = pstmt:execute(hello, 7) -- or ... = pstmt:query(hello, 7) or such style api. Injecting into implicit prepared statement is a strange api. Not necessarily. If the injection function stores a key/value pair of injected statements and prepares them beforehand, then a subsequent call using the same statement would just look up whether that statement has already been prepared, and there would be no need to recompile. Though, I do see the benefits of instead associating a prepared statement with a tag of your own, so I will definitely consider this as well :) Thanks for your feedback, it's very much appreciated! With regards, Daniel.
Re: [Discuss] mod_lua and database connectivity
On 01/05/2013 10:49 AM, Igor Galić wrote: Implied semantics matter a LOT in API design. +1 Check your errors :-) I don't need to check errors, I just need to check whether 'rows' is a table or a nil value in the case of an error. I could've checked if 'err' was anything, but the result is the same. An API which returns (foo, err) should be error checked on the error, not the foo. This style of API will sometimes return a foo in a bad state, and an err to let you know. In your example this is fine, I am just being a pedant because if an API is designed a certain way, we should use it that way :-) My take away is that we want mod_dbd bindings in mod_lua, but we want the API to be more carefully crafted. i My attempt at humour seems to have failed, so I'll be more to the point. Yes, calling it acquire rather than open makes sense, and it's a good suggestion that I have applied to my draft. Regarding the return values of 'acquire' (dbacquire, as it's currently called), this, as well as the query/run (or should it be called select/query? I'm not sure, but running db:select(SELECT...) seems a bit redundant in my mind) will never return a 'bad state', they will return nil if an error occurred, followed by an error message. How one chooses to check for an error, whether it be checking the nil value or checking for an error message, the result will be the same. However, in my documentation addition to mod_lua, I have consistently made the examples check for an error message, so no need to worry there - I was only being brief in my example snippets in the previous email, apologies. Return values are as follows: r:dbacquire(type, connstring): DB handle on success, nil + error on failure (error is either can't connect, can't load driver or mod_dbd not loaded) db:query(SELECT ): Result set on success, nil + error on failure (syntax error, permission issue or db handle not connected to backend) db:run(DELETE ): Number of affected rows on success, nil + error on failure (same errors as :query) With regards to how :query should work, this could either be done synchronously, wherein all rows are fetched at once, or async where rows are fetched as needed. The sync way is rather easy, but could fill up more memory than needed, while the async has a smaller footprint but proves rather difficult to implement, as the darn dbd driver keeps wanting to free up the result set before it's finished being used (apr_dbd_get_row keeps segfaulting when I request a row that is out of bounds... :( ). Also,there is the consideration of what happens if you query a db, get a result set, close the db handle and try to fetch more rows - this would most likely result in a segfault, as the db handle would have been freed when you try to use it again (how to check that?). Also, getting the number of rows, or even doing: for k, v in pairs(rows) ... proves to be quite difficult with the async method. What I've pieced together so far would work something like this: local results, err = db:query(SELECT .) it not err then -- Async method here: local x = 1 local row = results(x) -- fetch row 1 while row do x = x + 1 row = results(x) -- fetch row 2,3,4,5...N end -- Sync method here: local rows = results() -- fetch all rows at once for index, row in pairs(rows) do end end As usual, suggestions and comments are most welcome! And as for the inject/prepare stuff, I'm working on a new approach to that as well, will keep you guys posted. With regards, Daniel.
Re: [Discuss] mod_lua and database connectivity
On 01/06/2013 12:16 AM, Sean Conner wrote: It was thus said that the Great Daniel Gruno once stated: With regards to how :query should work, this could either be done synchronously, wherein all rows are fetched at once, or async where rows are fetched as needed. The sync way is rather easy, but could fill up more memory than needed, while the async has a smaller footprint but proves rather difficult to implement, as the darn dbd driver keeps wanting to free up the result set before it's finished being used (apr_dbd_get_row keeps segfaulting when I request a row that is out of bounds... :( ). Also,there is the consideration of what happens if you query a db, get a result set, close the db handle and try to fetch more rows - this would most likely result in a segfault, as the db handle would have been freed when you try to use it again (how to check that?). Also, getting the number of rows, or even doing: for k, v in pairs(rows) ... proves to be quite difficult with the async method. What I've pieced together so far would work something like this: local results, err = db:query(SELECT .) it not err then -- Async method here: local x = 1 local row = results(x) -- fetch row 1 while row do x = x + 1 row = results(x) -- fetch row 2,3,4,5...N end -- Sync method here: local rows = results() -- fetch all rows at once for index, row in pairs(rows) do end end You could always create an interator for the results and hide the method (sync/async) behind it: function db:query(q) ... local function results_async() local function getnext(state) -- state is the db object return db:results_next(state) end return getnext,self end local function results_sync() local row = db:results_all(db) return pairs(row) end ... return results_async,err end local results, err = db:query(SELECT ... ) if not err then for row in results() do blah_de_blah_blah() end end Untested code and all that (so it may very be wrong, but the intent is there) -spc I may have been a tad too hasty with my proposal there. I realized that the async fetching can be made quite simple via apr_dbd: local results, err = db:query(SELECT ) if not err then while true do row = results(-1) -- fetch the next row if not row then break do_stuff() end end The example you provided could be used in the documentation to provide methods to get a pairs iterator for both sync and async, so thanks for that :) One could in fact construct a function that takes async as a boolean parameter: function rows(resultset, async) local a = 0 local function getnext() a = a + 1 local row = resultset(-1) return row and a or nil, row end if not async then return pairs(resultset(0)) else return getnext, self end end and then do: -- async method: for index, row in rows(resultset, true) do ... end -- sync method: for index, row in rows(resultset, false) do -- or just rows(resultset) end Now I just have to take a good look at how to rewrite the prepared statement stuff, and I believe I'll have a decent proposal ready for commit :) With regards, Daniel.
Re: [Discuss] mod_lua and database connectivity
On 01/06/2013 04:23 PM, Stefan Fritsch wrote: On Sun, 6 Jan 2013, Daniel Gruno wrote: Now I just have to take a good look at how to rewrite the prepared statement stuff, and I believe I'll have a decent proposal ready for commit :) I am a bit late in the discussion, but maybe you also want to support using statements that have been prepared with DBDPrepareSQL from mod_dbd? Other important things (but I think these have already been pointed out): - don't let lua scripts open connections, instead make them aquire connections from mod_dbd's connection pool. - use parametrized prepared statements in all examples and make that as easy to use as possible. Don't show any examples that put parameters directly into the statement strings. First off, I should mention that mod_dbd is indeed supported in the proposal, in fact, I use only mod_dbd for my own Lua stuff. As per our discussion on IRC, I have made some additions to the prepared statements, so that statements prepared using DBDPrepareSQL can also be fetched using db:prepared(r, tag). Thus prepared statements can be used in two ways: -- Regular prepared statement creation: local prepped, err = db:prepare(SELECT * FROM `tbl` WHERE `id` = %s) if not err then local result, err = prepped(foobar) -- insert foobar as id ... end -- Fetch from DBDPrepareSQL: local prepped, err = db:prepared(someTag) if not err then local result, err = prepped(foobar) -- insert foobar as id ... end This and the rest is discussed in my draft for the docs changes, which can be found at: http://www.humbedooh.com/apache/mod_lua.html.en#databases I hope you guys will review it and let me know if you think it's time to actually commit the code ;) With regards, Daniel.
Re: [Discuss] mod_lua and database connectivity
On 01/06/2013 07:21 PM, Daniel Gruno wrote: On 01/06/2013 04:23 PM, Stefan Fritsch wrote: On Sun, 6 Jan 2013, Daniel Gruno wrote: -- Regular prepared statement creation: local prepped, err = db:prepare(SELECT * FROM `tbl` WHERE `id` = %s) if not err then local result, err = prepped(foobar) -- insert foobar as id ... end -- Fetch from DBDPrepareSQL: local prepped, err = db:prepared(someTag) if not err then local result, err = prepped(foobar) -- insert foobar as id ... end One last change before I commit the code; prepared statements now have two functions identical to the database object; select and query. These were formerly known as query and run in the db object, but I have renamed them to comply with the naming conventions of apr_dbd, thus 'query' is for running a command and fetching the no. of rows affected, and 'select' is for...selecting :) So, prepared statements are now run as follows: -- select stuff local prepared, err = db:prepare(SELECT * FROM `tbl` WHERE `age` %u) if not err then local result, err = prepared:select(1234) end -- run stuff local prepared, err = db:prepare(DELETE FROM `tbl` WHERE `age` %u) if not err then local result, err = prepared:query(1234) end With regards, Daniel.
Re: svn commit: r1430590 - /httpd/httpd/branches/2.4.x/STATUS
On 01/08/2013 11:40 PM, j...@apache.org wrote: Author: jim Date: Tue Jan 8 22:40:29 2013 New Revision: 1430590 URL: http://svn.apache.org/viewvc?rev=1430590view=rev Log: BalancerInherit proposal Modified: httpd/httpd/branches/2.4.x/STATUS Modified: httpd/httpd/branches/2.4.x/STATUS URL: http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/STATUS?rev=1430590r1=1430589r2=1430590view=diff == --- httpd/httpd/branches/2.4.x/STATUS (original) +++ httpd/httpd/branches/2.4.x/STATUS Tue Jan 8 22:40:29 2013 @@ -176,6 +176,20 @@ PATCHES PROPOSED TO BACKPORT FROM TRUNK: 2.4.x patch: trunk patch works + CHANGES to be added +1: jailletc36, jim + * mod_proxy: Allow balancers to be server-specific, as they should have + been. Inheritance causes too many behind-the-scene interactions + to be reliable in a dynamic environ. We maintain the old-default + of inheritance. + trunk patch: http://svn.apache.org/viewvc?view=revisionrevision=1387603 + http://svn.apache.org/viewvc?view=revisionrevision=1388029 + http://svn.apache.org/viewvc?view=revisionrevision=1420124 + http://svn.apache.org/viewvc?view=revisionrevision=1421288 + http://svn.apache.org/viewvc?view=revisionrevision=1421912 + http://svn.apache.org/viewvc?view=revisionrevision=1422943 + http://svn.apache.org/viewvc?view=revisionrevision=1422980 + http://svn.apache.org/viewvc?view=revisionrevision=1430575 + 2.4.x patch: http://people.apache.org/~jim/patches/proxypassinherit2.patch + +1: jim A list of further possible backports can be found at: Did you mean http://people.apache.org/~jim/patches/proxypassinherit.patch (without the '2') ? With regards, Daniel.
Re: svn commit: r1431215 - /httpd/httpd/branches/2.4.x/STATUS
On 01/10/2013 10:17 AM, fua...@apache.org wrote: Author: fuankg Date: Thu Jan 10 09:17:18 2013 New Revision: 1431215 URL: http://svn.apache.org/viewvc?rev=1431215view=rev Log: vote. Modified: httpd/httpd/branches/2.4.x/STATUS Modified: httpd/httpd/branches/2.4.x/STATUS URL: http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/STATUS?rev=1431215r1=1431214r2=1431215view=diff == --- httpd/httpd/branches/2.4.x/STATUS (original) +++ httpd/httpd/branches/2.4.x/STATUS Thu Jan 10 09:17:18 2013 @@ -104,6 +104,7 @@ PATCHES PROPOSED TO BACKPORT FROM TRUNK: 2.4.x patch: http://www.humbedooh.com/apache/lua_dbd.patch + CHANGES +1: humbedooh + -1: fuankg - we 1st need some workarounds for stupid CodeWarrior compiler. * configure --with-modules: - Fix shell errors when trying to AC_MSG_RESULT(). How am I supposed to write a workaround for a compiler I apparently can't run on any of my computers (and also have to pay for?)? Can you provide me with the errors that it produces, or some tips on how I can possibly run this compiler on my own computer? Otherwise, I really don't know what to do here - the bindings work fine on all the machines I've tested them on. With regards, Daniel.
Re: svn commit: r1431215 - /httpd/httpd/branches/2.4.x/STATUS
On 01/10/2013 01:52 PM, Guenter Knauf wrote: Hi Daniel, Am 10.01.2013 10:34, schrieb Daniel Gruno: Can you provide me with the errors that it produces, or some tips on how I can possibly run this compiler on my own computer? Otherwise, I really don't know what to do here - the bindings work fine on all the machines I've tested them on. meanwhile all clarfied; I was writing the mail to you just after I did mention the prob in STATUS; just wanted to avoid that the backport takes place without a workaround. Thanks for your quick coding! Gün. Yeah, it did seem a bit funny that those emails arrived at about the same time. I've done some manual pushing of functions now, that work just as well - the 3D array was really just a convenient way of pushing everything, and a standard Lua-C practice. Hopefully we won't get any more compiler errors :) With regards, Daniel.
Re: svn commit: r1431215 - /httpd/httpd/branches/2.4.x/STATUS
On 01/10/2013 10:33 PM, Gregg Smith wrote: Hi Daniel, On 1/10/2013 4:55 AM, Daniel Gruno wrote: On 01/10/2013 01:52 PM, Guenter Knauf wrote: Hi Daniel, Am 10.01.2013 10:34, schrieb Daniel Gruno: Can you provide me with the errors that it produces, or some tips on how I can possibly run this compiler on my own computer? Otherwise, I really don't know what to do here - the bindings work fine on all the machines I've tested them on. Unfortunately, all the lua_pushcfunctions are nightmarish on Windows from .\lua_dbd.c(662) : error C2440: 'function' : cannot convert from 'int (__stdcall *)(lua_State *)' to 'lua_CFunction' to .\lua_dbd.c(692) : error C2440: 'function' : cannot convert from 'int (__stdcall *)(lua_State *)' to 'lua_CFunction' Casting the int function to lua_CFunction seems to work. Your 2.4 patch seems to be missing this part of r1430225 http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/lua/mod_lua.dsp?r1=1430225r2=1430224pathrev=1430225 On a side note there's this, not sure how long that's been there, it just seems wrong not having a 'case' return something. c:\build2\httpd-2.4.x_r1431331\modules\lua\mod_lua.c(110) : warning C4715: 'scope_to_string' : not all control paths return a value Cheers, Gregg Why can't we just make httpd run on UNIX and say that that's it ;) sigh, I guess I have to do some more work on this ting today, thanks for letting me know :) It's appreciated that people actually try these things out and give such good feedback as is given on the http project. With regards, Daniel.
Re: svn commit: r1431215 - /httpd/httpd/branches/2.4.x/STATUS
On 01/10/2013 10:33 PM, Gregg Smith wrote: On a side note there's this, not sure how long that's been there, it just seems wrong not having a 'case' return something. c:\build2\httpd-2.4.x_r1431331\modules\lua\mod_lua.c(110) : warning C4715: 'scope_to_string' : not all control paths return a value Cheers, Gregg That's been fixed in trunk with r1422373, just fyi (though probably not just backportable, as it was part of a larger fix to trunk code). It's not a real issue though, but yeah, it doesn't hurt to make compilers happy (most of the time). With regards, Daniel.
[Discuss] Time to rewrite/rethink modules.apache.org?
Hello dear dev@, I'd like to propose that we rewrite and rethink modules.apache.org. For those of you who detest long emails (henceforth known as the TL;DRs), just scroll to the bottom for a quick summary. While modules.a.o does provide a mediocre service to those looking for a module, I'd like to think we can do a lot better. I've split this into topics, in which I'll go through each aspect of what I find needs improvement, and which benefits could come from this, as well as some more proactive reasons as to why we should rewrite/rethink this site: - General look and feel - The first thing that strikes me about modules.a.o is that it's not so much an index, but more like a hastily thrown together list of modules. It offers no detailed insight into each module, and clicking on either a module or the browse link takes you to a search function, which at first makes you think you may have clicked the wrong link or that the site is broken. The browse feature has no categories or ways to actually index modules other than listing them alphabetically, which makes searching quite tedious. I have to use the search feature in my browser if I am to find for instance a GPL licensed module which deals with security. Browsing and searching is virtually the same, as in there is no difference between clicking the browse button or clicking the search button and searching for an empty string. This gives me the impression that the search/browse feature has never really been thought through. Out-of-datedness The site clearly shows signs of not having been updated in over a decade. You have the option between a 1.3.x or 2.x module - where is the distinction between 2.0, 2.2, 2.4 and trunk? Some modules have not been updated since 1998, yet they are still on the list? Surely, there should be some sort of limit on how many _decades_ your module can remain on that list without being updated. This should be an index of modules you can still use, not modules that only works in 1.3. - Indexing and browsing - Indexing...what indexing, there is none. Everything is just alphabetical, or you can search for something (the search page doesn't say what field you're searching?). There are no categories, no ways to limit your search other than specifying a very specific string (which probably won't match), no sorting by relevance, popularity, stability, how up-to-date the module is, etc. There is no way to limit a search to specific license - I'd like to be able to just view ASLv2 licensed modules, but I can't. -- Moderation -- The criteria for having a module listed is nowhere to be found. The approval process is a mystery (supposedly we have two people working on this, who may or may not have the time), there is no way to see if your module has been approved or rejected (as a personal experience with it, I have yet to find out if the modules I submitted last year were rejected or just mothballed for all eternity), there seems to be no reminders sent out if an approval request is not handled. Requiring a special task force seems like not-so-much the Apache Way. I'd like to see that we can collaborate as committers on this, much like we do on the comments system, where anyone within the ASF with an interest in helping out can do so, and where the procedures are both publicly described and logged in a manner that enables others to see if something requires attention. What's hip I'd like to see popular modules included as well - there is no mention of mod_php, mod_spdy, mod_pagespeed, mod_wsgi and so on, yet these are probably the modules that people are most inclined to go search for. While it's generally a good idea to let module authors contribute with their own modules to the list, I'd also like for this to be a place where you can find out more information about a particular module, even if it's a popular one with a corporation or foundation backing it. I'd also very much like the ability for people to either rate or in some way discuss modules; How they work, what could be improved, how to set them up and so on - some form of forum integration where a module can be put up for debate. I'd also like both users and/or authors to be able to rate their modules in terms of stability, usefulness (general purpose or niche product), popularity (how widespread is the use of this module?) and so forth. This could help people in need of a cookie cutter web server, as they could simply go to the site, view what's the most popular and used modules, see if/how they work, and find out where to get them. - Collaborating and eating our own dog food - Now comes the part where some (those that know me well) will chuckle, some will go pfeh!, while others may actually think this is a good idea: I'd like to
Re: mod_mruby to provide an alternative to mod_lua
On 01/20/2013 10:31 AM, MATSUMOTO Ryosuke wrote: Hi, all I'm Ryosuke MATSUMOTO, a Ph.D. student at Okabe Lab, Network Media Group Department of Intelligence Science and Technology Graduate School of Informatics, Kyoto University in Japan. My English is not very good, but I am studying at the moment to communicate developers of the world. I have been developing mod_mruby and ngx_mruby from Apr 2012. mod_mruby is a web server extension mechanism using embeddable scripting language mruby which has been attracting attention now. mod_mruby abstract: - As the increase of services using Web servers, the number of incidents also is increasing rapidly. In order to solve those problems, it is necessary to extend a functionality of a Web server software. In case of using Apache, developers are required high coding skill of C language and internal specifications of Apache in order to extend the functionality of it. The development of a web server extension requires some high skills, and the maintainability is low since that extension need to compile a code. Therefore, we propose mod_mruby that is a web server extension mechanism using embeddable scripting language mruby which has been attracting attention now. mod_mruby allows to extend the functionality of Apache easily by implementing a mruby script. mod_mruby provides an interface to hook and execute any mruby scripts in the various phases of processing requests inside Apache. When hooking mruby scripts, mruby scripts can process the data of processing requests inside Apache, taking advantage of the characteristics of a embeddable scripting language for C language. We have designed that mod_mruby run at high speed by sharing the data of state transition and the extension library of mruby by multiple mruby scripts and using only different byte code each mruby script. Many developers can implement a web server extension easily by mod_mruby in cooperation with coding style of mruby which is the same as object oriented programming ruby which is widely used by web developers. - see slide share about mod_mruby architecture and performance compared with mod_lua, mod_per, and a module written by C language.(Sorry in Japanese) http://www.slideshare.net/matsumoto_r/mrubyweb snip Hi, Matsumoto, Your project does indeed look interesting, and for those more accustomed to Ruby, perhaps this is a good alternative. I have tried to compile and install mod_mruby on my own machine to test it, but there are too many compiler errors for it to work :( In particular, you have a lot of declarations after statements in your code, which is not C90 compliant, and needs fixing. There are also some errors that force the source code to use 2.2 standards when compiling it for 2.4 or 2.5 - this also needs to be addressed: ap_mrb_connection.c:31 says: #ifdef __APACHE24__ This should probably change to: #if (AP_SERVER_MINORVERSION_NUMBER 2) I am very interested in how you got to the benchmark results you did. Statistically speaking, Ruby is a very slow language compared to Lua (and in particular LuaJIT which is extremely fast - if you attend my talk at ACNA, I'll show you just how fast ;) ). Which optimizations did you make to the configuration? Which scopes and code caching options did you use for your testing? Did you test mod_lua fom the 2.4 branch or the trunk? I'd also be interested in an English version of your slides, as there may be things to learn from it :) We embrace competition here at Apache, so mod_mruby is a most welcome addition, however I'd really like to get my hands on a working copy, so I can test it out and see what it can really do. One advantage that I could see from the source code is the ability to hook into the logging part of httpd, which is something mod_lua currently lacks. I did not see any filter hooks though - is this something you plan to add, or did I just miss it? With regards, Daniel.
Re: mod_mruby to provide an alternative to mod_lua
On 01/21/2013 07:32 AM, 松本 亮介 wrote: Hi Daniel. Thank you for your comment. I have tried to compile and install mod_mruby on my own machine to test it, but there are too many compiler errors for it to work :( In particular, you have a lot of declarations after statements in your code, which is not C90 compliant, and needs fixing. There are also some Did you built mruby? If you don't build murky, you try to build by bellow commands. - mruby and mod_mruby build git clone git://github.com/matsumoto-r/mod_mruby.git cd mod_mruby git submodule init git submodule update cd murby rake cd .. ./configure --with-apxs=/usr/local/apache/bin/apxs --with-apachectl=/usr/local/apache/bin/apachectl make make install - mod_mruby settings cp -p test/test.mrb /usr/local/apache/htdocs/. vi /usr/local/apache/conf/httpd.con (snip) LoadModule mruby_module modules/mod_mruby.so AddHandler mruby-script .mrb (snip) /usr/local/apache/bin/apachectl start - mod_mruby test http://youraddress/test.mrb snip Hi again, I did manage to finally get mod_mruby running on my test server, after a lot of tweaking of your source code. In general, you should always compile your development modules using _maintainer mode_. This can be achieved when you configure the httpd source by running ./configure --enable-maintainer-mode. This should also make apxs run using maintainer mode, which will alert you to anything about the code which doesn't sit right with httpd and the standards we have laid out. As for how the module runs, I'll include mod_mruby in my talk a bit, showing how mod_lua compares to it as well as mod_php and mod_perl on httpd 2.4 (yes, mod_perl can be built for 2.4 ;) ). While it shows a good performance - considering Ruby is generally a slow language - it does have serious performance issues once you start upping the concurrency on 2.4. At only 30 concurrent clients, I am getting a lot of disconnects and segmentation faults from mod_mruby, making it plummet down to 150 requests per second for a simple hello world script, and at 500 concurrent clients, it's as low as 50 requests per second, possibly because it crashes the server, which then has to re-spawn new workers all the time. I've uploaded a log of GDB at http://apaste.info/dsFz which you can possibly use to figure out why it's behaving like it does. There also seems to be a lot of other exceptions raised when just calling it with 1 client (mrb_exc_raise). I hope you figure these things out, as mod_mruby is a welcome addition to the http server :). If you can get it to run stable on 2.4/2.5 before ApacheCon, I'd love to try it out again and get some proper performance tests going. With regards, Daniel.
Re: mod_mruby to provide an alternative to mod_lua
On 01/21/2013 01:59 PM, 松本 亮介 wrote: Hi Daniel, I tested benchmark of mod_mruby. test case are: snip My main concern here is; is it thread-safe (or even thread-aware)? Most people will be using 2.4 with the event MPM, which is threaded, not the prefork MPM. I have no problems doing concurrency on the prefork MPM, it's with the worker/event MPM that things start to go wrong. With regards, Daniel.
Re: [Discuss] Time to rewrite/rethink modules.apache.org?
On 01/21/2013 01:02 AM, Nick Kew wrote: On 19 Jan 2013, at 23:26, Daniel Gruno wrote: Hello dear dev@, I'd like to propose that we rewrite and rethink modules.apache.org. snip As suggested by a fellow ASFer, I am going to play this a bit hard and fast, as not a lot of people really care that much about the old site in its current state. A replacement site for modules.apache.org is in the works (it's actually nearly completed already, you can see it at http://modules.humbedooh.com/ - do try it out), and as such, I'd like to propose we make the switch from the old site to the new, and start afresh with the database, as it's very lacking in its current state. Once this is done, anyone with an interest in further developing the site is most welcome to contact me, and we'll start hashing out what remains to be done (I can always think of new things to add, such as Nick's suggestion about DOAP files, possibly supporting multiple Apache projects etc). This will be done by lazy consensus; If I hear no complaints within the next 72 hours, I will consider the subject agreed upon and start upgrading the site to the new system. So, if you do have objections, I suggest you let them be heard :) But please do try out the new system before you make up your mind - it's got lots of improvements, both for visitors and module authors. With regards, Daniel.
Re: [Discuss] Time to rewrite/rethink modules.apache.org?
On 01/23/2013 01:00 AM, Eric Covener wrote: On Tue, Jan 22, 2013 at 6:08 PM, Gavin McDonald ga...@16degrees.com.au wrote: -Original Message- From: Eric Covener [mailto:cove...@gmail.com] Sent: Wednesday, 23 January 2013 9:25 AM To: dev@httpd.apache.org Subject: Re: [Discuss] Time to rewrite/rethink modules.apache.org? This will be done by lazy consensus; If I hear no complaints within the next 72 hours, I will consider the subject agreed upon and start upgrading the site to the new system. So, if you do have objections, I suggest you let them be heard :) But please do try out the new system before you make up your mind - it's got lots of improvements, both for visitors and module authors. 72hr lazy consensus is not enough to scrap the site and data that we stepped up to support in the not so distant past. hmm, how have you been supporting it since the code was moved to the infra repo ? I think you're contrasting httpd vs. infra and saying we didn't live up to our end of the bargain. I'm not disagreeing with that, and I guess step up is probably a bit misleading. What I intended to convey was that people cared about this during the last reboot (whether or not we fulfilled a committment properly), and that 72h lazy was not enough consideration for them and the submitters of data. I could be totally misunderstanding you though. Do you take issue with slowing things down or is this a tangent? Personally, I'm find with you guys objecting to a lazy consensus - it means this isn't just being ignored any more, as the site seems to have been for years, to be honest. The site is in a big need of an overhaul - there are no moderators for it currently, besides Gavin and me, and updates are done in the most painful way you can imagine. What I propose is a new site that lets authors update their modules in an easy, comfortable way, either manually adding new releases or managing it through a DOAP file, and which gives the visitors a better bang for their buck. The data we have on record now is stale, it's very sparse, and does not invite authors to do anything but just register the name of their module and a one-liner that'll hopefully get visitors attention - not much of a site if you ask me. I implore you to try out the new site, both as a regular visitor and as a (fake) module author, and see if this isn't a vast improvement of what we have. And I also ask you to consider, that with the new improvements, getting new module data will be a lot easier, and much of the scrapped data will surely come back in a hurry - except maybe for those modules that haven't been updated in this century or have been incorporated into httpd. So, for now, I'll withdraw my lazy consensus, and I'll instead put up a vote once the discussion has been had. This however requires some participation! With regards, Daniel.
Re: [Discuss] Time to rewrite/rethink modules.apache.org?
On 01/23/2013 05:07 AM, Yehuda Katz wrote: On Tue, Jan 22, 2013 at 7:10 PM, Daniel Gruno rum...@cord.dk mailto:rum...@cord.dk wrote: I implore you to try out the new site, both as a regular visitor and as a (fake) module author, and see if this isn't a vast improvement of what we have. To whom or where to we post bugs? - Y If you find a bug, post it to me or on the list, whichever you think is appropriate. Obviously, a huge gaping security hole should be posted more private ;) Since it's an infrastructure operated site, I suppose you can also post a JIRA ticket. If/once the site goes live, I suspect modules-...@httpd.apache.org would be the right place to post such bugs. For those interested in the source code, it's available at sourceforge at the moment (I did not want to trouble infrastructure or httpd by spamming svn updates on a site that's not an asf site yet) at https://sourceforge.net/p/modulesao/code/ - anyone interested is, as said earlier, most welcome to join in and make contributions. With regards, Daniel.
Re: [Discuss] Time to rewrite/rethink modules.apache.org?
On 01/23/2013 04:42 PM, Jim Jagielski wrote: On Jan 22, 2013, at 5:29 PM, Daniel Gruno rum...@cord.dk wrote: This will be done by lazy consensus; If I hear no complaints within the next 72 hours, I will consider the subject agreed upon and start upgrading the site to the new system. So, if you do have objections, I suggest you let them be heard :) But please do try out the new system before you make up your mind - it's got lots of improvements, both for visitors and module authors. -1 Veto. +1 for updating the site and all your comments and suggestions. -1 for lazy consensus. Have you contacted Infra about supporting the newly designed site? Lazy consensus was retracted in my previous email, so no need for a veto :). As to infra, yes, I am a part of the infrastructure team myself, and am in dialogue with gavin who currently operates the site. Switching to a new httpd with the works should not be a big issue - it's our software after all ;). As for the search stuff, yes I'll take a look at making globs work, though you could just click on 'Browse' and then select the 'logging' tag. With regards, Daniel. PS: DOAP file support and email notifications to authors have also been added since the time of my last email.
Re: [Discuss] Time to rewrite/rethink modules.apache.org?
On 01/23/2013 06:04 PM, Yehuda Katz wrote: On Wed, Jan 23, 2013 at 4:04 AM, Daniel Gruno rum...@cord.dk mailto:rum...@cord.dk wrote: If you find a bug, post it to me or on the list, whichever you think is appropriate. OK. Bug I found seems to be fixed (since about 2300 EST). When I clicked on the link to modules.lua on projects.lua, there was some error. Now it appears to be working. (and I just noticed that you sent me a message indicating that.) Several comments: - Clicking remove project should probably prompt Are you sure?. - It would be nice if the title would change based on the page you are on so that it is easier to use the browser's back/forward and history. - Y Yeah, I saw the bug and got it fixed - it appears to be a standard lua error that usually requires a small workaround. Yes, clicking remove should prompt - I'll add that, thanks for the tip :) And as for the title, I'll get around to that as well :) With regards, Daniel.
HTTPd hackathon at ACNA 2013
Hi folks, For those of you going to ACNA (And I hope it's a lot of you..!), we have a petition for a hackathon set up at http://wiki.apache.org/apachecon/HackathonNA13 - if you're interested, please bump the number a bit, so the producer etc can see that we need a spot if so. With regards, Daniel.
Re: [Discuss] Time to rewrite/rethink modules.apache.org?
On 01/23/2013 06:04 PM, Yehuda Katz wrote: On Wed, Jan 23, 2013 at 4:04 AM, Daniel Gruno rum...@cord.dk mailto:rum...@cord.dk wrote: If you find a bug, post it to me or on the list, whichever you think is appropriate. OK. Bug I found seems to be fixed (since about 2300 EST). When I clicked on the link to modules.lua on projects.lua, there was some error. Now it appears to be working. (and I just noticed that you sent me a message indicating that.) Several comments: - Clicking remove project should probably prompt Are you sure?. Done - It would be nice if the title would change based on the page you are on so that it is easier to use the browser's back/forward and history. Also done :) - Y Furthermore, comments have been enabled through comments.apache.org, so visitors and authors can discuss the modules on the site. I had some talks with various people about how best to transition from the old site to the new, and what we could agree on was as follows: - The new site will have a link to the old site (which will be relocated for the time being, before ultimately being scrapped at some point in the distant future, once enough modules have migrated). This means the old database will be retained for now, until we come to a decision as to what should happen with it. - Authors who have added modules to the old site will be informed of the new site and asked to please resubmit their module for approval. I am also pleased to say that the DOAP features are running smoothly, and should prove useful to those who prefer using DOAP over manually adding releases and editing their module information. Each project has a DOAp page where module authors can view their current (auto-generated) DOAP file with instructions on how to switch to DOAP, should they choose to do so. Given the response after my 'hard and fast' play, which I am pleased to say stirred things up a bit, I will let people try out the site for another few days, before I will propose a regular vote to transition to the new system. I hope people will try out every feature the new site has to offer (you can just make a fake module if you like), and view the upcoming vote as a decision to move forward, rather than whatever things could be done better with the new system. We can always improve on things, but the important thing is that we move onto a new system that provides a much better service for visitors. With regards, Daniel.
Re: [Discuss] Time to rewrite/rethink modules.apache.org?
On 01/24/2013 08:11 PM, Helmut Tessarek wrote: On 22.01.13 17:29 , Daniel Gruno wrote: works (it's actually nearly completed already, you can see it at http://modules.humbedooh.com/ - do try it out), and as such, I'd like to Looks nice. 2 comments though: 1) If you browse the modules and click on a tag, you can't reset it. You can only switch to a different/new tag, but you can't unset the tag you selected. 2) Something wrong with the search algorithm. If you search for 'nz' (w/o the quotes), you get the following result: mod_authz_dynamic mod_authnz_subrequest There is no 'nz' in 'mod_authz_dynamic'. Cheers, Helmut Although you could just click on 'browse modules' again, I'll take your suggestion into consideration :) Perhaps clicking the green tag button should just reset to 'no tags' As for the search, you're not just searching the module names, you're also searching the description of the modules. There appears to be a typo in the longer description of mod_authz_dynamic, erroneously claiming its name to be 'mod_authnz_dynamic', which is why it turns up when you search for 'nz' (or 'authnz'). We can discuss changing what exactly is being searched when a user enter a string, but perhaps such issues of fine tuning the engine is better put to purpose in a separate thread when the site has migrated and is free of any bugs that may be there. With regards, and thanks for your suggestion and review, Daniel.
Re: [Discuss] Time to rewrite/rethink modules.apache.org?
On 01/24/2013 08:51 PM, Helmut Tessarek wrote: On 24.01.13 14:18 , Daniel Gruno wrote: Although you could just click on 'browse modules' again, I'll take your suggestion into consideration :) Perhaps clicking the green tag button should just reset to 'no tags' Yes, I saw that you can do that. As long as there are only a few tags, I guess just clicking on browse again will do. Also, in browse you can only select one tag. In search you can select more than just one. Just mentioning it, since it is an inconsistency. Browse is meant to be a view of modules put into categories, whereas a search can be a more complex way of 'browsing' the site. You could argue that the two should be alike, but then you could also argue that it would confuse someone who is looking at one tag, then wants to switch to another, that he/she first have to remove one tag and add a new, or it'd display those modules who have both tags, so it's a trade-off between simplicity and complexity. For me, the browse feature should just be a fast way to see the most popular modules in each respective category, not in any way a complex tool for searching, as the search feature does that just fine. As for the search, you're not just searching the module names, you're also searching the description of the modules. There appears to be a typo in the longer description of mod_authz_dynamic, erroneously claiming its name to be 'mod_authnz_dynamic', which is why it turns up when you search for 'nz' (or 'authnz'). Ok, I was only looking at the result that was displayed and I could not find the 'nz' in the name of the module, nor the short description. That is one thing to consider, indeed; Whether the search term should be highlighted/shown within each result, so you know what your query hit inside that particular module. I'll give it some consideration/experimenting. We can discuss changing what exactly is being searched when a user enter a string, but perhaps such issues of fine tuning the engine is better put to purpose in a separate thread when the site has migrated and is free of any bugs that may be there. Sure, I've several ideas. :-) Ideas are always welcome, in fact the entire web site is available in Subversion for those interested, But as I said earlier, perhaps that's better suited for another thread (I'll be sure to post such a thread once we actually start migrating). I believe we can both implement and improve the new system at the same time, one thing doesn't have to put a stop to the other. With regards, Daniel.
Re: [Discuss] Time to rewrite/rethink modules.apache.org?
Okay, some final things before I start flinging vote messages about: - DOAP files will, for the time being, only be possible for Apache committers putting their DOAP files into people.apache.org. This is due to a very strict firewall policy by Infrastructure, to which I agree. I will look into ways of solving this issue, so we can hopefully, at one point, have everyone using DOAP. - The old modules.a.o archive will move to modules-archive.apache.org, where it will live happily ever after, or until we decide to scrap it completely. - Authors that have created or updated a module within the last two years will be notified that there is a new site, and encouraged to submit their modules to this site. - We are, as always, looking for volunteers!! If you'd like to help out managing the modules.apache.org site, please do speak up. We will be possibly adding some LDAP tie-ins later, making Apache committers moderators by default, but that is for another thread to discuss in. Currently, we will be only allowing Apache committers to apply as moderators, but we will be having a discussion about that in the other thread I'll start. - As said, I will be posting two threads, one voting thread and one discussion thread about feature requests and such for the site. That is all - at sunrise, look to the east...or look to the mailing list (tilt your screen to the west, please, it makes for a more dramatic entrance) With regards, Daniel.
[Vote] Overhaul modules.apache.org
So, this is when we get to vote on things! I am satisfied that the new site is working as intended, and that new requests for features can be integrated and reviewed, as the site is publicly available in svn (in the infrastructure repository). Now, the vote deals with a lot of things, so I'd like you to read the proposal carefully. Proposal 1) Move the current modules.apache.org to modules-archive.apache.org 2) Create a link on both modules.apache.org and modules-archive.apache.org linking to each other. 3) Replace modules.apache.org with the new modules site, currently available at http://modules.humbedooh.com and also available in svn for review. 4) Start afresh with a new, empty database on modules.apache.org and have modules-archive.apache.org retain the old database. 5) Contact all authors who have created or modified a module on the site within the last 2 years (this is 59 authors), and inform them of the new site, encouraging them to resubmit their modules. 6) Allow modules.apache.org to fetch DOAP files for projects, placed anywhere on the Internet, thus acting as an aggregator of publicly available information. Vote [ ] +1: I support this proposal [ ] 0: I don't care [ ] -1: I don't support this proposal, because... This vote will remain open for at least 72 hours, thus ending, at earliest, on Monday, January 28th, 13:20 GMT. Standard majority consensus applies, as it has with all other web site changes. With regards, Daniel.
Re: [Vote] Overhaul modules.apache.org
On 01/25/2013 02:21 PM, Daniel Gruno wrote: Vote [ X ] +1: I support this proposal [ ] 0: I don't care [ ] -1: I don't support this proposal, because... This vote will remain open for at least 72 hours, thus ending, at earliest, on Monday, January 28th, 13:20 GMT. Standard majority consensus applies, as it has with all other web site changes. With regards, Daniel. Adding my own +1.
Re: [Vote] Overhaul modules.apache.org
On 01/25/2013 04:00 PM, Jim Jagielski wrote: On Jan 25, 2013, at 8:21 AM, Daniel Gruno rum...@cord.dk wrote: Proposal 1) Move the current modules.apache.org to modules-archive.apache.org And made read-only, right? Yes, it will be a read only archive - no sense in fooling authors into posting on the old site as well as the new one (also, the approval process there makes me nauseous). With regards, Daniel.
Re: [Vote] Overhaul modules.apache.org
On 01/25/2013 11:01 PM, Nick Kew wrote: On 25 Jan 2013, at 13:21, Daniel Gruno wrote: [ ] +1: I support this proposal [ ] 0: I don't care [ ] -1: I don't support this proposal, because... -1 as stated. +1 in principle. IMHO it needs a tiny change. Instead of creating a messy new DNS entry for modules-archive, it should live under a single hostname: maybe modules.apache.org/archive/ I can't access modules.humbedooh.com right now, but I'll take what's there as of secondary importance: it's presumably intended more as startingpoint than final product. If people do not object to this, I believe we can accommodate your wish to put it under /archive instead without having to resort to a new vote. Anyone who's opposed to Nick's suggestion, please state so, or I will assume that we can continue the voting with this addendum. Apologies for the test site not being available at the time, it has been fixed now. And yes, it's a starting point. The whole point of this vote is to get _started_ on moving away from something that is utterly dysfunctional, and towards something that works and is simpler to manage. Once the voting is done, assuming no one starts throwing vetoes about, I will start a new thread, calling for ideas and suggestions on how to improve the new site, and as I've stated earlier, I am looking for anyone who would like to contribute to maintaining and improving the site. As it stands, we have Rich, Gavin, Jan from Infrastructure (I hope/think) and myself doing moderation and reviewing the processes, but we'd like more to join. With regards, Daniel.
Re: [Discuss] Time to rewrite/rethink modules.apache.org?
On 01/25/2013 11:39 PM, Helmut Tessarek wrote: On 25.01.13 5:24 , Daniel Gruno wrote: - Authors that have created or updated a module within the last two years will be notified that there is a new site, and encouraged to submit their modules to this site. I know, I don't have the right to vote, but I still would like to know, why you don't migrate the 'old' data to the new site? If you want to get rid of unmaintained modules this is one thing, but there might be modules on the old site that are still valid despite the fact that they haven't been touched within the last 2 years. With the 'old' data, you can at least populate all fields (except the long description). - We are, as always, looking for volunteers!! If you'd like to help out managing the modules.apache.org site, please do speak up. We will be possibly adding some LDAP tie-ins later, making Apache committers moderators by default, but that is for another thread to discuss in. Currently, we will be only allowing Apache committers to apply as moderators, but we will be having a discussion about that in the other thread I'll start. Ok, what does 'managing' the site mean? How many hours do you have to put in per week/month (just a ballpark)? I'd be interested. Cheers. The old data is simply incompatible with the new system, and we have no way of knowing which modules still exist except to to through them all manually (mind you, this is a lot of records) and check. The new system is based on a lot more parameters (such as tags, multiple release versions, short and long descriptions, detailed author profiles, component entries etc), which would throw every module from the old site into a muddied miscellaneous category from which there would be no escape, unless each author manually updated the records, which is unlikely for the majority of the modules. Furthermore, we cannot migrate the old userbase, as it's incompatible and severely outdated in terms of security (I will not go into specifics, you will have to trust me on this one), so the modules would not be able to be coupled with an author, and thus no one would have access to update them, unless we simply gave Carte Blanche to do so...which would require at least as much effort as simply creating the module on the new site. What I have proposed instead is that we contact any author who has created/updated a module within the last two years, inviting them to spend 2 minutes on the site, recreating their module information. Managing the site means approving new modules as they arrive. The process is quite simple: 1) A module is registered in the database 2) An email is sent to modules-...@httpd.apache.org 3) Site admins verify that the module is not bogus 4) You click on an 'approve' or a 'reject' button, and that's it. 5) Authors are notified of approval or rejection of the module. I'd estimate this to require between 5 minutes and half an hour per week at most, maybe a bit more in the beginning. With regards, Daniel.
Re: [Discuss] Time to rewrite/rethink modules.apache.org?
On 01/25/2013 11:39 PM, Helmut Tessarek wrote: On 25.01.13 5:24 , Daniel Gruno wrote: - Authors that have created or updated a module within the last two years will be notified that there is a new site, and encouraged to submit their modules to this site. I know, I don't have the right to vote, .. Everybody has the right to vote, but not every vote counts. We appreciate your opinion as much as the next person, and you're very welcome to vote on the issue. But I feel I must state again, that this is as much a vote about moving forward as it is a vote about specifics. The old database will remain untouched, and if at any point in time, we find a way to reintegrate the old data, we can do so if we choose. But I find if very unlikely, having looked at the internals of the old system. With regards, Daniel.
[Result] [Vote] Overhaul modules.apache.org
With the clock passing 13:20 GMT, the voting has ended, and been tallied. There was some concern about the DNS solution in the proposal, which has been adjusted to a subdirectory instead (and all URLs on the old site has been adjusted to use relative hrefs), and with no objections to that, the votes are as follows: +1: 15(13) - humbedooh, trawick, rpluem, jim, niq, fuankg, gsmith, rbowen, minfrin, rjung, sfritsch, covener, fielding, gmcdonald (ex officio, non-binding in this case), matsumoto (non-binding) 0: none -1: none And thus, I am pleased to say the vote passes. I will begin prepping bil (the machine on which all of this runs) for the new site and piggyback the old site onto the new one. I will also send out an email to module maintainers, informing them of the new site, once it's up and running well. I will also start a thread on modules-...@httpd.apache.org to get some suggestions and reviews coming in at a steady pace. Thanks for your votes and support, and I hope to see you enjoying the new site! With regards, Daniel, on behalf of the team behind the new site. PS: We are now 4 people working on the site, but if anyone else would like to volunteer, we can always use an extra helping hand. Proposal (for record keeping's sake) 1) Move the current modules.apache.org to modules.apache.org/archive 2) Create a link on both modules.apache.org and modules.apache.org/archive linking to each other. 3) Replace modules.apache.org with the new modules site, currently available at http://modules.humbedooh.com and also available in svn for review. 4) Start afresh with a new, empty database on modules.apache.org and have modules-archive.apache.org retain the old database. 5) Contact all authors who have created or modified a module on the site within the last 2 years (this is 59 authors), and inform them of the new site, encouraging them to resubmit their modules. 6) Allow modules.apache.org to fetch DOAP files for projects, placed anywhere on the Internet, thus acting as an aggregator of publicly available information.
[Vote] Overhaul modules.apache.org (second try)
Apologies for my email client apparently adding an in-reply-to which was not intended. This seems to have caused some difficulties for some people reading this vote as a part of the discussion thread, which it was not. As a result, some people may not have had seen the opportunity to vote, and therefore, I'll extend the voting for another 72 hours, so people can be heard properly. The previous votes will still be counted towards the end result, so there is no need to recast your vote if you've already voted. With regards, Daniel. Previous vote email follows, for reference: --- With the clock passing 13:20 GMT, the voting has ended, and been tallied. There was some concern about the DNS solution in the proposal, which has been adjusted to a subdirectory instead (and all URLs on the old site has been adjusted to use relative hrefs), and with no objections to that, the votes are as follows: +1: 15(13) - humbedooh, trawick, rpluem, jim, niq, fuankg, gsmith, rbowen, minfrin, rjung, sfritsch, covener, fielding, gmcdonald (ex officio, non-binding in this case), matsumoto (non-binding) 0: none -1: none And thus, I am pleased to say the vote passes. I will begin prepping bil (the machine on which all of this runs) for the new site and piggyback the old site onto the new one. I will also send out an email to module maintainers, informing them of the new site, once it's up and running well. I will also start a thread on modules-...@httpd.apache.org to get some suggestions and reviews coming in at a steady pace. Thanks for your votes and support, and I hope to see you enjoying the new site! With regards, Daniel, on behalf of the team behind the new site. PS: We are now 4 people working on the site, but if anyone else would like to volunteer, we can always use an extra helping hand. Proposal (for record keeping's sake) 1) Move the current modules.apache.org to modules.apache.org/archive 2) Create a link on both modules.apache.org and modules.apache.org/archive linking to each other. 3) Replace modules.apache.org with the new modules site, currently available at http://modules.humbedooh.com and also available in svn for review. 4) Start afresh with a new, empty database on modules.apache.org and have modules-archive.apache.org retain the old database. 5) Contact all authors who have created or modified a module on the site within the last 2 years (this is 59 authors), and inform them of the new site, encouraging them to resubmit their modules. 6) Allow modules.apache.org to fetch DOAP files for projects, placed anywhere on the Internet, thus acting as an aggregator of publicly available information.
[Result] [Vote] Overhaul modules.apache.org (second try)
With another 72 hours passed and no new votes cast, I am satisfied that the motion has been carried, so to speak. I'll get started preparing the new site and contacting old authors/maintainers. With regards, Daniel. Previous vote email follows, for reference: --- With the clock passing 13:20 GMT, the voting has ended, and been tallied. There was some concern about the DNS solution in the proposal, which has been adjusted to a subdirectory instead (and all URLs on the old site has been adjusted to use relative hrefs), and with no objections to that, the votes are as follows: +1: 15(13) - humbedooh, trawick, rpluem, jim, niq, fuankg, gsmith, rbowen, minfrin, rjung, sfritsch, covener, fielding, gmcdonald (ex officio, non-binding in this case), matsumoto (non-binding) 0: none -1: none And thus, I am pleased to say the vote passes. I will begin prepping bil (the machine on which all of this runs) for the new site and piggyback the old site onto the new one. I will also send out an email to module maintainers, informing them of the new site, once it's up and running well. I will also start a thread on modules-...@httpd.apache.org to get some suggestions and reviews coming in at a steady pace. Thanks for your votes and support, and I hope to see you enjoying the new site! With regards, Daniel, on behalf of the team behind the new site. PS: We are now 4 people working on the site, but if anyone else would like to volunteer, we can always use an extra helping hand. Proposal (for record keeping's sake) 1) Move the current modules.apache.org to modules.apache.org/archive 2) Create a link on both modules.apache.org and modules.apache.org/archive linking to each other. 3) Replace modules.apache.org with the new modules site, currently available at http://modules.humbedooh.com and also available in svn for review. 4) Start afresh with a new, empty database on modules.apache.org and have modules-archive.apache.org retain the old database. 5) Contact all authors who have created or modified a module on the site within the last 2 years (this is 59 authors), and inform them of the new site, encouraging them to resubmit their modules. 6) Allow modules.apache.org to fetch DOAP files for projects, placed anywhere on the Internet, thus acting as an aggregator of publicly available information.
Re: [VOTE] Release Apache httpd 2.4.4 as GA
On 02/18/2013 09:34 PM, Jim Jagielski wrote: The pre-release test tarballs for Apache httpd 2.4.4 can be found at the usual place: http://httpd.apache.org/dev/dist/ I'm calling a VOTE on releasing these as Apache httpd 2.4.4 GA. NOTE: The -deps tarballs are included here *only* to make life easier for the tester. They will not be, and are not, part of the official release. [ ] +1: Good to go [ ] +0: meh [ ] -1: Danger Will Robinson. And why. Vote will last the normal 72 hrs. +1 on FreeBSD 9.0 with maintainer mode and Lua enabled. configured fine, built fine, worked out of the box. I have also been running 2.4.4 on modules.apache.org for some time now (albeit a few revisions short of the hopefully official 2.4.4), and so far no problems have arisen. I got a few failures with the test framework, but that seems to mostly be failures with the framework itself, notably IP expression/access tests failed because I apparently wasn't connecting from 127.0.0.1 in the tests. With regards, Daniel.
