Combining SSI, PHP, and CGI in Apache 2.x

[Mxsmanic]

How can I combine SSI, CGI, and PHP in Apache 2.x? I keep reading that
this can be done, but I haven't found any examples of the actual
configuration required to do it.

What I want to do is:

1. Either pull the page from a file or generate it with a CGI program
(depending on the individual URL, as usual).

2. Run the output from (1) above through the includes module so that SSI
calls are expanded.

3. Run the output from (2) above through PHP so that any PHP code is
expanded and executed (including any PHP code in files included by the
SSI from the previous step).

I want to do this for every page.

I'm under the impression that Apache 2.0 can do this. So how is it
done?

--
Transpose hotmail and mxsmanic in my e-mail address to reach me directly.

[Sean]

On Sat, 15 Jan 2005 01:37:19 +0100, Mxsmanic <mx******@hotmail.com>
reverently intoned upon the aether:

How can I combine SSI, CGI, and PHP in Apache 2.x? I keep reading that
this can be done, but I haven't found any examples of the actual
configuration required to do it.

What I want to do is:

1. Either pull the page from a file or generate it with a CGI program
(depending on the individual URL, as usual).

2. Run the output from (1) above through the includes module so that SSI
calls are expanded.
Why use SSI when you can simply use include(), require(),
include_once(), and require_once() within PHP code. This will let
create a far more dynamic include structure than you will get using
SSI. Even better, an included file can call include() so you have
recursion which did not work in SSI the last time I checked.

In short, PHP has a more powerful include structure than SSI gives, so
why bother with the extra step at all.

3. Run the output from (2) above through PHP so that any PHP code is
expanded and executed (including any PHP code in files included by the
SSI from the previous step).

I want to do this for every page.

I'm under the impression that Apache 2.0 can do this. So how is it
done?

As for your general question, run the CGI program based on user input
and then have it redirect the user to the PHP script. How is this
done? Well, it depends on the language you are writing the cgi code
in.

And unless you are using a precoded cgi routine or need a cgi specific
tool, then why not just use PHP for the whole thing?

enjoy,

Sean


"In the End, we will remember not the words of our enemies,
but the silence of our friends."

- Martin Luther King Jr. (1929-1968)

Photo Archive @ http://www.tearnet.com/Sean
Last Updated 29 Sept. 2004

[News Me]

Sean wrote:
[snip]

SSI. Even better, an included file can call include() so you have
recursion which did not work in SSI the last time I checked.

An included file being able to include another file is not an example of
recursion, it is an example of nesting. Recursion is the capability of
a function to call itself. A file including itself is recursive only in
a very general sense and it would not produce a meaningful outcome.

NM

--
convert uppercase WORDS to single keystrokes to reply

[Mxsmanic]

Sean writes:

Why use SSI when you can simply use include(), require(),
include_once(), and require_once() within PHP code. This will let
create a far more dynamic include structure than you will get using
SSI. Even better, an included file can call include() so you have
recursion which did not work in SSI the last time I checked.

In short, PHP has a more powerful include structure than SSI gives, so
why bother with the extra step at all.
In short, you don't have an answer for my question. Maybe someone else
will.
As for your general question, run the CGI program based on user input
and then have it redirect the user to the PHP script. How is this
done? Well, it depends on the language you are writing the cgi code
in.
I don't care how it's done, because that's not what I want to do. I
want the Perl CGI program to generate output that is then parsed by
mod_include, and then processed by PHP.
And unless you are using a precoded cgi routine or need a cgi specific
tool, then why not just use PHP for the whole thing?

This isn't a class project, it's a production site with thousands of
files that must remain coherent, consistent, and maintainable.

I still need an answer to my question.

--
Transpose hotmail and mxsmanic in my e-mail address to reach me directly.

[Chris Newey]

