Re: svn commit: r646582 - /httpd/httpd/trunk/modules/ldap/util_ldap.c
On 10.04.2008 00:49, [EMAIL PROTECTED] wrote: Author: bnicholes Date: Wed Apr 9 15:49:31 2008 New Revision: 646582 URL: http://svn.apache.org/viewvc?rev=646582&view=rev Log: Move the initialization of rebind to the post_config handler so that it is done during the actual module load stage rather than the preload stage. If done during the preload stage, the pool passed into the initialization function will be cleared and all allocations will be freed. But isn't it the pconf pool in both cases? Currently I cannot follow this argument. Mind to explain in more detail? Regards Rüdiger
Re: Solaris sed based apache filtering module (mod_sed)
> just that, too. Any performance comparisons with its competitors? Some quick performance comparison results between mod_sed, mod_line_edit and mod_substitute. Search/Replace string : s/hello/hi/ test0.html : No matches, so no substitute. test.html : 1 comparision/substitute test2.html : 500 comparision/substitute Performance data was generated with 200 clients for 10 requests (for worker mpm). $ ab -c 200 -n 10 Requests Per Second (RPS) as measured by ab for s/hello/hi/ substitution. mod_sed mod_line_edit mod_substitute test0.html3263 3206 3129 test.html 3229 3213 3197 test2.html1278 4041130 Note that mod_sed performs better than either mod_line_edit or mod_substitute. Here is the configuration : -- Alias /testsed/ "/usr/local/apache2/htdocs/testsed/" LoadModule sed_module modules/mod_sed.so Options FollowSymLinks AllowOverride None AddOutputFilter Sed html OutputSed "s/hello/hi/g" Alias /testled/ "/usr/local/apache2/htdocs/testled/" LoadModule line_edit_module modules/mod_line_edit.so Options FollowSymLinks AddOutputFilter line-editor .html AllowOverride None LERewriteRule "hello" "hi" [R] Alias /testsub/ "/usr/local/apache2/htdocs/testsub/" LoadModule substitute_module modules/mod_substitute.so Options FollowSymLinks AllowOverride None AddOutputFilter SUBSTITUTE html Substitute s/hello/hi/ -- Regards, Basant.
Re: Solaris sed based apache filtering module (mod_sed)
On Wed, Apr 09, 2008 at 04:32:09AM +0100, Nick Kew wrote: > On 9 Apr 2008, at 03:40, [EMAIL PROTECTED] wrote: >> Hi, >> mod_sed is a sed[1] based Apache filtering module, with the sed code based >> on >> opensolaris sed. sed scripting offers a more familiar interface to build >> powerful filters. This mod_sed is designed to work with Apache HTTP server >> version 2.2 and above. > > Thanks. This is useful stuff. Of course mod_sed overlaps with > mod_line_edit > and mod_substitute, but you're the first to support both input and output > filtering. My knowledge of sed itself is limited to the same kind of > search- > and-replace those filters offer, but I have an idea it does a little more > than > just that, too. Any performance comparisons with its competitors? I have not yet done any performance comparisons with its competitor but feature wise sed is very rich. I will try to do some basic performance testing and come back with results. Besides search and replace and regular expressions, Some of it's feature are : 1) One can write if/else condition using sed labels and branches. If (match) do this else do that. 2) Read/Write to a file using 'r' and 'w' commands 3) operations on a particular line number. 4) deleting lines on a condition. 5) Using braces to specify multiple operations if a condition matches. 6) inserting and appending text and many others features. Here is one of the sed tutorial (from google) http://www.grymoire.com/Unix/Sed.html > >> Design of this filter is in the way that regexp.c, regexp.h, sed0.c >> sed1.c, >> libsed.h can be made part of the apr. While the filter code mod_sed.c >> will be a filter module which can reside under modules directory. This >> way other modules can also take advantage of sed libraries. > > I think you mean you've adapted the sed code to run on APR pools, > and updated it for thread-safety/reentrancy. Once we have a > modular build system in a release version of apr-util, that could > perhaps fit nicely as an apr_sed module. But that's a whole other > discussion. > >> Please have a look into the code and provide your comments. > > Well, I've had a preview of this, and it's good :-) > > -- > Nick Kew Regards, Basant.
Re: svn commit: r646445 - in /httpd/httpd/trunk/modules/aaa: mod_auth_basic.c mod_auth_digest.c
Chris Darroch wrote: Can you check if mod_auth_form also needs this? Yes, it does -- looks like you're doing your own ap_lookup_provider() calls on the authn provider group. This was based originally on the mod_auth_basic code. I didn't want to make a change that I didn't fully understand yet. > I can put it in for you if you like. I'd propose also taking out the AP_MODULE_MAGIC_AT_LEAST(20080403,1) check because in trunk you can just call the new function; if you're backporting to 2.2 before the "walk cache" stuff gets backported, just do it the old way (and don't define the list_provider_names callback). The reason for the AP_MODULE_MAGIC_AT_LEAST was so that you can drop the mod_auth_form stuff into httpd v2.2 and have it work (it's how I have production tested the thing), even if the modules aren't formally backported to v2.2 yet. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: svn commit: r646445 - in /httpd/httpd/trunk/modules/aaa: mod_auth_basic.c mod_auth_digest.c
Graham Leggett wrote: Let each consumer of authn providers redefine the list_provider_names callback in case they are loaded individually without mod_authn_core. Can you check if mod_auth_form also needs this? Yes, it does -- looks like you're doing your own ap_lookup_provider() calls on the authn provider group. I can put it in for you if you like. I'd propose also taking out the AP_MODULE_MAGIC_AT_LEAST(20080403,1) check because in trunk you can just call the new function; if you're backporting to 2.2 before the "walk cache" stuff gets backported, just do it the old way (and don't define the list_provider_names callback). I'll let the "walk cache" stuff settle a little more but I hope to propose it for backporting soon (see the relevant patch set under http://people.apache.org/~chrisd/patches/walk_cache/). It should be backwards-compatible and provides a performance boost, especially for mod_dav when running behind authn/z (which it almost always is). Chris. -- GPG Key ID: 366A375B GPG Key Fingerprint: 485E 5041 17E1 E2BB C263 E4DE C8E3 FA36 366A 375B
Re: svn commit: r646445 - in /httpd/httpd/trunk/modules/aaa: mod_auth_basic.c mod_auth_digest.c
[EMAIL PROTECTED] wrote: URL: http://svn.apache.org/viewvc?rev=646445&view=rev Log: Let each consumer of authn providers redefine the list_provider_names callback in case they are loaded individually without mod_authn_core. Modified: httpd/httpd/trunk/modules/aaa/mod_auth_basic.c httpd/httpd/trunk/modules/aaa/mod_auth_digest.c Can you check if mod_auth_form also needs this? Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: svn commit: r646281 - in /httpd/httpd/trunk: CHANGES include/http_protocol.h modules/http/http_filters.c
Graham Leggett wrote: Joe Orton wrote: The entire request body passes through the input filter stack when it is being discarded. So an input filter inserted by a module can capture and buffer it somewhere very easily; and can provide access to that buffered copy however it likes, without needing to modify request_rec. In practise it is not that simple[1]. If mod_include had its own kept_body filter, it would not take into account the magic that mod_auth_form performs to keep the contents of the end user's form from being lost. In other words, modules need to cooperate with one another to make this work effectively, and that means common code. So where does this common code go? apreq handles this. import apreq to turnk. IMO. -Paul
Re: AuthzMergeRules directive
Chris Darroch wrote: Here's another thought: for people doing mass virtual hosting, and who let their customers put authn/z directives into .htaccess files with "AllowOverride AuthConfig", I would think it may be important to ensure that these rules still merge together in the way they used to. Otherwise upgrading to 2.4 might mean tracking down every .htaccess file and rewriting it to do the right thing (sticking in an "AuthzMergeRules Off" or something). For some people doing vhosting I suspect that would be a tall order, so it would be good if 2.4 would function securely in this situation, by default. That said, I don't use .htaccess files and may not be making any sense today; my apologies. Here's a follow-up notion; admittedly, it represents a lot of re-refactoring work. It would provide an secure upgrade path for people with complex configurations, including those with many legacy .htaccess files to consider. A new directive, Accept, is introduced to take the place of Require. It functions as Require does now in 2.4. Thus we have two groups of authz directives, old (Require/Satisfy/Order/ Deny/Allow) and new (Accept/Reject//). The old directives function as they did in 2.2. Authz directives would be parsed and merged as follows: 1) Within a per-dir config block (//etc.) old and new authz directives may not be mixed. If directives from both groups appear, a config-time error is thrown. 2) When merging new authz directives within a per-dir config block, the default merge rule is OR, as in 2.4 at present. This is equivalent to using a around all new authz directives within a per-dir config block. 3) When merging per-dir config blocks at runtime, the following rules are applied; we'll call the parent block "base" and the child block "new": 3.1) If the new block contains no authz directives, the base's authz configuration is inherited (if any). This follows current 2.2 behaviour. 3.2) If the new block contains old authz directives, the base block's authz configuration is discarded, and the new block's authz directives are applied to a clean slate. This follows current 2.2 behaviour. 3.3) If the new block contains new authz directives, the base and new blocks' authz configurations are merged using the rule specified by AuthzMergeRules (as it appears within the new block): 3.3.1) If AuthzMergeRules is set to Off or is not defined, the base block's authz configuration is discarded, and the new block's authz directives are applied to a clean slate. This follows current 2.2 behaviour, to avoid confusion and simplify most configurations. 3.3.2) If AuthzMergeRules is set to Or or SatisfyOne, the base block's authz configuration is merged with the new block's as if they were collectively contained within a block. 3.3.3) If AuthzMergeRules is set to And or SatisfyAll, the base block's authz configuration is merged with the new block's as if they were collectively contained within a block. Writing that all out it mostly just seems like a depressingly large amount of work, but otherwise feels like it might offer a way forward, both for people upgrading from 2.2 and those starting fresh with 2.4. Thoughts? Chris. -- GPG Key ID: 366A375B GPG Key Fingerprint: 485E 5041 17E1 E2BB C263 E4DE C8E3 FA36 366A 375B
Re: svn commit: r646281 - in /httpd/httpd/trunk: CHANGES include/http_protocol.h modules/http/http_filters.c
Joe Orton wrote: The entire request body passes through the input filter stack when it is being discarded. So an input filter inserted by a module can capture and buffer it somewhere very easily; and can provide access to that buffered copy however it likes, without needing to modify request_rec. In practise it is not that simple[1]. If mod_include had its own kept_body filter, it would not take into account the magic that mod_auth_form performs to keep the contents of the end user's form from being lost. In other words, modules need to cooperate with one another to make this work effectively, and that means common code. So where does this common code go? HTTP request bodies being most closely associated with the HTTP protocol, the http_module seemed the most logical place for this functionality. Others may disagree that the http_module is the best place for this, and that is perfectly fine by me. I am open to suggestions for alternatives. Just to be clear: the current intention is to add it to the HTTP module, *not* the core. The fact that the HTTP module still is half melted into a core is a separate problem. [1] Making KeptBodySize work was like getting blood out of a stone. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: svn commit: r646281 - in /httpd/httpd/trunk: CHANGES include/http_protocol.h modules/http/http_filters.c
On Wed, Apr 09, 2008 at 05:07:33PM +0200, Graham Leggett wrote: > Joe Orton wrote: > >> I don't understand why *that* stuff needed to be in the core. It is >> certainly possible to consume then reinject the request body, without >> changing one line of core filters; it's done in mod_ssl, see >> ssl_io_filter_buffer/ssl_io_buffer_fill. > > What about modules that call ap_discard_request_body? Once the body has > been discarded, the body is discarded, there is no way to get it back. The entire request body passes through the input filter stack when it is being discarded. So an input filter inserted by a module can capture and buffer it somewhere very easily; and can provide access to that buffered copy however it likes, without needing to modify request_rec. joe
Re: svn commit: r646281 - in /httpd/httpd/trunk: CHANGES include/http_protocol.h modules/http/http_filters.c
Joe Orton wrote: I don't understand why *that* stuff needed to be in the core. It is certainly possible to consume then reinject the request body, without changing one line of core filters; it's done in mod_ssl, see ssl_io_filter_buffer/ssl_io_buffer_fill. What about modules that call ap_discard_request_body? Once the body has been discarded, the body is discarded, there is no way to get it back. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: svn commit: r646281 - in /httpd/httpd/trunk: CHANGES include/http_protocol.h modules/http/http_filters.c
On Wed, Apr 09, 2008 at 03:10:25PM +0200, Graham Leggett wrote: > Roy T. Fielding wrote: > >> -1. Bloat like this belongs in a module. > > This piece of code depends on the KeptBodySize directive, which is part of > the http_filter, and sits alongside ap_discard_request_body(). I don't understand why *that* stuff needed to be in the core. It is certainly possible to consume then reinject the request body, without changing one line of core filters; it's done in mod_ssl, see ssl_io_filter_buffer/ssl_io_buffer_fill. joe
Re: svn commit: r646285 - in /httpd/httpd/trunk: CHANGES docs/manual/mod/mod_auth_form.xml modules/aaa/config.m4 modules/aaa/mod_auth_form.c
Takashi Sato wrote: Please use svn:keywords = LastChangedRevision . Done. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: svn commit: r646281 - in /httpd/httpd/trunk: CHANGES include/http_protocol.h modules/http/http_filters.c
Roy T. Fielding wrote: -1. Bloat like this belongs in a module. This piece of code depends on the KeptBodySize directive, which is part of the http_filter, and sits alongside ap_discard_request_body(). I can move it into another module, but then that just gives the administrator one extra thing to configure incorrectly. Putting it in mod_auth_form meant that mod_auth_form would be delving into the internals of the http_filter module, which seems wrong to me. Rather let http_filter export a formal function to the world, than having external modules poking around inside it. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: svn commit: r646285 - in /httpd/httpd/trunk: CHANGES docs/manual/mod/mod_auth_form.xml modules/aaa/config.m4 modules/aaa/mod_auth_form.c
On Wed, 09 Apr 2008 11:46:48 - [EMAIL PROTECTED] wrote: > Added: httpd/httpd/trunk/docs/manual/mod/mod_auth_form.xml > URL: > http://svn.apache.org/viewvc/httpd/httpd/trunk/docs/manual/mod/mod_auth_form.xml?rev=646285&view=auto > == > --- httpd/httpd/trunk/docs/manual/mod/mod_auth_form.xml (added) > +++ httpd/httpd/trunk/docs/manual/mod/mod_auth_form.xml Wed Apr 9 04:46:46 > 2008 > @@ -0,0 +1,719 @@ > + > + > + > + Please use svn:keywords = LastChangedRevision . See r645857
Re: svn commit: r646281 - in /httpd/httpd/trunk: CHANGES include/http_protocol.h modules/http/http_filters.c
-1. Bloat like this belongs in a module. Roy
Re: Apache support for form authentication
Hi Graham, >> maybe you can already commit mod_auth_form for the un-patient even though >> docu might not be ready yet? I've just now a little bit time to look into >> building the whole session stuff properly on NetWare... > I just did :) and even with docu!! Thanks very much! Guenter.
Re: Apache support for form authentication
Guenter Knauf wrote: maybe you can already commit mod_auth_form for the un-patient even though docu might not be ready yet? I've just now a little bit time to look into building the whole session stuff properly on NetWare... I just did :) Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: Apache support for form authentication
Hi Graham, > The mod_session_dbd module is written but not yet completely tested, and > the mod_auth_form module is written, tested, but not yet documented. > This should be completed over the next few days. maybe you can already commit mod_auth_form for the un-patient even though docu might not be ready yet? I've just now a little bit time to look into building the whole session stuff properly on NetWare... thanks, Guenter.
Re: svn commit: r646126 - in /httpd/httpd/trunk/modules/session:mod_session.c mod_session_cookie.c mod_session_crypto.c mod_session_dbd.c
Hi Ruediger, > 1. Why using AP_DECLARE for functions that seem to be clearly used as > functions > local to this file. IMHO static int would be better. > 2. Why using an ap_ prefix for a local function? IMHO only exported > function > should get this prefix. Otherwise you might get confused reading the > code > by assuming that these functions get exported. > BTW: This comment is valid for all session stuff. from what I see mod_session does indeed export at least these: ap_hook_session_decode ap_hook_session_encode ap_hook_session_load ap_hook_session_save and f.e. mod_session_crypt does then consume them; on NetWare I need to manually control these exports / imports and tell them to the linker. Guenter.
Re: Functions run when configuration file is read
On Apr 8, 2008, at 8:44 PM, Andy Grant wrote:
I am writing a module that runs certain functions depending on the
configuration directives in the conf files. The functions are run
twice when the server is started and again when the server shuts
down. Is there a way to make the functions run only once? Maybe
some variable that can be checked stating that the server is reading
the conf files, actually starting the server, or shutting down?
Do a grep through the modulues for comments like 'first run'. It is
common for modules to do something post their conf init like:
.._init()
if (...) {
first run -- ignore
set some flag
} else {
do...
for example to first gather all the configured hostnames and only then
check if they can be reached.
Dw
Re: svn commit: r646206 - in /httpd/sandbox/amsterdam/d: build/build-modules-c.awk include/http_core.h server/Makefile.in server/serf_filters.c
On 09.04.2008 09:21, [EMAIL PROTECTED] wrote:
Author: pquerna
Date: Wed Apr 9 00:21:01 2008
New Revision: 646206
URL: http://svn.apache.org/viewvc?rev=646206&view=rev
Log:
Move the core serf filters to the core.
Added:
httpd/sandbox/amsterdam/d/server/serf_filters.c
Modified:
httpd/sandbox/amsterdam/d/build/build-modules-c.awk
httpd/sandbox/amsterdam/d/include/http_core.h
httpd/sandbox/amsterdam/d/server/Makefile.in
Added: httpd/sandbox/amsterdam/d/server/serf_filters.c
URL:
http://svn.apache.org/viewvc/httpd/sandbox/amsterdam/d/server/serf_filters.c?rev=646206&view=auto
==
--- httpd/sandbox/amsterdam/d/server/serf_filters.c (added)
+++ httpd/sandbox/amsterdam/d/server/serf_filters.c Wed Apr 9 00:21:01 2008
+
+static int serf_input_filter(ap_filter_t *f, apr_bucket_brigade *bb,
+ ap_input_mode_t mode, apr_read_type_e block,
+ apr_off_t readbytes)
+{
+apr_status_t status;
+core_net_rec *net = f->ctx;
+serf_core_ctx_t *ctx = (serf_core_ctx_t*)net->in_ctx;
+
+if (mode == AP_MODE_INIT) {
+return APR_SUCCESS;
+}
+if (!ctx)
+{
+ctx = init_ctx(f, net->client_socket);
+net->in_ctx = (void*)ctx;
+}
+
+if (mode == AP_MODE_GETLINE) {
+const char *data;
+apr_size_t len;
+int found;
+apr_bucket *b;
+
+ctx->serf_bucket_status = serf_bucket_readline(ctx->serf_in_bucket,
+ SERF_NEWLINE_ANY,
+ &found, &data, &len);
+b = apr_bucket_transient_create(data, len, f->c->bucket_alloc);
+APR_BRIGADE_INSERT_TAIL(bb, b);
+return APR_SUCCESS;
Why returning APR_SUCCESS here in all cases? What if the connection to the
client got broken?
+}
+if (mode == AP_MODE_READBYTES) {
+const char *data;
+apr_size_t len;
+apr_bucket *b;
+
+ctx->serf_bucket_status = serf_bucket_read(ctx->serf_in_bucket,
+ readbytes, &data, &len);
+b = apr_bucket_transient_create(data, len, f->c->bucket_alloc);
+APR_BRIGADE_INSERT_TAIL(bb, b);
+return APR_SUCCESS;
Same as above.
+}
+
+if (mode == AP_MODE_SPECULATIVE) {
+const char *data;
+apr_size_t len;
+apr_bucket *b;
+serf_bucket_t *sb;
+
+ctx->serf_bucket_status = serf_bucket_peek(ctx->serf_in_bucket,
+ &data, &len);
+
+b = apr_bucket_transient_create(data, len, f->c->bucket_alloc);
+APR_BRIGADE_INSERT_TAIL(bb, b);
+return APR_SUCCESS;
Same as above.
+}
+
+if (mode == AP_MODE_EATCRLF || mode == AP_MODE_EXHAUSTIVE) {
+abort();
Looks like a TODO here :-).
+}
+}
+
+static apr_status_t serf_output_filter(ap_filter_t *f,
+ apr_bucket_brigade *new_bb)
+{
+apr_status_t rv;
+serf_bucket_t *b;
+conn_rec *c = f->c;
+core_net_rec *net = f->ctx;
+serf_core_ctx_t *ctx = (serf_core_ctx_t*)net->in_ctx;
+if (!ctx) {
+ctx = init_ctx(f, net->client_socket);
+net->in_ctx = (void*)ctx;
+}
+
+if (new_bb) {
+b = brigade_create(f, new_bb, ctx);
+serf_bucket_aggregate_append(ctx->serf_out_bucket, b);
+c->data_in_output_filters = 1;
+}
+
+if (c->data_in_output_filters && new_bb == NULL) {
How do we get in the situation where new_bb is NULL?
+do {
+apr_status_t srv;
+const char *buf;
+apr_size_t len = 0;
+
+srv = serf_bucket_read(ctx->serf_out_bucket, SERF_READ_ALL_AVAIL,
+ &buf, &len);
+
+if (SERF_BUCKET_READ_ERROR(srv)) {
+/* bad, logme */
+return srv;
+}
+
+/* write data to network here. */
+if (len > 0) {
+apr_size_t blen = len;
+rv = apr_socket_send(net->client_socket, buf, &blen);
+if (blen != len) {
+b = serf_bucket_simple_create(buf+blen, len - blen, NULL,
NULL, ctx->serf_bkt_alloc);
+serf_bucket_aggregate_prepend(ctx->serf_out_bucket, b);
+srv = APR_SUCCESS;
+}
+}
+
+if (APR_STATUS_IS_EOF(srv)) {
+c->data_in_output_filters = 0;
+break;
+}
+if (APR_STATUS_IS_EAGAIN(srv)) {
+break;
+}
+} while (rv == APR_SUCCESS);
+}
+
+return APR_SUCCESS;
Is it really ok to return APR_SUCCESS in all cases?
Regards
Rüdiger
Re: svn commit: r646126 - in /httpd/httpd/trunk/modules/session: mod_session.c mod_session_cookie.c mod_session_crypto.c mod_session_dbd.c
On 09.04.2008 01:12, [EMAIL PROTECTED] wrote: Author: minfrin Date: Tue Apr 8 16:12:12 2008 New Revision: 646126 URL: http://svn.apache.org/viewvc?rev=646126&view=rev Log: Insert prototypes to remove compiler warnings. [Joe Orton] Modified: httpd/httpd/trunk/modules/session/mod_session.c httpd/httpd/trunk/modules/session/mod_session_cookie.c httpd/httpd/trunk/modules/session/mod_session_crypto.c httpd/httpd/trunk/modules/session/mod_session_dbd.c Modified: httpd/httpd/trunk/modules/session/mod_session.c URL: http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/session/mod_session.c?rev=646126&r1=646125&r2=646126&view=diff == --- httpd/httpd/trunk/modules/session/mod_session.c (original) +++ httpd/httpd/trunk/modules/session/mod_session.c Tue Apr 8 16:12:12 2008 @@ -40,13 +40,18 @@ (request_rec * r, session_rec * z), (r, z), OK, DECLINED) AP_IMPLEMENT_HOOK_RUN_ALL(int, session_decode, (request_rec * r, session_rec * z), (r, z), OK, DECLINED) + +AP_DECLARE(int) ap_session_identity_encode(request_rec * r, session_rec * z); +AP_DECLARE(int) ap_session_identity_decode(request_rec * r, session_rec * z); +AP_DECLARE(int) ap_session_fixups(request_rec * r); + Two questions: 1. Why using AP_DECLARE for functions that seem to be clearly used as functions local to this file. IMHO static int would be better. 2. Why using an ap_ prefix for a local function? IMHO only exported function should get this prefix. Otherwise you might get confused reading the code by assuming that these functions get exported. BTW: This comment is valid for all session stuff. Regards Rüdiger P.S.: Please add an appropriate [auto-props] config to your subversion client config to avoid the eol-style mess we had recently in the future.
Re: Solaris sed based apache filtering module (mod_sed)
On 9 Apr 2008, at 03:40, [EMAIL PROTECTED] wrote: Hi, mod_sed is a sed[1] based Apache filtering module, with the sed code based on opensolaris sed. sed scripting offers a more familiar interface to build powerful filters. This mod_sed is designed to work with Apache HTTP server version 2.2 and above. Thanks. This is useful stuff. Of course mod_sed overlaps with mod_line_edit and mod_substitute, but you're the first to support both input and output filtering. My knowledge of sed itself is limited to the same kind of search- and-replace those filters offer, but I have an idea it does a little more than just that, too. Any performance comparisons with its competitors? Design of this filter is in the way that regexp.c, regexp.h, sed0.c sed1.c, libsed.h can be made part of the apr. While the filter code mod_sed.c will be a filter module which can reside under modules directory. This way other modules can also take advantage of sed libraries. I think you mean you've adapted the sed code to run on APR pools, and updated it for thread-safety/reentrancy. Once we have a modular build system in a release version of apr-util, that could perhaps fit nicely as an apr_sed module. But that's a whole other discussion. Please have a look into the code and provide your comments. Well, I've had a preview of this, and it's good :-) -- Nick Kew
