Clientseitige Downloadpfad Eingabe

[hmm]

Hallo,

ich möchte ein paar Dateien von meiner Angular App downloaden können. Derzeit kann ich diese Dateien zwar downloaden, aber ich kann keinen Zielordner für den Download auswählen.

Kennt ihr ein passendes Element mit dem der Webseiten Anwender einen Ordner auswählen kann, in welchen die Files dann gespeichert werden? Ich brauche nur einen clientseitige Ordnerauswahlknopf.

[Matthias Apsel]

Hallo hmm,

das hängt doch sicher an den Browsereinstellungen der Benutzer.

Bis demnächst
Matthias

[hmm]

was meinst du damit? die wird sich anpassen lassen.

Meine Fachseite möchte einen Knopf habe, wo man den Downloadzielordner eingeben kann, ein ähnliches Dropdown wie beim klassischen Fileupload wäre ganz gut. Leider finde ich dazu nichts. Was klappen würde, wäre dass der Anwender hardcodet sein Zielverzeichnis in ein Textfeld eintippt, dass wäre aber unschön.

[Matthias Apsel]

Hallo hmm,

was meinst du damit? die wird sich anpassen lassen.

Meine Fachseite möchte einen Knopf habe, wo man den Downloadzielordner eingeben kann,

Wie sich ein Browser beim Download verhält, lässt sich einstellen und mMn. nicht durch ein HTML-Dokument beeinflussen.

Du könntest in einem Intranet die Einstellungen durch die IT-Abteilung ändern lassen.

Bis demnächst
Matthias

[Auge]

Hallo

ich möchte ein paar Dateien von meiner Angular App downloaden können. Derzeit kann ich diese Dateien zwar downloaden, aber ich kann keinen Zielordner für den Download auswählen.

Kennt ihr ein passendes Element mit dem der Webseiten Anwender einen Ordner auswählen kann, in welchen die Files dann gespeichert werden?

Nein, da es das so, wie gewünscht, nicht gibt.

Ich brauche nur einen clientseitige Ordnerauswahlknopf.

Alles, was du machen kannst, ist dem Downloadlink das Attribut download beizufügen. Damit erzwingest du den Download, auch wenn der Browser für den Datetyp ein Plugin haben sollte, wie es oft bei PDFs ist, wo im Browser das Adobe-Reader-Plugin geladen wird. Mit dem Attribut wird in jedem Fall ein Download ausgelöst.

Ob der Benutzer dann auch das Zielverzeichnis angeben kann, hängt aber von der Browserkonfiguration ab. Ist dort ein festes Zielverzeichnis – unter Windows und Ubuntu-Linux „Downloads“ – vorgegeben, wird der Download ohne weitere Nachfrage dort gespeichert. Ist kein Verzeichnis vorgegeben oder lautet die Einstellung – zumindest im Firefox so verfügbar – „jeses Mal nachfragen“, kann und muss der Benutzer eine Auswahl tätigen oder zumindest die vom letzten Download übernommene Vorauswahl bestätigen.

Im Firmenumfeld sollte die Konfiguration vorgegeben werden können. Ansonsten bist du darauf angewiesen, dass die Einstellung passend vorgenommen und nicht verändert wurde.

Tschö, Auge

[Rolf B]

Hallo Auge,

Nein, da es das so, wie gewünscht, nicht gibt.

Ich war im Begriff, ähnliches zu schreiben, musste dann aber vom PC weg.

Darum nur als Ergänzung: Der Grund dafür ist Sicherheit. Die Webseite in einem Browser ist der verlängerte Arm eines Servers, und damit grundsätzlich etwas, dem man nicht trauen darf. Darum darf eine Webseite nichts über die Maschine erfahren, in der sie ausgeführt wird. Der Browser ist ihre Welt, und jeder Kontakt mit dem, was außerhalb des Browsers existiert, muss explizit vom Anwender zugeliefert oder abtransportiert werden.

