Web-Skripte zum Laufen bringen Inhalt

Das Problem

Wenn ein CGI-Skript nicht laufen will, erhält man oft nur den allgemeinen Fehler:

Premature end of script headers

oder auch nur

Internal Server Error

Dies kann leider mehrere Ursachen haben. Schau dir die Liste der möglichen Ursachen unter den Skripten genau an und gehe einen nach dem anderen durch!

Wenn du die Möglichkeit hast, in die Apache-Error-Logs reinzuschauen, dann schau dir die letzten Einträge an. Meist enthalten diese etwas mehr Infos. Wenn du einen SSH-Zugang hast, dann probiere als erstes aus, das Skript in der Shell zu starten.

Test-CGI-Skript

Am besten erstellt man sich erstmal ein kleines Testskript:

   1 #!/usr/bin/env python
   2 # -*- coding: utf-8 -*-
   3 
   4 # Debugging für CGI-Skripte 'einschalten'
   5 import cgitb; cgitb.enable()
   6 
   7 print "Content-Type: text/html;charset=utf-8\n"
   8 print "Hello World!"

Wenn du ein wenig mehr Informationen erhalten willst, benutze das CGI-Skript von der Seite Server-Informationen.

Liste der möglichen Ursachen

Wenn das obige Testskript nicht läuft, gilt es, mehrere Punkte auszuschließen:

Wenn du wirklich alle hier aufgeführten Punkte berücksichtigt hast und deine Webapp immer noch nicht laufen sollte, dann schildere dein Problem doch im Python-Forum.

Die Probleme und Lösungen im Einzelnen

Pfad zum Interpreter

Die erste Zeile eines CGI-Skriptes zeigt dem Betriebssystem, mit welchem Programm es dieses Skript ausführen soll.

Unter Linux sieht diese Zeile i.d.R. so aus: #!/usr/bin/env python oder auch #!/usr/bin/python

Unter Windows muss der vollständige Pfad zur python.exe angegeben werden, z.B.: #!C:\python\python.exe

Datei-User/-Gruppe

Es kann vorkommen, dass Apache nur dann das Python-Skript ausführen kann, wenn der Dateieigentümer und die Gruppenzugehörigkeit (ändern mit chown) die richtigen sind. Stichwort suEXEC (en)

Je nach Konfiguration und Zugang (FTP/SSH) loggt man sich evtl. mit einem anderen User ein, als die Dateien als Eigentümer/Gruppe haben sollten.

Das dumme dabei ist, das man auch hierbei nur wieder ein Premature end of script headers zu sehen bekommt und keinerlei Hinweise dazu.

mod_python

Manchmal kommt es zu "merkwürdigen" Fehlern, wenn man versucht CGI-Skripte zum Laufen zu bekommen, bei denen mod_python im Spiel ist. Denn CGI-Skripte sind eigentlich für das CGI-Gateway gedacht und nicht für mod_python :)

Wenn dein Server mod_python hat, dann ist es oft so eingestellt, dass .py-Dateien per mod_python ausgeführt werden, wohingegen nur .cgi-Dateien als normales CGI starten.

Ob das so ist, kannst du mit dem folgenden Skript testen. Versuche es einmal als test.py und einmal als test.cgi:

   1 #!/usr/bin/env python
   2 # -*- coding: UTF-8 -*-
   3 
   4 print "Content-Type: text/html;charset=utf-8\n"
   5 
   6 import cgitb; cgitb.enable() # Debugging für CGI-Skripte 'einschalten'
   7 import os
   8 
   9 print "einfacher mod_python Test"
  10 
  11 if __name__ != "__main__":
  12     # Kann passieren, wenn das Skript nicht als CGI läuft, sondern
  13     # evtl. über mod_python
  14     print "<h1>Fehler:</h1>"
  15     print "<p>__name__ == %s (sollte aber == '__main__' sein!)</p>" % __name__
  16     print "<hr />"
  17 
  18 try:
  19     gateway = os.environ["GATEWAY_INTERFACE"]
  20 except KeyError:
  21     print "Fehler: GATEWAY_INTERFACE ist nicht in os.environ!"
  22     print "Wahrscheinlich ist der Server nicht richtig konfiguriert."
  23 else:
  24     print "<p>GATEWAY_INTERFACE: <strong>%s</strong></p>" % gateway
  25 
  26     if gateway=="CGI/1.1":
  27         print "<p>OK, running as CGI.</p>"
  28     else:
  29         print "<h3>Not running as CGI!</h3>"
  30 
  31 # Mal sehen ob das mod_python Modul verfügbar ist. Wenn ja, ist mod_python
  32 # generell installiert, aber evtl. nicht aktiv.
  33 try:
  34     import mod_python
  35 except ImportError, e:
  36     print "<p>Note: Can't import mod_python module: %s</p>" % e

