httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Helmut Tessarek <>
Subject DBD framework, APR, caching
Date Wed, 21 Mar 2007 21:59:41 GMT
Hi everybody,

Nick Kew suggested that I should post my findings and ideas regarding the DBD
framework, APR and caching.

Just a short paragraph on how this all came up:

I've written an authnz module for IBM DB2. The reason why I haven't used the DBD
framework was the lack of features that I have implemented in my module:
- stored procedure support
- caching
- password validation for a 32-character hexadecimal md5 hash

Please see Nick's blog entry 'In or Out [part 2]' at

I have some ideas how these features can be implemented within the DBD framework
and how others can benefit from them:

Password validation:

Many web applications use a 32-character hexadecimal md5 hash, since PHP returns
such a value for its md5 function. Unfortunately the apr_password_validate
function does not validate such a value. Since almost every authnz backend uses
this function, it would be perfect to add this validation process to
apr_password_validate. I have attached a patch for it.


I've just changed my caching algorithm to use APR, so it must be fairly easy to
either add caching to the DBD framework or to write its own caching backend.
Regarding the modularity, an own autnz caching backend would be best.
So all other expensive providers could benefit from caching.
See for my caching functions.
It would be nice to even add memory caching functionality to it.
If someone has any ideas, please let me know. I don't need to write all code by
myself, so I would be happy to help out with it.

Stored procedure support:

I think the DBD framework is the best way to implement SP functionality for all
SQL backends.
I have added two directives to my module which expect only the name of the
stored procedure. The procedures must have the following parameter format:
CREATE PROCEDURE group_procedure_name ( IN VARCHAR )
The input parameter is always the 'username'. In the user SP, the password is
returned in the out value and in the group SP an open cursor to the resultset is
There are other ways to implement it, but I thought that this would be the most
performant way.

I hope that this post initiates a discussion about this topic.
Furthermore I hope that others already have thought about the same issues and
that they are sharing their thoughts.

   Helmut Tessarek

View raw message