D.h. statt stumpf auf den Link zu klicken, müssen die Anwender mit der rechten Maustaste darauf klicken (oder wie auch immer man auf der konkreten Maschine das Kontextmenü des Links erreicht) und die "Link speichern unter..." oder "Ziel speichern unter..." Option auswählen, je nach Browser. Dann bekommen sie den entsprechenden Dialog und können den Zielordner und den Dateinamen nach Wunsch festlegen.

Eine Festlegung im HTML verrät der Webseite etwas über die Ordnerhierarchie des Zielgeräts, je nach Ordner sogar den angemeldeten Benutzernamen, und ist darum prinzipiell nicht zugelassen.

Wenn euer Fachbereich unbedingt so etwas haben will, dann müsste ich die Frage nach dem Betriebssystem stellen. Unter Windows gibt es so etwas wie URL Handler. Ein bekanntes Exemplar wäre mailto:, für das sich ein lokaler EMail-Client auf dem Gerät registrieren kann. Du kannst eigene URL-Handler registrieren.

Registriere den URL-Handler corpdown: (corporate download) oder ähnlich, und registriere darauf ein Programm. Dieses Programm bekommt den geklickten Link mitgeteilt, und kann dann einen eigenen Download der HTTP Ressource durchführen und vorher die Festlegung des Zielordners ermöglichen. Das kann beliebig komfortabel programmiert werden, weil es eine lokale App ist, die das durchführt.

Rolf

[hmm]

danke!

noch eine frage: wenn mein Programm lokal läuft kann ich sachen downloaden, laufen sie aber auf einem server, so kann ich was nicht. muss ich da meine proxy einstellungen anpassen? ich nutze chrome.

[dedlfix]

Tach!

wenn mein Programm lokal läuft kann ich sachen downloaden, laufen sie aber auf einem server, so kann ich was nicht. muss ich da meine proxy einstellungen anpassen?

Das kommt darauf an, wie "kann nicht" genau definiert ist. Gibt es Fehlermeldungen in der Konsole des Browsers? Wenn nicht, welche Response bekommt der Browser denn auf den Download-Versuch?

Wenn du zwangsweise einen Proxy nutzen musst, solltest du das besser mit dessen Administrator besprechen als mit Außenstehenden, die keine Ahnung von den Gegebenheiten haben.

dedlfix.

[Rolf B]

Hallo hmm,

wenn mein Programm lokal läuft

Reden wir hier von deiner Webseite oder von einem selbst geschriebenen Programm, das außerhalb des Browsers läuft? In welcher Sprache ist es erstellt? Wenn es selbst geschrieben ist, dann musst Du für den Fall, dass ein Proxy im Spiel ist, tatsächlich anders vorgehen. Zumindest war das bei allen C# Programmen so, die ich bisher geschrieben habe und die auf Transproxy-Ressourcen zugreifen sollten.

Ansonsten ist ein Download ist ein HTTP-Request wie alle anderen Browser-Requeste auch. Der Unterschied besteht, je nach Download, im MIME-Type der Response.

Ob Proxy-Einstellungen relevant sind, hängt davon ab, ob da tatsächlich ein Proxy zwischen deinem Browser und dem Server ist. Außer der Tatsache, dass ein selbst geschriebener Downloader eine Proxy-Awareness braucht, kann es auch noch sein, dass der Proxy bestimmte MIME-Typen verbietet, oder auf dem Proxy ein Scanner läuft, der bestimmte Inhalte verbietet, sofern die Downloadquelle nicht als vertrauenswürdig auf der Whitelist steht.

Das hängt dann an den Einstellungen der Software auf dem Proxy. Mit den Proxy-Einstellungen deines Geräts hat das weniger zu tun. In letzteren legst Du fest, welcher Proxy zu verwenden ist, welche Protokolle über welchen Proxy geroutet werden sollen, oder welche Adressen lokal sind und nicht über den Proxy laufen sollen. Ein verhinderter Download durch den Browser dürfte vom Proxy geblockt werden, und das müsste man im Netzwerktrace des Browsers erkennen können.

Rolf

[hmm]

