error 500: Interner Serverfehler
Karlheinz
- cgi
Hallo zusammen,
ich habe mal meine ersten Gehversuche mit Perl gestartet, ich möchte Formulare über Email senden.
Mailto ist ja mittlerweile eine ungewisse Sache und so möchte ich dies über einen einfachen Formmailer
mal angehen.
Für diesen Versuch wollte ich folgenden Formmailer verwenden:
http://selfaktuell.teamone.de/tippstricks/cgiperl/form-mail/index.htm
Rechte für die Datei selfmail.pl existieren.
Kann mir Jemand einen Tipp geben?
Gruss
Karlheinz
Moin!
Für diesen Versuch wollte ich folgenden Formmailer verwenden:
http://selfaktuell.teamone.de/tippstricks/cgiperl/form-mail/index.htmRechte für die Datei selfmail.pl existieren.
Kann mir Jemand einen Tipp geben?
Im error-Logfile des Webservers steht die Fehlermeldung, welche zur Problembehebung zwingend notwendig ist.
- Sven Rautenberg
Morgen Sven,
Moin!
Im error-Logfile des Webservers steht die Fehlermeldung, welche zur Problembehebung zwingend notwendig ist.
Wenn Du mir nun auch noch sagst, wo diese Error Log. liegt? ich habe mal mein Log-Verzeichnis gecheckt, dort wo z. B. meine traffics liegen... nichts!
Karlheinz
Moin!
Im error-Logfile des Webservers steht die Fehlermeldung, welche zur Problembehebung zwingend notwendig ist.
Wenn Du mir nun auch noch sagst, wo diese Error Log. liegt? ich habe mal mein Log-Verzeichnis gecheckt, dort wo z. B. meine traffics liegen... nichts!
Woher soll ich wissen, wo der Server diese Logdatei hinlegt? Wenn du sie in den Verzeichnissen, die dir zugänglich sind, nicht findest, hast du einen schlechten Provider gewählt und solltest entweder Kontakt mit dem Support aufnehmen oder einen anderen Provider aussichen.
Ach ja: Typischerweise versagen Perl-Skripte auch dann, wenn sie nicht im ASCII-Modus hochgeladen wurden. Das wäre noch einen Versuch wert. Ansonsten: Ohne Error-Log keine Fehlerbehebung.
- Sven Rautenberg
Moin!
Woher soll ich wissen, wo der Server diese Logdatei hinlegt? Wenn du sie in den Verzeichnissen, die dir zugänglich sind, nicht findest, hast du einen schlechten Provider gewählt und solltest entweder Kontakt mit dem Support aufnehmen oder einen anderen Provider aussichen.
Der Provider ist 1und1.
Schon klar, dass Du das nicht wissen kannst, aber manchmal gibt es da eben noch was, wo man solche Logs verfolgen kann, wie gesagt, ich bin hier noch etwas unbedarft.
Ach ja: Typischerweise versagen Perl-Skripte auch dann, wenn sie nicht im ASCII-Modus hochgeladen wurden. Das wäre noch einen Versuch wert. Ansonsten: Ohne Error-Log keine Fehlerbehebung.
Hochgeladen ist in Ascii.
Sieht wohl Sch... aus, hm?
1und1 stellt schon CGI Scr. zur Verfügung, die auch dann funktionieren. Kann man hier zur Lösung meines Problems ansetzten?
Karlheinz
Moin!
Hochgeladen ist in Ascii.
Sieht wohl Sch... aus, hm?
1und1 stellt schon CGI Scr. zur Verfügung, die auch dann funktionieren. Kann man hier zur Lösung meines Problems ansetzten?
1und1 hat irgendwo einen CGI-Debugger auf der Website. Ich hab den noch nicht persönlich benutzt, aber davon gehört. Ist immerhin besser als gar nichts. Ich würde im Support-Bereich mal danach Ausschau halten.
- Sven Rautenberg
Hallo Sven,
1und1 hat irgendwo einen CGI-Debugger auf der Website. Ich hab den noch nicht persönlich benutzt, aber davon gehört. Ist immerhin besser als gar nichts. Ich würde im Support-Bereich mal danach Ausschau halten.
Also den Debugger finde ich nicht.
Aber so wie es scheint fehlt es mir hier an Grundlegendem:
Ich möchte mittels Aufruf aus HTML aus Perl "Hallo" ausgeben, also habe ich eine HTML erstellt, mit:
<html>
<body>
<a href="../cgi-bin/self.pl">mal sehen</a>
</body>
</html>
----------
im user-bin Verz. gibt es dann:
#!/usr/bin/perl -w
use strict;
use CGI::Carp qw(fatalsToBrowser);
print "Content-type: text/html\n\n";
print ("Hallo\n");
-----------
hier bekomme ich in NN die Fehlermeldung:
Error 501
mit: no perl allowed
Ich kriege die Krise.
Karlheinz
Moin!
hier bekomme ich in NN die Fehlermeldung:
Error 501
mit: no perl allowedIch kriege die Krise.
Viel besser wäre es, das error-log zu kriegen. Und da hilft die alte Weisheit: Wenn der Prophet nicht zum Berg kommt, muß der Berg eben zum Propheten kommen. Oder mit anderen Worten ausgedrückt: Es hat wenig Sinn, blind auf dem 1und1-Server herumzustochern - installiere dir lieber einen Webserver lokal auf deinem Rechner und teste dort dein Skript.
Einige nette "Rundum-Sorglos-Pakete"[*] mit allem, was das Herz so braucht, gibts im Internet ja. Und damit kriegst du dann auch dein error-log. :)
[*] Das Problem eines "Alles-Drin"-Pakets ist eigentlich nur, dass man keine Konfiguration durchführen muß, diese aber das wichtigste an der ganzen Serversache ist, und man es eigentlich wirklich selbst tun sollte.
- Sven Rautenberg
Hallo Sven,
[*] Das Problem eines "Alles-Drin"-Pakets ist eigentlich nur, dass man keine Konfiguration durchführen muß, diese aber das wichtigste an der ganzen Serversache ist, und man es eigentlich wirklich selbst tun sollte.
so wie es aussieht, habe ich ein ganz anderes Problem.
Jetzt nicht lachen! Ich habe mir gerade eben meinen Vertrag mal angesehen.... Basic CGI´s hab ich, aber nicht freie CGI´s in meinem Vertrag... so wie ich das verstehe, kann ich eigene CGI´s nicht, ich muss mich erstmal erkundigen, warscheinlich finde ich auch deshalb mein error.log nicht, weil es bei mir keins gibt ;-(
Trotzdem, erstmal, Danke für Deine Hilfe.
Karlheinz
Hi,
so wie es aussieht, habe ich ein ganz anderes Problem.
Jetzt nicht lachen! Ich habe mir gerade eben meinen Vertrag mal angesehen.... Basic CGI´s hab ich, aber nicht freie CGI´s in meinem Vertrag... so wie ich das verstehe, kann ich eigene CGI´s nicht, ich muss mich erstmal erkundigen, warscheinlich finde ich auch deshalb mein error.log nicht, weil es bei mir keins gibt ;-(
Dann hast du tatsächlich keine CGI's. Aber auch wenn du bei 1und1/Puretec ein Paket mit Perl und PHP hast, bekommst du leider keine errorlogs. Das ist einer der großen Nachteile von 1und1. Wobei ich bis jetzt nicht verstehe, warum es keine errorlogs gibt. So groß wird der Aufwand ja doch nicht sein.
Andres Freund
Moin!
Wobei ich bis jetzt nicht verstehe, warum es keine errorlogs gibt. So groß wird der Aufwand ja doch nicht sein.
Es ist absolut Null Mehraufwand. Jeder virtuelle Host hat eine Direktive, die die Access-Logfiles in den vom Besitzer erreichbaren Plattenbereich schreibt. Es würde nur eine einzige weitere Direktive erfordern, auch das Error-Logfile dort reinzuschreiben. Noch eine zweite Logfile-Rotation (oder das Zeugs gleich wegwerfen), und fertig.
Kann natürlich sein, dass die Server soviele gleichzeitig offene Log-Dateien nicht mehr vertragen. Das wäre dann allerdings bedenklich.
- Sven Rautenberg
Es ist absolut Null Mehraufwand.
Eben. Das einzige was sein kann, das das deren tolles Verwaltungsystem nicht mitmacht. Aber soetwas da reizubasteln dürfte auch nicht alzuschwer sein.
Ich mach es inzwischen so, dass ich STDERR in eine Textdatei umleite. Das gibt mir zwar die Fehler die vor dem Parsen enteckt werden nicht aus, aber die kann man selber recht gut bemerken ;-).
Grüße Andres Freund
Hallo Sven,
Kann natürlich sein, dass die Server soviele gleichzeitig offene Log-Dateien nicht mehr vertragen. Das wäre dann allerdings bedenklich.
"Der Server" (Hardware) schon, aber der Apache nicht. Jedes zusätzliche Logfile ist ein zusätzliches Filehandle, und von denen kann er wohl nur sehr begrenzt viele verwalten.
Ein Grund mehr, auf einen kleinen Server mit wenigen Kunden zu gehen ...
Viele Grüße
Michael
(der sein eigenes error_log aus seinem Provider auch "herausfragen" mußte, aber es schließlich bekommen hat)
Hallo Sven, hallo Andres,
nur zur Info, ich habe gestern meinen Vertrag geändert, ich erhielt innerhalb einer Stunde die Freischaltung, und siehe da, nun laufen meine Scripts ohne Probleme.
Schnell sind sie ja.
Aber Error.log gibt es immer noch nicht, Andres hatte schon Recht. Aber es gibt ja trotzdem eine Möglichkeit Fehler im Script darzustellen.
use CGI::Carp qw(fatalsToBrowser);
Richtig so, oder?
Also nochmal, danke
Gruss
Karlheinz
Hi Karlheinz
use CGI::Carp qw(fatalsToBrowser);
Richtig so, oder?
Ja schon richtig, aber das zeigt dir nur die Fehler, die nach dem Parsen des Dokumentes entdeckt werden, etwa wenn du in strict vergisst eine Variable zu deklarieren oder ähnliches. Wenn aber ein grober Fehler das ganze verhindert siehst du den so nicht. Ausserdem werden auf diese Weise die Warnungen nicht ausgegeben. Dies kann man allerdings erreichen, indem man STDERR auf eine Datei setzt.
Grüße Andres Freund