Re: FCGI and FilterData

Mark Brown (mbrown@OpenMarket.com)
Fri, 17 May 1996 09:39:31 -0400

Message-Id: <199605171339.JAA03834@breckenridge.openmarket.com>
To: rasmus@madhaus.utcs.utoronto.ca
Subject: Re: FCGI and FilterData 
In-Reply-To: Your message of "Thu, 16 May 1996 19:46:40 EDT."
             <ML-2.0.832290400.1942.rasmus@krone.house.mil> 
Date: Fri, 17 May 1996 09:39:31 -0400
From: Mark Brown <mbrown@OpenMarket.com>


    I have read over the documentation on the StartFilterData() call in the
    fcgi library.  I don't quite see the benefit in my case.  The way PHP/FI
    works is that it gets the filename of the html file to parse from Apache,
    or in the case of the CGI version, right from $PATH_INFO.  Then it
    mmap's this file directly and goes through and parses any PHP/FI script
    tags that it finds and producing HTML on stdout.  It of course also reads
    any POST data from stdin and parses any GET data from the rq->args,
    or the $QUERY_STRING in CGI mode.

    The StartFilterData() seems to expect the HTML file to have already been
    read and the way I understand it, it simply allows me to read the file
    from stdin (once I have read other stdin POST data).  What do I gain by
    this?

What Filter allows you to do is to write URLs that refer directly to
the script in question, not indirectly by naming the PHP/FI interpreter
and then naming the script in the "virtual path".  The most significant
benefit of this arrangement is that the Web server becomes responsible for
performing access control to the script, rather than placing
the PHP/FI interpreter in the role of performing access control.
A secondary benefit is that users just need to put the correct extension
on the script name, rather than having to insert the path to the
interpreter.

    --mark