> My point is: The bad example does something, which is extremely
> inefficient but it just works. It has no side effects concerning
> security. All files are parsed by PHP, so no unparsed configuration
> files can leek.
> The "good example" only handles requests to the FastCGI instance if the
> file or directory can not be found by nginx. This is clearly not the
> same although the whole intention of the pitfall site is, in my eyes, to
> offer exactly that: A naive, inefficient way to achieve things and a
> professional, tested, reliable and secure way. It's the first URL given
> in Debian's default config and possibly the first place a user will look
> like searching for help.
> Proxying everything is certainly a bad idea; proxying too less is
> disastrous in terms of security. This should be pointed out in the wiki
> in big fat letters. Or better, let's come up with a better example of
> how to proxy a bare minimum.
I agree, it's not good to replace one bad example with another. OTOH,
cluttering up the "good" example might dilute the point (the particular
pitfall being discussed) with details.
Maybe continue that with a third example that introduces the pitfall of
accidentally serving up source code and provides the complete, correct
solution, or at the very least, put a big, fat warning next to the