Re: Dropping mod_sed into /trunk/ ?
On Sat, Aug 23, 2008 at 05:28:05PM +0530, rahul wrote: > I have a request, > > in mod_sed, if there are multiline commands, specifying them is > cumbersome, It would be nice to have the ability to specify a script > file instead. > I agree. But I think mod_sed should support both. Any votes or comments? E.g OutputSedScriptFile and InputSedScriptFile can read the sed commands from sed script file. libsed has a function to process file based request. It is matter of adding few lines of code (additional configuration) in mod_sed to include this capability. Regards, Basant.
Re: SNI in 2.2.x (Re: Time for 2.2.10?)
Ian G wrote: > > Nick Kew <[EMAIL PROTECTED]>wrote: >> ... >> It might be worth a --with-SNI configuration option, which >> would label it as an experimental feature. > > I imagine the use of SNI would need to be configured in > httpd.conf anyway, in the virtual host parts. Making SNI support configurable at runtime also seems a more attractive solution to me - it would basically mean that in ssl_init_ctx(), the SNI callback is not registered unless it's explicitly configured. I would suggest using something like SSLEnableSNI port [port] ... which would be used as a per-server directive (i.e. not within vhosts, only globally) and enable SNI on the specified ports. Sander, would a run-time configuration option still receive +1 from you? This would only be needed for the 2.2.x backport, not for trunk, right? Kaspar
Re: Dropping mod_sed into /trunk/ ?
I have a request, in mod_sed, if there are multiline commands, specifying them is cumbersome, It would be nice to have the ability to specify a script file instead. |There is one important aspect of mod_sed design (which is borrowed from Sun | Web Server) that I would like to emphasize is that sed code has been separated | from filter code. So sed code itself can be archived in a shared/static library | (let me call it as libsed). mod_sed filter code is just one consumer of libsed. rahul -- 1. e4 _
Re: Dropping mod_sed into /trunk/ ?
Hi, There is one important aspect of mod_sed design (which is borrowed from Sun Web Server) that I would like to emphasize is that sed code has been separated from filter code. So sed code itself can be archived in a shared/static library (let me call it as libsed). mod_sed filter code is just one consumer of libsed. Typical usage of libsed is : sed_commands_t cmd sed_init_commands(&cmd, ...); sed_compile_string(&cmd, string1); sed_compile_string(&cmd, string2); sed_finalize_command(&cmd); // Run eval on compiled context any number times. sed_eval_t eval; sed_init_eval(&eval, ...); sed_eval_buffer(&eval, ...); sed_finalize_eval(&eval, ...); // finally destroy the evaluation and compile context sed_destroy_eval(&eval); sed_destroy_commands(&cmd); Having said that, I would like to emphasize the sed command and evaluation context doesn't store any thread local storage. What this means is that multiple commands and evalution context can be created within a single thread. This means multiple consumers of libsed can be consumed safely in a single thread. This way, any number of apache modules can make use of sed libraries and coexist in a same thread. If developers like this idea then one option is to drop libsed code into apr and drop mod_sed.c (which is a sed filter module) into apache code. libsed code lies in sed0.c sed1.c and regexp.c regexp.h libsed.h Whereas filter code is in mod_sed.c http://src.opensolaris.org/source/xref/webstack/mod_sed/ Regards, Basant. On Wed, Aug 20, 2008 at 11:53:58PM +0100, Nick Kew wrote: > A little while ago, Basant Kukreja published mod_sed under the > Apache license. He's now also written a blog entry that could > become the basis for a tutorial into how mod_sed is much more > than a mere string-or-regexp search-and-replace filter: > > http://blogs.sun.com/basant/entry/using_mod_sed_to_filter > > I happen to know that Basant and Sun will be happy for us > to adopt mod_sed, and I think that with that blog entry > reworked into a howto doc, it'll add real value to httpd. > > Any thoughts on dropping it in to trunk, with a view > to including it as standard in 2.4 in due course? > > -- > Nick Kew > > Application Development with Apache - the Apache Modules Book > http://www.apachetutor.org/
Re: dtrace in apache
Hi,
I agree with Rahul. pid provider can be used to trace apr calls. Following
dscript traces apr calls in stock apache (without any probes)
pid*::apr_*:entry
/execname == "httpd"/
{
}
pid*::apr_*:return
/execname == "httpd"/
{
}
--
If apr calls would not have been started with prefix apr_ then putting a
specific probe might make more sense.
I have written a small blog for it.
http://blogs.sun.com/basant/entry/tracking_apr_calls_in_apache
Regards,
Basant.
On Sat, Aug 23, 2008 at 01:00:37PM +0530, rahul wrote:
> Hi,
> I was reviewing the omniti labs dtrace functions, at
> http://labs.omniti.com/trac/project-dtrace/browser/trunk/apache22/apr-util-hook-probes.patch
> This patch (util-hook) is committed into apache already.
>
> I was concerned that quite a few were just tracing function boundaries,
> which the dtrace does already for us with out the necessity of USDT probes
> baked into the code.
>
> For e.g in APR_IMPLEMENT_XXX macros, the below are inserted.
> but APR_IMPLEMENT_XXX macros already create function boundaries when
> they are called and these probes effectively duplicate the
> instrumentation available.
>
>
> /**
> * @file apr_hooks.h
> * @brief Apache hook functions
> @@ -107,12 +124,21 @@
> ns##_LINK_##name##_t *pHook; \
> int n; \
> \
> -if(!_hooks.link_##name) \
> - return; \
> +OLD_DTRACE_PROBE(name##__entry); \
> \
> -pHook=(ns##_LINK_##name##_t *)_hooks.link_##name->elts; \
> -for(n=0 ; n < _hooks.link_##name->nelts ; ++n) \
> - pHook[n].pFunc args_use; \
> +if(_hooks.link_##name) \
> +{ \
> +pHook=(ns##_LINK_##name##_t *)_hooks.link_##name->elts; \
> +for(n=0 ; n < _hooks.link_##name->nelts ; ++n) \
> +{ \
> +OLD_DTRACE_PROBE1(name##__dispatch__invoke, (char
> *)pHook[n].szName); \
> + pHook[n].pFunc args_use; \
> +OLD_DTRACE_PROBE2(name##__dispatch__complete, (char
> *)pHook[n].szName, 0); \
> +} \
> +} \
> +\
> +OLD_DTRACE_PROBE1(name##__return, 0); \
> +\
> }
>
>
> What do you think?
>
> rahul
> --
> 1. e4 _
Re: mod_limitipconn merge - try2
On Fri, 22 Aug 2008, William A. Rowe, Jr. wrote:
this is a form of authorization, it appears to fit in aaa. Perhaps even
with a name in that scheme, such as mod_authz_hostlimit or something like
that.
I'd say that's stretching a point. But since I don't think I can
suggest an existing category into which it fits: the nearest functions
to it are in core!
Something like modules/traffic/ would kind-of describe it, but as of
now it would seem lonely there. I wonder if there's a case for
modules/misc/ ?
modules/limiters/ or something? That would cover a lot of things like
concurrent requests-per-ip/mimetype, ratelimiting and so on but still isn't
auth/access control...
This *is* access control, you are denying access, based on something other
than user and password. mod_authn_hostname anyone? This fits neatly into
the same general category.
Yes, but it's not definitive access, more like the "amount" of
access... I think most end users see access control as "can I access
this content or not", and even though a rate limiter is denying access
in the sense that it's reducing bandwidth the user can still access
the data.
Sure, you can argue either way, but I think that end users
will be more confused by most modules being called
mod_authwhatever_whatever (in fact, they're already confused).
/Nikke
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Niklas Edmundsson, Admin @ {acc,hpc2n}.umu.se | [EMAIL PROTECTED]
---
* * * <- Tribbles
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
dtrace in apache
Hi,
I was reviewing the omniti labs dtrace functions, at
http://labs.omniti.com/trac/project-dtrace/browser/trunk/apache22/apr-util-hook-probes.patch
This patch (util-hook) is committed into apache already.
I was concerned that quite a few were just tracing function boundaries,
which the dtrace does already for us with out the necessity of USDT probes
baked into the code.
For e.g in APR_IMPLEMENT_XXX macros, the below are inserted.
but APR_IMPLEMENT_XXX macros already create function boundaries when
they are called and these probes effectively duplicate the
instrumentation available.
/**
* @file apr_hooks.h
* @brief Apache hook functions
@@ -107,12 +124,21 @@
ns##_LINK_##name##_t *pHook; \
int n; \
\
-if(!_hooks.link_##name) \
- return; \
+OLD_DTRACE_PROBE(name##__entry); \
\
-pHook=(ns##_LINK_##name##_t *)_hooks.link_##name->elts; \
-for(n=0 ; n < _hooks.link_##name->nelts ; ++n) \
- pHook[n].pFunc args_use; \
+if(_hooks.link_##name) \
+{ \
+pHook=(ns##_LINK_##name##_t *)_hooks.link_##name->elts; \
+for(n=0 ; n < _hooks.link_##name->nelts ; ++n) \
+{ \
+OLD_DTRACE_PROBE1(name##__dispatch__invoke, (char
*)pHook[n].szName); \
+ pHook[n].pFunc args_use; \
+OLD_DTRACE_PROBE2(name##__dispatch__complete, (char
*)pHook[n].szName, 0); \
+} \
+} \
+\
+OLD_DTRACE_PROBE1(name##__return, 0); \
+\
}
What do you think?
rahul
--
1. e4 _
