Re: Dynamic content and the order of httpd2 module processing

On Tue, Sep 03, 2002 at 10:38:23PM -0700, David Mankin wrote:
> On Tuesday, September 3, 2002, at 07:50 PM, Justin Erenkrantz wrote:
>...
> > You might want to try:
> >
> > AddOutputFilter php .php
> >
> > Yet, I'm not convinced that will work as I think we'd have to
> > rerun mod_mime or something like that once we know what the
> > 'file' extension is. (I think the path_info components aren't
> > tested in mod_mime.)
> >
> > If that doesn't work, then we probably need to rethink how mod_dav
> > delivers content so that we can get this to work. -- justin
>
> Short of reworking mod_dav, you might be able to setup proxying... I
> haven't tried this, but you might be able to get apache to proxy to
> itself so that, for instance, the repository is served on port 81, and
> then the port 80 requests are proxied onto the port 81 server. (That
> part should be quite doable.) Getting apache to then run the pages
> through php before returning them to the browser might be possible.

Bleck. mod_dav just shoves brigades into the output filters. It should "just
work". No need for proxying or any such stuff.

The problem stems with getting the (PHP) filter inserted into the output
filter chain, rather than any specific issue with mod_dav.

[ the concept here being that mod_dav simply supplies content to the chain;
  get the filters arranged properly, and you'll be set ]

Note: I'm not trying to shift blame off of mod_dav. I'm not going to state
it is Perfection Incarnate(tm). It is simply that mod_dav behaves in terms
of the "ideal" "content generator" and that Apache "ideally" should be
setting up a (output) filter chain to process the generated content
appropriately. The *goal* of the Apache filter design is to enable this
situation, so if we aren't getting the PHP filter in there, then the Apache
design needs to be tweaked.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org