"Mxsmanic" <mx******@hotmail.com> wrote in message
news:lu********************************@4ax.com...
| Sean writes:
|
| > Why use SSI when you can simply use include(), require(),
| > include_once(), and require_once() within PHP code. This will let
| > create a far more dynamic include structure than you will get using
| > SSI. Even better, an included file can call include() so you have
| > recursion which did not work in SSI the last time I checked.
| >
| > In short, PHP has a more powerful include structure than SSI gives, so
| > why bother with the extra step at all.
|
| In short, you don't have an answer for my question. Maybe someone else
| will.
|
| > As for your general question, run the CGI program based on user input
| > and then have it redirect the user to the PHP script. How is this
| > done? Well, it depends on the language you are writing the cgi code
| > in.
|
| I don't care how it's done, because that's not what I want to do. I
| want the Perl CGI program to generate output that is then parsed by
| mod_include, and then processed by PHP.
|
| > And unless you are using a precoded cgi routine or need a cgi specific
| > tool, then why not just use PHP for the whole thing?
|
| This isn't a class project, it's a production site with thousands of
| files that must remain coherent, consistent, and maintainable.
|
| I still need an answer to my question.
|
| --
| Transpose hotmail and mxsmanic in my e-mail address to reach me directly.

RTFM Dear boy RTFM

Try
http://httpd.apache.org/docs-2.0/handler.html
http://httpd.apache.org/docs-2.0/filter.html
http://httpd.apache.org/docs-2.0/howto/ssi.html

I reckon there's enough info there to get the job done

[Sean]

On Sat, 15 Jan 2005 03:13:29 +0100, Mxsmanic <mx******@hotmail.com>
reverently intoned upon the aether:

Sean writes:

Why use SSI when you can simply use include(), require(),
include_once(), and require_once() within PHP code. This will let
create a far more dynamic include structure than you will get using
SSI. Even better, an included file can call include() so you have
recursion which did not work in SSI the last time I checked.

In short, PHP has a more powerful include structure than SSI gives, so
why bother with the extra step at all.
In short, you don't have an answer for my question. Maybe someone else
will.

Actually I did. I also pointed out a simpler solution which any real
developer would use as removing an extra layer of software will make
your application simpler to code. What I did not do was hold your
hand and pat your on the head like a child.

As for your general question, run the CGI program based on user input
and then have it redirect the user to the PHP script. How is this
done? Well, it depends on the language you are writing the cgi code
in.
I don't care how it's done, because that's not what I want to do. I
want the Perl CGI program to generate output that is then parsed by
mod_include, and then processed by PHP.

You ask how it is done and then you say, " I don't care how it's done"
after being told how it can be done (redirects).

And unless you are using a precoded cgi routine or need a cgi specific
tool, then why not just use PHP for the whole thing?

This isn't a class project, it's a production site with thousands of
files that must remain coherent, consistent, and maintainable.

I still need an answer to my question.

It has already been answered. RTFM and learn how to do redirects.
Add a little GET data and you are on your way.

Beyond that, it is the design of the software that determines whether
or not thousands of files that remain coherent, consistent, and
maintainable. This takes process and good coding. It has nothing to
do with the technology you use to implement a solution, it has
everything to do with the coder.

may you reap what you sow,

Sean

"In the End, we will remember not the words of our enemies,
but the silence of our friends."

- Martin Luther King Jr. (1929-1968)

Photo Archive @ http://www.tearnet.com/Sean
Last Updated 29 Sept. 2004

[Sean]

On Fri, 14 Jan 2005 18:06:14 -0800, News Me <newsTWOme@pacifierDOTcom>
reverently intoned upon the aether:

Sean wrote:
[snip]

SSI. Even better, an included file can call include() so you have
recursion which did not work in SSI the last time I checked.

An included file being able to include another file is not an example of
recursion, it is an example of nesting. Recursion is the capability of
a function to call itself. A file including itself is recursive only in
a very general sense and it would not produce a meaningful outcome.

NM

Actually the recursion I was alluding to is the ability to include
from an included file. This is recursion of the include
functionality. It is more of a meta concept than functional
recursion, but it is still recursion.

And in truth one gets functional recursion here too, as include() will
end up including and calling include() if there is an include()
statement in the included file.

enjoy,

Sean
"In the End, we will remember not the words of our enemies,
but the silence of our friends."

- Martin Luther King Jr. (1929-1968)

Photo Archive @ http://www.tearnet.com/Sean
Last Updated 29 Sept. 2004

[Mxsmanic]

Sean writes:

