Eine Frage an unseren Admin:

Seit ich gestern Wolles Fotos zum Weihnachtsmarkt Moyland angesehen habe, bietet mir das System HIER im Club immer in einem separaten Fenster an modules.php von www.smart-roadster-club.de auf meine Festplatte zu speichern. Was ist das???

Ich habe mir gestern zwar von Wolles Fotos ein paar runtergespeichert, aber selbst nach mehrmaligen Runterfahren des PCs erscheint immer wieder dieses Fenster mit der Bitte um "Datei speichern" oder "verlassen". Wie kriege ich das wieder weg und hat das noch jemand? Bisher habe ich immer "verlassen" geklickt, denn ich wollte mir nicht irgendetwas Dubioses runterladen.

Hallo Tina,

ich habe schon befürchtet, dass ich nicht der einzige bin, bei dem das ab und zu passiert. Ich vermute, es liegt an der Gzip-Komprimierung. Auf dem alten Server hatte die keine Probleme gemacht. Ich habe jetzt die Komprimierung in der Forumssoftware ausgeschaltet und dafür global eingeschaltet. Der Effekt sollte nun nicht mehr auftreten.

Gefährlich war das übrigens nicht. Der Browser hielt die Webseite für eine ZIP-Datei und wollte sie runterladen. Durch Wegklicken der Meldung und Neuladen der Seite ließ sich das Problem dann auch umgehen.

Ist bei mir gerade einmal passiert.

Immer noch? Mist. Ich will die Komprimierung nicht ganz abschalten müssen, denn das erhöht den Traffic doch enorm...

Also bei mir tritt das Problem auch auf... auch heute wieder!
Scheint somit noch nicht erledigt zu sein...

