Frage zu cgi.FieldStorage

fantomas · Freitag 6. Februar 2009, 14:24

Hallo zusammen,

mein erstes Posting hier. Bin Newbie, daher ist meine Frage vielleicht trivial, sorry..

Ich möchte ein CGI Skript mit Python schreiben. Einem CGI Skript übergibt man Informationen, meines Wissens nach, wie folgt:

http://domain/path/cgi-skript/path-info?query-string

In Python soll man diese Informationen dann mit einer Instanz der Klasse cgi.FieldStorage abfangen können.

Mein Problem: Ich bekomme Informationen aus dem query-string (z.B.: cgi.FieldStorage.getvalue()). Aber path-info geht irgendwie verloren. In der Dokumentation auf python.org habe ich leider keine Antwort auf meine Frage gefunden.

Kann mir jemand einen Tipp geben, was ich falsch mache bzw. wo ich nachschlagen kann? Vielen Dank!

Leonidas · Freitag 6. Februar 2009, 18:23

Hallo fantomas, willkommen im Forum,

muss es denn CGI sein? Eigentlich ist CGI unter Python schon längst tot, man nutzt WSGI-Frameworks und Libs, die einem viel Arbeit abnehmen und dann unter CGI/FastCGI/SCGI/mod_wsgi/HTTP-Proxying etc. laufen.

hendrikS · Freitag 6. Februar 2009, 19:46

Warum soll CGI unter Python tot sein?

Ich habe jetzt mein erstes CGI script fertiggestellt, das ich online stelle sobald ich mich fuer einen Hoster entschieden habe. Es funktioniert tadellos. Die Parameter fuer das Skript kommen dabei aus einer HTML form (text feld und options liste).

Ich benutze cgi.FieldStorage und form.getfirst. Eigentlich easy.

numerix · Freitag 6. Februar 2009, 19:57

hendrikS hat geschrieben:Warum soll CGI unter Python tot sein?

Ich habe jetzt mein erstes CGI script fertiggestellt, das ich online stelle sobald ich mich fuer einen Hoster entschieden habe. Es funktioniert tadellos. Die Parameter fuer das Skript kommen dabei aus einer HTML form (text feld und options liste).

Ich benutze cgi.FieldStorage und form.getfirst. Eigentlich easy.

Es geht ja nicht darum, dass es kompliziert wäre. Die Gründe sind andere. Kannst du z.B. via Forensuche oder auch im Wiki nachlesen.

@Leonidas: Gelegentlich ist man drauf angewiesen, weil der Webhoster, dem man sich anvertraut hat, nicht mehr zu bieten hat. Für Einstiegsexperimente reicht es ja auch aus.

gerold · Freitag 6. Februar 2009, 20:02

Hallo fantomas!

Das Skript (ganz unten) auf dieser Seite [wiki]CGI[/wiki] zeigt dir an, welche Informationen du vom Webserver übergeben bekommst.

mfg
Gerold

Leonidas · Freitag 6. Februar 2009, 20:06

numerix hat geschrieben:@Leonidas: Gelegentlich ist man drauf angewiesen, weil der Webhoster, dem man sich anvertraut hat, nicht mehr zu bieten hat. Für Einstiegsexperimente reicht es ja auch aus.

Man kann WSGI auch auf CGI laufen lassen. Deswegen ist direkte CGI-Programmierung tot.

Zusätzlich zu CGI bietet es aber die Vorteile, dass es nicht auf CGI beschränkt ist und dass man alle WSGI-Apps/Libs verwenden kann. Also warum sich selbst mit CGI einschränken?

hendrikS · Freitag 6. Februar 2009, 20:42

Leonidas hat geschrieben: Man kann WSGI auch auf CGI laufen lassen.

Kannst mal kurz erläutern was das praktisch bedeutet?

Ich verstehe es so: Eine WSGI Webapplikation wuerde auch funktionieren, wenn kein WSGI server vorhanden ist. Richtig?
Es gibt offenbar rund keinen Hoster, der so was anbietet. Wenn man sich so die Angebote durchliest, ist von WSGI nie die Rede.

Oder ich stelle die Frage mal so:
Welche Voraussetzungen muss ein Webhoster bieten, um eine WSGI basierende Applikation laufen zu lassen?

Leonidas · Freitag 6. Februar 2009, 22:40

hendrikS hat geschrieben:Ich verstehe es so: Eine WSGI Webapplikation wuerde auch funktionieren, wenn kein WSGI server vorhanden ist. Richtig?

So etwas wie WSGI-Server gibt es gar nicht. Das sind eigentlich zwei orthogonale Konzepte.

hendrikS hat geschrieben:Es gibt offenbar rund keinen Hoster, der so was anbietet. Wenn man sich so die Angebote durchliest, ist von WSGI nie die Reede.

