nicht angemeldet
Premature end of script headers..
Hallo,
ich nutze den Apache-Webserver 1.3.22 mit PHP 4.0.6 auf einem Windows-2000-Pro-Rechner. Soweit ist alles "richtig" konfiguriert, und ich habe mehrere VirtualHosts eingerichtet, die auch alle meinen Wünschen gemäß funktionieren. Nun sollen jedoch PHP-scripte aus einem Verzeichnis "e:/xyz/www/skripte/" heraus laufen - dieses kommentiert mir Apache mit einem "Premature end of script headers". Meine Frage lautet nun : Ich habe die httpd.conf des Apache nur meinen Örtlichkeiten angepasst ("DocumentRoot", "Servername" etc.), und diese Angaben in den VirtualHosts-Containern entsprechend der Speicher-Verzeichnisse für die http-Dokumente geändert. Muß ich nun noch irgendwelche "Rechte" bei den VirtualHosts-Definitionen in die httpd.conf eintragen wie etwa "ExecCGI"? Habe ich schon einmal probiert, doch anscheinend fehlt mir der Überblick über das gesamte. Denn: Wird das gleiche Script aus dem Stamm-httpd-Verzeichnis des Webservers heraus gestartet, dann funktioniert es. Vielen Dank für mögliche Antworten im Voraus.
-
Hi
Ich selbst kenne diese Fehlermeldung aus Perl,
und die kommt immer wenn ich den Content-type vergesse.Wenn ich dann in mein Perl(!)-Script
eine zeile reinmache a la "Content-type: text/html\n\n";
ist alles Paletti mit vielen Confetti.Greeeetzzzzzz
Aquariophile-
Hi
Ich selbst kenne diese Fehlermeldung aus Perl,
und die kommt immer wenn ich den Content-type vergesse.Wenn ich dann in mein Perl(!)-Script
eine zeile reinmache a la "Content-type: text/html\n\n";
ist alles Paletti mit vielen Confetti.Greeeetzzzzzz
AquariophileDanke für die rasche Antwort, aber am content-type kann es nicht liegen, da aus dem Speicherverzeichnis des VirutalHost heraus noch nicht einmal das Script phpinfo(); heraus läuft... geschweige denn, daß ich auch nur im entferntesten daran denken kann, eine Content-Type "text-hmtl" zu generieren. Wie gesagt: Aus dem Stannverzeichnis (bei mir in Apache-httpd.conf-Notation : "c:/apache/htdocs") heraus funktioniert jedes Script, nur nicht aus einem durch einen virtuellen Host eingerichteten Speicherverzeichnis für die Dokumente heraus nicht (hier: "e:/aixpage/www"). Das hat (global gesehen) irgendetwas mit dem .htaccess zu tun, den ich in der httpd.conf im Virtaul-Host-Container definiert habe - nur was es ist, bleibt mir nach langer Testerei noch immer verborgen.
-
hi,
Aus dem Stannverzeichnis (bei mir in Apache-httpd.conf-Notation : "c:/apache/htdocs") heraus funktioniert jedes Script, nur nicht aus einem durch einen virtuellen Host eingerichteten Speicherverzeichnis für die Dokumente heraus nicht (hier: "e:/aixpage/www").
Klingt etwas seltsam. Bei PERL kann sowas passieren, weil PERL auf ein cgi-bin-Verzeichnis angewiesen ist und darauf, daß die Option ExecCGI für das entsprechende Scriptverzeichnis vergeben wurde. PHP verlangt sowas nicht.
Das hat (global gesehen) irgendetwas mit dem .htaccess zu tun, den ich in der httpd.conf im Virtaul-Host-Container definiert habe
möglich. Dann müßtest du uns aber diese Definition noch mitteilen. Wenn du die Optionen zu restriktiv eingestellt hast, kann sowas vielleicht passieren, ist mir allerdings noch nichtr vorgekommen.
Grüße aus Berlin
Christoph S.-
Das hat (global gesehen) irgendetwas mit dem .htaccess zu tun, den ich in der httpd.conf im Virtaul-Host-Container definiert habe
möglich. Dann müßtest du uns aber diese Definition noch mitteilen. Wenn du die Optionen zu restriktiv eingestellt hast, kann sowas vielleicht passieren, ist mir allerdings noch nichtr vorgekommen.
Grüße aus Berlin
Christoph S.Ich denke, wir kommen der Sache irgendwie näher; danke auf jeden Fall für die rasche Antwort. Die httpd.conf enthält bei mir folgende Restriktionen für das Dokument-Stammverzeichnis:
...
<Directory />
Options FollowSymLinks
AllowOverride None
</Directory>
...
<Directory "C:/Apache/htdocs">
Options Indexes FollowSymLinks MultiViews
AllowOverride None Order allow,deny
Allow from all
</Directory>
...Der entsprechende VirtuellHostContainer sieht nun folgende Restriktionen vor:
...
<Directory "E:/kuenstler-management/www/">
AllowOverride All
Options All
Order allow,deny
Allow from all
</Directory>
...Muß ich etwa den durch den ScriptAlias definierten Bereich "c:/php/" auch mit einem Restriktions-Satz besonders notieren? (Gedanke 1)
Oder stimmt irgendetwas nicht mit dem Virtual-Host-Restriktionssatz?
Danke schon einmal für die rasche Antwort!
-
Hallo Christoph,
Du postest in den letzten Wochen pausenlos unwahre Behauptungen über die
Apache-Konfiguration.
Das ist m. E. der Lösung von Problemen nicht wirklich förderlich.Bei PERL kann sowas passieren, weil PERL auf ein cgi-bin-Verzeichnis
angewiesen ist und darauf, daß die Option ExecCGI für das entsprechende
Scriptverzeichnis vergeben wurde.Das ist Unfug.
Perl ist nicht auf ein cgi-bin-Verzeichnis "angewiesen".
Perl ist insbesondere völlig ohne Webserver verwendbar.Relativieren wir Deine Behauptung also zu "die Ausführung von Perl-Skripten
via CGI ist ... angewiesen."
Dadurch wird sie aber nicht im Geringsten wahrer. (Insbesondere sind das
cgi-bin-Verzeichnis und die Option "ExecCGI" eben gerade zwei unterschied-
liche Mechanismen, die ganz bestimmt nicht beide erforderlich sind, sondern
einer von beiden - je nach erwünschtem Einsatz-Modell.)Lies doch einfach mal die existierenden Feature-Artikel, im aktuellen Fall
http://aktuell.de.selfhtml.org/artikel/cgiperl/inbetriebnahme/#a6
wenn Du verstehen willst, wie ein Webserver erkennt, ob er eine Datei als
CGI-Skript interpretieren soll.Viele Grüße
Michael
-
-
-
-
guten Abend,
für die von dir angeführte Meldung kann es mehrere Gründe geben. Die Meldung selber sagt nichts anderes aus, als daß Apache deinem Script - in dem Fall also eine PHP-Datei - keinen Interpreter zuordnen kann, dem die Scriptausführung übergeben werden soll. Sie kann aber auch zustandekommen, wenn deine PHP-Installation nicht korrekt ist, also müßte nicht nur die httpd.conf, sondern auch die php.ini überprüft werden.
Möglicherweise hilfts dir, weiter, mal in http://aktuell.de.selfhtml.org/artikel/server/apacheconf/index.htm reinzuschauen.Grüße aus Berlin
Christoph S.-
guten Abend,
für die von dir angeführte Meldung kann es mehrere Gründe geben. Die Meldung selber sagt nichts anderes aus, als daß Apache deinem Script - in dem Fall also eine PHP-Datei - keinen Interpreter zuordnen kann, dem die Scriptausführung übergeben werden soll. Sie kann aber auch zustandekommen, wenn deine PHP-Installation nicht korrekt ist, also müßte nicht nur die httpd.conf, sondern auch die php.ini überprüft werden.
Möglicherweise hilfts dir, weiter, mal in http://aktuell.de.selfhtml.org/artikel/server/apacheconf/index.htm reinzuschauen.Grüße aus Berlin
Christoph S.Danke für Deinen Vorschlag, doch er bringt mich auch nicht weiter. P. S.: Durch dieses Dokument hab' ich erst einmal mit der httpd.conf umgehen gelernt :)
-
Hallo
für die von dir angeführte Meldung kann es mehrere Gründe geben. Die Meldung selber sagt nichts anderes aus, als daß Apache deinem Script - in dem Fall also eine PHP-Datei - keinen Interpreter zuordnen kann, dem die Scriptausführung übergeben werden soll.
Falsch. Sie sagt aus, dass das Script keinen (vollständigen) Header ausgibt.
Das passiert vermutlich auch, wenn es den Interpreter nicht gibt.Grüße
Daniel
-
Hi Daniel,
Falsch. Sie sagt aus, dass das Script keinen (vollständigen) Header
ausgibt.
Das passiert vermutlich auch, wenn es den Interpreter nicht gibt.wenn der Webserver eine CGI-Anwendung startet, dann muß er dafür ja ein
Programm ausführen (nämlich dasjenige, das er als Interpreter ausgedeutet
hat).
Als Ergebnis dieses Ausführungsversuchs bekommt der Server mindestens die
beiden folgenden Informationen zurück:
a) einen Returncode des Ausführungsversuchs
b) seine nach stdout gesendeten Ausgaben, welche letztlich an den Client
zurück gesendet werden sollen.
Letzteres erfordert allerdings, daß der Webserver zuerst einen passenden
HTTP-Header davor bastelt (mit Änderungsdatum, Längenangabe etc.).
Bevor er das tut, kann er allerdings bereits den Returncode der versuchten
Ausführung des Skripts abfangen - und wenn dieser ungleich 0 ist (dies um-
faßt auch den Fall "Interpreter-Datei nicht gefunden", ebenso wie "x-Bit
nicht gesetzt" oder einige andere Fälle), dann wird der Ausführungsversuch
als gescheitert betrachtet, die stdout-Ausgabe verworfen und statt dessen
die entsprechende Fehlerbehandlung für "Internal Server Error" durchgeführt.Insofern ergibt eine Referenz auf einen fehlenden Interpreter eher einen
"Error 500" als einen unvollständigen HTTP-Header.Viele Grüße
Michael-
Moin
Insofern ergibt eine Referenz auf einen fehlenden Interpreter eher einen
"Error 500" als einen unvollständigen HTTP-Header.Interessant. Und welchen HTTP-Status hat dann letzteres?
--
Henryk Plötz
Grüße aus Berlin-
Hi Henryk,
Insofern ergibt eine Referenz auf einen fehlenden Interpreter
eher einen "Error 500" als einen unvollständigen HTTP-Header.
Interessant. Und welchen HTTP-Status hat dann letzteres?ups - Du hast natürlich völlig recht.
Nur im Apache-error_log kann man beide Fälle unterscheiden:
Das ist der fehlende Interpreter ...
[Wed Jan 23 02:06:22 2002] [error] (2)No such file or directory: exec of /export/home/ms/public_html/x.pl failed
[Wed Jan 23 02:06:22 2002] [error] [client 153.46.90.209] Premature end of script headers: /export/home/ms/public_html/x.pl... und das der vom Skript selbst ausgegebene kaputte HTTP-Header
[Wed Jan 23 02:07:12 2002] [error] [client 153.46.90.209] malformed header from script. Bad header=DOCUMENT_ROOT=/usr/local/apach: /export/home/ms/public_html/y.plim Browser sieht beides gleich aus:
Internal Server Error
The server encountered an internal error or misconfiguration and was unable
to complete your request.Please contact the server administrator, ... and inform them of the time
the error occurred, and anything you might have done that may have caused
the error.More information about this error may be available in the server error log.
Apache/1.3.22 Server at tkschwarz Port 80
Sorry, verhaspelt ... :-\ Michael
-
-
-
-
-
Hi,
hast du ein AddHandler gesetzt?
Ciao,
Wolfgang-
Hi,
hast du ein AddHandler gesetzt?
Ciao,
WolfgangJa, probehalber gerade einmal... das gleiche Problem wie vorher auch. Ich nutze die CGI-Version von PHP; jedoch habe ich durch Unmengen von Nachlesen auf Unmengen von Internet-Seiten eine solche Notation für .php noch nicht gesehen. ich habe die AddType-Lösung, die bei jedem mit gleicher Rechner-Konfig funktioniert... Danke trotzdem für den Vorschlag.
-
-
Hallo,
nochmal eine kleine Zusammenfassung :
Offensichtlich liegt mein Problem darin, daß durch ein PHP-Script ausserhalb des Stammverzeichnisses für http-dokumente der PHP-Interpreter nicht angesprochen wird.
Wie spreche ich ausser mit "action application..." oder "addtype" einen Interpreter aus einem durch VirtualHost funktnierenden Verzeichnis an, daß nicht unterhalb des Verzeicnisses des Webservers liegt? (Die komplette Syntax würde mir weiterhelfen).
Oder : Wie muß der .htacces-Restriktionssatz heißen, damit das Verzeichnis (hier: "E:/aixpage/www") für PHP genutzt werden kann?
Danke im Voraus...
-
Hi,
ich nutze den Apache-Webserver 1.3.22 mit PHP 4.0.6 auf einem
Windows-2000-Pro-Rechner.
Soweit ist alles "richtig" konfiguriert, und ich habe mehrere
VirtualHosts eingerichtet, die auch alle meinen Wünschen gemäß
funktionieren.
Nun sollen jedoch PHP-scripte aus einem Verzeichnis
"e:/xyz/www/skripte/" heraus laufen - dieses kommentiert mir
Apache mit einem "Premature end of script headers".Diese Aussage halte ich für nicht korrekt.
Beide Teil-Aussagen mögen wahr sein, aber ein unmittelbarer Zusammenhang
ist meiner Meinung nach nicht gegeben.
a) Ja, Du magst PHP so konfiguriert haben.
b) Ja, der Apache produziert diese Meldung bei der Ausführung Deines
Skripte.Versuchen wir doch erst mal, diese Meldung zu verstehen.
"Premature end of script headers" bedeutet "vorzeitiges Ende der Header,
welche von diesem Skript erzeugt wurden".
Gemeint sind in diesem Falle die HTTP-Header, welche das an den Browser
gesendete Paket einleiten und dessen Inhalt beschreiben.
Und das bedeutet für mich, daß Deine Apache-Konfiguration mit hoher
Wahrscheinlichkeit nicht die Fehlerursache darstellt. (Es gibt immer
noch Möglichkeiten in dieser Richtung, welche aber von der Art Deines
PHP-Skripts abhängen.)
Wäre beispielsweise nur der Inhalt der Skript-Datei aufgrund einer
Fehl-Konfiguration als Klartext an den Browser geschickt worden, dann
hätte der Apache automatisch einen korrekten HTTP-Header davor gesetzt.
Daraus schließe ich immerhin, daß Dein PHP-Skript _ausgeführt_ wurde.Daß dies nicht geschehen ist, läßt mich als sicher annehmen, daß der
erzeugte HTTP-Header nicht vom Apache-Kern stammt, sondern von etwas,
das Du diesem hinzugefügt hast.
Dafür gibt es m. E. zwei wahrscheinliche Kandidaten:
a) Dein PHP-Skript selbst (das könnte einen Programmierfehler enthalten
und eine Fehlermeldung ausgeben, welche natürlich nicht die Syntax
eines korrekten HTTP-Headers erfüllt). Ein guter Kandidat für so
etwas könnte beispielsweise ein Pfadname sein, der auf Deinem Server
nicht paßt.
b) Dein PHP-Modul (das könnte fehlerhaft installiert sein, irgendwelche
Ressourcen nicht finden, ebenfalls eine Fehlermeldung ausgeben, siehe
oben).Problem a) könntest Du dadurch zu bekämpfen versuchen, daß Du in Deinem
PHP-Skript als allererstes - vor jeglichen anderen Operationen - einen
korrekten HTTP-Header ausgibst (z. B. "Content-type: text/html\n\n").
Was immer anschließend eventuell als Fehlermeldung ausgegeben wird,
würdest Du im Browser lesen können.Problem b) zu lokalisieren ist ohne direkten Zugriff auf den Server
schwieriger. In diesem Fall - wie in fast allen Fällen - ist der Inhalt
des Apache-error_log ungeheuer hilfreich. Ohne diesen ist die Fehlersuche
bei Server-Programmierung erstens Kristallkugelanwendung und zweitens
unnötige Selbstverdummung: Das error_log ist genau dafür da, um Dir im
Falle eines Fehlers zu sagen, was passiert ist!
Also mußt Du zuallererst dort hinein schauen, wenn irgendwas nicht tut.Meine Frage lautet nun : Ich habe die httpd.conf des Apache nur
meinen Örtlichkeiten angepasst ("DocumentRoot", "Servername" etc.),
und diese Angaben in den VirtualHosts-Containern entsprechend der
Speicher-Verzeichnisse für die http-Dokumente geändert.
Muß ich nun noch irgendwelche "Rechte" bei den VirtualHosts-
Definitionen in die httpd.conf eintragen wie etwa "ExecCGI"?Das kommt darauf an, wie Du PHP eingebunden hast. Dafür gibt es m. E.
mehrere Möglichkeiten - sowohl eine, die den PHP-Interpreter über die
CGI-Schnittstelle einbindet (Stefan Münz hat erst letzte Woche hier
gepostet, dies sei das Einsatzmodell, das auf dem Rechner des Self-
Portals genutzt wird), als auch eine andere, die PHP als Modul des
Apache einbindet (was ggf. performanter, aber deutlich RAM-intensiver
ist).
Ein Kommentar zu Deiner Apache-Konfiguration würde genauere Angaben
von Deiner Seite erfordern. Ich bin selbst kein PHP-Benutzer - ich
kann Dir lediglich sagen, wie der Apache funktioniert, und an dessen
Funktionsprinzipien muß sich auch PHP auf die eine oder andere Weise
halten.Habe ich schon einmal probiert, doch anscheinend fehlt mir der
Überblick über das gesamte.Ich halte die PHP-Einbindung nicht für völlig trivial (um sie wirklich
zu verstehen und nicht nur irgendwas einzuschalten, sind durchaus ein
paar detaillierte Kenntnisse über den Apache erforderlich) - also:
Kopf hoch, das geht nicht sofort völlig ohne Lernen. Aber es geht.Denn: Wird das gleiche Script aus dem Stamm-httpd-Verzeichnis des
Webservers heraus gestartet, dann funktioniert es.Das ist immerhin eine interessante Information - aber sie reicht mir
nicht, um daraus zu schließen, ob das Problem im PHP-Skript oder in
der Apache-Konfiguration liegt. Falls Du beispielsweise irgendwelche
Dateien über relative Pfade zu adressieren versuchen solltest, würde
der Installatios-Ort Deines Skripts genau den Unterschied ausmachen.Wir suchen letzten Endes einen Fehler in Deinem Skripts - davon gehe
ich aus, weil der Apache das Skript auf jeden Fall schon mal ausführt
(und zwar in jedem der beiden genannten Verzeichnisse, nur eben mit
unterschiedlichem "Erfolg").Vorgeschlagene Maßnahmen:
1. error_log lesen und Meldung hier posten
2. Dein Skript lesen und überlegen, ob Du von irgendwelchen externen
Ressourcen abhängig bist, die nur unter bestimmten Bedingungen
verfügbar sind.Viele Grüße
Michael-
Moin
Problem a) könntest Du dadurch zu bekämpfen versuchen, daß Du in Deinem
PHP-Skript als allererstes - vor jeglichen anderen Operationen - einen
korrekten HTTP-Header ausgibst (z. B. "Content-type: text/html\n\n").
Was immer anschließend eventuell als Fehlermeldung ausgegeben wird,
würdest Du im Browser lesen können.Leider (glücklicherweise?) ist PHP nicht Perl. Afaik gibt der PHP-Interpreter sowohl im CGI- als auch im Apache-Modus immer und komme was wolle einen guten HTTP-Header aus um eben dieses Problem zu vermeiden, es sei denn du hast PHP in der CGI-Version mit dem Kommandozeilenparameter -q gestartet.
Dieser Weg führt also in eine Sackgasse. Bleibt noch zu prüfen ob der Interpreter überhaupt angesprungen ist oder sonstige Schwierigkeiten hat.
--
Henryk Plötz
Grüße aus Berlin
-