On Wed, Sep 04, 2002 at 12:41:09AM -0700, Greg Stein wrote:
> 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.
This came up before on dev@httpd, I thought the problem is that the PHP
output filter just doesn't really filter: I'm no filtering guru, but if
you look at sapi/apache2filter/sapi_apache2.c:php_output_filter, it only
processes FILE buckets, and for them it extracts the filename using
apr_file_name_get and passes that to the Zend engine. (at least in PHP
4.2.2).
Regards,
joe
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Sep 4 10:54:32 2002