das Problem besteht doch nicht. ich hatte meinen code eingecheckt und per jenkins gebaut und deployt, leider habe ich dann auf einer alten version getestet. erst nach browserneustart war ich auf der neuen version, da funktioniertder pdf download.

Allerdings habe ich ein anderes Problem: Ich downloade anscheind .gzip Dateien und .xml. Eigentlich möchte ich nur das File herausgeben, dass ich bekomme. Ich versuche das gerade so:

<a href="rest/ui/download/product-part/{{item.download}}" target="_blank">Download</a>

Dabei bekomme ich aber ein 401 Error. Jetzt versuche ich herauszufinden, wie ich einen Header in diesem href Konstrukt mitschicken kann.

Wenn ich mir die Datei so hole, bekomme ich sie, leider weiß ich nicht wie ich dass dann zum Download freigeben kann:

this.httpClient.get('/rest/ui/produktteile?size=' + 
         this.config.itemsPerPage + 
         '&page=' + (this.config.currentPage - 1) + 
         this.sort  + this.searchParams,
     { headers: this.headers,  observe: 'response' }
).subscribe(data => {

// hier möchte ich eigentlich das file zum download
// freigeben, dass ich in data bekomme

});

[Matthias Apsel]

Hallo hmm,

das dir bereits in diesem Thread empfohlene download-Attribut ist nicht zielführend?

Bis demnächst
Matthias

[hmm]

das problem ist anscheind der type des Downloades. ich bekomme einen parsing Error.

Welchen Type muss ich den bei gzip und xml eintragen?

[Auge]

Hallo

das problem ist anscheind der type des Downloades. ich bekomme einen parsing Error.

Wo hast du einen Parse Error? Auf dem Server (PHP, Perl, Python, WasAuchImmer?) oder im Browser (JS/Angular?).

Welchen Type muss ich den bei gzip und xml eintragen?

• gzip: gzip/deflate
• xml: text/xml oder application/xml

Tschö, Auge

[hmm]

danke. kann ich beide angeben? ich weiß nicht welches der beiden Formate zurück kommt.

[Auge]

Hallo

danke. kann ich beide angeben?

Ich denke, dass das nicht geht. Ich kann mir auch keine sinnvolle Anwendung denken. Schließlich ist ein Komprimat ein Kompriimat und keine XML-Dokument und umgekehrt.

ich weiß nicht welches der beiden Formate zurück kommt.

Das musst du schon auf dem ausliefernden Server ermitteln und dich dort für den passenden MIME-Typ entscheiden.

Tschö, Auge

[hmm]

ok danke. leider bekomme ich immernoch einen "Http failure during parsing for..." fehler. wie gehe ich an sowas ran?

mein content type lautet:

new HttpHeaders({ 'content-type': 'application/xml; charset=UTF-8', 'authorization': "Bearer " + localStorage.getItem('token') });

in der console wird mir ein xml ausgegeben.

hier mein code:

Quelltext hier  download(url) {
    let downloadHeaders = new HttpHeaders({ 'content-type': 'application/xml; charset=UTF-8',
      'authorization': "Bearer " + localStorage.getItem('token') });
    downloadHeaders.append('Access-Control-Allow-Origin', '*');
    this.httpClient.get('/rest/ui/download/product-part/' + url, { headers: downloadHeaders }).subscribe(response => {
        console.log(response);
        this.downLoadFile(response, "application/xml");
      }
    );
  }


  downLoadFile(data: any, type: string) {
    let blob = new Blob([data], { type: type});
    let url = window.URL.createObjectURL(blob);
    let pwa = window.open(url);
    if (!pwa || pwa.closed || typeof pwa.closed == 'undefined') {
      alert( 'Please disable your Pop-up blocker and try again.');
    }
  }

er logt mir den Respone in die Console. Leider bekomme ich den parsin error dann in downLoadFile. ich bekomme anscheind immer einen content-typ von xml und einen content-encoding gzip

[Rolf B]

Hallo hmm,

d.h. der eigentliche Download vom Server gelingt und du bekommt einen XML String geliefert. Den gibst Du ja aus.

