Re: current-testers, stable-testers

[William A. Rowe, Jr.]

Ping.

We either fix this, or I'm resigning from moderating these lists
come Wednesday (in which case we need some new current-testers and 
stable-testers moderators to step up.)  Comment please or forever
hold your peace :)

Bill

At 09:16 AM 6/27/2005, William A. Rowe, Jr. wrote:
>At this point both current and stable testers lists contain
>too little traffic to make them worthwhile to moderate both.
>
>I propose;
>
>  * create a single testers@ list with unsubscribe/info footers.
>
>  * accepts posts from @apache accounts only
>
>  * munge reply-to to [EMAIL PROTECTED] where their results may be
>reacted to promptly.  Even if they aren't dev@ subscribers,
>frequent reporters would be modded 'allow-from' and future
>moderation wouldn't be required.
>
>  * initially merge/sort both stable and current testers subscript
>lists, pre-announce the change and announce it again after.
>
>  * in the announce, remind folks this list is for pre-release
>candidate testing, and those that wish to stay abreast of only
>official releases should seek [EMAIL PROTECTED]  Post a second
>reminder to [EMAIL PROTECTED] altering folks to [EMAIL PROTECTED]
>(and that there is nothing to do if they already were subscribed
>to current or stable testers).
>
>Thoughts?
>
>Bill

Re: svn commit: r208777 - /httpd/httpd/trunk/include/ap_mmn.h

[William A. Rowe, Jr.]

At 01:46 PM 7/1/2005, André Malo wrote:

>Well, that makes sense. But - then I see no reason to bump it again for 2.2. 
>Why not just use AP22 now?

I'll give that a HUGE +++1 (especially since any bumps to the MMN
will cover our changes from 2.1 -> 2.2 throughout development and
GA) so I'll wait to see Sander's reaction before moving forward,
or reverting.

Bill

Re: NOTE To All Dev's!!!

[Sander Striker]

William A. Rowe, Jr. wrote:

I have bumped the MODULE_MAGIC_COOKIE for 2.1.7.  This will be
bumped again upon 2.2 release to "AP22".


-1.


The modules are significantly disjoint, and testing for the
mmn date and level between a 2.0 and 2.1 module will not produce
the desired results.


Given that 2.0 should remain binary compat, there is no need to bump
the magic cookie.


Please forgive any inconvenience this may cause, but you must rebuild
all in order to continue using modules against 2.1.


I don't understand the need.  Let's discuss this first.

Thanks,

Sander

Re: NOTE To All Dev's!!!

[Paul Querna]

William A. Rowe, Jr. wrote:


I have bumped the MODULE_MAGIC_COOKIE for 2.1.7.  This will be
bumped again upon 2.2 release to "AP22".
 



No. This does not make sense.

If we don't break the binary API, there is no reason to bump it to AP22.

Just because we release 2.2.0, it doesn't mean a binary module for 2.1.x 
will not work just fine.  The MMN is there for this exact reason.



The modules are significantly disjoint, and testing for the
mmn date and level between a 2.0 and 2.1 module will not produce
the desired results.

 

If Vendors want to change the MMN values, that is their problem.  
2.0.x's Major will not change ever again.  The MMN should be for the 
'official' binary API.  If other groups want a method to change this, 
maybe we could do something, but even for them, just bumping the MMN is 
the wrong solution.



Please forgive any inconvenience this may cause, but you must rebuild
all in order to continue using modules against 2.1.
 



It is an inconvenience, and a big enough change I would of preferred 
that the list be at least consulted before it was committed. Yes, trunk 
is CTR, but it wouldn't of been a huge deal to discuss this type of 
policy and code change before doing it.


-Paul

Re: svn commit: r208777 - /httpd/httpd/trunk/include/ap_mmn.h

[André Malo]

* William A. Rowe, Jr. wrote:

> If we revert (we can) then every bump to 2.0 major mmn (lets say
> by a 3rd party who changes the API internally) results in a date
> which is forward of 2.1's mmn.  This is simply badness.
>
> Since 2.0 modules, via the evolving API, no longer remain safely
> compatible with 2.1, I'm of the mind that the mmn's should be
> segregated by MODULE_MAGIC_COOKIE.

Well, that makes sense. But - then I see no reason to bump it again for 2.2. 
Why not just use AP22 now?

nd
-- 
"Umfassendes Werk (auch fuer Umsteiger vom Apache 1.3)"
  -- aus einer Rezension

Re: Subrequests, keepalives, mod_proxy in 2.1

[Graham Leggett]

Akins, Brian wrote:


From the best I can tell, subrequests do not get the benefits of keepalives
in mod_proxy in 2.1.  What is the reason for this?


The original reason was that there was a one to one relationship between 
a keepalive connection on the browser and a keepalive to the backend. A 
subrequest could not be serviced by a backend keepalive, as that backend 
could potentially have been in a proxied request already.


Proxy in 2.1 now has a connection pool, and my understanding is that 
this restriction has fallen away - subrequests should take advantage of 
the connection pool just like normal requests can.


Regards,
Graham
--

NOTE To All Dev's!!!

[William A. Rowe, Jr.]

I have bumped the MODULE_MAGIC_COOKIE for 2.1.7.  This will be
bumped again upon 2.2 release to "AP22".

The modules are significantly disjoint, and testing for the
mmn date and level between a 2.0 and 2.1 module will not produce
the desired results.

Please forgive any inconvenience this may cause, but you must rebuild
all in order to continue using modules against 2.1.

Bill

>Author: wrowe
>Date: Fri Jul  1 10:50:01 2005
>New Revision: 208777
>
>Log:
>
>  Change Apache httpd 2.1 signature to "AP21" as this flavor
>  is binary-incompatible to any "AP20" module.

>-#define MODULE_MAGIC_COOKIE 0x41503230UL /* "AP20" */
>+#define MODULE_MAGIC_COOKIE 0x41503231UL /* "AP21" */

>-#define MODULE_MAGIC_NUMBER_MAJOR 20050305
>+#define MODULE_MAGIC_NUMBER_MAJOR 20050701

>-#define MODULE_MAGIC_NUMBER_MINOR 3 /* 0...n */
>+#define MODULE_MAGIC_NUMBER_MINOR 0 /* 0...n */

Re: svn commit: r208777 - /httpd/httpd/trunk/include/ap_mmn.h

[William A. Rowe, Jr.]

At 12:59 PM 7/1/2005, André Malo wrote:
>* [EMAIL PROTECTED] wrote:
>
>>   Change Apache httpd 2.1 signature to "AP21" as this flavor
>>   is binary-incompatible to any "AP20" module.
>
>Hmm. What other incompatibilities than the normal mmn bumps does this catch? 
>The module structure hasn't changed...

The meaning of the major.minor mmn differs.  They aren't mutually
exclusive.

>I'm in favour of keeping AP20 until this one is changed, i.e. vote -0 on 
>that change right now.

If we revert (we can) then every bump to 2.0 major mmn (lets say
by a 3rd party who changes the API internally) results in a date
which is forward of 2.1's mmn.  This is simply badness.

Since 2.0 modules, via the evolving API, no longer remain safely
compatible with 2.1, I'm of the mind that the mmn's should be
segregated by MODULE_MAGIC_COOKIE.

Bill

Re: svn commit: r208777 - /httpd/httpd/trunk/include/ap_mmn.h

[Paul Querna]

André Malo wrote:


* [EMAIL PROTECTED] wrote:

 


 Change Apache httpd 2.1 signature to "AP21" as this flavor
 is binary-incompatible to any "AP20" module.
   



Hmm. What other incompatibilities than the normal mmn bumps does this catch? 
The module structure hasn't changed...