Bei mir ist es noch nie aufgetreten. Ich arbeite sowohl mit IE 6.0 als mit Mozilla/Firefox 1.0.6 auf verschiedenen Systemen, im Büro und zuHause. In Linux ist es auch nicht aufgetreten (wem wundert's ). Was ist bei euch anders als bei mir ? (ja, mir fallen hierzu auch einige scherzhafte Bemerkungen ein, ich weiß, aber bitte aufs Thema bezogen ! ).
Was seit des Domainumzuges schon auffällt, ist daß bei einigen die Sig nicht mehr erreichbar ist innerhalb Internet Explorer 6.0 , aber wohl innerhalb Firefox 1.0.6 ! , obwohl die Adressen nicht geändert worden sind. Es hat wohl nichts zu tun mit der zusätzlichen Adresse ohne Striche (also: smartroadsterclub statt smart-roadster-club), denn bei einigen funktioniert die alte Adresse auch noch immer. Woran liegt es dann ?

Hallo Guido,

ich nutze auch Firefox und habe die Meldung trotzdem! Jetzt gerade eben erst wieder!
Stört mich nicht großartig, man kann sie ja wegdrücken, aber komisch ists schon!

Leider bin ich kein PC Experte, mehr kann ich nicht dazu sagen...

Das mit den Sigs habe ich auch, zumindest bei manchen ...

Hallo zusammen,

das mit den Signaturen wird sich von alleine lösen, sobald Werner die bisherige Domain smart-roadster-club.de freigegeben hat und diese dann auch auf dem neuen Server liegt. Bis dahin gehen die Zugriffe auf smart-roadster-club.de erst zu Werners altem Server und werden von dort wieder hier hin zurückgeleitet. Manchmal kommt es dabei wohl zu einem Timeout. Ein "verschärftes" Neuladen der Seite (Shift + Reload) lädt die fehlenden Signaturen nach.

Das Phänomen mit dem Downloaddialog bei modules.php ist mir allerdings rätselhaft. Zumal es nur sporadisch auftritt. Ich warte da aber auch erst mal den vollständigen Domainumzug ab.

Ich hatte den Prompt mit IE6 und nicht mit IE7 und FF. Nach dem Löschen des PW Cookies unter IE6 war er da ebenfalls weg (wenns hilft...).

Pierre

Hab seit ein paar Wochen Mozilla 2.x! Heute bin ich das erste mal seit längerer Zeit wieder im Forum, bei mir kam auch eben das Feld!

Dachte schon es wär ein Virus-Proggi... hab sicherheitshalber "Abbrechen" gedrückt

Gruß Hape

Ha, bei mir hat alles super geklappt. Ich hab mir sogar vor paar Tagen ein neues Passwort angefordert und gerade wieder geändert, damit ich endlich mal weiß, wie ich mich ausserhalb einloggen könnte.....wollt eigentlich nur mal grad was schreiben um zu sehn ob alles beim Alten ist *gg*

Ich benutze normal Netscape und den Fehler hatte ich bisher auch nicht. ....also weiter so und ein Lob an die Moderatoren.

sam, schau mal was der apa ins error log dazu schreibt
liegt aber 100 pro nicht am gzip

Zitat:

---

sam, schau mal was der apa ins error log dazu schreibt

---

Zitat:

---

liegt aber 100 pro nicht am gzip

---

Menno , gerade ist es bei mir wieder aufgetreten. Es erscheint zwar nicht mehr so oft, aber heute hatte ich mal wieder das Vergnügen...

Schaden kann das modules.php nicht. Helfen tut es aber auch nichts auf der eigenen Festplatte . Es enthält die php-Skripts für den Aufbau und das Verhalten der Webseiten des Forums, aber es macht nur Sinn innerhalb des Servers. Auf dem eigenen Rechner hat es nichts zu suchen.

Ich sehe daß der html-Server auf Apache 2.0.54 dreht. Jetzt sind wir aber bei Version 2.2.3. Auch wird php 4.4.4 benutzt, während Version 5.2.0 verfügbar wäre. Würde es etwas bringen den Debian Linux-Server auf dem letzten Stand zu bringen ? .

Zitat:

---

Schaden kann das modules.php nicht.

---

Es ist bloß komisch daß es nicht immer passiert, sondern nur gelegentlich. Gestern sah ich es bei mir zum ersten Mal im Mozilla-Browser auf Window$ XP während des Einstellens eines Posts. Bei Mac OS (10.2.8) habe ich es noch nicht gesehen, auch nicht bei Linux (SuSE 10). Das sind immer die schwierigsten Fälle, da wo eine Störung nur ab und zu auftritt. Trotzdem, es muß eine Erklärung geben für dieses Benehmen. Die Logs weiter beobachten und vergleichen, würde ich sagen.
Es braucht nicht zu nerven, klicke es einfach weg. Wie oft passiert es denn ? Nur beim Posten oder auch beim bloßen angucken der Seiten ?

naja entweder schmiert der apa weg (unwahrscheinlich da nix in den logs) oder ein modul des apas semmelt weg (aber auch da müsste was in den logs stehen)
man koennte mal ausprobieren ob es mit php als modul / cgi (je nachdem was grad läuft eben das andere) immer noch auftritt.
alternativ eventuell wirklich auf php 5.x updaten.
und es wäre noch interessant was der inhalt der downgeloadeten seite ist, eventuell steht da die fehlermeldung drinne (zu kurze scriptlaufzeit, zu wenig speicher, whatever)
ansonsten bin ich momentan eher ratlos

Zitat:

---

Würde es etwas bringen den Debian Linux-Server auf dem letzten Stand zu bringen ?

---

Zitat:

---

alternativ eventuell wirklich auf php 5.x updaten.

---

Zitat:

---

und es wäre noch interessant was der inhalt der downgeloadeten seite ist, eventuell steht da die fehlermeldung drinne (zu kurze scriptlaufzeit, zu wenig speicher, whatever)

---

So, jetzt ist es passiert.

Die heruntergeladene Datei beginnt mit den magic bytes 0x1f 0x8b. Es ist also eine Gzip-komprimierte Datei. Dann folgen in der Datei die HTTP Header im Klartext(!), dann nochmal die magic bytes 0x1f 0x8b und dann eine Menge binäres, wohl der komprimierte Inhalt der Seite. Wieso sind die HTTP Header im Klartext innerhalb des Gezippten, anstatt davor? Das scheint mir der Fehler zu sein. Nur, wo kommt er her?



[Editiert am 2007-1-5 von SAM]

Ne. Der Header muss im Klartext übertragen werden - sonst weiss ja keiner, dass es sich beim Content Encoding um Gzip handelt (könnte ja auch was anderes sein).

Pierre

Schon klar. Aber der Header sollte nicht nach dem magic byte, welches den Anfang des Gezippten markiert, kommen, oder?

Möglicherweise ist der selbe Header auch ein zweites mal korrekt vor dem gezippten Inhalt gesendet worden, das sehe ich ja der gespeicherten Datei nicht an. Aber er gehört doch nicht ins Gezippte hinein.

So nämlich will gzip die Datei durchaus entzippen, meldet dann aber, dass der Inhalt "garbage" sei.

Ah, verstehe. Sieht also so aus, als würde irgend ein Modul in die komprimierten Daten reinfummeln. Ist Output Buffering aktiv? Das würde erklären, warum der Fehler immer nur sporadisch aber dafür mit allen Browsern auftritt.

Pierre

Ja, das hätte ich jetzt auch spontan so vermutet.
Schuldigung! *schonwegbin*
Viel Glück , SAM !

Noch ne Idee... wenn der (neue?) Apache sowieso auf dynamic compression ausgelegt ist, dann wird er die von PHP komprimierten Daten unter bestimmten Umständen nochmal komprimieren wollen. (Dann könnte man die Compression unter PHP aber auch einfach abschalten).

Pierre

Zitat:

---

Ist Output Buffering aktiv?

---

Ich hab übrigens beim Logout auch schon ein Prompt für users.php bekommen.

Pierre

(zum obigen Post noch ein Auszug aus der Nuke Doku)

3.9.19. Compressed output in forums

Figure 3-37. Gzip compression in the Admin Panel of the Forums module.

[forum-gzip-compression.png]

Gzip compression in the Admin Panel of the Forums module.

You seem to be getting a compressed output in the forums. You are
either seeing garbage, or you can see it in IE, but not in Mozilla.
When you press "Refresh", Mozilla reacts like you want to download
something that is "encrypted" or compressed.

All this is a sign that you may be compressing the page twice. If, for
example, your Apache has been already configured to send compressed
output (with mod_gzip, or some other technique for Web Content
Compression), then you should disable gzip compression in the forums
administration panel (from "General Admin, Configuration", as in
Figure 3-37).

See also Cannot see forum in Mozilla and see in IE.

[Editiert am 5/1/2007 von Pierre]

Danke für den Hinweis. Ja, es sieht wirklich so aus wie zweifache Komprimierung. Aber warum nur ab und zu? Und wenn ich die Komprimierung bei PHP ganz abschalte, dann ist gar nichts mehr komprimiert (so zeigt es jedenfalls Web-Sniffer an). Der Apache hat auch kein Modul geladen, was komprimieren könnte. Mehr kann ich nicht feststellen, bei Shared Webhosting komme ich ja an den Apache nicht ran.

Ich schalte jetzt mal für ein paar Tage testweise die PHP-Komprimierung ganz ab. Ich sollte dann ja an der täglichen Traffic-Statistik merken, wenn wirklich nichts komprimiert wurde.

Gute Frage... wenn ich den Kompressionsalgorithmus richtig verstehe, komprimiert der erst ab einer bestimmten content-length prediction und hört wieder auf, sobald der target buffer einen overflow bekommt. Da der so groß wie der Source Block allokiert wird, bedeutet ein Overflow, dass die Daten durchs Komprimieren wachsen, weshalb die Daten dann unkomprimiert übertragen werden (macht ja auch Sinn). Da die anscheinen beide (PHP und Apache) mit denselben gzip Modulen arbeiten kann ich mir höchstens vorstellen, dass der vom Apache vielleicht etwas härter eingestellt ist (-9 oder so) und ab und zu eben doch noch was zum komprimieren findet, während er normalerweise aussteigt und die Originaldaten in Ruhe lässt. Das Prinzip hinter der php Buffer Compression verstehe ich überghaupt nicht. Da ist irgendwo von Dynamic Bandwidth Adaption die Rede, aber wie will er dass denn ermitteln, wenn er bloss seinen Output Buffer komprimieren soll? Oder macht setzt der Browser das accept Flag mal so und mal so - je nach Durchsatz? Fragen über Fragen

Pierre

Nein, tut mir Leid ! Keine Hilfe mehr von mir. Da müsst Ihr jetzt mal von selbst drauf kommen.

Hoffentlich ist das alles nicht ansteckend, was Ihr hier so schreibt.

Doppelt komprimiert kann auch nicht sein. Dann wären die Header darin ja nicht im Klartext. Außerdem: Wenn ich mit einem Hex-Editor die Klartextheader entferne (und das magic byte für gzip am Anfang auch; denn nach den Klartextheadern kommt noch ein zweites Mal solch ein magic byte), dann lässt sich die Datei zu lesbarem HTML entzippen. Allerdings nicht ganz, so auf der Hälfte bricht es mit einem Lesefehler ab.

Eigentlich kann da nur PHP was falsch machen. PHP komprimiert und PHP setzt auch die Header. Nur gerät da was durcheinander.

(Dieser Fehler macht mich noch irre. Macht...? Äh... wie auch immer.)

Zitat:

---

Es braucht nicht zu nerven, klicke es einfach weg. Wie oft passiert es denn ? Nur beim Posten oder auch beim bloßen angucken der Seiten ?

---

Ja.. blöde Geschichte. Und im Google findet man so spontan auch keinen wirklich guten Hinweis. Aber nach dem Abschalten des Compression müsste ja eigentlich alles funktionieren. Ist das denn mit dem traffic so schlimm? Wird das nach transfer volume verrechnet? (Denn im Bezug auf Performance dürfte es doch eigentlich kein Thema sein. Zumindest von hier aus macht die komplette site einen vergleichsweise responsiven Eindruck.)

Pierre

Könnte es sein, daß das MagicByte ganz am Anfang da stehen muß, damit der Parser Bescheid weiß daß eine komprimierte Seite geschickt worden ist ?
Wieso wird eigentlich über php die Komprimierung gemacht ? Kann Apache das mit den eigenen Modulen nicht selber dynamisch erledigen ?
Und schließlich: vielleicht werden die Komprimierungen der gif- und jpg-Bilder nicht richtig gerendert, weil sie ja schon von sich aus komprimiert sind. Das führt dann nur manchmal zum Problem, weil das Ergebnis der "Komprimierung" etwas anderes ist, als der Parser es erwartet. Wäre es ein Versuch wert in der gzip-config die gif- und jpg's raus zu nehmen ?
.

War es das jetzt schon ? Der Umzug ist jetzt wohl volendet. Hat jemand noch das Problem mit dem modules.php ? Ich habe es nur ein paar Mal gesehen und seit einiger Zeit überhaupt nicht mehr. Endet die Geschichte hier rumlos oder geht es hinter den Kulissen weiter ?

Hi Guido,
also bei mir ist die Meldung nicht wieder aufgetaucht! Scheint dank der fähigen Leute behoben zu sein!

DANKE!!!