Content-Type für erzwungene Downloads

Einklappen
X
 
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • Content-Type für erzwungene Downloads

    Hallo,
    ich benutze ein Script für erzwungene Downloads, damit man den Usern nicht für jeden Browser erklären muß, wie er die Datei auf die Festplatte bekommt, statt daß die online geöffnet wird. Das klappt ja auch gut, aber mit der Erkennung/Darstellung des Dateiformats bin ich nicht 100% zufrieden. Lassen wir mal eine Verzeichnisstruktur weg und gehen davon aus, daß der Name der angebotenen Datei in $datei gespeichert ist, dann habe ich
    PHP-Code:
    header("Content-Length: ".filesize($datei));
    header("Content-Disposition: attachment; filename=".$datei);
    readfile($datei); 
    Davor habe ich als erste header-Zeile unterschiedliche Sachen ausprobiert, zu denen auf verschiedenen Internetseiten geraten wurde:
    PHP-Code:
    header("Content-Type: x-type/subtype");
    header("Content-Type: x-type/x-subtype");
    header("Content-Type: application/octet-stream");
    header("Content-Type: application/".substr(strrchr($datei"."),1)); 
    Das erste bewirkt, daß beim FireFox für jede Datei als Typ "Adobe Acrobat Document" angezeigt wird. Schön im Klartext und mit zugehörigem Logo als Icon, aber das war natürlich Mist.
    Die anderen Varianten oder das Weglassen dieser zusätzlichen Zeile bringen zwar keine falschen Ergebnisse und sind einigermaßen erträglich, aber erstens zeigt der FireFox als Icon nicht das Symbol der zugehörigen Anwendung und zweitens bekommen nur manche Formate eine Klartext-Bezeichnung, ansonsten steht da "xxx-Datei" (wobei xxx hier für die Dateikennung steht).

    Gibt es denn eine Möglichkeit, wie man per Script für jedes Dateiformat den passenden Content-Type-Eintrag generieren lassen kann oder einen universellen Eintrag für Content-Type, der die Browsermöglichkeiten (inkl. Anwendungssymbol) vollständig nutzt?


    Danke!
    Zuletzt geändert von micmen; 06.04.2006, 13:49.

  • #2
    Re: Content-Type für erzwungene Downloads

    Original geschrieben von micmen
    aber erstens zeigt der FireFox als Icon nicht das Symbol der zugehörigen Anwendung und zweitens bekommen nur manche Formate eine Klartext-Bezeichnung, ansonsten steht da "xxx-Datei" (wobei xxx hier für die Dateikennung steht).
    Ja was hast du denn erwartet?

    Damit der Browser "garantiert" die Ressource zum Abspeichern anbietet, verwendest du einen MimeType, der im mit allerhöchster Wahrscheinlichkeit unbekannt ist.
    Wie bitte soll er zu etwas ihm vollkommen Unbekanntem die "passende" Anwendung und "Klartext-Bezeichnung" ermitteln ...?
    I don't believe in rebirth. Actually, I never did in my whole lives.

    Kommentar


    • #3
      Hi wahsaga,
      ich habe keine einzige Datei auf dem Server, für die mein Rechner nicht eine Standardanwendung hätte, also eigentlich sollte er alle Typen erkennen.
      Er bekommt ja auch die Kennung (steckt ja im Dateinamen) und in der letzten der vier Varianten wird ihm die Kennung sogar explizit über header Content-Type übergeben.

      Er bringt ja für manche Dateitypen den korrekten Klartext, wie er soll. Wie gesagt, halt nur nicht immer. Also ein grundsätzliches Problem scheidet sowieso schonmal aus.

      Der IE zum Beispiel zeigt für alle Dateien das Symbol der verknüpften Anwendung an, der FireFox nicht. Mit der Ausnahme der ersten Variante, wo er so tut, als sei jede Datei ein PDF (oder sonst ein "Adobe Acrobat Document"), mit korrektem Icon und Klartext.


      Frage ist, wie ich das Script anders machen könnte...

      Kommentar


      • #4
        Original geschrieben von micmen
        ich habe keine einzige Datei auf dem Server, für die mein Rechner nicht eine Standardanwendung hätte, also eigentlich sollte er alle Typen erkennen.
        Du hast im HTTP-Umfeld überhaupt keine "Dateien", sondern nur Ressourcen.
        Er bekommt ja auch die Kennung (steckt ja im Dateinamen)
        Noch mal: Das Konstrukt "Datei" gibt es in diesem Umfeld nicht, sondern lediglich eine Ressource.
        Und deren Name ist vollkommen uninteressant, ebenso ob sie irgendeine "Endung" hat.
        Wie der Client die Ressource behandeln soll, entscheidet er einzig und allein anhand des Content-type-Headers, unter dem der Server die Ressource ausliefert.
        Ein Browser, der etwas anderes macht, ist eindeutig als kaputt zu bezeichnen - so beispielsweise der IE.

        und in der letzten der vier Varianten wird ihm die Kennung sogar explizit über header Content-Type übergeben.
        Ja, "explizit" als x-type/x-subtype oder application/octet-stream.
        Und welche Anwendung hast du in den Einstellungen deines Firefox mit diesen Content-types verknüpft?
        I don't believe in rebirth. Actually, I never did in my whole lives.

        Kommentar


        • #5
          Hmm Ressource - möglicherweise kenne ich da nicht alle relevanten Aspekte...
          Aber wie gesagt habe ich hier ja auch eine Frage gepostet, ich suche also tatsächlich nach einer Info. Ich sehe zwar nicht, wie diese ganzen Dinge da weiterhelfen sollen, aber ich will trotzdem auf den Beitrag eingehen:
          Bei allen diesen von mir beschriebenen Varianten werden, wie man sehen kann, dem Browser ja gar keine mime-Typen übergeben. Also kann er die Ressource, die er bekommt, ja nur aufgrund der Dateikennung beurteilen. Wenn es eine Möglichkeit gibt, via Script eine mime-Type-Angabe zu generieren, wäre das Problem wohl eh sofort gelöst.[list=1][*]Also wenn es da diese Unterscheidung in Ressourcen und Dateien gibt, deren Bedeutung mir so erstmal nicht klar ist: Wenn es wirklich ganz konkret um das Herunterladen von Dateien geht, also daß eine real auf einem Server gespeicherte Datei vom Server auf einen lokalen Datenträger kopiert wird, dann kann ein lokaler Browser doch entscheiden, was für eine Sorte von lokaler Datei das ist, die er da speichert. Wenn er eine Datei mit der Kennung PDF angeboten bekommt, warum sollte er unterschlagen, daß solche Dateien in dem System, unter dem er selbst läuft, als PDF-Dateien registriert sind und standardmäßig (z.B.) mit dem Acrobat Reader geöffnet werden? Spätestens dann, wenn der Download beendet ist, muß ohnehin nur noch das System entscheiden, was es mit der Datei macht, wenn sie z.B. doppelt angeklickt wird. Da hiflt kein möglicherweise irgendwann mal genannter mime-Typ mehr.
          [*]Wie geschrieben, behandelt der Browser die Dateien im Prinzip auch korrekt, wenn ich die Zeile header Content-Type weglasse. Also "weiß" er schon ganz genau anhand der Kennung, was er da herunterzuladen glaubt. Warum er "kaputt" sein soll, wenn er dem User nicht verheimlicht, daß er eine Videodatei oder oder eine Adobe Acrobat-Datei herunterläd, verstehe ich nicht... Spätestens nach dem Download würde einem User eh diese Info zu der Datei gegeben, warum soll ausgerechnet der Browser dem User was anderes erzählen als das restliche System?
          [*]Wenn auf einer primitiven HTML-Seite ein statischer Link auf eine PDF- oder AVI- oder TXT-Datei enthalten ist und man den anklickt, startet der Browser ja auch die im System hinterlegte Anwendung, um die Datei zu öffnen. Da bekommt er nie etwas anderes an Info als "href='xxx.pdf" oder ähnlich und muß ohne mime-Typ selbst entscheiden, was er macht.[/list=1]

          Ich hoffe das war ironisch gemeint, denn sonst habe ich das auch nicht verstanden...:
          und in der letzten der vier Varianten wird ihm die Kennung sogar explizit über header Content-Type übergeben
          Ja, "explizit" als x-type/x-subtype oder application/octet-stream.
          Und welche Anwendung hast du in den Einstellungen deines Firefox mit diesen Content-types verknüpft?
          Außerdem passen das Zitat und die Antwort nicht zusammen:
          Diese letzte der vier Varianten (Zitat) ist
          PHP-Code:
          header("Content-Type: application/".substr(strrchr($datei"."),1)); 
          und da wird die Kennung wirklich explizit übergeben.
          Die Antwort bezieht sich aber auf die zweite und dritte der vier Varianten
          PHP-Code:
          header("Content-Type: x-type/x-subtype");
          header("Content-Type: application/octet-stream"); 


          Aber abgesehen von dem allen jetzt:
          Ich habe keine Browser programmiert und kann nichts dafür, daß sich irgendein Browser so oder so verhält.
          Meine Frage war, ob jemand eine bessere als die 5 von mir beschriebenen Möglichkeiten kennt, für einen solchen "erzwungenen" Download den Content-Type zu übergeben? Ja genau mit dem Sinn, daß das dann besser klappt, daß der Browser die bestmöglichen Infos hat und dem User anzeigt.

          Danke
          Zuletzt geändert von micmen; 06.04.2006, 18:05.

          Kommentar


          • #6
            Original geschrieben von micmen
            Wenn er eine Datei mit der Kennung PDF angeboten bekommt,
            Bekommt er aber nicht - er bekommt eine Ressource angeboten.
            warum sollte er unterschlagen, daß solche Dateien in dem System, unter dem er selbst läuft, als PDF-Dateien registriert sind und standardmäßig (z.B.) mit dem Acrobat Reader geöffnet werden?
            Das wird er genau dann tun, wenn der Server die Ressource mit einem passenden Content-type Header ausliefrt.
            Spätestens dann, wenn der Download beendet ist, muß ohnehin nur noch das System entscheiden, was es mit der Datei macht, wenn sie z.B. doppelt angeklickt wird. Da hiflt kein möglicherweise irgendwann mal genannter mime-Typ mehr.
            Zu dem Zeitpunkt unterhalten wir uns aber nicht mehr über HTTP.
            Warum er "kaputt" sein soll, wenn er dem User nicht verheimlicht, daß er eine Videodatei oder oder eine Adobe Acrobat-Datei herunterläd, verstehe ich nicht...
            Der Browser ist dann als kaputt zu anzusehen, wenn er die Datei als etwas anderes betrachtet, als im Content-type header vom Server angegeben wurde.
            Spätestens nach dem Download würde einem User eh diese Info zu der Datei gegeben, warum soll ausgerechnet der Browser dem User was anderes erzählen als das restliche System?
            Weil es zum Zeitpunkt des Downloads noch keine Datei ist, sondern eine Ressource.
            Etwas anderes gibt es im HTTP-Umfeld nicht!
            Wenn auf einer primitiven HTML-Seite ein statischer Link auf eine PDF- oder AVI- oder TXT-Datei enthalten ist und man den anklickt, startet der Browser ja auch die im System hinterlegte Anwendung, um die Datei zu öffnen.
            Natürlich - weil ihm der Server da idR. per Content-type Header mitteilt, um was es sich handelt.
            Da bekommt er nie etwas anderes an Info als "href='xxx.pdf" oder ähnlich und muß ohne mime-Typ selbst entscheiden, was er macht.
            Doch, in über 99,9% der Fälle dürfte er vom Server mitgeteilt bekommen, um was es sich handelt.
            Diese letzte der vier Varianten (Zitat) ist
            PHP-Code:
            header("Content-Type: application/".substr(strrchr($datei"."),1)); 
            und da wird die Kennung wirklich explizit übergeben.
            Aber bei application/{Dateiendung} dürfte es sich idR. um keinen definierten Mime-Typen handeln.
            Meine Frage war, ob jemand eine bessere als die 5 von mir beschriebenen Möglichkeiten kennt, für einen solchen "erzwungenen" Download den Content-Type zu übergeben? Ja genau mit dem Sinn, daß das dann besser klappt, daß der Browser die bestmöglichen Infos hat und dem User anzeigt.
            Die beste Möglichkeit hast du doch selbst schon genannt:
            Ein einfacher Link auf die Datei, und fertig.

            Ob diese Ressource - die vom Server höchstvermutlich mit einem passenden Mime-Type versendet wird - abzuspeichern, direkt anzuzeigen oder sonst was ist, entscheidet der Browser - und zwar an hand dessen, wie der User ihn konfiguriert hat.
            I don't believe in rebirth. Actually, I never did in my whole lives.

            Kommentar


            • #7
              Hi wahsaga,
              danke für die Antwort, die ganz am Ende dann noch enthalten war.
              Gut, dann streiten wir halt vorher noch über den Sinn oder Unsinn dessen, wie sich ein Browser in bestimmten Situationen benimmt (wofür ich noch immer nicht verantwortlich bin ) - irgendwie muß der Webspace dieses Forums ja genutzt werden:



              Original geschrieben von wahsaga
              Original geschrieben von micmen
              Wenn er eine Datei mit der Kennung PDF angeboten bekommt,
              Bekommt er aber nicht - er bekommt eine Ressource angeboten.
              OK. Da Dein Beitragszähler zur Zeit bei knapp 15000 steht (Respekt), nehme ich an, daß Du Dich gut auskennst und glaube Dir. Ich weiß halt nicht, welche wirklich praktisch bedeutsame Rolle das in genau "unserer" Situation spielt, in der ich den Server via Script anweise, eine Datei von der Festplatte des Servers so an den Browser des Users zu senden, daß sie dort 1:1 als Datei auf dessen Festplatte ankommt (so daß letztendlich also vom realen, praktischen Ergebnis her eine Datei von einer Festplatte auf eine andere kopiert wird), aber mal egal: Zwischendurch ist diese Datei also für kurze Zeit eine Ressource, habe ich verstanden.



              Original geschrieben von wahsaga
              Original geschrieben von micmen
              warum sollte er unterschlagen, daß solche Dateien in dem System, unter dem er selbst läuft, als PDF-Dateien registriert sind und standardmäßig (z.B.) mit dem Acrobat Reader geöffnet werden?
              Das wird er genau dann tun, wenn der Server die Ressource mit einem passenden Content-type Header ausliefrt.
              Hier will ich mal ein Zitat von Dir vorziehen, was erst an späterer Stelle kommt:
              Original geschrieben von wahsaga
              Aber bei application/{Dateiendung} dürfte es sich idR. um keinen definierten Mime-Typen handeln.
              In allen bisher besprochenen 5 Varianten bekommt der Browser vom Server ja gerade keine mime-Typen geliefert, sondern in einem Fall die Dateikennung (die nach unser beider Meinung kein "vollwertiger", definierter mime-Type ist) und in allen 4 anderen Fällen gar nichts.
              Also, wie gesagt, spreche ich hier bei den ganzen Browser-Verhalten von der Situation, in der der Browser selbst herausfinden muß, was er da bekommt, und entscheiden muß, als was er das dem User verkauft.



              Original geschrieben von wahsaga
              Original geschrieben von micmen
              Spätestens dann, wenn der Download beendet ist, muß ohnehin nur noch das System entscheiden, was es mit der Datei macht, wenn sie z.B. doppelt angeklickt wird. Da hiflt kein möglicherweise irgendwann mal genannter mime-Typ mehr.
              Zu dem Zeitpunkt unterhalten wir uns aber nicht mehr über HTTP.
              Ja gut. Aber der Browser ist ja nun eine vom User auf dem System des Users installierte Software und nicht etwa ein Teil "meines" Servers. Er ist mit dem System des Users bei weitem näher verbunden als allem, was ich über den Server beeinflussen kann. Warum soll ein Browser einem fremden Server mehr Bedeutung beimessen, als seinem eigenen System, auf dem "sein" User bestimmt hat, was wie gehandhabt werden soll? Also wenn der Browser "weiß", daß die Datei xxx.avi, die er auf der Festplatte speichert, vom System für alle Zeit (z.B.) mit dem VLC Media Player geöffnet werden soll und wird, warum soll er dann seinem User im Download-Dialog etwas anderes erzählen? Welchen Nutzen sollte der User von dieser Diskrepanz haben? Egal ob Ressource oder Datei, HTTP oder direkter Dateizugriff, ist es für den User doch am dienlichsten, wenn ihm die Datei im Download-Dialog schon als das angezeigt wird, was sie direkt nach dem Download dauerhaft sein wird?
              Und darauf habe ich als Gestalter der Dateien auf dem Server keinerlei Einfluß - für mich ist es doch toll, wenn der Browser sich selbst drum kümmert, dem User das für sein System richtige anzuzeigen?
              Wir sprechen hier ja ausschließlich um das Abspeichern von Dateien auf der Festplatte des Users, nicht um in HTML-Code eingebettete Objekte, die der Browser direkt online verarbeiten und visuell/auditiv ausgeben soll.



              Original geschrieben von wahsaga
              Original geschrieben von micmen
              Warum er "kaputt" sein soll, wenn er dem User nicht verheimlicht, daß er eine Videodatei oder oder eine Adobe Acrobat-Datei herunterläd, verstehe ich nicht...
              Der Browser ist dann als kaputt zu anzusehen, wenn er die Datei als etwas anderes betrachtet, als im Content-type header vom Server angegeben wurde.
              Darüber habe ich mir noch nie Gedanken gemacht, aber klar, kann man so sehen und macht auch Sinn, da will ich gar nicht widersprechen (und habe ich auch nie getan): Solange die Bauer von Auftritten keinen Mist verzapfen, ist es am besten so, wenn sie über den mime-Type das Verhalten des Browsers steuern können.



              Original geschrieben von wahsaga
              Original geschrieben von micmen
              Spätestens nach dem Download würde einem User eh diese Info zu der Datei gegeben, warum soll ausgerechnet der Browser dem User was anderes erzählen als das restliche System?
              Weil es zum Zeitpunkt des Downloads noch keine Datei ist, sondern eine Ressource.
              Etwas anderes gibt es im HTTP-Umfeld nicht!
              Naja, in meinen Augen spielt dieser Aspekt in dieser Situation keine Rolle, siehe zwei Punkte höher:
              Der Download dauert eine kurze Zeit, danach liegt die vom Server gesandte Datei ewig auf der Festplatte des Users. Warum sollte den kurzen Moment vor dem Download für die Datei eine andere Information angezeigt werden, als vom System die gesamte Zeit danach? Welchen Vorteil soll es für den User ergeben, wenn man Browser so "verwirrend" programmieren würde? Wie gesagt, hier geht es nur um Downloads, das Erzeugen einer real auf der Festplatte des Users gespeicherten Datei.



              Original geschrieben von wahsaga
              Original geschrieben von micmen
              Wenn auf einer primitiven HTML-Seite ein statischer Link auf eine PDF- oder AVI- oder TXT-Datei enthalten ist und man den anklickt, startet der Browser ja auch die im System hinterlegte Anwendung, um die Datei zu öffnen.
              Natürlich - weil ihm der Server da idR. per Content-type Header mitteilt, um was es sich handelt.
              und:
              Original geschrieben von wahsaga
              Original geschrieben von micmen
              Da bekommt er nie etwas anderes an Info als "href='xxx.pdf" oder ähnlich und muß ohne mime-Typ selbst entscheiden, was er macht.
              Doch, in über 99,9% der Fälle dürfte er vom Server mitgeteilt bekommen, um was es sich handelt.
              Das ist jetzt eine neue Sache für mich, diesen Mechanismus kenne ich noch nicht. Im HTML-Quelltext steht ja nichts davon, da steht ja nur "href='xxx.PDF'", so wie sonst "href='xxx.HTML'" oder "href='xxx.PHP'" o.ä. steht? Wie erhält der Browser denn vom Server die Info über den zu jedem Link gehörigen mime-Type?







              OK
              Das alles hatte mit dem Thema meines Threads rein gar nix zu tun. Ich hatte da eine Frage nach Verbesserungsmöglichkeiten für mein Script gestellt und den Grund dafür beschrieben, warum mir meine bislang getesteten Lösungen nicht gefallen: Nämlich, weil sich der Browser nicht so verhält, wie ich es mir wünschen würde.
              Ich habe das Verhalten des Browsers nur neutral beschrieben, ohne zu bewerten, ob ich das Verhalten bezogen auf die jeweiligen Scriptbefehle nun gut oder schlecht finde.


              Original geschrieben von wahsaga
              Original geschrieben von micmen
              Meine Frage war, ob jemand eine bessere als die 5 von mir beschriebenen Möglichkeiten kennt, für einen solchen "erzwungenen" Download den Content-Type zu übergeben? Ja genau mit dem Sinn, daß das dann besser klappt, daß der Browser die bestmöglichen Infos hat und dem User anzeigt.
              Die beste Möglichkeit hast du doch selbst schon genannt:
              Ein einfacher Link auf die Datei, und fertig.

              Ob diese Ressource - die vom Server höchstvermutlich mit einem passenden Mime-Type versendet wird - abzuspeichern, direkt anzuzeigen oder sonst was ist, entscheidet der Browser - und zwar an hand dessen, wie der User ihn konfiguriert hat.
              In dem, was Du von mir zitierst, steht "erzwungener" Download und darum geht es halt. Ein einfacher Link kann das nicht leisten.
              Soll ich diese Antwort so interpretieren, daß es am besten ist, die Zeile mit dem header Content-Type wegzulassen?

              Ich hatte gehofft, daß es (mindestens) eine von zwei Lösungswegen gibt:[list=1][*]daß es für header Content-Type einen allgemeinen Wert (wie "x-type/subtype", "x-type/x-subtype" oder "application/octet-stream") gibt, der den Browser fest anweist, immer so zu verfahren, wie es im System gemäß Dateikennung registriert ist[*]oder daß es eine Möglichkeit gibt, per Script auf Basis der Dateikennung den richtigen Wert nach Muster "image/gif" zusammenzubauen[/list=1]Letzteres muß wohl irgendwie möglich sein - habe da mal was gelesen von "PECL extension fileinfo" oder auch von einer Datei "magic.mime" und einer Funktion mime_content_type(), die auf Infos in dieser Datei zugreift (?).


              danke nochmal
              Zuletzt geändert von micmen; 07.04.2006, 13:12.

              Kommentar


              • #8
                Original geschrieben von micmen
                Warum soll ein Browser einem fremden Server mehr Bedeutung beimessen, als seinem eigenen System, auf dem "sein" User bestimmt hat, was wie gehandhabt werden soll?
                Er hat vom fremden Server eine Ressource angefordert.
                Wenn er Server ihm sagt, "diese Ressource ist vom Typ xy" - warum sollte er ihm das nicht erstmal glauben?
                Also wenn der Browser "weiß", daß die Datei xxx.avi, die er auf der Festplatte speichert, vom System für alle Zeit (z.B.) mit dem VLC Media Player geöffnet werden soll und wird, warum soll er dann seinem User im Download-Dialog etwas anderes erzählen?
                Der Browser weiß es nicht, wenn er keinen korrekten Content-type vom Server mitgeteilt bekommt.

                Du versuchst ihm "Content-Type: application/octet-stream" zu geben - "OK, das kann irgendwas sein, genauer weiß ich es nicht, als biete ich das dem Benutzer erst mal zum Speichern an".
                Egal ob Ressource oder Datei, HTTP oder direkter Dateizugriff, ist es für den User doch am dienlichsten, wenn ihm die Datei im Download-Dialog schon als das angezeigt wird, was sie direkt nach dem Download dauerhaft sein wird?
                <gebetsmühle>
                Es ist noch keine Datei, sondern lediglich eine Ressource.
                </gebetsmühle>

                Dass diese angeblich einen bestimmten Dateinamen und -endung haben soll, interessiert im HTTP-Umfeld noch niemanden, darf niemanden interessieren.
                Namen sind in diesem Umfeld Schall und Rauch.
                für mich ist es doch toll, wenn der Browser sich selbst drum kümmert, dem User das für sein System richtige anzuzeigen?
                Sein System wird ihm nachher "das Richtige" anzeigen - sobald daraus eine Datei geworden ist, die im Dateisystem abgespeichert ist. Dann nutzt das System seine Möglichkeiten heruaszufinden, um was es sich handeln könnte - in dem es beispielsweise wie Windows das tut auf Grund der Dateiendung rät.

                Naja, in meinen Augen spielt dieser Aspekt in dieser Situation keine Rolle, siehe zwei Punkte höher:
                Der Download dauert eine kurze Zeit, danach liegt die vom Server gesandte Datei ewig auf der Festplatte des Users. Warum sollte den kurzen Moment vor dem Download für die Datei eine andere Information angezeigt werden, als vom System die gesamte Zeit danach?
                Weil sie zu diesem Zeitpunkt noch keine "Datei" ist, und du auch keine Zeitmaschine hast, die daran etwas ändern kann.

                Das ist jetzt eine neue Sache für mich, diesen Mechanismus kenne ich noch nicht. Im HTML-Quelltext steht ja nichts davon, da steht ja nur "href='xxx.PDF'", so wie sonst "href='xxx.HTML'" oder "href='xxx.PHP'" o.ä. steht? Wie erhält der Browser denn vom Server die Info über den zu jedem Link gehörigen mime-Type?
                Wenn die angeforderte Ressource im Dateisystem des Servers auf eine reale Datei gemappt wird - dann schaut sich auf der Webserver die Endung an, und schaut in seiner Konfiguration nach, welchen Mime-Type er dafür als Content-type angeben soll.

                Ich hatte gehofft, daß es (mindestens) eine von zwei Lösungswegen gibt: daß es für header Content-Type einen allgemeinen Wert (wie "x-type/subtype", "x-type/x-subtype" oder "application/octet-stream") gibt, der den Browser fest anweist, immer so zu verfahren, wie es im System gemäß Dateikennung registriert ist
                Es ist noch keine Datei zu dem Zeitpunkt, wo der Browser die Daten empfängt ...
                oder daß es eine Möglichkeit gibt, per Script auf Basis der Dateikennung den richtigen Wert nach Muster "image/gif" zusammenzubauen
                Natürlich wäre es das - aber was macht dein Browser mit Ressourcen vom Typ image/gif?
                Richtig, er zeigt sie direkt an - es sei denn, du hättest ihn für diesen Typ anders konfiguriert, dass er es zum Abspeichern anbieten soll o.ä.
                Dann würde er aber auch jegliches Gif-Bild, welches in einem HTML-Dokument über <img> eingebunden ist, zum Abspeichern anbieten - logisch, oder?

                In dem, was Du von mir zitierst, steht "erzwungener" Download und darum geht es halt.
                Und die Möglichkeit dazu kennst du bereits:
                Sende dem Browser irgendeinen Content-type, den er nicht kennt, für den der Nutzer also höchstvermutlich noch keine Einstellung getroffen hat, wie er zu behandeln ist.
                Ja, dann wird ein gängiger Browser den Nutzer fragen, was er damit machen will - Abspeichern zum Beispiel.
                Ein einfacher Link kann das nicht leisten.
                Beim Klick auf einen einfachen Link, auf den hin der Server die Ressource mit dem wirklich passenden Content-type ausliefert, wird das passieren, was ich in meinem Browser eingestellt habe - ein PDF zum Beispiel wird er mir zum Herunterladen anbieten, weil ich es hasse, wenn diese Dinger im Browser selbst per Plugin dargestellt werden.
                Ein andere mag vielleicht das Plugin, also hat er seinen Browser entsprechend anders eingestellt.

                Somit sind hier eigentlich beide Nutzer glücklich - nur der Seitenersteller vielleicht nicht. Weil der noch nicht eingesehen hat, dass es nicht an ihm ist zu "Erzwingen", wie eine Ressource auf dem Client behandelt wird.

                Soll ich diese Antwort so interpretieren, daß es am besten ist, die Zeile mit dem header Content-Type wegzulassen?
                Nein, sondern so, dass du die Ressource am besten mit dem passend(st)en Content-type auslieferst - und dem Browser bzw. seinem Nutzer die Entscheidung darüber überlässt, wie damit zu verfahren ist.

                Ja, die Möglichkeit des "Erzwingens" hast du wie beschrieben (in geringem Umfang) - in dem du einen anderen, unpassenden Content-type wählst, mit dem der Browser höchstwahrscheinlich nichts anzufangen weiß.
                Aber dann darfst du natürlich nicht erwarten, dass bereits vor dem Ablegen im Dateisystem eine Zuordnung zur "richtigen" Anwendung erfolgt - weil der Browser dafür idR. keine "zuständige" kennt.


                Also entscheide dich, was von beidem du willst.
                Mein Vorschlag steht ja nun mehrmals da - liefere die Ressource korrekt aus, und überlasse die Entscheidung dem Nutzer.
                Und halte den Nutzer bitte nicht pauschal für zu dämlich, eine Ressource abzuspeichern, wenn er das will.
                Falls deine Nutzer das erwiesener (oder vermuteter) Maßen aber doch sein sollten - dann hilft eigentlich wirklich nur Aufklärung, wie sie mit ihrem Browser richtig umgehen, damit er das macht, was sie wollen.
                I don't believe in rebirth. Actually, I never did in my whole lives.

                Kommentar


                • #9
                  Hi wahsaga,
                  also am Ende liest das hier noch ein anderer außer uns beiden und wir wollen es vielleicht nicht übertreiben

                  Meiner Ansicht nach spielt es in der Situation, daß ein Browser einen Download-Dialog öffnet, um eine auf der Festplatte (oder sonstwo) gespeicherte Datei zu erzeugen, absolut keine Rolle, ob Datei oder Ressource oder weiß der Geier was auch immer. Und der Programmierer des Browser braucht auch keine Zeitmaschine, um zu ahnen, daß dieser Download-Dialog dahin münden wird, daß auf der Festplatte des Users (oder woanders) eine Datei angelegt wird. Und der, der den Browser programmiert, weiß, daß das System des Users nach dem Download bestimmt, wie diese Datei gehandhabt wird. Und wenn der Server in dieser Situation keine Info zum mime-Type der Ressource liefert, so ist es für den User meiner Ansicht nach naheliegend, daß der Browser-Programmierer dafür sorgt, daß der Browser auch im Download-Dialog schon die herunterzuladende Datei dem User entsprechend anzeigt, wie es auch danach immer wieder dem Verhalten seines Systems entspricht. Also statt "AVI-Datei" etwas wie "VLC Video" oder irgendwas in der Art - wie's halt auch im System heißt.
                  Der Programmierer des Browser weiß, warum er in welcher Situation seinen Browser einen Download-Dialog öffnen läßt, und ohne hellseherische Fähigkeiten kann der Browser-Programmierer absehen, daß der User hinterher eine Datei auf der Platte (oder wo) haben wird, die ihm sein System als (in dem Beispiel) AVI-Datei anzeigen wird.
                  Alles in der Situation, daß der Browser vom Server über die Ressource keinerlei Info bekommt, also nur aufgrund der Kennung im Namen der Ressource entscheiden muß - denn keine der 5 von mir getesteten Möglichkeiten liefert etwas besseres.
                  Der Browser kann ja tatsächlich die "Dateikennung der Ressource" erkennen/verarbeiten, das haben meine Tests ja ergeben.





                  Original geschrieben von wahsaga
                  Original geschrieben von micmenWarum soll ein Browser einem fremden Server mehr Bedeutung beimessen, als seinem eigenen System, auf dem "sein" User bestimmt hat, was wie gehandhabt werden soll?
                  Er hat vom fremden Server eine Ressource angefordert.
                  Wenn er Server ihm sagt, "diese Ressource ist vom Typ xy" - warum sollte er ihm das nicht erstmal glauben?
                  Ja, stimmt, da hast Du eigentlich Recht. Ändere ich meine Meinung: Wenn der Server eine solche Info liefert (dafür habe ich im Moment noch keine Lösung), sollte die beim Browser tatsächlich Vorrang haben.
                  Zu dem Fall hatte (und habe) ich mangels Lösung noch keine praktische Erfahrung und da habe ich aus dem Stehgreif was losgeschrieben, was eigentlich unsinnig ist - da hast Du Recht.




                  Original geschrieben von wahsaga
                  Wenn die angeforderte Ressource im Dateisystem des Servers auf eine reale Datei gemappt wird - dann schaut sich auf der Webserver die Endung an, und schaut in seiner Konfiguration nach, welchen Mime-Type er dafür als Content-type angeben soll.
                  Wie genau kann ich den Server denn dazu bringen?




                  Original geschrieben von wahsaga
                  Original geschrieben von micmenIn dem, was Du von mir zitierst, steht "erzwungener" Download und darum geht es halt.
                  Und die Möglichkeit dazu kennst du bereits:
                  Sende dem Browser irgendeinen Content-type, den er nicht kennt, für den der Nutzer also höchstvermutlich noch keine Einstellung getroffen hat, wie er zu behandeln ist.
                  Ja, dann wird ein gängiger Browser den Nutzer fragen, was er damit machen will - Abspeichern zum Beispiel.
                  (.....)
                  Original geschrieben von wahsagaBeim Klick auf einen einfachen Link, auf den hin der Server die Ressource mit dem wirklich passenden Content-type ausliefert, wird das passieren, was ich in meinem Browser eingestellt habe - ein PDF zum Beispiel wird er mir zum Herunterladen anbieten, weil ich es hasse, wenn diese Dinger im Browser selbst per Plugin dargestellt werden.
                  Ein andere mag vielleicht das Plugin, also hat er seinen Browser entsprechend anders eingestellt.

                  Somit sind hier eigentlich beide Nutzer glücklich - nur der Seitenersteller vielleicht nicht. Weil der noch nicht eingesehen hat, dass es nicht an ihm ist zu "Erzwingen", wie eine Ressource auf dem Client behandelt wird.
                  Das sind zwei Sachen:[list=1][*]Ja, ich will/muß/sollte bei den betroffenen Links einen Download erzwingen und im Interesse der User verhindern, daß deren Browser versuchen könnte, die Datei online zu öffnen.
                  Aber trotzdem soll dem User ja im Download-Dialog schon angezeigt werden, was für einen Typ von Datei er da gerade runterzuladen im Begriff ist, darüber sprechen wir ja die ganze Zeit...[*]Ich biete den Usern auf der Seite tatsächlich ausdrücklich Downloads an. Also den Service, daß sie sich bestimmte Dateien auf die Festplatte holen können. Ich schreibe nicht, daß sie sich Sachen ansehen/anhören können, sondern da geht es tatsächlich ausschließlich um den Download von Dateien.
                  Und ich kann nicht davon ausgehen, daß die User irgendwie mit Rechnern oder Internet vertraut sind. Vielleicht haben sie es mit Ach und Krach geschafft, meine Downloadseite zu finden, und wollen jetzt die zugesagten Dateien haben. Wenn ich da z.B. eine PDF-Datei anbiete (davon habe ich definitiv mehrere), muß ich verhindern, daß der ahnungslose User mit seinem Standard-IE statt des Downloads so, wie Du es offensichtlich auch kennst , ein nervtötendes Gegakel im Browser geboten bekommt. Der hat im Moment mit größter Wahrscheinlichkeit gar keine Lust, das zu lesen, er braucht das Material irgendwann später - möglicherweise zu einem Zeitpunkt, zu dem ich es auf dem Server gar nicht mehr anbiete. Wenn ich den Usern dann mit einer ewig langen Doku komme, was alles zu tun ist, damit die Datei irgendwann endlich auf seinem Rechner ist, wird er möglicherweise überfordert oder verärgert sein. Denn das ufert ganz schön aus: "falls Sie den InternetExplorer unter Windows benutzen, klicken Sie mit der rechten Maustaste und wählen 'Ziel speichern unter'. Wenn sie den InternetExplorer unter MacOs benutzen, klicken Sie den Link bei gedrückter Apfel-Taste an und" ..."Wenn Sie den NetscapeNavigator unter Windows..."

                  Es geht also echt nicht darum, daß ich etwas nicht einsehe, sondern wirklich um Userfreundlichkeit - ich verspreche ganz ausdrücklich "Downloads" und will sicherstellen, daß die User so, wie sie es erwarten, auch diesen zugesagten Service bekommen, und nicht eventuell irgendwelches Gehampel in ihrem Browserfenster.[/list=1]



                  Original geschrieben von wahsaga
                  Original geschrieben von micmen
                  oder daß es eine Möglichkeit gibt, per Script auf Basis der Dateikennung den richtigen Wert nach Muster "image/gif" zusammenzubauen
                  Natürlich wäre es das - aber was macht dein Browser mit Ressourcen vom Typ image/gif?
                  Richtig, er zeigt sie direkt an - es sei denn, du hättest ihn für diesen Typ anders konfiguriert, dass er es zum Abspeichern anbieten soll o.ä.
                  Dann würde er aber auch jegliches Gif-Bild, welches in einem HTML-Dokument über <img> eingebunden ist, zum Abspeichern anbieten - logisch, oder?
                  Bei "per Script auf Basis der Dateikennung den richtigen Wert zusammenzubauen" sprach ich ja davon, daß in meinem erzwungenen Download die Zeile header Content-Type hinten den richtigen mime-Type eingetragen hat. Und nach allem, was ich weiß (zu wissen glaube?), sorgt doch die Zeile
                  PHP-Code:
                  header("Content-Disposition: attachment; filename=".$datei); 
                  dafür, daß der Browser in jedem Fall den Download-Dialog öffnet, unabhängig von seinem Standardhandler für den jeweiligen mime-Type?
                  Oder liege ich da falsch?




                  Original geschrieben von wahsaga
                  Original geschrieben von micmen
                  Soll ich diese Antwort so interpretieren, daß es am besten ist, die Zeile mit dem header Content-Type wegzulassen?
                  Nein, sondern so, dass du die Ressource am besten mit dem passend(st)en Content-type auslieferst - und dem Browser bzw. seinem Nutzer die Entscheidung darüber überlässt, wie damit zu verfahren ist.

                  Ja, die Möglichkeit des "Erzwingens" hast du wie beschrieben (in geringem Umfang) - in dem du einen anderen, unpassenden Content-type wählst, mit dem der Browser höchstwahrscheinlich nichts anzufangen weiß.
                  Aber dann darfst du natürlich nicht erwarten, dass bereits vor dem Ablegen im Dateisystem eine Zuordnung zur "richtigen" Anwendung erfolgt - weil der Browser dafür idR. keine "zuständige" kennt.

                  Also entscheide dich, was von beidem du willst.
                  Mein Vorschlag steht ja nun mehrmals da - liefere die Ressource korrekt aus, und überlasse die Entscheidung dem Nutzer.
                  Und halte den Nutzer bitte nicht pauschal für zu dämlich, eine Ressource abzuspeichern, wenn er das will.
                  Falls deine Nutzer das erwiesener (oder vermuteter) Maßen aber doch sein sollten - dann hilft eigentlich wirklich nur Aufklärung, wie sie mit ihrem Browser richtig umgehen, damit er das macht, was sie wollen.
                  Es geht hier echt darum, daß ich den Usern etwas fest verspreche: "Geht in's Internet auf die und die Seite, dort könnt Ihr Euch die und die und die Datei herunterladen". Und von dämlich sagt keiner was - vielleicht sind das die größten Asse auf irgendwelchen anderen Gebieten, nur mit PCs hatten sie in ihrem Leben kaum je zu tun. Also da sind Leute dabei, die gehen vielleicht extra für diese Datei, die sie brauchen, zum ersten Mal in ihrem Leben auf eine Downloadseite. Die erwarten dann echt, daß das ohne Probleme vonstatten geht. Und das können und sollen sie auch erwarten.


                  Tja...

                  Kommentar

                  Lädt...
                  X