Actually I did. I also pointed out a simpler solution which any real
developer would use as removing an extra layer of software will make
your application simpler to code.
I'm already aware of the "simpler" solutions, and they are not suitable
for my application (nor are they actually any simpler).
You ask how it is done and then you say, " I don't care how it's done"
after being told how it can be done (redirects).
No. I ask how one thing is done and then you tell me how something
entirely different is done. This latter thing is not the thing that I
wish to do, so I don't care how it is done.
It has already been answered.
No, it has not. I continue to hope that someone else will actually be
able to answer the question. I know from my research that this problem
arises with great frequency, but I still haven't found anyone who can
resolve it. Most "answers" are pointers to the same paragraphs on the
same Web pages, which don't explain anything, or are explanations of
completely different strategies which represent the only strategies the
poster understands. Neither of these helps me, and I'm getting tired of
seeing them over and over.
RTFM and learn how to do redirects.
There isn't any manual that explains it (as far as I've been able to
find), and redirects won't do the job.
Beyond that, it is the design of the software that determines whether
or not thousands of files that remain coherent, consistent, and
maintainable. This takes process and good coding.
No, it takes competent system administration.
It has nothing to
do with the technology you use to implement a solution, it has
everything to do with the coder.

It's only slightly related to the former, and even less related to the
latter. Ultimately it's the way you manage your systems that counts
most. I know people who see Windows crash on them every day, whereas I
never have a crash, even though I use the same version of Windows. The
difference is that I know what I'm doing, whereas they do not.

--
Transpose hotmail and mxsmanic in my e-mail address to reach me directly.

[Mxsmanic]

Chris Newey writes:

RTFM Dear boy RTFM

Try
http://httpd.apache.org/docs-2.0/handler.html
http://httpd.apache.org/docs-2.0/filter.html
http://httpd.apache.org/docs-2.0/howto/ssi.html

I reckon there's enough info there to get the job done

You reckon incorrectly. I've visited all of those pages many times, and
I've read them with great care. If you do the same, you'll see that
they don't come anywhere close to answering my question. Everyone
points to those, but apparently nobody reads them before doing so.

--
Transpose hotmail and mxsmanic in my e-mail address to reach me directly.

[Chris Newey]

"Mxsmanic" <mx******@hotmail.com> wrote in message
news:qn********************************@4ax.com...
| Sean writes:
|
| > Actually I did. I also pointed out a simpler solution which any real
| > developer would use as removing an extra layer of software will make
| > your application simpler to code.
|
| I'm already aware of the "simpler" solutions, and they are not suitable
| for my application (nor are they actually any simpler).
|
| > You ask how it is done and then you say, " I don't care how it's done"
| > after being told how it can be done (redirects).
|
| No. I ask how one thing is done and then you tell me how something
| entirely different is done. This latter thing is not the thing that I
| wish to do, so I don't care how it is done.
|
| > It has already been answered.
|
| No, it has not. I continue to hope that someone else will actually be
| able to answer the question. I know from my research that this problem
| arises with great frequency, but I still haven't found anyone who can
| resolve it. Most "answers" are pointers to the same paragraphs on the
| same Web pages, which don't explain anything, or are explanations of
| completely different strategies which represent the only strategies the
| poster understands. Neither of these helps me, and I'm getting tired of
| seeing them over and over.
|
| > RTFM and learn how to do redirects.
|
| There isn't any manual that explains it (as far as I've been able to
| find), and redirects won't do the job.
|
| > Beyond that, it is the design of the software that determines whether
| > or not thousands of files that remain coherent, consistent, and
| > maintainable. This takes process and good coding.
|
| No, it takes competent system administration.
|
| > It has nothing to
| > do with the technology you use to implement a solution, it has
| > everything to do with the coder.
|
| It's only slightly related to the former, and even less related to the
| latter. Ultimately it's the way you manage your systems that counts
| most. I know people who see Windows crash on them every day, whereas I
| never have a crash, even though I use the same version of Windows. The
| difference is that I know what I'm doing, whereas they do not.
|
| --
| Transpose hotmail and mxsmanic in my e-mail address to reach me directly.

My you do have a high a high opinion of yourself.
A period of silence would now be welcomed.

[Mxsmanic]

Chris Newey writes:

My you do have a high a high opinion of yourself.
That opinion is justified.
A period of silence would now be welcomed.

You don't have to read my posts if you don't want to.

If you are able to answer my question, I'd like to see that, however, as
I cannot find answers anywhere.

--
Transpose hotmail and mxsmanic in my e-mail address to reach me directly.

[Andy Hassall]

On Sat, 15 Jan 2005 01:37:19 +0100, Mxsmanic <mx******@hotmail.com> wrote:

How can I combine SSI, CGI, and PHP in Apache 2.x? I keep reading that
this can be done, but I haven't found any examples of the actual
configuration required to do it.