Mit dem GZIP bin ich nicht sicher, ob ich das richtig verstehe. Du schreibst immer "GZIP und XML", das klingt nach XML als Content-Type und GZIP als Content-Encoding. Das siehst du aber im Netzwerktab des Browsers, wenn Du Dir die Response des Servers auf deine Anfrage anschaust.

Jedenfalls musst Du beim Senden des GET Requests an den Server keinen Content-Type setzen. Du sendest ja keinen Content. Das tut nur der Server, deshalb muss der den Content-Type setzen. Der Client kann einen Accept-Header setzen, mit dem er dem Server die MIME-Typen schickt, die der Client versteht. Der Default dürfte / oder so sein. Guck ins Netzwerk-Tab, da siehst Du was der Browser schickt.

Das Content-Encoding musst Du eigentlich nicht beachten, das ist eine Sache der Transportschicht und sollte vom Brauser transparent behandelt werden. Beim Erzeugen der ObjectURL spielt das Content-Encoding, das der Server benutzte, keine Rolle mehr. Das siehst Du daran, dass deine Response ein XML String ist.

Oder - ist es das? Oder ist das ein Response-Objekt, das eine toString() Methode besitzt die den Content ausgibt? Das müsstest Du herausfinden. Entweder mit dem Debugger, oder durch Nachlesen im Angular Handbuch. Wenn Du ein Response-Objekt bekommst, dass sich lediglich für console.log() in einen String mit dem Content verwandelt, könnte das den Parse-Error erklären.

Update: Ich sehe gerade, dass Du createObjectUrl verwendest. Erstaunlich, dass das überhaupt klappt, weil eine ObjectURL an das Dokument gebunden ist in dem sie erzeugt wurde. Aber in einem Fiddle hat das funktioniert. Es ist dann nur so, dass diese ObjectURL Chrome dazu bringt, einen XML Pretty Printer anzuwerfen, der die XML-Declaration Zeile unterschlägt. Was der Fuchs tut weiß ich nicht. Wenn das das ist, was Du willst, prima. Wenn Du die XML Datei „nackig“ anzeigen willst, dann setze für den Blob den Typ "text/plain".

Ich habe das mit einem Mini-XML Dokument probiert, das in einem String steht, und bekomme keinen Parse-Error. Ist dein XML Dokument nicht in Ordnung? Chrome sagt mir genau, wo der Parse-Error ist. Guck Dir das erhaltene XML an der Stelle mal an.

Rolf

[hmm]

hallo Rolf,

ich bekomme immer xml.gzip Dateien und text.gzip Dateien. Der Inhalt beider wird per console.log richtig in meiner Konsole ausgegeben. Ich muss jetzt noch dafür sorgen, dass diese .gzip Datei auf den Clientserver gedownloadet wird.

Hier die Response Infos vom Browser:

Cache-Control: no-cache, no-store, max-age=0, must-revalidate

Connection: keep-alive

Content-Disposition: attachment;

filename=ERKENNUNGSMODELL_CI.26.1_part_1_of_1.xml

Content-Encoding: gzip

Content-Length: 1322

Content-MD5: BW5jZw4MDWtK3qiK0bl/6g==

Content-Type: application/xml

Date: Thu, 10 Sep 2020 08:39:38 GMT

Expires: 0

Keep-Alive: timeout=60

Pragma: no-cache

Strict-Transport-Security: max-age=31536000 ; includeSubDomains

X-Content-Type-Options: nosniff

X-XSS-Protection: 1; mode=block

Da der Konsolen log alles richtig in die Konsoleschreibt, liegt der Fehlder in diesem COde Stück:

downLoadFile(data: any, type: string) {
    let blob = new Blob([data], { type: type});
    let url = window.URL.createObjectURL(blob);
    let pwa = window.open(url);
    if (!pwa || pwa.closed || typeof pwa.closed == 'undefined') {
      alert( 'Please disable your Pop-up blocker and try again.');
    }
  }

