Re: [VOTE] release httpd mod_fcgid-2.3.1?
William A. Rowe, Jr. wrote: [ ] +1 to release as 2.3.1-beta With +1's recorded from chrisd, trawick and wrowe, the package is released as-beta (due principally to the more experimental auth issues and terse documentation). I've staged the release, and in response to the details from Rainer, I regenerated the .md5/.sha1 tags in the process, using appropriate tools. The embedded filenames now reflect -beta tags. At 2pm EDT we can go ahead and sync the entire site, but I won't be at the office for an hour or so after that, so if anyone beats me to it, terrific :) I've synced the module doc area for mod_fcgid and the configuration is also updated to bridge all our links across into the httpd trunk docs. Feel free to test this out before the entire site is synced; http://httpd.apache.org/mod_fcgid/ you may be waiting for up to 45 minutes after this message for minotaur to sync to the live server.
Re: [VOTE] release httpd mod_fcgid-2.3.1?
Rainer Jung wrote: Some people seem to indicate, that the implementation of pgp is safer, on the other hand md5sum etc. have a builtin check option (-c), so you can run them directly against the checksum file to compares the checksum in the checksum file with a freshly computed checksum of the base file. This seems handy to me. It looks like gpg is not able to do that, i.e. you have to compare the sums by staring at them. Of course with gpg you can check using the signature file. That is frustrating. I wish we didn't illustrate it in our release.sh scripts :( But a SHA1 or MD5 or whatever result is a specific value, the Safety argument is complete drivel (and I didn't complete it, either). I regenerated all the mod_fcgid .md5/sha1 artifacts and then verified they had not changed. This was necessary anyways due to the -beta rename, and I'll be doing the same for mod_ftp if we get that far.
Re: DAV Option Patch
On Tue, 2009-09-15 at 11:25 +0200, ext Graham Leggett wrote: Brian J. France wrote: Jari is the original author of mod_dav_acl, which requires patches to httpd to work. I need the same functionality added to httpd to get a mod_dav_acl type module working, so I have split up his patch into smaller pieces. Can a patch be under a different license than the original code? Yes it can, but only the author of the original code can do that, as only the original author (the copyright holder) can set the terms by which his patch can be used. The way forward is to ask Jari to submit his httpd-2.2.8-ju.patch to us, granting us permission to use the Apache software license on it. I'll assume that you don't need here the content which is included within mod_dav_acl package at sf.net ? Otherwise you are certainly free to use it anyways you like. Patch contains mostly some hooks to mod_dav, but since i'm not that familiar with apr apache code, you can certainly improve things. For dav_acl, caldav and carddav modules (the latter of which i just recently submitted), only similar kind of things are needed, so you can change the api freely as long as the functionality remains. I do have some cycles to update my modules accordingly. What comes to having included these with httpd, I'm in the process of asking permission from my company the change the license to APL Thanks, Jari
Re: DAV Option Patch
On Tue, 2009-09-15 at 18:42 +0200, ext Julian Reschke wrote: Brian J. France wrote: ... There is one draw back to this patch in that there could be duplicated values in the headers. Both mod_dav_acl and mod_caldav want to add the REPORT in the Allow header, so it would show up twice in the list. I am not sure if this is a major problem, but wanted to make a note of it. ... It shouldn't be a problem, but on the other hand: is there any particular reason for the new code not to enforce each value is only reported once? BR, Julian Nothing at all, since it is trivial to fix it so (originally i didn't bother to do that since I knew clients don't mind...) br, Jari
Re: DAV Option Patch
Jari Urpalainen wrote: What comes to having included these with httpd, I'm in the process of asking permission from my company the change the license to APL APL? We presume you mean AL (or ApL) ;-)
Re: OCSP stapling in mod_ssl - use as OCSP cache for client authentication
Dr Stephen Henson wrote: First comment to list in general: any comments on what needs to be done to get the OCSP stapling patch accepted? I had been under the impression, from reading the bug commentary too many times, that it was not vetting the CA chain from root to cert. It seems I misunderstood and this patch is ready for backport. Please correct us if there are any other changes required to bless this code as 'production ready'/General Availability. Bill
Re: [VOTE] release httpd mod_ftp-0.9.5 beta?
Guenter Knauf wrote: Bill, Mario just told me that there's no mod_ftp Win32 binary yet: http://httpd.apache.org/dev/dist/mod_ftp/ maybe you can one upload? I generally roll binaries closer to the release date, and right now, we are evaluating one particular set of compile warnings. As soon as we know .9.5 will go live, I'll get binaries together for this release. Sorry we hadn't released any for .9.2.
Re: svn commit: r815611 - in /httpd/site/trunk/docs/mod_fcgid: index.en.html index.html
On 16 Sep 2009, at 06:38, wr...@apache.org wrote: Author: wrowe Date: Wed Sep 16 05:38:09 2009 New Revision: 815611 URL: http://svn.apache.org/viewvc?rev=815611view=rev Log: Generated new content Ouch! What is generating new content in transitional HTML, incorporating a bunch of crap that was deprecated as long ago as 1997? I know we have some legacy stuff, but our /docs/2.0/ and up have been an example of consistently Good Practice. It would be better to avoid a backwards step in importing new modules. -- Nick Kew
Lots of GET requests is sent when getting properties of a large file
Hi, I use mod_dav of Apache to build a WebDAV server, and use MapNetworkDrive of WindowsXP to build a connection to the WebDAV server. There is a large file (about 100MB) on the WebDAV server. When I try to get the properties (right click the large file) of the large file or delete the large file, I find that it will take a long time to finish the operation. After tracking the communication, I find that the client sends lots of GET requests to the server. If the target file is small, this will not happen. Does anybody know what is wrong and how to solve this problem? Thank you very much. // Zeyi
Re: DAV Option Patch
On Wed, Sep 16, 2009 at 10:09:23AM +0300, Jari Urpalainen wrote: I'll assume that you don't need here the content which is included within mod_dav_acl package at sf.net ? Otherwise you are certainly free to use it anyways you like. Patch contains mostly some hooks to mod_dav, but since i'm not that familiar with apr apache code, you can certainly improve things. For dav_acl, caldav and carddav modules (the latter of which i just recently submitted), only similar kind of things are needed, so you can change the api freely as long as the functionality remains. I do have some cycles to update my modules accordingly. What comes to having included these with httpd, I'm in the process of asking permission from my company the change the license to APL If you can submit the patches to the ASF under the Apache Software License, it is sufficient for you to send them to this mailing list - that counts as a contribution to the ASF. If you can do that, we can then include the patches in the tree, but if your employer owns the copyright to the patches, then be sure you are authorized to submit the code under that license first. Regards, Joe
Re: DAV Option Patch
On Wed, 2009-09-16 at 11:39 +0200, ext Joe Orton wrote:
On Wed, Sep 16, 2009 at 10:09:23AM +0300, Jari Urpalainen wrote:
I'll assume that you don't need here the content which is included
within mod_dav_acl package at sf.net ? Otherwise you are certainly free
to use it anyways you like. Patch contains mostly some hooks to
mod_dav, but since i'm not that familiar with apr apache code, you can
certainly improve things. For dav_acl, caldav and carddav modules (the
latter of which i just recently submitted), only similar kind of things
are needed, so you can change the api freely as long as the
functionality remains. I do have some cycles to update my modules
accordingly. What comes to having included these with httpd, I'm in the
process of asking permission from my company the change the license to
APL
If you can submit the patches to the ASF under the Apache Software
License, it is sufficient for you to send them to this mailing list -
that counts as a contribution to the ASF.
If you can do that, we can then include the patches in the tree, but if
your employer owns the copyright to the patches, then be sure you are
authorized to submit the code under that license first.
Regards, Joe
Ok, here's the patch (which I'm authorized to submit). And yes you can
apply the Apache License, Version 2.0 or what is the official name.
thanks Jari
diff -Naur httpd-2.2.8/modules/dav/fs/repos.c httpd-2.2.8-ju/modules/dav/fs/repos.c
--- httpd-2.2.8/modules/dav/fs/repos.c 2008-06-04 10:53:04.0 +0300
+++ httpd-2.2.8-ju/modules/dav/fs/repos.c 2008-07-02 10:17:47.0 +0300
@@ -46,6 +46,7 @@
apr_pool_t *pool;/* memory storage pool associated with request */
const char *pathname; /* full pathname to resource */
apr_finfo_t finfo; /* filesystem info */
+request_rec *r;
};
/* private context for doing a filesystem walk */
@@ -200,6 +201,11 @@
**
** PRIVATE REPOSITORY FUNCTIONS
*/
+request_rec *dav_fs_get_request_rec(const dav_resource *resource)
+{
+return resource-info-r;
+}
+
apr_pool_t *dav_fs_pool(const dav_resource *resource)
{
return resource-info-pool;
@@ -638,6 +644,7 @@
/* Create private resource context descriptor */
ctx = apr_pcalloc(r-pool, sizeof(*ctx));
ctx-finfo = r-finfo;
+ctx-r = r;
/* ### this should go away */
ctx-pool = r-pool;
@@ -1775,17 +1782,13 @@
if (!resource-exists)
return apr_pstrdup(ctx-pool, );
+{
+ request_rec *r = ctx-r;
-if (ctx-finfo.filetype != 0) {
-return apr_psprintf(ctx-pool, \% APR_UINT64_T_HEX_FMT -%
-APR_UINT64_T_HEX_FMT -% APR_UINT64_T_HEX_FMT \,
-(apr_uint64_t) ctx-finfo.inode,
-(apr_uint64_t) ctx-finfo.size,
-(apr_uint64_t) ctx-finfo.mtime);
-}
-
-return apr_psprintf(ctx-pool, \% APR_UINT64_T_HEX_FMT \,
- (apr_uint64_t) ctx-finfo.mtime);
+ r-mtime = ctx-finfo.mtime;
+r-finfo = ctx-finfo;
+ return ap_make_etag(r, 0);
+}
}
static const dav_hooks_repository dav_hooks_repository_fs =
@@ -1812,6 +1815,9 @@
dav_fs_remove_resource,
dav_fs_walk,
dav_fs_getetag,
+dav_fs_get_request_rec,
+dav_fs_pathname,
+NULL
};
static dav_prop_insert dav_fs_insert_prop(const dav_resource *resource,
diff -Naur httpd-2.2.8/modules/dav/main/mod_dav.c httpd-2.2.8-ju/modules/dav/main/mod_dav.c
--- httpd-2.2.8/modules/dav/main/mod_dav.c 2008-06-04 10:53:04.0 +0300
+++ httpd-2.2.8-ju/modules/dav/main/mod_dav.c 2008-07-02 10:24:09.0 +0300
@@ -57,6 +57,8 @@
#include http_request.h
#include util_script.h
+#include ap_provider.h
+
#include mod_dav.h
@@ -79,6 +81,8 @@
const char *dir;
int locktimeout;
int allow_depthinfinity;
+int acl_checking;
+int etag_response;
} dav_dir_conf;
@@ -195,10 +199,18 @@
newconf-dir = DAV_INHERIT_VALUE(parent, child, dir);
newconf-allow_depthinfinity = DAV_INHERIT_VALUE(parent, child,
allow_depthinfinity);
+newconf-acl_checking = DAV_INHERIT_VALUE(parent, child, acl_checking);
+newconf-etag_response = DAV_INHERIT_VALUE(parent, child, etag_response);
return newconf;
}
+DAV_DECLARE(const char *) dav_get_provider_name(request_rec *r)
+{
+dav_dir_conf *conf = ap_get_module_config(r-per_dir_config, dav_module);
+return conf ? conf-provider_name : NULL;
+}
+
static const dav_provider *dav_get_provider(request_rec *r)
{
dav_dir_conf *conf;
@@ -287,6 +299,30 @@
}
/*
+ * Command handler for the DAVACL directive, which is FLAG.
+ */
+static const char *dav_cmd_acl_checking(cmd_parms *cmd, void *config,
+ int arg)
+{
+dav_dir_conf *conf = (dav_dir_conf *)config;
+
+conf-acl_checking = arg;
+return NULL;
+}
+
+/*
+ * Command
Re: DAV Option Patch
Jari Urpalainen wrote: Ok, here's the patch (which I'm authorized to submit). And yes you can apply the Apache License, Version 2.0 or what is the official name. Excellent, thank you for the running round - this clears Brian to keep submitting patches based on this one. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: Data are send in reverse order
In my module I do not modify any data sended from server to client.
Unfortunatelly when I am using ap_r* then firstly are sended data and then
HTTP relevant code.
Sample code is:
/*
* Procedure for sending data from server to client side
* Instead of ap_rvputs like functions should be used following procedure
* especially for SecMCJ issue
*/
apr_status_t send_data_to_client(request_rec *r, char * data_to_send, int
length_data)
{
//apr_status_t rv;
apr_bucket_brigade * bb =
apr_brigade_create(r-pool,r-connection-bucket_alloc);
apr_bucket * b =
apr_bucket_immortal_create(data_to_send,length_data,r-connection-bucket_alloc);
APR_BRIGADE_INSERT_TAIL(bb,b);
ap_pass_brigade(r-connection-output_filters,bb);
//apr_bucket_destroy(b);
//apr_brigade_destroy(bb);
return OK;
}
/*
* Location /USSW/secmcj
* SetHandler ussw-secmcj
* allow from all
* Satisfy any
* /Location
*/
int udsc_secmcj_handler(request_rec *r)
{
secmcj_body = apr_pstrcat(r-pool,
sessionID=,
apr_psprintf(r-pool, %lu, pSession-us.udsc_sessionid),
requestNr=, pSession-session_id,
*request_body == '' ? : ,
request_body,
NULL);
/* now post the data to usmw /secmcj */
ap_log_error(APLOG_MARK, APLOG_NOERRNO | APLOG_DEBUG, 0, r-server,
secmcj body: %s,secmcj_body);
/* now return the response to the client (secmcj class) */
ap_log_error(APLOG_MARK, APLOG_NOERRNO | APLOG_DEBUG, 0, r-server,
secmcj body receive: %s,response_body);
r-content_type = text/plain;
/* added because of JRE 1.4 SE SSL problem */
bodylen = strlen(response_body);
ap_set_content_length(r, bodylen);
ap_send_http_header(r);
if (r-header_only)
{
ap_log_error(APLOG_MARK,APLOG_NOERRNO | APLOG_DEBUG, 0, r-server,
HEADER ONLY);
return OK;
}
ap_log_error(APLOG_MARK, APLOG_NOERRNO | APLOG_DEBUG, 0, r-server,
before any sending. Length is:%d,bodylen);
send_data_to_client(r,response_body, bodylen);
return OK;
}
best regards
Petr
Nick Kew napsal(a):
Petr Hracek wrote:
I have found mod_nntp_like where is mention in
ap_pass_brigade(c-output_filters,bb);
and in smtp_core is usage the same.
Those are protocol modules. So anything-HTTP is not relevant to them.
Unfortunatelly when I am using ap_pass_brigade(r-output_filter,bb);
then it is not working. Web page is not show.
Do you need to use anything more complex than the ap_r* family
(ap_rputs, etc)? If so (and if what Graham already told you isn't
enough) you might want my book - details at http://www.apachetutor.org/
Re: Data are send in reverse order
Petr Hracek wrote: In my module I do not modify any data sended from server to client. Unfortunatelly when I am using ap_r* then firstly are sended data and then HTTP relevant code. That's because you've made the same mistake in this code that you made in the previous code you posted: ap_pass_brigade(r-connection-output_filters,bb); ^ Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: OCSP stapling in mod_ssl - use as OCSP cache for client authentication
William A. Rowe, Jr. wrote: Dr Stephen Henson wrote: First comment to list in general: any comments on what needs to be done to get the OCSP stapling patch accepted? I had been under the impression, from reading the bug commentary too many times, that it was not vetting the CA chain from root to cert. It seems I misunderstood and this patch is ready for backport. Please correct us if there are any other changes required to bless this code as 'production ready'/General Availability. I may have missed something here but the OCSP stapling code doesn't appear to be in trunk. The patch in: https://issues.apache.org/bugzilla/show_bug.cgi?id=43822 doesn't apply cleanly any more, though the changes needed to get it working are fairly trivial. I'm in the process of including an updated patch. Nitpick: along the way I noticed the ocsp code in ssl_util_ocsp.c was updated to support a configurable timeout (which was in the original stapling patch) but the comment: /* Inherit the default I/O timeout. */ has been retained which isn't true any more. Steve. -- Dr Stephen N. Henson. Senior Technical/Cryptography Advisor, Open Source Software Institute: www.oss-institute.org OpenSSL Core team: www.openssl.org
Re: OCSP stapling in mod_ssl - use as OCSP cache for client authentication
On Wed, Sep 16, 2009 at 01:38:50PM +0100, Dr Stephen Henson wrote: I may have missed something here but the OCSP stapling code doesn't appear to be in trunk. The patch in: https://issues.apache.org/bugzilla/show_bug.cgi?id=43822 doesn't apply cleanly any more, though the changes needed to get it working are fairly trivial. I'm in the process of including an updated patch. I'm working on merging this right now, your patch did apply fine, I've committed the one part separately which you alude to below. Nitpick: along the way I noticed the ocsp code in ssl_util_ocsp.c was updated to support a configurable timeout (which was in the original stapling patch) but the comment: /* Inherit the default I/O timeout. */ Thanks for that, will fix. Joe
Re: Data are send in reverse order
Sorry it was my fault. I have corrected them to r-output_filters now. But situation is the same. Data are send but java aplication which receiving data sended over ap_pass_brigade does not receive anything. It seems that between apache and java aplication are lost is there any posibility how to track if that hasa been really send via ap_pass_brigade? 2009/9/16 Graham Leggett minf...@sharp.fm Petr Hracek wrote: In my module I do not modify any data sended from server to client. Unfortunatelly when I am using ap_r* then firstly are sended data and then HTTP relevant code. That's because you've made the same mistake in this code that you made in the previous code you posted: ap_pass_brigade(r-connection-output_filters,bb); ^ Regards, Graham --
Re: Data are send in reverse order
Petr Hracek wrote: Sorry it was my fault. I have corrected them to r-output_filters now. But situation is the same. Data are send but java aplication which receiving data sended over ap_pass_brigade does not receive anything. It seems that between apache and java aplication are lost is there any posibility how to track if that hasa been really send via ap_pass_brigade? One thing to check, are you sending an EOS bucket (end-of-stream) at the end to tell everybody you're done? I suspect what might be happening is that httpd is waiting for you to say I'm done, but you never send the bucket to say so, so the data buffered in the connection is being discarded when the connection is eventually timed out by the client. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Who can cast binding votes?
While we're discussing voting, I've been looking at http://httpd.apache.org/dev/guidelines.html Under Apache HTTP Server Committers it says these volunteers may cast binding votes on any technical discussion. Under Voting, it says the only binding votes are those cast by active members of the Apache Group, which sounds like PMC members, but that would imply that not all committers can cast binding votes, contradicting what was said earlier. Can someone clarify that for me? Thanks. -- Dan Poirier poir...@pobox.com
Re: Who can cast binding votes?
On 16 Sep 2009, at 15:10, Dan Poirier wrote: While we're discussing voting, I've been looking at http://httpd.apache.org/dev/guidelines.html Under Apache HTTP Server Committers it says these volunteers may cast binding votes on any technical discussion. Under Voting, it says the only binding votes are those cast by active members of the Apache Group, which sounds like PMC members, but that would imply that not all committers can cast binding votes, contradicting what was said earlier. Can someone clarify that for me? Any committer can vote in STATUS, and we treat all votes as equal. I guess that counts as technical issues. Not sure if that's just de- facto, but it's happened for as long as I can remember. Project management matters, such as approving a release or electing a new committer, are for the PMC. Can't help on that frankly-confusing wording you quote. -- Nick Kew
[PATCH/heads up] mod_fcgid: checking for global-only directives in a vhost
This has the potential for breaking existing configs by forcing the admin to
remove some ignored directives they've coded in a vhost.
The affected directives are BusyScanInterval, DefaultMaxClassProcessCount,
DefaultMinProcessCount, ErrorScanInterval, IdleScanInterval, IdleTimeout,
MaxProcessCount, PHP_Fix_Pathinfo_Enable, ProcessLifetime, SharedmemPath,
SocketPath, SpawnScore, SpawnScoreUpLimit, TerminationScore, TimeScore, and
ZombieScanInterval.
I suppose that a couple of these might have seemed to the administrator to
be more flexible than global-only, though it wouldn't have changed the
behavior when they added any of these to a vhost.
Please object now if you want to allow affected existing configurations to
continue to work. We can probably change the hard failure to a warning.
(A case where I might want to issue a warning for an ignored directive is
with IPCConnectTimeout on Unix; it is ignored there, but it has entered the
web wisdom as something that can help certain problems regardless of
platform. But that is independent of this patch.)
Index: fcgid_conf.c
===
--- fcgid_conf.c(revision 815491)
+++ fcgid_conf.c(working copy)
@@ -161,6 +161,12 @@
server_rec *s = cmd-server;
fcgid_server_conf *config =
ap_get_module_config(s-module_config, fcgid_module);
+const char *err = ap_check_cmd_context(cmd, GLOBAL_ONLY);
+
+if (err != NULL) {
+return err;
+}
+
config-idle_timeout = atol(arg);
return NULL;
}
@@ -178,6 +184,12 @@
server_rec *s = cmd-server;
fcgid_server_conf *config =
ap_get_module_config(s-module_config, fcgid_module);
+const char *err = ap_check_cmd_context(cmd, GLOBAL_ONLY);
+
+if (err != NULL) {
+return err;
+}
+
config-idle_scan_interval = atol(arg);
return NULL;
}
@@ -211,6 +223,12 @@
server_rec *s = cmd-server;
fcgid_server_conf *config =
ap_get_module_config(s-module_config, fcgid_module);
+const char *err = ap_check_cmd_context(cmd, GLOBAL_ONLY);
+
+if (err != NULL) {
+return err;
+}
+
config-busy_scan_interval = atol(arg);
return NULL;
}
@@ -229,6 +247,12 @@
server_rec *s = cmd-server;
fcgid_server_conf *config =
ap_get_module_config(s-module_config, fcgid_module);
+const char *err = ap_check_cmd_context(cmd, GLOBAL_ONLY);
+
+if (err != NULL) {
+return err;
+}
+
config-proc_lifetime = atol(arg);
return NULL;
}
@@ -246,6 +270,12 @@
server_rec *s = cmd-server;
fcgid_server_conf *config =
ap_get_module_config(s-module_config, fcgid_module);
+const char *err = ap_check_cmd_context(cmd, GLOBAL_ONLY);
+
+if (err != NULL) {
+return err;
+}
+
config-error_scan_interval = atol(arg);
return NULL;
}
@@ -264,6 +294,12 @@
server_rec *s = cmd-server;
fcgid_server_conf *config =
ap_get_module_config(s-module_config, fcgid_module);
+const char *err = ap_check_cmd_context(cmd, GLOBAL_ONLY);
+
+if (err != NULL) {
+return err;
+}
+
config-zombie_scan_interval = atol(arg);
return NULL;
}
@@ -281,6 +317,12 @@
server_rec *s = cmd-server;
fcgid_server_conf *config =
ap_get_module_config(s-module_config, fcgid_module);
+const char *err = ap_check_cmd_context(cmd, GLOBAL_ONLY);
+
+if (err != NULL) {
+return err;
+}
+
config-sockname_prefix = ap_server_root_relative(cmd-pool, arg);
if (!config-sockname_prefix)
return Invalid socket path;
@@ -300,6 +342,12 @@
server_rec *s = cmd-server;
fcgid_server_conf *config =
ap_get_module_config(s-module_config, fcgid_module);
+const char *err = ap_check_cmd_context(cmd, GLOBAL_ONLY);
+
+if (err != NULL) {
+return err;
+}
+
config-shmname_path = ap_server_root_relative(cmd-pool, arg);
if (!config-shmname_path)
return Invalid shmname path;
@@ -320,6 +368,12 @@
server_rec *s = cmd-server;
fcgid_server_conf *config =
ap_get_module_config(s-module_config, fcgid_module);
+const char *err = ap_check_cmd_context(cmd, GLOBAL_ONLY);
+
+if (err != NULL) {
+return err;
+}
+
config-spawnscore_uplimit = atol(arg);
return NULL;
}
@@ -372,6 +426,12 @@
server_rec *s = cmd-server;
fcgid_server_conf *config =
ap_get_module_config(s-module_config, fcgid_module);
+const char *err = ap_check_cmd_context(cmd, GLOBAL_ONLY);
+
+if (err != NULL) {
+return err;
+}
+
config-spawn_score = atol(arg);
return NULL;
}
@@ -388,6 +448,12 @@
server_rec *s = cmd-server;
fcgid_server_conf *config =
ap_get_module_config(s-module_config, fcgid_module);
+const char *err = ap_check_cmd_context(cmd, GLOBAL_ONLY);
+
+if (err != NULL) {
+return err;
+}
+
config-time_score =
Re: [PATCH/heads up] mod_fcgid: checking for global-only directives in a vhost
Jeff Trawick wrote: Please object now if you want to allow affected existing configurations to continue to work. We can probably change the hard failure to a warning. As this is a beta, let's just break the config, we should put something very clear in README about this.
Re: [PATCH/heads up] mod_fcgid: checking for global-only directives in a vhost
On 16.09.2009 17:18, Jeff Trawick wrote: This has the potential for breaking existing configs by forcing the admin to remove some ignored directives they've coded in a vhost. The affected directives are BusyScanInterval, DefaultMaxClassProcessCount, DefaultMinProcessCount, ErrorScanInterval, IdleScanInterval, IdleTimeout, MaxProcessCount, PHP_Fix_Pathinfo_Enable, ProcessLifetime, SharedmemPath, SocketPath, SpawnScore, SpawnScoreUpLimit, TerminationScore, TimeScore, and ZombieScanInterval. I suppose that a couple of these might have seemed to the administrator to be more flexible than global-only, though it wouldn't have changed the behavior when they added any of these to a vhost. Does it make sense to correctly merge some of them? I didn't check right now. Maybe some things are singletons, like the scanners, but others moght make sense per vhost, like e.g. the IdleTimeout or the scores. Consider e.g. when various vhosts use different wrappers.
Re: svn commit: r815611 - in /httpd/site/trunk/docs/mod_fcgid: index.en.html index.html
Nick Kew wrote: On 16 Sep 2009, at 06:38, wr...@apache.org wrote: Author: wrowe Date: Wed Sep 16 05:38:09 2009 New Revision: 815611 URL: http://svn.apache.org/viewvc?rev=815611view=rev Log: Generated new content Ouch! What is generating new content in transitional HTML, incorporating a bunch of crap that was deprecated as long ago as 1997? I know we have some legacy stuff, but our /docs/2.0/ and up have been an example of consistently Good Practice. It would be better to avoid a backwards step in importing new modules. Fairy nough. I simply borrowed the template from site/docs/mod_ftp/ (likely borrowed from mod_aspdotnet so long ago) so both need attention. Be my guest in updating these :) Bill
mod_ftp - start directory?
Looking over the mod_ftp documentation, I don't see a way to do this, but maybe I'm just missing it. Can I arrange for anyone logging into the mod_ftp server to start out in some subdirectory of the document root? I want a fixed directory, not something that depends on their user name. For extra credit, can I keep them restricted to that directory and subdirectories of it? Concrete example: VirtualHost _default_:21 FTP On DocumentRoot /var/share/ftpdocs /VirtualHost When Alice or Bob log in, I want them to be looking at the files in /var/share/ftpdocs/interesting/directory, and 'pwd' should return '/interesting/directory'. They should be able to access anything under there, but not anything outside that subtree. -- Dan Poirier poir...@pobox.com
Re: [PATCH/heads up] mod_fcgid: checking for global-only directives in a vhost
On Wed, Sep 16, 2009 at 11:42 AM, Rainer Jung rainer.j...@kippdata.dewrote: On 16.09.2009 17:18, Jeff Trawick wrote: This has the potential for breaking existing configs by forcing the admin to remove some ignored directives they've coded in a vhost. The affected directives are BusyScanInterval, DefaultMaxClassProcessCount, DefaultMinProcessCount, ErrorScanInterval, IdleScanInterval, IdleTimeout, MaxProcessCount, PHP_Fix_Pathinfo_Enable, ProcessLifetime, SharedmemPath, SocketPath, SpawnScore, SpawnScoreUpLimit, TerminationScore, TimeScore, and ZombieScanInterval. I suppose that a couple of these might have seemed to the administrator to be more flexible than global-only, though it wouldn't have changed the behavior when they added any of these to a vhost. Does it make sense to correctly merge some of them? I didn't check right now. Maybe some things are singletons, like the scanners, but others moght make sense per vhost, like e.g. the IdleTimeout or the scores. Consider e.g. when various vhosts use different wrappers. In the long term, maybe a few of them should support vhost-specific settings (PHP_Fix_Pathinfo_Enable, IdleTimeout, or ProcessLifetime). We'll see what people ask for (or who jumps in to implement ;) ). At the moment I'm more interested in fixing the settings that pretend to be merged and/or aren't picked up from the proper vhost.
Re: mod_ftp - start directory?
Dan Poirier wrote: Looking over the mod_ftp documentation, I don't see a way to do this, but maybe I'm just missing it. Can I arrange for anyone logging into the mod_ftp server to start out in some subdirectory of the document root? I want a fixed directory, not something that depends on their user name. For extra credit, can I keep them restricted to that directory and subdirectories of it? Concrete example: VirtualHost _default_:21 FTP On DocumentRoot /var/share/ftpdocs /VirtualHost When Alice or Bob log in, I want them to be looking at the files in /var/share/ftpdocs/interesting/directory, and 'pwd' should return '/interesting/directory'. They should be able to access anything under there, but not anything outside that subtree. We should be able to make JailUser behave independently of FTPHomeDir. But that is only half the question. An FTPDefaultDir directive perhaps?
Re: svn commit: r815962 - /httpd/mod_fcgid/trunk/modules/fcgid/fcgid_conf.h
On Wed, Sep 16, 2009 at 4:59 PM, traw...@apache.org wrote: Author: trawick Date: Wed Sep 16 20:59:22 2009 New Revision: 815962 URL: http://svn.apache.org/viewvc?rev=815962view=rev Log: sort server config fields first by scope then by name of corresponding directive perhaps gratuitous or even nonsensical, but it helped/is helping my feeble brain with later changes ;)
Re: [VOTE] release httpd mod_ftp-0.9.5 beta?
Hi Bill, William A. Rowe, Jr. wrote: Gregg L. Smith wrote: I mentioned on another thread; the builds are very closely related, so it's pretty simple to check them out side by side or put them into the same server. Most defiantly when it comes to building them and I now understand that thinking. Not really a release issue at all. But something we might do more to promote. I'd think moving from beta to GA might help that? I'd been stubborn about GA mostly due to protocol issues (almost entirely now solved) and versioning, but have come to the conclusion that 0.9.X might be a perfectly good GA, while 1.0.0 might introduce some API version expectations and consistency for user/developers. Understood, GA can't hurt with the Beta refusenics. Those of use willing to use beta there are no worries about. Promote is the key word, at all levels. Yup :) I find it funny the number of them you can yum install/apt get from any distro. Yes, I have a Fedora box and have seen just this. Plenty on the Windows side as well. This is why it made the list. But **we don't vote on binaries** :) We vote on source code, This is not what I was implying, sorry if it came out that way and I know it got jumbled into the thread. I was more trying to address the lack of interest. Remember, your email covered two things really, voting and lack of interest to vote. Maybe I see things too simple or simply incorrectly, how I see it is end-user use is proportionate to availability, dev interest may be proportionate to users interest? Maybe it is just me but life is cost/benefit weighing at every turn. What is the benefit for developers to spend all the time working on/having interest in a project that has no interest at the user level. I wouldn't waste my time. How does one promote user interest, make it available. If you build it they will come sort of thing. It's two dogs chasing each others tails, someone needs to step in and seed this process, this is one case where policy I think is more hindering than helpful. You need to have releases to get users to use it and generate interest, you need to have the votes to get the release. Self defeating policy when it comes to new things that could box you into a no win situation. mod_fcgid while new to the ASF is not new by any means which is why I want to shy away from it in this discussion. mod_aspdotnet you say, apples and okra as it was a Windows only thing IIRC and therefore an uphill battle from the start. Windows users are spoiled rotten cause they are bred that way and therefore will require a binary since not many Windows users will compile, you opened that barn door on 6/20/98. Linux users are really just as spoiled for the most part but are fortunate in that their distros provide binaries via yum/apt get so they do not have to make as much noise to the ASF to get what they want in binaries. MS is not going to provide a binary for their users. This is the only reason why I mentioned binaries. Although Windows binaries may be available at a few places, the first place people are going to look is httpd.apache.org. Regardless, it seems the threat to dissolve this project woke some people that needed to be awaken. In that sense it certainly worked. I'm looking forward to 0.9.6 after you crush the build problems Guenter pointed to. I took a little time to look over the docs last night and will do so again every evening till I think I have a handle on it so as I can give the next run a decent try and at least say works great or sucks big time :) I just hope you can now muster your needed three votes. Regards, Gregg
Re: [VOTE] release httpd mod_ftp-0.9.5 beta?
Guenter Knauf wrote: ftp_commands.c: In function ‘common_list’: ftp_commands.c:694: warning: suggest parentheses around within || As we worked out, the distinction made no effective difference, but... ftp_protocol.c: In function ‘ftp_read_line’: ftp_protocol.c:244: warning: comparison is always false due to limited range of data type ftp_protocol.c:246: warning: comparison is always false due to limited range of data type ftp_protocol.c:246: warning: comparison is always true due to limited range of data type ftp_protocol.c:255: warning: comparison is always false due to limited range of data type ftp_protocol.c:258: warning: comparison is always false due to limited range of data type ftp_protocol.c:258: warning: comparison is always true due to limited range of data type we should fix these first, and re-roll ... that sounds right; this code was faulty on platforms where '\xff' != 0xff.
Re: [VOTE] release httpd mod_ftp-0.9.5 beta?
Gregg L. Smith wrote: This is not what I was implying, sorry if it came out that way and I know it got jumbled into the thread. I was more trying to address the lack of interest. Remember, your email covered two things really, voting and lack of interest to vote. Maybe I see things too simple or simply incorrectly, how I see it is end-user use is proportionate to availability, dev interest may be proportionate to users interest? There is certainly some relationship there, but often user and dev interest diverge. If you count how many users wish the httpd project would have stuck with their tried-and-true 1.3, the project would never have moved forwards at all :) You need to have releases to get users to use it and generate interest, you need to have the votes to get the release. Self defeating policy when it comes to new things that could box you into a no win situation.[...] Carts and horses, yup :) Windows users are spoiled rotten cause they are bred that way and therefore will require a binary since not many Windows users will compile, you opened that barn door on 6/20/98. Linux users are really just as spoiled for the most part but are fortunate in that their distros provide binaries via yum/apt get so they do not have to make as much noise to the ASF to get what they want in binaries. As a footnote, I disagree with you. Windows users weren't spoiled, but deprived. Deprived of the compiler/linker build toolchain that most operating systems sported, and most of them free, at that :) The express editions have improved the situation dramatically, let's hope MS keeps that up :) Bill