What I want to do is:

1. Either pull the page from a file or generate it with a CGI program
(depending on the individual URL, as usual).

2. Run the output from (1) above through the includes module so that SSI
calls are expanded.

3. Run the output from (2) above through PHP so that any PHP code is
expanded and executed (including any PHP code in files included by the
SSI from the previous step).

I want to do this for every page.

I'm under the impression that Apache 2.0 can do this. So how is it
done?

I could be talking out of my hat here, but wouldn't this require PHP to be
implemented as a filter, rather than a handler? Then you could specify both
INCLUDES and PHP as output filters?

http://httpd.apache.org/docs-2.0/mod...ddoutputfilter

There's http://httpd.apache.org/docs-2.0/mod...xt_filter.html which you
could use to set up the PHP commandline executable as a filter, but that
doesn't look like a good idea bearing in mind the notes on that manual page.

--
Andy Hassall / <an**@andyh.co.uk> / <http://www.andyh.co.uk>
<http://www.andyhsoftware.co.uk/space> Space: disk usage analysis tool

[HansH]

"Mxsmanic" <mx******@hotmail.com> schreef in bericht
news:3b********************************@4ax.com...

Chris Newey writes:

RTFM Dear boy RTFM
Try
http://httpd.apache.org/docs-2.0/handler.html
http://httpd.apache.org/docs-2.0/filter.html
http://httpd.apache.org/docs-2.0/howto/ssi.html
I reckon there's enough info there to get the job done

You reckon incorrectly. I've visited all of those pages many times, and
I've read them with great care. If you do the same, you'll see that
they don't come anywhere close to answering my question. Everyone
points to those, but apparently nobody reads them before doing so.

Still, these are the basic steps just waiting to be combined ... however, I
think there is trouble ahead ....

Recalling from your previous post, you want the Perl CGI program to generate
output that is then parsed by mod_include, and then processed by PHP.
But AFAIK mod_include, being an outputfilter, _must_ be the last in the
chain and that conflicts your demand.

Perhaps a master document, alike
<!--#include virtual="/cgi-bin/top.php?argument=value" -->
<!--#include virtual="/cgi-bin/example.pl?argument=value" -->
<!--#include virtual="/cgi-bin/bottom.php?argument=value" -->
might suite your needs.

HansH
--

[Mxsmanic]

HansH writes:

Still, these are the basic steps just waiting to be combined ... however, I
think there is trouble ahead ....
My impression is that it should be easy to do ... if it's possible at
all. But I've seen no examples of how to do it.
Recalling from your previous post, you want the Perl CGI program to generate
output that is then parsed by mod_include, and then processed by PHP.
But AFAIK mod_include, being an outputfilter, _must_ be the last in the
chain and that conflicts your demand.
Actually the Apache documentation gives an example for AddOutputFilter
that has DEFLATE as the last filter ("AddOutputFilter INCLUDE;DEFLATE")
so apparently mod_include doesn't have to be last. I saw another
example, somewhere, mentioning "INCLUDE;PHP" but when I try to put PHP
on the line, I get an error message in the log for each process ("an
unknown filter was not added").
Perhaps a master document, alike
<!--#include virtual="/cgi-bin/top.php?argument=value" -->
<!--#include virtual="/cgi-bin/example.pl?argument=value" -->
<!--#include virtual="/cgi-bin/bottom.php?argument=value" -->
might suite your needs.

The includes are mostly just text with one or two XSSI arguments. I
prefer not to incur the overhead of Perl or PHP just for that. I use
the includes to insert "boilerplate" text that appears on every page,
but beyond that it's fairly static content.

--
Transpose hotmail and mxsmanic in my e-mail address to reach me directly.

[Mxsmanic]

Andy Hassall writes:

I could be talking out of my hat here, but wouldn't this require PHP to be
implemented as a filter, rather than a handler? Then you could specify both
INCLUDES and PHP as output filters?
Maybe; I don't understand the difference very well.

How do I implement PHP as a filter? When I try to put it on
AddOutputFilter ("INCLUDES;PHP") Apache ignores PHP with an error
message, so it must not be configured as a filter right now.
http://httpd.apache.org/docs-2.0/mod...ddoutputfilter

There's http://httpd.apache.org/docs-2.0/mod...xt_filter.html which you
could use to set up the PHP commandline executable as a filter, but that
doesn't look like a good idea bearing in mind the notes on that manual page.

It looks terribly awkward. Is there a way to configure and install PHP
5.x as a filter?

--
Transpose hotmail and mxsmanic in my e-mail address to reach me directly.

[Sean]

Please troll elsewhere. Otherwise, pony up the cash to get the answer
the way you want.

sincerely,

Sean
"In the End, we will remember not the words of our enemies,
but the silence of our friends."

- Martin Luther King Jr. (1929-1968)

Photo Archive @ http://www.tearnet.com/Sean
Last Updated 29 Sept. 2004

[Mxsmanic]

Sean writes:

Please troll elsewhere. Otherwise, pony up the cash to get the answer
the way you want.

I'm getting a few answers already--but not from you.

--
Transpose hotmail and mxsmanic in my e-mail address to reach me directly.

[HansH]

"Mxsmanic" <mx******@hotmail.com> schreef in bericht
news:b1********************************@4ax.com...

Still, these are the basic steps just waiting to be combined ... however, I think there is trouble ahead .... My impression is that it should be easy to do ... if it's possible at
all. But I've seen no examples of how to do it.

Recalling from your previous post, you want the Perl CGI program to generate output that is then parsed by mod_include, and then processed by PHP.
But AFAIK mod_include, being an outputfilter, _must_ be the last in the
chain and that conflicts your demand.

Actually the Apache documentation gives an example for AddOutputFilter
that has DEFLATE as the last filter ("AddOutputFilter INCLUDE;DEFLATE")
so apparently mod_include doesn't have to be last.

There is a litle misunderstanding here ....
You are -correctly- referencing a chain of outputfilters .... however I ment
the chain of things Apache does while processing a request. I my chain yours
comes last ;-)
I saw another example, somewhere, mentioning "INCLUDE;PHP"
but when I try to put PHP on the line, I get an error message in the log for each process ("an unknown filter was not added"). Well AFAIK mod_php is indeed a handler, not a (output)filter.