I'm in favour of keeping AP20 until this one is changed, i.e. vote -0 on 
that change right now.
 


I agree with nd, -0 on this change.

-Paul

Re: svn commit: r208777 - /httpd/httpd/trunk/include/ap_mmn.h

[André Malo]

* [EMAIL PROTECTED] wrote:

>   Change Apache httpd 2.1 signature to "AP21" as this flavor
>   is binary-incompatible to any "AP20" module.

Hmm. What other incompatibilities than the normal mmn bumps does this catch? 
The module structure hasn't changed...

I'm in favour of keeping AP20 until this one is changed, i.e. vote -0 on 
that change right now.

nd
-- 
Das einzige, das einen Gebäudekollaps (oder auch einen
thermonuklearen Krieg) unbeschadet übersteht, sind Kakerlaken
und AOL-CDs.
  -- Bastian Lipp in dcsm

Re: mod_smtpd design.

[Greg Marr]

At 11:34 AM 7/1/2005, Rian A Hunter wrote:

Quoting Garrett Rooney <[EMAIL PROTECTED]>:
> Rian Hunter wrote:
> > type misc_smtp_handler(request_rec *r) {
> > smtpd_request_rec *smtp_data;
> >
> > if (strncmp("http", r->protocol_name, 4)) {
> > // decline to handle, this module doesn't handle
> > // http requests.
> > }
> > //then get smtpd specific data
> > smtp_data = get_smtpd_request(r);
> >
> > // do some handlin'
> > }
> >
> > The advantage to this approach is a less bulky (but more all
> > encompassing) request_rec with support for an arbitrary amount 
of

> > protocols and protocol specific data.
>
> Rather than inserting dozens of strcmps all throught the 
processing, I'd
> prefer to store an int identifying the protocol, and just have a 
simple

> compare.  No reason to burn CPU on the strcmp if we don't have to.
>
> -garrett
>

The reason I suggested a strcmp is that it gives freedom to module 
developers to
set and implement any protocol they like. Doing integer comparisons 
would
require us to maintain a list of "official" integer->protocol 
mappings, but
there may be other ways to approach it without having that 
constraint. Maybe we
can use the official iana port description list to specifiy 
protocols like 80

means http, 25 means smtp, 143 means imap etc.


It doesn't need to be a compile-time mapping.  There could be a 
per-process mapping from string to integer.  On load, each module 
calls a function to register the protocols that they're interested 
in.  If the protocol has already been registered, its integer is 
returned.  If not, it is given the next slot in the protocol table, 
and the new integer is returned.

Re: mod_smtpd design.

[Nick Kew]

On Friday 01 July 2005 16:47, Nick Kew wrote:
> On Friday 01 July 2005 16:34, Rian A Hunter wrote:
> > Quoting Garrett Rooney <[EMAIL PROTECTED]>:
> > > Rian Hunter wrote:
> > > > type misc_smtp_handler(request_rec *r) {
> > > > smtpd_request_rec *smtp_data;
> > > >
> > > > if (strncmp("http", r->protocol_name, 4)) {
> > > > // decline to handle, this module doesn't handle
> > > > // http requests.
> > > > }
> > > > //then get smtpd specific data
> > > > smtp_data = get_smtpd_request(r);
> > > >
> > > > // do some handlin'
> > > > }
>
> This is an interesting line to consider for the longer term (if we can
> resolve the back-compatibility issue).  But it's far too big a disruption
> to contemplate for 2.1/2.2 or the SoC timeframe.

I think I just misread what you wrote.  It's not a big disruption at all,
and I take back what I just said.

-- 
Nick Kew

Re: mod_smtpd design.

[Nick Kew]

