xwolf.de|com

Menü

Inhalt dieser Site

Ansicht

Individuelle Benutzerkonfiguration für die Site.

Druckansicht Startseite Suchen

A A A A

Internationale CGI-FAQ

Diese FAQ basiert auf die gleichnamige englische FAQ von Nick Kew. Ergänzungen, Änderungen und Übersetzung von Wolfgang Wiese.
Diese FAQ ist auch als ZIP-Archiv ladbar.
Copyright © Nick Kew, 1996/1997. Bitte lesen Sie die Copyright-Bestimmungen.

Inhalt

  1. Änderungen
    1. Copyright-Bestimmungen
    2. Dokument-Herkunft
    3. Kann ich dem Autor Fragen emailen?
    4. Sollte ich die Newsgroup comp.infosystems.www.authoring.cgi fragen?
    5. Credits
  2. Allgemeine Fragen
    1. Was ist CGI?
    2. Ist es ein Skript oder ein Programm?
    3. Wann brauch ich CGI?
    4. Sollte ich CGI oder JAVA nehmen?
    5. Sollte ich CGI oder SSI nehmen?
    6. Sollte ich CGI oder API nutzen?
    7. Was muss ich überhaupt wissen?
    8. Ist CGI kein Sicherheitsrisiko?
    9. Brauch ich UNIX?
    10. Muß ich Perl benutzen?
    11. Muß ich alles ins cgi-bin kopieren?
    12. Muß ich es *.cgi nennen? Oder *.pl?
    13. Was ist CGIWrap, und welchen Effekt hat es auf meine Programme?
  3. HTTP Header und NPH Skripten
    1. Was ist HTTP (HyperText Transfer Protocol)?
    2. Welche HTTP request header kann ich nutzen?
    3. Welche Environment-Variablen sind für meine Applikation verfügbar?
    4. Welche HTTP response header sollte ich kennen?
    5. Was ist NPH?
    6. Muß,/Kann ich nph Skripten schreiben?
    7. Muß ich es nph-* nennen?
    8. Was ist der Unterschied zwischen GET und POST?
  4. Technische Fragen: "Wie mache ich...?"
    1. Kann ich Informationen über meine Besucher bekommen?
    2. Kann ich die EMail meiner Besuchen bekommen?
    3. "Aber ich sah eine coole Seite, wo meine EMail-Adresse angezeigt wurde...."
    4. Kann ich die EMail-Adresse, die Leute in meiner Form eingeben, überprüfen?
    5. Kann ich Browser-Angaben bekommen und so unterschiedliche Seiten anbieten?
    6. Kann ich herausfinden, woher User kommen und wohin sie gehen?
    7. Kann ich einen langen Prozess starten und ein Seite zurückgeben, bevor es beendet ist?
    8. Kann ich einen langen Prozess starten und den Benutzer in es interagieren lassen?
    9. Kann ich meine Seiten mit Passwort schützen?
    10. Kann ich HTTP-Authentication mit CGI machen?
    11. Kann ich User identifizieren, ohne Passwort-Schutz?
    12. Kann ich User zu underen Seiten weiterleiten?
    13. Kann ich ein CGI-Skript ausführen, ohne daß eine Rückgabe erfolgt?
    14. Kann ich verschiedene Netscape-Frames adressieren?
    15. Kann ich Ausgabe auf einmal zu verschiedenen Frames schreiben?
    16. Kann ich mit einen CGI Skript sowohl Text als auch Bilder anzeigen lassen?
    17. Wie kann ich Caches nutzen um CGI schneller und Benutzerfreundlicher zu machen?
    18. Wie kann ich vermeiden, daß User "Submit" mehrmals klicken?
  5. Skripten: Gibt es ein Skript zu ...
    1. Wo sollte man nach Skripten und anderen Informationen suchen?
    2. Wo finde ich kostenlose Skripten?
    3. Diskussionsgruppen / Boards
    4. CSCW/Groupware
    5. Datensammlung
  6. Debugging eines CGI-Skriptes
    1. Gibt es interaktive debugging Tools oder Service?
    2. Ich hab Probleme mit meinen Headern. Was soll/kann ich tun?
  7. Weitere Informationen
    1. Andere FAQs / Sammlungen (Einschließlich Online-Bücher)
    2. Referenz

Kapitel 0: Änderungen

20. Mai 2003
Kontrolle der im Dokument enthaltenen Links. Einige Links wurden angepasst. Bei den Texten, zu denen es keine existierenden Dokumente mehr gab, wurden Änderungen durchgeführt.
27. April 1997
Übersetzung des englischen Textes mit Ergänzungen und Anpassung an aktuelle Stundards.

[Inhalt]

0.1: Copyright-Bestimmungen

Copyright 1996-7 Nick Kew.
Kopierung und Weitergabe dieses Dokuments im ganzen oder in Teilen ist erlaubt. Außnahme:
Sie machen dies kommerziell.
Sie lassen diese Copyrightbestimmungen weg,
Erklärung: Die Informationen in diesem Dokument werden mit gutem Willen und in der Hoffnung angeboten, daß sie nützlich sind. Es kann allerdings nicht dafür garantiert werden, daß alles korrekt, aktuell oder hilfreich ist.
Die Autoren entziehen sich jeglicher Verantwortung für eine falsche Nutzung diese Informationen.

[Inhalt]

0.2: Dokument-Herkunft

Dieses Dokument kann (in englisch!) gefunden werden auf den Seiten:
WDG, http://htmlhelp.com/
URL: http://htmlhelp.com/faq/cgifaq.html
WebThing ist eine interaktive Seite, welche CGI-Software benutzt, die es erlaubt, daß Kommentare und Ergänzungen zum CGI-FAQ gemacht werden können.

