On Mon, 7 Jan 2019, Tomas Kuchta wrote:
Yes, the file serving part works, and is observable in the logs. There is
good visibility on client side with curl or browsers. When Apache executes
it, I get the output html/json/.... When it doesn't work, I get to download
the code.
I usually build couple of identical machines and synchronize their
config/content. Still, when one machine in the pair is stubbornly refusing
to run some stuff, it takes a lot of diffing, renaming, rebuilding, ...
What makes Apache to choose to execute some files and not the others, is
the $M question.
There are a few possible answers.
First, the non-executing scripts may live in a directory not
identified by a ScriptAlias directive or in a directory that doesn't
have "SetHandler cgi-script" and "Options +ExecCGI" configured.
Second, if the CGI script is handled by an interpreter (/usr/bin/perl,
for example, or /usr/bin/python) the #! line may be incorrect or the
file may not be marked as executable in the filesystem.
Third, the CGI script fails to set the Content-Type header of the
return text correctly. Use "curl -I <<your failing url>>" to see. In
cases where it's failing, you're probably getting "text/plain"; but
where it's successful you're seeing "application/json".
Those are the most likely cases I can imagine.
--
Paul Heinlein
[email protected]
45°38' N, 122°6' W
_______________________________________________
PLUG mailing list
[email protected]
http://lists.pdxlinux.org/mailman/listinfo/plug