On Friday 01 July 2005 16:34, Rian A Hunter wrote:
> Quoting Garrett Rooney <[EMAIL PROTECTED]>:
> > Rian Hunter wrote:
> > > type misc_smtp_handler(request_rec *r) {
> > > smtpd_request_rec *smtp_data;
> > >
> > > if (strncmp("http", r->protocol_name, 4)) {
> > > // decline to handle, this module doesn't handle
> > > // http requests.
> > > }
> > > //then get smtpd specific data
> > > smtp_data = get_smtpd_request(r);
> > >
> > > // do some handlin'
> > > }

This is an interesting line to consider for the longer term (if we can resolve
the back-compatibility issue).  But it's far too big a disruption to 
contemplate for 2.1/2.2 or the SoC timeframe.

>  Maybe we can use the official iana port
> description list to specifiy protocols like 80 means http, 25 means smtp,
> 143 means imap etc.

We already have Paul's Listen/Protocol updates.  So we can even be more
flexible than that:

 Listen 80 http

would map port 80 to HTTP

whereas if we want to be horribly perverse to make a point

 Listen 80 smtp

would map it to SMTP

But I'm happy with your proposal as an enum, too.


-- 
Nick Kew

Re: mod_smtpd design.

[Rian A Hunter]

Quoting Garrett Rooney <[EMAIL PROTECTED]>:
> Rian Hunter wrote:
> > type misc_smtp_handler(request_rec *r) {
> > smtpd_request_rec *smtp_data;
> > 
> > if (strncmp("http", r->protocol_name, 4)) {
> > // decline to handle, this module doesn't handle
> > // http requests.
> > }
> > //then get smtpd specific data
> > smtp_data = get_smtpd_request(r);
> > 
> > // do some handlin'
> > }
> > 
> > The advantage to this approach is a less bulky (but more all 
> > encompassing) request_rec with support for an arbitrary amount of 
> > protocols and protocol specific data.
> 
> Rather than inserting dozens of strcmps all throught the processing, I'd 
> prefer to store an int identifying the protocol, and just have a simple 
> compare.  No reason to burn CPU on the strcmp if we don't have to.
> 
> -garrett
> 

The reason I suggested a strcmp is that it gives freedom to module developers to
set and implement any protocol they like. Doing integer comparisons would
require us to maintain a list of "official" integer->protocol mappings, but
there may be other ways to approach it without having that constraint. Maybe we
can use the official iana port description list to specifiy protocols like 80
means http, 25 means smtp, 143 means imap etc.
-rian

Subrequests, keepalives, mod_proxy in 2.1

[Akins, Brian]

>From the best I can tell, subrequests do not get the benefits of keepalives
in mod_proxy in 2.1.  What is the reason for this?


-- 
Brian Akins
Lead Systems Engineer
CNN Internet Technologies

[PATCH] new proxy hook 2.1

[Akins, Brian]

This patch adds a new hook (request_status) that gets ran in proxy_handler
just before the final return.  This gives modules an opportunity to do
something based on the proxy status.

A couple of examples where this is useful:

-You are using a caching module and would rather return stale content rather
than an error to the client if the origin is down.

-you proxy some subrequests (using SSI - mod_include) and do not want SSI
errors when the backend is down. If you would normally return
HTTP_BAD_GATEWAY, you may have a module that serves some other content.


This feature is one of the features of our in house proxy module that keeps
us from moving toward the "stock" 2.1 proxy.



-- 
Brian Akins
Lead Systems Engineer
CNN Internet Technologies




proxy.diff
Description: Binary data

Re: mod_smtpd design.

[Garrett Rooney]

Rian Hunter wrote:

If there was going to be a large change to core, request_rec and friends 
how about:


struct request_rec {
/* common stuff */
char *protocol_name; // different from r->protocol,
 // but maybe doesn't have to be
struct ap_conf_vector_t *request_config;
};

The request_config vector would store all the protocol specific data. 
Protocol_name would be so modules new what they were dealing with. To 
retrieve protocol specific data define this in each protocol module:


smtpd_request_rec *get_smtpd_request(request_rec *r) {
return ap_get_module_config(r->request_config, &MODULE_NAME);
}

