Re: RFC: can I make mod_cache per-dir?
On Tue, Aug 16, 2005 at 10:44:11PM -0700, Paul Querna wrote: > > We'd certainly sacrifice some speed under these circumstances; but it'd > > perhaps be better than nothing and would avoid the possibility where we > > serve > > content that is now excluded. -- justin > > IMO, this is why we should revive my original work[1] to enable > mod_cache to run as both a Quick Handler and a Normal Handler. We could > also invent a new handler, 'middle' handler, that runs after > map_to_storage, but before the rest of the hooks. (And hence, ran once > we have done directory blocks) Is this is essentially the exact same problem as is being discussed in relation to r220307? ie a handler which wants per-dir information is running too early, and all they have available to them is the request_rec and the per-server config. If so, and it's a problem in two different places, that adds some merit to a general solution over hacking either module on an ad-hoc basis. -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: mod_mbox seg faulting on ajax
Joshua Slive wrote: > [What is the active mod_mbox devel list? Trying [EMAIL PROTECTED] [EMAIL PROTECTED] is the best list. > As the subject says, mod_mbox has seg faulted about 50 times so far > today on ajax. Some core files in ajax:/tmp (after hacking apachectl to > adjust the ulimits). I think I just fixed this in trunk with r233127, but I didn't have enough spare cycles to test/reproduce it. -Paul
Re: RFC: can I make mod_cache per-dir?
[snip] >> >> >> CacheEnable disk >> >> >>might be equivalent to "CacheEnable disk /foo". It would be trivial to >>make this work as-is, but seems fairly pointless. Location-based >>application can be done already. > > > That would be an improvement over what we have today. > > However, I wonder if we can store some information in our cache that can > provide enough information for the check (i.e. done with directory/file). > > A thought: record the fact that this particular cache entry was originated > through a directory check - this can also *only* happen when mod_cache is > fronting a local origin server (nowhere else would Directory come into play). > Under what I've deduced from your previous emails, we know this because we'd > have to delay our cacheablity config check until cache_save_filter. So, if > this bit is set, then we know we have to wait for the directory/location walk > to run again before we can 'approve' serving the cached response. (Or, we > could also try to run the directory walk ourselves in the cache handler.) > > Yet, there is a *possibility* that something could switch from a Location to a > Directory (i.e. switch from a scenario where we could solely rely upon the > configuration to where a directory now controls the cacheability: hence we > need the dir walk). Not sure what we should do there. > > We'd certainly sacrifice some speed under these circumstances; but it'd > perhaps be better than nothing and would avoid the possibility where we serve > content that is now excluded. -- justin IMO, this is why we should revive my original work[1] to enable mod_cache to run as both a Quick Handler and a Normal Handler. We could also invent a new handler, 'middle' handler, that runs after map_to_storage, but before the rest of the hooks. (And hence, ran once we have done directory blocks) -Paul [1] http://marc.theaimsgroup.com/?l=apache-httpd-dev&m=111597814015667&w=2
New Committer - Colm MacCarthaigh
The Apache HTTP Server Project PMC is happy to announce that Colm
MacCarthaigh has been given SVN write access ("commit access") to the
httpd project repositories.
Lets all give a round of applause to Colm.
-Paul
Re: Apache code-style vim tips
On Wed, Aug 17, 2005 at 05:06:08AM +0100, Colm MacCarthaigh wrote:
>
> Just wondering what vim-users here may be using for help with coding in
> the Apache style. Currently I have;
>
> set tabstop=4
> set shiftwidth=4
> set expandtab
>
> Which are all reasonably obvious, but thought that others may have
> collated the corrent autoindent configurations, trapping of "{" on their
> own lines, the preferred comment format, and so on.
I use autocmd to set the types for C files.
Some relevant snippets:
" Makefiles ALWAYS must have real TABS
autocmd FileType make set noet
let c_syntax_for_h=1
autocmd FileType c set ts=4 sw=4 et cindent cino=:0(0 fo+=ro
If it helps, my full vimrc is at: http://www.ics.uci.edu/~jerenkra/vimrc
I also do funny things with tab characters and trailing spaces so that
they stick out like sore thumbs. It ensures that I get annoyed. ;-)
I'd be curious about what other features vim offers that I'm ignoring...
HTH. -- justin
Apache code-style vim tips
Just wondering what vim-users here may be using for help with coding in
the Apache style. Currently I have;
set tabstop=4
set shiftwidth=4
set expandtab
Which are all reasonably obvious, but thought that others may have
collated the corrent autoindent configurations, trapping of "{" on their
own lines, the preferred comment format, and so on.
--
Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: [PATCH] Make CacheEnable useful for forward proxies
On Tue, Aug 16, 2005 at 06:23:28PM -0700, Justin Erenkrantz wrote: > > - CacheDirLevels 5 > > - CacheDirLength 3 > > + CacheDirLevels 2 > > + CacheDirLength 1 > > Why are you changing these? (I don't think it's relevant to this patch.) Sorry, they slipped in, I'm currently working on a patch to the mod_cache documentation and a new Caching user guide. I thought I had cought everything from my diff. 5 & 3 as defaults are getting caught up in a lot of places, including mine and PaulQ's talks at ApacheConEU - and well, as I think was pointed out on the list last week, they're awful default values. > > +static int uri_hsp_meets_conditions(apr_uri_t filter, apr_uri_t url) > > I find 'hsp' to be rather non-intuitive. (It took me a bit to figure out what > it meant.) How about just uri_meets_conditions? Better. > And, why not push the path check to this function? At some point I think it was purely to lessen the ammount of confusion by having a 3 argument function with the pathlen's. Passing the container structure won't work, because they differ for cacheenable and cachedisable. I'll just make it a 3-argument function. > This cache_select_url function probably needs to get a new name. It may have > made sense a while ago; but the name doesn't seem to jive with its > implementation now. (AFAICT, this change is unrelated to the rest of the > patch.) That change is from getting rid of un-used variable compiler warnings. -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: RFC: can I make mod_cache per-dir?
On Wed, Aug 17, 2005 at 02:33:30AM +0100, Colm MacCarthaigh wrote: > > Why would the system trigger a match then? The configuration should block > > the > > requests from being processed. > > Because it would be basing its decision to serve a cached entity > entirely based on that entity being in the cache. See below. > > > # Don't cache these files at all > > > > > > CacheContent disk off > > > > > > > Should that be 'off' or 'none' or something else? What's disk doing here? > > In my implementation, it was removing disk from the list of caching > providers for that context :) The correct thing would be to clear the provider hash for that location. > I don't think it's that easy to achieve without triggering Graham's very > valid -1. The decision on whether to serve from the cache would be based > entirely on entities being in the cache, which is non-intuitive to > administrators. Oh. Ergh. I didn't catch that part of your proposal. Yah, -1 too. > There is a another way of doing it though, which would be to allow > CacheEnable directives on a per-dir basis but only within > blocks. > > So; > > > CacheEnable disk > > > might be equivalent to "CacheEnable disk /foo". It would be trivial to > make this work as-is, but seems fairly pointless. Location-based > application can be done already. That would be an improvement over what we have today. However, I wonder if we can store some information in our cache that can provide enough information for the check (i.e. done with directory/file). A thought: record the fact that this particular cache entry was originated through a directory check - this can also *only* happen when mod_cache is fronting a local origin server (nowhere else would Directory come into play). Under what I've deduced from your previous emails, we know this because we'd have to delay our cacheablity config check until cache_save_filter. So, if this bit is set, then we know we have to wait for the directory/location walk to run again before we can 'approve' serving the cached response. (Or, we could also try to run the directory walk ourselves in the cache handler.) Yet, there is a *possibility* that something could switch from a Location to a Directory (i.e. switch from a scenario where we could solely rely upon the configuration to where a directory now controls the cacheability: hence we need the dir walk). Not sure what we should do there. We'd certainly sacrifice some speed under these circumstances; but it'd perhaps be better than nothing and would avoid the possibility where we serve content that is now excluded. -- justin
Re: Performance proxy_ajp vs. mod_jk when TOMCAT integration with Apache
Hi, Can somebody tell me what the difference between the proxy_ajp and mod_jk is. thanks, Christine --- Mladen Turk <[EMAIL PROTECTED]> wrote: > Xuekun Hu wrote: > > Hi, > >>From performance point, which connector will be > used for TOMCAT > > intergration with Apache? proxy_ajp or mod_jk? > > > > I read some docs which said mod_jk should have > better performance than > > proxying. While proxy_ajp in Apache2.1 is an > addition to the mod_proxy > > and uses Tomcat's AJP protocol stack. So I ask the > upper question. > > > > Right, both mod_jk and proxy_ajp have almost the > same performance, > and they are up to twice as fast compared with http > mostly because > of constant connection pool. AJP protocol gives it's > share too > by transferring less data across the wire. > > If you are using Apache 2.1+ there is no need to use > mod_jk and > maintain additional module. > > Regards, > Mladen. > > - > To unsubscribe, e-mail: > [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] > > __ Do you Yahoo!? Yahoo! Mail - You care about security. So do we. http://promotions.yahoo.com/new_mail
Re: RFC: can I make mod_cache per-dir?
On Tue, Aug 16, 2005 at 06:13:38PM -0700, Justin Erenkrantz wrote: > On Mon, Aug 15, 2005 at 09:55:34AM +0100, Colm MacCarthaigh wrote: > > mod_cache configurability sucks big-time. CacheEnable adds yet another > > location mapping scheme for administrators to deal with, but this scheme > > lacks basic flexibility; > > > > It can't reliably disable caching for a directory. > > As I mentioned in my previous email, we know nothing about directories at the > time that the cache is run. We know everything about directories when entities are cached, and we know what entities have been cached when the cache is run :-) It's not even a big patch, it's just a bad idea ;-) But don't get trapped into thinking that this isn't technically easy either with the existing handler system. > > It's about 99.9% useless for a forward proxy configuration. ;-) > > I'm not sure why you think that. Can you expand upon this? See my patch making CacheEnable useful for a forward proxy :) > > 2. If an admin re-configures with caching enabled for less > >locations that they had previously, they have to know to > >either clear the cache or to know that the entities will > >still get served from the cache until they have expired. > >The patch includes a new Caching user guide, for this and > >other reasons. > > Why would the system trigger a match then? The configuration should block the > requests from being processed. Because it would be basing its decision to serve a cached entity entirely based on that entity being in the cache. > > # Don't cache these files at all > > > > CacheContent disk off > > > > Should that be 'off' or 'none' or something else? What's disk doing here? In my implementation, it was removing disk from the list of caching providers for that context :) > I do think this is likely a more intuitive way to configure it if we can do it > without impacting overall performance. I don't think it's that easy to achieve without triggering Graham's very valid -1. The decision on whether to serve from the cache would be based entirely on entities being in the cache, which is non-intuitive to administrators. There is a another way of doing it though, which would be to allow CacheEnable directives on a per-dir basis but only within blocks. So; CacheEnable disk might be equivalent to "CacheEnable disk /foo". It would be trivial to make this work as-is, but seems fairly pointless. Location-based application can be done already. > > But I'm still not finished, and I'd like some advice on what next. The > > per-dir information isn't availabe at the quick-handle stage, so the > > mod_cache handle has to rely on per-server config to decide which > > providers to try and use for serving content. (right now I've simply > > hard-coded mem and disk). > > Why must they be hard coded? They must not :-) I simply sensed that my diff's were rapidly becoming way out of the bounds of what others more knowledgeable than I would consider rational and decided to ask for comments for proceeding. Many thanks to all who did :) -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: RFC: can I make mod_cache per-dir?
On Wed, Aug 17, 2005 at 02:20:59AM +0100, Colm MacCarthaigh wrote: > On Tue, Aug 16, 2005 at 06:02:04PM -0700, Justin Erenkrantz wrote: > > The quick handler runs well before any knowledge is available about the > > backend (dir/file). The only thing you know is the URI path: > > unsurprisingly, > > this is all that CacheEnable and CacheDisable can reasonably work with. > > It's not the only thing, we also have the Cache provider itself. > > If that lookup is quick enough (it certainly would be for say > mod_mem_cache) that's how you determine if it's cached. > > From experience with mod_disk_cache, I don't it's hit as all that > expensive either, I run millions of requests through "CacheEnable disk > /" per day without problem, but I still have to concede it is going to > be slower than a few strcmp's. Oh, so you mean to see if previous requests have cached it? But, again, that doesn't show you a 'negative' (non-cacheable) response. And, we already have to do this - so I'm not sure what you mean here. > By the time the cache_save_filter is run, the directory walks have > happened, so deciding cachability there is trivial. Right. But, that's not telling us anything about whether its cacheable or not. > > The only way to resolve this is to do the directory walks and file > > resolution; > > but that is *very* expensive to do per request. -- justin > > My changes didn't need this at all. Oh. *light bulb* Let me see if I understand what you are proposing: only exclude saving the request by redoing the configuration check in cache_save_filter. We still have to go through the entire process as if we were to cache the request; but we'd block it at the last second from actually being saved in the filter. Yah, I guess that could work. -- justin
Re: [PATCH] Make CacheEnable useful for forward proxies
On Tue, Aug 16, 2005 at 01:32:03PM +0100, Colm MacCarthaigh wrote: > > More mod_cache fix-ups; > > "CacheEnable /" > > isn't very useful for forward proxy servers. This patch makes; > > CacheEnable / > CacheEnable ftp:// > CacheEnable http://somesite/ > CacheDisablewww.apache.org/blah/ > CacheDisableftp:// > CacheDisablehttp://httpd.apache.org/manual/ > > work. Comments inline. > Index: docs/manual/mod/mod_cache.html.en > === > --- docs/manual/mod/mod_cache.html.en (revision 232960) > +++ docs/manual/mod/mod_cache.html.en (working copy) > @@ -87,14 +96,14 @@ >> > #LoadModule disk_cache_module modules/mod_disk_cache.so > -# If you want to use mod_disk_cache instead of mod_mem_cache, > -# uncomment the line above and comment out the LoadModule line below. > +# If you want to use mod_disk_cache instead of mod_mem_cache, > +# uncomment the line above and comment out the LoadModule line > below. > > >CacheRoot c:/cacheroot >CacheEnable disk / > - CacheDirLevels 5 > - CacheDirLength 3 > + CacheDirLevels 2 > + CacheDirLength 1 Why are you changing these? (I don't think it's relevant to this patch.) ..snip... > Index: modules/cache/cache_util.c > === > --- modules/cache/cache_util.c(revision 232960) > +++ modules/cache/cache_util.c(working copy) > @@ -24,23 +24,64 @@ > > extern module AP_MODULE_DECLARE_DATA cache_module; > > +/* Determine if "url" matches the hostname, scheme and port found > + * in "filter". Comparisons are case-insensitive. > + */ > +static int uri_hsp_meets_conditions(apr_uri_t filter, apr_uri_t url) I find 'hsp' to be rather non-intuitive. (It took me a bit to figure out what it meant.) How about just uri_meets_conditions? And, why not push the path check to this function? ...snip... > @@ -114,7 +106,7 @@ > * add cache_out filter > * return OK > */ > -rv = cache_select_url(r, url); > +rv = cache_select_url(r); > if (rv != OK) { > if (rv == DECLINED) { > if (!lookup) { This cache_select_url function probably needs to get a new name. It may have made sense a while ago; but the name doesn't seem to jive with its implementation now. (AFAICT, this change is unrelated to the rest of the patch.) ...snip... The rest of it looks fine. +1. -- justin
Re: RFC: can I make mod_cache per-dir?
On Tue, Aug 16, 2005 at 06:02:04PM -0700, Justin Erenkrantz wrote: > The quick handler runs well before any knowledge is available about the > backend (dir/file). The only thing you know is the URI path: unsurprisingly, > this is all that CacheEnable and CacheDisable can reasonably work with. It's not the only thing, we also have the Cache provider itself. If that lookup is quick enough (it certainly would be for say mod_mem_cache) that's how you determine if it's cached. >From experience with mod_disk_cache, I don't it's hit as all that expensive either, I run millions of requests through "CacheEnable disk /" per day without problem, but I still have to concede it is going to be slower than a few strcmp's. By the time the cache_save_filter is run, the directory walks have happened, so deciding cachability there is trivial. > The only way to resolve this is to do the directory walks and file resolution; > but that is *very* expensive to do per request. -- justin My changes didn't need this at all. -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: RFC: can I make mod_cache per-dir?
On Mon, Aug 15, 2005 at 09:55:34AM +0100, Colm MacCarthaigh wrote: > mod_cache configurability sucks big-time. CacheEnable adds yet another > location mapping scheme for administrators to deal with, but this scheme > lacks basic flexibility; > > It can't reliably disable caching for a directory. As I mentioned in my previous email, we know nothing about directories at the time that the cache is run. The problem is identical for any external caches that have no knowledge of the file paths that the origin server has. > It's about 99.9% useless for a forward proxy configuration. ;-) I'm not sure why you think that. Can you expand upon this? > It can't do regex matching, unlike every other part of Apache. That is fairly trivial to resolve. However, regexes are extremely expensive. > It involves some fairly pants linear searches through the url lists, > which means not a hope of implementing complex configurations while > keeping the performance mod_cache is supposed to be for :-/ Hmm? > I'm guessing that the majority of CacheEnable instances out there in the > world probably take "/" as their url argument. For this case, the > changes I've made speed things up. For other cases there is some small > potential slowdown, for example if you had only; > > CacheEnable disk /wiki/ > > Previously mod_cache would have done a url match at the handle stage and > if it didn't match, that would have been that. With this patch, it > instead looks up the url with the caching provider directly. This has > two consequences; I don't understand what you mean. > 1. It means all requests are hit with the cost of a lookup > in the cache provider, but this shouldn't be expensive. > It's already what most sites are doing. And even with > mod_disk_cache it's relatively painless, just a hashcalc > and an attempt at open(). > > Either way, the url match functionality at this stage can > be added back trivially, but I decided not to in my patch > because it's so confusing to have. Hmm? > 2. If an admin re-configures with caching enabled for less > locations that they had previously, they have to know to > either clear the cache or to know that the entities will > still get served from the cache until they have expired. > The patch includes a new Caching user guide, for this and > other reasons. Why would the system trigger a match then? The configuration should block the requests from being processed. > As I was saying; What I've done gets rid of the CacheEnable and > CacheDisable directives, and instead lets you do this; > > # Cache everything to memory, or then disk > CacheContent mem disk > > # Cache content for /foo/ to disk only > > CacheContent disk > > > # Don't cache these files at all > > CacheContent disk off > Should that be 'off' or 'none' or something else? What's disk doing here? > > # Only cache to disk > CacheConent disk > > > http://securityupdates/dist/> > # Don't cache the list of security updates, ever > CacheContent off > > > > # This vhost should never be cached > CacheContent off > I do think this is likely a more intuitive way to configure it if we can do it without impacting overall performance. > But I'm still not finished, and I'd like some advice on what next. The > per-dir information isn't availabe at the quick-handle stage, so the > mod_cache handle has to rely on per-server config to decide which > providers to try and use for serving content. (right now I've simply > hard-coded mem and disk). Why must they be hard coded? > There are two options for doing this; > > 1. Register any providers used by CacheContent at the config > stage in the per-server conf. Has the advantage of reducing > the ammount of directives involved and minimisming admin > confusion. Disadvantages; Makes using CacheContent in > htaccess files a bit iffy, there would have to be a > CacheContent directive in the base config files first. > Making the order providers are tried in would also be a > bit of a pain. Why should these be in htaccess? There should not be any directory walking. > 2. Adding a another directive. "CacheEnable" makes the most > sense as a name, but it would also be a change in its > behaviour. So "CacheServe" as a name might be an option. > This would be a per-server directive, that says; > > "CacheEnable mem disk" > > Which would mean serve from memory, or then disk (ie in > that order) for this server. > > I vastly prefer 2. myself, but I'd like to know what hope (if any) have > I of getting
Re: Performance proxy_ajp vs. mod_jk when TOMCAT integration with Apache
proxy_ajp is mod_jk successor in Apache2.1/2.2 core. You can find more info: http://httpd.apache.org/docs-2.1/mod/mod_proxy.html http://httpd.apache.org/docs-2.1/mod/mod_proxy_ajp.html http://httpd.apache.org/docs-2.1/mod/mod_proxy_balancer.html Thx, Xuekun On 8/17/05, Christine Ho <[EMAIL PROTECTED]> wrote: > Hi, > Can somebody tell me what the difference between > the proxy_ajp and mod_jk is. > > thanks, > Christine
Re: RFC: can I make mod_cache per-dir?
On Mon, Aug 15, 2005 at 01:29:13PM +0100, Colm MacCarthaigh wrote: > My main reason is that I can't enable or disable caching on a > per-directory or per-file basis. The quick handler runs well before any knowledge is available about the backend (dir/file). The only thing you know is the URI path: unsurprisingly, this is all that CacheEnable and CacheDisable can reasonably work with. The only way to resolve this is to do the directory walks and file resolution; but that is *very* expensive to do per request. -- justin
Re: [PATCH] Make CacheEnable useful for forward proxies
Colm MacCarthaigh wrote: More mod_cache fix-ups; "CacheEnable /" isn't very useful for forward proxy servers. This patch makes; CacheEnable / CacheEnable ftp:// CacheEnable http://somesite/ CacheDisablewww.apache.org/blah/ CacheDisableftp:// CacheDisablehttp://httpd.apache.org/manual/ work. +1 in concept, this is very cool (haven't had a chance to test the patch itself yet, when my inbox dips below 1000 I'll do it). Regards, Graham --
Re: svn commit: r220307 - in /httpd/httpd/trunk/modules: metadata/mod_setenvif.c ssl/mod_ssl.c ssl/mod_ssl.h ssl/ssl_expr_eval.c
On Tue, Aug 16, 2005 at 04:45:41PM +0100, David Reid wrote:
> Joe Orton wrote:
> > On Mon, Aug 15, 2005 at 02:36:18PM +0100, Joe Orton wrote:
> >
> >>I just went to write a test case for the SetEnvIf function, and there
> >>seems to be a rather annoying fundamental problem: the match_headers
> >>hooks runs too early to be useful for this when doing per-dir client
> >>cert negotiation.
> >
> >
> > I can't see any simple way round this, and I don't think this feature
> > should go in 2.2 unless this can be solved. Any ideas?
>
> I've not looked at it in detail, so would have to dig through the code.
> Care to post your test case?
Well, try testing it in any configuration with "SSLVerifyClient require"
in Directory or Location context rather than in the vhost context.
httpd-test test case:
mkdir t/htdocs/modules/setenvif/ssl
+ applying
Index: t/conf/extra.conf.in
===
--- t/conf/extra.conf.in(revision 231019)
+++ t/conf/extra.conf.in(working copy)
@@ -358,6 +358,11 @@
Options +Includes
AllowOverride All
+
+
+Options +Includes
+AllowOverride All
+
##
Index: t/htdocs/modules/setenvif/ssl/.htaccess
===
--- t/htdocs/modules/setenvif/ssl/.htaccess (revision 0)
+++ t/htdocs/modules/setenvif/ssl/.htaccess (revision 0)
@@ -0,0 +1 @@
+SetEnvIf SSL_PeerExtList("2.16.840.1.113730.1.13") "(.*)" NETSCAPE_COMMENT=$1
Property changes on: t/htdocs/modules/setenvif/ssl/.htaccess
___
Name: svn:eol-style
+ native
Index: t/htdocs/modules/setenvif/ssl/peerextlist.shtml
===
--- t/htdocs/modules/setenvif/ssl/peerextlist.shtml (revision 0)
+++ t/htdocs/modules/setenvif/ssl/peerextlist.shtml (revision 0)
@@ -0,0 +1 @@
+0:
Property changes on: t/htdocs/modules/setenvif/ssl/peerextlist.shtml
___
Name: svn:eol-style
+ native
Index: t/ssl/setenvif.t
===
--- t/ssl/setenvif.t(revision 0)
+++ t/ssl/setenvif.t(revision 0)
@@ -0,0 +1,21 @@
+use strict;
+use warnings FATAL => 'all';
+
+use Apache::Test;
+use Apache::TestRequest;
+use Apache::TestUtil;
+
+plan tests => 2, need 'setenvif', need_min_apache_version("2.1.6");
+
+Apache::TestRequest::scheme("https");
+
+my $r = GET("/require/asf/modules/setenvif/ssl/peerextlist.shtml", cert =>
'client_ok');
+
+ok t_cmp($r->code, 200, "fetched page works");
+
+my $c = $r->content;
+
+chomp $c;
+
+ok t_cmp($c, "0:This Is A Comment", "Retrieve nsComment extension");
+
Re: svn commit: r220307 - in /httpd/httpd/trunk/modules: metadata/mod_setenvif.c ssl/mod_ssl.c ssl/mod_ssl.h ssl/ssl_expr_eval.c
Joe Orton wrote: > On Mon, Aug 15, 2005 at 02:36:18PM +0100, Joe Orton wrote: > >>I just went to write a test case for the SetEnvIf function, and there >>seems to be a rather annoying fundamental problem: the match_headers >>hooks runs too early to be useful for this when doing per-dir client >>cert negotiation. > > > I can't see any simple way round this, and I don't think this feature > should go in 2.2 unless this can be solved. Any ideas? I've not looked at it in detail, so would have to dig through the code. Care to post your test case? david
Re: New mod_smtpd release
On Aug 16, 2005, at 6:47 AM, Nick Kew wrote: Rian Hunter wrote: [chop] I think I should have looked harder before replying ... looks like you've done more than I realised. I guess what I was asking about slots easily in to data_post ? Which question exactly? -rian
Re: New mod_smtpd release
On Aug 16, 2005, at 6:37 AM, Nick Kew wrote:
Spooling and dealing with multiple recipients are things I'd like to
think about now. ISTR posting about this before: I think each
recipient
needs a separate request processing cycle, because each recipient may
have completely different processing rules. Do you think we can deal
with that by creating a new suprequest for each recipient? If so,
we'll need to allow filter hooks both before and after subrequesting,
and pass each one the spooled input data.
I've thought about this and it has sort of been an avoided topic but
I think the current plan is that in smtpd_run_queue (the hook where
modules should queue or deliver the message) each registered hook
will be called with the recipient list and access to the message
until one of them returns something other than SMTPD_DECLINED or
SMTPD_OK (unlike smtpd_run_rcpt, which will stop when a module
returns SMTPD_OK).
For instance let's say you have a mail message with two recipients:
[EMAIL PROTECTED] and [EMAIL PROTECTED] and you want each to be dealt
with by different modules because one is a local address and one
should be relayed. The modules are mod_smtpd_queue_local and
mod_smtpd_queue_relay. Both of the modules have some means of
configuration which lets them know what email addresses they accept.
When smtpd_run_queue is called on them, they only accept the email
addresses they are configured for and ignore the rest. Of course if
not one module returns SMTPD_OK then we respond with some sort of 4**
error saying that we don't have a queue-er. When a server admin is
configuring the accepted email addresses for each module he should be
sure the their respective lists are mutually exclusive else he'll get
the same addresses being handled by two modules which is probably bad
news.
This design seems to satisfy the modularity that I was expecting from
mod_smtpd. Disabling local delivery or relay can be as simple as not
loading a module in a server config. Maybe mod_smtpd can even specify
a convention for email address acceptance lists like:
SmtpAcceptList my_list1 mysql://foo
SmtpAcceptList my_list2 regex:[EMAIL PROTECTED]
LocalQueueAccept my_list1
RelayQueueAccept my_list2
and mod_smtpd_queue_{local,relay} both know that they accept mail
from my_list1 and my_list2 repectively.
The problem with this design is that you have repetitious string
comparisons for each hook on smtp_run_queue. This is not a big
problem except for when the recipient list is long (~40 recipients)
and you have maybe three modules handling mail queuing. My short term
solution is that each module remove mail addresses from the recipient
list that they handled, so the list grows shorter as each queue hook
is called (this also solves the problem of email addresses handled
twice). Another short term fix for this is having mod_smtpd hash the
recipient list (md5?) as another list passed so comparisons and
lookups are quicker. I think this problem is a trade-off though for
our modularity.
Either way, lacking header parsing in mod_smtpd is being
impractically pedant since probably 99% of SMTP transfers involve
messages in the RFC 2822/MIME formats. Although I think that
maybe there will be a plugin that wants data from the DATA
command verbatim. I still feel this needs some thought.
Agreed. Maybe a hook for DATA could deal with pathological cases,
with
normal header/body handling the default? But I haven't thought it
through: I wasn't even aware of the notion of smtp-without-RFC(2)822.
I figure we'll have an input filter registered and if the data
doesn't look like RFC-(2)822, then it passes it on verbatim.
-rian
[PATCH] Make CacheEnable useful for forward proxies
More mod_cache fix-ups; "CacheEnable /" isn't very useful for forward proxy servers. This patch makes; CacheEnable / CacheEnable ftp:// CacheEnable http://somesite/ CacheDisablewww.apache.org/blah/ CacheDisableftp:// CacheDisablehttp://httpd.apache.org/manual/ work. -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED] Index: docs/manual/mod/mod_cache.html.en === --- docs/manual/mod/mod_cache.html.en (revision 232960) +++ docs/manual/mod/mod_cache.html.en (working copy) @@ -87,14 +96,14 @@#LoadModule disk_cache_module modules/mod_disk_cache.so -# If you want to use mod_disk_cache instead of mod_mem_cache, -# uncomment the line above and comment out the LoadModule line below. +# If you want to use mod_disk_cache instead of mod_mem_cache, +# uncomment the line above and comment out the LoadModule line below. + +# When acting as a proxy, don't cache the list of security updates +CacheDisable http://security.update.server/update-list/ @@ -185,6 +197,20 @@ CacheEnable disk / +When acting as a forward proxy server, url-string can +also be used to specify remote sites and proxy protocols which +caching should be enabled for. + + + # Cache proxied url's + CacheEnable disk / + # Cache FTP-proxied url's + CacheEnable disk ftp:/// + # Cache content from www.apache.org + CacheEnable disk http://www.apache.org/ + + + CacheIgnoreCacheControl Directive Index: docs/manual/mod/mod_cache.xml === --- docs/manual/mod/mod_cache.xml (revision 232960) +++ docs/manual/mod/mod_cache.xml (working copy) @@ -86,14 +95,14 @@CacheRoot c:/cacheroot CacheEnable disk / - CacheDirLevels 5 - CacheDirLength 3 + CacheDirLevels 2 + CacheDirLength 1 @@ -108,6 +117,9 @@ MCacheMaxObjectSize 2048#LoadModule disk_cache_module modules/mod_disk_cache.so -# If you want to use mod_disk_cache instead of mod_mem_cache, -# uncomment the line above and comment out the LoadModule line below. +# If you want to use mod_disk_cache instead of mod_mem_cache, +# uncomment the line above and comment out the LoadModule line below. + +# When acting as a proxy, don't cache the list of security updates +CacheDisable http://security.update.server/update-list/ @@ -145,6 +157,20 @@ CacheEnable fd/images CacheEnable disk / + +When acting as a forward proxy server, url-string can +also be used to specify remote sites and proxy protocols which +caching should be enabled for. + + + # Cache proxied url's + CacheEnable disk / + # Cache FTP-proxied url's + CacheEnable disk ftp:/// + # Cache content from www.apache.org + CacheEnable disk http://www.apache.org/ + + Index: modules/cache/cache_util.c === --- modules/cache/cache_util.c (revision 232960) +++ modules/cache/cache_util.c (working copy) @@ -24,23 +24,64 @@ extern module AP_MODULE_DECLARE_DATA cache_module; +/* Determine if "url" matches the hostname, scheme and port found + * in "filter". Comparisons are case-insensitive. + */ +static int uri_hsp_meets_conditions(apr_uri_t filter, apr_uri_t url) +{ +/* Compare the hostnames */ +if(filter.hostname) { +if (!url.hostname) { +return 0; +} +else if (strcasecmp(filter.hostname, url.hostname)) { +return 0; +} +} +/* Compare the schemes */ +if(filter.scheme) { +if (!url.scheme) { +return 0; +} +else if (strcasecmp(filter.scheme, url.scheme)) { +return 0; +} +} + +/* Compare the ports */ +if(filter.port_str) { +if (url.port_str && filter.port != url.port) { +return 0; +} +/* NOTE: ap_port_of_scheme will return 0 if given NULL input */ +else if (filter.port != apr_uri_port_of_scheme(url.scheme)) { +CacheRoot c:/cacheroot CacheEnable disk / - CacheDirLevels 5 - CacheDirLength 3 + CacheDirLevels 2 + CacheDirLength 1 @@ -107,6 +116,9 @@ MCacheMaxObjectSize 2048
Re: svn commit: r220307 - in /httpd/httpd/trunk/modules: metadata/mod_setenvif.c ssl/mod_ssl.c ssl/mod_ssl.h ssl/ssl_expr_eval.c
On Mon, Aug 15, 2005 at 02:36:18PM +0100, Joe Orton wrote: > I just went to write a test case for the SetEnvIf function, and there > seems to be a rather annoying fundamental problem: the match_headers > hooks runs too early to be useful for this when doing per-dir client > cert negotiation. I can't see any simple way round this, and I don't think this feature should go in 2.2 unless this can be solved. Any ideas? joe
Re: New mod_smtpd release
Rian Hunter wrote: [chop] I think I should have looked harder before replying ... looks like you've done more than I realised. I guess what I was asking about slots easily in to data_post ? -- Nick Kew
Re: New mod_smtpd release
Rian Hunter wrote: Well not exactly. A module that parses headers can register itself as an input_filter for mod_smtpd. It can parse the headers and the headers can be accessed by a get_smtpd_headers(request_rec*) function or similar exported by the parsing module, and modules that rely on this module will know about that API. This module can even be included with the default mod_smptd package. Do you agree that this is possible? It should certainly be included with the mod_smtpd package. Is there any reason why the existing header parsing code for http shouldn't be used for this? AFAICS, the new things we have to deal with for SMTP are: - smtp handshake and envelope (which you've done) - spooling - dealing with multiple recipients - dealing with MIME message MIME decoding of multipart messages is something I'd like to see (for spam filtering), but it's not an immediate priority. If we have the initial RFC822 headers in r->headers_in, that'll be fine for now. Spooling and dealing with multiple recipients are things I'd like to think about now. ISTR posting about this before: I think each recipient needs a separate request processing cycle, because each recipient may have completely different processing rules. Do you think we can deal with that by creating a new suprequest for each recipient? If so, we'll need to allow filter hooks both before and after subrequesting, and pass each one the spooled input data. Either way, lacking header parsing in mod_smtpd is being impractically pedant since probably 99% of SMTP transfers involve messages in the RFC 2822/MIME formats. Although I think that maybe there will be a plugin that wants data from the DATA command verbatim. I still feel this needs some thought. Agreed. Maybe a hook for DATA could deal with pathological cases, with normal header/body handling the default? But I haven't thought it through: I wasn't even aware of the notion of smtp-without-RFC(2)822. -- Nick Kew
Re: [PATCH] use arrays in smtpd_request_rec
On Aug 15, 2005, at 10:05 PM, Garrett Rooney wrote:
Joe Schaefer wrote:
Garrett Rooney <[EMAIL PROTECTED]> writes:
Index: smtp_protocol.c
===
--- smtp_protocol.c(revision 232680)
+++ smtp_protocol.c(working copy)
[...]
+for (i = 0; i < sr->extensions->nelts; ++i) {
+ ap_rprintf(r, "%d-%s\r\n", 250, ((char **)sr->extensions-
>nelts)[i]);
^
That should be "elts", shouldn't it?
Yes indeed, it should. One of the problems with data structures
that require casting in order to access what you've stored in
them... The version that Rian committed is slightly different, but
still has the same problem. I'd post a patch, but it's probably
faster to fix it by hand than it is to detach a patch from an email
and apply it.
Over in Subversion-land we have a couple of macros defined for
dealing with apr arrays, they make it rather difficult to make this
kind of mistake, and I'd love to see them in the main APR release,
but the last time it was brought up I believe someone objected to
their inclusion...
-garrett
Fixed. I didn't even catch this because I don't test mod_smtpd with a
plugin that registers extensions. Things like this beckon some kind
of test suite module. Someone can get to this after mod_smtpd is redone.
-rian
Re: svn commit: r220307 - in /httpd/httpd/trunk/modules: metadata/mod_setenvif.c ssl/mod_ssl.c ssl/mod_ssl.h ssl/ssl_expr_eval.c
On Mon, Aug 15, 2005 at 02:36:18PM +0100, Joe Orton wrote:
> OK, hope you had a good holiday. I wasn't trying to argue about the
> semantics just to nitpick the naming. Having "SSL" in the SSLRequire
> function is redundant, but not in the context of mod_setenvif. So, my
> preference is:
>
> SSLRequire "committers" in PeerExtList("1.3.6.1.4.1.18060.1");
>
> SetEnvIf SSL_PeerExtList("etc") ...
>
+1 on concept
vh
Mads Toftum
--
`Darn it, who spiked my coffee with water?!' - lwall
Re: svn commit: r220307 - in /httpd/httpd/trunk/modules: metadata/mod_setenvif.c ssl/mod_ssl.c ssl/mod_ssl.h ssl/ssl_expr_eval.c
Joe Orton wrote:
> On Fri, Aug 05, 2005 at 08:00:01PM +0200, Martin Kraemer wrote:
>
>>On Tue, Aug 02, 2005 at 07:14:10PM +0200, Martin Kraemer wrote:
>>
>>>I wanted something like
>>>
>>> SSLRequire "committers" in SSLPeerExtList("1.3.6.1.4.1.18060.1");
>>>
>>>to mean "at least one extension with an OID of
>>>1.3.6.1.4.1.18060.1 with a value of 'committers' exists in the
>>>client cert".
>>
>>I'll be on vacation next week, and will send in another patch after
>>that.
>
>
> OK, hope you had a good holiday. I wasn't trying to argue about the
> semantics just to nitpick the naming. Having "SSL" in the SSLRequire
> function is redundant, but not in the context of mod_setenvif. So, my
> preference is:
>
> SSLRequire "committers" in PeerExtList("1.3.6.1.4.1.18060.1");
>
> SetEnvIf SSL_PeerExtList("etc") ...
+1 on the revised naming.
Patch looks OK as well.
david
Re: howto retrieve request URI args and request body within an output filter module?
Have you checked libapreq2? By the way, if I recall correctly, it is a candidate for integration into httpd (or APR/APR-UTIL). Christian Parpart wrote: > > Hi all, > > I was looking for a module which I can use for publishing my XML/XSLT based > web application on; That means, simple static transformation are not enough, > as *EVERY* new request to the same .xml file may potentially change the > result; > > finally, I found mod_transform[1] somewhat usefull, but it - obviousely - > doesn't fit all the needs I have to have as it (e.g.) does not pass request > arguments from GET and PUT to the XSLT stylesheet :( > > though, my question: how do I get these from within that .xml output filter? > > Thanks in advance, > Christian Parpart. -- Eli Marmor [EMAIL PROTECTED] Netmask (El-Mar) Internet Technologies Ltd. __ Tel.: +972-9-766-1020 8 Yad-Harutzim St. Fax.: +972-9-766-1314 P.O.B. 7004 Mobile: +972-50-5237338 Kfar-Saba 44641, Israel
Re: mod_dnsbl_lookup 0.90
On Mon, Aug 15, 2005 at 11:11:46PM -0500, Jem Berkes wrote: > I did start to implement software side caching in mod_dnsbl_lookup but it > raised questions as to whether it's appropriate to have global scale > caching when we're doing connection and request oriented processing. > > So I've left caching out of mod_dnsbl_lookup 0.91 That's fair enough, it's a pain to implement. mod_smtpd is unlikely to make multiple serialised RBL lookups like exim or sendmail on a per-request basis anyway, so there may not even be as much benefit. -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
howto retrieve request URI args and request body within an output filter module?
Hi all, I was looking for a module which I can use for publishing my XML/XSLT based web application on; That means, simple static transformation are not enough, as *EVERY* new request to the same .xml file may potentially change the result; finally, I found mod_transform[1] somewhat usefull, but it - obviousely - doesn't fit all the needs I have to have as it (e.g.) does not pass request arguments from GET and PUT to the XSLT stylesheet :( though, my question: how do I get these from within that .xml output filter? Thanks in advance, Christian Parpart. -- 09:24:36 up 145 days, 22:32, 1 user, load average: 0.34, 0.52, 0.44 pgpQgg65vASIP.pgp Description: PGP signature
Notification from PayPal #ATP 968540-350209-8595-6840595
Dear valued PayPal member:It has come to our attention that your PayPal account information needs to beupdated as part of our continuing commitment to protect your account and toreduce the instance of fraud on our website. If you could please take 5-10 minutesout of your online experience and update your personal records you will not run intoany future problems with the online service.However, failure to update your records will result in account suspension.Please update your records on or before August 19, 2005.Once you have updated your account records, your PayPal session will not beinterrupted and will continue as normal.To update your PayPal records click on the following link:https://www.paypal.com/cgi-bin/webscr?cmd=_login-run Thank You.PayPal UPDATE TEAM Accounts Management As outlined in our User Agreement, PayPal willperiodically send you information about site changes and enhancements. Visit our Privacy Policy and User Agreement if you have any questions. http://www.paypal.com/cgi-bin/webscr?cmd=p/gen/ua/policy_privacy-outside
