cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ben Laurie <>
Subject Re: extensions in public URIs [was: RE: Variations on a theme by Cocoon]
Date Thu, 17 Feb 2000 09:28:18 GMT
Pierpaolo Fumagalli wrote:
> Stefano Mazzocchi wrote:
> >
> > Ben Laurie wrote:
> > >
> > > Y'know, the thing that's worrying me about all this is that Apache
> > > already has considerable power to do this kind of matching, [...]
> >
> > I am worried too.
> >
> > I do see the overlap and I do see the problems.... probably Cocoon might
> > well get merged in Apache 2.1... or even become the next apache using
> > tomcat + the protocol native libraries... who knows.
> >
> > Anyway, don't forget Cocoon is a servlet, thus should not presume
> > anything about the running environment.
> I am not really worried... First of all because Cocon 2.0 is completely
> abstracted from the web server. It's not even a Servlet anymore (or
> better, not only a servlet), so, even if there's some overlap, in our
> case that overlap is nedeed...
> And anyway the overlap is just on the matching part... We do all the
> translation that apache doesn't do right now (BTW, I know
> mod_rewrite)... IMVHO it's a completely different model...

The issue is that if I want some particular subset of URLs to be served
by a particular Cocoon processing chain, but _also_ have, say,
restricted access, I have to ensure that the Cocoon and Apache configs
match exactly. This is difficult and risky. The simple fix is to allow
(but not require) the sitemap to match on handler (or environment
variables, which can also be set in a variety of circumstances in
Apache), then the sysadmin can choose which approach to take. If you
also (optionally) allow the source file to be the result of Apache doing
the URL translation (which is available in the environment), then the
problem is solved without compromising the generality of sitemaps.




Y19100 no-prize winner!

View raw message