You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by James Ponder <ja...@squish.net> on 2002/11/14 02:09:22 UTC

[PATCH] post_connection hook

Hi.

I would like to be able to monitor connection establishment
(pre_connection) and connection termination (post_connection), however
only the former hook exists.  I was thinking the best way would be to modify
ap_process_connection in connection.c to add the post_connection hook, as
below:

AP_CORE_DECLARE(void) ap_process_connection(conn_rec *c, void *csd)
{
    ap_update_vhost_given_ip(c);

    ap_run_pre_connection(c, csd);

    if (!c->aborted) {
        ap_run_process_connection(c);
    }

    ap_run_post_connection(c, csd);
}

I'm new to looking at Apache 2, so let me down gently if this is completely
the wrong approach.


Best wishes, James

--- httpd-2.0.43.dist/include/http_connection.h	2002-03-29 08:17:19.000000000 +0000
+++ httpd-2.0.43/include/http_connection.h	2002-11-14 01:41:04.000000000 +0000
@@ -120,8 +120,9 @@
    
 /**
  * This hook gives protocol modules an opportunity to set everything up
- * before calling the protocol handler.  All pre-connection hooks are
- * run until one returns something other than ok or decline
+ * before calling the protocol handler, or for other modules to monitor a
+ * connection establishment.  All pre-connection hooks are run until one
+ * returns something other than ok or decline
  * @param c The connection on which the request has been received.
  * @param csd The mechanism on which this connection is to be read.  
  *            Most times this will be a socket, but it is up to the module
@@ -132,6 +133,20 @@
 AP_DECLARE_HOOK(int,pre_connection,(conn_rec *c, void *csd))
 
 /**
+ * This hook gives protocol modules an opportunity to clean-up anything done
+ * in the pre_connection handler, or for other modules to monitor a
+ * connection closing.  All post-connection hooks are run until one returns
+ * something other than ok or decline
+ * @param c The connection on which the request was received.
+ * @param csd The mechanism on which this connection was read.
+ *            Most times this will be a socket, but it is up to the module
+ *            that accepts the request to determine the exact type.
+ * @return OK or DECLINED
+ * @deffunc int ap_run_post_connection(conn_rec *c, void *csd)
+ */
+AP_DECLARE_HOOK(int,post_connection,(conn_rec *c, void *csd))
+
+/**
  * This hook implements different protocols.  After a connection has been
  * established, the protocol module must read and serve the request.  This
  * function does that for each protocol module.  The first protocol module
diff -ur httpd-2.0.43.dist/server/connection.c httpd-2.0.43/server/connection.c
--- httpd-2.0.43.dist/server/connection.c	2002-07-15 09:05:10.000000000 +0100
+++ httpd-2.0.43/server/connection.c	2002-11-14 01:33:16.000000000 +0000
@@ -76,14 +76,16 @@
 
 APR_HOOK_STRUCT(
             APR_HOOK_LINK(create_connection)
-	    APR_HOOK_LINK(process_connection)
-	    APR_HOOK_LINK(pre_connection)
+            APR_HOOK_LINK(process_connection)
+            APR_HOOK_LINK(pre_connection)
+            APR_HOOK_LINK(post_connection)
 )
 AP_IMPLEMENT_HOOK_RUN_FIRST(conn_rec *,create_connection,
                             (apr_pool_t *p, server_rec *server, apr_socket_t *csd, long conn_id, void *sbh, apr_bucket_alloc_t *alloc),
                             (p, server, csd, conn_id, sbh, alloc), NULL)
 AP_IMPLEMENT_HOOK_RUN_FIRST(int,process_connection,(conn_rec *c),(c),DECLINED)
 AP_IMPLEMENT_HOOK_RUN_ALL(int,pre_connection,(conn_rec *c, void *csd),(c, csd),OK,DECLINED)
+AP_IMPLEMENT_HOOK_RUN_ALL(int,post_connection,(conn_rec *c, void *csd),(c, csd),OK,DECLINED)
 /*
  * More machine-dependent networking gooo... on some systems,
  * you've got to be *really* sure that all the packets are acknowledged
@@ -206,5 +208,7 @@
     if (!c->aborted) {
         ap_run_process_connection(c);
     }
+
+    ap_run_post_connection(c, csd);
 }
 
-- 
James Ponder; www.squish.net; London, UK

Re: [PATCH] post_connection hook

Posted by "William A. Rowe, Jr." <wr...@apache.org>.
At 03:36 AM 11/14/2002, James Ponder wrote:
>On Wed, Nov 13, 2002 at 08:43:05PM -0500, Jeff Trawick wrote:
>> The recommended approach is to register a cleanup with the conn_rec
>> pool.  When the connection goes away, so does the conn_rec pool, and
>> your cleanup will then run.
>
>Does that place any restrictions on what can be done in the cleanup code,
>for example is there any memory that might have vanished as I'm trying to
>do things?  (I can't actually think what I may want to do on a connection
>close apart from use the IP/socket information - presumably that's at least
>still available)

Cleanups are a LIFO stack.  When a pool is freed, first all sub-pools are
freed.  Then all cleanups within that pool are run (the cleanups in the
sub-pool already ran when those sub-pools were freed.)

So if you register a cleanup, then create an apr object in the same pool,
those apr object's cleanup runs before your registered cleanup.

If you create an apr object and register your own cleanup, you still have
that object until your registered cleanup is finished.

Bill


Re: [PATCH] post_connection hook

Posted by Jeff Trawick <tr...@attglobal.net>.
James Ponder <ja...@squish.net> writes:

> On Wed, Nov 13, 2002 at 08:43:05PM -0500, Jeff Trawick wrote:
> > The recommended approach is to register a cleanup with the conn_rec
> > pool.  When the connection goes away, so does the conn_rec pool, and
> > your cleanup will then run.
> 
> Does that place any restrictions on what can be done in the cleanup code,
> for example is there any memory that might have vanished as I'm trying to
> do things?  (I can't actually think what I may want to do on a connection
> close apart from use the IP/socket information - presumably that's at least
> still available)

Cleanups are able to reference storage allocated from the pool, since
the storage isn't released until after the last cleanup has been run.
So the IP/socket information is still available.

I don't know what the rules are for what you can do in a cleanup.  I
don't think you'd want to do anything that would cause another cleanup
to be registered.  Other than that, I dunno.

-- 
Jeff Trawick | trawick@attglobal.net
Born in Roswell... married an alien...

Re: [PATCH] post_connection hook

Posted by James Ponder <ja...@squish.net>.
On Wed, Nov 13, 2002 at 08:43:05PM -0500, Jeff Trawick wrote:
> The recommended approach is to register a cleanup with the conn_rec
> pool.  When the connection goes away, so does the conn_rec pool, and
> your cleanup will then run.

Does that place any restrictions on what can be done in the cleanup code,
for example is there any memory that might have vanished as I'm trying to
do things?  (I can't actually think what I may want to do on a connection
close apart from use the IP/socket information - presumably that's at least
still available)


Best wishes, James
-- 
James Ponder; www.squish.net; London, UK

Re: [PATCH] post_connection hook

Posted by Jeff Trawick <tr...@attglobal.net>.
James Ponder <ja...@squish.net> writes:

> I would like to be able to monitor connection establishment
> (pre_connection) and connection termination (post_connection), however
> only the former hook exists.  I was thinking the best way would be to modify
> ap_process_connection in connection.c to add the post_connection hook, as
> below:

The recommended approach is to register a cleanup with the conn_rec
pool.  When the connection goes away, so does the conn_rec pool, and
your cleanup will then run.

-- 
Jeff Trawick | trawick@attglobal.net
Born in Roswell... married an alien...