Re: [VOTE] release httpd mod_fcgid-2.3.1?
Rainer Jung wrote:
I think it's still beta, because the docs are not enough to get one
started. Especially the description for FCGIWrapper is strange:
Well, all the docs are strange ;-) Any volunteers?
http://svn.apache.org/repos/asf/httpd/mod_fcgid/trunk/docs/manual/mod/
- I wasn't able to use it without the optional (?) second param:
In file fcgid_conf.c:
762 const char *set_wrapper_config(cmd_parms * cmd, void *dirconfig,
763const char *wrapperpath,
764const char *extension)
765 {
...
775 /* Sanity check */
776 if (wrapperpath == NULL || extension == NULL
---^
777 || *extension != '.' || *(extension + 1) == '\0'
778 ...
779 return Invalid wrapper file extension;
although it is declared as
AP_INIT_TAKE12(FCGIWrapper, set_wrapper_config, NULL,
RSRC_CONF | ACCESS_CONF | OR_FILEINFO,
The CGI wrapper setting),
- the needed extension is completely undocumented
- the path of wrapperpath is not resolved relative to the server root
FWIW at httpd committers, feel free to fix. If svn permissions aren't set
up correctly, I'm happy to fix. But I would hate to see some territorial
boundaries (real or perceived) interfere with fixing httpd code, whether
it's in the main trunk or off on a module subproject.
Re: [VOTE] release httpd mod_fcgid-2.3.1?
William A. Rowe, Jr. wrote: Rainer Jung wrote: Signing good, hash files are in a format at least my md5sum and sha1sum do not understand how to check. Can anyone point out what I'm doing wrong with 'gpg --print-md md5'? Am I missing some magic flag, or is the idea of using gpg to create hashes simply broken? FYI; $ gpg --version gpg (GnuPG) 1.4.9 ... in case that is significant.
[VOTE] release httpd mod_fcgid-2.3.1?
mod_fcgid freinds; Please fetch up the newly minted mod_fcgid-2.3.1.tar.gz (or bz2) or the win32 suitable package mod_fcgid-2.3.1-crlf.zip from: http://httpd.apache.org/dev/dist/mod_fcgid/ review, take it for a spin, and cast your choice [ ] -1 for any release of 2.3.1 (regressed from 2.3.0?) [ ] +1 to release as 2.3.1-beta [ ] +1 to release as 2.3.1-GA The most major change was handling modern win32 apr calls, and filling in the basic pathing variables by platform to help launch the cgid process in the first place. Note no configuration updates occur yet on make install. Not sure what our 'example' aught to look like, yet. Note no documentation was donated, so there is a reference to all of the directives taken from the cmd_rec array, but this needs attention from fans to fill in the text and correct a few more typos. For getting started, http://svn.apache.org/repos/asf/httpd/mod_fcgid/tags/2.3.1/README-FCGID Bill
Re: svn commit: r807823 - /httpd/mod_fcgid/trunk/CHANGES-FCGID
On Wed, Aug 26, 2009 at 1:10 AM, William A. Rowe, Jr. wr...@rowe-clan.netwrote: Chris Darroch wrote: wr...@apache.org wrote: URL: http://svn.apache.org/viewvc?rev=807823view=rev Log: suppose this would be worth noting Changes with mod_fcgid 2.3.1 + *) Complete the unix port to 2.3-dev trunk. [William Rowe] Thank you for all this work ... it's much appreciated, especially since I've been utterly useless lately on the httpd front. Thanks again! So... if I throw the effort at getting unix to build clean for httpd-2.0 branch, you won't be offended ;-? (brain dump since I have to get some real work done) Here's a patch to get the proper header files included for the apr 0.9.x compatibility code. http://people.apache.org/~trawick/fcgid_2.0.x_detect.patch Is it worth the trouble to make that ugly code (copy of apr_shm_remove) compile correctly? Should we just add that function to the not-anally-versioned APR 0.9.x? My configure.apxs build currently fails to find mod_fcgid.a; that doesn't seem to be related to the patch, but that knowledge brings only so much happiness... And I haven't tried building in-tree.
Re: svn commit: r807823 - /httpd/mod_fcgid/trunk/CHANGES-FCGID
Jeff Trawick wrote: (brain dump since I have to get some real work done) :) Here's a patch to get the proper header files included for the apr 0.9.x compatibility code. http://people.apache.org/~trawick/fcgid_2.0.x_detect.patch Is it worth the trouble to make that ugly code (copy of apr_shm_remove) compile correctly? Should we just add that function to the not-anally-versioned APR 0.9.x? Sure. Let's get it building correctly without updating 0.9.x; it serves as a good example of this module build schema. The four lines of fchmod example in configure.apxs be deleted. And it appears there is a stray ')' at the end of your revised APACHE_MODULE line. Just need to strip all these checks when brought into httpd trunk, if we do so. My configure.apxs build currently fails to find mod_fcgid.a; that doesn't seem to be related to the patch, but that knowledge brings only so much happiness... And I haven't tried building in-tree. :) How does modules.mk from .apxs compare with a normal modules.mk that would exist in one of your modules/ subdirectories of a normal 2.0 build? Is it invoking the right libtool (copied into apr/build/)? There are some flaws in the httpd-2.0 installation still, particularly if apr ends up installed in a different directory than httpd.
Re: svn commit: r807823 - /httpd/mod_fcgid/trunk/CHANGES-FCGID
William A. Rowe, Jr. wrote: Jeff Trawick wrote: (brain dump since I have to get some real work done) :) Here's a patch to get the proper header files included for the apr 0.9.x compatibility code. And if I wasn't clear, please feel free to dump this into svn, I'll assure it doesn't break anything before I tag and roll. We gotta keep your stats up in Tomislav's analysis :) Bill
Re: svn commit: r807823 - /httpd/mod_fcgid/trunk/CHANGES-FCGID
William A. Rowe, Jr. wrote: Thank you for all this work ... it's much appreciated, especially since I've been utterly useless lately on the httpd front. Thanks again! So... if I throw the effort at getting unix to build clean for httpd-2.0 branch, you won't be offended ;-? Seriously, no troubles, I'd just like to see this released, so we get bug reports, so that we fix them, so that this becomes more relevant and ends up in the 2.3-dev tree :) Absolutely, and again, apologies for being a useless lump at the moment. I'm rolling sometime tomorrow. If folks can check out, test compile and experiment, I'd be most appreciative. It would be lovely if it could go GA on the first try. I can't make a promise but I'll try to grab it and spin it up. Again, thank you. Chris. -- GPG Key ID: 366A375B GPG Key Fingerprint: 485E 5041 17E1 E2BB C263 E4DE C8E3 FA36 366A 375B
Re: svn commit: r807823 - /httpd/mod_fcgid/trunk/CHANGES-FCGID
On Wed, Aug 26, 2009 at 12:56 PM, William A. Rowe, Jr. wr...@rowe-clan.netwrote: William A. Rowe, Jr. wrote: Jeff Trawick wrote: (brain dump since I have to get some real work done) :) Here's a patch to get the proper header files included for the apr 0.9.x compatibility code. And if I wasn't clear, please feel free to dump this into svn, I'll assure it doesn't break anything before I tag and roll. Yep (I'll take a few minutes to fix/test further based on your comments.) We gotta keep your stats up in Tomislav's analysis :) Yes, André is breathing down my neck.
Re: svn commit: r807823 - /httpd/mod_fcgid/trunk/CHANGES-FCGID
Hi Bill and Chris, Question, is this going to work with APR 1.3 on Windows? I see this http://svn.apache.org/viewvc?view=revrevision=787561 but when I look at what I was given by Tom Donovan he seemed to have to deal with APR 1.3 as a #if seperate entity #endif, nasty yes but it works. My build out-of-tree on the 19th builds and loads fine but when it is called upon it did this; Faulting application httpd.exe, version 2.2.13.0, faulting module libapr-1.dll, version 1.3.8.0, fault address 0x793d. This failure in libapr-1.dll leave me a bit suspicious. My usual disclaimer, I will not deny this may possibly be my fault. Regards, Gregg William A. Rowe, Jr. wrote: Chris Darroch wrote: wr...@apache.org wrote: URL: http://svn.apache.org/viewvc?rev=807823view=rev Log: suppose this would be worth noting Changes with mod_fcgid 2.3.1 I'm rolling sometime tomorrow. If folks can check out, test compile and experiment, I'd be most appreciative. It would be lovely if it could go GA on the first try.
Re: svn commit: r807823 - /httpd/mod_fcgid/trunk/CHANGES-FCGID
Gregg L. Smith wrote: Faulting application httpd.exe, version 2.2.13.0, faulting module libapr-1.dll, version 1.3.8.0, fault address 0x793d. Gregg, your Dr Watson or windbg fault backtrace please?
Re: svn commit: r797647 - /httpd/mod_fcgid/trunk/mod_fcgid/mod_fcgid.c
On Fri, Jul 24, 2009 at 4:54 PM, wr...@apache.org wrote: Author: wrowe Date: Fri Jul 24 20:54:46 2009 New Revision: 797647 URL: http://svn.apache.org/viewvc?rev=797647view=rev Log: use our apr specific methods of merging this server config table and array Modified: httpd/mod_fcgid/trunk/mod_fcgid/mod_fcgid.c Modified: httpd/mod_fcgid/trunk/mod_fcgid/mod_fcgid.c URL: http://svn.apache.org/viewvc/httpd/mod_fcgid/trunk/mod_fcgid/mod_fcgid.c?rev=797647r1=797646r2=797647view=diff == --- httpd/mod_fcgid/trunk/mod_fcgid/mod_fcgid.c (original) +++ httpd/mod_fcgid/trunk/mod_fcgid/mod_fcgid.c Fri Jul 24 20:54:46 2009 @@ -99,6 +100,71 @@ return APR_SUCCESS; } + +/* This should be proposed as a stand-alone improvement to the httpd module, + * either in the arch/ platform-specific modules or util_script.c from whence + * it came. + */ +static void default_proc_env(apr_table_t *e) do you have any code yet to call this function?
Re: svn commit: r807823 - /httpd/mod_fcgid/trunk/CHANGES-FCGID
Hi Bill, Since I had tossed it all you forced me to rebuild. I do not remember doing anything different prior but The Culprit; My usual disclaimer, I will not deny this may possibly be my fault. Sorry and Thanks for getting this module going. I can think of a lot of people that will be very happy now that the ASF has taken it over. Gregg William A. Rowe, Jr. wrote: Gregg L. Smith wrote: Faulting application httpd.exe, version 2.2.13.0, faulting module libapr-1.dll, version 1.3.8.0, fault address 0x793d. Gregg, your Dr Watson or windbg fault backtrace please? No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.5.392 / Virus Database: 270.13.69/2328 - Release Date: 08/26/09 12:16:00
Re: svn commit: r797647 - /httpd/mod_fcgid/trunk/mod_fcgid/mod_fcgid.c
Jeff Trawick wrote: do you have any code yet to call this function? Once again, compiler warnings are our friend. Yes, this needs to be invoked, but it's a NTP, and the code I tossed was a new direction I wanted to go in, which would pick up all the PassEnv and other overrides, and set these all aside in a way that it would reinvoke the program again identically if a worker is lost. I then looked at the possibility of using httpd's API but that wasn't suitable either. So... back to the drawing board to flesh out this table before we go and invoke apr_proc_create. Thanks for drawing it to my attention.
Re: svn commit: r807823 - /httpd/mod_fcgid/trunk/CHANGES-FCGID
wr...@apache.org wrote: URL: http://svn.apache.org/viewvc?rev=807823view=rev Log: suppose this would be worth noting Changes with mod_fcgid 2.3.1 + *) Complete the unix port to 2.3-dev trunk. [William Rowe] Thank you for all this work ... it's much appreciated, especially since I've been utterly useless lately on the httpd front. Thanks again! Chris. -- GPG Key ID: 366A375B GPG Key Fingerprint: 485E 5041 17E1 E2BB C263 E4DE C8E3 FA36 366A 375B
Re: svn commit: r807823 - /httpd/mod_fcgid/trunk/CHANGES-FCGID
Chris Darroch wrote: wr...@apache.org wrote: URL: http://svn.apache.org/viewvc?rev=807823view=rev Log: suppose this would be worth noting Changes with mod_fcgid 2.3.1 + *) Complete the unix port to 2.3-dev trunk. [William Rowe] Thank you for all this work ... it's much appreciated, especially since I've been utterly useless lately on the httpd front. Thanks again! So... if I throw the effort at getting unix to build clean for httpd-2.0 branch, you won't be offended ;-? Seriously, no troubles, I'd just like to see this released, so we get bug reports, so that we fix them, so that this becomes more relevant and ends up in the 2.3-dev tree :) I'm rolling sometime tomorrow. If folks can check out, test compile and experiment, I'd be most appreciative. It would be lovely if it could go GA on the first try.
Re: svn commit: r807368 - /httpd/mod_fcgid/trunk/mod_fcgid/CHANGES
On 08/24/2009 10:35 PM, wr...@apache.org wrote: Author: wrowe Date: Mon Aug 24 20:35:09 2009 New Revision: 807368 URL: http://svn.apache.org/viewvc?rev=807368view=rev Log: Note changes Modified: httpd/mod_fcgid/trunk/mod_fcgid/CHANGES Modified: httpd/mod_fcgid/trunk/mod_fcgid/CHANGES URL: http://svn.apache.org/viewvc/httpd/mod_fcgid/trunk/mod_fcgid/CHANGES?rev=807368r1=807367r2=807368view=diff == --- httpd/mod_fcgid/trunk/mod_fcgid/CHANGES [utf8] (original) +++ httpd/mod_fcgid/trunk/mod_fcgid/CHANGES [utf8] Mon Aug 24 20:35:09 2009 @@ -1,5 +1,12 @@ -*- coding: utf-8 -*- -Changes with mod_fcgid 2.3 +Changes with mod_fcgid 2.3.1 + + *) Provide a default, manditory environment as with mod_cgi (with the Should that be mandatory instead? Regards Rüdiger
Re: svn commit: r797603 - /httpd/mod_fcgid/trunk/mod_fcgid/mod_fcgid.c
William A. Rowe, Jr. wrote: wr...@apache.org wrote: Author: wrowe Date: Fri Jul 24 18:54:39 2009 New Revision: 797603 URL: http://svn.apache.org/viewvc?rev=797603view=rev Log: Remove hop by hop headers and set Connection: close to convince all fastcgi consumers that they are not responsible for the various processing which httpd has already performed, internally. Folks, the patch inspires two questions; Modified: httpd/mod_fcgid/trunk/mod_fcgid/mod_fcgid.c URL: http://svn.apache.org/viewvc/httpd/mod_fcgid/trunk/mod_fcgid/mod_fcgid.c?rev=797603r1=797602r2=797603view=diff == --- httpd/mod_fcgid/trunk/mod_fcgid/mod_fcgid.c (original) +++ httpd/mod_fcgid/trunk/mod_fcgid/mod_fcgid.c Fri Jul 24 18:54:39 2009 -/* Remove some environment variables */ -/* The Web server does not send CONTENT_LENGTH, PATH_INFO, PATH_TRANSLATED, and SCRIPT_NAME headers */ +/* Drop the variables CONTENT_LENGTH, PATH_INFO, PATH_TRANSLATED, + * SCRIPT_NAME and most Hop-By-Hop headers - EXCEPT we will pass + * PROXY_AUTH to allow CGI to perform proxy auth for httpd + */ Do we want Proxy-Auth* headers to be shared with a CGI application? If so, howso, and if not, why not? Note this auth is hop-by-hop, and (in theory) httpd is both an endpoint, and a gateway to cgi which is allowed to do auth processing. apr_table_unset(r-subprocess_env, CONTENT_LENGTH); apr_table_unset(r-subprocess_env, PATH_INFO); apr_table_unset(r-subprocess_env, PATH_TRANSLATED); apr_table_unset(r-subprocess_env, SCRIPT_NAME); [these four above are not removed for the actual request _handler, but only when acting for the authn/authz mechanics.] +apr_table_unset(r-subprocess_env, HTTP_KEEP_ALIVE); +apr_table_unset(r-subprocess_env, HTTP_TE); +apr_table_unset(r-subprocess_env, HTTP_TRAILER); +apr_table_unset(r-subprocess_env, HTTP_TRANSFER_ENCODING); +apr_table_unset(r-subprocess_env, HTTP_UPGRADE); None of the above should matter to the cgi; fastcgi protocol doesn't have a trailer mechanism for request bodies, so far as I'm aware. The request body Transfer Encoding, any upgrade or keep_alives should be ignored, and +/* Connection hop-by-hop header to prevent the CGI from hanging */ +apr_table_set(r-subprocess_env, HTTP_CONNECTION, close); we should let the fastcgi app context consider itself 'done' upon completion of one request. I presume this is correct? Thoughts?
Re: svn commit: r797603 - /httpd/mod_fcgid/trunk/mod_fcgid/mod_fcgid.c
wr...@apache.org wrote: Author: wrowe Date: Fri Jul 24 18:54:39 2009 New Revision: 797603 URL: http://svn.apache.org/viewvc?rev=797603view=rev Log: Remove hop by hop headers and set Connection: close to convince all fastcgi consumers that they are not responsible for the various processing which httpd has already performed, internally. Folks, the patch inspires two questions; Modified: httpd/mod_fcgid/trunk/mod_fcgid/mod_fcgid.c URL: http://svn.apache.org/viewvc/httpd/mod_fcgid/trunk/mod_fcgid/mod_fcgid.c?rev=797603r1=797602r2=797603view=diff == --- httpd/mod_fcgid/trunk/mod_fcgid/mod_fcgid.c (original) +++ httpd/mod_fcgid/trunk/mod_fcgid/mod_fcgid.c Fri Jul 24 18:54:39 2009 -/* Remove some environment variables */ -/* The Web server does not send CONTENT_LENGTH, PATH_INFO, PATH_TRANSLATED, and SCRIPT_NAME headers */ +/* Drop the variables CONTENT_LENGTH, PATH_INFO, PATH_TRANSLATED, + * SCRIPT_NAME and most Hop-By-Hop headers - EXCEPT we will pass + * PROXY_AUTH to allow CGI to perform proxy auth for httpd + */ Do we want Proxy-Auth* headers to be shared with a CGI application? If so, howso, and if not, why not? Note this auth is hop-by-hop, and (in theory) httpd is both an endpoint, and a gateway to cgi which is allowed to do auth processing. apr_table_unset(r-subprocess_env, CONTENT_LENGTH); apr_table_unset(r-subprocess_env, PATH_INFO); apr_table_unset(r-subprocess_env, PATH_TRANSLATED); apr_table_unset(r-subprocess_env, SCRIPT_NAME); [these four above are not removed for the actual request _handler, but only when acting for the authn/authz mechanics.] +apr_table_unset(r-subprocess_env, HTTP_KEEP_ALIVE); +apr_table_unset(r-subprocess_env, HTTP_TE); +apr_table_unset(r-subprocess_env, HTTP_TRAILER); +apr_table_unset(r-subprocess_env, HTTP_TRANSFER_ENCODING); +apr_table_unset(r-subprocess_env, HTTP_UPGRADE); None of the above should matter to the cgi; fastcgi protocol doesn't have a trailer mechanism for request bodies, so far as I'm aware. The request body Transfer Encoding, any upgrade or keep_alives should be ignored, and +/* Connection hop-by-hop header to prevent the CGI from hanging */ +apr_table_set(r-subprocess_env, HTTP_CONNECTION, close); we should let the fastcgi app context consider itself 'done' upon completion of one request. I presume this is correct?
mod_fcgid: start CHANGES file for post-2.2-release changes, keep ChangeLog for previously released issues (?)
concerns?
[mod_fcgid PATCH] don't try to change ownership of socket directory unless running as root
Currently, starting httpd as non-root with mod_fcgid loaded fails unless User/Group are set to the active User/Group. Normally, httpd modules don't try to set ownership of objects to the specified User/Group unless starting as root. Thus, httpd.conf can contain reasonable User/Group settings for production use but still be suitable for use by Joe User. The affected code in fcgid_pm_unix.c is from the original revision ( http://svn.apache.org/viewvc/httpd/mod_fcgid/trunk/mod_fcgid/arch/unix/fcgid_pm_unix.c?revision=753487view=markup ). Logic was added a couple of years ago ( http://svn.apache.org/viewvc?view=revrevision=753553) to bypass the directory creation/chown if the directory already existed and had the correct ownership, to allow use with some SELinux policy. Comments/concerns? fcgid.patch Description: Binary data
Re: [mod_fcgid PATCH] don't try to change ownership of socket directory unless running as root
On Mon, May 11, 2009 at 11:56:42AM -0400, Jeff Trawick wrote: Currently, starting httpd as non-root with mod_fcgid loaded fails unless User/Group are set to the active User/Group. Normally, httpd modules don't try to set ownership of objects to the specified User/Group unless starting as root. Thus, httpd.conf can contain reasonable User/Group settings for production use but still be suitable for use by Joe User. The affected code in fcgid_pm_unix.c is from the original revision ( http://svn.apache.org/viewvc/httpd/mod_fcgid/trunk/mod_fcgid/arch/unix/fcgid_pm_unix.c?revision=753487view=markup ). Logic was added a couple of years ago ( http://svn.apache.org/viewvc?view=revrevision=753553) to bypass the directory creation/chown if the directory already existed and had the correct ownership, to allow use with some SELinux policy. Comments/concerns? I bumped into problems with this when I tried the Fedora package of mod_fcgid recently, but got scared off when I started reading the code. 1. global symbol names like get_socketpath() etc 2. defaults: #define DEFAULT_SOCKET_PREFIX logs/fcgidsock #define DEFAULT_SHM_PATH logs/fcgid_shm should be DEFAULT_REL_RUNTIMEDIR-relative, then these would appear in the correct place by default (e.g. /var/run in a Fedora build) 3. the whole apr_dir_make_recursive() thing seemed a bit dubious (at least in that it's _recursive) - I would have expected a prerequisite of a correctly configured directory and failure otherwise. but I confess I haven't had time/energy to look into this module in detail. The only requirement on the directory is that root can create sockets in the directory, and the less-privileged user can open those sockets, right? Regards, Joe
Re: [mod_fcgid PATCH] don't try to change ownership of socket directory unless running as root
On Mon, May 11, 2009 at 4:26 PM, Joe Orton jor...@redhat.com wrote: On Mon, May 11, 2009 at 11:56:42AM -0400, Jeff Trawick wrote: Currently, starting httpd as non-root with mod_fcgid loaded fails unless User/Group are set to the active User/Group. Normally, httpd modules don't try to set ownership of objects to the specified User/Group unless starting as root. Thus, httpd.conf can contain reasonable User/Group settings for production use but still be suitable for use by Joe User. The affected code in fcgid_pm_unix.c is from the original revision ( http://svn.apache.org/viewvc/httpd/mod_fcgid/trunk/mod_fcgid/arch/unix/fcgid_pm_unix.c?revision=753487view=markup ). Logic was added a couple of years ago ( http://svn.apache.org/viewvc?view=revrevision=753553) to bypass the directory creation/chown if the directory already existed and had the correct ownership, to allow use with some SELinux policy. Comments/concerns? I bumped into problems with this when I tried the Fedora package of mod_fcgid recently, but got scared off when I started reading the code. It seems that there's a lot to understand ;) The only requirement on the directory is that root can create sockets in the directory, and the less-privileged user can open those sockets, right? Close. The startup user (root) creates the directory and sets permissions to 0700. The child user (e.g., webservd) creates the sockets and connects to them. (A pipe is used for communication as well. I think there's a unix socket per application instance.)
Re: mod_fcgid support
William A. Rowe, Jr. wrote: Chris, I'm really confused. Are you asking to branch httpd trunk into a 2.4 branch (bad, we aren't there) or a 2.3 branch (overkill IMHO, if we don't have cycles to get to 2.4/3.0 with what's in trunk, we certainly don't have cycles to make the determinations of what is in 2.4 vs 3.0). Sorry, neither -- it's confusing because mod_fcgid's last released version was 2.2, so any discussion about subsequent releases (completely independent from httpd development) naturally leads to talk of 2.3/2.4/etc. version numbers. So there's a confusing but coincidental overlap between the version numbers in play here. Basically my question boils down to this: do we work first on moving mod_fcgid into httpd trunk, or work on it first as a standalone product? Or asking for an fcgid branch? You can do whatever you like in the sandbox including preparing a 2.2 or 2.0 flavor from the initial import. (To then release it requires a vote of the PMC, of course). Yes, I was asking about a mod_fcgid branch (named 2.x, I guess). More on that below. Jeff Trawick wrote: * import the cleaned up mod_fcgid into httpd trunk for expected inclusion in the next httpd release (2.4 or 3.0 or whatever it is) ** work on autoconf and incompatible code changes there (httpd trunk) ** if for some reason this work doesn't proceed fast enough for mod_fcgid to be included in the next httpd release, it can be axed from the future httpd 2.4/3.0/whatever branch when that branch is created This would be ideal. The steps to move forward here are obvious and straightforward, I think. * use the httpd/mod_fcgid subtree for bug fix releases of mod_fcgid (retain compatibility with httpd 2.0/2.2 as well as existing mod_fcgid configurations) I see where you're going with this, and I like it. It means that for the time being, we just ignore the incomplete autoconf/build stuff in mod_fcgid's sandbox. Going forward, if we feel we have a useful codebase in httpd trunk's mod_fcgid module that we want to release independently, we backport it as necessary to make it compatible with existing standalone mod_fcgid configurations (likely mostly renaming config directives back to their old names, etc.), deal creating a proper build framework for an independent mod_fcgid (if, indeed, that's needed at all), and vote on a release. But since we might not even do any of this, no need to start on this work first. OK, that helps a lot. Sorry to get hung up on these process issues. If no one else has comments, I think proceeding down the road Jeff outlined is the way forward. Thanks, Chris. -- GPG Key ID: 366A375B GPG Key Fingerprint: 485E 5041 17E1 E2BB C263 E4DE C8E3 FA36 366A 375B
Re: mod_fcgid support
Chris Darroch wrote: * use the httpd/mod_fcgid subtree for bug fix releases of mod_fcgid (retain compatibility with httpd 2.0/2.2 as well as existing mod_fcgid configurations) I see where you're going with this, and I like it. It means that for the time being, we just ignore the incomplete autoconf/build stuff in mod_fcgid's sandbox. Yea - now I gotcha... that isn't a sandbox, repos/asf/httpd/mod_fcgid/ should have a trunk/ branches/ tags/ schema. Now when you want to go ahead and architect the move to mod_proxy_fcgi[d] and it's not ready for primetime, that's when I'd create something under repos/asf/httpd/ sandbox/ tree, as a work-in-progress.
Re: mod_fcgid support
Chris Darroch wrote: I see where you're going with this, and I like it. It means that for the time being, we just ignore the incomplete autoconf/build stuff in mod_fcgid's sandbox. FWIW, httpd/mod_ftp/ has a build schema that can literally be dropped on top of an httpd source tree, or run independently with simply ./configure.apxs (prepend APXS=/path/to/apxs if you like). If you have a minimal number of extra autoconf feature tests, this might be a solution.
Re: mod_fcgid support
On Fri, Apr 10, 2009 at 6:32 PM, Chris Darroch chr...@pearsoncmg.comwrote: Hi -- Jeff Trawick wrote: Many people use mod_fcgid on Apache 2.0/2.2. The message should be that mod_fcgid development has moved to the ASF, and existing users are not being left behind in the transition. So a branch for mod_fcgid 2.x is maintained for httpd 2.0/2.2 users just as our own stable branches are maintained (FAR beyond emergencies, at least for 2.2.x). This isn't necessarily in opposition to what you said, but some might read it as something like Apache took over and they won't distribute fixes that work with my existing configurations except in extreme circumstances. I think that's something we want to avoid. (Sorry for the slow response; I'd like to say I've been giving this deep thought but actually I've just been distracted with other work for a bit.) It's also worth assuming, I think, that mod_fcgid isn't going to be back-ported and included in the 2.2.x distribution anytime soon. sure; IMO it doesn't ever need to be included in the 2.2.x distribution Given that, I suppose we should look at continuing a 2.x branch for mod_fcgid (with improved autoconf magic, obviously), at least until a httpd 2.4.x is released with mod_fcgid in it. It's slightly inconvenient but I'll willing to start digging into the autoconf stuff and generally trying to get a branch going before we add it into httpd trunk. How do others feel? As I understand it, the current state of mod_fcgid is that it has been imported into the httpd project's mod_fcgid subtree, it has been cleaned up w.r.t. licensing and coding style and some other concerns (what's in readme vs. other files), but no real code changes have been made. Can we * import the cleaned up mod_fcgid into httpd trunk for expected inclusion in the next httpd release (2.4 or 3.0 or whatever it is) ** work on autoconf and incompatible code changes there (httpd trunk) ** if for some reason this work doesn't proceed fast enough for mod_fcgid to be included in the next httpd release, it can be axed from the future httpd 2.4/3.0/whatever branch when that branch is created * use the httpd/mod_fcgid subtree for bug fix releases of mod_fcgid (retain compatibility with httpd 2.0/2.2 as well as existing mod_fcgid configurations)
mod_fcgid support
Hi -- Jeff Trawick wrote: Many people use mod_fcgid on Apache 2.0/2.2. The message should be that mod_fcgid development has moved to the ASF, and existing users are not being left behind in the transition. So a branch for mod_fcgid 2.x is maintained for httpd 2.0/2.2 users just as our own stable branches are maintained (FAR beyond emergencies, at least for 2.2.x). This isn't necessarily in opposition to what you said, but some might read it as something like Apache took over and they won't distribute fixes that work with my existing configurations except in extreme circumstances. I think that's something we want to avoid. (Sorry for the slow response; I'd like to say I've been giving this deep thought but actually I've just been distracted with other work for a bit.) It's also worth assuming, I think, that mod_fcgid isn't going to be back-ported and included in the 2.2.x distribution anytime soon. Given that, I suppose we should look at continuing a 2.x branch for mod_fcgid (with improved autoconf magic, obviously), at least until a httpd 2.4.x is released with mod_fcgid in it. It's slightly inconvenient but I'll willing to start digging into the autoconf stuff and generally trying to get a branch going before we add it into httpd trunk. How do others feel? Chris. -- GPG Key ID: 366A375B GPG Key Fingerprint: 485E 5041 17E1 E2BB C263 E4DE C8E3 FA36 366A 375B
Re: mod_fcgid support
Chris Darroch wrote: It's also worth assuming, I think, that mod_fcgid isn't going to be back-ported and included in the 2.2.x distribution anytime soon. Given that, I suppose we should look at continuing a 2.x branch for mod_fcgid (with improved autoconf magic, obviously), at least until a httpd 2.4.x is released with mod_fcgid in it. It's slightly inconvenient but I'll willing to start digging into the autoconf stuff and generally trying to get a branch going before we add it into httpd trunk. How do others feel? Chris, I'm really confused. Are you asking to branch httpd trunk into a 2.4 branch (bad, we aren't there) or a 2.3 branch (overkill IMHO, if we don't have cycles to get to 2.4/3.0 with what's in trunk, we certainly don't have cycles to make the determinations of what is in 2.4 vs 3.0). Or asking for an fcgid brach? You can do whatever you like in the sandbox including preparing a 2.2 or 2.0 flavor from the initial import. (To then release it requires a vote of the PMC, of course). Or what, exactly ;-?
Re: mod_fcgid
Roy T. Fielding wrote: I think most of the stuff in NOTICE is documentation that belongs in README. The only things we put in NOTICE files are copyright or attribution lines required by the original copyright owners. OK, thanks -- made a quick edit this morning. Makefile and .deps should be generated files. Agreed; I haven't removed .deps yet because the existing build process fails without it. If we're moving into httpd's modules collection, all this stuff can be scrubbed. If we're distributing separately, the module will need a full autoconf implementation. I'm +1 on the former idea as it saves a lot of effort. :-) We have not done any releases of this code, so we are not responsible for fixing releases that might already exist. In any case, a branch can be created at any time by copying a specific revision number; there is no reason to create it before the branch is needed. True; I just figured this might count as part of dotting all the i's, etc. Happy to skip it if not needed. Go ahead. It might be worthwhile to create a tag after the whitespace changes (same as a branch but without implying later mods) that we can use for easier functional diffs in the future. Done and done, I think. FCGI_ is good. What about docs? Docs will take some time, as they always do. Ryan's original English docs, which are fairly terse, remain on his fastcgi.coremail.cn site. I think it's probably worth taking the time to write a fresh set and one that covers all the more recent configuration directives. Again, this would be a lot easier to do within the existing httpd doc build framework (even if the docs aren't actually committed until the code migrates too), so I'm inclined to wait for an agreement on whether that's the general plan before diving in. Opinions? Chris. -- GPG Key ID: 366A375B GPG Key Fingerprint: 485E 5041 17E1 E2BB C263 E4DE C8E3 FA36 366A 375B
Re: [summary] accept mod_fcgid codebase into httpd project
On Tue, Mar 17, 2009 at 6:44 PM, Chris Darroch chr...@pearsoncmg.comwrote: I'm +1 on the idea of moving toward inclusion in httpd trunk as a module, at least as a longer-term goal. My thoughts were: - Start by branching httpd/mod_fcgid/branches/2.x/mod_fcgid based on the current relicensed code, just in case an emergency turns up (security bug?) and we'd like to do a release based on the existing code; most likely, we won't use this going forward. Many people use mod_fcgid on Apache 2.0/2.2. The message should be that mod_fcgid development has moved to the ASF, and existing users are not being left behind in the transition. So a branch for mod_fcgid 2.x is maintained for httpd 2.0/2.2 users just as our own stable branches are maintained (FAR beyond emergencies, at least for 2.2.x). This isn't necessarily in opposition to what you said, but some might read it as something like Apache took over and they won't distribute fixes that work with my existing configurations except in extreme circumstances. (But of course we should include in httpd trunk for Apache 2.4 and beyond, and make any appropriate changes for consistency, new directions, etc.) - Before we can add to httpd trunk, we need to look at the directive names. There are a large number of config directives with names that don't imply FastCGI and in some cases are a little mysterious. I don't think we can drop 32 new directives into httpd with generic names like SocketPath and PassHeader. Trunk is a fine place to address those issues. BTW, thanks for all your work on this!!!
Re: [summary] accept mod_fcgid codebase into httpd project
Roy T. Fielding wrote: Done. I set all of Ryan Pan's commits to svn:author=pqf (for consistency), loaded the whole thing under httpd/mod_fcgid and fixed the eol-style to native. Please relicense the directory and files first before making any other changes. Thanks! I think the relicensing is all done; anyone who wants to check for errors will get a thank-you. After that, we should remove the generated artifacts and consider moving the subdirectory to a module dir under the server trunk. Which artifacts are you concerned about? I'm not 100% sure what you'd like done here. I'm +1 on the idea of moving toward inclusion in httpd trunk as a module, at least as a longer-term goal. My thoughts were: - Start by branching httpd/mod_fcgid/branches/2.x/mod_fcgid based on the current relicensed code, just in case an emergency turns up (security bug?) and we'd like to do a release based on the existing code; most likely, we won't use this going forward. - Fix the whitespace; currently if you set your tab stops to 4 chars it looks right and close to the httpd style, so it's just a conversion from tabs to spaces that remains. I've got a reformatted version ready to commit. - Before we can add to httpd trunk, we need to look at the directive names. There are a large number of config directives with names that don't imply FastCGI and in some cases are a little mysterious. I don't think we can drop 32 new directives into httpd with generic names like SocketPath and PassHeader. I have an old patch I can dust off to rename these; we should choose a prefix first, though. FCGI or FastCGI? The latter might conflict with mod_fastcgi, but then, why would anyone run both at the same time? Still, perhaps FCGI is best? As for the names themselves, I (natch) have a few suggestions which I think clarify the purpose of some of the more obscure ones and align them with other httpd modules a bit. E.g., DefaultMinClassProcessCount might become FCGIKeepServersPerScript or just FCGIKeep since it resembles mod_dbd's DBDKeep in its purpose. I'd like to branch and apply whitespace changes fairly soon; if folks think that's the wrong approach or if there errors in the newly-applied license text, please let me know! Cheers, Chris. -- GPG Key ID: 366A375B GPG Key Fingerprint: 485E 5041 17E1 E2BB C263 E4DE C8E3 FA36 366A 375B
mod_fcgid
On Mar 17, 2009, at 3:44 PM, Chris Darroch wrote: Roy T. Fielding wrote: Done. I set all of Ryan Pan's commits to svn:author=pqf (for consistency), loaded the whole thing under httpd/mod_fcgid and fixed the eol-style to native. Please relicense the directory and files first before making any other changes. Thanks! I think the relicensing is all done; anyone who wants to check for errors will get a thank-you. I think most of the stuff in NOTICE is documentation that belongs in README. The only things we put in NOTICE files are copyright or attribution lines required by the original copyright owners. After that, we should remove the generated artifacts and consider moving the subdirectory to a module dir under the server trunk. Which artifacts are you concerned about? I'm not 100% sure what you'd like done here. Makefile and .deps should be generated files. I'm +1 on the idea of moving toward inclusion in httpd trunk as a module, at least as a longer-term goal. My thoughts were: - Start by branching httpd/mod_fcgid/branches/2.x/mod_fcgid based on the current relicensed code, just in case an emergency turns up (security bug?) and we'd like to do a release based on the existing code; most likely, we won't use this going forward. We have not done any releases of this code, so we are not responsible for fixing releases that might already exist. In any case, a branch can be created at any time by copying a specific revision number; there is no reason to create it before the branch is needed. - Fix the whitespace; currently if you set your tab stops to 4 chars it looks right and close to the httpd style, so it's just a conversion from tabs to spaces that remains. I've got a reformatted version ready to commit. Go ahead. It might be worthwhile to create a tag after the whitespace changes (same as a branch but without implying later mods) that we can use for easier functional diffs in the future. - Before we can add to httpd trunk, we need to look at the directive names. There are a large number of config directives with names that don't imply FastCGI and in some cases are a little mysterious. I don't think we can drop 32 new directives into httpd with generic names like SocketPath and PassHeader. I have an old patch I can dust off to rename these; we should choose a prefix first, though. FCGI or FastCGI? The latter might conflict with mod_fastcgi, but then, why would anyone run both at the same time? Still, perhaps FCGI is best? FCGI_ is good. What about docs? Roy
Re: [summary] accept mod_fcgid codebase into httpd project
On Feb 18, 2009, at 1:13 PM, Chris Darroch wrote: Roy T. Fielding wrote: I'd suggest that we import the code into SVN by starting not with this temporary package, but with a cvs2svn export of the SourceForge commit history. The relicensing can then follow as a single subsequent commit. Sound OK? Yes, that is what I prefer as well. All paperwork is done, so please let us know when you have an export. I (or one of the other svnadmins) will have to massage it a bit to prefix the sourceforge ids, so just point us to the dump file when you have it ready. It should be in people.apache.org:/home/chrisd/donations/ mod_fcgid now. I used the default full cvs2svn conversion; if you want one with just the trunk and without the small number of CVS tags in the mod_fcgid repository, let me know. There weren't any branches or anything too complex in the SF repository. Done. I set all of Ryan Pan's commits to svn:author=pqf (for consistency), loaded the whole thing under httpd/mod_fcgid and fixed the eol-style to native. Please relicense the directory and files first before making any other changes. After that, we should remove the generated artifacts and consider moving the subdirectory to a module dir under the server trunk. Roy
Re: [summary] accept mod_fcgid codebase into httpd project
Chris Darroch wrote: Roy T. Fielding wrote: Yes, that is what I prefer as well. All paperwork is done, so please let us know when you have an export. I (or one of the other svnadmins) will have to massage it a bit to prefix the sourceforge ids, so just point us to the dump file when you have it ready. It should be in people.apache.org:/home/chrisd/donations/mod_fcgid now. I used the default full cvs2svn conversion; if you want one with just the trunk and without the small number of CVS tags in the mod_fcgid repository, let me know. There weren't any branches or anything too complex in the SF repository. Sorry not to follow up on this for a while; been busy with other stuff. Is there anything else I can help with here? I'd be happy to tackle munging IDs if someone can provide a quick tutorial on what's needed. I should probably also ask about setting up mailing lists, a Bugzilla entry, and getting Web site mojo for mod_fcgid. It would be good to have stuff up and running so we can let people on the old SourceForge mailing lists know about the adoption, among other things. Once the code's in SVN I figured I'd try to do the following: - apply license changes - create legacy 2.x branch - apply whitespace changes to match httpd standard - begin applying functional patches Thoughts? Chris. -- GPG Key ID: 366A375B GPG Key Fingerprint: 485E 5041 17E1 E2BB C263 E4DE C8E3 FA36 366A 375B
Re: [summary] accept mod_fcgid codebase into httpd project
Roy T. Fielding wrote: I'd suggest that we import the code into SVN by starting not with this temporary package, but with a cvs2svn export of the SourceForge commit history. The relicensing can then follow as a single subsequent commit. Sound OK? Yes, that is what I prefer as well. All paperwork is done, so please let us know when you have an export. I (or one of the other svnadmins) will have to massage it a bit to prefix the sourceforge ids, so just point us to the dump file when you have it ready. It should be in people.apache.org:/home/chrisd/donations/mod_fcgid now. I used the default full cvs2svn conversion; if you want one with just the trunk and without the small number of CVS tags in the mod_fcgid repository, let me know. There weren't any branches or anything too complex in the SF repository. Chris. -- GPG Key ID: 366A375B GPG Key Fingerprint: 485E 5041 17E1 E2BB C263 E4DE C8E3 FA36 366A 375B
Re: [summary] accept mod_fcgid codebase into httpd project
Roy T. Fielding wrote: I ended up fixing all website generation to utf-8 -- I am surprised that it lasted this long with just iso-8859-1. Thanks -- looks good! Yes, that is what I prefer as well. All paperwork is done, so please let us know when you have an export. I (or one of the other svnadmins) will have to massage it a bit to prefix the sourceforge ids, so just point us to the dump file when you have it ready. I'll tackle this next week, if tomorrow's not possible. Thanks very much, Chris. -- GPG Key ID: 366A375B GPG Key Fingerprint: 485E 5041 17E1 E2BB C263 E4DE C8E3 FA36 366A 375B
Re: [summary] accept mod_fcgid codebase into httpd project
On Jan 27, 2009, at 9:44 AM, Chris Darroch wrote: The httpd-mod_fcgid.xml file is my first whack at the IP clearance template. I renamed this .xml.utf8 this morning because I realized it has some non-ASCII UTF-8 character sequences in it. I don't know if those will pass through the Incubator's XML-to-HTML transformation smoothly; if not, they could probably be removed. I ended up fixing all website generation to utf-8 -- I am surprised that it lasted this long with just iso-8859-1. 4) The code package is a checkout of the CVS trunk from SourceForge; all I've done is insert LICENSE and NOTICE files, add AL 2.0 license text to all .c, .h, .rc, and .mk files (following the httpd example) and prune out some small text and CVS files. Assuming the Incubator IP clearance review passes, I'd suggest that we import the code into SVN by starting not with this temporary package, but with a cvs2svn export of the SourceForge commit history. The relicensing can then follow as a single subsequent commit. Sound OK? Yes, that is what I prefer as well. All paperwork is done, so please let us know when you have an export. I (or one of the other svnadmins) will have to massage it a bit to prefix the sourceforge ids, so just point us to the dump file when you have it ready. Roy
Re: [summary] accept mod_fcgid codebase into httpd project
Hi -- I wrote: The httpd-mod_fcgid.xml file is my first whack at the IP clearance template. I renamed this .xml.utf8 this morning because I realized it has some non-ASCII UTF-8 character sequences in it. I don't know if those will pass through the Incubator's XML-to-HTML transformation smoothly; if not, they could probably be removed. 4) The code package is a checkout of the CVS trunk from SourceForge; all I've done is insert LICENSE and NOTICE files, add AL 2.0 license text to all .c, .h, .rc, and .mk files (following the httpd example) and prune out some small text and CVS files. Assuming the Incubator IP clearance review passes, I'd suggest that we import the code into SVN by starting not with this temporary package, but with a cvs2svn export of the SourceForge commit history. The relicensing can then follow as a single subsequent commit. Sound OK? Chris. -- GPG Key ID: 366A375B GPG Key Fingerprint: 485E 5041 17E1 E2BB C263 E4DE C8E3 FA36 366A 375B
Re: [summary] accept mod_fcgid codebase into httpd project
William A. Rowe, Jr. wrote: sounds great, the form is here; http://svn.apache.org/repos/asf/incubator/public/trunk/site-author/ip-clearance/ip-clearance-template.xml Good god is incubator/public/trunk/ a mess ;-) I've tried to wade through this and the results are here: http://people.apache.org/~chrisd/donations/mod_fcgid/ The httpd-mod_fcgid.xml file is my first whack at the IP clearance template. You may want to adjust a few things: 1) For officer or member managing donation I put my name, but it should perhaps be whoever commits to the Incubator SVN, for which I lack karma. 2) I added a few extra paragraphs listing the specific information we've gathered here over the last couple of months; these may be something you want to delete. 3) The code package and MD5 and SHA1 signatures are in my personal directory. My reading of the form is that this is OK since the SLA doesn't specifically mention a checksum; as a result we just need a temporary location to host the package while it is reviewed. 4) The code package is a checkout of the CVS trunk from SourceForge; all I've done is insert LICENSE and NOTICE files, add AL 2.0 license text to all .c, .h, .rc, and .mk files (following the httpd example) and prune out some small text and CVS files. The NOTICE file contains an acknowledgment of Ryan's original work and the location of the FastCGI specification (but specifically not the mod_fastcgi code or documentation!) Hope that helps; let me know if there's more I can do. Thanks, Chris. -- GPG Key ID: 366A375B GPG Key Fingerprint: 485E 5041 17E1 E2BB C263 E4DE C8E3 FA36 366A 375B
Re: [summary] accept mod_fcgid codebase into httpd project
William A. Rowe, Jr. wrote: sounds great, the form is here; http://svn.apache.org/repos/asf/incubator/public/trunk/site-author/ip-clearance/ip-clearance-template.xml Good god is incubator/public/trunk/ a mess ;-) OK, I'll take a whack at filling it out and post back the results -- might take a few days. Chris. -- GPG Key ID: 366A375B GPG Key Fingerprint: 485E 5041 17E1 E2BB C263 E4DE C8E3 FA36 366A 375B
Re: [summary] accept mod_fcgid codebase into httpd project
William A. Rowe, Jr. wrote: Sorry, let this thread continue too long, sorry I've been distracted. +1; wrowe, sctemme, issac, rjung, trawick, lars, niq, covener, fielding, jerenkrantz and chrisd. and the support of Albert Lash, Brian Akins and Brian McCallister. The vote passes; next step is to submit the appropriate IP statement to the incubator, wait 72 hours for lazy consensus, and check it in. Thanks! Please let me know if there's anything I can do to help with the IP statement -- drafting, collating email message references, etc. IIRC it's the PMC which has to submit, but I'm happy to do some scut work beforehand if it's useful. Chris. -- GPG Key ID: 366A375B GPG Key Fingerprint: 485E 5041 17E1 E2BB C263 E4DE C8E3 FA36 366A 375B
Re: [summary] accept mod_fcgid codebase into httpd project
Chris Darroch wrote: Thanks! Please let me know if there's anything I can do to help with the IP statement -- drafting, collating email message references, etc. IIRC it's the PMC which has to submit, but I'm happy to do some scut work beforehand if it's useful. sounds great, the form is here; http://svn.apache.org/repos/asf/incubator/public/trunk/site-author/ip-clearance/ip-clearance-template.xml Good god is incubator/public/trunk/ a mess ;-)
[summary] 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 Sorry, let this thread continue too long, sorry I've been distracted. +1; wrowe, sctemme, issac, rjung, trawick, lars, niq, covener, fielding, jerenkrantz and chrisd. and the support of Albert Lash, Brian Akins and Brian McCallister. The vote passes; next step is to submit the appropriate IP statement to the incubator, wait 72 hours for lazy consensus, and check it in.
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 Unless I missed a -1, that looked like a lot of +1s to me ... is there a standard length of time to wait before calling the vote to a close? Assuming the vote passed, what's the next step? The docs at http://incubator.apache.org/ip-clearance/index.html describe an IP clearance submission to the Incubator, to be written by the PMC. Would it help if I tried drafting a version of this which the PMC could then revise? Let me know what's best; thanks, Chris. -- GPG Key ID: 366A375B GPG Key Fingerprint: 485E 5041 17E1 E2BB C263 E4DE C8E3 FA36 366A 375B
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: 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: 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: 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: 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: 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: 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: Transfer Patch Rights for mod_fcgid ASF
Hi, From the thread I get here: http://mail-archives.apache.org/mod_mbox/httpd-dev/200611.mbox/%3cdb4ef19e-148b-41a3-a27c-354b0d640...@gbiv.com%3e The procedure is: (1) make this thread a formal vote and, assuming that passes (2) fill out the incubation paperwork at http://incubator.apache.org/ip-clearance/index.html and then (3) import the code under httpd/mod_wombat Should someone start a vote or further discussion is needed? Thanks - Original Message - From: William A. Rowe, Jr. wr...@rowe-clan.net To: dev@httpd.apache.org Sent: Sunday, January 11, 2009 2:15 AM Subject: Re: Transfer Patch Rights for mod_fcgid ASF Chris Darroch wrote: pqf wrote: Now both authors have subscribe this maillist and claimed to transfer all rights to the patch to the Apache Software Foundation, is it OK? Can we move forward now? Excellent question -- it would seem we have resolved the outstanding issues here, so what is the next step? If we're looking to fast-track adoption, do we submit something to the httpd PMC, the Incubator, or some other body? Take a vote? Any guidance appreciated! Go ahead and review the threads under; http://www.google.com/search?q=site%3Ahttp%3A%2F%2Fmail-archives.apache.org%2Fmod_mbox%2Fhttpd-dev+%22ip+clearance%22+mod_wombatie=utf-8oe=utf-8aq=trls=org.mozilla:en-US:officialclient=firefox-a which is a pretty recent example.
accept mod_fcgid codebase into httpd project
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
Re: accept mod_fcgid codebase into httpd project
[+1] Accept mod_fcgid into httpd from me
Re: accept mod_fcgid codebase into httpd project
+1 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 +/-1 [ ] Accept mod_fcgid into httpd
Re: accept mod_fcgid codebase into httpd project
+1 On Sun, Jan 11, 2009 at 7:55 PM, Albert Lash albert.l...@gmail.com wrote: +1 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 +/-1 [ ] Accept mod_fcgid into httpd
Re: Transfer Patch Rights for mod_fcgid ASF
Chris Darroch wrote: pqf wrote: Now both authors have subscribe this maillist and claimed to transfer all rights to the patch to the Apache Software Foundation, is it OK? Can we move forward now? Excellent question -- it would seem we have resolved the outstanding issues here, so what is the next step? If we're looking to fast-track adoption, do we submit something to the httpd PMC, the Incubator, or some other body? Take a vote? Any guidance appreciated! Go ahead and review the threads under; http://www.google.com/search?q=site%3Ahttp%3A%2F%2Fmail-archives.apache.org%2Fmod_mbox%2Fhttpd-dev+%22ip+clearance%22+mod_wombatie=utf-8oe=utf-8aq=trls=org.mozilla:en-US:officialclient=firefox-a which is a pretty recent example.
Re: Transfer Patch Rights for mod_fcgid ASF
Tim Jensen wrote: I am new to the list. Love apache. It has served me well for over a decade. Keep up the great work. I had previously contributed a patch to the mod_fcgid module whose ownership is being transfered to ASF. As author of my minor little patch to mod_fcgid I gladly transfer all rights to the patch to the Apache Software Foundation. ASF is free so use, modify, delete, or distrubute the patch and any derivative works as they see fit. Thank you for your contribution and your support! Your positive comments are much appreciated by myself and, I feel sure, the community as a whole. Chris. -- GPG Key ID: 366A375B GPG Key Fingerprint: 485E 5041 17E1 E2BB C263 E4DE C8E3 FA36 366A 375B
Re: Transfer Patch Rights for mod_fcgid ASF
pqf wrote: Now both authors have subscribe this maillist and claimed to transfer all rights to the patch to the Apache Software Foundation, is it OK? Can we move forward now? Excellent question -- it would seem we have resolved the outstanding issues here, so what is the next step? If we're looking to fast-track adoption, do we submit something to the httpd PMC, the Incubator, or some other body? Take a vote? Any guidance appreciated! Chris. -- GPG Key ID: 366A375B GPG Key Fingerprint: 485E 5041 17E1 E2BB C263 E4DE C8E3 FA36 366A 375B
Transfer Patch Rights for mod_fcgid ASF
Hello, I am new to the list. Love apache. It has served me well for over a decade. Keep up the great work. I had previously contributed a patch to the mod_fcgid module whose ownership is being transfered to ASF. As author of my minor little patch to mod_fcgid I gladly transfer all rights to the patch to the Apache Software Foundation. ASF is free so use, modify, delete, or distrubute the patch and any derivative works as they see fit. Tim Jensen tim at rtsports dot com
Re: Transfer Patch Rights for mod_fcgid ASF
Hi, Thank you Tim Jensen :) These are the Major patchs which I thought I should ask the patch authors: Major patches version 1.10 ( Jul 3rd 2006 ) 1. Use poll() instead of select() in UNIX. It becomes problematic on apache2 with large number of logfiles. Apache2 calls poll() (when OS supports it), and in that case it doesn't need to be recompiled with larger FD_SETSIZE. select() is still limited to FD_SETSIZE.(Thank Piotr Gackiewicz gacek at intertele.pl for the patch.) 2. Bug fix: Some requests fail with HTTP 500 and no errorlog entry is generated (Thank Piotr Gackiewicz gacek at intertele.pl for the patch.) Version2.2 (Jul 31st 2007) 3. Support configuration TimeScore Thank Tim Jensen for the patch. (This is a patch from sourceforge.net: https://sourceforge.net/tracker/download.php?group_id=174879atid=870993file_id=218023aid=1670268, author is https://sourceforge.net/users/timjensen66/) Now both authors have subscribe this maillist and claimed to transfer all rights to the patch to the Apache Software Foundation, is it OK? Can we move forward now? - Original Message - From: Tim Jensen t...@rtsports.com To: dev@httpd.apache.org Sent: Friday, January 09, 2009 2:05 AM Subject: Transfer Patch Rights for mod_fcgid ASF Hello, I am new to the list. Love apache. It has served me well for over a decade. Keep up the great work. I had previously contributed a patch to the mod_fcgid module whose ownership is being transfered to ASF. As author of my minor little patch to mod_fcgid I gladly transfer all rights to the patch to the Apache Software Foundation. ASF is free so use, modify, delete, or distrubute the patch and any derivative works as they see fit. Tim Jensen tim at rtsports dot com
Re: mod_fcgid license questions
Piotr Gackiewicz wrote: Hi, my name is Piotr Gackiewicz and I am the autor of these patches. I confirm, that I personaly consider them as minor changes and agree, that you should put them into minor patch group. Without signing CLA and official Software Grant. I appreciate transferring this software into ASF very much and would like thank all you guys for the great work you put into this great software, which Apache is. Thanks for your reply, your agreement, and your contribution! Much appreciated, Chris. -- GPG Key ID: 366A375B GPG Key Fingerprint: 485E 5041 17E1 E2BB C263 E4DE C8E3 FA36 366A 375B
Re: Re: mod_fcgid license questions
Hi, guys Good news is I track down another author now. We are talking about the license questions now, so far so good :) Thanks -原始邮件- 发件人: Chris Darroch chr...@pearsoncmg.com 发送时间: 2009年1月1日 星期四 收件人: dev@httpd.apache.org 抄送: 主题: Re: mod_fcgid license questions Hi -- On 31 Dec 2008, at 05:48, Roy T. Fielding wrote: Foes anyone have a sense of whether these would indeed require a CLA and SGA? They look like simple repairs to me. More importantly, if he thinks they are simple repairs and he is happy to see them Apache Licensed, then there is no need for a CLA or software grant. +1. This is in the same ballpark as third-party patches we routinely accept, e.g. from reports in bugzilla. OK, that sounds reasonable. I think we're just waiting to hear from one other person, then. Chris. -- GPG Key ID: 366A375B GPG Key Fingerprint: 485E 5041 17E1 E2BB C263 E4DE C8E3 FA36 366A 375B
Re: mod_fcgid license questions
On Wed, 31 Dec 2008, pqf wrote: Hi, guys Thanks Chris first :) Please take a look at the attachments, I got it from my mail archive. The errorlog patch is a minor patch. the poll patch change not much lines of code, but it did come with original idea. If Piotr Gackiewicz think his job is simple repairs, I think these patchs can be put to minor patch group too. - Original Message - From: Chris Darroch chr...@pearsoncmg.com To: dev@httpd.apache.org Sent: Wednesday, December 31, 2008 1:31 PM Subject: Re: mod_fcgid license questions pqf wrote: version 1.10 ( Jul 3rd 2006 ) 1. Use poll() instead of select() in UNIX. It becomes problematic on apache2 with large number of logfiles. Apache2 calls poll() (when OS supports it), and in that case it doesn't need to be recompiled with larger FD_SETSIZE. select() is still limited to FD_SETSIZE. (Thank Piotr Gackiewicz gacek at intertele.pl for the patch.) 2. Bug fix: Some requests fail with HTTP 500 and no errorlog entry is generated (Thank Piotr Gackiewicz gacek at intertele.pl for the patch.) Hi, my name is Piotr Gackiewicz and I am the autor of these patches. I confirm, that I personaly consider them as minor changes and agree, that you should put them into minor patch group. Without signing CLA and official Software Grant. I appreciate transferring this software into ASF very much and would like thank all you guys for the great work you put into this great software, which Apache is. Best regards, -- Piotr Gackiewicz Intertele S.A. - operator systemów ITL.PL i DOMENY.ITL.PL al. T. Rejtana 1, 35-326 Rzeszów TEL: +48 17 8507580, FAX: +48 17 8520275, INFOLINIA: 0 801 335523 http://www.itl.pl - niezawodne serwery wirtualne http://domeny.itl.pl- tanie domeny internetowe http://www.intertele.pl
Re: mod_fcgid license questions
On 31 Dec 2008, at 05:48, Roy T. Fielding wrote: Foes anyone have a sense of whether these would indeed require a CLA and SGA? They look like simple repairs to me. More importantly, if he thinks they are simple repairs and he is happy to see them Apache Licensed, then there is no need for a CLA or software grant. +1. This is in the same ballpark as third-party patches we routinely accept, e.g. from reports in bugzilla. -- Nick Kew
Re: mod_fcgid license questions
Hi -- On 31 Dec 2008, at 05:48, Roy T. Fielding wrote: Foes anyone have a sense of whether these would indeed require a CLA and SGA? They look like simple repairs to me. More importantly, if he thinks they are simple repairs and he is happy to see them Apache Licensed, then there is no need for a CLA or software grant. +1. This is in the same ballpark as third-party patches we routinely accept, e.g. from reports in bugzilla. OK, that sounds reasonable. I think we're just waiting to hear from one other person, then. Chris. -- GPG Key ID: 366A375B GPG Key Fingerprint: 485E 5041 17E1 E2BB C263 E4DE C8E3 FA36 366A 375B
Re: mod_fcgid license questions
pqf wrote:
version 1.10 ( Jul 3rd 2006 )
1. Use poll() instead of select() in UNIX. It becomes problematic on
apache2 with large number of logfiles. Apache2 calls poll()
(when OS supports it), and in that case it doesn't need to be recompiled
with larger FD_SETSIZE. select() is still limited to FD_SETSIZE.
(Thank Piotr Gackiewicz gacek at intertele.pl for the patch.)
2. Bug fix: Some requests fail with HTTP 500 and no errorlog entry is
generated (Thank Piotr Gackiewicz gacek at intertele.pl for the patch.)
Ryan has been in touch with Piotr Gackiewicz independently and Piotr
asks if we can confirm that a CLA and SGA are necessary, as he considers
his contribution to have been just simple repairs (his term).
From looking over the CVS repository at
http://mod-fcgid.cvs.sourceforge.net/viewvc/mod-fcgid/mod_fcgid/
it would appear to me that these patches amount to the following.
Foes anyone have a sense of whether these would indeed require
a CLA and SGA?
Chris.
=
--- fcgid_bridge.c2006/01/22 14:16:231.25
+++ fcgid_bridge.c2006/05/13 23:45:441.26
@@ -256,8 +256,11 @@
}
bucket_ctx = apr_pcalloc(request_pool, sizeof(*bucket_ctx));
-if (!bucket_ctx)
+if (!bucket_ctx) {
+ap_log_error(APLOG_MARK, APLOG_WARNING, rv, r-server,
+ mod_fcgid: apr_calloc of %d bytes failed in handle_request
function, sizeof(*bucket_ctx));
return HTTP_INTERNAL_SERVER_ERROR;
+}
bucket_ctx-ipc.connect_timeout = g_connect_timeout;
bucket_ctx-ipc.communation_timeout = g_comm_timeout;
bucket_ctx-ipc.request = r;
@@ -315,7 +318,7 @@
/* Now I get a connected ipc handle */
if (!bucket_ctx-procnode) {
-ap_log_error(APLOG_MARK, APLOG_INFO, 0, r-server,
+ap_log_error(APLOG_MARK, APLOG_WARNING, 0, r-server,
mod_fcgid: can't apply process slot for %s, argv0);
return HTTP_SERVICE_UNAVAILABLE;
}
@@ -326,7 +329,7 @@
if ((rv =
proc_write_ipc(main_server, bucket_ctx-ipc,
output_brigade)) != APR_SUCCESS) {
-ap_log_error(APLOG_MARK, APLOG_INFO, rv, r-server,
+ap_log_error(APLOG_MARK, APLOG_WARNING, rv, r-server,
mod_fcgid: write data to fastcgi server error);
bucket_ctx-has_error = 1;
return HTTP_INTERNAL_SERVER_ERROR;
@@ -335,8 +338,11 @@
/* Create brigade */
brigade_stdout =
apr_brigade_create(request_pool, r-connection-bucket_alloc);
-if (!brigade_stdout)
+if (!brigade_stdout) {
+ap_log_error(APLOG_MARK, APLOG_WARNING, rv, r-server,
+ mod_fcgid: apr_brigade_create failed in handle_request
function);
return HTTP_INTERNAL_SERVER_ERROR;
+}
APR_BRIGADE_INSERT_TAIL(brigade_stdout,
ap_bucket_fcgid_header_create(r-connection-
bucket_alloc,
@@ -346,7 +352,11 @@
/* Check the script header first. If got error, return immediately */
if ((cond_status = ap_scan_script_header_err_core
(r, sbuf, getsfunc_fcgid_BRIGADE, brigade_stdout)) = 400)
+{
+ap_log_error(APLOG_MARK, APLOG_INFO, rv, r-server,
+mod_fcgid: ap_scan_script_header_err_core failed in
handle_request function: %d, cond_status);
return cond_status;
+}
/* Check redirect */
location = apr_table_get(r-headers_out, Location);
@@ -377,6 +387,9 @@
if ((rv =
ap_pass_brigade(r-output_filters,
brigade_stdout)) != APR_SUCCESS) {
+ap_log_error(APLOG_MARK, APLOG_WARNING, rv, r-server,
+ mod_fcgid: ap_pass_brigade failed in handle_request
function);
+
return HTTP_INTERNAL_SERVER_ERROR;
}
@@ -437,7 +450,7 @@
AP_MODE_READBYTES,
APR_BLOCK_READ,
HUGE_STRING_LEN)) != APR_SUCCESS) {
-ap_log_error(APLOG_MARK, APLOG_INFO, rv,
+ap_log_error(APLOG_MARK, APLOG_WARNING, rv,
main_server,
mod_fcgid: can't get data from http client);
apr_brigade_destroy(output_brigade);
--- arch/unix/fcgid_proc_unix.c2006/01/22 14:16:231.27
+++ arch/unix/fcgid_proc_unix.c2006/05/13 23:45:441.28
@@ -2,6 +2,7 @@
#include sys/un.h
#include sys/types.h
#include netinet/tcp.h/* For TCP_NODELAY */
+#include sys/poll.h
#define CORE_PRIVATE
#include httpd.h
#include apr_thread_proc.h
@@ -525,10 +526,9 @@
fcgid_ipc * ipc_handle, const char *buffer,
apr_size_t * size)
{
-fd_set rset;
-struct timeval tv;
int retcode, unix_socket;
fcgid_namedpipe_handle *handle_info;
+struct pollfd pollfds[1];
handle_info = (fcgid_namedpipe_handle *) ipc_handle-ipc_handle_info
Re: mod_fcgid license questions
On Dec 31, 2008, at 6:31 PM, Chris Darroch wrote: pqf wrote: version 1.10 ( Jul 3rd 2006 ) 1. Use poll() instead of select() in UNIX. It becomes problematic on apache2 with large number of logfiles. Apache2 calls poll() (when OS supports it), and in that case it doesn't need to be recompiled with larger FD_SETSIZE. select() is still limited to FD_SETSIZE. (Thank Piotr Gackiewicz gacek at intertele.pl for the patch.) 2. Bug fix: Some requests fail with HTTP 500 and no errorlog entry is generated (Thank Piotr Gackiewicz gacek at intertele.pl for the patch.) Ryan has been in touch with Piotr Gackiewicz independently and Piotr asks if we can confirm that a CLA and SGA are necessary, as he considers his contribution to have been just simple repairs (his term). From looking over the CVS repository at http://mod-fcgid.cvs.sourceforge.net/viewvc/mod-fcgid/mod_fcgid/ it would appear to me that these patches amount to the following. Foes anyone have a sense of whether these would indeed require a CLA and SGA? They look like simple repairs to me. More importantly, if he thinks they are simple repairs and he is happy to see them Apache Licensed, then there is no need for a CLA or software grant. Roy
Re: mod_fcgid license questions
Hi, guys
Thanks Chris first :)
Please take a look at the attachments, I got it from my mail archive. The
errorlog patch is a minor patch. the poll patch change not much lines of code,
but it did come with original idea.If Piotr Gackiewicz think his job is
simple repairs, I think these patchs can be put to minor patch group too.
Thanks
- Original Message -
From: Chris Darroch chr...@pearsoncmg.com
To: dev@httpd.apache.org
Sent: Wednesday, December 31, 2008 1:31 PM
Subject: Re: mod_fcgid license questions
pqf wrote:
version 1.10 ( Jul 3rd 2006 )
1. Use poll() instead of select() in UNIX. It becomes problematic on
apache2 with large number of logfiles. Apache2 calls poll()
(when OS supports it), and in that case it doesn't need to be recompiled
with larger FD_SETSIZE. select() is still limited to FD_SETSIZE.
(Thank Piotr Gackiewicz gacek at intertele.pl for the patch.)
2. Bug fix: Some requests fail with HTTP 500 and no errorlog entry is
generated (Thank Piotr Gackiewicz gacek at intertele.pl for the patch.)
Ryan has been in touch with Piotr Gackiewicz independently and Piotr
asks if we can confirm that a CLA and SGA are necessary, as he considers
his contribution to have been just simple repairs (his term).
From looking over the CVS repository at
http://mod-fcgid.cvs.sourceforge.net/viewvc/mod-fcgid/mod_fcgid/
it would appear to me that these patches amount to the following.
Foes anyone have a sense of whether these would indeed require
a CLA and SGA?
Chris.
=
--- fcgid_bridge.c2006/01/22 14:16:231.25
+++ fcgid_bridge.c2006/05/13 23:45:441.26
@@ -256,8 +256,11 @@
}
bucket_ctx = apr_pcalloc(request_pool, sizeof(*bucket_ctx));
-if (!bucket_ctx)
+if (!bucket_ctx) {
+ap_log_error(APLOG_MARK, APLOG_WARNING, rv, r-server,
+ mod_fcgid: apr_calloc of %d bytes failed in
handle_request function, sizeof(*bucket_ctx));
return HTTP_INTERNAL_SERVER_ERROR;
+}
bucket_ctx-ipc.connect_timeout = g_connect_timeout;
bucket_ctx-ipc.communation_timeout = g_comm_timeout;
bucket_ctx-ipc.request = r;
@@ -315,7 +318,7 @@
/* Now I get a connected ipc handle */
if (!bucket_ctx-procnode) {
-ap_log_error(APLOG_MARK, APLOG_INFO, 0, r-server,
+ap_log_error(APLOG_MARK, APLOG_WARNING, 0, r-server,
mod_fcgid: can't apply process slot for %s, argv0);
return HTTP_SERVICE_UNAVAILABLE;
}
@@ -326,7 +329,7 @@
if ((rv =
proc_write_ipc(main_server, bucket_ctx-ipc,
output_brigade)) != APR_SUCCESS) {
-ap_log_error(APLOG_MARK, APLOG_INFO, rv, r-server,
+ap_log_error(APLOG_MARK, APLOG_WARNING, rv, r-server,
mod_fcgid: write data to fastcgi server error);
bucket_ctx-has_error = 1;
return HTTP_INTERNAL_SERVER_ERROR;
@@ -335,8 +338,11 @@
/* Create brigade */
brigade_stdout =
apr_brigade_create(request_pool, r-connection-bucket_alloc);
-if (!brigade_stdout)
+if (!brigade_stdout) {
+ap_log_error(APLOG_MARK, APLOG_WARNING, rv, r-server,
+ mod_fcgid: apr_brigade_create failed in handle_request
function);
return HTTP_INTERNAL_SERVER_ERROR;
+}
APR_BRIGADE_INSERT_TAIL(brigade_stdout,
ap_bucket_fcgid_header_create(r-connection-
bucket_alloc,
@@ -346,7 +352,11 @@
/* Check the script header first. If got error, return immediately */
if ((cond_status = ap_scan_script_header_err_core
(r, sbuf, getsfunc_fcgid_BRIGADE, brigade_stdout)) = 400)
+{
+ap_log_error(APLOG_MARK, APLOG_INFO, rv, r-server,
+mod_fcgid: ap_scan_script_header_err_core failed in
handle_request function: %d, cond_status);
return cond_status;
+}
/* Check redirect */
location = apr_table_get(r-headers_out, Location);
@@ -377,6 +387,9 @@
if ((rv =
ap_pass_brigade(r-output_filters,
brigade_stdout)) != APR_SUCCESS) {
+ap_log_error(APLOG_MARK, APLOG_WARNING, rv, r-server,
+ mod_fcgid: ap_pass_brigade failed in handle_request
function);
+
return HTTP_INTERNAL_SERVER_ERROR;
}
@@ -437,7 +450,7 @@
AP_MODE_READBYTES,
APR_BLOCK_READ,
HUGE_STRING_LEN)) != APR_SUCCESS) {
-ap_log_error(APLOG_MARK, APLOG_INFO, rv,
+ap_log_error(APLOG_MARK, APLOG_WARNING, rv,
main_server,
mod_fcgid: can't get data from http client);
apr_brigade_destroy(output_brigade);
--- arch/unix/fcgid_proc_unix.c2006
Re: mod_fcgid license questions
On Fri, 19 Dec 2008 21:43:01 -0800 Chris Darroch chr...@pearsoncmg.com wrote: pqf wrote: Sorry for the delay, I have track down all patches base on my ChangeLog ( I keep my mail archive), so here is my brief: Minor patches ...Ignore here, I attach a file to show every modification to every ChangeLog entry. (If anyone think any change is major, please let me know) On a quick skim-through, what looks like the only large patch here belongs to Nick Kew, who's also an active httpd committer. Hmmm, I know I've sent feedback to Ryan on mod_fcgid, but I really didn't think it was anything substantial. If it's the biggest contribution not yet covered, then I think we're basically there. So, that mean there are other two people are involved. If that's all it is, that should be fairly simple. I guess I'll ask the list again what the next step should be ... a vote? Contacting these folks? Advice appreciated! Thanks, happy holidays to everyone. Contact those two people, explain that a donation has been proposed, and ask if they're happy to have their work relicensed under ASL? IMO it's probably best if Ryan contacts them in the first instance, but it might be easiest for a native English speaker to draft the message. I don't mind giving it some thought once my wretched cold has cleared out of my head. -- Nick Kew
Re: mod_fcgid license questions
On Dec 16, 2008, at 4:30 PM, Ruediger Pluem wrote: On 12/16/2008 10:08 PM, William A. Rowe, Jr. wrote: Chris Darroch wrote: pqf wrote: For the moment, though, I think we're just waiting for some feedback from other httpd developers and especially those with some experience of the Incubator process. I or someone else likely needs to draft and submit a proposal to the Incubator, for example, as a next step. Any thoughts here from other folks? I'd prefer that we simply sponsor this effort under the httpd PMC here at our project. We have to file an IP code clearance through the Incubator, but that's relatively simple (and a good part is finished already now that the appropriate paperwork is filed with the secretary). Does anyone feel that the addition of mod_fcgid should be driven through the incubator? Speaking first hand, it didn't resolve the shortcomings of lack of community behind mod_aspdotnet, and didn't really give mod_ftp the visibility it needed (and attracted once it graduated). So for most existing modules, I don't think it solves many of the problems we might or might not face here at httpd. +1. I see no need to put it in the incubator, except for the IP code clearance paperwork. So it seems that the above fast track through the incubator to do just that should be enough. Afterwards put it in trunk and lets see how we can 'merge' it with mod_proxy_fcgi. +1.
Re: mod_fcgid license questions
pqf wrote: Sorry for the delay, I have track down all patches base on my ChangeLog ( I keep my mail archive), so here is my brief: Minor patches ...Ignore here, I attach a file to show every modification to every ChangeLog entry. (If anyone think any change is major, please let me know) On a quick skim-through, what looks like the only large patch here belongs to Nick Kew, who's also an active httpd committer. Major patches So, that mean there are other two people are involved. If that's all it is, that should be fairly simple. I guess I'll ask the list again what the next step should be ... a vote? Contacting these folks? Advice appreciated! Thanks, happy holidays to everyone. Chris. -- GPG Key ID: 366A375B GPG Key Fingerprint: 485E 5041 17E1 E2BB C263 E4DE C8E3 FA36 366A 375B
Re: mod_fcgid license questions
Hi, all
Sorry for the delay, I have track down all patches base on my ChangeLog( I
keep my mail archive), so here is my brief:
the Inside job
version 0.76 ( Jul 6th 2004 )
1. Code fix. Replace the depreciated BRIGADE_FOREACH macro, which compile
against httpd 2.1-Dev.
(Patch by Paul Querna(chip at force-elite.com))
Version2.1 ( Feb 15th 2007 )
3. Bug fix. Authoritative flag reversed
Thank Chris Darroch for the patch
---
Minor patches
...Ignore here, I attach a file to show every modification to every ChangeLog
entry. (If anyone think any change is major, please let me know)
Major patches
version 1.10 ( Jul 3rd 2006 )
1. Use poll() instead of select() in UNIX. It becomes problematic on apache2
with large number of logfiles. Apache2 calls poll() (when OS supports it), and
in that case it doesn't need to be recompiled with larger FD_SETSIZE. select()
is still limited to FD_SETSIZE.(Thank Piotr Gackiewicz gacek at intertele.pl
for the patch.)
2. Bug fix: Some requests fail with HTTP 500 and no errorlog entry is
generated (Thank Piotr Gackiewicz gacek at intertele.pl for the patch.)
Version2.2 (Jul 31st 2007)
3. Support configuration TimeScore
Thank Tim Jensen for the patch.
(This is a patch from sourceforge.net:
https://sourceforge.net/tracker/download.php?group_id=174879atid=870993file_id=218023aid=1670268,
author is https://sourceforge.net/users/timjensen66/)
So, that mean there are other two people are involved.
Thanks
- Original Message -
From: Chris Darroch chr...@pearsoncmg.com
To: dev@httpd.apache.org
Sent: Thursday, December 18, 2008 1:20 PM
Subject: Re: mod_fcgid license questions
William A. Rowe, Jr. wrote:
How many are we talking about (in the significant category)? The
easiest way probably depends on how many people, how easy they are
to contact, etc.
Ryan, do you have a rough sense of this?
From my own review of the ChangeLog, it looks like there are
roughly about 10-12 major contributions by others (two of whom are
httpd committers). There are lots of additional people listed,
but these seem to divide up between minor patch contributions,
thanks for bug reports or for testing a bug fix, or thanks for
suggesting a possible new feature.
Clearly, though, we'll need Ryan to look through and identify
the major contributors.
I'd prefer that we simply sponsor this effort under the httpd PMC here
at our project.
We have to file an IP code clearance through the Incubator, but that's
relatively simple (and a good part is finished already now that the
appropriate paperwork is filed with the secretary).
Does anyone feel that the addition of mod_fcgid should be driven through
the incubator? Speaking first hand, it didn't resolve the shortcomings
of lack of community behind mod_aspdotnet, and didn't really give mod_ftp
the visibility it needed (and attracted once it graduated). So for most
existing modules, I don't think it solves many of the problems we might
or might not face here at httpd.
I really don't know all the options here, but from what you describe,
it sounds like a faster track to get the IP code clearance done would
be ideal, if possible. So, a +1 from me if this is feasible.
Thanks,
Chris.
--
GPG Key ID: 366A375B
GPG Key Fingerprint: 485E 5041 17E1 E2BB C263 E4DE C8E3 FA36 366A 375B
--
version 1.04 ( Dec 2nd 2004 )
1. Bug fix. ap_scan_script_header_err_core can return non OK without errors.
e.g. CGI outputs Last-Modified header and browser request with
If-Mofieided-Since header, ap_scan_script_header_err_core() may returns 302(Not
Modified)
(Thank Tatsuki Sugiura, sugi at nemui.org for the bug fix patch)
--- fcgid_bridge.c.orig 2004-11-11 09:40:17.0 +0900
+++ fcgid_bridge.c 2004-11-11 09:41:30.0 +0900
@@ -217,7 +217,7 @@
server_rec *main_server = r-server;
fcgid_command fcgi_request;
fcgid_bucket_ctx *bucket_ctx;
- int i, stopping;
+ int i, stopping, cond_status;
apr_status_t rv;
apr_bucket_brigade *brigade_stdout;
char sbuf[MAX_STRING_LEN];
@@ -330,11 +330,10 @@
bucket_ctx));
/*APR_BRIGADE_INSERT_TAIL(brigade_stdout,
apr_bucket_flush_create(r-connection-bucket_alloc)); */
- /* Check the script header first */
- if (ap_scan_script_header_err_core
- (r, sbuf, getsfunc_fcgid_BRIGADE, brigade_stdout) != OK) {
- return HTTP_INTERNAL_SERVER_ERROR;
- }
+ /* Check the script header first. If got error, return immediately */
+ if ((cond_status = ap_scan_script_header_err_core
+ (r, sbuf, getsfunc_fcgid_BRIGADE, brigade_stdout)) = 400)
+ return cond_status;
/* Check redirect */
location = apr_table_get(r
Re: mod_fcgid license questions
William A. Rowe, Jr. wrote: How many are we talking about (in the significant category)? The easiest way probably depends on how many people, how easy they are to contact, etc. Ryan, do you have a rough sense of this? From my own review of the ChangeLog, it looks like there are roughly about 10-12 major contributions by others (two of whom are httpd committers). There are lots of additional people listed, but these seem to divide up between minor patch contributions, thanks for bug reports or for testing a bug fix, or thanks for suggesting a possible new feature. Clearly, though, we'll need Ryan to look through and identify the major contributors. I'd prefer that we simply sponsor this effort under the httpd PMC here at our project. We have to file an IP code clearance through the Incubator, but that's relatively simple (and a good part is finished already now that the appropriate paperwork is filed with the secretary). Does anyone feel that the addition of mod_fcgid should be driven through the incubator? Speaking first hand, it didn't resolve the shortcomings of lack of community behind mod_aspdotnet, and didn't really give mod_ftp the visibility it needed (and attracted once it graduated). So for most existing modules, I don't think it solves many of the problems we might or might not face here at httpd. I really don't know all the options here, but from what you describe, it sounds like a faster track to get the IP code clearance done would be ideal, if possible. So, a +1 from me if this is feasible. Thanks, Chris. -- GPG Key ID: 366A375B GPG Key Fingerprint: 485E 5041 17E1 E2BB C263 E4DE C8E3 FA36 366A 375B
Re: mod_fcgid license questions
Hi, all I have signed the two documents( http://www.apache.org/licenses/software-grant.txt and http://www.apache.org/licenses/iclas), and emailed the scan version to secretary at apache.org. So what I should do next is? Should I contact all major contributors and ask for the agreement to this: http://www.apache.org/licenses/software-grant.txt. Or I just identify all the major contributors and wait for next step? Anything I can do please let me know :) Thanks - Original Message - From: William A. Rowe, Jr. wr...@rowe-clan.net To: dev@httpd.apache.org; Ryan pan p...@mailtech.cn Sent: Saturday, December 13, 2008 11:18 AM Subject: Re: mod_fcgid license questions pqf wrote: Hi, guys Nice to meet you :) I hope I can help to clarify the questions. Likewise :) When you wrote mod_fcgid, was there any code which you borrowed from mod_fastcgi? No. I didn't borrow any code from mod_fastcgi. That's good - we are looking at the headers you use and the fcgi package liberal licensing (as opposed to the mod_fastcgi package). Your current intention is for mod_fcgid to be available under the GPL version 2.0, correct? Could you confirm that you wanted the GPL to apply to all the mod_fcgid code? Yes, I confirm I wanted the GPL version 2.0 apply to everything. So to clarify, you don't seem strongly married to any particular license. Is the AL 2.0 acceptable and would you be willing to license it such, or offer a software grant under the terms of the AL 2.0? See http://www.apache.org/licenses/software-grant.txt we would also want to capture a CLA so that you can contribute your own ideas to the new code http://www.apache.org/licenses/#clas Finally, if there are other contributors to the efforts, aside from the obvious simple bug fixes and maintenance, we would need their buy-in as well, and count on you to identify such people that have shaped fcgid. Looking forward to this solution! Bill
Re: mod_fcgid license questions
pqf wrote: I have signed the two documents ( http://www.apache.org/licenses/software-grant.txt and http://www.apache.org/licenses/iclas), and emailed the scan version to secretary at apache.org. So what I should do next is? Should I contact all major contributors and ask for the agreement to this: http://www.apache.org/licenses/software-grant.txt. Or I just identify all the major contributors and wait for next step? Anything I can do please let me know :) Thanks, Ryan -- that was fast! :-) I think first we probably need to wait for the secretary to check the documents and let you know if there's anything left to do with those. Beyond that, I think we're waiting for some consensus (if more is needed) from httpd committers that they'd like to proceed, and then, yes, I'd expect that while in the Incubator we'd hope for your help in tracking down the major contributors. For the moment, though, I think we're just waiting for some feedback from other httpd developers and especially those with some experience of the Incubator process. I or someone else likely needs to draft and submit a proposal to the Incubator, for example, as a next step. Any thoughts here from other folks? One thing to note is that with Christmas and other end-of-year holidays coming up things might move a little slowly for a couple of weeks. Thank you again for your efforts! Chris. -- GPG Key ID: 366A375B GPG Key Fingerprint: 485E 5041 17E1 E2BB C263 E4DE C8E3 FA36 366A 375B
Re: mod_fcgid license questions
Chris Darroch wrote: pqf wrote: I have signed the two documents ( http://www.apache.org/licenses/software-grant.txt and http://www.apache.org/licenses/iclas), and emailed the scan version to secretary at apache.org. So what I should do next is? Should I contact all major contributors and ask for the agreement to this: http://www.apache.org/licenses/software-grant.txt. Or I just identify all the major contributors and wait for next step? Anything I can do please let me know :) Yea; since all of your significant contributors (excluding simple maintenance fixes and things that can't be copyrighted, such as data or facts) assigned license as GPL, they need to relicense their work as Apache License, sign a grant for their contributions or just file an iclas and offer their patch(es) to this list. How many are we talking about (in the significant category)? The easiest way probably depends on how many people, how easy they are to contact, etc. For the moment, though, I think we're just waiting for some feedback from other httpd developers and especially those with some experience of the Incubator process. I or someone else likely needs to draft and submit a proposal to the Incubator, for example, as a next step. Any thoughts here from other folks? I'd prefer that we simply sponsor this effort under the httpd PMC here at our project. We have to file an IP code clearance through the Incubator, but that's relatively simple (and a good part is finished already now that the appropriate paperwork is filed with the secretary). Does anyone feel that the addition of mod_fcgid should be driven through the incubator? Speaking first hand, it didn't resolve the shortcomings of lack of community behind mod_aspdotnet, and didn't really give mod_ftp the visibility it needed (and attracted once it graduated). So for most existing modules, I don't think it solves many of the problems we might or might not face here at httpd.
Re: mod_fcgid license questions
On 12/16/2008 10:08 PM, William A. Rowe, Jr. wrote: Chris Darroch wrote: pqf wrote: For the moment, though, I think we're just waiting for some feedback from other httpd developers and especially those with some experience of the Incubator process. I or someone else likely needs to draft and submit a proposal to the Incubator, for example, as a next step. Any thoughts here from other folks? I'd prefer that we simply sponsor this effort under the httpd PMC here at our project. We have to file an IP code clearance through the Incubator, but that's relatively simple (and a good part is finished already now that the appropriate paperwork is filed with the secretary). Does anyone feel that the addition of mod_fcgid should be driven through the incubator? Speaking first hand, it didn't resolve the shortcomings of lack of community behind mod_aspdotnet, and didn't really give mod_ftp the visibility it needed (and attracted once it graduated). So for most existing modules, I don't think it solves many of the problems we might or might not face here at httpd. +1. I see no need to put it in the incubator, except for the IP code clearance paperwork. So it seems that the above fast track through the incubator to do just that should be enough. Afterwards put it in trunk and lets see how we can 'merge' it with mod_proxy_fcgi. Regards Rüdiger
Re: mod_fcgid license questions
pqf wrote: When you wrote mod_fcgid, was there any code which you borrowed from mod_fastcgi? No. I didn't borrow any code from mod_fastcgi. Your current intention is for mod_fcgid to be available under the GPL version 2.0, correct? Could you confirm that you wanted the GPL to apply to all the mod_fcgid code? Yes, I confirm I wanted the GPL version 2.0 apply to everything. But I would like to see someone else take over my mod_fcgid project and continune to make it better. I get a lot from the others (that why I like open source and share), and I would like to share to the other if I have a chance. It's my pleasure if ASF willing to take it over. Thanks, Ryan, for replying so promptly! OK, well, how should we proceed from here? From my reading of the Incubator process, if there's some consensus on this list that we'd like to explore adopting mod_fcgid, we begin by recruiting a Champion and then working on a proposal to make to the Incubator PMC. If accepted, I assume we'd then get a license grant or transfer from Ryan and work on tracking down those folks from the ChangeLog who've made substantial contributions (more than just repair work). Are there steps I'm not aware of here? Advice from those on the Incubator PMC or with Incubator experience would be most welcome. Thanks, Chris. -- GPG Key ID: 366A375B GPG Key Fingerprint: 485E 5041 17E1 E2BB C263 E4DE C8E3 FA36 366A 375B
Re: mod_fcgid license questions
pqf wrote: Hi, guys Nice to meet you :) I hope I can help to clarify the questions. Likewise :) When you wrote mod_fcgid, was there any code which you borrowed from mod_fastcgi? No. I didn't borrow any code from mod_fastcgi. That's good - we are looking at the headers you use and the fcgi package liberal licensing (as opposed to the mod_fastcgi package). Your current intention is for mod_fcgid to be available under the GPL version 2.0, correct? Could you confirm that you wanted the GPL to apply to all the mod_fcgid code? Yes, I confirm I wanted the GPL version 2.0 apply to everything. So to clarify, you don't seem strongly married to any particular license. Is the AL 2.0 acceptable and would you be willing to license it such, or offer a software grant under the terms of the AL 2.0? See http://www.apache.org/licenses/software-grant.txt we would also want to capture a CLA so that you can contribute your own ideas to the new code http://www.apache.org/licenses/#clas Finally, if there are other contributors to the efforts, aside from the obvious simple bug fixes and maintenance, we would need their buy-in as well, and count on you to identify such people that have shaped fcgid. Looking forward to this solution! Bill
Re: mod_fcgid incubation?
On Dec 10, 2008, at 8:05 PM, Roy T. Fielding wrote: On Dec 10, 2008, at 4:51 AM, Jim Jagielski wrote: On Dec 9, 2008, at 4:56 PM, Nick Kew wrote: It's unfortunate there's no clear copyright statement, but would it not be reasonable to assume Copyright Pan Qingfeng and deal with him? Contact other contributors as a courtesy, but not let it worry us if some of them prove uncontactable, only if someone actually objects? Submitting a patch or code does not imply copyright assignment. So we cannot assume copyright Pan for the whole thing. Right, but not all code has a separate copyright. Repairs, for example, do not. So it is actually feasible that Pan can determine who needs to be contacted based on the change log and only contact those whose contributions were more than repairs to Pan's work. +1
mod_fcgid license questions
Hi -- I believe Pan Qingfeng (潘庆峰), the developer of mod_fcgid, has joined this list for the time being while the possibility of mod_fcgid becoming project in the Apache incubator is discussed. I'll use his English name of Ryan Pan from here on. I asked Ryan to join so that he could answer the couple of questions regarding the origin of the mod_fcgid code and his licensing intentions which have come up so far, and also to thank him publicly for being willing to consider contributing mod_fcgid to the ASF. Ryan, the main question which has come up in the last couple of days seems to be this one: When you wrote mod_fcgid, was there any code which you borrowed from mod_fastcgi? The other questions I had related to the existing license for mod_fcgid: Your current intention is for mod_fcgid to be available under the GPL version 2.0, correct? Could you confirm that you wanted the GPL to apply to all the mod_fcgid code? (I ask because the LICENSE file in mod_fcgid contains the GPL 2.0, however, the .c and .h files don't also include the usual GPL text.) Finally, Ryan, would you mind re-stating for the record your interest in the idea of mod_fcgid becoming an Apache project? I'd like to personally extend my thanks to Ryan for developing mod_fcgid in the first place, for his interest in the idea of contributing it to the ASF, and for being willing to work through the licensing issues that will involve. Many thanks! (I'd also like to thank my colleague Sharon or Xiaomei Ma (笑梅), an excellent developer in her own right, for her help translating some of the communications Ryan and I have already had.) Chris. -- GPG Key ID: 366A375B GPG Key Fingerprint: 485E 5041 17E1 E2BB C263 E4DE C8E3 FA36 366A 375B
Re: mod_fcgid license questions
Hi, guys Nice to meet you :) I hope I can help to clarify the questions. When you wrote mod_fcgid, was there any code which you borrowed from mod_fastcgi? No. I didn't borrow any code from mod_fastcgi. Your current intention is for mod_fcgid to be available under the GPL version 2.0, correct? Could you confirm that you wanted the GPL to apply to all the mod_fcgid code? Yes, I confirm I wanted the GPL version 2.0 apply to everything. Finally, Ryan, would you mind re-stating for the record your interest in the idea of mod_fcgid becoming an Apache project? Actually I didn't care too much about which license I should choose. The reason I chose GPL is that all other license descriptions are in English and are tricky. I didn't want to spend much time on studying those terms so I just followed most of people to choose GPL. I intended to put it as open source so people can share. I don't really care which license it is under. (Thanks Miss Xiaomei for this native translation) I was single when I developed this project, but now I have to spend more time with my family, and I am now actually interesting on LinuxTV things(So I can spend time on something both I and my wife need :). But I would like to see someone else take over my mod_fcgid project and continune to make it better. I get a lot from the others(that why I like open source and share), and I would like to share to the other if I have a chance. It's my pleasure if ASF willing to take it over. Anything I can help please let me know :) Thanks - Original Message - From: Chris Darroch chr...@pearsoncmg.com To: dev@httpd.apache.org Sent: Friday, December 12, 2008 6:15 AM Subject: mod_fcgid license questions Hi -- I believe Pan Qingfeng (潘庆峰), the developer of mod_fcgid, has joined this list for the time being while the possibility of mod_fcgid becoming project in the Apache incubator is discussed. I'll use his English name of Ryan Pan from here on. I asked Ryan to join so that he could answer the couple of questions regarding the origin of the mod_fcgid code and his licensing intentions which have come up so far, and also to thank him publicly for being willing to consider contributing mod_fcgid to the ASF. Ryan, the main question which has come up in the last couple of days seems to be this one: When you wrote mod_fcgid, was there any code which you borrowed from mod_fastcgi? The other questions I had related to the existing license for mod_fcgid: Your current intention is for mod_fcgid to be available under the GPL version 2.0, correct? Could you confirm that you wanted the GPL to apply to all the mod_fcgid code? (I ask because the LICENSE file in mod_fcgid contains the GPL 2.0, however, the .c and .h files don't also include the usual GPL text.) Finally, Ryan, would you mind re-stating for the record your interest in the idea of mod_fcgid becoming an Apache project? I'd like to personally extend my thanks to Ryan for developing mod_fcgid in the first place, for his interest in the idea of contributing it to the ASF, and for being willing to work through the licensing issues that will involve. Many thanks! (I'd also like to thank my colleague Sharon or Xiaomei Ma (笑梅), an excellent developer in her own right, for her help translating some of the communications Ryan and I have already had.) Chris. -- GPG Key ID: 366A375B GPG Key Fingerprint: 485E 5041 17E1 E2BB C263 E4DE C8E3 FA36 366A 375B
Re: mod_fcgid incubation?
On Dec 9, 2008, at 4:56 PM, Nick Kew wrote: It's unfortunate there's no clear copyright statement, but would it not be reasonable to assume Copyright Pan Qingfeng and deal with him? Contact other contributors as a courtesy, but not let it worry us if some of them prove uncontactable, only if someone actually objects? Submitting a patch or code does not imply copyright assignment. So we cannot assume copyright Pan for the whole thing.
Re: mod_fcgid incubation?
On Dec 10, 2008, at 4:51 AM, Jim Jagielski wrote: On Dec 9, 2008, at 4:56 PM, Nick Kew wrote: It's unfortunate there's no clear copyright statement, but would it not be reasonable to assume Copyright Pan Qingfeng and deal with him? Contact other contributors as a courtesy, but not let it worry us if some of them prove uncontactable, only if someone actually objects? Submitting a patch or code does not imply copyright assignment. So we cannot assume copyright Pan for the whole thing. Right, but not all code has a separate copyright. Repairs, for example, do not. So it is actually feasible that Pan can determine who needs to be contacted based on the change log and only contact those whose contributions were more than repairs to Pan's work. Roy
mod_fcgid incubation?
Hi -- As Paul Querna noted recently, some folks are using mod_fcgid these days instead of mod_fastcgi, in part because it was (I believe) the first of the two to work with httpd 2.2. Unfortunately, the original developer of mod_fcgid, Pan Qingfeng, has largely moved on to other things. He and I have been in touch lately about long-term maintenance of mod_fcgid. (We've helped by a colleague of mine who can translate fluently between Chinese and English, although Pan Qingfeng's English is quite good as well.) In a pinch, I've offered to help get releases out and review some of the queued-up patches contributed by various folks. I also asked, though, whether he'd be interested in contributing mod_fcgid to the ASF as, perhaps, a sub-project of httpd, and received a very positive reply: 很高兴认识你们。我开发这个模块的目的也是想尽可能多的人可以用上它，所以 把它交给ASF完全没有问题（实际上我也很希望可以交给ASF)，过程中有任何问题我都 可以帮忙的。 which my colleague translates as follows: I am very glad to know you guys. I did this module and hoped more people could use it. There is no problem at all for me to donating the module to ASF (actually, I am glad to do so). If there is anything I can do to help, please feel free to let me know. So, I said I'd raise the question on the httpd dev list. Since I'm a neophyte to such things, and also not a lawyer, I assume this would need to be voted on somehow, and then (if accepted) moved into the incubation stage until legal issues were resolved. One key question I have (jumping ahead a little) is whether everyone who has contributed a patch to the project needs to contacted and a signed contributor agreement recovered from them. If not, then I would think that we'd just need a CLA from Pan Qingfeng to proceed (and perhaps, in that case, we could skip the incubator stage, as Apache ZooKeeper recently did). If we do need CLAs from all patch contributors, that might take more time. Fortunately, there's a good change log for the project with names and email addresses; it includes some of the usual suspects (like Paul Querna and myself) but also a number of other folks we'd need to track down. I know there's mod_proxy_fcgi in httpd already, but among other things, it only handles the FCGI_RESPONDER role. It might be very nice to be able to provide the FCGI_AUTHORIZER functionality as well either via a separate module based on mod_fcgid, or through code merged into mod_proxy_fcgi from that project. (The FCGI_FITLER role seems to be unsupported in both mod_fcgid and mod_fastcgi; looks like that's a job for the future, one way or another.) At any rate, if people wouldn't mind chewing this over for a bit, I'd really appreciate it. The project is available from SourceForge under the GPL version 2.0. (Unfortunately, the actual code files are largely missing the legal headers, but the intent is clear; I'm sure this is an oversight due to [human] language barriers.) See the following for info, code, and my own pending patches: http://fastcgi.coremail.cn/ http://sourceforge.net/projects/mod-fcgid http://people.apache.org/~chrisd/patches/mod_fcgid/ Thanks very much in advance for any advice people can offer, Chris. -- GPG Key ID: 366A375B GPG Key Fingerprint: 485E 5041 17E1 E2BB C263 E4DE C8E3 FA36 366A 375B
Re: mod_fcgid incubation?
On Dec 9, 2008, at 1:30 PM, Chris Darroch wrote: One key question I have (jumping ahead a little) is whether everyone who has contributed a patch to the project needs to contacted and a signed contributor agreement recovered from them. If not, then I would think that we'd just need a CLA from Pan Qingfeng to proceed (and perhaps, in that case, we could skip the incubator stage, as Apache ZooKeeper recently did). If we do need CLAs from all patch contributors, that might take more time. Fortunately, there's a good change log for the project with names and email addresses; it includes some of the usual suspects (like Paul Querna and myself) but also a number of other folks we'd need to track down. Since the orig code is GPL, then when people submitted the patches, the expectation is that they would also be GPL. As such, for us to be able to fold in the code, we would need iCLAs from everyone who submitted a patch allowing us to relicense their bits as AL instead of GPL... similar to what we needed to do when SpamAssassin come on board.
Re: mod_fcgid incubation?
Jim Jagielski wrote: On Dec 9, 2008, at 1:30 PM, Chris Darroch wrote: One key question I have (jumping ahead a little) is whether everyone who has contributed a patch to the project needs to contacted and a signed contributor agreement recovered from them. If not, then I would think that we'd just need a CLA from Pan Qingfeng to proceed (and perhaps, in that case, we could skip the incubator stage, as Apache ZooKeeper recently did). If we do need CLAs from all patch contributors, that might take more time. Fortunately, there's a good change log for the project with names and email addresses; it includes some of the usual suspects (like Paul Querna and myself) but also a number of other folks we'd need to track down. Since the orig code is GPL, then when people submitted the patches, the expectation is that they would also be GPL. As such, for us to be able to fold in the code, we would need iCLAs from everyone who submitted a patch allowing us to relicense their bits as AL instead of GPL... similar to what we needed to do when SpamAssassin come on board. Is it? If the *original* code dates to Open Market's implementation, we need to use some caution. The original license was very restrictive. The current mod_fastcgi license is much less restrictive; Open Market permits you to use, copy, modify, distribute, and license this Software and the Documentation for any purpose, provided that existing copyright notices are retained in all copies and that this notice is included verbatim in any distributions. No written agreement, license, or royalty fee is required for any of the authorized uses. Modifications to this Software and Documentation may be copyrighted by their authors and need not follow the licensing terms described here. If modifications to this Software and Documentation have new licensing terms, the new terms must be clearly indicated on the first page of each file where they apply. http://www.fastcgi.com/drupal/node/6?q=node/14 At one point, authorized uses was much narrower, meaning that if the code was in svn, and re-purposed elsewhere, it was not licensed. If this is based on the original mod_fastcgi license, perhaps incorporating the modern, appropriately licensed flavor and then layering the mod_fcgid improvements on top of that would make the most sense?
Re: mod_fcgid incubation?
William A. Rowe, Jr. wrote: If the *original* code dates to Open Market's implementation, we need to use some caution. The original license was very restrictive. The current mod_fastcgi license is much less restrictive; Open Market permits you to use, copy, modify, distribute, and license this Software and the Documentation for any purpose, provided that existing copyright notices are retained in all copies and that this notice is included verbatim in any distributions. No written agreement, license, or royalty fee is required for any of the authorized uses. Modifications to this Software and Documentation may be copyrighted by their authors and need not follow the licensing terms described here. If modifications to this Software and Documentation have new licensing terms, the new terms must be clearly indicated on the first page of each file where they apply. http://www.fastcgi.com/drupal/node/6?q=node/14 At one point, authorized uses was much narrower, meaning that if the code was in svn, and re-purposed elsewhere, it was not licensed. If this is based on the original mod_fastcgi license, perhaps incorporating the modern, appropriately licensed flavor and then layering the mod_fcgid improvements on top of that would make the most sense? Ok, this does get worse; the license cited above applies to to the fcgi package itself. The mod_fastcgi implementation has the following terms; Open Market permits you to use, copy, modify, distribute, and license this Software and the Documentation solely for the purpose of implementing the FastCGI specification defined by Open Market or derivative specifications publicly endorsed by Open Market and promulgated by an open standards organization and for no other purpose, provided that existing copyright notices are retained in all copies and that this notice is included verbatim in any distributions. No written agreement, license, or royalty fee is required for any of the authorized uses. Modifications to this Software and Documentation may be copyrighted by their authors and need not follow the licensing terms described here, but the modified Software and Documentation must be used for the sole purpose of implementing the FastCGI specification defined by Open Market or derivative specifications publicly endorsed by Open Market and promulgated by an open standards organization and for no other purpose. If modifications to this Software and Documentation have new licensing terms, the new terms must protect Open Market's proprietary rights in the Software and Documentation to the same extent as these licensing terms and must be clearly indicated on the first page of each file where they apply. I'd call that a category X license, submission denied.
Re: mod_fcgid incubation?
William A. Rowe, Jr. wrote: Jim Jagielski wrote: On Dec 9, 2008, at 1:30 PM, Chris Darroch wrote: One key question I have (jumping ahead a little) is whether everyone who has contributed a patch to the project needs to contacted and a signed contributor agreement recovered from them. If not, then I would think that we'd just need a CLA from Pan Qingfeng to proceed (and perhaps, in that case, we could skip the incubator stage, as Apache ZooKeeper recently did). If we do need CLAs from all patch contributors, that might take more time. Fortunately, there's a good change log for the project with names and email addresses; it includes some of the usual suspects (like Paul Querna and myself) but also a number of other folks we'd need to track down. Since the orig code is GPL, then when people submitted the patches, the expectation is that they would also be GPL. As such, for us to be able to fold in the code, we would need iCLAs from everyone who submitted a patch allowing us to relicense their bits as AL instead of GPL... similar to what we needed to do when SpamAssassin come on board. Is it? It is. AFAIK, mod_fcgid is a clean room implementation of the FastCGI protocol, just like our mod_proxy_fcgi. If you have looked at both mod_fastcgi and mod_fcgid, you will quickly see there is no resemblance. mod_fcgid uses lots of 2.x concepts, like custom buckets types and brigades all over, while mod_fastcgi is a horrible horrible piece of code written for 1.x, and later ported to 2.x. -Paul
Re: mod_fcgid incubation?
Hi, Chris Darroch wrote: Hi -- As Paul Querna noted recently, some folks are using mod_fcgid these days instead of mod_fastcgi, in part because it was (I believe) the first of the two to work with httpd 2.2. Unfortunately, the original developer of mod_fcgid, Pan Qingfeng, has largely moved on to other things. He and I have been in touch lately about long-term maintenance of mod_fcgid. (We've helped by a colleague of mine who can translate fluently between Chinese and English, although Pan Qingfeng's English is quite good as well.) In a pinch, I've offered to help get releases out and review some of the queued-up patches contributed by various folks. I don't know much about the legal issues, but I think it's a good time to decide about that. FastCGI is very popular and should be available by the apache-distribution. mod_fcgid did a nice start with their process-control (in shared hosting environments), but it's lacking good documentation and active maintenance. When I read the question about the current development state of mod_fcgid, I thought about to spent some time on it to (try to) improve things, but I wouldn't be worth if Apache httpd would come up with native FastCGI support in 2.4.x. 0.02$, .max
Re: mod_fcgid incubation?
William A. Rowe, Jr. wrote: The mod_fastcgi implementation has the following terms; Open Market permits you to use, copy, modify, distribute, and license this Software and the Documentation solely for the purpose of implementing the FastCGI specification defined by Open Market or derivative specifications publicly endorsed by Open Market and promulgated by an open standards organization and for no other purpose, provided that existing copyright notices are retained in all copies and that this notice is included verbatim in any distributions. No written agreement, license, or royalty fee is required for any of the authorized uses. Modifications to this Software and Documentation may be copyrighted by their authors and need not follow the licensing terms described here, but the modified Software and Documentation must be used for the sole purpose of implementing the FastCGI specification defined by Open Market or derivative specifications publicly endorsed by Open Market and promulgated by an open standards organization and for no other purpose. If modifications to this Software and Documentation have new licensing terms, the new terms must protect Open Market's proprietary rights in the Software and Documentation to the same extent as these licensing terms and must be clearly indicated on the first page of each file where they apply. I'd call that a category X license, submission denied. So far as I know -- I'll check with the author -- mod_fcgid is a completely separate implementation from mod_fastcgi. I don't know of any generally shared or derived code, but I will check. The exception, I think, might be the FCGI protocol itself, which specifies the byte-level structure of the headers that are passed back and forth during communication with FCGI application processes. This definition lives in fcgi_protocol.h in both mod_fastcgi, and appears in very similar forms in both mod_fcgid's fcgi_protocol.h and also httpd's modules/proxy/fcgi_protocol.h. Look for the fcgi_header or FCGI_Header structure, and the various FCGI_* #defines for type values, roles, etc. It's a little hard for me to see how alternate implementations of the FastCGI spec could get away without doing something like this at a minimum, though. Chris. -- GPG Key ID: 366A375B GPG Key Fingerprint: 485E 5041 17E1 E2BB C263 E4DE C8E3 FA36 366A 375B
Re: mod_fcgid incubation?
Chris Darroch wrote: William A. Rowe, Jr. wrote: The mod_fastcgi implementation has the following terms; Open Market permits you to use, copy, modify, distribute, and license this Software and the Documentation solely for the purpose of implementing the FastCGI specification defined by Open Market or derivative specifications publicly endorsed by Open Market and promulgated by an open standards organization and for no other purpose, provided that existing copyright notices are retained in all copies and that this notice is included verbatim in any distributions. No written agreement, license, or royalty fee is required for any of the authorized uses. Modifications to this Software and Documentation may be copyrighted by their authors and need not follow the licensing terms described here, but the modified Software and Documentation must be used for the sole purpose of implementing the FastCGI specification defined by Open Market or derivative specifications publicly endorsed by Open Market and promulgated by an open standards organization and for no other purpose. If modifications to this Software and Documentation have new licensing terms, the new terms must protect Open Market's proprietary rights in the Software and Documentation to the same extent as these licensing terms and must be clearly indicated on the first page of each file where they apply. I'd call that a category X license, submission denied. So far as I know -- I'll check with the author -- mod_fcgid is a completely separate implementation from mod_fastcgi. I don't know of any generally shared or derived code, but I will check. The exception, I think, might be the FCGI protocol itself, which specifies the byte-level structure of the headers that are passed back and forth during communication with FCGI application processes. This definition lives in fcgi_protocol.h in both mod_fastcgi, and appears in very similar forms in both mod_fcgid's fcgi_protocol.h and also httpd's modules/proxy/fcgi_protocol.h. Look for the fcgi_header or FCGI_Header structure, and the various FCGI_* #defines for type values, roles, etc. It's a little hard for me to see how alternate implementations of the FastCGI spec could get away without doing something like this at a minimum, though. Whatever can be found in fcgi-2.4.0 can be appropriately licensed by the ASF and sublicensed to end users, complying with their license terms as a NOTICE. Whatever is only found in mod_fastcgi-2.4.6 is verboten. Bill
Re: mod_fcgid incubation?
On Tue, 09 Dec 2008 10:30:54 -0800 Chris Darroch [EMAIL PROTECTED] wrote: He and I have been in touch lately about long-term maintenance of mod_fcgid. (We've helped by a colleague of mine who can translate fluently between Chinese and English, although Pan Qingfeng's English is quite good as well.) In a pinch, I've offered to help get releases out and review some of the queued-up patches contributed by various folks. If IP issues can be dealt with, then I'd say a definite +1. FastCGI is one of our most popular third-party extensions, and mod_fcgid appears to be the best available implementation. Does anyone have a complete list of people who have made nontrivial contributions, such that their IP might be affected? One key question I have (jumping ahead a little) is whether everyone who has contributed a patch to the project needs to contacted and a signed contributor agreement recovered from them. If not, then I would think that we'd just need a CLA from Pan Qingfeng to proceed (and perhaps, in that case, we could skip the incubator stage, as Apache ZooKeeper recently did). Possibly a software grant rather than a CLA, if he's basically handing it to us. But yes, we'd need to act together. If we do need CLAs from all patch contributors, that might take more time. Fortunately, there's a good change log for the project with names and email addresses; it includes some of the usual suspects (like Paul Querna and myself) but also a number of other folks we'd need to track down. It's unfortunate there's no clear copyright statement, but would it not be reasonable to assume Copyright Pan Qingfeng and deal with him? Contact other contributors as a courtesy, but not let it worry us if some of them prove uncontactable, only if someone actually objects? -- Nick Kew Application Development with Apache - the Apache Modules Book http://www.apachetutor.org/
Re: mod_fcgid incubation?
On Tue, 9 Dec 2008 21:56:43 + Nick Kew [EMAIL PROTECTED] wrote: Does anyone have a complete list of people who have made nontrivial contributions, such that their IP might be affected? Ignore that - I meant to chop those lines when I read (as opposed to skimmed) the following paragraphs. Bah. -- Nick Kew Application Development with Apache - the Apache Modules Book http://www.apachetutor.org/
