On Jan 7, 2019, at 3:30 PM, Paul Heinlein <heinl...@madboa.com> wrote: > > 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. > Don't forget the script extension for CGI, and also file permissions of the script itself.
-- Louis Kowolowski lou...@cryptomonkeys.org <mailto:lou...@cryptomonkeys.org> Cryptomonkeys: http://www.cryptomonkeys.com/ <http://www.cryptomonkeys.com/> Making life more interesting for people since 1977 _______________________________________________ PLUG mailing list PLUG@pdxlinux.org http://lists.pdxlinux.org/mailman/listinfo/plug
