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,
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,
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
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
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
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
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
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
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.
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
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
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
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
-
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
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 */
.
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
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
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
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
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
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))
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
* [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
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
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
/* 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 */
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
* 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
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
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
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
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
32 matches
Mail list logo
