nicht angemeldet
JürgenB
Rolf B
Der Martin
Camping_RIDER
JürgenB
Der Martin
Rolf B
Camping_RIDER
Robert B.
JürgenB
Hallo,
gibt es eine Möglichkeit, bei einem Link auf eine xml-Datei (gpx) den Download zu erzwingen, statt die Datei im Browser zu öffnen.
Ich habe in der .htacess AddType application/gpx+xml gpx stehen, und im Link das download-Attribut.
Bei mir hat das funktioniert, aber bei einem der Anwender meines GPX-Viewers wird die Datei im Browser geöffnet.
Gruß
Jürgen
Hallo JürgenB,
https://wiki.selfhtml.org/wiki/HTTP/Header/Content-Disposition
nützt Dir das was?
MDN schreibt noch:
Die same-origin Restriktion steht nicht in der Spec, soweit ich das sehe, aber laut MDN lässt Chrome ab Version 65 keine cross-domain Downloads zu. Bei FF steht keine Version dabei, aber da "same-origin" vorweg bei den allg. Einschränkungen steht, dürfte es im FF auch so sein.
Rolf
Hallo Rolf,
https://wiki.selfhtml.org/wiki/HTTP/Header/Content-Disposition
nützt Dir das was?
leider nicht, weil ich nicht weiß, wie und wo ich diesen Header senden kann, und wie ich ihn nur für einen bestimmten Dateityp senden kann.
Gruß
Jürgen
Hallo JürgenB,
Tante Google sagt mir: Geht nicht sowas in der .htaccess, an Stelle des AddType?
<Files *.gpx>
ForceType application/gpx+xml
Header set Content-Disposition attachment
</Files>
Rolf
Hallo Jürgen,
gibt es eine Möglichkeit, bei einem Link auf eine xml-Datei (gpx) den Download zu erzwingen, statt die Datei im Browser zu öffnen.
wenn ich erreichen will, dass eine Ressource nicht mit der passenden Anwendung geöffnet, sondern einfach nur gespeichert wird, greife ich gern zu einer schmutzigen, aber pragmatischen Lösung: Ich liefere sie mit dem Content-Type application/octet-stream aus.
Ich habe in der .htacess
AddType application/gpx+xml gpxstehen, und im Link dasdownload-Attribut.
Mit dem download-Attribut im Link habe ich selbst noch keine Erfahrung, aber schon oft gehört, dass es nicht zuverlässig funktioniert. Da wäre Rolfs Vorschlag mit dem Content-Disposition-Header schon schöner.
Live long and pros healthy,
Martin
Aloha ;)
gibt es eine Möglichkeit, bei einem Link auf eine xml-Datei (gpx) den Download zu erzwingen, statt die Datei im Browser zu öffnen.
wenn ich erreichen will, dass eine Ressource nicht mit der passenden Anwendung geöffnet, sondern einfach nur gespeichert wird, greife ich gern zu einer schmutzigen, aber pragmatischen Lösung: Ich liefere sie mit dem Content-Type application/octet-stream aus.
Diese Lösung funktioniert zwar vordergründig, aber bei weitem nicht in allen Fällen; sie bringt ihre ganz eigenen Problemchen mit sich. Es ist halt nur ein Notbehelf.
Das ganze scheitert, sobald die Datei in irgend einem anderen Kontext verwendet werden soll, als zum Abspeichern durch einen Anwender.
Drei Problem-Beispiele, die mir auf die Schnelle einfallen:
Grüße,
RIDER
Hallo Janosch,
das ist in meinem Fall aber kein Problem. Die gpx-Dateien werden entweder per Ajax als Text-Datei geladen, oder eben zum Download angeboten.
Gruß
Jürgen
n'Abend Janosch,
wenn ich erreichen will, dass eine Ressource nicht mit der passenden Anwendung geöffnet, sondern einfach nur gespeichert wird, greife ich gern zu einer schmutzigen, aber pragmatischen Lösung: Ich liefere sie mit dem Content-Type application/octet-stream aus.
Diese Lösung funktioniert zwar vordergründig, aber bei weitem nicht in allen Fällen; sie bringt ihre ganz eigenen Problemchen mit sich. Es ist halt nur ein Notbehelf.
das sehe ich nicht so; ich sehe das im Gegenteil als technisch bevorzugte Lösung, nur halt ein bisschen hinterhältig.
Das ganze scheitert, sobald die Datei in irgend einem anderen Kontext verwendet werden soll, als zum Abspeichern durch einen Anwender.
Aber das war ja hier nicht das Thema.
- Indizierung durch Suchmaschinen (inwiefern die den Dateinamen auch auswerten, weiß ich nicht)
- hohldrehende Internet-Security-Plugins diverser Antiviren-Hersteller mögen sowas nicht
- Drittprogramme, die via URL zugreifen wollen, kommen damit manchmal nicht klar (mir bekanntes Beispiel: Video-teilen in BigBlueButton funktioniert auch mit Direktlink zur MP4-Datei, aber nur mit richtigem Content-Type)
Okay. Aber das war in Jürgens Anwendungsfall alles nicht gefragt.
Und selbst wenn man sich alle Optionen offenhalten möchte, kann man die Ressource immer noch mit dem "richtigen" Content-Type ausliefern und dem Besucher einen Hinweis geben, dass er das Ding mit einem Rechtsklick auf den Link und "Ziel speichern unter" auch lokal speichern kann.
Live long and pros healthy,
Martin
Hallo Martin,
dem Besucher einen Hinweis geben, dass er das Ding mit einem Rechtsklick auf den Link und "Ziel speichern unter" auch lokal speichern kann.
Das ist vermutlich die einzig korrekte Lösung. Nach dem, was Jürgen beschrieb, mutmaße ich same-origin für den Download-Link , und wenn ein Browser dann trotz download-Attribut und Content-Disposition Header keinen Download macht, sondern auf einer inline-Anzeige der GPX-Datei besteht, sollte man keine weiteren Bocksprünge unternehmen. "Octet-Stream" ist eine Binärdatei, wer weiß welcher Virenscanner sich darüber erregt...
Rolf
Aloha ;)
wenn ich erreichen will, dass eine Ressource nicht mit der passenden Anwendung geöffnet, sondern einfach nur gespeichert wird, greife ich gern zu einer schmutzigen, aber pragmatischen Lösung: Ich liefere sie mit dem Content-Type application/octet-stream aus.
Diese Lösung funktioniert zwar vordergründig, aber bei weitem nicht in allen Fällen; sie bringt ihre ganz eigenen Problemchen mit sich. Es ist halt nur ein Notbehelf.
das sehe ich nicht so; ich sehe das im Gegenteil als technisch bevorzugte Lösung, nur halt ein bisschen hinterhältig.
Technisch bevorzugte Lösung? Naja. Es ist ein Hack - man nutzt ein übliches Browserverhalten unter bestimmten Randbedingungen (hier der Standard-Mime-Typ für "unbekannt") aus, um zu erreichen, was man möchte.
Ich halte die anderen genannten Lösungswege für besser. Das Download-Attribut und der (von @Rolf B bereits genannte) Content-Disposition-Header sind für mich, was ich technisch bevorzugte Lösung nennen würde, denn sie sollen genau das tun, was man mit dem Hack erreicht.
Das download-Attribut hilft natürlich nicht, wenn man nur die URL hat - daher sollte man hier wirklich das Augenmerk auf Content-Disposition: attachment legen. Dieser Header tut genau das, was gefragt ist, ohne dabei ein Hack zu sein, der ggf. andere Dinge kaputt macht oder in der Zukunft zu jetzt noch unabsehbaren Schwierigkeiten führt[1].
Hacks sind gut, solang es keine andere, gleichartige Möglichkeit gibt, und/oder solange man auf andere Weise keine ausreichende Kompatibilität zu Browsern oder gar Funktionalität erreicht.
Die Browser-Unterstützung für Content-Disposition ist allerdings mittlerweile so breit, dass man getrost auf den Hack verzichten kann. Insofern ist Content-Disposition für mich die technisch bevorzugte Lösung.
Aber das war ja hier nicht das Thema.
Das ist einerseits richtig, andererseits sollte man Dinge (vor allem bei vergleichbarem Aufwand wie hier) besser gleich richtig machen. Es passiert zu oft, dass irgendwann Anforderungen oder Probleme entstehen, die man nicht vorhergesehen hat.
Okay. Aber das war in Jürgens Anwendungsfall alles nicht gefragt.
Das ist halt ein bissl wie die „Blinde wollen eh nicht auf meine Webseite“-Diskussion. Woher weiß man vorher, was ein User braucht oder will? Mag sein, dass hier nicht der Fokus auf diesen Dingen lag, aber das heißt nicht, dass sie deshalb egal sind.
Und selbst wenn man sich alle Optionen offenhalten möchte, kann man die Ressource immer noch mit dem "richtigen" Content-Type ausliefern und dem Besucher einen Hinweis geben, dass er das Ding mit einem Rechtsklick auf den Link und "Ziel speichern unter" auch lokal speichern kann.
Genau richtig! Es gibt also sogar eine built-in-Funktion, so dass bei fehlender Browser-Unterstützung von Content-Disposition trotzdem ein Download möglich ist. Content-Disposition ist dann klassisches Progressive Enhancement - was die alternative Verwendung des Hacks noch unnötiger macht.
Grüße,
RIDER
Das ist immer das Grundsatzproblem bei Hacks. Weil es Hacks sind, also eine Zweckentfremdung, kann niemand garantieren, dass zukünftige oder andere Implementierungen des selben Mechanismus sich auf die selbe Art und Weise zweckentfremden lassen… ↩︎
Moin Jürgen,
gibt es eine Möglichkeit, bei einem Link auf eine xml-Datei (gpx) den Download zu erzwingen, statt die Datei im Browser zu öffnen.
Ich habe in der .htacess
AddType application/gpx+xml gpxstehen, und im Link dasdownload-Attribut.
es ist zwar nicht ganz dieses Thema, aber hoffentlich inspirierend: https://forum.selfhtml.org/self/2021/apr/26/content-disposition-attachment-via-querystring-korrekt-setzen/1787796#m1787796.
Viele Grüße
Robert
Hallo Robert,
hat denn das
Header set Content-Disposition attachment
dazu geführt, dass die Datei zum download angeboten wird?
Mein Problem ist: bei mir werden GPX-Dateien sogar ohne das download-Attribut im Link und ohne Anweisung in der .htaccess zum Download angeboten. Das war allerdings nicht immer so.
Beim Anwender meines GPX-Viewers ist das leider nicht der Fall. So wie er schreibt, ist das Verhalten sogar Browserabhängig.
Gruß
Jürgen
Hallo JürgenB,
Beim Anwender meines GPX-Viewers ist das leider nicht der Fall.
Welchen Brauser verwendet der denn? Hat er vielleicht irgendein Plugin drin, das querschießt?
Browser zeigen eigentlich nur Dateien an, deren Mime-Typ sie kennen (ab Werk oder per Plugin). Den Rest loaden sie automatisch down.
Ich habe im Büro mit Content-Disposition die Erfahrung gemacht (im IE, seit bestimmt 10 Jahren), dass ein Dateityp (.pdf), den der Browser von sich aus per Acrobat Reader Plugin anzeigt, zum Download wird. Das war zwar kein Apache mit .htaccess, sondern ein IIS und eine ASP.NET Anwendung, aber das sollte dem Browser ja egal sein.
Rolf
Hallo Rolf,
Welchen Brauser verwendet der denn? Hat er vielleicht irgendein Plugin drin, das querschießt?
Chrome, Firefox und Edge. Für das „Cache-Problem“ ist er sensibel. Von Plugins hat er nichts geschrieben. Er hat jetzt mal diverse Einstellungen in die .htaccess geschrieben und wird sich nach Tests bei mir melden.
Gruß
Jürgen
Hallo JürgenB,
ah - das ist kein Anwender der deinen Server nutzt, sondern er verwendet deinen GPX Viewer auf seinem Server. Gut zu wissen.
Und du kannst das Problem nicht nachstellen, wenn Du auf seinem Server zugreifst?
Okehhhh... knifflig.
Rolf
Hallo Rolf,
Und du kannst das Problem nicht nachstellen, wenn Du auf seinem Server zugreifst?
doch, das konnte ich. Und z.Zt. funktioniert es bei unter Windows auch.
Gruß
Jürgen
Moin Jürgen,
hat denn das
Header set Content-Disposition attachmentdazu geführt, dass die Datei zum download angeboten wird?
Ja, zumindest in
(Weitere Browser habe ich nicht probiert.)
Viele Grüße
Robert
Ich habe in der .htacess
AddType application/gpx+xml gpxstehen, und im Link dasdownload-Attribut.
Das sieht zwar korrekt aus, führt aber dazu, dass der Browser das womöglich als xml behandeln will. Anders gesagt: Bei Angabe einesContent-Type macht der Browser, was in diesem für den Content-Type eingestellt ist.
Wenn Du den Download erzwingen willst, dann ist
AddType application/octet-stream
eines der möglichen Mittel. application/unknown wird auch gern genannt.
Das folgende Bild zeigt, was passieren kann, wenn man einen bekannten Content-Type sendet:
Klickt der Benutzer jetzt an, dass der Browser sich diese Aktion merken soll und dann auf "OK", dann wird nicht wieder gefragt, bis über die Browsereinstellungen diese Auswahl rückgängig gemacht wird.
Mit application/octet-stream oder application/unknown ist man als Versender dann aber halbwegs sicher, weil der Besucher schon einige Antrengungen unternehmen muss um bei diesen Mime-Typen eine Anwendung festzulegen.
Ich muss mir also auch überlegen, ob ich da was ändere…
Hallo,
vielen Dank für die Unterstützung. Der Anwender meines GPX-Viewers hat sich jetzt gemeldet und es funktioniert, außer im Safari, der immer im Downloadordner speichert.
Er verwendet das Download-Attribut und hat in die .htaccess einfach alle Vorschläge eingebaut.
Gruß
Jürgen