Perl oder HTML-Fehler bei CGI mit Netscape?
Thomas
- cgi
Hallo,
jetzt ist es soweit. Ich bin völlig am Ende meines Lateins!!
Die Situation: Wir sind letzte Woche von NT auf Linux umgestiegen (COBALT-RAQ2+) die meisten Skripte funktionierten einwandfrei. Die Perl-Änderungen waren überschaubar und erfolgreich. Nur eines will einfach nicht so, wie es soll.
Auf dem IE(5) kein Problem. Ich habe hier gelesen, dass der aber kein Maßstab ist, weil er sehr viele HTML-Fehler übersieht. Mit Netscape(4.6) wird immer die HTML-Ausgabe mi klartext ausgegeben. Diese ist aber völlig richtig!! Warum verarbeitet NS diese Ausgabe nicht?
Habe bereits ALLES versucht, was ich im Archiv gefunden habe. Sämtliche Tips von Euch hatten keinen Erfolg.
Das merkwürdigste ist, dass ein anderes Programm, welches in der gleichen Art und Weise geschrieben wurde funktioniert einwandfrei!!
Der Netscape weigert sich standhaft die gesendeten HTML-Tags zu verarbeiten. Dazu bemerkt, dass ich aus schlechten Erfahrungen so gut es geht vermeide Standard-Module zu nutzen. Hat manchmal auch Nachteile, aber bis jetzt komme ich gut damit klar. CGI.PM ist also kein Thema. Meine Versuche hatten nämlich auch hier keine Verbesserung zur Folge. Ich programmiere immer so einfach ich nur kann, damit die Übersicht erhalten bleibt.
Sollten noch Fragen offen sein, um mir helfen zu können, bitte schamlos stellen. Ich werde sehen, ob ich die nötigen Infos zusammen bekomme.
Vielen Dank im Voraus.
Thomas
Moin!
Auf dem IE(5) kein Problem. Ich habe hier gelesen, dass der aber kein Maßstab ist, weil er sehr viele HTML-Fehler übersieht. Mit Netscape(4.6) wird immer die HTML-Ausgabe mi klartext ausgegeben. Diese ist aber völlig richtig!! Warum verarbeitet NS diese Ausgabe nicht?
Du sagst es und so isses auch. Ich hatte mal ein Script was eine Tabelle erzeugt, im IE ging es, im NN nicht - Ursache: die Tabelle war nicht geschlossen (Tag vergessen).
Viele Grüße, Rolf
Hallo Rolf,
» Du sagst es und so isses auch. Ich hatte mal ein Script was eine Tabelle erzeugt, im IE ging es, im NN nicht - Ursache: die Tabelle war nicht geschlossen (Tag vergessen).
»
Habe ich auch schon versucht zu prüfen. Wenn ich die Tabellen-Tags zähle, ergibt es die gleiche Anzahl für Tag-Anfang und -Ende.
Zusätzlich ist noch wichtig, dass in diesem Skript drei HTML-Ausgaben möglich sind, je nach Verarbeitungsergebniss. Alle werden als Quelltext dargestellt. Auch, wenn ich einen Quelltext nehme, der in einem anderen Programm funktioniert, bleibt es dabei. Das brachte mich dazu zu sagen, dass es am Script liegen müsste. Aber nach Zeilenweiser Prüfung habe ich keinen Fehler feststellen können, und die Datenverarbeitung funktioniert ja auch.
Gruss Thomas
Hi Thomas!
Zusätzlich ist noch wichtig, dass in diesem Skript drei HTML-Ausgaben möglich sind, je nach
Verarbeitungsergebniss. Alle werden als Quelltext dargestellt. Auch, wenn ich einen Quelltext
nehme, der in einem anderen Programm funktioniert, bleibt es dabei. Das brachte mich dazu
zu sagen, dass es am Script liegen müsste.
Sieht so aus, als ob es am Script liegt. Speichere den im Netscape angezeigten Code mal als html Datei und öffnen die local mit dem Browser. Wird nun alles richtig angezeigt? Wenn ja, dann ist der code i.o. - es liegt also an der Ausgabe des Scripts. Es sieht so aus, als sei Dein HTTP-Header nicht in Ordnung. Alles was das Script sendet wird bis zu den ersten 2 \n als Header gewertet. Überprüfe doch nochmal, ob vor dem print "Content-type: text/html\n\n"; wirklich keine andere Ausgabe zum Browser gesendet wird. Oder das print "Content-type: text/html\n\n"; fehlt.
Gruß Frank
P.S.
fängt der HTML-Code, den Du im Netscape siehst mit <HTML> an oder steht da content type...., vielleicht mit Leerzeilen davor?
Hallo Frank,
Sieht so aus, als ob es am Script liegt. Speichere den im Netscape angezeigten Code mal als html Datei und öffnen die local mit dem Browser. Wird nun alles richtig angezeigt? Wenn ja, dann ist der code i.o. - es liegt also an der Ausgabe des Scripts. Es sieht so aus, als sei Dein HTTP-Header nicht in Ordnung. Alles was das Script sendet wird bis zu den ersten 2 \n als Header gewertet. Überprüfe doch nochmal, ob vor dem print "Content-type: text/html\n\n"; wirklich keine andere Ausgabe zum Browser gesendet wird. Oder das print "Content-type: text/html\n\n"; fehlt.
Nun habe ich es also noch einmal geprüft. Und auch nochmal genau die Zeilen aus dem laufenden Skript copy&pastet. Zum 20sten mal, aber Du hast schon recht, lieber einmal zuviel als zu wenig! Aber, Nix!
fängt der HTML-Code, den Du im Netscape siehst mit <HTML> an oder steht da content type...., vielleicht mit Leerzeilen davor?
Als erstes wird folgendes ausgegeben:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 FINAL//EN">
<HTML>
...
Die DOCTYPE-Zeile hatte ich auch schon gelöscht! Nix!
Selbst unser Provider kann es uns nicht auf Anhieb erklären. Er konnte nur bestätigen, dass die Konfiguration einwandfrei ist. Leider. Das hätte ich mir fast gewünscht. Dann wäre es nicht mein Fehler, aber so??
So was blödes. Dann wieder ran und weiter suchen. Jeder Rat wird gern gehört!!
Danke
Gruß Thomas
Hi,
Der Netscape weigert sich standhaft die gesendeten HTML-Tags zu verarbeiten.
füttere http://validator.w3.org/ mit Deiner Script-URI.
Dazu bemerkt, dass ich aus schlechten Erfahrungen so gut es geht vermeide Standard-Module zu nutzen.
Kannst Du bitte erläutern, was für schlechte Erfahrungen das sind?
Ich programmiere immer so einfach ich nur kann, damit die Übersicht erhalten bleibt.
Genau deswegen (u.a.) sollte man Module verwenden.
Cheatah
Hallo,
Der Netscape weigert sich standhaft die gesendeten HTML-Tags zu verarbeiten.
füttere http://validator.w3.org/ mit Deiner Script-URI.
Da kommt dann sowas heraus. Ich mag mich irren, aber diese Zeile ist doch richtig, oder?
Line 7, column 17:
<script language="JavaScript" src="../javascript/xxxxxxx.js"></script>
Error: there is no attribute "LANGUAGE"
Dazu bemerkt, dass ich aus schlechten Erfahrungen so gut es geht vermeide Standard-Module zu nutzen.
Kannst Du bitte erläutern, was für schlechte Erfahrungen das sind?
Könnte auch gut an mir liegen, aber bis jetzt habe ich kaum eines so ohne weiteres zum Laufen bekommen. Einige Stunden Dokus lesen sind dabei drauf gegangen, bis ich merkte, dass die möglichen Module nicht das machen, was ich möchte, also selbst schreiben! Dann habe ich mir einfach die das lesen gespart und gleich programmiert.
Hast Du eine einfache Idee? Denn meine Programmierung kann doch eigentlich nicht so falsch sein. Denn es laufen ja 90% und sie sind alle von gleichem Strickmuster!
Danke.
Gruss Thomas
Hi,
Da kommt dann sowas heraus. Ich mag mich irren, aber diese Zeile ist doch richtig, oder?
Line 7, column 17:
<script language="JavaScript" src="../javascript/xxxxxxx.js"></script>Error: there is no attribute "LANGUAGE"
nein, denn in HTML 4.0 gibt es dieses Attribut hier wirklich nicht mehr (in HTML 4.01 wurde es aber IIRC wieder aufgenommen). Statt dessen benötigst Du ein type-Attribut: type="text/javascript".
[Module]
Kannst Du bitte erläutern, was für schlechte Erfahrungen das sind?
Könnte auch gut an mir liegen, aber bis jetzt habe ich kaum eines so ohne weiteres zum Laufen bekommen.
Ich würde wirklich sagen, daß es an Dir liegt ;-) Andererseits sind Module aber schon ein wenig gewöhnungsbedürftig. Wenn man den Einstieg allerdings geschafft hat, hat man so ziemlich das mächtigste Werkzeug der gesamten Perl-Welt zur freien Verfügung.
Einige Stunden Dokus lesen sind dabei drauf gegangen, bis ich merkte, dass die möglichen Module nicht das machen, was ich möchte, also selbst schreiben!
Huh? Das verstehe ich nicht.
Dann habe ich mir einfach die das lesen gespart und gleich programmiert.
Tja, meist verbringt man aber mehr Zeit mit Lesen als mit Programmieren ;-)
Hast Du eine einfache Idee?
Klar: Gewöhn Dich an Module! Sie nehmen Dir einen Großteil der Programmierarbeit ab und beachten Dinge, an die Du im Traum nicht gedacht hättest. Nutze die Fähigkeiten der Experten!
Cheatah
Hi,
- Error-Log = [warn] [client XXX.XXX.XXX.XXX] handler "cgi-wrapper" not found for: XXX.pl
Leider weiss ich nicht ganz genau, was das bedeutet.
Bist Du sicher, daß diese Meldung aufgrund Deines Aufrufs entstanden ist?
Wenn ja, dann sollte mal jemand (Dein Provider) der Sache auf den Grund gehen. (Ein Handler wird m. E. in der angeblich so fehlerfreien Server-Konfiguration definiert - und was passiert, wenn ausgerechnet das Teil, was für die Ausführung Deines CGI-Skripts zuständig ist, nicht vorhanden ist, weiß der Himmel.)
Der Netscape weigert sich standhaft die gesendeten HTML-Tags zu verarbeiten.
Dann scheint er nicht den passenden Content-type empfangen zu haben. Daß M$IE in einem solchen Fall wild rät und Netscape irgendwas Naheliegendes (in Deinem Fall aber nicht Erwünschtes) macht, ist eine häufig beobachtete Reaktionsweise.
Du magst der Meinung sein, diesen korrekt mitgesendet zu haben. Aber wer sagt Dir, daß Deine Ausgabe unbehandelt zum Client kommt, *wenn* der Server einen Wrapper um Dein CGI-Skript herum einsetzt?
Ich tendiere dazu, Dein Skript für unschuldig zu halten. Installiere Dir lokal einen Apache, weise nach, daß es bei Dir funktioniert und die Server-Konfiguration Deines Providers verantwortlich sein muß.
mfG - Michael