. Falls Sie die FAQ auf Ihre Website kopieren wollen, ist es vorteilhaft den Autoresponder von Nick Kew zu nutzen. Dort erhalten sie allerdings vorerst nur die englische Version. Die deutsche Version erhalten Sie durch das kopieren diese Seite.
undere Quellen:

  1. USENET: posted to newsgroups (TEXT)
    news:comp.infosystems.www.authoring.cgi
    news:comp.answers
    news:news.answers

  2. RTFM (TEXT)
    ftp://rtfm.mit.edu/pub/usenet/news.answers/www/cgi-faq

  3. RTFM WWW Mirror Sites (Zum Teil HTML)
    Europe - http://www.cs.ruu.nl/cgi-bin/faqwais
    America - http://www.cis.ohio-state.edu/hypertext/faq/usenet/
  4. Über EMAIL (Autoresponder) (HTML or TEXT):
    Senden Sie eine leere Mail mit dem folgenden Subject:
    send cgifaq.txt
    oder
    send cgifaq.html
    zu der Adresse:
    mailto:satfaq@pobox.com

[Inhalt]

0.3: Kann ich dem Autor Fragen mailen?

Ich bekomme schon mehr Mail als ich antworten kann; So ist die allgemeine Antwort: Nein. Ich bin kein kostenloses Hilfezentrum :)
Einzige Ausnahme kann sein, wenn etwas, was bereits in der FAQ steht Klärung bedarf. Erwarten Sie aber bitte keine persönliche Reply. Trotzdem könnte ich etwas an der FAQ ändern. Deswegen schauen Sie doch später nochmal nach, ob die Hilfe nicht präzisiert wurde.

Die Newsgroups sind dagegen der richtige Weg um Hilfe zu bekommen. Aber beachten Sie: Auf eine schlechte Frage wird sicher auch eine schlechte Antwort kommen.

[Inhalt]

0.4: Soll ich die Newsgroup comp.infosystems.www.authoring.cgi fragen?

Dies ist eine moderierte Newsgroup. Der Moderator ist ein Robot, der von Thomas Boutell ( mailto:boutell@boutell.com ) eingerichtet wurde. Die Newsgroup sendet beim ersten Postingversuch folgende (englische) Mail an Sie:
This newsgroup is self-moderated. Your first posting will not appear until you have read und responded to an automatic welcome mailing, at which point your posting will appear with no further delay. Provision will also be made to automatically approve first postings that contain a header requesting this. Subsequent postings are approved automatically.
Falls Ihr Newsreader Probleme hat moderierten Newsgroups Artikel zu senden, besteht die Möglichkeit die Artikel mit EMail auf die Newsgroup zu bringen:

mailto:authoring-cgi@boutell.com

Sofern Ihre Absenderadresse in der Mail richtig ist, bekommen Sie präzise Informationen wie Sie Ihr Artikel posten können.
Alternativen sind nachzulesen in der WWW FAQ die von Thomas Boutell regelmäßig veröffentlicht werden.

[Inhalt]

0.5: Credits

Diese FAQ wurde von Nick Kew geschrieben und verbessert durch die Hilfe und Kommentare, sowie Newsgroup-Artikel von Nathan Neulinger, Maurice L. Marvin, Matthew Healy und Alan J. Flavell.
Übersetzt wurde es von Wolfgang Wiese.

[Inhalt]

Kapitel 1: Allgemeine Fragen

In diesem Kapitel finden Sie Antworten auf allgemeine Fragen, über die Grundlagen von CGI und seiner Rolle in der Internet-Programmierung. Fragen/Antworten, welche nicht in undere Kapitel passen, sind hier ebenfalls aufgeführt.

1.1: Was ist CGI?

