mod_smtpd design.
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. Currently a session specific smtp data structure will have the fields: (string) (he|eh)lo argument (string) mail from argument (string) rctp to argument a module specific data structure wlil have the fields (table) supported smtp extensions (could be extended by other modules with ap_run_post_config()) (bool) smtp enabled? (string) server identifier (mod_smtpd by default) Since filters are something of great importance to mod_smtpd, i'm leaning toward keeping request_rec, and storing session specific data in r-request_conf, although I am very open to doing away with request_rec completely and definining new hooks (which also means adding new handler directives, eg. SetSmtpHandler). Anyone have any thoughts and additional comments/considerations? Here is a list of hooks i was thinking that mod_smtpd should call: ap_hook_auth_checker /* maybe this one after helo, mail from, rcpt to but before data */ ap_hook_create_request /* after the request_rec has been created */ ap_hook_fixups /* right before calling handler */ ap_hook_handler /* called to handle request or session */ ap_hook_insert_filter/* right before calling handler */ either ap_hook_auth_checker or a new hook we'll define for smtp (tentatively called envelope). that's still up in the air. If we go with the discarding request_rec design, basically we'll still call these logical hooks. Are there any complications I've overlooked? Any criticism or comments are very welcome!! -rian
more mod_smtpd stuff [was Summer of Code]
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
Re: more mod_smtpd stuff [was Summer of Code]
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
Re: mod_smtpd design.
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
mod_cache new directive
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: more mod_smtpd stuff [was Summer of Code]
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.
Re: mod_smtpd design.
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: HTTP Spoofing
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: HTTP Spoofing
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: mod_smtpd project planning
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: mod_smtpd project planning
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]
mmap / shm new design implementation ready.
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
shm design features
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 - RD.
Re: mod_smtpd design.
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
Re: mod_smtpd design.
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.
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
[PATCH] new proxy hook 2.1
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
Subrequests, keepalives, mod_proxy in 2.1
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
Re: mod_smtpd design.
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
Re: mod_smtpd design.
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.
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.
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: svn commit: r208777 - /httpd/httpd/trunk/include/ap_mmn.h
* [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: svn commit: r208777 - /httpd/httpd/trunk/include/ap_mmn.h
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
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
NOTE To All Dev's!!!
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: Subrequests, keepalives, mod_proxy in 2.1
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 --
Re: svn commit: r208777 - /httpd/httpd/trunk/include/ap_mmn.h
* 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 http://pub.perlig.de/books.html#apache2
Re: NOTE To All Dev's!!!
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: NOTE To All Dev's!!!
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: svn commit: r208777 - /httpd/httpd/trunk/include/ap_mmn.h
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: current-testers, stable-testers
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