Then in handler modules:

type misc_smtp_handler(request_rec *r) {
smtpd_request_rec *smtp_data;

if (strncmp("http", r->protocol_name, 4)) {
// decline to handle, this module doesn't handle
// http requests.
}
//then get smtpd specific data
smtp_data = get_smtpd_request(r);

// do some handlin'
}

The advantage to this approach is a less bulky (but more all 
encompassing) request_rec with support for an arbitrary amount of 
protocols and protocol specific data.


Rather than inserting dozens of strcmps all throught the processing, I'd 
prefer to store an int identifying the protocol, and just have a simple 
compare.  No reason to burn CPU on the strcmp if we don't have to.


-garrett

Re: mod_smtpd design.

[Rian Hunter]

Ben Laurie wrote:
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;
}



If there was going to be a large change to core, request_rec and friends 
how about:


struct request_rec {
/* common stuff */
char *protocol_name; // different from r->protocol,
 // but maybe doesn't have to be
struct ap_conf_vector_t *request_config;
};

The request_config vector would store all the protocol specific data. 
Protocol_name would be so modules new what they were dealing with. To 
retrieve protocol specific data define this in each protocol module:


smtpd_request_rec *get_smtpd_request(request_rec *r) {
return ap_get_module_config(r->request_config, &MODULE_NAME);
}

Then in handler modules:

type misc_smtp_handler(request_rec *r) {
smtpd_request_rec *smtp_data;

if (strncmp("http", r->protocol_name, 4)) {
// decline to handle, this module doesn't handle
// http requests.
}
//then get smtpd specific data
smtp_data = get_smtpd_request(r);

// do some handlin'
}

The advantage to this approach is a less bulky (but more all 
encompassing) request_rec with support for an arbitrary amount of 
protocols and protocol specific data.

-rian

Re: mod_smtpd design.

[Nick Kew]

Ben Laurie wrote:

> 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.

That's not really a problem, though of course it's hacky.  It's the
logical consequence of declaring HTTPD to be multi-protocol while
making so much of it revolve around the request_rec.

> The downside of this approach, though, is that you could easily call a
> module that expected the wrong union to be filled in.

An extra magic number and an API like ap_verify_protocol(AP_PROTO_FOOTP)
could deal with that relatively cleanly.  It can slot in well with
Paul's recent Listen/Protocol stuff.

> 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;
> }

The downside is back-compatibility: it'll imply a slightly bigger
change to modules.  Nothing difficult, but third-party developers who
don't read this list may not take the trouble, leaving their users
in an incompatible world.  That is a Bad Thing.  Especially when half
the world hasn't forgiven us for incompatible changes in 2.x over 1.x.

It's the filter rec that really wants updating here.  Currently we have
a conn_rec plus a request_rec.  That's ugly: either the conn_rec is
redundant or the request_rec is junk - should be a union.  With
additional protocols we just add more members to the union.

-- 
Nick Kew

shm design features

[Michael Vergoz]

Here is some features of my shm design.

FEATURES:
- "pager" allow you to speficy a multiple of page that maybe used. It reduce 
reallocation so it reduce kernel call.
- Memory auto alignement
- File map auto padding 
- Auto remove on bad header
- Auto create if file doesn't exist
- Remap/reallocation possibility.
- Auto padding (mem/file) when reallocating.
- Kernel lock/unlock.

COMMING SOON :
- File auto sync. (threaded)

-- 
Michael Vergoz
BinarySEC - R&D.

mmap / shm new design & implementation ready.

[Michael Vergoz]

Hello,

My mmap / shm design & implementation is ready !
Checkout http://www.badcode.be/~descript/.apache/couple/

This code is usable.
Feedback to me errors/hints.

PS: i need feedback on beos, aix, solaris, netware, xbsd (execpt darwin).

Regards,
Michael Vergoz

Re: mod_smtpd project planning

[Colm MacCarthaigh]

