Re: New mod_smtpd release
> Well there's also another problem. RFC 2821 (SMTP) doesn't define a > particular message format for SMTP (in wide use there the RFC 822 and > MIME message formats). I don't think that mod_smtpd should assume a RFC > 822 or MIME message format since its strictly a SMTP module, that's why I agree with this > I still think header parsing should be in another module. Of course > this module is free to register itself as an mod_smtpd filter and do > what it needs to do, but it shouldn't be part of the main mod_smtpd. That seems wise. Any weird thing can come through over SMTP, it could look very much unlike an email after all. You're handling the protocol in your module and that means the SMTP protocol as I understand, not MIME or anything.
Re: New mod_smtpd release
On Aug 12, 2005, at 5:57 PM, Rian Hunter wrote: This version of mod_smtpd is callback based, very similar to Qpsmtpd. Here is a list of all the hooks you can register: That's a beautiful cycle. When I added the plugin/extension/hook system to qpsmtpd way back when I borrowed many concepts from the httpd module system. :-) - ask -- http://www.askbjoernhansen.com/
Re: [PATCH] use arrays in smtpd_request_rec (was Re: smtpd_request_rec questions)
Rian Hunter wrote: This patch looks good but I have some questions. You seem to use the returned pointers from apr_array_push without checking if they are NULL. Even in apr_array_push, apr_palloc is used without checking for NULL even though apr_palloc can definitely return NULL. Because of that, I'm not sure whether or not you don't check for NULL on purpose. Could you explain? Thanks. Well, it depends on what your general attitude towards checking for errors in memory allocation. In many projects it's generally considered to be the kind of error you can't effectively recover from anyway, so cluttering up the code with if (foo == NULL) checks is kind of pointless, you're likely to have been killed by a kernel OOM checker before that can do anything useful, or you could be on an OS that doesn't even return NULL (memory overcommit), so the checks are pointless anyway. The only way to be safe is to make sure that algorithmicly your program can't allocate unbounded amounts of memory, then tune your box and app so that this kind of problem doesn't happen in practice. APR generally doesn't bother checking for this kind of error for just this reason, same with Subversion and if I'm not mistaken Apache HTTPD itself. -garrett
Re: New mod_smtpd release
Rian Hunter <[EMAIL PROTECTED]> writes: >> The request_rec slot can be NULL for connection-level filters. >> But I'd create a request_rec sometime before I added an smtp protocol >> filter, which would just do the "."-decoding, similar to how >> http_in deals with TE. >> > > Yeah I agree. I'd be more than happy to work on the filters for mod_smtpd if you want to delegate that task. -- Joe Schaefer
Re: [PATCH] use arrays in smtpd_request_rec (was Re: smtpd_request_rec questions)
This patch looks good but I have some questions. You seem to use the
returned pointers from apr_array_push without checking if they are
NULL. Even in apr_array_push, apr_palloc is used without checking for
NULL even though apr_palloc can definitely return NULL.
Because of that, I'm not sure whether or not you don't check for NULL
on purpose. Could you explain? Thanks.
-rian
On Aug 14, 2005, at 8:52 PM, Garrett Rooney wrote:
Garrett Rooney wrote:
Rian Hunter wrote:
Ah I didn't even realize the key allocation, I'll fix that. Thanks!
The reason I don't use an apr_array_t or similar is that I
thought that the number of elements in that type has to be fixed
and can't be automatically extended and allocated on the fly, If
I'm wrong I can change these structures to use apr_array_t (or
you can send in a patch if you like).
APR arrays are variable length, you use apr_array_push and
apr_array_pop to add and remove entries. I'll throw together the
patch sometime today.
And here's the patch. This is totally untested, since I haven't
yet gotten around to making mod_smtpd do anything other than
compile yet, but it's pretty simple and should give you an idea of
what I meant.
-garrett
* mod_smtpd.h
(smtpd_request_rec::e_index,
smtpd_request_rec::r_index): removed.
(smtpd_request_rec::extensions,
smtpd_request_rec::rcpt_to): change from a hash to an array.
* smtp_core.c
(smtpd_register_extension): push the extension onto the array.
(smtpd_clear_request_rec): allocate the new arrays.
* smtp_protocol.c
(helo): remove ext and ext_next variables, iterate over the array
instead of doing backflips to iterate over the hash.
(rcpt): remove new_elt variable, just push the rcpt address onto
the array.
Index: mod_smtpd.h
===
--- mod_smtpd.h(revision 232680)
+++ mod_smtpd.h(working copy)
@@ -90,16 +90,13 @@
// by default smtp
smtpd_protocol_type extended;
-// current max index of the extension hash
-int e_index;
-apr_hash_t *extensions;
+apr_array_header_t *extensions;
// string of who this mail is from
char *mail_from;
-// current max index of the rcpt_to hash
-int r_index;
-apr_hash_t *rcpt_to;
+apr_array_header_t *rcpt_to;
+
// hostname we were helo'd with
char *helo;
} smtpd_request_rec;
Index: smtp_protocol.c
===
--- smtp_protocol.c(revision 232680)
+++ smtp_protocol.c(working copy)
@@ -121,7 +121,6 @@
HANDLER_DECLARE(ehlo) {
int i = 0, retval = 0;
- char *ext = NULL, *ext_next;
smtpd_request_rec *sr = smtpd_get_request_rec(r);
if (buffer[0] == '\0') {
@@ -161,21 +160,13 @@
}
// print out extension
- ext = apr_hash_get(sr->extensions, &i, sizeof(i));
retval = 250;
- if (ext) {
+ if (sr->extensions->nelts) {
ap_rprintf(r, "%d-%s\r\n", 250, sr->helo);
-
-while (1) {
- i++;
- if ((ext_next = apr_hash_get(sr->extensions, &i, sizeof(i {
-ap_rprintf(r, "%d-%s\r\n", 250, ext);
- } else {
-ap_rprintf(r, "%d %s\r\n", 250, ext);
-break;
- }
- ext = ext_next;
+
+for (i = 0; i < sr->extensions->nelts; ++i) {
+ ap_rprintf(r, "%d-%s\r\n", 250, ((char **)sr->extensions-
>nelts)[i]);
}
} else {
ap_rprintf(r, "%d %s\r\n", 250, sr->helo);
@@ -344,7 +335,6 @@
char *loc;
char *allocated_string;
int retval = 0;
- int *new_elt;
// need mail first
if ((sr->state_vector != SMTPD_STATE_GOT_MAIL) &&
@@ -413,19 +403,8 @@
// add a recipient
if ((allocated_string = apr_pstrdup(sr->p, loc))) {
-new_elt = apr_palloc(sr->p, sizeof(int));
+(*((char **)apr_array_push(sr->rcpt_to))) = allocated_string;
-if (!new_elt) {
- ap_rprintf(r, "%d %s\r\n", 421, "Error: Internal");
- // out of memory close connection
- retval = 0;
- goto end;
-}
-
-*new_elt = sr->r_index;
-apr_hash_set(sr->rcpt_to, new_elt,
- sizeof(*new_elt), allocated_string);
-sr->r_index++;
sr->state_vector = SMTPD_STATE_GOT_RCPT;
ap_rprintf(r, "%d %s\r\n", 250, "Ok");
Index: smtp_core.c
===
--- smtp_core.c(revision 232680)
+++ smtp_core.c(working copy)
@@ -127,11 +127,7 @@
SMTPD_DECLARE_NONSTD(void)
smtpd_register_extension(smtpd_request_rec *sr, const char *line)
{
- int *cur = apr_palloc(sr->p, sizeof(int));
- *cur = sr->e_index;
-
- apr_hash_set(sr->extensions, cur, sizeof(*cur), line);
- (sr->e_index)++;
+ (*((char **)apr_array_push(sr->extensions))) = apr_pstrdup(sr-
>p, line);
}
// how to reset the transaction
@@ -154,10 +150,8 @@
sr->state_vector = SMTPD_STATE_GOT_NOTHING;
sr->tfp = NULL;
sr->extended = SMTPD_PROTOCOL_SMTP;
- sr->e_index = 0;
- sr->extensions = apr_hash_make(sr->p);
- sr->r_index = 0;
- sr->rcpt_to = apr_has
Re: New mod_smtpd release
On Aug 14, 2005, at 8:12 PM, Joe Schaefer wrote: Rian Hunter <[EMAIL PROTECTED]> writes: On Aug 14, 2005, at 1:22 PM, Joe Schaefer wrote: +RELEASE SHOWSTOPPERS: + + + smtp_process_connection_internal should take a "smtp_proto_rec" + argument (which is what the current "smtp_request_rec" struct + should be renamed to). I can easily rename smtpd_request_rec but I don't think I should pass it to smtpd_process_connection internal only because the hooks take a request_rec*. The hooks can still take a request_rec, but IMO the protocol's state management shouldn't be done from a request_rec. I'd still like to see one request correspond to one MAIL FROM/RCPT TO/DATA sequence, so that whenever the state gets reset, the whole request_rec pool gets cleaned up. This make sense. smtpd_request_rec does what you say. After looking at smtp_core.c it seems that request_rec isn't really something needed for mod_smtpd (and really never was). After figuring out the input filters situation, i'll probably do away with request_rec (since it isn't needed for connection-level filters) and just stick to smtpd_proto_rec. Any objections? They need request_rec to use filters (even though i don't currently enable convenient use of filters yet). The request_rec slot can be NULL for connection-level filters. But I'd create a request_rec sometime before I added an smtp protocol filter, which would just do the "."-decoding, similar to how http_in deals with TE. Yeah I agree. Ideally header parsing should be done in an mod_smtpd plugin not in mod_smtpd. I respectfully disagree, because I'd like different hooks to have increasing state information available to them through the request_rec. In particular I'd like to see the smtp filtering API match httpd, by first parsing the headers, but passing the rest of the data through r->input_filters, with smtp_in translating the final "." line into an EOS bucket. Well there's also another problem. RFC 2821 (SMTP) doesn't define a particular message format for SMTP (in wide use there the RFC 822 and MIME message formats). I don't think that mod_smtpd should assume a RFC 822 or MIME message format since its strictly a SMTP module, that's why I still think header parsing should be in another module. Of course this module is free to register itself as an mod_smtpd filter and do what it needs to do, but it shouldn't be part of the main mod_smtpd. The modules that will specifically rely on this header parsing module will know how to obtain the header information using the conventions specified by that parsing module. -rian
[PATCH] use arrays in smtpd_request_rec (was Re: smtpd_request_rec questions)
Garrett Rooney wrote:
Rian Hunter wrote:
Ah I didn't even realize the key allocation, I'll fix that. Thanks!
The reason I don't use an apr_array_t or similar is that I thought
that the number of elements in that type has to be fixed and can't be
automatically extended and allocated on the fly, If I'm wrong I can
change these structures to use apr_array_t (or you can send in a
patch if you like).
APR arrays are variable length, you use apr_array_push and apr_array_pop
to add and remove entries. I'll throw together the patch sometime today.
And here's the patch. This is totally untested, since I haven't yet
gotten around to making mod_smtpd do anything other than compile yet,
but it's pretty simple and should give you an idea of what I meant.
-garrett
* mod_smtpd.h
(smtpd_request_rec::e_index,
smtpd_request_rec::r_index): removed.
(smtpd_request_rec::extensions,
smtpd_request_rec::rcpt_to): change from a hash to an array.
* smtp_core.c
(smtpd_register_extension): push the extension onto the array.
(smtpd_clear_request_rec): allocate the new arrays.
* smtp_protocol.c
(helo): remove ext and ext_next variables, iterate over the array
instead of doing backflips to iterate over the hash.
(rcpt): remove new_elt variable, just push the rcpt address onto
the array.
Index: mod_smtpd.h
===
--- mod_smtpd.h (revision 232680)
+++ mod_smtpd.h (working copy)
@@ -90,16 +90,13 @@
// by default smtp
smtpd_protocol_type extended;
-// current max index of the extension hash
-int e_index;
-apr_hash_t *extensions;
+apr_array_header_t *extensions;
// string of who this mail is from
char *mail_from;
-// current max index of the rcpt_to hash
-int r_index;
-apr_hash_t *rcpt_to;
+apr_array_header_t *rcpt_to;
+
// hostname we were helo'd with
char *helo;
} smtpd_request_rec;
Index: smtp_protocol.c
===
--- smtp_protocol.c (revision 232680)
+++ smtp_protocol.c (working copy)
@@ -121,7 +121,6 @@
HANDLER_DECLARE(ehlo) {
int i = 0, retval = 0;
- char *ext = NULL, *ext_next;
smtpd_request_rec *sr = smtpd_get_request_rec(r);
if (buffer[0] == '\0') {
@@ -161,21 +160,13 @@
}
// print out extension
- ext = apr_hash_get(sr->extensions, &i, sizeof(i));
retval = 250;
- if (ext) {
+ if (sr->extensions->nelts) {
ap_rprintf(r, "%d-%s\r\n", 250, sr->helo);
-
-while (1) {
- i++;
- if ((ext_next = apr_hash_get(sr->extensions, &i, sizeof(i {
- ap_rprintf(r, "%d-%s\r\n", 250, ext);
- } else {
- ap_rprintf(r, "%d %s\r\n", 250, ext);
- break;
- }
- ext = ext_next;
+
+for (i = 0; i < sr->extensions->nelts; ++i) {
+ ap_rprintf(r, "%d-%s\r\n", 250, ((char **)sr->extensions->nelts)[i]);
}
} else {
ap_rprintf(r, "%d %s\r\n", 250, sr->helo);
@@ -344,7 +335,6 @@
char *loc;
char *allocated_string;
int retval = 0;
- int *new_elt;
// need mail first
if ((sr->state_vector != SMTPD_STATE_GOT_MAIL) &&
@@ -413,19 +403,8 @@
// add a recipient
if ((allocated_string = apr_pstrdup(sr->p, loc))) {
-new_elt = apr_palloc(sr->p, sizeof(int));
+(*((char **)apr_array_push(sr->rcpt_to))) = allocated_string;
-if (!new_elt) {
- ap_rprintf(r, "%d %s\r\n", 421, "Error: Internal");
- // out of memory close connection
- retval = 0;
- goto end;
-}
-
-*new_elt = sr->r_index;
-apr_hash_set(sr->rcpt_to, new_elt,
- sizeof(*new_elt), allocated_string);
-sr->r_index++;
sr->state_vector = SMTPD_STATE_GOT_RCPT;
ap_rprintf(r, "%d %s\r\n", 250, "Ok");
Index: smtp_core.c
===
--- smtp_core.c (revision 232680)
+++ smtp_core.c (working copy)
@@ -127,11 +127,7 @@
SMTPD_DECLARE_NONSTD(void)
smtpd_register_extension(smtpd_request_rec *sr, const char *line)
{
- int *cur = apr_palloc(sr->p, sizeof(int));
- *cur = sr->e_index;
-
- apr_hash_set(sr->extensions, cur, sizeof(*cur), line);
- (sr->e_index)++;
+ (*((char **)apr_array_push(sr->extensions))) = apr_pstrdup(sr->p, line);
}
// how to reset the transaction
@@ -154,10 +150,8 @@
sr->state_vector = SMTPD_STATE_GOT_NOTHING;
sr->tfp = NULL;
sr->extended = SMTPD_PROTOCOL_SMTP;
- sr->e_index = 0;
- sr->extensions = apr_hash_make(sr->p);
- sr->r_index = 0;
- sr->rcpt_to = apr_hash_make(sr->p);
+ sr->extensions = apr_array_make(sr->p, 5, sizeof(char *));
+ sr->rcpt_to = apr_array_make(sr->p, 5, sizeof(char *));
sr->mail_from = NULL;
sr->helo = NULL;
}
Re: smtpd_request_rec questions
Rian Hunter wrote: Ah I didn't even realize the key allocation, I'll fix that. Thanks! The reason I don't use an apr_array_t or similar is that I thought that the number of elements in that type has to be fixed and can't be automatically extended and allocated on the fly, If I'm wrong I can change these structures to use apr_array_t (or you can send in a patch if you like). APR arrays are variable length, you use apr_array_push and apr_array_pop to add and remove entries. I'll throw together the patch sometime today. -garrett
Re: smtpd_request_rec questions
On Aug 14, 2005, at 4:21 PM, Garrett Rooney wrote: I was just looking at the smtpd_request_rec in mod_smtpd, and I had a few questions. It seems that extensions and rcpt info is being stored in an apr_hash_t, but it's only being keyed by integer. If you're only going to use ints as keys, it seems like an apr_array_header_t would be more appropriate. Also, while the extensions has is specifically allocating its keys, the rcpt_to hash is reusing the r_index variable each time, so if more than one entry is added things aren't going to work, since that location in memory is having its value changed after its been used as a key. Anyway, I'd be happy to produce patches to either switch to an array or fix the key issue in the rcpt_to section, depending on which way we want to go. Personally, I'd prefer the array version though. -garrett Ah I didn't even realize the key allocation, I'll fix that. Thanks! The reason I don't use an apr_array_t or similar is that I thought that the number of elements in that type has to be fixed and can't be automatically extended and allocated on the fly, If I'm wrong I can change these structures to use apr_array_t (or you can send in a patch if you like). -rian
Re: New mod_smtpd release
Rian Hunter <[EMAIL PROTECTED]> writes: > On Aug 14, 2005, at 1:22 PM, Joe Schaefer wrote: >> +RELEASE SHOWSTOPPERS: >> + >> + >> + smtp_process_connection_internal should take a "smtp_proto_rec" >> + argument (which is what the current "smtp_request_rec" struct >> + should be renamed to). >> > I can easily rename smtpd_request_rec but I don't think I should pass > it to smtpd_process_connection internal only because the hooks take a > request_rec*. The hooks can still take a request_rec, but IMO the protocol's state management shouldn't be done from a request_rec. I'd still like to see one request correspond to one MAIL FROM/RCPT TO/DATA sequence, so that whenever the state gets reset, the whole request_rec pool gets cleaned up. > They need request_rec to use filters (even though i > don't currently enable convenient use of filters yet). The request_rec slot can be NULL for connection-level filters. But I'd create a request_rec sometime before I added an smtp protocol filter, which would just do the "."-decoding, similar to how http_in deals with TE. [...] > Ideally header parsing should be done in an mod_smtpd plugin not in > mod_smtpd. I respectfully disagree, because I'd like different hooks to have increasing state information available to them through the request_rec. In particular I'd like to see the smtp filtering API match httpd, by first parsing the headers, but passing the rest of the data through r->input_filters, with smtp_in translating the final "." line into an EOS bucket. -- Joe Schaefer
Re: mod_smtpd compile problem
On Aug 14, 2005, at 2:05 PM, Garrett Rooney wrote: So I'm having a little trouble getting mod_smtpd to compile, once I fixed up the configure script to find apxs and apache correctly, I end up with the following error: $ make /usr/bin/apxs2 -Wc,"-Wall" -o mod_smtpd.la -c smtp_core.c smtp_protocol.c /usr/bin/libtool --silent --mode=compile gcc -prefer-pic -pipe -I/ usr/include/xmltok -I/usr/include/openssl -Wall -O2 - DAP_HAVE_DESIGNATED_INITIALIZER -DLINUX=2 -D_REENTRANT - D_XOPEN_SOURCE=500 -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -pipe -I/usr/include/xmltok -I/usr/include/openssl -Wall -O2 -pthread -I/ usr/include/apache2 -I/usr/include/apr-0 -I/usr/include/apr-0 -I/ usr/include -Wall -c -o smtp_core.lo smtp_core.c && touch smtp_core.slo smtp_core.c: In function `register_hooks': smtp_core.c:348: error: `default_queue' undeclared (first use in this function) smtp_core.c:348: error: (Each undeclared identifier is reported only once smtp_core.c:348: error: for each function it appears in.) smtp_core.c:349: error: `default_rcpt' undeclared (first use in this function) apxs:Error: Command failed with rc=65536 . make: *** [mod_smtpd.la] Error 1 Sorry I removed one part of code and not the other. -rian
Re: New mod_smtpd release
On Aug 14, 2005, at 1:22 PM, Joe Schaefer wrote: snip... +CURRENT RELEASE NOTES: + + Virtual hosts a'la mod_ftpd don't work. It does work like this: Listen 80 Listen 25 NameVirtualHost *:80 NameVirtualHost *:25 ServerName localhost DocumentRoot htdocs ServerName localhost SmtpProtocol On no? +RELEASE SHOWSTOPPERS: + + + smtp_process_connection_internal should take a "smtp_proto_rec" argument + (which is what the current "smtp_request_rec" struct should be renamed to). I can easily rename smtpd_request_rec but I don't think I should pass it to smtpd_process_connection internal only because the hooks take a request_rec*. They need request_rec to use filters (even though i don't currently enable convenient use of filters yet). Unless I add a member to smtpd_proto_rec that is a pointer to the related request_rec (solely so filters can work) and use smtpd_proto_rec as the main structure. + +CURRENT VOTES: + + +TODO ISSUES: + + The request i/o is driven around ap_rgetline, when it really + should be using input filters. I have to look a little more into this. +WISH LIST: + + Link against libapreq2 so we can use its header and multipart parsers. + apreq's header parser would help in implementing rfc2821 loop- detection, + and in providing the header collection as r->headers_in for "data" + hooks to examine. Ideally header parsing should be done in an mod_smtpd plugin not in mod_smtpd. -rian
Bug report for Apache httpd-2.0 [2005/08/14]
+---+ | Bugzilla Bug ID | | +-+ | | Status: UNC=Unconfirmed NEW=New ASS=Assigned| | | OPN=ReopenedVER=Verified(Skipped Closed/Resolved) | | | +-+ | | | Severity: BLK=Blocker CRI=CriticalMAJ=Major | | | | MIN=Minor NOR=Normal ENH=Enhancement | | | | +-+ | | | | Date Posted | | | | | +--+ | | | | | Description | | | | | | | | 7483|Ass|Enh|2002-03-26|Add FileAction directive to assign a cgi interpret| | 7741|Ass|Nor|2002-04-04|some directives may be placed outside of proper co| | 7862|New|Enh|2002-04-09|suexec never log a group name.| | 8483|Inf|Min|2002-04-24|apache_2.0 .msi installer breaks .log and .conf fi| | 8713|New|Min|2002-05-01|No Errorlog on PROPFIND/Depth:Infinity| | 8925|New|Cri|2002-05-09|Service Install (win32 .msi/.exe) fails for port i| | 9727|New|Min|2002-06-09|Double quotes should be flagged as T_HTTP_TOKEN_ST| | 9903|Opn|Maj|2002-06-16|mod_disk_cache does not remove temporary files| | 9945|New|Enh|2002-06-18|[PATCH] new funtionality for apache bench | |10114|Ass|Enh|2002-06-21|Negotiation gives no weight to order, only q value| |10154|Ass|Nor|2002-06-23|ApacheMonitor interferes with service uninstall/re| |10722|Opn|Nor|2002-07-12|ProxyPassReverse doesn't change cookie paths | |10775|Ass|Cri|2002-07-13|SCRIPT_NAME wrong value | |10932|Opn|Enh|2002-07-18|Allow Negative regex in LocationMatch | |11035|New|Min|2002-07-22|Apache adds double entries to headers generated by| |11294|New|Enh|2002-07-30|desired vhost_alias option| |11427|Opn|Maj|2002-08-02|Possible Memory Leak in CGI script invocation | |11540|Opn|Nor|2002-08-07|ProxyTimeout ignored | |11580|Opn|Enh|2002-08-09|generate Content-Location headers | |11971|Opn|Nor|2002-08-23|HTTP proxy header "Via" with wrong hostname if Ser| |11997|Opn|Maj|2002-08-23|Strange critical errors possibly related to mpm_wi| |12033|Opn|Nor|2002-08-26|Graceful restart immidiately result in [warn] long| |12340|Opn|Nor|2002-09-05|WindowsXP proxy, child process exited with status | |12355|Opn|Nor|2002-09-06|SSLVerifyClient directive in location make post to| |12680|New|Enh|2002-09-16|Digest authentication with integrity protection | |12885|New|Enh|2002-09-20|windows 2000 build information: mod_ssl, bison, et| |13029|New|Nor|2002-09-26|Win32 mod_cgi failure with non-ASCII characters in| |13101|Inf|Cri|2002-09-27|Using mod_ext_filter with mod_proxy and http/1.1 c| |13507|New|Enh|2002-10-10|capturing stderr from mod_cgi | |13577|New|Maj|2002-10-13|mod_proxy mangles query string with mod_rewrite | |13599|Ass|Nor|2002-10-14|autoindex formating broken for multibyte sequences| |13603|New|Nor|2002-10-14|incorrect DOCUMENT_URI in mod_autoindex with Heade| |13661|Ass|Enh|2002-10-15|Apache cannot not handle dynamic IP reallocation | |13946|Inf|Nor|2002-10-24|reverse proxy errors when a document expires from | |13986|Ass|Enh|2002-10-26|remove default MIME-type | |14016|Inf|Nor|2002-10-28|Problem when using mod_ext_filter with ActivePerl | |14090|New|Maj|2002-10-30|mod_cgid always writes to main server error log | |14206|New|Nor|2002-11-04|DirectoryIndex circumvents -FollowSymLinks option | |14227|Ass|Nor|2002-11-04|Error handling script is not started (error 500) o| |14335|Opn|Enh|2002-11-07|AddOutputFilterByType doesn't work with proxy requ| |14496|New|Enh|2002-11-13|Cannot upgrade 2.0.39 -> 2.0.43. Must uninstall fi| |14556|Inf|Nor|2002-11-14|mod_cache with mod_mem_cache enabled doesnt cash m| |14750|Inf|Maj|2002-11-21|Windows 9x: apr_socket_opt_set cannot set SO_KEEPA| |14858|New|Enh|2002-11-26|mod_cache never caches responses for requests requ| |14922|Ass|Enh|2002-11-28| is currently hardcoded to 'apache2' | |15045|Ass|Nor|2002-12-04|addoutputfilterbytype doesn't work for defaulted t| |15221|New|Nor|2002-12-10|reference to old script: sign.sh | |15233|Opn|Nor|2002-12-10|move AddType application/x-x509-ca-cert from ssl.c| |15235|New|Nor|2002-12-10|add application/x-x509-email-cert, application/x-x| |15625|New|Nor|2002-12-23|mention mod_ssl in http://nagoya.apache.org/dist/h| |15626|New|Nor|2002-12-23|mention which modules are part of the (binary) dis| |15631|New|Nor|
Bug report for Apache httpd-1.3 [2005/08/14]
+---+ | Bugzilla Bug ID | | +-+ | | Status: UNC=Unconfirmed NEW=New ASS=Assigned| | | OPN=ReopenedVER=Verified(Skipped Closed/Resolved) | | | +-+ | | | Severity: BLK=Blocker CRI=CriticalMAJ=Major | | | | MIN=Minor NOR=Normal ENH=Enhancement | | | | +-+ | | | | Date Posted | | | | | +--+ | | | | | Description | | | | | | | | 8329|New|Nor|2002-04-20|mime_magic gives 500 and no error_log on Microsoft| | 8372|Ass|Nor|2002-04-22|Threadsaftey issue in Rewrite's cache [Win32/OS2/N| | 8849|New|Nor|2002-05-07|make install errors as root on NFS shares | | 8882|New|Enh|2002-05-07|[PATCH] mod_rewrite communicates with external rew| | 9037|New|Min|2002-05-13|Slow performance when acessing an unresolved IP ad| | 9126|New|Blk|2002-05-15|68k-next-openstep v. 4.0 | | 9726|New|Min|2002-06-09|Double quotes should be flagged as T_HTTP_TOKEN_ST| | 9894|New|Maj|2002-06-16|getline sub in support progs collides with existin| | |New|Nor|2002-06-19|Incorrect default manualdir value with layout.| |10038|New|Min|2002-06-20|ab benchmaker hangs on 10K https URLs with keepali| |10073|New|Maj|2002-06-20|upgrade from 1.3.24 to 1.3.26 breaks include direc| |10169|New|Nor|2002-06-24|Apache seg faults due to attempt to access out of | |10178|New|Maj|2002-06-24|Proxy server cuts off begining of buffer when spec| |10195|New|Nor|2002-06-24|Configure script erroneously detects system Expat | |10199|New|Nor|2002-06-24|Configure can't handle directory names with unders| |10243|New|Maj|2002-06-26|CGI scripts not getting POST data | |10354|New|Nor|2002-06-30|ErrorDocument(.htaccess) fails when passed URL wit| |10446|Opn|Blk|2002-07-03|spaces in link to http server seen as foreign char| |10470|New|Cri|2002-07-04|proxy module will not correctly serve mixed case f| |10666|New|Enh|2002-07-10|line-end comment error message missing file name | |10744|New|Nor|2002-07-12|suexec might fail to open log file| |10747|New|Maj|2002-07-12|ftp SIZE command and 'smart' ftp servers results i| |10760|New|Maj|2002-07-12|empty ftp directory listings from cached ftp direc| |10939|New|Maj|2002-07-18|directory listing errors | |11020|New|Maj|2002-07-21|APXS only recognise tests made by ./configure | |11236|New|Min|2002-07-27|Possible Log exhaustion bug? | |11265|New|Blk|2002-07-29|mod_rewrite fails to encode special characters| |11765|New|Nor|2002-08-16|.apaci.install.tmp installs in existing httpd.conf| |11986|New|Nor|2002-08-23|Restart hangs when piping logs on rotation log pro| |12096|New|Nor|2002-08-27|apxs does not handle binary dists installed at non| |12574|New|Nor|2002-09-12|Broken images comes from mod_proxy when caching ww| |12583|New|Nor|2002-09-12|First piped log process do not handle SIGTERM | |12598|Opn|Maj|2002-09-12|Apache hanging in Keepalive State | |13188|New|Nor|2002-10-02|does not configure correctly for hppa64-hp-hpux11.| |13274|Ass|Nor|2002-10-04|Subsequent requests are destroyed by the request e| |13607|Opn|Enh|2002-10-14|Catch-all enhancement for vhost_alias?| |13687|New|Min|2002-10-16|Leave Debug symbol on Darwin | |13822|New|Maj|2002-10-21|Problem while running Perl modules accessing CGI::| |14095|Opn|Nor|2002-10-30|Change default Content-Type (DefaultType) in defau| |14250|New|Maj|2002-11-05|Alternate UserDirs don't work intermittantly | |14443|New|Maj|2002-11-11|Keep-Alive randomly causes TCP RSTs | |14448|Opn|Cri|2002-11-11|Apache WebServer not starting if installed on Comp| |14518|Opn|Nor|2002-11-13|QUERY_STRING parts not incorporated by mod_rewrite| |14670|New|Cri|2002-11-19|Apache didn't deallocate unused memory| |14748|New|Nor|2002-11-21|Configure Can't find DBM on Mac OS X | |15011|New|Nor|2002-12-03|Apache processes not timing out on Solaris 8 | |15028|New|Maj|2002-12-03|RedirectMatch does not escape properly| |15242|New|Blk|2002-12-10|mod_cgi prevents handling of OPTIONS request | |16236|New|Maj|2003-01-18|Include directive in Apache is not parsed within c| |16241|New|Maj|2003-01-19|Apache processes takes 100% CPU until killed manua| |16492|New|Maj|2003-01-28|mod_proxy doesn't correctly retrieve values from C| |16493|
Re: svn commit: r230592 - in /httpd/httpd/branches/2.0.x: CHANGES STATUS modules/proxy/proxy_http.c
On 8/6/05, William A. Rowe, Jr. <[EMAIL PROTECTED]> wrote: > At 08:39 PM 8/6/2005, Jeff Trawick wrote: > >On 8/6/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > >> Author: wrowe > >> Date: Sat Aug 6 14:29:05 2005 > >> New Revision: 230592 > >> > >> URL: http://svn.apache.org/viewcvs?rev=230592&view=rev > >> Log: > >> > >> As much as it pains me, seriously, it seems that reviewing the re-backport > >> of this code was too illegible for review, so it seems we will need to > >> re-review a fresh backport from httpd trunk. > > > >It looks to me that we have lost our second of two chances to go > >through a stepwise, single-problem/single-solution approach to > >resolving the issues with this code, even after multiple comments > >stating that mixing that set of changes was undesired. It isn't > >impossible to move forward from this point, but I don't understand why > >we're still in big-patch mode after those previous comments. > > Hold on a second ;-) Are you suggesting this original backport > patch was 'small' enough for review? I didn't realize we were talking about the original backport. I recall talking about a number of other seemingly-independent fixes which were rolled together and which at least a couple of people asked to be split up. If during the original backport review somebody had asked me to split up changes to solve one problem at a time, I think I would have worked hard to do that. Small enough for review is easy to determine empirically. > I'd challenge that > the reasons > why the errors were not caught was that the original backport was the > patch that was too large, and there simply weren't enough eyeballs > on it (no insult intended; you know how many iterations my later > changes went through.) no insult taken > The other side of the coin, however, is that all agree the old code > in proxy_http is horribly broken. If we agree trunk/ both behaves > correctly and is now more legible, shouldn't we put far more trust > in the code on trunk/ than the cruft in 2.0.x? last time I played with proxy on trunk I got a crash down in apr_reslist_something ;) as a matter of fact I don't have a lot of trust > I'm suggesting that the review should have occurred commit-by-commit > on trunk (C-t-R). The entire history of these changes is sitting > on trunk, with all the wrinkles from the beginning of the effort. > > Since we have little faith that sufficient 'R' occurred as we moved > through each bit of your and my efforts, perhaps it's too much to > ask people to have faith in the resulting backport. > > If I have folks look at each 'little piece', I'm happy to 'precommit' > each of the side-effects (reformatting, apr_natstrcasecmp, etc) in > separate commits that make the end-result patch easier to read. > > But the bottom line; do you really want me to hand a "STACK" of > patches representing each of these changes, which will inevitable > not apply cleanly unless layered in a specific order (and even then...) > > What if I take Joe's breakdown of issues and ask for each of them to > have a separate vote (without individual patch files, the main patch > file can be used to see 'what will change') and the moment we have > 3 +1's I'll commit that small layer, making the final, harry refactor > patch of the body stream/spool code just a wee bit easier to read. > Does this appeal to everyone? makes sense > Forgive me if I've been humorless about this; already pointed out > I had burned 60, maybe 80 hours of my early summer on this mess, > all because, when I added proxy trace and tried to actually send > bodies, the proxy request body processing would simply hang on > the back end because the proxied request was simply mishandled. > Apache 1.3? Was close. Apache 2.1? Even closer. 2.0.x - blah. > Fixing one small quirk would point out yet another until various > bits of the code looked nothing as they had started as. This seems a lot like business as usual to me. Anybody working on 2.x (or any big project) for a while has been through this countless times. What do you do? a) Figure everything necessary to get the darn thing working. b) for each independent fix that can be extracted, work just that fix through the system c) you're likely left with a larger-than-average fix (a set of changes which make no sense without everything else in the set) > I'll do my best to put on a smile and slog through the 'correct' > solution in a manner 'agreeable' to both you and Joe :) If you have enough +1s from other folks, you can remove me from the list and I will trust the collective +1s. In a situation where there were not such approvals, and I wanted to play a constructive role, I asked/complained/whatever for the changes to be submitted in a manner that I thought I could constructively participate with.
Murky decalrations/types in apreq_param.h
It's currently impossible to compile apache modules using libabreq2
with c++ compilers due to some inconsistent types in file apreq_param.h.
Here are the error messages:
In file included from /usr/include/apreq2/apreq_parser.h:21,
from /usr/include/apreq2/apreq_module.h:21,
from /usr/include/apache2/apreq2/apreq_module_apache2.h:20,
from mod_xapian.h:41,
from mod_xapian.cc:34:
/usr/include/apreq2/apreq_param.h: In function `apreq_charset_t
apreq_param_charset_set(apreq_param_t*, unsigned char)':
/usr/include/apreq2/apreq_param.h:67: error: cannot convert `unsigned char' to
`apreq_charset_t' in return
/usr/include/apreq2/apreq_param.h: In function `apreq_charset_t
apreq_param_charset_get(apreq_param_t*)':
/usr/include/apreq2/apreq_param.h:73: error: invalid conversion from `unsigned
int' to `apreq_charset_t'
Function apreq_param_charset_set does:
unsigned char old = APREQ_FLAGS_GET(p->flags, APREQ_CHARSET);
ans later on returns 'old' even so the return value of the function is
declared as 'apreq_charset_t' which is of type enum (in c++
typedef'ed enums create distinct types that can't be casted from
integral types). Since 'old' is actually _never touched_ in this
function there seems to be no reason not to do it as follows:
/** Sets the character encoding for this parameter. */
static APR_INLINE
apreq_charset_t apreq_param_charset_set(apreq_param_t *p, unsigned char c) {
apreq_charset_t old = (apreq_charset_t) APREQ_FLAGS_GET(p->flags,
APREQ_CHARSET); APREQ_FLAGS_SET(p->flags, APREQ_CHARSET, c); return
old;
}
Further on, in function 'apreq_param_charset_get(apreq_param_t*)' it would
be nice to expicitly cast the return value to the correct type:
/** Gets the character encoding for this parameter. */
static APR_INLINE
apreq_charset_t apreq_param_charset_get(apreq_param_t *p) {
return (enum apreq_charset_t) APREQ_FLAGS_GET(p->flags, APREQ_CHARSET);
}
Cheers Ralf Mattes
smtpd_request_rec questions
I was just looking at the smtpd_request_rec in mod_smtpd, and I had a few questions. It seems that extensions and rcpt info is being stored in an apr_hash_t, but it's only being keyed by integer. If you're only going to use ints as keys, it seems like an apr_array_header_t would be more appropriate. Also, while the extensions has is specifically allocating its keys, the rcpt_to hash is reusing the r_index variable each time, so if more than one entry is added things aren't going to work, since that location in memory is having its value changed after its been used as a key. Anyway, I'd be happy to produce patches to either switch to an array or fix the key issue in the rcpt_to section, depending on which way we want to go. Personally, I'd prefer the array version though. -garrett
Re: 2.1 proxy and keepalives
Akins, Brian wrote: Does this code from 2.1 in apr_proxy_http_request still make sense? Do we not want to attempt to maintain the server connection anyway? Maybe I'm missing some other logic... /* strip connection listed hop-by-hop headers from the request */ /* even though in theory a connection: close coming from the client * should not affect the connection to the server, it's unlikely * that subsequent client requests will hit this thread/process, * so we cancel server keepalive if the client does. */ This code was from the days when keepalives were supported, but there was no connection pool, so keeping the connection open beyond the end of a frontend connection made no sense. Now there is a connection pool, so in theory the code should no longer be there. I would check though whether removing this code (which I think is the right thing to do) doesn't uncover some regressions - the major testing on the connection pool as I understand revolved around the ajp connector rather than the http connector. Regards, Graham --
Re: [PATCH] Make caching hash more deterministic
Colm MacCarthaigh wrote: Currently; GET / HTTP/1.1 Host: ftp.heanet.ie GET http://ftp.heanet.ie/ HTTP/1.0 GET HTTP://Ftp.Heanet.Ie/ HTTP/1.0 are all mapped to different hashes by mod_cache; despite being the same content, this is an inefficient waste of disk space and really awkward for me trying to write a debug/admin tool. The attached patch makes it deterministic, by mapping them all to; "http://ftp.heanet.ie:80/?"; The idea of canonicalising the name is sound, but munging them into an added :80 and an added ? is really ugly - these are not the kind of URLs that an end user would understand at a glance if they had to see them listed. Is it possible to remove the :80 if the scheme is https, and remove the :443 if the scheme is https:? What is the significance of the added "?"? Regards, Graham --
mod_smtpd compile problem
So I'm having a little trouble getting mod_smtpd to compile, once I fixed up the configure script to find apxs and apache correctly, I end up with the following error: $ make /usr/bin/apxs2 -Wc,"-Wall" -o mod_smtpd.la -c smtp_core.c smtp_protocol.c /usr/bin/libtool --silent --mode=compile gcc -prefer-pic -pipe -I/usr/include/xmltok -I/usr/include/openssl -Wall -O2 -DAP_HAVE_DESIGNATED_INITIALIZER -DLINUX=2 -D_REENTRANT -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -pipe -I/usr/include/xmltok -I/usr/include/openssl -Wall -O2 -pthread -I/usr/include/apache2 -I/usr/include/apr-0 -I/usr/include/apr-0 -I/usr/include -Wall -c -o smtp_core.lo smtp_core.c && touch smtp_core.slo smtp_core.c: In function `register_hooks': smtp_core.c:348: error: `default_queue' undeclared (first use in this function) smtp_core.c:348: error: (Each undeclared identifier is reported only once smtp_core.c:348: error: for each function it appears in.) smtp_core.c:349: error: `default_rcpt' undeclared (first use in this function) apxs:Error: Command failed with rc=65536 . make: *** [mod_smtpd.la] Error 1 This is with Apache 2.0.53, if that makes a difference... -garrett
[PATCH] mod_smtpd function naming
I noticed that mod_smtpd seems to go to some lengths to avoid messing up
the global namespace, prefixing globally visible function names with
smtpd_ and so forth, but there seems to be one case where this isn't
done, process_smtp_connection_internal. This patch renames it to
smtpd_process_connection_internal.
-garrett
* smtp.h
(process_smtp_connection_internal): rename to...
(smtpd_process_connection_internal): this.
* smtp_protocol.c
(process_smtp_connection_internal): rename to...
(smtpd_process_connection_internal): this.
* smtp_core.c
(process_smtp_connection): update call to
smtpd_process_connection_internal.
Index: smtp_core.c
===
--- smtp_core.c (revision 232623)
+++ smtp_core.c (working copy)
@@ -262,7 +262,7 @@
r = smtpd_create_request(c);
ap_update_child_status(r->connection->sbh, SERVER_BUSY_KEEPALIVE, r);
- process_smtp_connection_internal(r);
+ smtpd_process_connection_internal(r);
return OK;
}
Index: smtp.h
===
--- smtp.h (revision 232623)
+++ smtp.h (working copy)
@@ -43,7 +43,7 @@
} smtpd_handler_st;
void
- process_smtp_connection_internal(request_rec *r);
+ smtpd_process_connection_internal(request_rec *r);
void
smtpd_clear_request_rec(smtpd_request_rec *);
Index: smtp_protocol.c
===
--- smtp_protocol.c (revision 232623)
+++ smtp_protocol.c (working copy)
@@ -38,7 +38,7 @@
#define BUFFER_STR_LEN 1024
void
-process_smtp_connection_internal(request_rec *r)
+smtp_process_connection_internal(request_rec *r)
{
apr_pool_t *p;
apr_hash_t *handlers = smtpd_get_handlers();
[PATCH] mod_smtpd configure fixes
On my Ubuntu linux box, the Apache2 apxs is installed as 'apxs2', and
the httpd binary is installed in the SBINDIR, not BINDIR, and is not
named httpd, so the current configure script can't find it. Here's an
updated version that makes two changes, first it lets you specify a full
path to the apxs binary, second it makes the search for the apache
binary check both the SBINDIR and BINDIR directories, and makes it query
apxs for the actual program name.
A log message and patch follows.
-garrett
* configure.ac
(CHECK_VERSION): try the SBINDIR directory in addition to the BINDIR,
and query apxs for the httpd program name instead of hardcoding
httpd.
(APACHE_DIR): interpret an argument that points to a file as the full
path to apxs.
Index: configure.ac
===
--- configure.ac (revision 232623)
+++ configure.ac (working copy)
@@ -4,7 +4,14 @@
AC_DEFUN([CHECK_VERSION],[dnl
min_apache_version=ifelse([$1], ,no,$1)
AP_BIN=`$APXS_BIN -q BINDIR`
- our_apache_version=`$AP_BIN/httpd -v | grep -i Apache |
+ AP_SBIN=`$APXS_BIN -q SBINDIR`
+AP_PROG=`$APXS_BIN -q PROGNAME`
+if test -e "$AP_BIN/$AP_PROG"; then
+AP_PATH="$AP_BIN/$AP_PROG"
+else
+AP_PATH="$AP_SBIN/$AP_PROG"
+fi
+ our_apache_version=`$AP_PATH -v | grep -i Apache |
sed -e 's/.*Apache\///' | tr -dc [^0-9.]`
AC_MSG_CHECKING(for Apache version >= $min_apache_version)
@@ -27,14 +34,16 @@
apxs_prefix="$withval",
)
- if test ! -d $apxs_prefix; then
- apxs_prefix=`dirname $apxs_prefix`
+ if test -d $apxs_prefix; then
+ apxs_prefix=`dirname $apxs_prefix`
+
+test_paths="$apxs_prefix:$apxs_prefix/bin:$apxs_prefix/sbin"
+test_paths="${test_paths}:${PATH}:/usr/bin:/usr/sbin"
+test_paths="${test_paths}:/usr/local/bin:/usr/local/sbin:/usr/local/apache2/bin"
+ AC_PATH_PROG(APXS_BIN, apxs, no, [$test_paths])
+else
+APXS_BIN="$withval"
fi
-
- test_paths="$apxs_prefix:$apxs_prefix/bin:$apxs_prefix/sbin"
- test_paths="${test_paths}:${PATH}:/usr/bin:/usr/sbin"
- test_paths="${test_paths}:/usr/local/bin:/usr/local/sbin:/usr/local/apache2/bin"
- AC_PATH_PROG(APXS_BIN, apxs, no, [$test_paths])
if test "$APXS_BIN" = "no"; then
AC_MSG_ERROR([*** The apxs binary installed by apache could not be found!])
Re: New mod_smtpd release
Branko Čibej <[EMAIL PROTECTED]> writes: > May I suggest you resend this patch, using "svn diff" instead of "diff > -pur" to create it? You're diffing the SVN administrative directory... Thanks. Here's another patch to add a skeleton STATUS file, using svn diff this time. Index: STATUS === --- STATUS (revision 0) +++ STATUS (revision 0) @@ -0,0 +1,49 @@ +mod_smtpd STATUS: -*-text-*- +Last modified at [$Date: $] + +The current version of this file can be found at: + + * http://svn.apache.org/repos/asf/httpd/mod_smtpd/trunk/STATUS + + +Release history: + + 0.9 under development. + + +Contributors looking for a mission: + + * Just do an egrep on "TODO" or "XXX" in the source. + + * Review the bug database at: http://issues.apache.org/bugzilla/ + + * Open bugs in the bug database. + + +CURRENT RELEASE NOTES: + + Virtual hosts a'la mod_ftpd don't work. + + +RELEASE SHOWSTOPPERS: + + + smtp_process_connection_internal should take a "smtp_proto_rec" argument + (which is what the current "smtp_request_rec" struct should be renamed to). + + +CURRENT VOTES: + + +TODO ISSUES: + + The request i/o is driven around ap_rgetline, when it really + should be using input filters. + + +WISH LIST: + + Link against libapreq2 so we can use its header and multipart parsers. + apreq's header parser would help in implementing rfc2821 loop-detection, + and in providing the header collection as r->headers_in for "data" + hooks to examine. -- Joe Schaefer
Re: New mod_smtpd release
Joe Schaefer wrote: Rian Hunter <[EMAIL PROTECTED]> writes: You can checkout this code out from: http://svn.apache.org/repos/asf/httpd/mod_smtpd/trunk/ Very cool, thanks! I had some trouble compiling it, and I noticed you're using // comments alot. Here are two patches for that. May I suggest you resend this patch, using "svn diff" instead of "diff -pur" to create it? You're diffing the SVN administrative directory... (Or at the very least, tell diff to "-x .svn".) -- Brane
Re: New mod_smtpd release
Rian Hunter <[EMAIL PROTECTED]> writes:
> You can checkout this code out from:
> http://svn.apache.org/repos/asf/httpd/mod_smtpd/trunk/
Very cool, thanks! I had some trouble compiling it,
and I noticed you're using // comments alot.
Here are two patches for that.
diff -pur trunk/.svn/entries trunk-00/.svn/entries
--- trunk/.svn/entries 2005-08-14 01:17:03.0 -0400
+++ trunk-00/.svn/entries 2005-08-14 01:11:47.0 -0400
@@ -58,7 +58,7 @@
diff -pur trunk-00/.svn/entries trunk-01/.svn/entries
--- trunk-00/.svn/entries 2005-08-14 01:11:47.0 -0400
+++ trunk-01/.svn/entries 2005-08-14 00:42:43.0 -0400
@@ -49,7 +49,7 @@
request_config, &smtpd_module);
}
-// should be called at smtpd_hook_connect
+/* should be called at smtpd_hook_connect */
SMTPD_DECLARE_NONSTD(void)
smtpd_register_extension(smtpd_request_rec *sr, const char *line)
{
@@ -134,19 +134,20 @@ smtpd_register_extension(smtpd_request_r
(sr->e_index)++;
}
-// how to reset the transaction
+/* how to reset the transaction */
SMTPD_DECLARE_NONSTD(void)
smtpd_reset_transaction(request_rec *r) {
- // REVIEW: don't know whether to run clear request first
- // then run reset hooks, or run reset hooks then clear request
- // depends on whether hooks want to save info before it gets cleared out
- // or if they want to overwrite default values in the request rec
- smtpd_run_reset_transaction(r);
+ /* REVIEW: don't know whether to run clear request first
+ * then run reset hooks, or run reset hooks then clear request
+ * depends on whether hooks want to save info before it gets cleared out
+ * or if they want to overwrite default values in the request rec
+ * smtpd_run_reset_transaction(r);
+ */
smtpd_clear_request_rec(smtpd_get_request_rec(r));
}
-// friend methods
-// only our sources can call these
+/* friend methods */
+/* only our sources can call these */
void
smtpd_clear_request_rec(smtpd_request_rec *sr) {
@@ -167,10 +168,10 @@ smtpd_get_handlers() {
return smtpd_handlers;
}
-// private methods
-// only used in this file
+/* private methods */
+/* only used in this file */
-// can overwrite currently registered handlers
+/* can overwrite currently registered handlers */
static void
smtpd_register_handler(char *key, smtpd_handler *func, const char *help_text,
void *data, apr_pool_t *p)
@@ -186,7 +187,7 @@ smtpd_register_handler(char *key, smtpd_
apr_hash_set(smtpd_handlers, dupkey, APR_HASH_KEY_STRING, hand);
}
-// Creates the main request record for the connection
+/* Creates the main request record for the connection */
static request_rec *
smtpd_create_request(conn_rec *conn)
{
@@ -212,7 +213,7 @@ smtpd_create_request(conn_rec *conn)
r->err_headers_out = apr_table_make(r->pool, 5);
r->notes = apr_table_make(r->pool, 5);
- // Must be set before we run create request hook
+ /* Must be set before we run create request hook */
r->request_config = ap_create_request_config(r->pool);
r->proto_output_filters = conn->output_filters;
@@ -232,7 +233,7 @@ smtpd_create_request(conn_rec *conn)
apr_socket_t *csd=((core_net_rec *)r->input_filters->ctx)->client_socket;
apr_socket_timeout_set(csd, APR_INT64_C(10));
- // create custom smtpd rec
+ /* create custom smtpd rec */
sr = apr_pcalloc(r->pool, sizeof(*sr));
apr_pool_create(&sp, r->pool);
@@ -246,7 +247,7 @@ smtpd_create_request(conn_rec *conn)
return r;
}
-// process connection hook
+/* process connection hook */
static int
process_smtp_connection(conn_rec *c)
{
@@ -267,7 +268,7 @@ process_smtp_connection(conn_rec *c)
return OK;
}
-// creates server config
+/* creates server config */
static void *
smtpd_create_server_config(apr_pool_t *p, server_rec *s)
{
@@ -280,7 +281,7 @@ smtpd_create_server_config(apr_pool_t *p
return pConfig;
}
-// sets protocol status in server config
+/* sets protocol status in server config */
static const char *
set_protocol_status(cmd_parms *cmd,
void *struct_ptr,
@@ -294,7 +295,7 @@ set_protocol_status(cmd_parms *cmd,
return NULL;
}
-// sets server id string in server config
+/* sets server id string in server config */
static const char *
set_id_string(cmd_parms *cmd,
void *struct_ptr,
@@ -309,7 +310,7 @@ set_id_string(cmd_parms *cmd,
return NULL;
}
-// sets server id string in server config
+/* sets server id string in server config */
static const char *
set_max_data_size(cmd_parms *cmd,
void *struct_ptr,
@@ -338,11 +339,11 @@ static const command_rec smtpd_cmds[] =
{ NULL }
};
-// registers httpd hooks
+/* registers httpd hooks */
static void
register_hooks (apr_pool_t *p)
{
- // register connection processor
+/* register connection processor */
ap_hook_process_connection(process_smtp_connection, NULL,
NULL, APR_HOOK_MIDDLE);
/*
@@ -364,10 +365,10 @@ register_hooks (apr_pool_t *p)
module AP_MODULE_DECLARE_DATA smtpd_module =
open_logs hook's ordering
hi~ I can't understand the hook sorting in the case: I see the modules registering open_logs hook are prefork.c, core.c, log_config.c. When these modules register the hook, they use the order like this. prefork.c : APR_HOOK_MIDDLE core.c : APR_HOOK_REALLY_FIRST log_config.c : APR_HOOK_MIDDLE After I unpacked Apache tarball and set the apr_hook_debug_enabled = 1 in apr_hooks.c, I installed and ran Apache. And see Sorting open_logs : prefork.c core.c mod_log_opens.c I think core.c must be in first place but it doesn't. I don't know what it is ^^; 무료 1GB용량!, 더이상 용량 고민없는 야후! 메일을 써보세요. 대한민국 블로그가 모인 곳! 피플링에서 네이버, 이글루스를 만나다 야후! 모바일 최신 휴대폰 정보, 벨소리, 캐릭터, 문자메세지
Re: mod_dnsbl_lookup 0.90
On Fri, Jul 29, 2005 at 10:11:46PM +0100, Colm MacCarthaigh wrote: > Cool. I'd split dnsbl_zones into ipv4_dnsbl_zones and ipv6_dnsbl_zones > and have the DnsblZones directive work like; > > DnsblIPv4Zones > DnsblIPv6Zones FWIW, I think it'd be fine to have DnsblZones implicitly be DnsblIPv4Zones. IPv6's directive can explicitly. But, I think having users always have to type in IPv4 in the normal case is overkill. -- justin
