selfuser: Download einer PDF-Datei sicherstellen

Hallo,

Wie kann man erreichen, dass beim Klicken auf eine verlinkte PDF-Datei (via "Download" button) wirklich ein Download erfolgt, anstatt dass die PDF-Datei nur im Browser angezeigt wird?

Kann es sein, dass dies davon abhängt auf welchem Server sie sich befindet, und welche Einstellungen auf diesem Server aktiv sind?

Vielen Dank!

  1. Lieber selfuser,

    Wie kann man erreichen, dass beim Klicken auf eine verlinkte PDF-Datei (via "Download" button) wirklich ein Download erfolgt, anstatt dass die PDF-Datei nur im Browser angezeigt wird?

    das erreichst Du, indem Du dem Browser vorgaukelst, er hätte garantiert kein passendes Plugin, um diese Datei selbst zu verarbeiten.

    Kann es sein, dass dies davon abhängt auf welchem Server sie sich befindet, und welche Einstellungen auf diesem Server aktiv sind?

    Ja, es hängt von den Einstellungen ab. Wenn der Server die Datei mit einem falschen MIME-Typ ausgibt (also z.B. "application/octet-stream" anstatt "application/pdf"), dann "weiß" der Browser nicht, mit welchem verarbeitenden Programm/Plugin sich diese Datei anzeigen ließe und blendet dafür den Download-Dialog ein.

    Verwendest Du eine Script-Sprache auf dem Server, mit der Du Dateien bei passenden Requests mit diesem MIME-Typ ausliefern lassen könntest?

    Liebe Grüße,

    Felix Riesterer.

    --
    "Wäre die EU ein Staat, der die Aufnahme in die EU beantragen würde, müsste der Antrag zurückgewiesen werden - aus Mangel an demokratischer Substanz." (Martin Schulz, Präsident des EU-Parlamentes)
    1. Hallo Felix,

      Danke für die schnelle Antwort!

      Kann es sein, dass dies davon abhängt auf welchem Server sie sich befindet, und welche Einstellungen auf diesem Server aktiv sind?

      Ja, es hängt von den Einstellungen ab. Wenn der Server die Datei mit einem falschen MIME-Typ ausgibt (also z.B. "application/octet-stream" anstatt "application/pdf"), dann "weiß" der Browser nicht, mit welchem verarbeitenden Programm/Plugin sich diese Datei anzeigen ließe und blendet dafür den Download-Dialog ein.

      Verwendest Du eine Script-Sprache auf dem Server, mit der Du Dateien bei passenden Requests mit diesem MIME-Typ ausliefern lassen könntest?

      Es handelt sich um einen "Business Plan" von HostGator (http://www.hostgator.com/shared) mit cPanel (habe dort bisher nur mit Addon-Domains, Sub-Domains und Wordpress-Installation experimentiert).

      Ich verwende also keine Script-Sprache (wüsste auch nicht wie), sondern habe bisher den PDF-Downlaod nur mit einer einfachen HTML-Datei getestet und das beschriebene, unerwünschte Verhalten festgestellt. Demnächst möchte ich eine fertige Seite (kreiert auf http://www.leadpages.net) in Verbindung mit dem HostGator-Account verwenden, wo der Download sicher funktionieren soll.

      Am besten wäre es, wenn man dafür eine globale Einstellung ändern könnte.

      Nochmals vielen Dank für die Hilfe!

      1. hi,

        Am besten wäre es, wenn man dafür eine globale Einstellung ändern könnte.

        Setz doch einen Handler in die .htaccess falls das möglich ist.

        MfG

        1. Hallo hotti,

          Danke für den Vorschlag:

          Setz doch einen Handler in die .htaccess falls das möglich ist.

          Soweit ich weiß ist das eine hidden Datei, die z.B. für Forwarding verwendet wird, oder?

          Ich hatte mit einer solchen Datei noch nie zu tun. Was müsste denn genau drin stehen?

          Ich habe CuteFTP - damit sollte es doch möglich sein eine solche Datei zu platzieren...?

    2. Moin Moin!

      Wie kann man erreichen, dass beim Klicken auf eine verlinkte PDF-Datei (via "Download" button) wirklich ein Download erfolgt, anstatt dass die PDF-Datei nur im Browser angezeigt wird?

      das erreichst Du, indem Du dem Browser vorgaukelst, er hätte garantiert kein passendes Plugin, um diese Datei selbst zu verarbeiten.

      Klar, das ist der brutale Weg. Man erfindet immer neue MIME-Typen, bis irgendwann jemand dem Browser beibringt, anhand der URL oder der ersten paar Bytes des Downloads zu raten, dass es eine anzeigbare PDF-Datei ist. Womit wir dann so ungefähr beim Internet Explorer 4 wären.

      Der saubere Weg ist der Content-Disposition-Header, siehe RFC2616. "Content-Disposition: attachment" teilt dem Browser mit, dass der Server die jeweilige Resource nicht angezeigt, sondern gespeichert haben möchte. Bislang habe ich noch keinen Browser gesehen, der diesen Hinweis ignoriert. Das Gegenteil wäre übrigens "Content-Disposition: inline", damit teilt der Server dem Browser mit, dass die jeweilige Resource nach Möglichkeit direkt angezeigt werden soll.

      Alexander

      --
      Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so".
      1. Hallo Alexander,

        Der saubere Weg ist der Content-Disposition-Header, ...

        kann man den auch per .htaccess setzen? Und wenn ja, wie?

        Gruß, Jürgen

        1. Hi,

          Der saubere Weg ist der Content-Disposition-Header, ...

          kann man den auch per .htaccess setzen? Und wenn ja, wie?

          Mittels Header-Direktive, ggf. gekapselt in <Files>.

          MfG ChrisB

          --
          Kids these days just don’t get ASCII art any more – it’s all UTF-this and Unicode-that with those youngsters …
          1. Hallo ChrisB,

            danke.

            Gruß, Jürgen

          2. Hallo Chris,

            Der saubere Weg ist der Content-Disposition-Header, ...

            kann man den auch per .htaccess setzen? Und wenn ja, wie?

            Mittels Header-Direktive, ggf. gekapselt in <Files>.

            Ich habe nun lange nach einer Lösung für .htaccess gesucht und folgendes gefunden:

            | <Files *.pdf> |   ForceType application/octet-stream |   Header set Content-Disposition attachment | </Files>

            Ist das korrekt und würde das funktionieren?

            Alternativ, für 2 Datei-Arten, wäre folgendes richtig (ersetzt die 1. Zeile):

            | <FilesMatch ".(pdf|mp4)$"> ...

            Danke nochmals!

            1. Moin Moin!

              Der saubere Weg ist der Content-Disposition-Header, ...

              kann man den auch per .htaccess setzen? Und wenn ja, wie?

              Mittels Header-Direktive, ggf. gekapselt in <Files>.

              Ich habe nun lange nach einer Lösung für .htaccess gesucht und folgendes gefunden:

              | <Files *.pdf> |   ForceType application/octet-stream

              Falsch. Der MIME-Typ für PDFs ist application/pdf. Es gibt keinen Grund, daran etwas zu ändern. Laß die Zeile einfach weg. Der Apache sollte schon wissen, mit welchem MIME-Type PDFs auszuliefern sind.

              |   Header set Content-Disposition attachment

              Den Wert würde ich sicherheitshalber quoten, ist aber wahrscheinlich optional. Also: Header set Content-Disposition "attachment"

              | </Files>

              Ist das korrekt

              MIME-Type nein, C-D-Header vermutlich ja.

              und würde das funktionieren?

              Was spricht dagegen, es einfach auszuprobieren?

              Alternativ, für 2 Datei-Arten, wäre folgendes richtig (ersetzt die 1. Zeile):

              | <FilesMatch ".(pdf|mp4)$">

              Wenn Du die ForceType-Zeile wegläßt, ja.

              Vorausgesetzt natürlich, alle Dateinamen enden mit Kleinbuchstaben. Wenn Du x.pdf, y.PDF und z.Pdf hast und alle zum Download anbieten willst, mußt Du im ersten Fall von <Files *.pdf> auf <FilesMatch "\.(?i:pdf)$"> umstellen und im zweiten Fall die RegExp analog auf case insensitive umstellen (<FilesMatch "\.(?i:pdf|mp4)$">).

              Alexander

              --
              Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so".
              1. Danke, Alexander, für die Kommentare.

                Die Zeile "ForceType application/octet-stream" hatte ich eingebaut, weil ich gelesen hatte sie wäre für ältere Browser nötig. Kann sie denn schaden?

                Ich verwende zwar nur Kleinbuchstaben bei den pdfs und mp4s, aber schreibe dann sicherheitshalber lieber "<FilesMatch ".(?i:pdf|mp4)$">".

                Der Abschluss heißt dann logischerweise "</FilesMatch>", richtig?

                1. Moin Moin!

                  Die Zeile "ForceType application/octet-stream" hatte ich eingebaut, weil ich gelesen hatte sie wäre für ältere Browser nötig.

                  Das wären dermaßen alte Relikte, dass sie nur HTTP/1.0 beherrschen. Damit funktionieren auch Name-based Virtual Hosts nicht, sprich: nur eine Domain pro IP-Adresse. Sowas dürfte in freier Wildbahn angesichts der großen Anzahl von Shared-Hosting-Angeboten gründlich ausgerottet sein. Die paar Hardcore-User, die so etwas noch einsetzen, wissen, dass sie mit Problemen rechnen müssen.

                  Kann sie denn schaden?

                  Prinzipiell schon. Mit application/pdf weiß mein imaginäres MIME-Type-basierendes Betriebssystem, dass da gleich eine PDF-Datei kommt, kann mir beim Save-As-Dialog gleich die passenden Icons und Optionen für PDF-Dateien anzeigen. Bei application/octet-stream heißt die Ansage "Binärmüll", entsprechend kann mein imaginäres Betriebssystem nur Icons und Optionen für Binärmüll anbieten. Und schlimmer noch: Da mein imaginäres Betriebssystem auch den MIME-Type speichert, muß ich nach dem Speichern nochmal manuell ran und die Datei von Binärmüll auf PDF umtypisieren, weil das System sonst nur meckert, dass es unspezifischen Binärmüll nicht öffnen kann.

                  Ganz frei erfunden ist das nicht, ganz im Gegenteil. Viele Betriebssysteme speichern zu Dateien zusätzlich Metadaten, und repräsentieren und handhaben anhand dieser die Dateien unterschiedlich. Der bekannteste Vertreter dürfte das klassische MacOS und auch die ersten paar Versionen von MacOS X mit seinen Creator Codes sein. Nur, dass MacOS eben nicht direkt MIME-Typen, sondern 32-Bit-Integer benutzt.

                  Davon abgesehen könnten ein paar Proxies mit Firewall-Ansätzen auch "nervös" werden, wenn Du ihnen angeblichen Binärmüll anfütterst. Im blödsten Fall schlägt irgendeine schwachsinnige Paranoia-Regel zu und blockiert den Download. Frei nach dem Motto application/octet-stream == EXE-Datei == Böse Malware. Das denke ich mir definitiv nicht aus, mit so einem Schwachsinn habe ich mich schon rumschlagen dürfen. Out-of-the-box ist wohl kein Proxy so konfiguriert, aber auf dem Layer 8 passieren die merkwürdigsten Dinge.

                  Ich verwende zwar nur Kleinbuchstaben bei den pdfs und mp4s, aber schreibe dann sicherheitshalber lieber "<FilesMatch ".(?i:pdf|mp4)$">".

                  Ja.

                  Der Abschluss heißt dann logischerweise "</FilesMatch>", richtig?

                  Korrekt.

                  Alexander

                  --
                  Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so".
                  1. Hallo Alexander,

                    Die Zeile "ForceType application/octet-stream" hatte ich eingebaut, weil ich gelesen hatte sie wäre für ältere Browser nötig.

                    Das wären dermaßen alte Relikte, dass sie nur HTTP/1.0 beherrschen. Damit funktionieren auch Name-based Virtual Hosts nicht, sprich: nur eine Domain pro IP-Adresse. Sowas dürfte in freier Wildbahn angesichts der großen Anzahl von Shared-Hosting-Angeboten gründlich ausgerottet sein. Die paar Hardcore-User, die so etwas noch einsetzen, wissen, dass sie mit Problemen rechnen müssen.

                    Kann sie denn schaden?

                    Prinzipiell schon...

                    OK ich habe die Zeile nun entfernt und es scheint gut zu funktionieren. (getestet auf Mac mit Safari.)

                    Danke nochmals! Nettes Forum hier übrigens... :) (ich hatte meine erste Begegnung mit SelfHTML 1999)

      2. Hi there,

        Der saubere Weg ist der Content-Disposition-Header, siehe RFC2616. "Content-Disposition: attachment" teilt dem Browser mit, dass der Server die jeweilige Resource nicht angezeigt, sondern gespeichert haben möchte.

        Hm. Wikipedia ist da (in Bezug auf "sauber") anderer Ansicht: "Mit diesem nicht standardisierten und als gefährlich eingestuften Feld kann der Server für bestimmte MIME-Typen Downloadfenster erzeugen und einen Dateinamen vorschlagen."...

        1. Moin Moin!

          Der saubere Weg ist der Content-Disposition-Header, siehe RFC2616. "Content-Disposition: attachment" teilt dem Browser mit, dass der Server die jeweilige Resource nicht angezeigt, sondern gespeichert haben möchte.

          Hm. Wikipedia ist

          ... ein großer Haufen Text mit stark variierender Qualität. Aus welchem Artikel zitierst Du hier?

          da (in Bezug auf "sauber") anderer Ansicht: "Mit diesem nicht standardisierten und als gefährlich eingestuften Feld kann der Server für bestimmte MIME-Typen Downloadfenster erzeugen und einen Dateinamen vorschlagen."...

          Das ist ja großartiger Murks.

          1. Der Server kann das Herunterladen für jede x-beliebige Resource vorschlagen, unabhängig vom MIME-Typ. Entscheidend ist der Content-Disposition-Header.

          2. Wer hat das "Feld" als "gefährlich" eingestuft? Welches Feld übrigens? C-D ist ein HTTP-Header, kein Feld, um mal ein paar Erbsen zu zählen.

          3. Nicht standardisiert? Hmmm, tatsächlich. In RFC2616 steht unter "15.5 Content-Disposition Issues" folgendes: "RFC 1806 [35], from which the often implemented Content-Disposition (see section 19.5.1) header in HTTP is derived, has a number of very serious security considerations. Content-Disposition is not part of the HTTP standard, but since it is widely implemented, we are documenting its use and risks for implementors. See RFC 2183 [49] (which updates RFC 1806) for details." Die Risiken beziehen sich tatsächlich nur auf die Dateinamen, siehe unten.

          4. Was bitteschön ist gefährlich daran, eine Resource zum Speichern vorzuschlagen? Der Server KANN einen abweichenden Dateinamen VORSCHLAGEN, muß er aber nicht. In wie weit sich der Client (Browser) daran hält, ist dessen Problem. Kein halbwegs sauberer Browser wird Pfadangaben vom Server annehmen, allerhöchstens den Dateinamen. Und kein halbwebs sauberes Betriebssystem wird einen Standard-Benutzer systemrelevante Dateien überschreiben lassen.

          Die Angriffsmöglichkeiten in RFC2183 beziehen sich auf Unixe, und sind ziemlich blauäugig:

          +    Creating startup files (e.g., ".login").

          Möglich, lästig, und letztlich nur möglich, wenn der Client (Mailer oder Browser) den vorgeschlagenen Namen nicht genügend filtert. Von einem Unix-Client erwarte ich, dass führende Punkte aus dem vorgeschlagenen Dateinamen entfernt werden.

          +    Creating or overwriting system files (e.g., "/etc/passwd").

          Wieder ein Filter-Problem. /etc/ im vorgeschlagenen Namen sollte ignoriert werden. Außerdem sollte /etc/passwd von Usern nicht überschrieben werden können. Wenn doch, hat der root gepennt. Und root sollte weder als root mailen noch als root surfen. Also Mumpitz.

          +    Overwriting any existing file.

          Nochmal ein Filter-Problem. Verzeichnisangaben haben ignoriert zu werden. So kann nur eine Datei im zum Download ausgewählten Verzeichnis überschrieben werden, soweit der User auf der Datei Schreibrechte hat. In aller Regel fragt der Client, ob überschrieben werden soll. Auf systemrelevante Dateien hat der User keine Schreibrechte zu haben.

          +    Placing executable files into any command search path (e.g., "~/bin/more").

          Wieder ein Filter-Problem. Verzeichnisnamen im vorgeschlagenen Dateinamen haben ignoriert zu werden. Und selbst wenn nicht: Kein vernünftiger Client wird Dateien mit gesetzten Executable-Bits ablegen. Und ohne Executable-Bits ignorieren Unixe im Suchpfad abgelegte Dateien. Ähnliche Situation unter Windows: User sollten nicht in Programmverzeichnisse schreiben können.

          +    Sending the file to a pipe (e.g., "| sh").

          Das ist nur möglich, wenn nicht ausreichend gefiltert wird UND auch noch die Shell mit ungefilterten Daten aufgerufen wird.

          Letztlich ist diese Panikmache schlecht aus den RFCs abgeschrieben. Content-Disposition ist der de-facto-Standard, und alle relevanten Clients filtern mindestens die Pfadangaben aus dem Dateinamen. Natürlich kann man sich einen HTTP- oder Mail-Client stricken, der Dateinamen aus dem C-D-Header nicht filtert, so riesige Lücken reißt, und das System von außen angreifbar macht. Ist das dann aber der Fehler der RFCs oder desjenigen, der den Client gebastelt hat?

          Weiter oben in der RFC2183, im Kapitel 2.3, steht übrigens nochmal ausdrücklich, dass Clients den Dateinamen gründlich zu filtern haben: "It is important that the receiving MUA not blindly use the suggested filename. The suggested filename SHOULD be checked (and possibly changed) to see that it conforms to local filesystem conventions, does not overwrite an existing file, and does not present a security problem (see Security Considerations below). The receiving MUA SHOULD NOT respect any directory path information that may seem to be present in the filename parameter.  The filename should be treated as a terminal component only."

          Alexander

          --
          Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so".
          1. Hi there,

            Der saubere Weg ist der Content-Disposition-Header, siehe RFC2616. "Content-Disposition: attachment" teilt dem Browser mit, dass der Server die jeweilige Resource nicht angezeigt, sondern gespeichert haben möchte.

            Hm. Wikipedia ist

            ... ein großer Haufen Text mit stark variierender Qualität. Aus welchem Artikel zitierst Du hier?

            http://de.wikipedia.org/wiki/Liste_der_HTTP-Headerfelder

            da (in Bezug auf "sauber") anderer Ansicht: "Mit diesem nicht standardisierten und als gefährlich eingestuften Feld kann der Server für bestimmte MIME-Typen Downloadfenster erzeugen und einen Dateinamen vorschlagen."...

            Das ist ja großartiger Murks.

            Mag ja sein. Ich wollte Deinen Vorschlag nur nachlesen und bin auf die Seite in der Wikipedia gestossen. Deine Stellungnahme ist ja nun dankenswerterweise sehr ausführlich ausgefallen...

            1. Moin Moin!

              Aus welchem Artikel zitierst Du hier?

              http://de.wikipedia.org/wiki/Liste_der_HTTP-Headerfelder

              Ah ja, danke. Der Link fehlte einfach.

              da (in Bezug auf "sauber") anderer Ansicht: "Mit diesem nicht standardisierten und als gefährlich eingestuften Feld kann der Server für bestimmte MIME-Typen Downloadfenster erzeugen und einen Dateinamen vorschlagen."...

              Das ist ja großartiger Murks.

              Mag ja sein. Ich wollte Deinen Vorschlag nur nachlesen und bin auf die Seite in der Wikipedia gestossen. Deine Stellungnahme ist ja nun dankenswerterweise sehr ausführlich ausgefallen...

              Und das schönste daran: Ich hab auch noch was gelernt. Ich hätte ziemlich viel darauf gewettet, das C-D ein verbindlicher Standard ist.

              Alexander

              --
              Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so".
  2. Hi,

    Wie kann man erreichen, dass beim Klicken auf eine verlinkte PDF-Datei (via "Download" button) wirklich ein Download erfolgt, anstatt dass die PDF-Datei nur im Browser angezeigt wird?

    mal so der Erbsenzählerei wegen: Auch wenn das PDF-Dokument per Plugin direkt im Browser angezeigt wird, erfolgt vorher erst ein Download.

    Kann es sein, dass dies davon abhängt auf welchem Server sie sich befindet, und welche Einstellungen auf diesem Server aktiv sind?

    Ja, dazu hat sich Felix schon geäußert. Und noch dazu hängt es sehr von der Konfiguration des Clients ab. Meine Browser fragen beispielsweise bei PDF-Dokumenten grundsätzlich nach, ob sie die Ressource einfach nur speichern oder gleich mit dem zugehörigen Programm öffnen sollen.

    Ciao,  Martin

    --
    Zwei Freundinnen tratschen: "Du, stell dir vor, die Petra kriegt ein Kind!" - "Ich kann mir schon denken, von wem." - "Dann ruf sie mal schnell an, das würde ihr bestimmt weiterhelfen." Selfcode: fo:) ch:{ rl:| br:< n4:( ie:| mo:| va:) de:] zu:) fl:{ ss:) ls:µ js:(
  3. Hakuna matata!

    Wie kann man erreichen, dass beim Klicken auf eine verlinkte PDF-Datei (via "Download" button) wirklich ein Download erfolgt, anstatt dass die PDF-Datei nur im Browser angezeigt wird?

    Zusätzlich zu den schon genannten Methoden, kannst du das auch clientseitig lösen, indem du dem Link das download-Attribut verpasst.

    <a href="foo.pdf" download="foo.pdf">Download foo.pdf</a>

    --
    “All right, then, I'll go to hell.” – Huck Finn
    1. Moin Moin!

      Zusätzlich zu den schon genannten Methoden, kannst du das auch clientseitig lösen, indem du dem Link das download-Attribut verpasst.

      Dir ist schon klar, dass das aus dem Entwurf (Draft) von HTML 5.1 ist? HTML 4 kennt das Attribut nicht, die früheren Standards wahrscheinlich auch nicht. In HTML 5 gibt es das Attribut. (Warum hast Du nicht darauf verlinkt?)

      Wie weit die Browser das Attribut unterstützen, ist eine völlig andere Frage. Wie erwartet sieht das ziemlich übel aus: IE geht gar nicht, Safari Mac geht gar nicht, Safari iOS geht gar nicht, Opera Mini geht gar nicht, IE Mobile geht gar nicht. Firefox vor 20 geht nicht, Chrome vor 14 geht nicht, Opera vor 15 geht nicht, Android Browser vor 4.4 geht nicht. Blackberry Browser vor 10 geht nicht, Opera Mobile vor 24 geht nicht.

      Ich denke, der Content-Disposition-Header dürfte von allen Browsern unterstützt werden. Auf jeden Fall von IE 4 und neuer, allen Firefox-Versionen, allen Chrome-Versionen und allen Opera-Versionen. Ich gehe mal davon aus, dass IE 3, Netscape 4.x und das ganze mobile Gerümpel mit C-D auch klarkommen.

      Alexander

      --
      Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so".
      1. Hakuna matata!

        Zusätzlich zu den schon genannten Methoden, kannst du das auch clientseitig lösen, indem du dem Link das download-Attribut verpasst.

        Dir ist schon klar, dass das aus dem Entwurf (Draft) von HTML 5.1 ist?

        Ja.

        In HTML 5 gibt es das Attribut. (Warum hast Du nicht darauf verlinkt?)

        Warum sollte ich? Wir haben auch nicht gewartet auf HTML5 zu verlinken, bis es eine fertige Recommendation war, und das hat sich als ganz gute Idee erwiesen. Wieso sollte ich das nun bei HTML5.1 anders machen? Die Standards werden sowieso nicht als diskrete Einheiten implementiert oder adaptiert, weswegen man beim WHATWG die Reihe auch einfach als „Living HTML“ bezeichnet.

        Wie weit die Browser das Attribut unterstützen, ist eine völlig andere Frage.

        Ja, und meine Antwort darauf lautet Polyfill.

        Ich denke, der Content-Disposition-Header dürfte von allen Browsern unterstützt werden.

        Daran zweifle ich nicht, ich wollte lediglich eine weitere Lösungsvariante vorschlagen. Die dürftige Browserunterstützung kann man als ein Nachteil betrachten. Ein Vorteil der clientseitigen Lösung ist, dass man gleichzeitig auf ein Dokument "zum Anzeigen" und "zum Download" verlinken kann, und der Browser für beide Links die selbe Ressource cachen kann.

        --
        “All right, then, I'll go to hell.” – Huck Finn