Perhaps a master document, alike
<!--#include virtual="/cgi-bin/top.php?argument=value" -->
<!--#include virtual="/cgi-bin/example.pl?argument=value" -->
<!--#include virtual="/cgi-bin/bottom.php?argument=value" -->
might suite your needs.

The includes are mostly just text with one or two XSSI arguments.

Your previous post gave a different impression:
"including any PHP code in files included by the SSI from the previous step"
I prefer not to incur the overhead of Perl or PHP just for that.

If p.e. top goes without PHP, just change the first line to
<!--#include file="includes/top.php?argument=value" -->

Changing to file= even removes virtual='s burden of subrequests, however the
files to be included has to be at or below the folder of the current file.
HansH

[Mxsmanic]

HansH writes:

You are -correctly- referencing a chain of outputfilters .... however I ment
the chain of things Apache does while processing a request. I my chain yours
comes last ;-)
I haven't been able to find any clear documentation of how Apache chains
these operations together, or how to change or configure that order.
Well AFAIK mod_php is indeed a handler, not a (output)filter.
There's no way to compile and install it otherwise?

If it's only a handler, why is PHP mentioned in examples? There must be
some way to configure it as a filter.
Your previous post gave a different impression:
"including any PHP code in files included by the SSI from the previous step"

Yes, but the code still looks like straight HTML to SSI, since it
doesn't care about any embedded PHP code.

--
Transpose hotmail and mxsmanic in my e-mail address to reach me directly.

[Chung Leong]

"Mxsmanic" <mx******@hotmail.com> wrote in message
news:ia********************************@4ax.com...

How can I combine SSI, CGI, and PHP in Apache 2.x? I keep reading that
this can be done, but I haven't found any examples of the actual
configuration required to do it.

What I want to do is:

1. Either pull the page from a file or generate it with a CGI program
(depending on the individual URL, as usual).

2. Run the output from (1) above through the includes module so that SSI
calls are expanded.

3. Run the output from (2) above through PHP so that any PHP code is
expanded and executed (including any PHP code in files included by the
SSI from the previous step).

I want to do this for every page.

I'm under the impression that Apache 2.0 can do this. So how is it
done?

Nope, it does not work with PHP. The PHP Apache 2 filter doesn't parse code
coming through the pipeline. Still a mystery to me why they made it a
separate SAPI module.

[Mxsmanic]

Chung Leong writes:

Nope, it does not work with PHP. The PHP Apache 2 filter doesn't parse code
coming through the pipeline. Still a mystery to me why they made it a
separate SAPI module.

