Re: svn commit: r733221 - in /httpd/apreq/branches/v2_10: include/apreq_version.h library/module_cgi.c library/parser.c module/apache2/handle.c
On Mon, 2009-01-12 at 06:32 -0800, Joe Schaefer wrote: Are you planning to pursue 2.10 as RM or should we be moving on to 2.11? The only outstanding issue I am aware of is pgollucci's claim that the perl modules aren't linking correctly to libapreq2 on Solaris. While that would be nice to fix, I don't consider it a showstopper either. I'm kinda waiting for the outcome of that discussion on the list before we go ahead. From what I can see, current decision is to have 2.11 released, right? If so, let's roll that (I'm not attached to version numbers in any way). -- Bojan
Re: svn commit: r733221 - in /httpd/apreq/branches/v2_10: include/apreq_version.h library/module_cgi.c library/parser.c module/apache2/handle.c
Joe Schaefer wrote: - Original Message From: Bojan Smojver bo...@rexursive.com To: Joe Schaefer joe_schae...@yahoo.com Cc: Issac Goldstand mar...@beamartyr.net; apreq-dev@httpd.apache.org Sent: Monday, January 12, 2009 11:09:23 AM Subject: Re: svn commit: r733221 - in /httpd/apreq/branches/v2_10: include/apreq_version.h library/module_cgi.c library/parser.c module/apache2/handle.c On Mon, 2009-01-12 at 06:32 -0800, Joe Schaefer wrote: Are you planning to pursue 2.10 as RM or should we be moving on to 2.11? The only outstanding issue I am aware of is pgollucci's claim that the perl modules aren't linking correctly to libapreq2 on Solaris. While that would be nice to fix, I don't consider it a showstopper either. I'm kinda waiting for the outcome of that discussion on the list before we go ahead. From what I can see, current decision is to have 2.11 released, right? If so, let's roll that (I'm not attached to version numbers in any way). I've looked over pgollucci's build tree on the perl zone and confirmed that the perl .so modules cannot locate either libapreq2 nor libapr. We may need to add more rpath-related stuff to our linking flags. With respect to 2.10 or 2.11, it all depends on what we wanna do with that v2_10 branch. It's current now, and I don't mind keeping it synced with trunk if someone's planning to release from it this week. But if not, I think we should move on to 2.11. Regardless of that, I'd like to merge in the enhanced-cgi stuff later in the week. So we can either do 2 consecutive releases or get 2.10 out the door now and re-vote on 2.11 in another week or so.
RANT: what a dead project looks like
Dead projects typically have a bus-factor of 1, where committers have all gotten into the habit of waiting for one another to come along for the ride. It's true that somebody has to drive the bus, but the driver should rotate (and is named RM). The only person allowed to set a schedule for a healthy project is an RM, everyone else is only allowed to block progress by using their voting rights. This bs we tell each other about things we all plan to do soon needs to come to a close if we're ever going to be able to handle the support load httpd may be asking us to take on.
Re: svn commit: r733493 - in /httpd/httpd/trunk: CHANGES docs/man/rotatelogs.8 docs/manual/programs/rotatelogs.xml support/rotatelogs.c
On Sun, Jan 11, 2009 at 05:36:07PM -, rj...@apache.org wrote: Author: rjung Date: Sun Jan 11 09:36:07 2009 New Revision: 733493 URL: http://svn.apache.org/viewvc?rev=733493view=rev Log: Allow to trigger rotatelogs log file rotation from using HUP and INT signals to the rotatelogs process. This is helpful, when log activity is low, but you want rotatelogs to close the open log files. Sending SIGTERM to the rotatelogs process and having the parent recycle it should have done that already, surely, without adding all this complexity to rotatelogs? A lot of the stuff you're doing in the new signal handler is not async-signal safe, so -1. (closeFile notably calls pool functions) joe
Re: mod_lua headers_out
On Mon, Jan 12, 2009 at 5:23 AM, Brian McCallister bri...@skife.org wrote:
Bertrand,
I just send in a patch on the message with subject patch for handling
headers_in and headers_out as tables in mod_lua which takes knowledge
of setting headers_in, headers_out off the request which, with that
patch, can just push the apr_table_t as a boxed pointer allowing
lua-style [] access and modification.
Does that work?
Yes, it will work, thank you :)
The advantage of having a function instead of a table for setting
headers_in/headers_out is that you can use luaL_checkstring() to make
sure the given parameters are of the correct type. I don't know what
the patch will return if someone tries to set a table like in
headers_out['Foo'] = {Bar = 'baz'}
Maybe it is possible to set a metatable for headers_in/headers_out
that would check on __index and __newindex if the value validates with
luaL_checkstring (just thinking out loud).
Re: svn commit: r733493 - in /httpd/httpd/trunk: CHANGESdocs/man/rotatelogs.8 docs/manual/programs/rotatelogs.xmlsupport/rotatelogs.c
On 12.01.2009 10:04, Joe Orton wrote: On Sun, Jan 11, 2009 at 05:36:07PM -, rj...@apache.org wrote: Author: rjung Date: Sun Jan 11 09:36:07 2009 New Revision: 733493 URL: http://svn.apache.org/viewvc?rev=733493view=rev Log: Allow to trigger rotatelogs log file rotation from using HUP and INT signals to the rotatelogs process. This is helpful, when log activity is low, but you want rotatelogs to close the open log files. Sending SIGTERM to the rotatelogs process and having the parent recycle it should have done that already, surely, without adding all this complexity to rotatelogs? Thanks for the hint. In fact I just tested it and it does work for rotatelogs used in CustomLog, but not for the ErrorLog one. That one simply dies, no automatic restart and further error messages are lost (quickly tested on Solaris, and only with 2.2.x, needs some further testing for trunk). A lot of the stuff you're doing in the new signal handler is not async-signal safe, so -1. (closeFile notably calls pool functions) Yes. I'll see whether I could safely work around that. After I will have investigated more about your above hint and the possibilities of implementing it async signal safe, we might have another check, whether the use case makes sense as an internal functionality of rotatelogs or not? Regards, Rainer
Re: accept mod_fcgid codebase into httpd project
On Jan 12, 2009, at 12:53 PM, William A. Rowe, Jr. wrote: Based on the enthusiasm of the module authors to adopt the AL and offer the mod_fcgid code to the httpd community, please vote +/-1 [ ] Accept mod_fcgid into httpd +1 S. -- Sander Temme scte...@apache.org PGP FP: 51B4 8727 466A 0BC3 69F4 B7B8 B2BE BC40 1529 24AF smime.p7s Description: S/MIME cryptographic signature
Re: accept mod_fcgid codebase into httpd project
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Jan 12, 2009, at 12:53 PM, William A. Rowe, Jr. wrote: Based on the enthusiasm of the module authors to adopt the AL and offer the mod_fcgid code to the httpd community, please vote +/-1 [ ] Accept mod_fcgid into httpd +1 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAklrIPcACgkQ7bEFiW+VItiftwCdEEcYZnrBUo0qvqfm5xswAc8g jk8AoL1+ho/KrjAe6lnIMjDpeBZfVRzV =vG/V -END PGP SIGNATURE-
Re: svn commit: r733493 - in /httpd/httpd/trunk: CHANGESdocs/man/rotatelogs.8 docs/manual/programs/rotatelogs.xmlsupport/rotatelogs.c
On 12.01.2009 11:19, Rainer Jung wrote: On 12.01.2009 10:04, Joe Orton wrote: On Sun, Jan 11, 2009 at 05:36:07PM -, rj...@apache.org wrote: Author: rjung Date: Sun Jan 11 09:36:07 2009 New Revision: 733493 URL: http://svn.apache.org/viewvc?rev=733493view=rev Log: Allow to trigger rotatelogs log file rotation from using HUP and INT signals to the rotatelogs process. This is helpful, when log activity is low, but you want rotatelogs to close the open log files. Sending SIGTERM to the rotatelogs process and having the parent recycle it should have done that already, surely, without adding all this complexity to rotatelogs? Thanks for the hint. In fact I just tested it and it does work for rotatelogs used in CustomLog, but not for the ErrorLog one. That one simply dies, no automatic restart and further error messages are lost (quickly tested on Solaris, and only with 2.2.x, needs some further testing for trunk). It's the same for trunk: CustomLog automatically gets respawned, ErrorLog not. The code uses ap_open_piped_log() in server/log.c to open access logs. This in turn uses piped_log_spawn(), which registers piped_log_maintenance() using apr_proc_other_child_register(). In piped_log_maintenance() the logger is automatically restarted using again piped_log_spawn(), when the conditions for restarting are appropriate. All this is true if AP_HAVE_RELIABLE_PIPED_LOGS is defined. ErrorLog is handled by open_error_log() also in server/log.c. This calls log_child(), which uses apr_proc_create() to create the logger, but does not register any restarter. When AP_HAVE_RELIABLE_PIPED_LOGS is not set, access log handling works like error log handling, i.e. without automatic restart. Reliable piped logs seem to be used, whenever APR defines APR_HAS_OTHER_CHILD, which seems to be true by default (no auto-detection). Does it make sense to add the reliable piped logs way of handling loggers to the error log? Or is there any known dependency between the code used in ap_open_piped_log() and the error log itself? Regards, Rainer
Re: accept mod_fcgid codebase into httpd project
On 12.01.2009 04:53, William A. Rowe, Jr. wrote: Based on the enthusiasm of the module authors to adopt the AL and offer the mod_fcgid code to the httpd community, please vote +/-1 [+1] Accept mod_fcgid into httpd
Re: accept mod_fcgid codebase into httpd project
On Jan 11, 2009 10:53pm, William A. Rowe, Jr. wr...@rowe-clan.net wrote: Based on the enthusiasm of the module authors to adopt the AL and offer the mod_fcgid code to the httpd community, please vote +/-1 [+1] Accept mod_fcgid into httpd And Thanks! to the mod_fcgid author and contributors!
Re: httpd build variables
On Sat, Jan 03, 2009 at 02:55:24PM +0100, Rainer Jung wrote: Most build variables for httpd are used via APACHE_SUBST, which means they get added to build/config_vars.mk. A) Where to define them? There are two places, were a lot of ariables are added via APACHE_SUBST: 1) Macro APACHE_GEN_CONFIG_VARS Defined in acinclude.m4 and called in configure.in. It contains 75 calls to APACHE_SUBST. 2) Directly in configure.in It contains about 21 calls to APACHE_SUBST. Is there any concept, whether APACHE_SUBST for a new variable should be put into APACHE_GEN_CONFIG_VARS or directly into configure.in? Generally, I'd put new SUBST calls in configure.in, grouped near to the places where the new variables are being defined. I can see that the ones in the macro will be included last into config_vars.mk, but apart from that any rules? Not really, it's a bit random! B) Should they be installed? The script build/config_vars.sh deletes a lot of variables before installing build/config_vars.mk. Is there any concept, which variables should get installed, and which ones should be removed before installing the file? It should be trimmed by config_vars.sh unless you have a good reason why an external module would need to use the new variable at build time. Generally, I'd say: try to export as little as possible in config_vars.mk because otherwise it becomes part of the API and some third-party module will depend on it. Regards, Joe
Re: accept mod_fcgid codebase into httpd project
William A. Rowe, Jr. wrote: Based on the enthusiasm of the module authors to adopt the AL and offer the mod_fcgid code to the httpd community, please vote +/-1 [ ] Accept mod_fcgid into httpd +1 ciao... -- Lars Eilebrecht l...@eilebrecht.net
Re: accept mod_fcgid codebase into httpd project
traw...@gmail.com wrote: [+1] Accept mod_fcgid into httpd +1 And Thanks! to the mod_fcgid author and contributors! +1 to that, too. -- Nick Kew
Re: accept mod_fcgid codebase into httpd project
On Sun, Jan 11, 2009 at 10:53 PM, William A. Rowe, Jr. wr...@rowe-clan.net wrote: Based on the enthusiasm of the module authors to adopt the AL and offer the mod_fcgid code to the httpd community, please vote [ ] Accept mod_fcgid into httpd +1 -- Eric Covener cove...@gmail.com
Re: svn commit: r733702 - /httpd/httpd/branches/2.2.x/STATUS
rpl...@apache.org wrote: Author: rpluem Date: Mon Jan 12 03:53:17 2009 New Revision: 733702 + * mod_proxy_http: Add server_rec to ap_log_error() calls for interim + response messages +trunk + http://svn.apache.org/viewvc?rev=733127view=rev + http://svn.apache.org/viewvc?rev=733219view=rev +2.2.x: + trunk works + PATCHES PROPOSED TO BACKPORT FROM TRUNK: Oops ... - * mod_proxy_http: Add server_rec to ap_log_error() calls for interim - response messages -trunk - http://svn.apache.org/viewvc?rev=733127view=rev - http://svn.apache.org/viewvc?rev=733219view=rev -2.2.x: - trunk works -+1: covener, niq, rpluem -- Nick Kew
VH/NVH: _default_ vs *, do we need both?
I've always had difficulty understanding how _default_ and * in NameVirtualHost and VirtualHost differ. It sure seems like they don't, in any meaningful way (save that NVH _default_ warns but still works). They both end up in the default_list, so neither covers up more specific host/port specfications and both are of course factored into the initial ip-based mapping. Does anyone have a use case or example that actually behaves differently when you change one from the other? Any chance we can drop _default_ servers from trunk and simplify our doc? -- Eric Covener cove...@gmail.com
Re: Re: Graceful restart not so graceful?
On Jan 11, 2009 11:34am, Stefan Fritsch s...@sfritsch.de wrote: Hi, thanks for following up on this and sorry for the late response. On Wednesday 07 January 2009, Jeff Trawick wrote: Initial testing of your idea for a timeout was promising. I couldn't reproduce any hangs under linux with the patch you commited to trunk. Thanks for all of your work on this issue! In my patch I tried to avoid that an idle apache wakes periodically for no good reasons. But if you don't think that is a problem, please backport your patch to 2.2.x. I'd also prefer that prefork doesn't wake up unless it has work, but I think the simpler, localized change which was committed will be less trouble in the long run. wrt backporting: I think that modern Linux and modern Solaris, perhaps the only platforms tested so far, both work for the same reason under the covers. Has anyone tested with regular poll()? If not, I can try to test another platform or at least dumb down APR to bypass epoll/event queue/etc.
Re: svn commit: r733756 - in /httpd/httpd/branches/2.2.x: ./ STATUS docs/ docs/conf/mime.types modules/proxy/mod_proxy_http.c support/ab.c support/suexec.c
On Mon, Jan 12, 2009 at 8:56 AM, j...@apache.org wrote: Author: jim Date: Mon Jan 12 05:56:19 2009 New Revision: 733756 URL: http://svn.apache.org/viewvc?rev=733756view=rev Log: Merge r733127, r733219 from trunk: pass a server_rec to ap_log_error on two interim response messages use ap_log_rerror instead of r-server per niq's comments Submitted by: covener Reviewed/backported by: jim Modified: httpd/httpd/branches/2.2.x/ (props changed) httpd/httpd/branches/2.2.x/STATUS httpd/httpd/branches/2.2.x/docs/ (props changed) httpd/httpd/branches/2.2.x/docs/conf/mime.types (props changed) httpd/httpd/branches/2.2.x/modules/proxy/mod_proxy_http.c httpd/httpd/branches/2.2.x/support/ab.c (props changed) httpd/httpd/branches/2.2.x/support/suexec.c (props changed) I'm a bit of an svn newbie, but is this stuff that came along for the ride harmless? -- Eric Covener cove...@gmail.com
Re: svn commit: r733756 - in /httpd/httpd/branches/2.2.x: ./ STATUS docs/ docs/conf/mime.types modules/proxy/mod_proxy_http.c support/ab.c support/suexec.c
-Ursprüngliche Nachricht- Von: Eric Covener Gesendet: Montag, 12. Januar 2009 15:02 An: dev@httpd.apache.org Betreff: Re: svn commit: r733756 - in /httpd/httpd/branches/2.2.x: ./ STATUS docs/ docs/conf/mime.types modules/proxy/mod_proxy_http.c support/ab.c support/suexec.c On Mon, Jan 12, 2009 at 8:56 AM, j...@apache.org wrote: Author: jim Date: Mon Jan 12 05:56:19 2009 New Revision: 733756 URL: http://svn.apache.org/viewvc?rev=733756view=rev Log: Merge r733127, r733219 from trunk: pass a server_rec to ap_log_error on two interim response messages use ap_log_rerror instead of r-server per niq's comments Submitted by: covener Reviewed/backported by: jim Modified: httpd/httpd/branches/2.2.x/ (props changed) httpd/httpd/branches/2.2.x/STATUS httpd/httpd/branches/2.2.x/docs/ (props changed) httpd/httpd/branches/2.2.x/docs/conf/mime.types (props changed) httpd/httpd/branches/2.2.x/modules/proxy/mod_proxy_http.c httpd/httpd/branches/2.2.x/support/ab.c (props changed) httpd/httpd/branches/2.2.x/support/suexec.c (props changed) I'm a bit of an svn newbie, but is this stuff that came along for the ride harmless? Yeah. These are updates to the mergeinfo properties of these resources. I don't know why this only happens on those resources. You need to have a svn client = 1.5.0 to have this happen I guess. Regards Rüdiger
Re: svn commit: r733221 - in /httpd/apreq/branches/v2_10: include/apreq_version.h library/module_cgi.c library/parser.c module/apache2/handle.c
- Original Message From: Bojan Smojver bo...@rexursive.com To: Joe Schaefer joe_schae...@yahoo.com Cc: Issac Goldstand mar...@beamartyr.net; apreq-...@httpd.apache.org Sent: Sunday, January 11, 2009 5:10:44 AM Subject: Re: svn commit: r733221 - in /httpd/apreq/branches/v2_10: include/apreq_version.h library/module_cgi.c library/parser.c module/apache2/handle.c On Sat, 2009-01-10 at 08:03 -0800, Joe Schaefer wrote: Actually it turns out that the problem I was having at first was related to Bojan's prior -fno-strict-aliasing removal. If you try building trunk with maintainer-mode set, the build will fail badly without the flag. OUCH! Sorry about that - didn't attempt to compile in that mode at all :-( No worries, was easy to fix. Are you planning to pursue 2.10 as RM or should we be moving on to 2.11? The only outstanding issue I am aware of is pgollucci's claim that the perl modules aren't linking correctly to libapreq2 on Solaris. While that would be nice to fix, I don't consider it a showstopper either.
Re: svn commit: r733493 - in /httpd/httpd/trunk: CHANGESdocs/man/rotatelogs.8 docs/manual/programs/rotatelogs.xmlsupport/rotatelogs.c
On Mon, Jan 12, 2009 at 12:03:31PM +0100, Rainer Jung wrote: On 12.01.2009 11:19, Rainer Jung wrote: On 12.01.2009 10:04, Joe Orton wrote: Sending SIGTERM to the rotatelogs process and having the parent recycle it should have done that already, surely, without adding all this complexity to rotatelogs? Thanks for the hint. In fact I just tested it and it does work for rotatelogs used in CustomLog, but not for the ErrorLog one. That one simply dies, no automatic restart and further error messages are lost (quickly tested on Solaris, and only with 2.2.x, needs some further testing for trunk). It's the same for trunk: CustomLog automatically gets respawned, ErrorLog not. ... Sorry, my mistake, I hadn't realised the piped error-logs code was different in this respect. Your analysis looks spot on here anyway. Does it make sense to add the reliable piped logs way of handling loggers to the error log? Or is there any known dependency between the code used in ap_open_piped_log() and the error log itself? Well, I certainly had the expectation that piped error-loggers were automatically restarted; I don't know if there's some technical reason why it's not done, I expect it's just an oversight. Regards, Joe
Re: accept mod_fcgid codebase into httpd project
On 1/11/09 10:53 PM, William A. Rowe, Jr. wr...@rowe-clan.net wrote: [ ] Accept mod_fcgid into httpd +1 -- Brian Akins Chief Operations Engineer Turner Digital Media Technologies
Re: svn commit: r733711 - /httpd/apreq/branches/1.x/RELEASE
- Original Message From: is...@apache.org is...@apache.org To: apreq-...@httpd.apache.org Sent: Monday, January 12, 2009 7:49:45 AM Subject: svn commit: r733711 - /httpd/apreq/branches/1.x/RELEASE Author: issac Date: Mon Jan 12 04:49:42 2009 New Revision: 733711 URL: http://svn.apache.org/viewvc?rev=733711view=rev Log: update the release cycle instructions Modified: httpd/apreq/branches/1.x/RELEASE Modified: httpd/apreq/branches/1.x/RELEASE URL: http://svn.apache.org/viewvc/httpd/apreq/branches/1.x/RELEASE?rev=733711r1=733710r2=733711view=diff == --- httpd/apreq/branches/1.x/RELEASE (original) +++ httpd/apreq/branches/1.x/RELEASE Mon Jan 12 04:49:42 2009 @@ -16,7 +16,7 @@ 3. Upload a release candidate to httpd.apache.org/~username and post a candidate announcement to apreq-...@. The RM or any other apreq committer may call for a formal vote on the - candidate, but a formal vote is not a requirement for the release. + candidate, but a formal vote is not a requirement for the candidate. Also, it is strongly recommended that the RM crosspost the candidate announcement to the modperl@ list, to solicit feedback from a much larger audience. This section is totally wrong. Formal votes on releases is a foundation-wide requirement, and crossposting the candidate announcement to the modperl@ list is effectively releasing the candidate, so it should not be done. @@ -36,6 +36,10 @@ =item 1.35 - libapreq-1.35 released. + + Also, add a release entry to ./STATUS + + 1.35 : Released 6. Tag the tree, s/./_/g in the version number, and roll the release. @@ -82,21 +86,40 @@ /www/www.apache.org/dist/httpd/KEYS file. --- -9. Upload the package to CPAN. Doublecheck that the md5 checksum - received from PAUSE is correct. +9. Call for a formal vote on the release artifact as explained in 4 and 5 + above. Note that since this is a release artiface, a formal vote is + required, and 3 +1 votes from members of the httpd PMC are required to + proceed. If all is well after 72 hours, proceed to step 11 (NOT 10). We shouldn't bless what was done with 1.34, as stuff should never be put on the mirror system (www.apache.org/dist/) until AFTER it has passed a vote.
Re: svn commit: r733711 - /httpd/apreq/branches/1.x/RELEASE
Joe Schaefer wrote: - Original Message From: is...@apache.org is...@apache.org To: apreq-...@httpd.apache.org Sent: Monday, January 12, 2009 7:49:45 AM Subject: svn commit: r733711 - /httpd/apreq/branches/1.x/RELEASE Author: issac Date: Mon Jan 12 04:49:42 2009 New Revision: 733711 URL: http://svn.apache.org/viewvc?rev=733711view=rev Log: update the release cycle instructions Modified: httpd/apreq/branches/1.x/RELEASE Modified: httpd/apreq/branches/1.x/RELEASE URL: http://svn.apache.org/viewvc/httpd/apreq/branches/1.x/RELEASE?rev=733711r1=733710r2=733711view=diff == --- httpd/apreq/branches/1.x/RELEASE (original) +++ httpd/apreq/branches/1.x/RELEASE Mon Jan 12 04:49:42 2009 @@ -16,7 +16,7 @@ 3. Upload a release candidate to httpd.apache.org/~username and post a candidate announcement to apreq-...@. The RM or any other apreq committer may call for a formal vote on the - candidate, but a formal vote is not a requirement for the release. + candidate, but a formal vote is not a requirement for the candidate. Also, it is strongly recommended that the RM crosspost the candidate announcement to the modperl@ list, to solicit feedback from a much larger audience. This section is totally wrong. Formal votes on releases is a foundation-wide requirement, and crossposting the candidate announcement to the modperl@ list is effectively releasing the candidate, so it should not be done. But this isn't a release, it's a candidate and will never be blessed by the ASF in any manner. I'd suggest leaving the vote instructions as-is (they're technically correct) and removing the crosspost until the actual release. Sound ok? @@ -36,6 +36,10 @@ =item 1.35 - libapreq-1.35 released. + + Also, add a release entry to ./STATUS + + 1.35 : Released 6. Tag the tree, s/./_/g in the version number, and roll the release. @@ -82,21 +86,40 @@ /www/www.apache.org/dist/httpd/KEYS file. --- -9. Upload the package to CPAN. Doublecheck that the md5 checksum - received from PAUSE is correct. +9. Call for a formal vote on the release artifact as explained in 4 and 5 + above. Note that since this is a release artiface, a formal vote is + required, and 3 +1 votes from members of the httpd PMC are required to + proceed. If all is well after 72 hours, proceed to step 11 (NOT 10). We shouldn't bless what was done with 1.34, as stuff should never be put on the mirror system (www.apache.org/dist/) until AFTER it has passed a vote. Good point. I knew that but missed fixing it.
Re: mod_lua headers_out
On Mon, Jan 12, 2009 at 2:07 AM, Bertrand Mansion bmans...@mamasam.net wrote:
.. snip ..
Does that work?
Yes, it will work, thank you :)
The advantage of having a function instead of a table for setting
headers_in/headers_out is that you can use luaL_checkstring() to make
sure the given parameters are of the correct type. I don't know what
the patch will return if someone tries to set a table like in
headers_out['Foo'] = {Bar = 'baz'}
Maybe it is possible to set a metatable for headers_in/headers_out
that would check on __index and __newindex if the value validates with
luaL_checkstring (just thinking out loud).
I believe it does -- header_in and headers_out are boxed apr_table_t
instances and the only thing they have in their metatable are __index
and __newindex. If they are not checking for strings, that is a bug as
apr_table_t is string only.
-Brian
Re: svn commit: r733221 - in /httpd/apreq/branches/v2_10: include/apreq_version.h library/module_cgi.c library/parser.c module/apache2/handle.c
On Mon, 2009-01-12 at 18:44 +0200, Issac Goldstand wrote: Regardless of that, I'd like to merge in the enhanced-cgi stuff later in the week. So we can either do 2 consecutive releases or get 2.10 out the door now and re-vote on 2.11 in another week or so. We didn't have a release for a very long time, so one extra week isn't going to make a lot of difference. People have been asking for enhanced CGI stuff, so let's do that. Everyone OK with that approach? -- Bojan
Re: accept mod_fcgid codebase into httpd project
William A. Rowe, Jr. wrote: Based on the enthusiasm of the module authors to adopt the AL and offer the mod_fcgid code to the httpd community, please vote [+1] Accept mod_fcgid into httpd And as others have already expressed, many thanks to Ryan and everyone else involved. Chris. -- GPG Key ID: 366A375B GPG Key Fingerprint: 485E 5041 17E1 E2BB C263 E4DE C8E3 FA36 366A 375B
Re: svn commit: r733493 - in /httpd/httpd/trunk: CHANGESdocs/man/rotatelogs.8 docs/manual/programs/rotatelogs.xmlsupport/rotatelogs.c
Rainer Jung wrote: Does it make sense to add the reliable piped logs way of handling loggers to the error log? Or is there any known dependency between the code used in ap_open_piped_log() and the error log itself? When I was looking at this, the difference didn't make a whole lot of sense to me, but I was not trying to make any mass changes, only more subtle changes that corrected the number of open and lingering fd's. Provided that your patch to be consistent in registering reliable restart info does work as a per-host error logger and the global stderr logger, I'd say go ahead for 2.3 alpha. But it would be interesting to look at this historically, why error loggers were not in the original reliable piped logs implementation code path? Bill
Re: accept mod_fcgid codebase into httpd project
On Mon, Jan 12, 2009 at 12:59 PM, traw...@gmail.com wrote: On Jan 11, 2009 10:53pm, William A. Rowe, Jr. wr...@rowe-clan.net wrote: Based on the enthusiasm of the module authors to adopt the AL and offer the mod_fcgid code to the httpd community, please vote +/-1 [+1] Accept mod_fcgid into httpd not that my vote counts but I think mod_fcgid's inclusion in the main httpd will be a good think. +1 And Thanks! to the mod_fcgid author and contributors! +1 to this as wel!
Re: svn commit: r733221 - in /httpd/apreq/branches/v2_10: include/apreq_version.h library/module_cgi.c library/parser.c module/apache2/handle.c
- Original Message From: Bojan Smojver bo...@rexursive.com To: Issac Goldstand mar...@beamartyr.net Cc: Joe Schaefer joe_schae...@yahoo.com; APREQ List apreq-...@httpd.apache.org Sent: Monday, January 12, 2009 12:31:57 PM Subject: Re: svn commit: r733221 - in /httpd/apreq/branches/v2_10: include/apreq_version.h library/module_cgi.c library/parser.c module/apache2/handle.c On Mon, 2009-01-12 at 18:44 +0200, Issac Goldstand wrote: Regardless of that, I'd like to merge in the enhanced-cgi stuff later in the week. So we can either do 2 consecutive releases or get 2.10 out the door now and re-vote on 2.11 in another week or so. We didn't have a release for a very long time, so one extra week isn't going to make a lot of difference. People have been asking for enhanced CGI stuff, so let's do that. Everyone OK with that approach? Fine with me. I'm no longer committing stuff to the v2_10 branch, so someone should probably nuke it.
Re: accept mod_fcgid codebase into httpd project
+1 Roy
Re: accept mod_fcgid codebase into httpd project
On Sun, Jan 11, 2009 at 7:53 PM, William A. Rowe, Jr. wr...@rowe-clan.net wrote: [ ] Accept mod_fcgid into httpd +1. Thanks. -- justin
Re: Re: Re: Graceful restart not so graceful?
On Jan 12, 2009 8:49am, traw...@gmail.com wrote: wrt backporting: I think that modern Linux and modern Solaris, perhaps the only platforms tested so far, both work for the same reason under the covers. Has anyone tested with regular poll()? If not, I can try to test another platform or at least dumb down APR to bypass epoll/event queue/etc. I tested prefork on OpenSolaris with ac_cv_func_port_create=no (ie, use poll()) and it worked with/without the patch. I tested on Leopard (kevent) and it appeared to work with/without the patch, but I'm not very confident that I was able to reproduce the right timing window. I've proposed for backport to 2.2.x.
Re: svn commit: r733493 - in /httpd/httpd/trunk: CHANGESdocs/man/rotatelogs.8 docs/manual/programs/rotatelogs.xmlsupport/rotatelogs.c
On 12.01.2009 18:59, William A. Rowe, Jr. wrote: Rainer Jung wrote: Does it make sense to add the reliable piped logs way of handling loggers to the error log? Or is there any known dependency between the code used in ap_open_piped_log() and the error log itself? When I was looking at this, the difference didn't make a whole lot of sense to me, but I was not trying to make any mass changes, only more subtle changes that corrected the number of open and lingering fd's. Provided that your patch to be consistent in registering reliable restart info does work as a per-host error logger and the global stderr logger, I'd say go ahead for 2.3 alpha. I'll see how far it gets. Your comments and Joe's indicate, that it's worth investigating. But it would be interesting to look at this historically, why error loggers were not in the original reliable piped logs implementation code path? I just checked, and the same construction and difference between access and error log was already in 1.3.0. From the changes, reliable piped logs have been introduced in 1.3b2, but I didn't check that code version to see, if it looks the same. The changes file doesn't have an entry about error log changes w.r.t. the piped logging between 1.3.b2 and 1.3.0. What can be seen from the CHANGES file, is that the logging of some modules that also allow the use of piped logging, has been switched to the new implementation only in later versions. So it's possible it was done only for access from the start and whenever someone stumbled over another case of piped logging, it was switched to the reliable pipes. Regards, Rainer
Re: patch for handling headers_in and headers_out as tables in mod_lua
Nudge -- if there are no objections to the patch, would someone be kind enough to apply it? -Brian On Sun, Jan 11, 2009 at 8:20 PM, Brian McCallister bri...@skife.org wrote: The attached patch changes headers_in and headers_out handling in mod_lua as boxed userdata rather than functions. Basically we go from: -- OLD function handle(r) local host = r.headers_in(host) r:puts(host) end to -- NEW function handle(r) local host = r.headers_in['host'] r:puts(host) -- and can now modify them r.headers_in['X-XX-Fake'] = 'rabbits!' r.headers_out['wombat'] = 'lua now!' end In order to treat tables idiommatically, it also corrects the apl_push_apr_table(..) function to behave as a regular lua style push function instead of a set function. -Brian
