Re: Apache gprof profiling
Chris Knight wrote: Hi all, I found some mention of profiling Apache with gprof via google. I tried the following: % setenv CFLAGS '-pg -DGPROF -g' % ./configure [my configure flags] % make; make install; cd $PREFIX [alter the conf file to set the MaxRequestsPerChild to 1] % bin/httpd -X [make a request and close the connection, which should cause httpd to terminate normally.] I should end up with a gmon.out file that I can then feed to gprof, but I'm not. Is there a step I'm missing and/or is this possible? For that matter, is there any official documentation regarding profiling? (In reality I want to profile a particular module but I thought it would be interesting to profile all of Apache's internals as well to get a complete picture.) After Jeff graciously pointed out that some gprof changes had occurred in 2.1-dev, I decided to give it a try and sure enough I could get a gmon.out file. Then, after doing a bunch of diffs, I came to the conclusion that the code defguarded by NO_USE_SIGACTION was removed in 2.1 and I tried defining that, sure enough it works now. Huzzah! (Just thought I'd report in so someone else trying to profile 2.0 will not stumble across this problem.) So the way to get profiling in 2.0.48: % setenv CFLAGS '-pg -DGPROF -g -DNO_USE_SIGACTION' % ./configure [my configure flags] % make; make install; cd $PREFIX [alter the conf file to set the MaxRequestsPerChild to 1] % bin/httpd -X [make a request and close the connection] I had a suspicion it had something to do with signals (since you don't get a gmon.out unless the process dies normally). Anyways, fixed a bug in the code along the way. :^)
Apache gprof profiling
Hi all, I found some mention of profiling Apache with gprof via google. I tried the following: % setenv CFLAGS '-pg -DGPROF -g' % ./configure [my configure flags] % make; make install; cd $PREFIX [alter the conf file to set the MaxRequestsPerChild to 1] % bin/httpd -X [make a request and close the connection, which should cause httpd to terminate normally.] I should end up with a gmon.out file that I can then feed to gprof, but I'm not. Is there a step I'm missing and/or is this possible? For that matter, is there any official documentation regarding profiling? (In reality I want to profile a particular module but I thought it would be interesting to profile all of Apache's internals as well to get a complete picture.)
mod_auth_ldap weirdness (no, not mod_ldap)
Ok, so I'm running 2.0.47 with mod_ldap, mod_auth_ldap, and a bunch of other modules. I've already stumbled across the mod_ldap problems and I've disabled caching entirely (LDAPCacheEntries 0) and LDAP authentication seems to work generally. However, when I ldap-protect a Location (as opposed to using the built-in htpasswd authentication) I get occasional (like 5% of the time) failures to load images and html documents. The access logs look normal (no 500's) and there is nothing in the error_log (no coredump or anything.) My LDAP server is running OpenLDAP 2.0.27 and my web server is running OpenLDAP 2.1.22. Any ideas what could be causing this? Is this a known problem? (Seems to be a fatal bug.) Hints as to where to look? I can run gdb on the server as well as Ethereal. Should I patch the mod_ldap stuff as well? (Does the latest CVS checkins contain the mod_ldap fixes?) Relevant Location section: Location /xyz AuthType Basic AuthName Authentication Required #AuthUserFile /usr/people/netmarkFTP/webdav/private/90.htpasswd require valid-user AuthLDAPEnabled on AuthLDAPURL ldap://myserver:389/dc=nasa,dc=gov; AuthLDAPAuthoritative on AuthLDAPBindDN cn=Manager,dc=nasa,dc=gov ModMimeUsePathInfo on /Location
pool interface for shared memory?
I would like to be able to use the existing apr_hash_t type with shared memory. To do so, I'd need to wrap a block of shared memory with an apr_pool_t type. It seems to me that this should be possible but reviewing the pool code, it appears it would not be possible without modifying pools code, perhaps to add a way to create an allocator that would take a block of existing memory in as input? I'd be interested to hear your ideas/suggestions and I'd be happy to slog some code...
Re: Spam Using SMTP Over HTTP-Proxy
Joshua Slive wrote: I think we've done pretty-much all we can. I wouldn't mind putting a little note on the httpd.apache.org homepage saying Have you secured your proxy? and point to the correct docs. What about sending a warning message to stderr/error_log upon startup if the proxy is not access controlled? ...HTTPS proxying is even worse and could be used to mount a variety of TCP attacks.
hello world example module...?
Would there be any interest in including example modules with the Apache
source distribution? And/or could a complete example module be included
in the documentation for developers? (Personally I'd prefer it be
included in the source distribution...The web documentation has become
quite out of date in places and it's more likely to be current if it
could be included in the distribution test suite.)
Yesterday, in trying to convey how to implement a module, I developed a
hello world example module that has a handler hook that responds
with a canned message to all requests. (It demonstrates hooks, and I
have a slightly more complex example showing how to read per-directory
configurations.)
I would have found a barebones example immensely useful and would have
saved me much time and code-grepping.
Anyways, I've attached my hello world module. Please
comment/correct/chastise as you see fit, I am by no means an expert. ;^
/* mod_hello_world.c
* Written by Chris Knight, NASA Ames Research Center
* [EMAIL PROTECTED]
*
* Build using:
* $APACHE_HOME/build/libtool gcc -c -I$APACHE_HOME/include mod_hello_world.c
*
* followed by:
* $APACHE_HOME/build/libtool --mode=link $(CC) -o $@ -fPIC $(INCLUDE) \
*hello_world.lo $(LIBS) $(APACHE_CFLAGS) -rpath /usr/lib -avoid-version
*/
#include httpd.h
#include http_core.h
#include http_config.h
#include ap_config.h
#include http_log.h
// Forward declaration of the module, see the bottom of this document for
// details.
module AP_MODULE_DECLARE_DATA hello_world_module;
// A struct to hold this module's configuration parameters.
typedef struct conf {
apr_pool_t *p;
char *message;
} conf;
/**
* Instantiate this module's configuration structure.
* This function is called by Apache for each configuration section and is
* passed by Apache to other module functions.
* @param p The memory pool to be used by this module.
* @param d The directory/location for this section?
* @return The configuration block's pointer.
*/
static void *create_conf(apr_pool_t *p, char *d) {
conf *c = apr_pcalloc(p, sizeof(conf));
c-p = p;
c-message = NULL;
return c;
}
/**
* Set the message in this module's configuration. This is called when
* the HelloWorldMsg directive is encountered in a configuration section.
* @param cmd The directive parameters ???
* @param config The section's configuration
* @param arg1 The message.
* @return The error message if there is an error with this directive.
*/
static const char *set_message(cmd_parms *cmd, void *config, const char *arg1) {
conf *c = (conf *)config;
c-message = (char *)apr_pstrdup(c-p, arg1);
return NULL;
}
/**
* Provide the response to the request.
* @param r The request record. (Containing all of the details of the request.)
* @return Flag indicating successful handling of the request.
*/
int handle(request_rec *r) {
conf *conf = ap_get_module_config(r-per_dir_config, hello_world_module);
// if there is no message declared for this URI (no matching Location,
// Directory, etc) then let another hook handle the request.
if (conf == NULL || conf-message == NULL) return DECLINED;
// otherwise, send our message to the client
ap_rprintf(r, conf-message);
// and tell Apache that we've handled the request
return OK;
}
/**
* Connect hook functions to Apache so that Apache will call them at the
* appropriate time.
* @param p The memory pool to use.
*/
static void register_hooks(apr_pool_t *p) {
// The handler hooks are used to provide the response's contents for a
// successful request.
ap_hook_handler(handle, NULL, NULL, APR_HOOK_MIDDLE);
}
// This list details which configuration directives this module understands.
static const command_rec cmds[] = {
// The HelloWorldMsg directive takes one argument, the message to send.
AP_INIT_TAKE1(HelloWorldMsg, set_message, NULL, OR_AUTHCFG,
specify the message to send clients),
// Indicates the end of the list of directives.
{NULL}
};
// This module declaration tells Apache which configuration directives this
// module understands and which methods to call to connect the hook functions.
module AP_MODULE_DECLARE_DATA hello_world_module = {
STANDARD20_MODULE_STUFF, // always need this
create_conf, // called for each configuration section
NULL,// called for nested configuration sections (?)
NULL,// called once per server configuration
NULL,// ?
cmds,// which configuration directives do I handle?
register_hooks // function to be called at bind-time
};
Re: hello world example module...?
Jeff Trawick wrote: Chris Knight wrote: Would there be any interest in including example modules with the Apache source distribution? modules/experimental/mod_example.c Ah, fair enough. I wouldn't have thought of looking in experimental, however (I seemed to remember that there was an example module somewhere but couldn't find it yesterday). And it's certainly a lot more to swallow than a hello world example.
fixed -- mod_mime.c#find_ct() redux
Justin Erenkrantz wrote: It looks like Catacomb (0.8.0 is what I just downloaded) is doing the same thing in its dav_repos_set_headers as mod_dav_svn. That hook runs after the fixups hooks, so it just trounces on the content-type that mod_mime tried to set with ModMimeUsePathInfo. Ah, good call. I've fixed Catacomb to not do this anymore unless the RDBMS has Content-Type defined. In doing some debugging, with mod_dav_fs (with DEBUG_GET_HANDLER defined in repos.c) I've found that find_ct is not called to identify the type. I'm Well, here, find_ct is called in the fixups stage. So, I'm not sure what's going on for you. Some more specifics could be helpful. I think because content_type was already defined, it skipped calling ap_run_type_checker? assuming the inability to run PHP scripts from a DAV server is the same problem. Bug or feature? Note that since PHP 4.2.3, which (I believe) introduced the PHP handler for httpd-2.0 and removed the PHP filter, it's not possible to do this chaining. Implementing PHP as a filter got to be a nightmare, and we eventually gave up and did it as a handler instead. One of the drawbacks is that PHP can't work off of virtual repositories or anything that has its own handler now. (PHP requires file-backed input into its parser which kills it for Subversion and httpd-2.0. I believe there may be some work to allow PHP to take in push-based streams like Apache httpd output filters can deliver - when that is ready, we can reexamine PHP as filter again and determine what needs to happen on httpd's side to make it all happy - there is definitely some work that has to be done to httpd as well.) This is a major issue with non-fs backends...One option would be to re-do the filter to use a temporary file to feed to PHP (a gross hack, I know.) Thanks for the details/history... Also, I would highly recommend that testing of Apache include testing the GET handler in mod_dav_fs. There are other backends (Catacomb, ?) that use mod_dav as their front-end and who handle GETs themselves and we're running into these issues. httpd-test's perl-framework already has some tests for WebDAV that does exactly this. Feel free to help us expand our tests over on [EMAIL PROTECTED] -- justin Strangely, I am not seeing the problem with mod_dav_fs anymore...Perhaps I was hallucinating...I guess it works for me. :^o Good news is I now have a much firmer grasp of the internal workings of Apache... Is there an active project to write/improve the documentation of these internal workings?
Re: automatic type identification (by extension) in virtual DAV repositories
André Malo wrote: * Chris Knight wrote: So, Catacomb and other mod_dav backends that handle GET requests would like to have the Content-Type of resources be automatically identified based on the path information of that resource in the same manner as file resources. How would I best approach this problem? It appears that the mod_dav.c hooks are defined as MIDDLE as is the mod_mime.c hooks...Should I force a specific ordering of execution? Only other problem is find_ct in mod_mime.c wants to see the finfo structure which doesn't apply to virtual resources. ModMimeUsePathInfo was created for this purpose IIRC. HTH, nd But it does not function in this circumstance. I believe ModMimeUsePathInfo turns on calls to find_ct but find_ct relies on filename which only goes down to the Location (the root of the Catacomb server.) I could hack the filename if I can get to it before find_ct is called (as detailed in my second paragraph) but that's certainly a poor solution.
Re: automatic type identification (by extension) in virtual DAV repositories
Justin Erenkrantz wrote: --On Friday, May 30, 2003 2:34 AM +0200 André Malo [EMAIL PROTECTED] wrote: ModMimeUsePathInfo was created for this purpose IIRC. Indeed. The only caveat is that ModMimeUsePathInfo shouldn't necessarily be enabled on resources that you edit. The problem comes into play when filters are applied and the transmitted representation differs from the on-disk (in-storage) resource. (This is actually a major collision with REST that WebDAV never quite solved cleanly - it just assumes that the resource == representation.) Note that Content-Type identification would only come into play when the Content-Type was not explicitly identified by the original PUT (as happens with the Win32's Web Folders client and the Cadaver client and surely many others.) Would it be better, instead, to not send a Content-Type header at all? (It appears that find_ct defaults to text/plain if it's unable to determine type by extension, should it instead do nothing?) The best example is with mod_include'd files. With ModMimeUsePathInfo On, there is no way to disable the output filters when communicating with a DAV client. Therefore, the solution is to mount the repository twice - once as read-only with ModMimeUsePathInfo On and another one with it Off so that the DAV clients can modify without having the filters executed and get the 'raw' representation. Hope that makes sense. If not, I can try to clarify. -- justin Already addressed by the WebDAV spec, see: http://asg.web.cmu.edu/rfc/rfc2518.html#sec-5.4 And, of course, this issue is peripheral to Content-Type identification.
automatic type identification (by extension) in virtual DAV repositories
So, Catacomb and other mod_dav backends that handle GET requests would like to have the Content-Type of resources be automatically identified based on the path information of that resource in the same manner as file resources. How would I best approach this problem? It appears that the mod_dav.c hooks are defined as MIDDLE as is the mod_mime.c hooks...Should I force a specific ordering of execution? Only other problem is find_ct in mod_mime.c wants to see the finfo structure which doesn't apply to virtual resources. I can't call find_ct directly, nor can I get at the mime_dir_config information to map the extension back to a Content-Type. Ideas? It seems to me that the mime_dir_config information should be made public or at least some methods for converting extension to Content-Type (and visa-versa?)
Re: mod_dav overhaul
Ben Collins-Sussman wrote: [...] I'm writing because I plan to do some major overhauling of mod_dav. No need to fear, because I'm essentially a disciple of gstein. :-) I'm reasonably familiar with mod_dav code already, because I'm intimate with the mod_dav_svn provider (Subversion's main server.) [...] Comments? Yes yes yes! If you need help, I'm a willing sucker/victim/volunteer. ;^o As is, I'm sure, all of the Catacomb back-end developers. (I've cc'd the Catacomb mailing list.) Perhaps it would be worthwhile to branch off to a sub mailing list for this effort?
guidance requested - how to get handler to work with GET in mod_dav_fs
I'd like to have handlers (from the http_request module, created by the Action and AddHandler directives) properly handle output sent from the mod_dav_fs module (with DEBUG_GET_HANDLER turned on.) For example, if mod_dav_fs handles a GET to a text/html file and I've added Action text/html /cgi-bin/footer.cgi, it should hand off the html document to the footer.cgi script for further processing. Is it the responsibility of the module responding to the GET to hand off to these handlers or should this be the default/core behavior of Apache? If not, can someone point me in the direction of how to hand off to a http_request handler? This functionality is critical for mod_dav backends. TIA!
any way for a module to call (mod_access) int check_dir_access(request_rec*rec)?
I am writing a module that would very much like to find out if a particular user has access to a particular URI (not the URI that got to my module). Is there any way through an inter-module framework or the like to call this function from within my module? I'd rather not formulate another HTTP request just to test this. If you must know why, I'm working on a mod_dav submodule and we'd like to not display information in PROPFIND that the user shouldn't be able to read via any other method. My apologies if this is not the correct list to ask this question.