[ Aus der CGI Referenz http://hoohoo.ncsa.uiuc.edu/cgi/overview.html ] Das Common Gateway Interface, oder CGI, ist ein Stundard für Gateway Programmen zum Zwecke der Interaktion mit Servern, wie dem HTTP Server. Ein normales HTML-Dokument, welches der Web-Browser erhält ist statisch. Das heißt, es hat eine feste Form (eine Text-Datei), welche sich nicht ändert. Ein CGI Programm auf der underen Seite wird in Real-Time ausgeführt, so daß es dynamische Informationen ausgeben kann.

[Inhalt]

1.2: Ist es ein Skript oder ein Programm?

Dies ist eine Frage der Definition. Traditionell werden compilierte ausführbare (binäre) Dateien als Programme bezeichnet. Programme dagegen, die nur mit Hilfe eines Interpreters laufen werden als Skripten bezeichnet.
Im Bereich der CGI allerdings wurden diese Definitionen "schwammig". Beide Begriffe werden oft nebeneinunder benutzt (inklusive in diesem Dokument). Im Moment wird der Begriff "Skript" öfter benutzt für CGI Programme.

[Inhalt]

1.3: Wann brauch ich CGI?

Es gibt unzählige Kommentare auf diese Frage; Im Prinzip braucht aber jede Webseite, welche eine Form enthählt ein CGI Skript um die Eingaben zu verarbeiten.

[Inhalt]

1.4: Sollte ich CGI oder JAVA nehmen?

CGI und JAVA sind total unterschiedlich, und für die meisten Applikationen nicht verknüpfbar. Dennoch ist es zum Beispiel möglich ein CGI Programm in JAVA zu schreiben.

CGI ist ein Mechanismus um Programme auf einem WWW Server laufen zu lassen. Typische Anwendungen enthalten den Zugriff auf Datenbanken, das Absenden von Aufträgen oder Senden von Nachrichten an schwarze Bretter. JAVA dagegen ermöglicht es ein Programm auf der Maschine des Benutzers zu starten und wird zum Beispiel dazu verwendet Bilder zu manipulieren.

In einigen Fällen werden beide für eine einzelne Anwendung zu kombinieren: Zum Beispiel ein JAVA Applet um eine Region auf einer geographischen Karte zu bestimmen, zusammen mit ein CGI Skript,welches die Daten der selektierten Region verarbeitet.

[Inhalt]

1.5: Sollte ich CGI oder SSI nehmen?

CGI und SSI (Server-Side Includes) sind oft kombinierbar. Folgendes sollte man dabei beachten:
  1. CGI ist ein allgemeiner Stundard und wird von allen wichtigen HTTPDs unterstützt. SSI dagegen ist kein allgemeiner Stundard. Es ist eine Entwicklung von NCSA's HTTPD, welches von vielen Servern übernommen wurde.
  2. Falls Ihre Anforderungen klein genug sind, daß sie nur mit SSI auskommen können, dann ist dies auch der effizienteste Weg. Eine typische Anwendung könnte es sein, 'house styles', wie Toolbars oder Netscape-Eigene <body>-Tags zu benutzen.
  3. Für komplexere Anwendungen, wie die Verarbeitung einer Form, wo Sie ein Programm ausführen lassen müßen, ist CGI die bessere Wahl.

[Inhalt]

1.6: Sollte ich CGI oder API benutzen?

API ist ein Programmier-Interface, welches von einigen Betriebssystemen unterstützt wird. Die Benutzung von API schränkt deswegen die Portabilität Ihres Programms ein!
Falls Sie wissen, daß Ihr Programm nur auf einer bestimmten Plattform laufen soll, und API unterstützt wird, sollten Sie es nutzen. undernfalls bleiben Sie bei CGI.

[Inhalt]

1.7: Was muß ich überhaupt wissen?

Falls Sie bereits programmieren können, werden Sie feststellen, daß CGI extrem geradlinig in der Anwendung ist und deswegen einfach. Sie sollten sich nur die Zeit nehmen, folgende Informationen zu sichten:
  1. Installations-Einweisungen für Ihr HTTPD. Wurde es konfiguriert, so daß CGI Programme laufen können? Und wie erkennt der Server, daß es sich um ein CGI-Programm hundelt? (Lesen Sie hierzu Ihre MANUALS, READMEs, ISP Seiten/FAQs oder Ihren Systemadministrator)
  2. Die CGI Spezifikation von NSCA liefert Ihnen alle Informationen die Sie brauchen um Ihr Programm laufen zu lassen:
    http://hoohoo.ncsa.uiuc.edu/cgi/interface.html
  3. Lesen Sie die WWW Security FAQ. Dies ist zwar nicht notwendig, um ein Skript laufen zu lassen, aber es ist grundlegend um keine Probleme zu bekommen durch Sicherheitslöcher:
    http://www.w3.org/Security/Faq/
Falls Sie noch nie programmiert haben, bleibt Ihnen keine undere Möglichkeit als zu lernen! Falls Sie zum Beispiel noch Ihre Probleme haben, Programme von der Kommundozeile auszuführen, wie 'grep' oder 'cat', so haben Sie ein Problem.
Stellen Sie sicher, daß Ihre Skripten auf der Kommundozeile arbeiten, bevor Sie versuchen, sie

[Inhalt]

1.8: Ist CGI kein Sicherheitsrisiko?

Es ist ein Sicherheitsrisiko. Wenn es schlecht programmiert wurde.
Es gibt eine Vielzahl von Möglichkeiten, umd die Gefahr zu minimieren. Auf alle Fälle sollten Sie Lincoln Stein's WWW-Sicherheits-FAQ lesen und versuchen zu verstehen:
http://www-genome.wi.mit.edu/WWW/faqs/www-security-faq.html .

[Inhalt]

1.9: Brauch ich UNIX?

Nein, aber es wäre sehr hilfreich. Das Web, wie das internet selbst, C, Perl und fast jede gute Innovation der letzten 20 Jahre in der Informatik wurden zuerst auf UNIX gemacht. Auch im Moment ist UNIX das weitverbreiteste und am besten unterstützte Betriebssystem für Anwendungen im Web.
(Nein, dieser Satz kommt nicht aus Antipathie gegen Mircosoft, es ist wirklich wahr).

[Inhalt]

1.10: Muß ich Perl benutzen?

Nein. Sie können jede Programmiersprache benutzen, die sie mögen! Perl ist einfach nur die heute am meisten genutzte Sprache für CGI Anwendungen. undere oft benutze Sprachen sind C, TCL, BASIC und -für einfache Aufgaben- Shell Skripts.
Gründe für die große Verbreitung von Perl sind u.a. die dessen groß Fähigkeiten bei der Text-Manipulation und der groß Anzahl an Modulen.

[Inhalt]

1.11: Muß ich alles ins cgi-bin kopieren?

Vielleicht. Dies hängt von den Einstellungen Ihres Servers ab.

[Inhalt]

1.12: Muß ich es *.cgi nennen? Oder *.pl?

Vielleicht. Dies hängt von der Einstellung Ihres Servers ab. Diese Dateinamen sind nicht mehr als eine gebräuchliche Konvention und auch nicht mehr. Es hängt von dem Server-Administrator ab, welcherart Einstellungen vorgenommen sind und welche Konventionen deswegen benutzt werden sollten.
Falls Sie Ihren eigenen Server besitzen, lesen Sie die Manuals. Falls Sie Webspace gemietet haben, lesen Sie die betreffenden Seiten oder FAQs Ihres Providers. Falls alles nichts hilft, fragen Sie den Server-Administrator.

[Inhalt]

1.13: Was ist CGIWrap, und welchen Effekt hat es auf meine Programme?

Ausschnitt aus http://www.umr.edu/~cgiwrap/intro.html:
CGIWrap is a gateway program that allows general users to use CGI scripts und HTML forms without compromising the security of the http server. Scripts are run with the permissions of the user who owns the script. In addition, several security checks are performed on the script, which will not be executed if any checks fail. CGIWrap is used via a URL in an HTML document. As distributed, cgiwrap is configured to run user scripts which are located in the ~/public_html/cgi-bin/ directory.

Sehen Sie auch auf http://www.umr.edu/~cgiwrap/

[Inhalt]

Kapitel 2: HTTP Headers und NPH Skripten

Dies ist ein mehr technisches Kapitel, welches mit HTTP beschäftigt. Es enthält auch NPH, dem Mechanismus, mit dem CGI Programme HTTP Header Informationen direkt zum Client zurückgeben können.

2.1: Was ist HTTP (HyperText Transfer Protocol)?

HTTP ist das Protokol mit dem Server und Klienten (in der Regel Webbrowser) kommunizieren. Eine HTTP-Transaktion besteht aus einer Anfrage, welche von einem Klienten an einen Server gesandt wird und der Antwort, die vom Server geantwortet wird.
Jede HTTP-Anfrage und Antwort enthält einen Nachrichtenkopf ("Header") welcher die Nachricht beschreibt. Dieser wird durch den HTTPD ausgewertet. CGI Programme ignorieren diese Informationen jedoch oft. Es können auch weitere Informationen übergeben werden.
  1. Eine HEAD- oder GET-Anfrage sendet nur einen Header. Die FORM-Daten werden in den HTTP_QUERY_STRING übergeben, welche für ein CGI Programm mit der Variable QUERY_STRING abgefragt werden können.
  2. Eine POST-Anfrage sendet sowohl Header als auch den Body. Der Body enthält typischerweise die Daten, die vom Benutzer in einer Form eingegeben wurden.
  3. Eine HEAD-Anfrage erwartet keinen Body in der Antwort.
  4. Eine GET- und eine POST-Anfrage kann sowohl Antworten mit wie ohne Body akzeptieren. Normalerweise enthält der Body ein HTML Dokument.

[Inhalt]

2.2: Welche HTTP-Request Header kann ich nutzen?

Die meisten HTTP Request Header werden zu CGI Skripten als Environment-Variablen übertragen. Einige sind fest und Abhängig von der CGI-Spezifikation. Andere sind Abhängig von Server, Browser und Programmen.
Um zu sehen, welche Informationen Ihr Browser und der Server miteinander austauschen, können Sie das folgende einfache CGI-Skript benutzen, welches die Environment-Variablen ausgibt. In UNIX:
#!/bin/sh
echo "Content-type: text/plain"
echo
set

(Benennen Sie es einfach "env.cgi" und kopieren Sie es in das Verzeichnis, in welcher der Server CGI-Programme ausführt. Dann lassen Sie Ihren Browser die folgende URL anzeigen: http://www.example.org/verzeichniss/zu/env.cgi ).

Für weitere Details über die einzelnen Variablen lesen Sie die CGI-Spezifikation bei http://hoohoo.ncsa.uiuc.edu/cgi/env.html. (Dort finden Sie auch eine Version des obigen Skriptes, welche aber die Variablen schöner formatiert ausgibt.)

[Inhalt]

2.3: Welche Environemt-Variablen sind für meine Applikation verfügbar?

Sehen Sie die vorige Frage. Jene, die total verfügbar sind lassen sich den NCSA-Dokumenten entnehmen. Jene, welche nur für Ihren Server und Browser verfügbar sind erhalten Sie, wenn Sie das obige Skript ausführen.

[Inhalt]

2.4: Welche HTTP response headers sollte ich kennen?

Solange Sie nicht NPH benutzen, wird der HTTPD alle nötigen Antworten übergeben. Natürlich immer Abhängig davon, wie der Server eingestellt ist.

Wie auch immer, es gibt eine Übereinkunft für Server den Content-type Header basierend auf dem Dateinamen der URL einzusetzen; Für ein CGI-Skript kann dies oftmals zu Fehlern führen.
Der übliche Rat ist deshalb, explizit einen Content-type ausgeben zu lassen.

Einige andere Header die Sie nutzen können sind:

Sie können auch MIME Header benutzen: Zum Beispiel "Keywords" um die Vorteile von Suchmaschinen auszunutzen. Die "offizielle" Liste der HTTP Header kann man finden bei http://www.w3.org/pub/WWW/Protocols/HTTP/Object_Headers.html

[Inhalt]

2.5: Was ist NPH?

NPH = "No Parsed Headers". Dieses Skript vermeidet es, alle HTTP Response Header auszugeben. Der HTTPD ist deswegen daraufhin angewiesen, die Header nicht zu parsen, wie es normalerweise tun würde.

[Inhalt]

2.6: Muß / Kann ich NPH Skripten schreiben?

Im allgemeinen nicht. Es ist üblicherweise besser, dem HTTPD diese Arbeit zu überlassen. Falls Sie dennoch NPH nutzen wollen, sollten Sie unbedingt die HTTP Spezifikation bei http://www.w3.org/pub/WWW/Protocols/ lesen.

Ihr Header sollte komplett und richtig sein. Denn Sie weisen den HTTPD an, den Header nicht zu korrigieren oder fehlendes zu ergänzen. Mögliche Umstände, die die Benutzung von NPH empfehlen sind: Sehen Sie auch http://www.w3.org/pub/WWW/Protocols/HTTP/HTRESP.html

[Inhalt]

2.7: Muß ich es nph-* nennen?

Nach den NCSA Referenzseiten ist dies ein Standard dafür, um den Server zu sagen, daß es sich um ein NPH-Skript handelt. Somit sollten Sie diese Konvention auch übernehmen.

[Inhalt]

2.8: Was ist der Unterschied zwischen GET und POST?

Zuerst muß man wissen, daß das HTTP Protokol unterschiedliche Zwecke mit beiden Methoden verfolgt. GET-Anfragen sollten immer alleine auftreten. D.h., wenn eine GET-Anfrage Variablen auf dem Server ändert, dann sollten zwei oder mehr weitere identische Anfragen keinen weiteren Effekt ausmachen.

Dies sollte bei der CGI-Programmierung beachtet werden. Falls ein Benutzer eine Seite "reloaded" wird eine identische Anfrage wie beim ersten Aufruf der Seite zum Server gesandt. Dies kann dann dazu führen, daß Sie dann zwei identische Einträge in Ihrem Gästebuch, in einem Counter oder einem anderen Programm haben.

GET ist theoretisch die bessere Methode bei Operationen, die nicht doppelt ausgeführt werden sollen, wie z.B. Anfragen an Datenbanken. Da allerdings viele Systeme die Länge einer GET-Anfrage beschränken ist es bei langen Anfragen (um die 1Kb) zu empfehlen POST zu nutzen.

POST und GET unterscheiden sich im wesentlichen durch die Art, wie Parameter zum CGI-Skript übertragen werden. Im Falle von POST werden die Form-Daten zum STDIN weitergeleitet, so daß das Skript von dort lesen muß. Im Falle von GET werden die Daten der Environment-Variable QUERY_STRING übergeben.
Der "content-type" (application/x-www-form-urlencoded) ist identisch für GET- und POST-Anfragen.

[Inhalt]

Kapitel 3: Technische Fragen: "Wie mache ich...?"

Dieses Kapitel enthält Programmierhinweise und Tips für eine Anzahl von immer wieder auftretenden Problemen. Außerdem finden sich hier einige Fragen, wo die Antwort ein "Dies geht (so) nicht" ist, zusammen mit dem Grund warum.

3.1: Kann ich Informationen über meine Besucher bekommen?

Viele Leute fragen immer wieder wie man Besucher-Daten erhalten kann, oder machen Vorschläge wie man diese erhacken könnte. Es scheint, sie wollen einfach kein "Nein" als Antwort akzeptieren...

Der Hintergrund ist: Jede Art von Daten, die Sie erhalten können, kann auch jeder andere, aber auch wirklich jeder, im Netz bekommen! Wenn also ein Browser es dennoch mal erlaubt persönliche Daten über Besucher zu sammeln, dann wird dies gemeldet, und der Bug schnell wieder behoben.

Sie können allerdings begrenzte Informationen durch die Environment-Variablen erhalten. Aber nur wenige von diesen werden auch in jedem Fall übergeben. Einige andere können zu falschen Resultaten f¨hren. Für eine genauere Erklärung der Variablen sehen Sie unten, bzw. die NCSA-Referenzseiten.

[Inhalt]

3.2: Kann ich die EMail meiner Besucher bekommen?

Warum wollen Sie dies?

Die besten Informationen erhalten Sie durch die Variablen REMOTE_ADDR und REMOTE_HOST, welche Ihnen aber nichts über den User aussagen. Techniken, wie "finger@" sind nicht ratsam und werden von den meisten Usern abgelehnt. Außerdem sind sie oft nicht zuverlässig, produzieren dafür aber totsicher lange Wartezeiten. Besser, und höflicher, ist es, den Benutzer mit einer Form selbst zu fragen.

Übrigens: Die "From:" Header Zeile (HTTP_FROM Variable) wird im allgemeinen nur von Robots gesetzt, da normalerweise richtige Besucher nicht unbedingt wollen, daß ihre Addressen ohne Erlaubnis gesammelt werden. Browser respektieren diese Persönlichkeitsrecht. Tun Sie es bitte auch.

[Inhalt]

3.3: "Aber ich sah eine coole Seite, wo meine EMail angezeigt wurde..."

Einige Sites benutzen Tricks, mit denen es Möglich ist, von einigen Usern die EMail-Addresse zu erfahren. Man kann dies unter anderen daran erkennen, daß die Ladezeiten dieser Sites außerordentlich lang sind (Ein "finger" auf @REMOTE_HOST wird dann meist durchgeführt. Dies funktioniert allerdings nicht oft, kann allerdings auch nicht erkannt werden.), oder durch einen "Submit"-Button, welches anscheinend garnichts tut. Ein <a href="mailto:user@domain.org">mailto:</a> funktioniert auch gut, kann allerdings leicht entdeckt werden.
Ein "Snoop" funktioniert dagegen schon viel besser. Aber sollten Sie feststellen, daß jemand diese Möglichkeit ausnutzt, sollten Sie dessen Provider alarmieren!

[Inhalt]

3.4: Kann ich die EMail, die Leute in meiner Form eingeben, überprüfen?

Leider benutzen einige Leute mitunter falsche oder ungültige EMail-Addressen in Ihrer Form. Noch schlimmer ist es, wenn Sie eine gültige, aber falsche Addresse eingeben, so daß jemand anders Ihre Mail bekommt, der diese garnicht haben will.

Eine Möglichkeit herauszufinden, ob eine EMail-Addresse richtig ist, ist es, diese nach Zeichen zu durchsuchen, die in einer Addresse vorkommen müssen, bzw. nicht vorkommen dürfen. Allerdings versagen die meisten dieser Methoden gegen gültige Addressen, wie z.B. "S=N.OTHER/OU1=X12345A/RECIPNUM=1/MTA-BASIC@attmail.com".

Der wohl beste Parser und Checker ist bei Tom Christiansen zu finden und kann heruntergeladen werden, bei http://www.perl.com/CPAN/authors/Tom_Christiansen/scripts/ckaddr.gz Natürlich sagt dies noch immer nichts darüber aus, ob Nachrichten übertragen werden können.

Der beste Weg, herauszufinden, ob eine EMail richtig ist, ist es immer noch, eine Mail zu der angegebenen Addresse zu schicken, und den Benutzer aufzufordern diese zu bestätigen. Fügen Sie ein Text ein wie "Falls diese Mail sie fälschlicherweise erreicht hat, entschuldigen Sie bitte die Störung".

[Inhalt]

3.5: Kann ich Browser-Angaben bekommen und so unterschiedliche Seiten anbieten?

Warum wollen Sie dies?

Gut geschriebenes HTML wird auf jedem Browser korrekt dargestellt. Somit ist die richtige Antwort auf diese Frage, daß man sich ein verfahren erstellt, mit dem man Ausgaben in gutes HTML macht.
Wenn Sie dennoch eine andere Antwort wollen, können Sie die HTTP_USER_AGENT-Variable benutzen. Dies verlangt aber Vorsicht, denn diese Variable kann zu unerwarteten Ergebnissen führen. Zum Beispiel kann das checken auf "Mozilla" und das liefern eines Frames bei positiver Antwort auch dazu führen, daß Sie einen Frame an einen alten Netscape-Browser liefern, der Frames noch nicht unterstützt. Auch gibt es Browser, wie MicroSoft, die dummerweise diesen String übernommen haben und nicht mit Frames umgehen können. Auch gibt es Möglichkeiten, die HTTP_USER_AGENT-Variable auszutricksen, und einen Browser vorzugeben, den man garnicht hat.

Denken Sie auch daran, daß nicht jeder User Agent ein Browser ist. Ihre Seite kann von einem User Agenten geladen werden, von dem Sie noch nie gehört haben, und der dann seine Informationen an 100 verschiedenen anderen Browsern oder einem Proxie weiterleitet. Dies ist ein weiterer Grund, lieber gutes HTML zu schreiben, anstelle einer coolen, aber schlechten Lösung.

[Inhalt]

3.6: Kann ich herausbekommen, woher User kommen, und wohin sie gehen?

HTTP_REFERER kann unter Umständen helfen. Sie können es auf jedenfall benutzen f¨r Statistiken, wenn Sie z.B. an einem Banneraustausch teilnehmen. Allerdings wird diese Variable nicht immer gesetzt und kann deswegen in die Irre leiten. Zum Beispiel wenn ein User ein Bookmark auf Ihre Seite gesetzt hat und der Browser nicht schlau genug ist, um hieraus die Variable zu setzen.
Es ist im Moment nicht möglich den Weg von einer Seite heraus zu einer fremden anderen Seite zu verfolgen. Falls Sie es wirklich versuchen wollen, weisen Sie alle Ihre herausgehenden Links auf den HTTPD und benutzen Sie dessen Zurückverfolgungs-Fähigkeit. Dies ist weniger aufwendg als die Benutzung eines CGI-Skripts.

[Inhalt]

3.7: Kann ich einen langen Prozeß starten und eine Seite zurückgeben, bevor es beendet ist?

[UNIX]
Sie müssen langelaufende Prozeße forken/spawnen. Wichtig dabei ist, daß man nicht vergißt alle File-Diskriptoren zu schließen; Ansonsten nichts wird zurückgegeben, bis das Programm zum Ende gekommen ist. Ein Standard-Trick ist es auf /dev/null zu redirecten:

exec ("long_process < /dev/null > /dev/null 2>&1 &")
print HTML page as usual

[Inhalt]

3.8: Kann ich einen langen Prozeß starten und den Benutzen in es interagieren laßen?

Dies passt nicht gut zu den grundlegenden Mechanismen des Webs, in denen jede Transaktion aufgeteilt ist in Anfrage und Antwort. Falls Ihre Aufgabe auf dem Computer des Users ausgeführt werden kann, empfiehlt sich eine Clientside-Applikation; Also z.B. ein JAVA Applet.

[Inhalt]

3.9: Kann ich meine Seiten mit einem Passwort schützen?

Ja. Benutzen Sie die HTTPD-Autentifizierung. Dann können Sie alle Ihre Seiten weiterhin genauso erstellen wie alle anderen HTML-Seiten, besitzen aber dennoch Passwortschutz.
Außerdem können Sie nun jeden Besucher anhand der Variable REMOTE_USER identifizieren.

[Inhalt]

3.10: Kann ich HTTP-Authentikation mit CGI machen?

Ja, Sie können CGI dazu benutzen um das Username/Passwort-Dialog des Browsers aufzurufen. Senden Sie einen Response Code von 401 zusammen mit einem "WWW-authenticate" Header, welcher Details für die Identifizierung enthält:

Status: 401 Unauthorized to access the document
WWW-authenticate: Basic realm="foobar"
Content-type: text/plain

Unauthorised to access this document
Der Nutzen den man hieraus ziehen kann, ist Abhängig vom Server. Außerdem ist es schwieriger zu implementieren, da die meisten Server erwarten, zuerst eine Identifizierung zu machen, bevor ein CGI-Skript ausgeführt werden kann (z.B. durch ".www_acl" oder ".htaccess").
Deswegen kann dieses Verfahren im allgemeinen nicht die normale Login-Sequenz ersetzen.

[Inhalt]

3.11: Kann ich den User ohne Passwortschutz identifizieren?

Üblich ist es, dies mit einem Cookie zu tun. Falls Sie dies allerdings tun, müssen Sie daran denken, daß nicht jeder User mit Cookies erfasst wird. (Meiner Erfahrung ist es sogar so, daß die Leute, die von Cookies wissen, diese generell ablehnen bzw. Ihren Browser so einstellen, daß keine Cookies eingerichtet werden.)
Eine Alternative ist es, den Seiten eine ID zu geben und diese durch ein verstecktes CGI-Skript abzufragen. Allerdings bedeutet dies eine große Netzlast, da jede Seite ein CGI-Skript startet.
Eine andere Möglichkeit ist die "Hyper-G" Lösung, die eine verschlüsselte ID mit der URL übergibt:
http://www.example.org//session_id/real/path/to/page
Dies hat den Nachteil, daß die URLs lang und verwirrend anzusehen sind und das User-Bookmarks Seiten mit alten IDs abrufen.
Beachten Sie, daß eine ID, welche auf der Variablen REMOTE_HOST (oder REMOTE_ADDR) basiert, nicht funktioniert, wenn verschiedene User von derselben Machine kommen.

[Inhalt]

3.12: Kann ich User zu anderen Seiten weiterleiten?

Für eine dauerhafte und einfache Weiterleitung benutzen Sie die HTTPD Konfigurations-Datei. Dies ist viel effizienter als wenn Sie es selbst tun (z.B. durch eine Dummy-Seite mit einem META-Tag). Einige Server unterstützen Sie darin, indem Sie einfach eine Datei in Ihren eigenen Verzeichniss ablegen (z.B. Apache), andere benutzen eine einzige Konfigurations-Datei worin alle zu weiterleitenden Seiten vermerkt sind.

Für kompliziertere Fälle (wenn z.B. auch Eingaben weitergeleitet werden müssen) sollten Sie den "Location:" Response Header benutzen.

[Inhalt]

3.13: Kann ich ein CGI-Skript ausführen, ohne daß eine Rückgabe erfolgt?

Ja, aber bedenken Sie folgendes: Wie werden Ihre Besucher wissen, daß Ihr "submit" ausgeführt wurde? Sie werden "submit" mehrmals tippen!
Die korrekte Lösung nach der HTTP Spezifikation ist es ein HTTP Status Code 204 zurückzugeben. Die Lösung kann dann folgendermaßen aussehen:
#!/bin/sh
# do processing (or launch it as background job)
echo "HTTP/1.0 204 No Change"
echo
Alan J. Flavell hat darauf verwiesen, daß dies unter Umständen bei einigen Browsern versagen kann und gab einen Vorschlag dies zu korrigieren: 1. Send status 204, Content-type of text/html, und a short body content that (for those few browsers that display it) will tell the reader that their browser does not handle this reponse correctly, und invites them to use their browser's Back function (hey, if someone tells me to put a back button on the HTML page itself, I think I shall scream...). Seine Zusammenfassung befindet sich bei folgender URL: http://ppewww.ph.gla.ac.uk/%7Eflavell/status204/results.html

[Inhalt]

3.14: Kann ich verschiedene Netscape-Frames addressieren?

Ja. Das Sie CGI benutzen macht keinen Unterschied: Benutzen Sie "target=" genauso wie auch in ein normales HTML-Dokument. Alternativ kann das Skript ein "Window-target" ausgeben. Lesen Sie hierzu auch die Seiten von Netscape; Diese beantworten alle Fragen zu Frames.

[Inhalt]

3.15: Kann ich Ausgaben auf einmal zu verschiedenen Frames schreiben?

Ein einziges CGI Skript kann immer nur in ein einziges Frame schreiben.

Wie auch immer, diese Einschränkung kann man umgehen, wenn man mehrere Skripte benutzt. Das erste Skript (Z.B. die URL des Submit-Buttons) schreibt ein Frameset, typischerweise mit dem Ziel "_parent" oder "_top".
Der HTML-Code einer oder aller Frames kann dabei durch das CGI-Skript ausgegeben werden. Dies Vorgehen ist allerdings nicht zu empfehlen. Falls Sie wollen, das das Design Ihrer Seite durch den User bestimmt werden kann, sollten Sie besse versuchen, dies auf einer höheren Ebene zu machen.

Beachten Sie:
  1. Vergessen Sie nicht, die URLs zu escapen.
  2. Diese Technik verursacht auf dem Server die Anfragen von vielen zum Teil gleichzeitigen Requests. Die Folge ist, daß Ihr Speicherverbrauch stark wächst. Insbesonders, wenn Sie mit Perl programmiert haben.


Eine gute Alternative ist es, Javaskript hier zu benutzen. Es gibt hierzu schon einige gute Lösungen auf entsprechenden JAVA-Sites.
Bedenken Sie nur, daß Javaskript je nach Browser unterschiedliche Ausgaben machen kann, bzw. auch bei einigen Benutzern ausgeschaltet ist.

[Inhalt]

3.16: Kann ich mit einem CGI-Skript sowohl Text als auch Bilder anzeigen lassen?

Nur indirekt. Ein Skript kann in der Regel nur eine Antwort auf ein Request senden.

Falls Sie eine dynamische Seite erzeugen lassen wollen, auf der unterschiedliche Grafiken je nach der Eingabe des Benutzers erscheinen, dann können folgendes tun:
In der Ausgabe Ihres Skriptes (ein HTML-Code) lassen Sie verschiedene weitere Requests automatisch starten. Die Ausgabe des ersten Skriptes wuerde dann im HTML-Code folgendes enthalten:

<img src="[Bild-generierendes-Skript]" alt="[Useranfrage]">


[Inhalt]

3.17: Wie kann ich Caches nutzen um CGI schneller und Benutzerfreundlicher zu machen?

Dies geht über diese FAQ hinaus!
Auf den folgenden Seiten wird dies Thema aber ausreichend erörtert:

[Inhalt]

3.18: Wie kann ich vermeiden, daß User mehrmals "Submit" anklicken?

Nein. Alles was Sie tun können, ist darauf in der richtigen Weise zu reagieren.

Eine Möglichkeit könnte es z.B. sein, bei jedem "Submit" einen Eintrag in eine gesonderte Log-Datei zu machen, in dem die Zeit und der Host des Submits geloggt werden. Wurde bereits ein Submit innerhalb einer gewissen Zeitspanne gemacht, kann man dies aus dem Log errechnen.
Ist die Zeitspanne unter ein gesetztes Limit, gibt man dem Benutzer eine Warnung aus, nicht mehrmals Abfragen zu senden. Andernfalls läßt man einfach das Skript wie normal weiterarbeiten.

Eine andere Möglichkeit wäre es, Cookies einzusetzen. Hier sollten Sie aber daran denken, daß viele Benutzer Cookies als Eingriff in Ihre Privatspähre erachten und Ihren Browser so konfiguriert haben, daß keine Cookies angenommen werden.

[Inhalt]

Kapitel 4: Gibt es ein Skript zu ...

Es gibt in der Tat eine große Zahl an vorhandenen Skripts zu fast allen Bereichen. Bevor Sie auf die Idee kommen Software zu kaufen, sollten Sie unbedingt vorher im Netz schauen, ob es das von Ihnen gesuchte nicht bereits umsonst gibt! Glauben Sie auf keinen Fall den bekannten Versprechen von Softwarefirmen, daß nur kommerzielle Software Ihren Ansprüchen gerecht sein kann.

Viele Fragen dieser Art wurden bereits in anderen FAQs (Zum Beispiel der von Thomas Boutell) beantwortet. Ich will jetzt nicht Dinge wiederholen, die bereits 1000 mal gesagt wurden. Deswegen bitte ich, doch dort weiterzulesen.

4.1: Wo soll man nach Skripten und anderen Informationen suchen?

Es gibt viele Seiten, auf denen Sammlungen von CGI-Skripten angeboten werden. (Leider sind die meisten nur Sammlungen die immer nur dasselbe alte Zeug blind kopiert haben; Die Anzahl der Seiten, wo wirklich aktive Programmierer hinterstecken, ist gering.)

Matt Wright - selbst Author von vielen bekannten CGI-Skripten - hat im März 97 eine neue Seite eröffnet, in der CGI Skripten zu unterschiedlichsten Themen von vielen CGI Authoren zusammengefasst worden:

http://www.cgi-resources.com/

[Inhalt]

4.2: Wo finde ich kostenlose Skripten?

(Sehen Sie auch die vorherige Frage hierzu!)
Einige populäre Sites für eine große Auswahl an CGI-Skripten sind:

[Inhalt]

4.3: Discussion group/bulletin board

David R. Woolley managed eine Liste mit zur Zeit etwa 100 Systemen auf: http://freenet.msp.mn.us/~drwool/webconf.html ("Conferencing on the Web").

Das folgende Board wird von mir selbst unterhalten, und wird in Kürze auch mit einer Mailingliste verbunden werden:

[Inhalt]

4.4: CSCW/Groupware

Es gibt einige Seiten, die eine Übersicht hierüber haben:

[Inhalt]

4.5: Database

Dies verlangt eine eigene FAQ. Gefragt, Matthew.Healy@yale.edu (Matthew D. Healy) gab diese Antwort:

> : Is there a CGI und Database FAQ available?
> : If so, could someone tell me where can I get it?
>
> Dunno about a FAQ on that. I can recommend a couple of published
> works, however:
>
> 1. I wrote a chapter about CGI/Database work for the book
> {Special Edition Using CGI}. Fulltext is online at the
> publisher's WWW site.
>
> http://www.mcp.com
>
> 2. Jeff Rowe wrote an excellent book, {Building Internet Database
> Servers With CGI}.
>
> Jeff's WWW site has scads of useful information on WWW/DBMS programming,
> und pointers to lots more sites.

[Inhalt]

Kapitel 5: Debugging eines CGI-Skriptes

Da dieses Thema bereits auf anderen Dokumenten ausführlich behandelt wird, wird diese FAQ hier etwas wenig zu sagen.

Tom Christiansen's "Idiot's guide to solving Perl/CGI problems" ist eine Auflistung von ganz allgemeinen Problemen, und Antworten wie man diese löst.

Marc Hedlund's CGI FAQ und Thomas Boutell's WWW FAQ behandeln ausserdem dieses Thema.

Unten finden Sie die Links zu diesen Seiten.

5.1: Gibt es interaktive debuggings Tools oder Dienste ?

Falls Sie Perl benutzen, holen Sie sich Lincoln Stein's CGI.pm Modul. Dies erlaubt es nicht nur, billige CGI-Programme, die "Hallo Welt" ausgeben zu machen, es bietet auch einige Tools zur Fehlerfindung und Vermeidung. (Es hat nur den Nachteil, das es etwas groß ist..)


Nathan Neulinger's cgiwrap ist ein anderes Paket für das Debugging.
http://www.umr.edu/~cgiwrap/
(Aber Vorsicht: Es wurde von Sicherheitslücken berichtet, die auf schlechte Konfiguration bei den Anwendern begründet lag)

[Inhalt]

5.2: Ich habe Probleme mit meinen Headern. Was kann ich tun?

Für einfache Fälle empfiehlt es sich die Reponse Header von Hand aus zu untersuchen: Nun erhalten Sie die Response Header.

Bein schwierigeren Fällen, wie wenn ein Request mit mehreren Header gesandt wird, oder bei dem Übertragen einer Form, empfiehlt es sich den kostenlosen Diagnose-Service von WebThing WebCentre zu nutzen. Dieses nimmt ein Request von Ihren Browser entgegen und leitet es an den Server weiter. Daraufhin wird die komplette Request, wie auch die Antwort vom Server ausgegeben.
http://pobox.com/~webthing/

[Inhalt]

Kapitel 6: Weitere Informationen



6.1: Andere FAQs / Sammlungen (einschließlich Online-Bücher)

Special Edition Using CGI
http://www.mcp.com/que/et/se_cgi/
Die "Web Authoring FAQ" von 'Galactus' Engelfriet und John Pozadzides
http://htmlhelp.com/links/wdgfaq.htm
Für allgemeine Fragen über WWW, die "World Wide Web FAQ" von Thomas Boutell
http://www.boutell.com/faq/
Perl/CGI programming FAQ, von Shishir Gundavaram und Tom Christiansen
http://www.perl.com/perl/faq/perl-cgi-faq.html
"The Idiot's Guide to solving Perl/CGI problems" von Tom Christiansen
http://www.perl.com/perl/faq/idiots-guide.html
"WWW Security FAQ" von Lincoln Stein
http://www-genome.wi.mit.edu/WWW/faqs/www-security-faq.html
CGI Resources Library
http://www.cgi-resources.com/

[Inhalt]

6.2: Referenz Seiten

The Common Gateway Interface (CGI)
http://hoohoo.ncsa.uiuc.edu/cgi/interface.html
HyperText Transfer Protocol (HTTP)
http://www.w3.org/pub/WWW/Protocols/HTTP/
HyperText Markup Language (HTML)
http://www.w3.org/pub/WWW/MarkUp/

[Inhalt]



Info

$Id: cgifaq.shtml,v 1.4 2003/05/23 13:41:50 xwolf Exp $
© 1996 - 2003 by xwolf