|
Perinet Webspace-Providing
Doppelklick Diese FAQ basiert auf die gleichnamige englische FAQ von Nick Kew. Ergänzungen, Änderungen und Übersetzung von Wolfgang Wiese.
Copyright © Nick Kew, 1996-7. Bitte lesen Sie die Copyright-Bestimmungen. Inhalt
Kapitel 0: Änderungen
0.1: Copyright-BestimmungenCopyright 1996-7 Nick Kew.Kopierung und Weitergabe dieses Dokuments im ganzen oder in Teilen ist erlaubt. Außnahme:
Die Autoren entziehen sich jeglicher Verantwortung für eine falsche Nutzung diese Informationen. [Inhalt] 0.2: Dokument-Herkunft
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:
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.
[Inhalt] 0.5: CreditsDiese 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 FragenIn 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:
[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:
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.[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 ]
Sehen Sie auch auf http://www.umr.edu/~cgiwrap/ [Inhalt] Kapitel 2: HTTP Headers und NPH SkriptenDies 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.
[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:
(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://ihr.server//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. 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:
[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.
[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 mailto: 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.
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:
[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:
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: 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:
[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".
Beachten Sie:
Eine gute Alternative ist es, Javaskript hier zu benutzen. Es gibt hierzu schon
einige gute Lösungen auf entsprechenden JAVA-Sites. [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:
[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. 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: [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 boardDavid 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/GroupwareEs gibt einige Seiten, die eine Übersicht hierüber haben:
[Inhalt] 4.5: DatabaseDies verlangt eine eigene FAQ. Gefragt, Matthew.Healy@yale.edu (Matthew D. Healy) gab diese Antwort:
Matthew's CGI Link-Liste auf http://ycmi.med.yale.edu/~healy/cgilinks.html erweitert die Listen und enthält außerdem einige Links zu wichtigen Libraries, wie z.B. expunds the list, und includes links to popular packages including Bo Frese Rasmussen's WDB auf http://venus.dtv.dk/~bfr/wdb/ [Inhalt] Kapitel 5: Debugging eines CGI-SkriptesDa 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..)http://www-genome.wi.mit.edu/ftp/pub/software/WWW/cgi_docs.html
Nathan Neulinger's cgiwrap ist ein anderes Paket für das Debugging. [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:
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.
[Inhalt] Kapitel 6: Weitere Informationen6.1: Andere FAQs / Sammlungen (einschließlich Online-Bücher)
[Inhalt] 6.2: Referenz Seiten
|