What about the examples I've seen that show things like:

AddOutputFilter INCLUDES;PHP .shtml .html

This seems to imply that there's a way to make PHP a filter.

But actually my experiments have resolved a portion of the problem:
right now, output from .php pages is being scanned for SSI after PHP
finishes, which is a huge step ahead. So my remaining issues are: how
can I get output from Perl scripts to be parsed by SSI, and how could I
get SSI to parse a page _after_ PHP is parsed, instead of before (which
would allow PHP code embedded in SSI-included files to be parsed, in
addition to the PHP code in the base page)?

--
Transpose hotmail and mxsmanic in my e-mail address to reach me directly.

[Andy Hassall]

On Sat, 15 Jan 2005 20:50:50 +0100, Mxsmanic <mx******@hotmail.com> wrote:

Andy Hassall writes:

I could be talking out of my hat here, but wouldn't this require PHP to be
implemented as a filter, rather than a handler? Then you could specify both
INCLUDES and PHP as output filters?

Maybe; I don't understand the difference very well.

How do I implement PHP as a filter? When I try to put it on
AddOutputFilter ("INCLUDES;PHP") Apache ignores PHP with an error
message, so it must not be configured as a filter right now.

http://httpd.apache.org/docs-2.0/mod...ddoutputfilter

There's http://httpd.apache.org/docs-2.0/mod...xt_filter.html which you
could use to set up the PHP commandline executable as a filter, but that
doesn't look like a good idea bearing in mind the notes on that manual page.

It looks terribly awkward. Is there a way to configure and install PHP
5.x as a filter?

I had a quick look on Google for examples of using PHP as a filter, and mostly
they were hits for people saying it didn't work.

This came up with a bit more background:
http://bugs.php.net/bug.php?id=17868&edit=1

Looks to me like the initial PHP Apache2 support was implemented as a filter,
this didn't work, and it was then changed to a handler. I don't know whether
the filter option is still available. PHP's configure script does still have a
"--with-apxs2filter" option though.

--
Andy Hassall / <an**@andyh.co.uk> / <http://www.andyh.co.uk>
<http://www.andyhsoftware.co.uk/space> Space: disk usage analysis tool

[HansH]

"Mxsmanic" <mx******@hotmail.com> schreef in bericht
news:1l********************************@4ax.com...

HansH writes:

You are -correctly- referencing a chain of outputfilters .... however I ment the chain of things Apache does while processing a request. I my chain yours comes last ;-) I haven't been able to find any clear documentation of how Apache chains
these operations together, or how to change or configure that order.

Collected most of it 'in between the lines' myself too ...

Well AFAIK mod_php is indeed a handler, not a (output)filter.

Today the spars informatition on how to configure php on Apache2 is limited
to handlers, a deeper look reveils more ...
There's no way to compile and install it otherwise? .... so be patient ...
If it's only a handler, why is PHP mentioned in examples?

Best I had found, was an almost three years old message referencing a
_patched_ 4.1.2 at http://slashdot.org/article.pl?sid=02/04/06/0216250 -the
download is no longer available- However, saw some references to more recent
RH's ditributions too.

Started browsing the source files (4.3.10 and 5.0.3) and found the sapi-tree
splitting into apache_hooks, apache2handler and apache2filter.
There's a note in the changelog dated 29 May 2003 and referencing Version
4.3.2 seeing "Added a new Apache 2.0 SAPI module (sapi/apache2handler) based
on the old version (sapi/apache2filter)".

That looks like the filter 'thingy' has been kicked out of default
installation ...
.... try replacing --with-apxs2 with --with-apxs2filter during installation.
as per _user_comment_ at http://www.php.net/manual/en/install.unix.php.
HansH
--
Unfortunately PHP5 comes without a Rich Text Formatted Manual.

[Mxsmanic]

Andy Hassall writes:

I had a quick look on Google for examples of using PHP as a filter, and mostly
they were hits for people saying it didn't work.

This came up with a bit more background:
http://bugs.php.net/bug.php?id=17868&edit=1
Kind of confusing.
Looks to me like the initial PHP Apache2 support was implemented as a filter,
this didn't work, and it was then changed to a handler. I don't know whether
the filter option is still available. PHP's configure script does still have a
"--with-apxs2filter" option though.

I tried --with-apex2filter, and the resulting module wouldn't work.