Ich muss leider 2h auf einem Server bauen, bis ich den Download neutesten kann (mein lokaler Rechner hat keine Rechte dafür). Bei Fidel habe leider keinen Beispielcode für die verwendung von new Blob mit gzip Files gefunden.

[Rolf B]

Hallo hmm,

ich bekomme immer xml.gzip Dateien und text.gzip

Nein, wenn ich die Header anschaue, bekommst Du das nicht. Du bekommst eine .xml Datei mit GZIP Content-Encoding.

Der Inhalt beider wird per console.log richtig in meiner Konsole ausgegeben.

Das „richtig“ erkennst Du woran? Wäre es eine GZIP Datei, hättest Du Bytesalat. Aber du erkennst den Inhalt und er stimmt? Dann bekommst Du definitiv eine .xml oder .text Datei, keine .gzip Datei. Wie ich vorhin schon schrieb: Content-Type und Content-Encoding sind zwei getrennte Dinge. Um den Content-Type musst Du Dich kümmern, um das Content-Encoding der HTTP-Client zusammen mit dem Browser.

Bei Fidel habe leider keinen Beispielcode für die verwendung von new Blob mit gzip Files gefunden.

Kein Problem, Du hast keine GZIP-Files. Du hast nur GZIP Encoding. Ist das XML geheim? Kannst Du es - ggf. mit virtuellen Schwärzungen - posten? Es ist ja nicht allzugroß.

Mein Fiddle: https://jsfiddle.net/Rolf_b/fLw5rgvx/

Ein mögliches Problem ist noch der Umstand, dass window.open nicht ohne Benutzerinteraktion erfolgen darf. Wenn ich das Fiddle ohne Button mache, mault Chrome herum und will eine Bestätigung, dass das Popup öffnen darf. Mit Button ist es eine Reaktion auf click und der Browser fragt nicht, sogar dann nicht, wenn ich Click-Handler und window.open durch einen setTimeout voneinander trenne.

Rolf

[hmm]

in der Konsoale langen manchmal xml Dateien die so aussehen:

<Erkennungsmodell

xmlns:xsi =" http://www.w3.org/2001/XMLSchema-instance "

xmlns =" http://ErkennungsmodellSchema "

xsi:schemaLocation =" http://ErkennungsmodellSchema ../schema/Erkennungsmodell.xsd "

schemaVersion =" 1.0 "

<Meta

</Meta

<Erkennungsobjekte

… </Erkennungsobjekte

</Erkennungsmodell>

Ganz normale xml's, lassen sich leider nur schwer aus der Konsole kopieren und beinhalten nur testdaten.

Die anderen Files haben so einen Response:

Cache-Control: no-cache, no-store, max-age=0, must-revalidate

Connection: keep-alive

Content-Disposition: attachment; filename=BARRIEREN_CI.9.221_part_1_of_1

Content-Encoding: gzip

Content-Length: 6109

Content-MD5: k9FjAVYWdHrIPPwKwVaHiA==

Content-Type: application/octet-stream

Date: Thu, 10 Sep 2020 09:12:45 GMT

Expires: 0

Keep-Alive: timeout=60

Pragma: no-cache

Strict-Transport-Security: max-age=31536000 ; includeSubDomains

X-Content-Type-Options: nosniff

X-XSS-Protection: 1; mode=block

Und geben im Konsolen log folgendes an:

---

Compressed.þMOSAICDATASET_INLINEGEOMETRY_STORAGEInLine*þMOSAICDATASET_INLINEBLOB_STORAGEInLine(þMOSAICDATASET_INLINE MAX_FILE_SIZE1TB,þMOSAICDATASET_INLINERASTER_STORAGEInLineKartografiedaten.gdb/a00000002.gdbtablx0000666 0000000 0000000 00000012040 13110777520 016310 0ustar 0000000 0000000 
#‘Ëï
>

€
¤
á
T}ÍúF~Ä÷5¸ô,v§Ô,a”æK}«×

meta.properties0100644 0000000 0000000 00000000540 13614274550 012657 0ustar000000000 0000000 #

