Download ohne Nachfrage - klappt nicht immer?

jbrown

Hi,

ich habe einen Dateityp mit einer Anwendung verknüpft und Download ohne Nachfrage eingestellt. Bei einem Link auf einen solchen Dateityp klappt das auch.

Wird die Datei aber über ein (php-)Skript ausgeliefert, erscheint trotzdem der "Öffnen von ..."-Nachfrage-Dialog.

Kann man irgendwo einstellen oder konfigurieren, dass solch ein Download immer ohne Nachfrage erfolgen soll?

(Firefox 3.0.19 unter Linux)

.Ulli

Hallo jbrown,

Willkommen im Forum

Zitat von jbrown

ich habe einen Dateityp mit einer Anwendung verknüpft und Download ohne Nachfrage eingestellt.

Das Internet, so auch das WWW, kennt keine Dateitypen.
Real hast du hier einen vom Server übertragenen Mime-Type mit einer Anwendung verknüpft.

Zitat von jbrown

Bei einem Link auf einen solchen Dateityp klappt das auch.

Weil der Server die Datei mit dem richtigen Mime-Type ausliefert.

Zitat von jbrown

Wird die Datei aber über ein (php-)Skript ausgeliefert, erscheint trotzdem der "Öffnen von ..."-Nachfrage-Dialog.

Wie das Skript auch immer gestaltet sein mag, an dieser Stelle gebricht es ihm an der richtigen Einstellung, denn es wird der falsche Mime-Type ausgeliefert.

Ohne Bekanntgabe eines Links zu der Seite, bzw. des Skripts, ist eine weitere Hilfestellung nicht möglich.

jbrown

Natürlich meinte ich "Mime-Typ" statt "Dateityp".

Direkt gestartet wird die verknüpfte Anwendung hier: http://releases.ubuntu.com/kubuntu/9.10/k…386.iso.torrent

Derselbe Mime-Typ kommt hier: http://www.byte.to/data/download.…032666f98abff67 (denn die Dialog-Box, die nun erscheint, zeigt an, dass genau mit derselben verknüpften Anwendung gestartet wird), aber man muss eben umständlicherweise noch bestätigen, obwohl in der mimeTypes.rdf

Code

NC:alwaysAsk="false"

steht.

Wie erreicht man, dass auch im zweiten Fall keine Abfrage mehr erscheint?

.Ulli

~~Funktioniert hier ohne Problem.~~

~~Gibt es in deinem System Komponenten, wie Proxy etc., die den Header verfälschen können ?~~

Edit: gedanklicher Irrtum, siehe weiter unten.

jbrown

Zitat von .Ulli

Funktioniert hier ohne Problem.

Merkwürdig.

Zitat von .Ulli

Gibt es in deinem System Komponenten, wie Proxy etc., die den Header verfälschen können ?

Nein, kein Proxy.

Hier ist mal der Ausschnitt aus meiner mimeTypes.rdf für mimetypes. Stimmt da evtl. was nicht?

Code

<RDF:Description RDF:about="urn:mimetypes">
    <NC:MIME-types RDF:resource="urn:mimetypes:root"/>
  </RDF:Description>


  <RDF:Seq RDF:about="urn:mimetypes:root">
    <RDF:li RDF:resource="urn:mimetype:application/octet-string"/>
    <RDF:li RDF:resource="urn:mimetype:application/x-bittorrent"/>
  </RDF:Seq>


  <RDF:Description RDF:about="urn:mimetype:application/octet-string"
                   NC:value="application/octet-string"
                   NC:editable="true"
                   NC:description="rar, zip">
    <NC:fileExtensions>rar</NC:fileExtensions>
    <NC:fileExtensions>zip</NC:fileExtensions>
    <NC:handlerProp RDF:resource="urn:mimetype:handler:application/octet-string"/>
  </RDF:Description>


  <RDF:Description RDF:about="urn:mimetype:handler:application/octet-string"
                   NC:alwaysAsk="false"
                   NC:saveToDisk="true">
    <NC:externalApplication RDF:resource="urn:mimetype:externalApplication:application/octet-string"/>
  </RDF:Description>


  <RDF:Description RDF:about="urn:mimetype:externalApplication:application/octet-string"
                   NC:prettyName=""
                   NC:path=""/>


  <RDF:Description RDF:about="urn:mimetype:application/x-bittorrent"
                   NC:fileExtensions="torrent"
                   NC:description="Torrents"
                   NC:value="application/x-bittorrent"
                   NC:editable="true">
    <NC:handlerProp RDF:resource="urn:mimetype:handler:application/x-bittorrent"/>
  </RDF:Description>


  <RDF:Description RDF:about="urn:mimetype:handler:application/x-bittorrent"
                   NC:alwaysAsk="false"
                   NC:saveToDisk="false"
                   NC:useSystemDefault="false"
                   NC:handleInternal="false">
    <NC:externalApplication RDF:resource="urn:mimetype:externalApplication:application/x-bittorrent"/>
  </RDF:Description>


  <RDF:Description RDF:about="urn:mimetype:externalApplication:application/x-bittorrent"
                   NC:path="/usr/bin/torrent.sh"
                   NC:prettyName="torrent.sh"/>

Alles anzeigen

torrent.sh startet dann die Anwendung mit der übergebenen torrent-Datei.

.Ulli

Jetzt auf einem anderen System mit installiertem Transmission angeschaut.

Zitat

http://releases.ubuntu.com/kubuntu/9.10/k…386.iso.torrent
GET /kubuntu/9.10/kubuntu-9.10-desktop-i386.iso.torrent HTTP/1.1
HTTP/1.x 200 OK
Content-Type: application/x-bittorrent
Content-Length: 27657

im Gegensatz zu

Zitat

http://www.byte.to/data/download.…032666f98abff67
GET /data/download.php?id=b65333c904f35428c09811a01032666f98abff67 HTTP/1.1
HTTP/1.x 200 OK
Content-Type: application/x-bittorrent
Content-Disposition: attachment; filename="kubuntu-9 10-desktop-i386.found.on.http://www.byte.to.torrent"

Der Unterschied liegt im Content. Beim ersten Link wird er direkt übertragen - und es funktioniert.

Beim zweiten Link liefert Server den Content nicht direkt sonder via attachment aus, d.h. dieser Content muss an dieser Stelle getrennt angefordert werden - und es funktioniert nicht.

Eine direkte Lösung innerhalb des Fx ist derzeit nicht bekannt.

Mein Irrtum lag in der Erwartungshaltung, "Datei speichern" würde sich identisch verhalten, denn die Dateien wurden jeweils ohne Nachfrage mit vollständigem Inhalt gespeichert.

jbrown

Gäbe es eine Möglichkeit, solche "Content-Disposition: attachment; filename"-Header seitenabhängig rauszufiltern und dadurch einen Download ohne Nachfrage zu erreichen?

boardraider

Beizeiten hatte ich Ähnliches einmal mit Ubiquity zu Testzwecken im Rahmen einer anderen Diskussion umgesetzt. Grundsätzlich sollte dazu eine Erweiterung also in der Lage sein.