gLan: Seite lädt nicht im IE

Hallo,

Hier der Link zu einer Seite, die ich gemacht habe.
Leider haben einige Leute gesagt, dass die Seite im Internet Explorer gar nicht oder nur sehr langsam geladen wird. In den Tests hat aber noch alles funktioniert:
Als ich es heute aber probiert habe, hat es bei mir auch nicht funktioniert. Selbst browsershots.org liefert bei einigen Browsern ein weißes Fenster.

Hat jemand eine Idee woran das liegen kann? Im Opera und Firefox funktioniert alles perfekt.

Danke schon mal im Voraus

MfG

--
How long? Not long! 'Cause what you reap, is what you sow!!!
SELF forever
Neuer Selfcode encoder?
  1. Hat jemand eine Idee woran das liegen kann? Im Opera und Firefox funktioniert alles perfekt.

    Tut es nicht.
    Endlos-Schleife bei Umleitungen.

    mfg Beat

    --
    ><o(((°>           ><o(((°>
       <°)))o><                     ><o(((°>o
    Der Valigator leibt diese Fische
    1. Hallo,

      Endlos-Schleife bei Umleitungen.

      Aber es wird gar nichts umgeleitet.
      Hmmm, warum funktioniert es bei mir seit die Seite online ist? Es funktioniert auch jetzt noch bei mir.
      FireFox 3 Beta 2: Funktioniert.
      Opera 9.64: Funktioniert.
      IE 8: Hat gerade mal funktioniert, jetzt funktioniert es wieder nicht. Ich habe den Verdacht, dass es an dem Frameset liegt. Denn Wenn ich die Seite öffne, die in dem Frameset eingefügt wird, klappt alles perfekt.

      Ich denke ich versuche das ganze mit einem Redirect zu lösen.

      MfG

      --
      How long? Not long! 'Cause what you reap, is what you sow!!!
      SELF forever
      Neuer Selfcode encoder?
  2. Hi,

    Hier der Link zu einer Seite, die ich gemacht habe.
    Leider haben einige Leute gesagt, dass die Seite im Internet Explorer gar nicht oder nur sehr langsam geladen wird. In den Tests hat aber noch alles funktioniert:
    Als ich es heute aber probiert habe, hat es bei mir auch nicht funktioniert. Selbst browsershots.org liefert bei einigen Browsern ein weißes Fenster.

    Hat jemand eine Idee woran das liegen kann?

    Daran, dass hier "Geiz ist Geil"-Mentalität und schlechte Programmierung in ungünstiger Konstellation aufeinander treffen :-)

    Die genannte Adresse http://www.ec-lauter.de/ dient lediglich dazu, der eigentlichen Adresse http://www.cus-lauter.de/ec/index.php ein Frameset überzustülpen - das ist der "Geiz"-Part: Nicht zufrieden mit der Domain, unter der die Inhalte liegen, aber (vermutlich) zu geizig, eine "richtige" Domain zu reservieren, die man auf den Webspace aufschalten kann, stattdessen die "Frame-Weiterleitung".

    Wie ein Aufruf mit dem Web-Sniffer zeigt, leitet http://www.cus-lauter.de/ec/index.php auf sich selber weiter (und auch das nicht mal HTTP-Konform mit "Location: index.php", wo eigentlich ein vollständiger URL inkl. Protokoll angegeben werden müsste), nachdem es einen Cookie zu setzen versucht hat.
    Ich nehme an, dass hier eine Session gestartet werden soll, und beim nächsten Aufruf des Scripts *mit* migeschicktem Cookie kein Redirect auf die gleiche Adresse mehr stattfinden wird(?). Das ist aber natürlich an sich schon mal eine Dummheit, weil damit für Clients, die keine Cookies akzeptieren, eine Endlosschleife produziert wird. Deine Beobachtung, dass es im Opera und FireFox "funktioniert" basiert also nur darauf, dass diese den Cookie ohne zu murren akzeptiert haben.

    Aber mein IE akzeptiert doch auch Cookies, höre ich dich sagen?
    Ja - aber in der Default-Datenschutzeinstellung keine sog. Third Party Cookies. Und ein solches liegt hier vor - eben wegen dem der Seite übergestülpten Frameset.
    Das "Hauptdokument", das Frameset, wurde von www.ec-lauter.de abgerufen.
    Das Script, welches den Cookie setzen möchte, stammt aber von www.cus-lauter.de - damit ist es eine "dritte Partei", und darf unter der vorliegenden Datenschutzeinstellung keine Cookies setzen.
    Diesem Umstand könnte man mit einer P3P-Datenschutzerklärung zwar Abhilfe schaffen - das würde das grundlegende Problem, dass das Script bei Nicht-Akzeptanz von Cookies durch den Client Amok läuft, aber noch nicht beheben.

    MfG ChrisB

    --
    Light travels faster than sound - that's why most people appear bright until you hear them speak.
    1. Hallo,

      vorab erstmal danke für deine schnelle und SEHR ausführliche Antwort.

      Daran, dass hier "Geiz ist Geil"-Mentalität und schlechte Programmierung in ungünstiger Konstellation aufeinander treffen :-)

      Ersteres, die Geiz-ist-Geil-Mentalität, stammt allerdings nicht von, sondern vom Kunden, jedoch muss ich das auch auf mich laden, weil ich nichts dagegen gesagt habe :-) ...
      Gegen das Zweite, die schlechte Programmierung, möcht ich mich wehren :D
      Das entstammt eher dem Unwissen über den Sachverhalt, den du mir dann auch erklärt hast.
      Wie du jetzt bemekren wirst, habe ich die "Geiz-ist-Geil-Mentalität" überbrückt, indem ich eine Weiterleitung eingebaut habe. Somt funktioniert die Seite auch wieder überall.

      auf sich selber weiter (und auch das nicht mal HTTP-Konform mit "Location: index.php", wo eigentlich ein vollständiger URL inkl. Protokoll angegeben werden müsste), nachdem es einen Cookie zu setzen versucht hat.

      Das ist das Rätsel was deine Antwort bei mir auslöst: es findet DEFINITIV kein Redirect statt (mit header() etc.)... Andererseits klingt deine Erklärung sehr plausibel. Doch ich habe alle in Frage kommende Dateien nach redirect-Funktionen/Anweisungen durchsucht...
      Hast du sonst eine Ahnung woran es hätte liegen können?
      Der Fehler tritt nun zwar nicht mehr auf, aber ich denke es wäre sicherlich gut zu erfahren woran es lag.

      Diesem Umstand könnte man mit einer P3P-Datenschutzerklärung zwar Abhilfe schaffen - das würde das grundlegende Problem, dass das Script bei Nicht-Akzeptanz von Cookies durch den Client Amok läuft, aber noch nicht beheben.

      Danke für die Info, das habe ich noch nicht gewusst... :D

      gLan

      1. Hi,

        Gegen das Zweite, die schlechte Programmierung, möcht ich mich wehren :D
        Das entstammt eher dem Unwissen über den Sachverhalt, den du mir dann auch erklärt hast.

        Ein Script, dass sich auf die Akzeptanz von Cookies durch den Client *verlässt*, und andernfalls Amok läuft - das *ist* schlecht geschrieben (sofern es nicht ausschliesslich in einer kontrollierbaren Umgebung eingesetzt werden soll).

        Wie du jetzt bemekren wirst, habe ich die "Geiz-ist-Geil-Mentalität" überbrückt, indem ich eine Weiterleitung eingebaut habe. Somt funktioniert die Seite auch wieder überall.

        Nein, tut sie nicht.
        Wenn der Client keine Cookies akzeptiert, landet das ganze nach wie vor in der Redirect-Endlosschleife.

        auf sich selber weiter (und auch das nicht mal HTTP-Konform mit "Location: index.php", wo eigentlich ein vollständiger URL inkl. Protokoll angegeben werden müsste), nachdem es einen Cookie zu setzen versucht hat.
        Das ist das Rätsel was deine Antwort bei mir auslöst: es findet DEFINITIV kein Redirect statt (mit header() etc.)...

        Die Ausgabe des Aufrufs mit dem Web-Sniffer zeigt, *dass* er stattfindet:
        HTTP Status Code: HTTP/1.1 302 Moved Temporarily
        Location: index.php

        Doch ich habe alle in Frage kommende Dateien nach redirect-Funktionen/Anweisungen durchsucht...
        Hast du sonst eine Ahnung woran es hätte liegen können?

        Nein.
        Umleiten machen weder Server noch PHP "einfach so".
        Dass das Script dies selber auslöst, ist die wahrscheinlichste Variante.

        MfG ChrisB

        --
        Light travels faster than sound - that's why most people appear bright until you hear them speak.
        1. Hallo,

          Die Ausgabe des Aufrufs mit dem Web-Sniffer zeigt, *dass* er stattfindet:
          HTTP Status Code: HTTP/1.1 302 Moved Temporarily
          Location: index.php

          Nein.
          Umleiten machen weder Server noch PHP "einfach so".
          Dass das Script dies selber auslöst, ist die wahrscheinlichste Variante.

          Das ist mir schon klar.
          Aber findest du in diesem Script ein Redirect (das Script wird geincludet, direkt danach findet die erste ausgabe statt):
          kfg.php:

            
          <?php  
            
          session_start();  
            
          // Einbinden der Klassen:  
          require_once 'k_verbindung.php';  
          require_once 'k_abfrage.php';  
          require_once 'k_bild.php';  
            
          // Konstanten:  
          // Es werden einige Konstanten definiert [habe ich an dieser Stelle rausgenommen]  
            
          // Verbindung zum MySQL-Server  
          // [...]  
            
          ?>  
          
          

          index.php:

            
          <?php  
          include "kfg.php";  
          ?>  
          <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"  
                  "http://www.w3.org/TR/html4/loose.dtd">  
          <html>  
          
          

          Danach kann ja kein Redirect mittels header gestartet werden, da ja jetzt schon was ausgegeben wurde.

          In den 3 Dateien mit den Klassen ist ebenfalls kein Redirect vorhanden,

          aber mir fällt gerade beim Schreiben so ein:
          Kann es sein dass das Redirect gemeint ist, was ich auf der Seite http://www.ec-lauter.de (wo nach http://www.cus-lauter.de/ec/index.php weitergeleitet wird) aufrufe?

          Anders kann ich mir das nicht erklären.

          gLan

          1. Hi,

            Danach kann ja kein Redirect mittels header gestartet werden, da ja jetzt schon was ausgegeben wurde.

            Das kommt drauf an, ob output_buffering aktiviert ist.

            aber mir fällt gerade beim Schreiben so ein:
            Kann es sein dass das Redirect gemeint ist, was ich auf der Seite http://www.ec-lauter.de (wo nach http://www.cus-lauter.de/ec/index.php weitergeleitet wird) aufrufe?

            Nein. Die Ausgabe des Web-Sniffers zeigt direkt die Rückgabe des Aufrufes von http://www.cus-lauter.de/ec/index.php, die andere Domain war dabei gar nicht im Spiel.

            MfG ChrisB

            --
            Light travels faster than sound - that's why most people appear bright until you hear them speak.