Ankündigung

Einklappen
Keine Ankündigung bisher.

Premature end of script headers: index.php im Zusammenhang mit Performanceverlust

Einklappen

Neue Werbung 2019

Einklappen
X
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • Premature end of script headers: index.php im Zusammenhang mit Performanceverlust

    Hi,

    bekomme bei einem Projekt zur Zeit laufend die Meldung
    Premature end of script headers: index.php
    . Ich selbst habe die Meldung noch nicht zu Gesicht bekommen, bin lediglich über das error logfile darauf gestoßen.

    [...]

    27.10.2010 21:03:58 skyline-panorama.de [client 67.195.113.250] Premature end of script headers: index.php
    27.10.2010 21:04:19 skyline-panorama.de [client 67.195.113.250] Premature end of script headers: index.php
    27.10.2010 21:04:40 skyline-panorama.de [client 67.195.113.250] Premature end of script headers: index.php
    27.10.2010 21:53:45 skyline-panorama.de [client 85.181.194.232] Premature end of script headers: index.php
    27.10.2010 21:55:54 skyline-panorama.de [client 66.249.66.13] Premature end of script headers: index.php
    27.10.2010 22:52:15 skyline-panorama.de [client 207.46.204.202] Premature end of script headers: index.php
    27.10.2010 22:52:59 skyline-panorama.de [client 207.46.204.202] Premature end of script headers: index.php
    28.10.2010 16:51:56 skyline-panorama.de [client 85.181.198.62] (70007)The timeout specified has expired: ap_content_length_filter: apr_bucket_read() failed
    28.10.2010 19:53:16 skyline-panorama.de [client 193.221.58.11] Premature end of script headers: index.php, referer: http://www.skyline-panorama.de/skyline-koeln.htm
    28.10.2010 19:54:35 skyline-panorama.de [client 193.221.58.11] Premature end of script headers: index.php, referer: http://www.skyline-panorama.de/skyline-koeln.htm
    28.10.2010 20:54:02 skyline-panorama.de [client 67.195.113.250] Premature end of script headers: index.php
    28.10.2010 20:55:35 skyline-panorama.de [client 67.195.113.250] Premature end of script headers: index.php
    Recherchen über Google haben mir bei der Problemlösung leider nicht geholfen. Unter anderem Hinweise auf falsch eingestellte Ordner- und Dateirechte und auf einen Zusammenhang beim Setzen von header-Anweisungen konnten das Problem nicht lösen (bin mir auch nicht sicher, was dabei genau den Fehler auslöst).

    Die Ordner- und Dateirechte stehen nun durchgehend auf 0755.
    Das Projekt liegt auf einem strato-Server und der Support erzählt mir (und dem Aftraggeber) leider nur einen vom Pferd: Auszug:
    Zitat von mein auftraggeber
    So wie es aussieht, liegen die Hänger immer noch an dem falsch hinterlegten
    absoluten Pfad in meinem System, die Dame von der Hotline meinte, dass nur
    der Webdesigner wüsste wo er angepasst wird und das er in jedem System an
    einem anderen Ort hinterlegt ist.
    Antwort vom Support (Ausschnitt):
    Zitat von strato-support
    vielen Dank für Ihre Anfrage, die ich Ihnen gerne beantworte.

    Der absolute Pfad zu Ihrem Webhosting-Paket:
    /home/strato/www/ersten zwei_buchstaben/www.wunschname.de/htdocs/

    Beispiel:
    /home/strato/www/wu/www.wunschname.de/htdocs/
    Bitte ersetzen Sie wunschname.de durch eine beliebige Domain innerhalb Ihres
    Webhosting-Paketes.

    Die Bezeichnung /home/strato/www/wu/ kommt nirgendwo vor, weil /wu/ für die
    beiden ersten Zeichen des Domainnamens (im BEISPIEL: wunschname.de) steht.

    Auf den Namen Ihrer Domain angewendet sieht der absolute Pfad demnach so
    aus:

    /home/strato/www/sk/skyline-panorama.de/htdocs

    Haben Sie bitte Verständnis dafür, dass wir keinen gesonderten Support für
    die Installation eines CMS bieten können. Gängige
    Open-Source-Geschäftsmodelle basieren auf Dienstleistungen wie Beratung,
    Implementierung, Integration, Optimierung sowie Wartung und Support.

    Da es am Markt mehr als 20 Content Management-Systeme, [...]
    Im Grund stelle ich mir nur die Frage, von welchem Pfad hier gesprochen wird und ob die Fehlermeldung im Zusammenhang mit langen Ladezeiten stehen kann.

    Hintergrund der Geschichte war nämlich die Beobachtung, dass sporadisch Ladezeiten von um die 60 Sekunden auftreten und vom Support auf diesen falsch eingestellten Pfad hingeweisen wurde (was sie wiederum aus dem error-logfile abgeleitet haben).

    Könntet ihr mich erleuchten?

    [edit]

    PS.

    Da es am Markt mehr als 20 Content Management-Systeme, [...]
    Es wird kein CMS benutzt.
    [URL]http://hallophp.de[/URL]

  • #2
    uebersetzt heisst das fuer mich "fruehzeitiges Ende der Skriptheader" - mit headers meint die Meldung die http-Header? Hast du die mal angeschaut? Ist ins Blaue geraten.
    "[URL="http://www.youtube.com/watch?v=yMAa_t9k2VA&feature=youtu.be&t=25s"]Mein Name ist Lohse, ich kaufe hier ein.[/URL]"

    Kommentar


    • #3
      Ja, das ist wohl mit der Meldung gemeint. Hier: http://httpd.apache.org/docs/1.3/mis...script-headers habe ich auch ein paar nette Hinweise gefunden, bin jedoch etwas ratlos, wie ich etwas testen soll, das bei mir selbst nicht auftritt. Eine Idee?

      Selbst wenn die Ladezeit der Seite bei mir über 60 Sekunden beträgt, bekomme ich keine Meldung angezeigt - sehe zwischen der Meldung und der Ladezeit also keinen Zusammenhang.
      Dies war aber die Aussage des Support auf die Anfrage, warum die Seite beim Aufrufen oft hängt und lange lädt.
      Wenn ich mir die gesendeten header mit dem FF-Plugin Live-HTTP-Headers anschaue, scheinen auch alle header vollständig zu sein - soweit ich das beurteilen kann.

      Kann mir denn jemand sagen, von welchem Pfad gesprochen wird, was ich damit machen soll oder ob das alles Humbug ist?

      [...]

      Der absolute Pfad zu Ihrem Webhosting-Paket:
      /home/strato/www/ersten zwei_buchstaben/www.wunschname.de/htdocs/

      [...]
      [URL]http://hallophp.de[/URL]

      Kommentar


      • #4
        also der Pfad der hier vom Support gemeint ist, ist der Document-Root der domain ..
        in dem Fall eben dieses
        /home/strato/www/sk/skyline-panorama.de/htdocs
        nun wenn die Support-Tante recht hat, dann versuchst du irgendwo Dateien aus einem anderen Pfad zu lesen / anzusprechen, die eben nicht in diesem Document-Root Pfad bzw darunter liegen ...

        Das kannst du wenigstens mal prüfen, Asipak. Evtl. navigierst du auch mit relativen Pfadangaben "zu hoch" und hast dann auf einmal keine Rechte mehr, weil du die "dort oben" gar nicht selbst setzen darfst

        was mir gerade noch einfällt: an dem Minus kann es aber nicht liegen, oder? kommt ja doch recht häufig in URLs vor .....
        "Irren ist männlich", sprach der Igel und stieg von der Drahtbürste [IMG]http://www.php.de/core/images/smilies/icon_lol.gif[/IMG]

        Kommentar


        • #5
          Ich sehe nicht, was das überhaupt mit Pfadangaben innerhalb eines Scriptes zu tun haben soll - wenn du versuchst, irgendwo zuzugreifen, wo du keine Rechte hast bzw. auf einen Pfad, der nicht existiert, dann sollte das doch eine entsprechende „normale“ PHP-Fehlermeldung geben ...
          [SIZE="1"]RGB is totally confusing - I mean, at least #C0FFEE should be brown, right?[/SIZE]

          Kommentar


          • #6
            wenn der Pfad nicht existiert - klar ..

            aber wenn der existiert, muss er Rechte prüfen (ok, die landen wohl im Cache für eine bestimmte Zeit, was erklärt dass nur einige der Anfragen über 60 Sekunden dauern, die anderen kann er dann schneller beantworten) - und wenn ich sehe, wie lange das teilweise dauert im lokalen Netz (ok schlagt mich - ist halt eine Windoof Domäne) dann vermute ich fast, dass ein guter Teil der großen Zeitdauer durch diese Rechtefragen verstreicht

            Das dazu keine PHP-Fehlermeldung kommt, könnte daran liegen, dass dieser Pfad vielleicht nur in einer rewrite-Regel oder in der Config drinsteht und von deiner Webseite gar nicht benutzt wird - aber trotzdem ackert er ja bei jedem request dadrüber ...

            Erklärung auf php-resource :
            Bei mir lags daran, dass ich php-scripte der Gruppe
            "www" und dem user "apacheuser" zuordnen muss.

            Strato Suse 9.0

            Ist der FTP-Account richtig eingestellt geschieht dies automatisch.
            (ähm ...sollte...)
            Da ich mit winSCP übertragen hatte, gehört alles root (mir)

            Ich fands raus im Apache Errorlog:
            Error in suphp.c on line 313: user is not allowed to run scripts
            im nächsten Post kommt noch die Bemerkung, das tatsächlich auch die lange Zeitdauer des Requests damit zu tun haben kann - weil die Meldung mit den premature end of headers auch kommt, wenn php gar nichts liefert (etwa wenn innerhalb der maximalen Ausführungszeit keine Ausgabe zustande kommt) daher hier mal der Link zum Threadstart

            http://www.php-resource.de/forum/fra...tml#post357026
            "Irren ist männlich", sprach der Igel und stieg von der Drahtbürste [IMG]http://www.php.de/core/images/smilies/icon_lol.gif[/IMG]

            Kommentar


            • #7
              Ich sehe nicht, was das überhaupt mit Pfadangaben innerhalb eines Scriptes zu tun haben soll - wenn du versuchst, irgendwo zuzugreifen, wo du keine Rechte hast bzw. auf einen Pfad, der nicht existiert, dann sollte das doch eine entsprechende „normale“ PHP-Fehlermeldung geben ...
              Genau der Meinung bin ich auch, weshalb ich das Problem nicht ganz verstehe.

              Ich werde dann noch mal die Pfadangaben und rewrite-Regeln überprüfen.
              Warum der Support mir allerdings überhaupt Pfad mitteilt, wird mir immer noch nicht klar. Diesen kann ich ja nicht effektiv verwenden, sondern ich nutze die absolute Adresse http://www.example.com/ .

              Danke erstmal an euch.
              [URL]http://hallophp.de[/URL]

              Kommentar


              • #8
                aber du benutzt doch nicht die URL für includes ... möglicherweise ist das von denen aber auch nur ein allgemeiner Textbaustein ....
                "Irren ist männlich", sprach der Igel und stieg von der Drahtbürste [IMG]http://www.php.de/core/images/smilies/icon_lol.gif[/IMG]

                Kommentar


                • #9
                  Nein, nicht für includes, diese Pfade sind relativ definiert.

                  möglicherweise ist das von denen aber auch nur ein allgemeiner Textbaustein ....
                  Der wofür gedacht sein könnte?

                  Selbst für includes kann ich den genannten Pfad nicht verwenden. Über die Servervariablen bekommt man einen weiteren Pfad heraus, der für includes eingesetzt werden kann. Doch die Dateien werden auch erfolgreich ohne diesen Pfad eingebunden und warum sollte ich daran etwas ändern - zumal die Fehlermeldung dadurch auch nicht aus den Logfiles verschwindet?
                  [URL]http://hallophp.de[/URL]

                  Kommentar


                  • #10
                    "Premature end of script headers" ist ein Fehler, der bei Perl-Scripten m.W. viel häufiger Auftritt.
                    Im Groben besagt der m.E., dass das Script bzw. der Script-Interpreter gar nicht so weit gekommen ist, sich ordentlich beim aufrufenden Prozess (Webserver) zurück zu melden.
                    Das kann aber eigentlich bei "normalen" Programmierfehlern im PHP-Script gar nicht auftreten - die erzeugen entsprechende Meldungen, ggf. auch einen Scriptabbruch.
                    Wenn aber der PHP-Prozess gar nicht dazu kommt, sich ordentlich beim Webserver zurück zu melden nach Erledigung seiner Aufgabe, dann sitzt das Problem eher auf Installations-Ebene, als im Script selber.
                    [SIZE="1"]RGB is totally confusing - I mean, at least #C0FFEE should be brown, right?[/SIZE]

                    Kommentar


                    • #11
                      Danke, ChrisB, genau so habe ich mir das auch versucht zu erklären und bin vorläufig zu dem Schluss gekommen, dass der Fehler beim Server liegt und der Support eigentlich Blödsinn erzählt.

                      Ich werde mich mal mit meinem Auftraggeber beraten und vielleicht noch mal den Support anschreiben.

                      Gruß und danke erstmal.
                      [URL]http://hallophp.de[/URL]

                      Kommentar


                      • #12
                        Hallo zusammen,

                        Ich stand vor genau dem selben Problem, ebenfalls Stratoserver.

                        Ich hab ein neues Joomla installiert und eingerichtet und wie beim Threadersteller zeitweise ewig lange Ladezeiten die ab und an in einem Server 500 Error endeten.

                        Bei mir war der tatsächliche Error nicht aussagekräftig, da er mich nur, wie beim Threadersteller auf die Index Datei verwiesen hat. Bei den Warnings im Errorlog tauchten dann allerdings 2 Scripte mit Pfad zu meinem Template auf die dafür verantwortlich waren. Irgendwelche Server externe Abfragen.
                        Nach löschen der beiden Scripte läuft die Seite einwandfrei.

                        Ich denke das einige Sachen zu diesem Fehler führen können, aber vielleicht hilft ja meine Lösung auch jemand anderem.

                        LG Sesca

                        Kommentar

                        Lädt...
                        X