Das ist ein Kommentar ...

Version=ci.9.221 Erstellungsdatum=2016-10-22T23:59:59Z

Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua. At vero eos et accusam et justo duo

Kommentar=Das ist ein ordentlich produziertes Produkt...

---

Also xml oder Text, ist da drin.

[hmm]

Wenn ich im HttpClient als Responsetype blob eingebe öffnet sich für die xml's eine seperate Seite wo diese dargestellt werden. kann ich statt einer seperaten seite auch einen Download als File machen? Oder ist das eine Browser Einstellung?

Bei den nicht xml's Dateien kommt es auf dieser Seite zu einem Error, wo der Browser sagt:

error on line 1 at column 1: Document is empty error on line 1 at column 1: Encoding error

Die Konsole wird aber mit .txt Inhalt vollgeschrieben.

[Rolf B]

Hallo hmm,

ersteres sollte funktionieren. Da fehlt zwar die XML Deklaration, aber das führt zu keinem Parsing Error.

Das zweite ist weder XML noch Text. Da ist auch der Content-Type nicht XML, sondern application/octet-stream - was auf eine Binärdatei hindeutet (oder darauf, dass der Server nicht weiß was er schickt). Betrachtet man dazu noch den Dateinamen

Content-Disposition: attachment; filename=BARRIEREN_CI.9.221_part_1_of_1

und den Anfang der Datei:

Compressed.þMOSAICDATASET_INLINE

dann ist tatsächlich eine komprimierte Datei. Die kannst Du natürlich nicht als ObjectURL öffnen lassen. Wenn der Browser die als XML interpretieren will, geht das kaputt. Ich frage mich nur, welches Format das ist. GZIP hat kein "Compressed" vorneweg.

Du bräuchtest eine JS Library, die GZIP-Strings entzippen kann. Zum Beispiel die hier. Ich habe sie noch nicht verwendet, ich hoffe, du kommst damit klar.

Äh, eine Frage noch: das läuft im Browser, ja? Oder in Node.js? Ich finde da einen Bug-Report bei Angular dass GZIP im Browser funktioniere, aber in Node nicht.

Wenn's ein Browser ist, kurz noch stop, bevor Du nach ZLib suchst: Die Frage ist doch, wer Dir das schickt. GZIP Encoding ist auf der Leitung aktiviert, aber das sollte transparent vom Browser decodiert werden. Ich mag mich irren, aber du solltest der Vermuting nachgehen, dass die auf dem Server laufende Application Software selbst eine GZIP Kompression durchführt, was Unsinn ist wenn der Webserver das transparent tun möchte (zu erkennen am Content-Encoding). Kann man das serverseitig einfach sein lassen? Nicht im Apache (oder welcher Webserver das auch immer ist), sondern in der Application Software?

Rolf

[hmm]

einen richtigen Filedownload bekomme ich leider auch nicht mit der Endung .xml hin, es öffnet sich nur eine neue Seite mit dem xml Inhalt. Eigendlich möchte ich nur die Datei auf dem Clientrechner speichern.

Also muss ich xml und application/octet-stream gesondert behandeln? woran erkenne ich, was von beiden ich bekomme? Brauche ich eine Lib die gzip's entzippen kann auch dann, wenn ich eigentlich nur die reine gezipte Datei downloaden möchte?

Ich nutze eine per JHipster generierte App aus Spring BootBackend und Angular Frontend, Node JS sehe ich hier nicht, könnte aber in der Infrastruktur mit verwendet worden sein. Allerdings habe ich keine Node JS installation.

[hmm]

der download klappt hiermit:

  downLoadFile(data: any, type: string) {
    let blob = new Blob([data], { type: type});
    let url = window.URL.createObjectURL(blob);

    let a_for_download = document.createElement("a");
    a_for_download.href = url;
    a_for_download.download = "output.xml";
    document.body.appendChild(a_for_download);
    a_for_download.click();
    URL.revokeObjectURL(url);
  }

jetzt bin gespannt ob das gzip auch klappt.