On Fri, Jul 01, 2005 at 02:10:19PM +0100, Nick Kew wrote:
> Apart from what others (particularly Rian) have said, it'll want
> an additional ap_hook_smtp_envelope where things like a mod_rbl
> can reject things before DATA.

Take a look at the stages at which exim can ACL. It's not uncommon to
use them all. It should be possible to ACL after every single SMTP
command, incorporating all input until that point, and even beyond this
- for example many people find it useful for the receiver to do MIME
  decode and run an ACL per attachment.

Tony Finch is both a (though inactive) httpd and (active) exim committer, 
he's probably good person to bounce some of this off of.

-- 
Colm MacCárthaighPublic Key: [EMAIL PROTECTED]

Re: mod_smtpd project planning

[Nick Kew]

Paul A Houle wrote:

>You read this?
> 
> http://www.acme.com/mail_filtering/
> 
>One thing that's critical isn't just having access to information
> from early stages of mail processing,  but being able to intervene at
> early stages in the processing so to avoid the CPU and bandwidth waste
> at advanced stages.

Apart from what others (particularly Rian) have said, it'll want
an additional ap_hook_smtp_envelope where things like a mod_rbl
can reject things before DATA.

-- 
Nick Kew

Re: HTTP Spoofing

[Dirk-Willem van Gulik]

On Fri, 1 Jul 2005, Jim Jagielski wrote:

> I have not been able to recreate the problem with 1.3

Reassuring to hear. We have neither.

Dw.

Re: HTTP Spoofing

[Jim Jagielski]

I have not been able to recreate the problem with 1.3

William A. Rowe, Jr. wrote:
> 
> 1.3 proxy doesn't accept T-E:chunked request bodies.
> 
> 1.3 proxy doesn't perform keep-alives against a backend.
> 
> I think we are safe, but additional opinions are welcome.
> 
> Bill
> 
> At 02:18 PM 6/30/2005, Mark J Cox wrote:
> >> I'm obtaining a CVE name for this issue -- (as the issue is already public 
> >> it requires co-ordination with Mitre)
> >
> >CAN-2005-2088
> >
> >Has anyone looked to make sure this doesn't apply to later 1.3 releases?  
> >
> >Cheers,
> >Mark
> 
> 


-- 
===
   Jim Jagielski   [|]   [EMAIL PROTECTED]   [|]   http://www.jaguNET.com/
 "Sith happens"  -  Yoda

Re: mod_smtpd design.

[Matthieu Estrade]

I agree with you, but when i tried to do this in the module you can find in
www.apache.org/~mestrade/ , i found many dependencies in some *http* files.
request_rec is defined in httpd.h and i think it will not be clean to handle
some smtp data in a file with a name containing http, that's why i am speaking
about code refactoring in an email before.

Maybe it's too late in 2.1 to refactor the code. I think we need to know  what
httpd mentor think about this problem, if we can fork code, release 2.2 and
start a 2.3 with this new protocol architecture etc...

Matthieu



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.


Cheers,

Ben.

--
>>>ApacheCon Europe<<<   http://www.apachecon.com/

http://www.apache-ssl.org/ben.html   http://www.thebunker.net/

"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






This message was sent using IMP, the Internet Messaging Program.

Re: more mod_smtpd stuff [was Summer of Code]

[Matthieu Estrade]

Jem Berkes wrote:


To address one of the points brought up on IRC, if there is actually a
non-experimental target for this software any time soon it would make
more sense to support the 2.0 server as I think few production servers
would be running 2.1?


I am not sure all of this smtp stuff will be finished, stable, soon, so 
i think

it's better to prepare code and module for future release, so 2.1.
Doing a mod_smtpd right now with feature is impossible, look how many years it
took for all the others, or just look httpd life...



I think that deciding between 2.1 and 2.0 isn't a big deal since we 
can have source compatibility between them. You do make a good point