Naja, weil nur ``mod_wsgi`` WSGI auch im Namen trägt. Aber man kann WSGI-Konforme Programme ja auch auf FastCGI laufen lassen. Oder wenn es sein muss ``mod_python``. Und diese Deployment-Möglichkeiten bieten einige Hoster durchaus. Der Geschwindigkeitsvorteil wenn das Skript nicht wie bei CGI jedes mal neu gestartet werden muss ist beträchtlich - WSGI bietet einem die Möglichkeit das auszunutzen, CGI nicht.

hendrikS hat geschrieben:Oder ich stelle die Frage mal so:
Welche Voraussetzungen muss ein Webhoster bieten, um eine WSGI basierende Applikation laufen zu lassen?

Einen Python-Interpreter und CGI oder besser.

Schau dir doch mal HOWTO Use Python in the web an.

numerix · Samstag 7. Februar 2009, 09:02

Leonidas hat geschrieben:Man kann WSGI auch auf CGI laufen lassen.

Das war mir nicht bewusst - hatte ich bisher anders verstanden.

gerold · Samstag 7. Februar 2009, 17:21

numerix hat geschrieben:
Leonidas hat geschrieben:Man kann WSGI auch auf CGI laufen lassen.
Das war mir nicht bewusst - hatte ich bisher anders verstanden

Hallo!

WSGI hinter CGI ist noch langsamer als reines CGI -- weil dann auch noch die WSGI-Bibliothek(en) bei jeder Anfrage neu geladen werden müssen.

Um sich an die Internetprogrammierung heranzutasten, halte ich CGI für eine gute Sache. Daten von einem HTML-Formular empfangen und vielleicht mal ein Email verschicken -- ja, dafür ist CGI gar nicht mal so schlecht geeignet. Aber, mehr sollte man nicht von CGI erwarten. Meine Meinung: Sobald die Frage nach Session-Variablen, Benutzerverwaltung oder gar Datenbankanbindung auftaucht, sollte man die Finger von CGI lassen.

Für weniger als 10 Euro im Monat, bekommt man schon einen V-Server, auf dem man alles tun kann was man möchte. Dort kann man **mod_wsgi** installieren und damit die Webanwendung so performant wie möglich ausführen lassen. Und ab diesem Moment sind auch WSGI und die darauf basierenden Tools und Frameworks interessant.

CGI -- kurz mal reinschnuppern und ein paar Kleinigkeiten damit machen. Und als nächste Entwicklungsstufe -- Tools und Frameworks für die Internetentwicklung nutzen.

mfg
Gerold

numerix · Samstag 7. Februar 2009, 17:41

gerold hat geschrieben:CGI -- kurz mal reinschnuppern und ein paar Kleinigkeiten damit machen. Und als nächste Entwicklungsstufe -- Tools und Frameworks für die Internetentwicklung nutzen.

Dann hatte ich das doch richtig verstanden.

Leonidas · Samstag 7. Februar 2009, 20:04

gerold hat geschrieben:WSGI hinter CGI ist noch langsamer als reines CGI -- weil dann auch noch die WSGI-Bibliothek(en) bei jeder Anfrage neu geladen werden müssen.

Wieviel langsamer? Sprechen wir von tatsächlichen Zahlen oder "es muss langsamer sein, weil es mehr lädt"?

Django über CGI ist in der Tat zu langsam, aber das liegt daran, dass Django ziemlich groß und nicht auf Startgeschwindigkeit optimiert ist, da dauert das kompilieren der URL-Regex schonmal etwas etc. Dabei gibt es durchaus auch schneller startende Libs.

gerold hat geschrieben:CGI -- kurz mal reinschnuppern und ein paar Kleinigkeiten damit machen. Und als nächste Entwicklungsstufe -- Tools und Frameworks für die Internetentwicklung nutzen.

Sehe ich anders.

hendrikS · Samstag 7. Februar 2009, 21:11

Also ich habe es immer noch nicht so richtig kapiert.
Es ist in allen Dokus von WSGI Servern die Rede. Leonidas sagt, die gäbe es eigentlich nicht.

Die vorhandenen Demo Applikationen habe ich so ans Laufen gebracht.

1.) Ich starte die Applikation (den Server) in einer DOS Box
2.) Ich führe die selbe Applikation wie gehabt über den Webserver/Interpreter aus

Irgendwie komisch. Mir fehlt hier noch das große Bild. Wobei ich ein solches tatsächlich in den ganzen Dokumentationen vermisse. Wäre hier wirklich hilfreich.

Hyperion · Samstag 7. Februar 2009, 21:17

hendrikS hat geschrieben: Irgendwie komisch. Mir fehlt hier noch das große Bild. Wobei ich ein solches tatsächlich in den ganzen Dokumentationen vermisse. Wäre hier wirklich hilfreich.

WSGI ist einfach nur eine genormte Schnittstelle für die Kommunikation zwischen einem Python-Script und einem Webserver. Was fehlt Dir an diesem "Bild"?

