Dark Guardian

Servus

Einer unserer Kunden hat ein Problem mit seiner Internetseite und wir finden den Fehler nicht.

Randinformationen: Die Seite wird auf einem 1&1 managed Server gehostet auf den ich außer FTP keinen Zugriff habe (kann also keinerlei Konfiguration einsehen, ändern oder Logs lesen).

Daher muss ich meine Frage hier leider sehr allgemein stellen was als mögliche Ursache in Frage kommt.

Nun kommt es ab und an vor das unser Kunde beim surfen auf seiner Webseite mit dem Internet Explorer, von 1&1 wegen angeblichen DoS Attacken gesperrt wird.

Mit Firefox, Chrome o.Ä. passiert dies nicht.

Folgendes Phänomen konnte ich beobachten und beheben, das Problem besteht aber weiterhin:

In der Haupt CSS Datei der Webseite war ein Verweis auf einen, nur für den IE bestimmten, PNG Fix. Die Datei existierte auf dem Server aber nicht mehr, konnte also nicht geladen werden.

Das seltsame daran war das der IE zunächst einen 304 Statuscode vom Server erhielt (für eine nicht existierende Datei) und daraufhin ca. 200-300 Requests auf diese Datei losfeuerte (alle endeten mit einem 304 Statuscode). Nachdem ich dann den Verweis aus der CSS entfernt habe wurde es besser und es werden nur noch Requests abgesetzt welche auch gemacht werden müssen, aber es passiert dennoch ab und an das man sich beim IE Surfen auf der Seite quasi selbst aussperrt.

Da ich mittlerweile ziemlich ratlos bin dachte ich, ich frage mal hier. Ich gehe zwar nicht davon aus viele Antworten zu erhalten, auch aufgrund fehlender Details zur Serverkonfiguration, aber vielleicht kennt ja jemand dieses höchst sonderbare Verhalten.

__________________
"Alles im Universum funktioniert, wenn du nur weißt wie du es anwenden musst".

Mister Ad

ChrisB

Wie sah der genau aus?
Waren vielleicht CSS Expressions im Spiel?

Mit dem gleichen IE - der vielleicht noch die alte Version der CSS-Ressource ab und an aus seinem zuweilen unergründlich arbeitenden Cache hervorzaubert, und damit das Verhalten trotz Behebung des Fehlers wiederholt;
oder auch mit anderen IEs, die die Seite zuvor noch nie besucht haben, und bei denen deshalb ein Cache-Problem sicher ausgeschlossen werden kann?


(Die Serverkonfiguration dürfte hierbei vermutlich weniger von Interesse sein.)

__________________
RGB is totally confusing - I mean, at least #C0FFEE should be brown, right?

Dark Guardian

Da mir die Funktionsweiße und die Möglichkeiten einer .htc Datei unbekannt sind kann ich genaueres dazu nicht sagen. Ich weiss nur das unser Mediengestalter dies ursprünglich eingesetzt hatte.

Sicher ausschließen kann ich ein Cacheproblem nicht. Ich habe nur nicht in Betracht gezogen das der IE eine Ressource die eigentlich gar nicht auf dem Server existiert cachen könnte. Aber theoretisch könnte das Sinn machen da ja auch ein 304 Status vom Server kam. Die Frage wäre dann nur warum würde der IE das ganze immernoch ausführen wenn der Verweis aus der CSS Datei entnommen wurde?

Naja, war mir dabei nicht ganz sicher weil eine 304 Response für eine nicht existierende Ressource eigentlich auch nicht normal ist... (bzw. falls ein Cacheproblem vorliegt eine "nicht mehr" existierende Ressource).

Vielleicht auch noch erwähnenswert: Die Webseite existiert zweimal. Einmal eine Produktivumgebung und eine Testumgebung. Bis heute kam dies ausschließlich in der Testumgebung vor. Heute sperrte ich mich (erstmals) beim Testen in der Produktivumgebung selbst aus. Dies spricht eigentlich gegen ein Cacheproblem da beide Systeme auf unterschiedlichen Domains laufen.

Bisher haben wir das Problem halt ignoriert weil es nur in der Testumgebung aufgetreten ist. Im Produktivsystem aber wird es zu einem sehr schwerwiegendem Problem da wir nicht wissen ob sich ggf. zahlende Kunden nun selber aussperren.

__________________
"Alles im Universum funktioniert, wenn du nur weißt wie du es anwenden musst".

nikosch

__________________
--
One pixel is still too big. Please make it smaller. ASAP.

Initiative Mittelstand.
Die wichtigste Gestaltungsregel im Screendesign ist Pi mal Daumen des Arbeitgebers.
--

Dark Guardian

Ok... es lag weder an dem .htc File noch am Browser Cache.

Wir haben mittlerweile Zugriffslogdateien bekommen und die Information vom Hoster das ab 23 paralellen Requests eine IP gesperrt wird. Jedoch bringen uns beide Informatiopnen nicht weiter.

Da die Anfragen eines Browser sequenziel erfolgen kann es schlecht an der Webseite liegen. Oder stellt der IE tatsächlich bis zu 23 Requests parallel?

__________________
"Alles im Universum funktioniert, wenn du nur weißt wie du es anwenden musst".

eagle275

frag die besser mal, wann die DB- oder ServerBackups fahren .. dann hast du "naturgemäß" langsame Antwortzeiten und die können zu Mehrfach-Abfragen führen ....

__________________
"Irren ist männlich", sprach der Igel und stieg von der Drahtbürste

mepeisen

IE Debugging tools installieren, netzwerkverkehr beobachten. Das ist was ähnliches wie firebug für ff.

__________________
www.php-maven.org PHP und Maven vereint: Build/Deploy/Produktion/Konfiguration, Projekt Management, CI, PHPUnit, zahlreiche Frameworks
Twitter @ https://twitter.com/#!/mepeisen und Facebook @ http://t.co/DZnKSUih

Flor1an

Das ist Konfigurationssache. Glaub als Standard hat der IE 2 oder 4 parallele Verbindungen eingestellt, man kann die aber beliebig hoch setzen (genauso in anderen Browsern).

ChrisB

@Flor1an: Das würde aber zwei Dutzend „parallele“ Requests nach der selben Ressource immer noch nicht schlüssig erklären.

__________________
RGB is totally confusing - I mean, at least #C0FFEE should be brown, right?

tr0y

http://support.microsoft.com/kb/319176

Ich vermute die HTC-Komponente des IE unterliegt nicht den Standard Prozess Werten und kann unlimitiert viele Requests feuern ( falls nötig ). Zumindest kann ich mir das Problem nicht anders erklären.

__________________
Lasse mir ohne Anwendung von Gewalt Dinge schenken, Amazon weiß darüber bald mehr.