super_tina
Ausgeschlossen
Beiträge: 769
Registriert: 31.3.2006
Status: Offline |
 erstellt am: 31.12.2006 um 00:13 Uhr: |
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. ____________________
 Ach ja... und JETZT ERST RECHT!  ... weil es so schön ärgert.
Geboren, geliebt, verschwunden, aber in unserem Herzen bleibt er für immer! |
| |
| |
onassis
 Beiträge: 476 Registriert: 5.5.2005 Status: Offline |
erstellt am: 15.1.2007 um 12:09 Uhr: |
Hi Guido,
also bei mir ist die Meldung nicht wieder aufgetaucht! Scheint dank der fähigen Leute behoben zu sein!
DANKE!!! ____________________
The Only Way To Keep Me, Is To Treat Me Like A Queen
..
 |
| |
gcrapels
Beiträge: 733 Registriert: 8.7.2006 Status: Offline |
erstellt am: 15.1.2007 um 07:37 Uhr: |
| 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 ? |
| |
gcrapels
Beiträge: 733 Registriert: 8.7.2006 Status: Offline |
erstellt am: 6.1.2007 um 18:32 Uhr: |
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 ?
 . |
| |
Pierre
Beiträge: 539 Registriert: 3.9.2004 Status: Offline |
erstellt am: 5.1.2007 um 18:32 Uhr: |
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 |
| |
super_tina
Ausgeschlossen
Beiträge: 769
Registriert: 31.3.2006
Status: Offline |
 erstellt am: 5.1.2007 um 17:43 Uhr: |
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 ?
DAS ist ja das was nervt... DAS WEGKLICKENMÜSSEN!
Es taucht übrigens auch nach dem Wegklicken noch mehrfach auf (manchmal) und zwar OHNE dass ich überhaupt poste. ____________________
Ach ja... und JETZT ERST RECHT! ... weil es so schön ärgert.
Geboren, geliebt, verschwunden, aber in unserem Herzen bleibt er für immer! |
| |
SAM
ehemaliger Administrator  Beiträge: 1361 Registriert: 2.4.2003 Status: Offline |
erstellt am: 5.1.2007 um 15:36 Uhr: |
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.) ____________________
  |
| |
smartys
Beiträge: 1194 Registriert: 23.2.2005 Status: Offline |
erstellt am: 5.1.2007 um 14:59 Uhr: |
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. |
| |
Pierre
Beiträge: 539 Registriert: 3.9.2004 Status: Offline |
erstellt am: 5.1.2007 um 14:48 Uhr: |
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 |
| |
SAM
ehemaliger Administrator Beiträge: 1361 Registriert: 2.4.2003 Status: Offline |
erstellt am: 5.1.2007 um 14:36 Uhr: |
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. ____________________
|
| |
Pierre
Beiträge: 539 Registriert: 3.9.2004 Status: Offline |
erstellt am: 5.1.2007 um 13:53 Uhr: |
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] |
| |
SAM
ehemaliger Administrator Beiträge: 1361 Registriert: 2.4.2003 Status: Offline |
erstellt am: 5.1.2007 um 13:48 Uhr: |
Zitat:
Ist Output Buffering aktiv?
Nicht mehr.
Wie ich weiter oben schon geschrieben habe, wurde ursprünglich Output Buffering für die Komprimierung verwendet (ob_gzhandler). Ich hielt das ja auch für die Ursache und hatte es deshalb abgeschaltet. Half nur nichts.
An anderen Stellen innerhalb von PostNuke kommt Output Buffering zwar noch vor, aber nicht bei dem, was von modules.php benutzt wird. ____________________
|
| |
Pierre
Beiträge: 539 Registriert: 3.9.2004 Status: Offline |
erstellt am: 5.1.2007 um 13:45 Uhr: |
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 |
| |
smartys
Beiträge: 1194 Registriert: 23.2.2005 Status: Offline |
erstellt am: 5.1.2007 um 13:20 Uhr: |
Ja, das hätte ich jetzt auch spontan so vermutet. 
Schuldigung! *schonwegbin*
Viel Glück , SAM ! |
| |
Pierre
Beiträge: 539 Registriert: 3.9.2004 Status: Offline |
erstellt am: 5.1.2007 um 13:03 Uhr: |
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 |
| |
SAM
ehemaliger Administrator Beiträge: 1361 Registriert: 2.4.2003 Status: Offline |
erstellt am: 5.1.2007 um 12:49 Uhr: |
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. ____________________
|
| |
Pierre
Beiträge: 539 Registriert: 3.9.2004 Status: Offline |
erstellt am: 5.1.2007 um 12:35 Uhr: |
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 |
| |
SAM
ehemaliger Administrator Beiträge: 1361 Registriert: 2.4.2003 Status: Offline |
erstellt am: 5.1.2007 um 11:59 Uhr: |
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] ____________________
|
| |
SAM
ehemaliger Administrator Beiträge: 1361 Registriert: 2.4.2003 Status: Offline |
erstellt am: 5.1.2007 um 11:08 Uhr: |
Zitat:
Würde es etwas bringen den Debian Linux-Server auf dem letzten Stand zu bringen ?
Vielleicht. Nur muss man das Host Europe fragen. Das ist hier nur shared Webhosting.
Zitat:
alternativ eventuell wirklich auf php 5.x updaten.
PHP 5 ist vorhanden, aber damit läuft das olle XForum nicht.
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)
Ja. Ich warte schon die ganze Zeit darauf, dass es bei mir auch mal wieder passiert, dann schaue ich mal, was dort steht. ____________________
|
| |
HSINC
Beiträge: 49 Registriert: 6.5.2005 Status: Offline |
erstellt am: 5.1.2007 um 08:50 Uhr: |
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 |
| |
gcrapels
Beiträge: 733 Registriert: 8.7.2006 Status: Offline |
erstellt am: 5.1.2007 um 07:36 Uhr: |
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 ? |
| |
super_tina
Ausgeschlossen
Beiträge: 769
Registriert: 31.3.2006
Status: Offline |
 erstellt am: 4.1.2007 um 23:01 Uhr: |