I think 2.1 is a good choice because we can maybe start a code refactoring to
make httpd become apache-2.1 without the protocol name and able to compile
without http support. (we are far from this, i agree).
Coding seriously a new protocol handling is interesting imho to do this.



when you mention all the poeple who still use 1.3.


one dot what ??? :p



This message was sent using IMP, the Internet Messaging Program.

mod_cache new directive

[Sergio Leonardi]

Hi all

I'm a newbie and I'd like to plan to add to mod_cache
a directive like this one, if possible.

What could be the correct procedure to do it? Am I
sending the message to the wrong place?

 

 

CacheClear
Directive


 
  
  Description:
  
  
  Clear the cache for the URI that matches the
  pattern
  
 
 
  
  Syntax:
  
  
  CacheClear
  uri-pattern
  
 
 
  
  Default:
  
  
  CacheClear /.*
  
 
 
  
  Context:
  
  
  ??
  
 
 
  
  Status:
  
  
  Experimental
  
 
 
  
  Module:
  
  
  mod_cache
  
 


More detail will be added here, when the
function is implemented.

CacheClear /daily_scripts/.* 

 

 

 

Re: mod_smtpd design.

[Ben Laurie]

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.


Cheers,

Ben.

--
>>>ApacheCon Europe<<<   http://www.apachecon.com/

http://www.apache-ssl.org/ben.html   http://www.thebunker.net/

"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

Re: more mod_smtpd stuff [was Summer of Code]

[Paul Querna]

Rian Hunter wrote:


Jem Berkes wrote:


To address one of the points brought up on IRC, if there is actually a
non-experimental target for this software any time soon it would make
more sense to support the 2.0 server as I think few production servers
would be running 2.1?  I'm just speaking from what I saw, that is,
among my colleagues I do not know anyone who has tried Apache 2.1 yet.
 Many are still stuck at 1.3, but those people suck anyway :)



I think that deciding between 2.1 and 2.0 isn't a big deal since we 
can have source compatibility between them. You do make a good point 
when you mention all the poeple who still use 1.3. I think we should 
support 2.0, although (i'm not trying to sound negative) I'm pretty 
sure that most of the people that will be using mod_smtpd will be 
people writing specialized smtp setups (and running the latest httpd 
anyway) and not people who run production mail servers, even though 
mod_smtpd will be powerful enough to be a production mail server i 
just think sys admins are more stubborn about changing their mail 
server setup than the web server setup.

-rian



FWIW, your email to this mailing list was handle by Apache::Qsmtpd, 
running on Apache HTTPD 2.1.5:

http://asf.osuosl.org/server-status/

mod_perl + Apache::Qsmtpd.  It handles all incoming email for apache.org.

Don't discount the chances of someone running it in production very very 
soon.


It doesn't matter if it doesn't revolutionize the mail server market 
overnight and completely replace Qmail, but I think it would be pretty 
cool to hear it handled X million emails in a 24 hour period.


-Paul

more mod_smtpd stuff [was Summer of Code]

[Rian Hunter]

Jem Berkes wrote:

To address one of the points brought up on IRC, if there is actually a
non-experimental target for this software any time soon it would make
more sense to support the 2.0 server as I think few production servers
would be running 2.1?  I'm just speaking from what I saw, that is,
among my colleagues I do not know anyone who has tried Apache 2.1 yet.
 Many are still stuck at 1.3, but those people suck anyway :)


I think that deciding between 2.1 and 2.0 isn't a big deal since we can 
have source compatibility between them. You do make a good point when 
you mention all the poeple who still use 1.3. I think we should support 
2.0, although (i'm not trying to sound negative) I'm pretty sure that 
most of the people that will be using mod_smtpd will be people writing 
specialized smtp setups (and running the latest httpd anyway) and not 
people who run production mail servers, even though mod_smtpd will be 
powerful enough to be a production mail server i just think sys admins 
are more stubborn about changing their mail server setup than the web 
server setup.

-rian