Schau auch mal auf die offizielle Seite zum Testen der mod_python Installation(en); dort findest du auch ein mod_python-Hello-World.

Ausführungsrechte

In einer .htaccess-Datei kann man folgendes definieren, damit Skripte auch außerhalb vom Verzeichnis cgi-bin laufen und die Endung .py statt .cgi haben dürfen:

# Damit allgemein CGIs ausgeführt werden
Options +ExecCGI

# Dateien mit der Endung ".py" sind CGI-Skripte
AddHandler cgi-script .py

Link zu der Apache-Dokumentation: ExecCGI, AddHandler

Die .htaccess-Datei muss man i.d.R. selber anlegen. Die Datei sollte in das Verzeichnis, in dem deine Webapp-Skripte liegen, erstellt werden.

Wenn man jetzt keinen Zugriff mehr auf das Skript hat, kann es evtl. daran liegen, dass man Options und AddHandler nicht per .htaccess ändern darf. Das wird per AllowOverride-Direktive festgelegt.

Dennoch kann es vorkommen, dass die Python-Skripte nur teilweise außerhalb von cgi-bin laufen! Siehe den Thread cgitb funktioniert nicht außerhalb von ./cgi-bin im Python-Forum.

Zeilenende

SciTE

In SciTE geht das ganz einfach!

Anzeigen kannst du dir die Endungszeichen mit View / End Of Line

Ändern kannst du es so:

Vim

Mit Vim ist das sogar noch einfacher.

Man stellt die Zeilenenden auf Unix-Stil: :set ff=unix (ff steht für fileformat, man darf beide Formen synonym verwenden). Damit wird die Datei auf LF-Zeilenenden konvertiert. Nun reicht es, die Datei mit :w abzuspeichern.

Ein kleiner fastCGI-Test

Für einen kleinen fastCGI-Test erstellen wir zwei Dateien:

dispatcher.fcgi

   1 #!/usr/bin/env python
   2 # -*- coding: UTF-8 -*-
   3 
   4 from flup.server.fcgi import WSGIServer
   5 from fastCGI_test_app import app
   6 
   7 WSGIServer(app).run()

test_app.py

   1 #!/usr/bin/env python
   2 # -*- coding: UTF-8 -*-
   3 
   4 from cgi import escape
   5 import sys, os
   6 
   7 def app(environ, start_response):
   8     start_response('200 OK', [('Content-Type', 'text/html')])
   9 
  10     yield '<h1>FastCGI Environment</h1>'
  11     yield '<table>'
  12     for k, v in sorted(environ.items()):
  13         yield '<tr><th>%s</th><td>%s</td></tr>' % (escape(k), escape(v))
  14     yield '</table>'

Die dispatcher.fcgi benötigt Ausführungsrechte und wird vom Browser aufgerufen. Wenn alles klappt, erhält man eine Liste der Umgebungsvariablen. Wenn nicht, erhält man meist nur einen Internal Server Error :(

Einige Fehlerquellen sind die selben, wie bei einem CGI-Skript. siehe oben.

Python mit XAMPP unter Windows

Im Forum tauchen öfter Beiträge auf, dass Python-CGI-Skripte nicht unter XAMPP ausgeführt werden. Deshalb hier nochmal einen kleinen Hinweis dazu.

Ein extra mod_Python-Paket für XAMPP ist nicht erforderlich! Es sei denn, man möchte explizit mod_python mit seinem Skript verwenden, siehe dazu: Ich habe Probleme mit mod_python in unserer FAQ.

Eigentlich reichen folgende Dinge:

Am besten nimmt man auch hier wieder das kleine Test-CGI-Skript und geht die Liste der möglichen Ursachen durch, wenn es spontan nicht klappen will. Anonsten kann man im Python-Forum nachfragen.

Weiterführender Link: XAMPP mit Python CGI

Python-Forum

Passende Threads im Forum:

Tags: Codesnippets | Web | Wsgi

Web-Skripte zum Laufen bringen (zuletzt geändert am 2009-06-17 16:14:15 durch anonym)