All of this filter stuff seems to represent problems that a great many
people are having, and yet it doesn't seem to be resolved. I'm only one
of quite a large group who would like to combine filters in the way I've
described. It's a logical way to use filters.

--
Transpose hotmail and mxsmanic in my e-mail address to reach me directly.

[Chung Leong]

"Mxsmanic" <mx******@hotmail.com> wrote in message
news:5o********************************@4ax.com...

Chung Leong writes:

Nope, it does not work with PHP. The PHP Apache 2 filter doesn't parse code coming through the pipeline. Still a mystery to me why they made it a
separate SAPI module.
What about the examples I've seen that show things like:

AddOutputFilter INCLUDES;PHP .shtml .html

This seems to imply that there's a way to make PHP a filter.

An Apache filter is something that operates on a request as a whole. The
granuity of the operation can vary greatly. Some filters filter the output
byte stream and some do not. The internal HTTP headers filter, for example,
builds the HTTP response headers and add them to the output stream. It
doen't filter the contents in the body.

I looked at the PHP Apache2 filter source code a little more closely. Here's
some qualification to what I said: PHP will parse a piece of data in the
output bucket brigade if comes in a file bucket. The core output filter
sends a requested file down the pipeline as a file bucket, so that gets
parsed. If you write an Apache2 filter that attaches a header file and a
footer file to the output, those too would get parsed. If the data is stored
in a memory bucket, it won't get parsed by PHP.
But actually my experiments have resolved a portion of the problem:
right now, output from .php pages is being scanned for SSI after PHP
finishes, which is a huge step ahead. So my remaining issues are: how
can I get output from Perl scripts to be parsed by SSI, and how could I
get SSI to parse a page _after_ PHP is parsed, instead of before (which
would allow PHP code embedded in SSI-included files to be parsed, in
addition to the PHP code in the base page)?

I'm not too sure what you're trying to achieve here, but I think <#include
virtual="/something.php"> is what you need.

[Mxsmanic]

Chung Leong writes:

I looked at the PHP Apache2 filter source code a little more closely. Here's
some qualification to what I said: PHP will parse a piece of data in the
output bucket brigade if comes in a file bucket. The core output filter
sends a requested file down the pipeline as a file bucket, so that gets
parsed. If you write an Apache2 filter that attaches a header file and a
footer file to the output, those too would get parsed. If the data is stored
in a memory bucket, it won't get parsed by PHP.
I don't understand what that tells me.
I'm not too sure what you're trying to achieve here, but I think <#include
virtual="/something.php"> is what you need.

If I change the #include virtual="/something.html" to #include
virtual="/something.php", I get

[an error occurred while processing this directive]

instead of the included file.

I tried adding .html and .htm to .php in the list of extensions on

AddType application/x-httpd-php .php

I get segmentation faults in the httpd processes each time they try to
process anything with an #include directive in it.

--
Transpose hotmail and mxsmanic in my e-mail address to reach me directly.

[Chung Leong]

"Mxsmanic" <mx******@hotmail.com> wrote in message
news:dr********************************@4ax.com...

Chung Leong writes:

I looked at the PHP Apache2 filter source code a little more closely. Here's some qualification to what I said: PHP will parse a piece of data in the
output bucket brigade if comes in a file bucket. The core output filter
sends a requested file down the pipeline as a file bucket, so that gets
parsed. If you write an Apache2 filter that attaches a header file and a
footer file to the output, those too would get parsed. If the data is stored in a memory bucket, it won't get parsed by PHP.

I don't understand what that tells me.

That's telling you the PHP Apache 2 filter is very funky. It will only parse
static files. If a filter ahead of it gives it some dynamically generated
code, it won't get processed.

I'm not too sure what you're trying to achieve here, but I think <#include virtual="/something.php"> is what you need.

If I change the #include virtual="/something.html" to #include
virtual="/something.php", I get

[an error occurred while processing this directive]

instead of the included file.

I tried adding .html and .htm to .php in the list of extensions on

AddType application/x-httpd-php .php

I get segmentation faults in the httpd processes each time they try to
process anything with an #include directive in it.

Did you turn off SSI filtering for .php first?

[Mxsmanic]

Chung Leong writes:

Did you turn off SSI filtering for .php first?

No, in theory everything should be going through SSI. Wouldn't that
defeat the purpose to turn it off?

--
Transpose hotmail and mxsmanic in my e-mail address to reach me directly.