httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ben Laurie <>
Subject Re: mod_smtpd design.
Date Fri, 01 Jul 2005 08:51:06 GMT
Rian Hunter wrote:
> Hi,
> Currently there are two approaches we are looking at for mod_smtpd. We 
> can use the existing request_rec structure, and store smtp specific data 
> in a structure stucture in the r->request conf vector. With this we can 
> reuse some of the existing core hooks that make sense (handler, 
> create_request) while also adding some new ones for smtp (envelope, 
> called after all necessary commands have been sent). The downside is 
> that a lot of the request_rec members are extraneous for smtp.
> The other approach is to use a custom smtp_request_rec structure for an 
> smtp session. This has the advantage/disadvantage of defining new hooks 
> only necessary for smtp, but the disadvantage is that currently in httpd 
> 2.x filters that alter content data require a valid request_rec. It 
> would be possible to pass a bogus request_rec with the filters set to 
> ap_add_*_filter*() (or ap_run_insert_filter() so we let reuse core's 
> handle the Set(Out|In)putFilter directive), except that seems a little 
> hackish to me.

I don't see why it matters if there are redundant members in 
request_rec. However, for purity, it might be cool to divide request_rec 
up into common elements and protocol-specific stuff in a union.

The downside of this approach, though, is that you could easily call a 
module that expected the wrong union to be filled in. So, it might be 
better to have all protocols members in request_rec, but ensure that the 
irrelevant ones have values that are consistent with their irrelevancy.

Another approach still would require a fairly large change to the core 
and many modules, but it strikes me as a better option...

struct http_data {

struct smtp_data {

struct request_rec {
	. /* common stuff */
	struct http_data *http;
	struct smtp_data *smtp;

with http set to NULL when smtp data is there. This means that modules 
that thought they were dealing with HTTP data on an SMTP request would 
die rather than behaving unpredictably. Of course, well-behaved modules 
would handle this gracefully.



 >>>ApacheCon Europe<<<         

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

View raw message