Zitat:
Schaden kann das modules.php nicht.
Nee, aber nerven tut es mittlerweile ziemlich  ____________________
Ach ja... und JETZT ERST RECHT! ... weil es so schön ärgert.
Geboren, geliebt, verschwunden, aber in unserem Herzen bleibt er für immer! |
| |
gcrapels
Beiträge: 733 Registriert: 8.7.2006 Status: Offline |
 erstellt am: 4.1.2007 um 20:43 Uhr: |
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 ? . ____________________
  |
| |
super_tina
Ausgeschlossen
Beiträge: 769
Registriert: 31.3.2006
Status: Offline |
erstellt am: 4.1.2007 um 17:47 Uhr: |
| Menno , gerade ist es bei mir wieder aufgetreten. Es erscheint zwar nicht mehr so oft, aber heute hatte ich mal wieder das Vergnügen... ____________________
Ach ja... und JETZT ERST RECHT! ... weil es so schön ärgert.
Geboren, geliebt, verschwunden, aber in unserem Herzen bleibt er für immer! |
| |
SAM
ehemaliger Administrator Beiträge: 1361 Registriert: 2.4.2003 Status: Offline |
erstellt am: 4.1.2007 um 10:18 Uhr: |
Zitat:
sam, schau mal was der apa ins error log dazu schreibt
Nichts in diesem Fall.
Zitat:
liegt aber 100 pro nicht am gzip
Ich hatte die Vermutung, weil ich beim Googlen Berichte gefunden habe, dass dieses Phänomen gerne mal bei Verwendung des ob_gzhandler vorkommt. Das war es aber nicht. Jetzt, mit zlib.output_compression statt ob_gzhandler kommt es immer noch vor.
Ich habe auch zur Sicherheit noch ein header("Content-Type: text/html", true); an den Anfang von modules.php gesetzt, aber auch das nutzt nichts. Ab und zu wird die Seite trotzdem mit dem MIME-Typ application/x-httpd-php oder application/octet-stream ausgeliefert. ____________________
|
| |
HSINC
Beiträge: 49 Registriert: 6.5.2005 Status: Offline |
erstellt am: 4.1.2007 um 06:56 Uhr: |
sam, schau mal was der apa ins error log dazu schreibt
liegt aber 100 pro nicht am gzip |
| |
Speedy
Beiträge: 544 Registriert: 21.7.2003 Status: Offline |
erstellt am: 3.1.2007 um 23:18 Uhr: |
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. ____________________
 |
| |
HDHome
Beiträge: 157 Registriert: 20.11.2005 Status: Offline |
erstellt am: 3.1.2007 um 14:00 Uhr: |
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 ____________________
|
| |
Pierre
Beiträge: 539 Registriert: 3.9.2004 Status: Offline |
erstellt am: 2.1.2007 um 11:17 Uhr: |
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 |
| |
SAM
ehemaliger Administrator Beiträge: 1361 Registriert: 2.4.2003 Status: Offline |
erstellt am: 2.1.2007 um 11:01 Uhr: |
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. ____________________
|
| |
