[Attachment Mod] Grafik speichern als...download.php!?
Verfasst: 20.08.2007 23:33
Gute Abend liebe Community 
Mich nerven meine Mitglieder mal wieder *g* Denn manch einer stört sich nachwievor an der Macke des Attachment-Mods, Bildernamen nicht korrekt zu übermitteln. Bedeutet:
Bei mir im Forum werden Bilder als "physical" geöffnet, sprich das Originalbild wird nach dem Klick auf den Link im Browserfenster auch angezeigt. Will man jedoch nun die Grafik lokal abspeichern, schlägt mir Firefox "download.php" als Dateiname vor- obwohl der Link im Adressfenster ein absoluter und kein dynamischer ist. Selbst die Seiteninformationen (Option im Rechtsklick-Menü) lassen nichts konspiratives erkennen. Ulkigerweise stimmt der Dateiname aber, wenn ich das Bild mit "Datei/Seite speichern unter" speichern will.
Der IE verhält sich dagegen etwas konkreter, er schlägt mir wenigstens ein "unbenannt.bmp" als Dateiname vor, was immerhin schonmal eine Grafik-Datei, aber auch nicht das Wahre ist. Ein Blick in die Seiteninformationen veräußert jedoch ein "...download?id=xxx" als Quelle, ganz im Gegensatz zum Adressfeld. Also kann hier offenbar etwas nicht stimmen. Der Trick über "Datei/Speichern unter" funktioniert hier im Gegensatz zum Firefox nicht.
Auffällig ist ausserdem, dass -wenn ich nicht auf die Büroklammer klicke sondern stattdessen "Ziel speichern unter" wähle- mir der IE den korrekten Dateinamen anbietet, Firefox jedoch bei seiner bewährten download.php bleibt. Und das nicht nur bei Grafiken, sondern auch anderen Dateiformaten. Ich blick nicht mehr durch x_x
Falls sich mal jemand selber einen Eindruck verschaffen will, nur zu :?
Gibt es evtl. bestimmte Parameter, die man an den Browser zusätzlich übermitteln muss, damit er den korrekten Dateinamen auch ausgibt?
Sicher, das Bild als download.php gespeichert ist nachwievor ein Bild, nur mit der falschen Dateiendung...und das mag nicht jeder wahr haben
Edit: Ach ja, die Versionsnummer...File Attachment Mod 2.4.5
Mich nerven meine Mitglieder mal wieder *g* Denn manch einer stört sich nachwievor an der Macke des Attachment-Mods, Bildernamen nicht korrekt zu übermitteln. Bedeutet:Bei mir im Forum werden Bilder als "physical" geöffnet, sprich das Originalbild wird nach dem Klick auf den Link im Browserfenster auch angezeigt. Will man jedoch nun die Grafik lokal abspeichern, schlägt mir Firefox "download.php" als Dateiname vor- obwohl der Link im Adressfenster ein absoluter und kein dynamischer ist. Selbst die Seiteninformationen (Option im Rechtsklick-Menü) lassen nichts konspiratives erkennen. Ulkigerweise stimmt der Dateiname aber, wenn ich das Bild mit "Datei/Seite speichern unter" speichern will.
Der IE verhält sich dagegen etwas konkreter, er schlägt mir wenigstens ein "unbenannt.bmp" als Dateiname vor, was immerhin schonmal eine Grafik-Datei, aber auch nicht das Wahre ist. Ein Blick in die Seiteninformationen veräußert jedoch ein "...download?id=xxx" als Quelle, ganz im Gegensatz zum Adressfeld. Also kann hier offenbar etwas nicht stimmen. Der Trick über "Datei/Speichern unter" funktioniert hier im Gegensatz zum Firefox nicht.
Auffällig ist ausserdem, dass -wenn ich nicht auf die Büroklammer klicke sondern stattdessen "Ziel speichern unter" wähle- mir der IE den korrekten Dateinamen anbietet, Firefox jedoch bei seiner bewährten download.php bleibt. Und das nicht nur bei Grafiken, sondern auch anderen Dateiformaten. Ich blick nicht mehr durch x_x
Falls sich mal jemand selber einen Eindruck verschaffen will, nur zu :?
Gibt es evtl. bestimmte Parameter, die man an den Browser zusätzlich übermitteln muss, damit er den korrekten Dateinamen auch ausgibt?
Sicher, das Bild als download.php gespeichert ist nachwievor ein Bild, nur mit der falschen Dateiendung...und das mag nicht jeder wahr haben
Edit: Ach ja, die Versionsnummer...File Attachment Mod 2.4.5
Darum habe ich mich auch selber etwas recherchiert. Dieses "Problem" scheint wohl nur bei php-Weiterleitungen mittels header(Location:) aufzutreten, nicht aber bei Redirects per META-Tag. Beim Internet Explorer 6 scheint dies ein Bug zu sein, beim Firefox dagegen ein Feature, denn dieses Problem taucht dort erst seit Firefox 1.5 auf - der dazugehörige 