Es gibt für die schnelle und einfache Entwicklung eben einen einfachen WSGI-kompatiblen Server, der von Python mitgeliefert wird. Man kann also Webanwednungen entwicklen, ohne eine persistente Webserverumgebung nutzen zu müssen (wie eben Apache und Konsorten!).

Diesen simplen Server hast Du vermutlich genutzt.

Man kann aber eben WSGI-Programme mit so ziemlich jedem Webserver verwenden. Das kann eben auch u.a. über die traditionelle CGI-Schnittstelle geschehen oder über spezielle Lösungen wie etwa mod_wsgi für den Apachen.

hendrikS · Samstag 7. Februar 2009, 21:50

Hyperion hat geschrieben: WSGI ist einfach nur eine genormte Schnittstelle für die Kommunikation zwischen einem Python-Script und einem Webserver. Was fehlt Dir an diesem "Bild"?

Was muss wer, wo, wann ausführen damit es geht.

Bei einem normalen CGI Skript funktionert es doch so: Der Webserver erkennt ein py script und startet den Python Interpreter um dieses auszuführen. Eigentlich ein einfaches Konzept.

Bei WSGI sind hier irgendwie mehr Schritte notwendig.

Hyperion · Samstag 7. Februar 2009, 22:01

Jein, es wird halt ggf. ein Wrapper aufgerufen, der das WSGI-Script an die Webserverschnittstelle bindet. Mit mod_wsgi braucht man so einen Wrapper nicht mehr.

Kommt jetzt drauf an, wie Du "Schritt" definierst. Man könnte es glaub ich so sagen: Es kommt ein Schritt hinzu, von dem Du nichts merkst.

hendrikS · Samstag 7. Februar 2009, 22:14

Hmm: "Jein" und "ggf." hilft mir natürlich wenig.

Also um die Hello World Applikation zum Laufen zu bringen, muß ich ein und dieselbe Applikation zweimal starten. Einmal in der Konsole und einmal wie gehabt. Ist erstmal mindestens ein Schritt mehr. Ist das der Normalfall?

Hyperion · Samstag 7. Februar 2009, 22:21

hendrikS hat geschrieben:Hmm: "Jein" und "ggf." hilft mir natürlich wenig.

Dann lies eben im Web alles nach und filtere die Infos selber

Also um die Hello World Applikation zum Laufen zu bringen, muß ich ein und dieselbe Applikation zweimal starten. Einmal in der Konsole und einmal wie gehabt. Ist erstmal mindestens ein Schritt mehr. Ist das der Normalfall?

Nein! Der Webserver ruft ein Script auf und fertig. Entweder ist es die Hello World Applikation direkt oder ein Wrapper-Script, welches intern dann auf eine gewisse Art und Weise Deine Applikation aufruft.

Wie ich schon sagte: Vom Automatismus her ändert sich quasi nichts!

Und noch einmal zu dieser "Konsolen"-Sache: Du startest da einfach den mitgelieferten minimalen Server vom Python WSGI Modul. Das ist eben ein einfacher, sehr simpler Webserver. Dieser ist eben vor allem für die Entwcklung gedacht und nicht für den produktiven Betrieb später.

Vorteil: Du musst Deine Applikation nicht nach jeder kleinen Änderung deployen (also die aktualsierten Dateien in ein bestimmtes Verzeichnis kopieren, auf das der webserver zugrreifen kann!)

hendrikS · Samstag 7. Februar 2009, 22:43

Ja und hier ist die eigentliche Lücke. Also ich nutze zur Entwicklung und Test einen Webserver (Xitami). Für diese Zwecke super geeignet.
Nur dieses WSGI Hello World will eben nicht. Und es mueste es ja nach Deiner Aussage auch ohne das ich die Applikation in der Konsole starte.

Hyperion · Samstag 7. Februar 2009, 22:53

hendrikS hat geschrieben:Ja und hier ist die eigentliche Lücke. Also ich nutze zur Entwicklung und Test einen Webserver (Xitami). Für diese Zwecke super geeignet.

Kenne ich nicht, daher kann ich dazu nichts sagen

Nur dieses WSGI Hello World will eben nicht. Und es mueste es ja nach Deiner Aussage auch ohne das ich die Applikation in der Konsole starte.

Du wirfst hier zig Sachen durcheinander! Was ist "die Applikation"? Wie sieht Dein "Hallo Welt" Script aus?

Ich nehme an, dass Du bisher immer CGI als Gateway von Xitami aus genutzt hast?

Dann musst Du eben Deine WSGI-Applikation mit einem geeigneten Handler wrappen. Diesen kannst Du als kleines eigenständiges Mini-Script erstellen. Dieses lässt Du dann vom webserver aus aufrufen.

[wiki]WSGI[/wiki]

Da findest Du ein Bsp dazu.