mikrocontroller.net

Forum: PC Hard- und Software Linux: Warum werden manche Archive nach dem Download vom Editor geöffnet?


Autor: Uhu U. (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich erlebe es immer wieder: nach dem Download z.B. eines .tar.gz-Archivs 
öffnet sich der Texteditor und mault, er könnte mit dem Format nichts 
anfangen.

Allerdings sind die Fälle häufiger, in denen sich das passende Programm 
nach dem Download öffnet.

Was ist der Unterschied?

Autor: Thomas Z. (thomas_z41)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Meine Glaskugel sagt: Der Webserver sendet den falschen MimeType.

Autor: Rolf M. (rmagnus)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Meine Glaskugel stimmt dem zu.

Autor: Torsten C. (torsten_c) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Meine auch.
@Uhu:
Auf der Festplatte entscheidet sich die SW anhand der Dateiendung.
Nun sind ".tar.gz" aber keine Dateiendung, das sind nur die letzten 
Zeichen der URL. Daher schaut der Browser auf den MimeType im 
HTTP-Response-Header.

Die letzten Zeichen der URL könnten auch …oller.net sein.
Da kommt dann z.B. der MimeType HTML onhne *.html-Endung.

Das ist nicht nur bei Linux (siehe Betreff) so, sondern immer.
Probiere es mit Windows aus, dann wissen wir, ob unsere Glaskugeln Recht 
hatten.

: Bearbeitet durch User
Autor: Uhu U. (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Datei war ein Update für LibreOffice - die sollten doch eigentlich 
wissen, wie man das richtig macht?

Windos hab ich keins.

: Bearbeitet durch User
Autor: Rolf M. (rmagnus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hast du mal einen Link? Dann könnte man sich den http-Header mal 
anschauen.

Autor: Uhu U. (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
https://www.libreoffice.org/download/download/?lan...
Dort die 64-Bit deb-Version auswählen.

Autor: Rolf M. (rmagnus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hmm, da ist es etwas schwierig, sich das anzuschauen. Der erste Link 
macht eine Webseite auf, auf der dann ein weiterer Download-Link 
automatisch geöffnet wird:
http://download.documentfoundation.org/libreoffice...

Der wiederum verweist auf mehrere Mirrors. Die geben dann 
unterschiedliche Mimetypes zurück. Bei 
https://mirror1.hs-esslingen.de/pub/Mirrors/tdf/li...
ist es z.B.:
  HTTP/1.1 200 OK
  Date: Thu, 11 Jan 2018 20:41:33 GMT
  Server: Apache/2.4.29 (Fedora)
  Last-Modified: Wed, 13 Dec 2017 20:44:43 GMT
  ETag: "10b7e664-5603ed64d40d5"
  Accept-Ranges: bytes
  Content-Length: 280487524
  Keep-Alive: timeout=10, max=500
  Connection: Keep-Alive
  Content-Type: application/x-gzip

Bei 
https://mirror.kumi.systems/tdf/libreoffice/stable... 
dagegen ist es:
 HTTP/1.1 200 OK
  Server: nginx
  Date: Thu, 11 Jan 2018 20:44:32 GMT
  Content-Type: application/octet-stream
  Content-Length: 280487524
  Last-Modified: Wed, 13 Dec 2017 20:44:43 GMT
  Connection: keep-alive
  ETag: "5a31913b-10b7e664"
  Strict-Transport-Security: max-age=63072000; includeSubDomains; preload
  X-Frame-Options: SAMEORIGIN
  X-Content-Type-Options: nosniff
  X-XSS-Protection: 1; mode=block
  Accept-Ranges: bytes

Es kann also je nach Mirror auch noch unterschiedliches passieren.

Autor: Uhu U. (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Rolf M. schrieb:
> Es kann also je nach Mirror auch noch unterschiedliches passieren.

Ich habe eben mal 3 Downloads angekickt und wieder abgebrochen, nachdem 
ich gesehen hatte, womit die Datei anschließend geöffnet werden soll: 2 
mal wars korrekt der Archiver, einmal der Editor.

Der Server mirror.kumi.systems war der Übeltäter.

: Bearbeitet durch User
Autor: Axel S. (a-za-z0-9)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Uhu U. schrieb:
> Ich erlebe es immer wieder: nach dem Download z.B. eines .tar.gz-Archivs
> öffnet sich der Texteditor
...
> Allerdings sind die Fälle häufiger, in denen sich das passende Programm
> nach dem Download öffnet.

Das hat nichts mit Linux zu tun, sondern in erster Linie mit dem 
Programm, das den Download durchführt. Die normal zu erwartende Aktion 
(und immer auch eine auswählbare Option) ist das Abspeichern der Datei 
auf der Festplatte. Wobei man dann auch einen Ordner (vulgo: Directory) 
vorgeben kann.

Natürlich kann man einen Firefox oder Crome oder $YOUNAMEIT auch kaputt 
konfigurieren. Und vielleicht kann ein Webbrowser sogar den Mimetype, 
den der Webserver sendet, für die Auswahl der Aktion verwenden (obwohl 
es schlauer ist, den Mimetype nach dem Download anhand des Inhalts der 
Datei festzustellen).

Sag uns also, was genau du machst, dann können wir dir auch raten.

Autor: Uhu U. (uhu)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Axel S. schrieb:
> Sag uns also, was genau du machst, dann können wir dir auch raten.

Das kannst du doch oben nachlesen...

Ich lade den Update herunter und anschließend öffnet sich ein Programm, 
das dieses .tar.gz-Ding weiterverarbeiten soll.

Einer von zwei Servern, den die Downloadseite irgendwie auswählt, 
schickt den falschen Mime-Type und die Folge ist, dass nicht der 
Archiver gestartet wird, sondern der Editor - der Server hat FF 
angelogen.

Ich beobachte das nicht nur bei LibreOffice, sondern immer wieder bei 
allem möglichen anderen Zeug. Weiß der Teufel, warum gepackte Dateien 
immer wieder als application/octet-stream gesendet werden.

> dann können wir dir auch raten.

Ich kann da gar nichts machen, außer die Serverbetreiber auf den Fehler 
hinzuweisen. Obs was hilft, steht in den Sternen.

: Bearbeitet durch User
Autor: Andreas B. (bitverdreher)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bei Firefox kann man das Verhaltune von heruntergeladenen Dateien unter 
"Einstellungen" -> "Anwendungen" einstellen.

Autor: Uhu U. (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das ist aber nutzlos, wenn der Server einen falschen Mime Type 
übermittelt.

Autor: guest (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Uhu U. schrieb:
> Das ist aber nutzlos, wenn der Server einen falschen Mime Type
> übermittelt.

Aber nur wenn er das tatsächlich tun würde. "application/octet-stream" 
ist völlig korrekt für eine downloadbare Datei. Mein FF fragt bei obigem 
Link z.B. ob er die Datei mit 7zip öffnen oder irgendwohin speichern 
soll.

Autor: Uhu U. (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
guest schrieb:
> "application/octet-stream" ist völlig korrekt für eine downloadbare Datei.

Nicht für ein zip-Archiv...

Autor: Rolf M. (rmagnus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Uhu U. schrieb:
> guest schrieb:
>> "application/octet-stream" ist völlig korrekt für eine downloadbare Datei.
>
> Nicht für ein zip-Archiv...

Naja, sagen wir mal so: Falsch ist es nicht direkt, aber sinnvoll auch 
nicht. Letztendlich könnte man im Prinzip für alles, was irgendwie 
download- oder übertragbar ist, application/octet-stream angeben, denn 
es ist ja prinzipiell ein Stream aus Oktetts. Das würde allerdings den 
Sinn und Zweck von Mimetypes ad absurdum führen.

Autor: Axel S. (a-za-z0-9)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Uhu U. schrieb:
> Axel S. schrieb:
>> Sag uns also, was genau du machst, dann können wir dir auch raten.
>
> Das kannst du doch oben nachlesen...
>
> Ich lade den Update herunter

Mit welchem Programm tust du das?

Wenn ich ein Update zu irgend etwas herunter lade, dann nehme ich 
bevorzugt die Paketverwaltung (für mich also aptitude). Und für 
generelle HTTP-Download am ehesten wget:
$wget http://download.documentfoundation.org/libreoffice/stable/5.4.4/deb/x86_64/LibreOffice_5.4.4_Linux_x86-64_deb.tar.gz
...

> und anschließend öffnet sich ein Programm,
> das dieses .tar.gz-Ding weiterverarbeiten soll.

Bei mir nicht.
...
HTTP request sent, awaiting response... 302 Found
Location: ...
Resolving mirror.irq1.org (mirror.irq1.org)... 88.198.84.4
Connecting to mirror.irq1.org (mirror.irq1.org)|88.198.84.4|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 280487524 (267M) [application/x-gzip]
Saving to: ‘LibreOffice_5.4.4_Linux_x86-64_deb.tar.gz’

Es gibt einen HTTP-Redirect. Dem läuft wget hinterher. Und das File vom 
Mirrorserver legt es brav im aktuellen Verzeichnis ab. Was anderes 
sollte es tun? Und: selbst wenn dein Browser etwas anderes macht: willst 
du das wirklich? Was ist jetzt gleich nochmal der Vorteil, wenn du den 
Inhalt des .tar.gz in einem "Archiver" (ich traue mich gar nicht zu 
fragen, was du damit meinst) anzeigt?

Wolltest du nicht eigentlich das Update installieren? Tut das dein 
"Archiver"? Ach, nein? Sowas!1!elf!!

> der Server hat FF angelogen.

OMG! Call The Police! The Scoundrel Lied!!!1!eins

> Ich beobachte das nicht nur bei LibreOffice, sondern immer wieder bei
> allem möglichen anderen Zeug. Weiß der Teufel, warum gepackte Dateien
> immer wieder als application/octet-stream gesendet werden.

Der Fehler liegt nach wie vor auf deiner Seite. Weil dein Browser 
(welcher, verdammt noch mal, wie oft soll ich noch fragen?) den 
Content-Type "application/octet-stream" glaubt, an einen Texteditor 
(LOL?!) weitergeben zu müssen.

Der MIME Type sollte eigentlich selbsterklärend sein. Aber sei es drum. 
"application" steht für "application defined" aka "anwendungsspezisch" 
und "octet stream" für "Folge von Bytes".

Ich bin mir gerade nicht sicher was man in welcher Menge getrunken 
haben muß, um das für die geeignete Eingabe für einen Texteditor zu 
halten. Aber gesundheitsfördernd ist das sicher nicht.

> Ich kann da gar nichts machen

Na klar. Du kannst deinen Browser passend konfigurieren. Wiewohl ich 
gerade lernen durfte, daß Firefox kein Werkzeug zum (sinnvollen) 
Bearbeiten der Zuordnung von MIME-Type und Action an Bord hat. Oder als 
Extension. So glaubt mein Firefox bspw. daß application/octet-stream 
ein PDF-Dokument sei (keine Ahnung wie der darauf kommt). Und es gibt 
keine Möglichkeit, ihn mit Bordmitteln diese Verknüpfung vergessen zu 
lassen. OK, ich kann ein .RDF File editieren. Du solltest dich 
vielleicht bei den Firefox-Leuten beschweren (lies: einen Bugreport 
schreiben). OH, verzeih. Da bin ich doch glatt davon ausgegangen, daß du 
Firefox benutzt. Obwohl du das so konsequent verschwiegen hast.

Aber auch wennn du den so grauenhaft verstümmelten Firefox Browser 
benutzen solltest, kannst du trotzdem (unter Edit->Preferences, Reiter 
"applications") die Action für application/octet-stream auf 
(sinnvollerweise) "save file" stellen. Notfalls halt "Always ask".

Autor: guest (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Uhu U. schrieb:
> Nicht für ein zip-Archiv...

Doch, auch für Zip ist das prinzipiell korrekt:
https://www.iana.org/assignments/media-types/appli...
[pre]
The "octet-stream" subtype is used to indicate that a body contains
arbitrary binary data.
{/pre]
Und das trifft definitiv auch auf .gz Dateien zu.

Geneu genommen macht es sogar der andere Server auf jeden Fall verkehrt. 
"application/x-gzip" war vor Urzeiten eine Idee in irgendeinem Draft, 
die seit mindestens 5 Jahren obsolet ist. Korrekt wäre eigentlich 
"application/gzip". Generell sind alle "x-" Typen 'deprecated', wenn 
schon unregistrierte Typen verwendet werden, dann mit "x."

Die offiziell registrierten Typen gibt es hier:
https://www.iana.org/assignments/media-types/media...

Autor: Uhu U. (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
guest schrieb:
> Geneu genommen macht es sogar der andere Server auf jeden Fall verkehrt.

Eine .tar.gz ist ein geziptes tar-Archiv. Entsprechend enthält es eine 
Sammlung von zig .deb-Files und eine Readme, die beschreibt, wie man den 
Inhalt installiert.

Nachdem Firefox diese Datei heruntergeladen hat, ruft er das zum 
Mimetype gehörige Programm auf und das ist für .tar.gz definitiv nicht 
der Editor - das macht der andere Server also definitiv richtig.

Wenn also der Archiver gestartet ist, entpackt man den Inhalt 
sinnvollerweise nach /tmp, liest die Readme und führt das dort 
aufgeführt dpkg aus - fertig ist die Laube.

Dazu muss man nicht mit wget rumfrickeln.

Autor: guest (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Uhu U. schrieb:
> das macht der andere Server also definitiv richtig.

Nö, der liefert einen ungültigen content type. Wenn dann Dein Browser 
trotzdem was sinnvolles zaubert hast Du einfach nur Schwein, ändert aber 
nichtsd daran, daß der Server nicht den eigenlich richtigen Typ ohne das 
"x-" vor dem "gzip" liefert.
Und wenn Du Deine Konfiguration so dermaßen versaust, daß Dein Browser 
mit dem allgemeineren, aber trotzdem korrekten 
"application/octet-stream" nichts anfangen kann, dann gib nicht dem 
Server die Schuld sondern bring erstmal Deinen eigenen Mist in Ordnung.

Autor: Rolf M. (rmagnus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
guest schrieb:
> Uhu U. schrieb:
>> Nicht für ein zip-Archiv...
>
> Doch, auch für Zip ist das prinzipiell korrekt:
> https://www.iana.org/assignments/media-types/appli...
> [pre]
> The "octet-stream" subtype is used to indicate that a body contains
> arbitrary binary data.
> {/pre]

Also zu deutsch in etwa: Das ist irgendwas, und ich hab absolut keine 
Ahnung, was da drin stecken könnte. Da könnte man den Content-Type auch 
einfach komplett weglassen. Das wäre genauso informativ.
Also: Korrekt, aber nutzlos.

> Und das trifft definitiv auch auf .gz Dateien zu.

Wenn der Server aus dem Mittelalter kommt, könnte man sich vielleicht 
vorstellen, dass er mit gzip-Files nun mal so gar nix anzufangen weiß 
und deshalb sagen muss: "Keine Ahnung, sind halt irgendwelche Bytes mit 
Daten drin..."

Autor: Thomas Z. (thomas_z41)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Zur Lösung des Problems:
du hast deinem Browser wahrscheinlich einmal gesagt, dass er 
application/octet-stream mit einem Editor öffenen soll.

Dies musst du einfach wieder rückgängig machen. Im Firefox geht das 
unter Preferences -> Applications, nach octet-stream suchen und 
Einstellung entsprechend ändern.

Autor: Ralf D. (doeblitz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Rolf M. schrieb:
[application/octet-stream]
> Also zu deutsch in etwa: Das ist irgendwas, und ich hab absolut keine
> Ahnung, was da drin stecken könnte. Da könnte man den Content-Type auch
> einfach komplett weglassen. Das wäre genauso informativ.
> Also: Korrekt, aber nutzlos.

Falsch. Es bedeutet "das sind Binärdaten, für die es keine 
wohldefinierte Interpretation in diesem Kontext gibt". Und das wird seit 
ewigen Zeiten für Daten genutzt, die primär für den Download, also die 
uninterpretierte Speicherung auf Client-Seite, gedacht sind.

>
>> Und das trifft definitiv auch auf .gz Dateien zu.
>
> Wenn der Server aus dem Mittelalter kommt, könnte man sich vielleicht
> vorstellen, dass er mit gzip-Files nun mal so gar nix anzufangen weiß
> und deshalb sagen muss: "Keine Ahnung, sind halt irgendwelche Bytes mit
> Daten drin..."

Oder dass der Admin des Servers das eben besser wusste.

Klar, das ist ein komprimiertes tar-Archiv, aber rein formal würde man 
das am saubersten eben als "application/x.tar" (wenn es denn dafür eine 
Registrierung gäbe) mit einem transport-encoding "gzip" verwenden.

Dummerweise führt das dann aber mit sehr hoher Wahrscheinlichkeit dazu, 
dass auf Client-Seite die Daten erst einmal dekomprimiert und dann erst 
weiterverabeitet werden. Und Download-Daten will man üblicherweise in 
der komprimierten Form speichern, nicht in der dekomprimierten - was der 
Browser eigentlich als einzige Möglichkeit anbieten kann (außer der 
direkten Weiterverarbeitung), da die Umkehrung der Transport-Kodierung 
ja von Browser zu erledigen ist. :-(

Also bräuchte man eher einen MIME-Type für "gzip-komprimiertes 
tar-Archiv" (denn es aber AFAIK nicht gibt). Dann könnte man 
clientseitig sinnvoll zwischen einfacher Speicherung des komprimierten 
Archivs oder seiner Verarbeitung durch irgendein anderes Programm 
entscheiden. Und wenn es so einen speziellen Typ für die Anwendungsdaten 
nicht gibt, dann verwendet man dafür seit ewigen Zeiten ... TADA ... 
eben genau "application/octet-stream".

Working as designed - wenn man nicht am Client Mist konfiguriert (wie ja 
auch schon von anderer Seite angemerkt wurde).

Autor: Rolf M. (rmagnus)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Ralf D. schrieb:
> Rolf M. schrieb:
> [application/octet-stream]
>> Also zu deutsch in etwa: Das ist irgendwas, und ich hab absolut keine
>> Ahnung, was da drin stecken könnte. Da könnte man den Content-Type auch
>> einfach komplett weglassen. Das wäre genauso informativ.
>> Also: Korrekt, aber nutzlos.
>
> Falsch. Es bedeutet "das sind Binärdaten, für die es keine
> wohldefinierte Interpretation in diesem Kontext gibt".

Das ist die gleiche Aussage, nur nicht umgangssprachlich formuliert.

> Und das wird seit ewigen Zeiten für Daten genutzt, die primär für den
> Download, also die uninterpretierte Speicherung auf Client-Seite, gedacht > 
sind.

Das sollte meiner Meinung nach auf Client-Seite entschieden werden und 
nicht auf Serverseite. Warum muss mir denn der Server vorschreiben, dass 
ich das nicht einfach direkt vom Browser aus öffnen darf, sondern es 
erst irgendwo speichern, dann in einem separaten Fenster dorthin 
navigieren, draufklicken und nach der Installation wieder manuell 
löschen muss?

> Klar, das ist ein komprimiertes tar-Archiv, aber rein formal würde man
> das am saubersten eben als "application/x.tar" (wenn es denn dafür eine
> Registrierung gäbe) mit einem transport-encoding "gzip" verwenden.

Du meinst vermutlich Transfer-Encoding, aber um sowas geht es doch gar 
nicht. Transfer-Encoding dient dazu, dass der Server es beim Senden 
on-the-fly komprimieren kann und der Empfänger dann weiß, dass er es 
erstmal wieder dekomprimieren muss, um an das Original zu kommen. Hier 
ist aber das Original bereits gzip-komprimiert.

> Dummerweise führt das dann aber mit sehr hoher Wahrscheinlichkeit dazu,
> dass auf Client-Seite die Daten erst einmal dekomprimiert und dann erst
> weiterverabeitet werden.

Ja, weil Transfer-Encoding das völlig falsche Mittel dafür ist.

> Also bräuchte man eher einen MIME-Type für "gzip-komprimiertes
> tar-Archiv" (denn es aber AFAIK nicht gibt).

Den bräuchte man. Müsste dann am ehesten sowas wie application/tar+gzip 
sein. Wobei es einen gzip-Suffix wohl auch bisher nicht gibt.

: Bearbeitet durch User
Autor: Ralf D. (doeblitz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Rolf M. schrieb:
[...]
>> Und das wird seit ewigen Zeiten für Daten genutzt, die primär für den
>> Download, also die uninterpretierte Speicherung auf Client-Seite, gedacht >
> sind.
>
> Das sollte meiner Meinung nach auf Client-Seite entschieden werden und
> nicht auf Serverseite.

IBTD. Wer Daten bereitstellt, der hat dabei ja eine gewisse Intention, 
und die beeinflußt natürlich auch, wie er die Daten bereitstellt. Bei 
EMails kannst du z.B. als Absender entscheiden, ob Attachment inline 
gezeigt oder extern gespeichert werden sollen.

> Warum muss mir denn der Server vorschreiben, dass
> ich das nicht einfach direkt vom Browser aus öffnen darf, sondern es
> erst irgendwo speichern, dann in einem separaten Fenster dorthin
> navigieren, draufklicken und nach der Installation wieder manuell
> löschen muss?

Das kannst du natürlich machen, nur sagt hier eben der Publisher via 
Server/MIME-Type, daß diese Daten primär nicht zur 
Darstellung/Verwendung im Browser (ggfls. mittels Hilfsprogramm) gedacht 
sind, sondern für externe Verwendung. Ob du die speicherst, via 
Datenträger auf ein anderes Gerät überträgst und dort dann installierst 
oder direkt vom Browser aus an ein Installationsprogramm verfütterst ist 
ganz alleine deine Entscheidung (hängt halt von der konkreten 
Client-Implementierung ab).

>> Klar, das ist ein komprimiertes tar-Archiv, aber rein formal würde man
>> das am saubersten eben als "application/x.tar" (wenn es denn dafür eine
>> Registrierung gäbe) mit einem transport-encoding "gzip" verwenden.
>
> Du meinst vermutlich Transfer-Encoding,

ACK

> aber um sowas geht es doch gar
> nicht. Transfer-Encoding dient dazu, dass der Server es beim Senden
> on-the-fly komprimieren kann und der Empfänger dann weiß, dass er es
> erstmal wieder dekomprimieren muss, um an das Original zu kommen. Hier
> ist aber das Original bereits gzip-komprimiert.

Jein. Das Transfer-Encoding kann gerade bei komprimierten Daten auch bei 
vorkomprimierten Daten zur Anwendung kommen. Man muß also kein x.tar auf 
dem Server lagern, das dann on-the-fly mittels gzip komprimiert wird, 
sondern kann dies genauso gleich mit x.tar.gz machen. BTDT, ist nicht 
unüblich, da es auf dem Server natürlich Rechenleistung spart.

>> Dummerweise führt das dann aber mit sehr hoher Wahrscheinlichkeit dazu,
>> dass auf Client-Seite die Daten erst einmal dekomprimiert und dann erst
>> weiterverabeitet werden.
>
> Ja, weil Transfer-Encoding das völlig falsche Mittel dafür ist.
>
>> Also bräuchte man eher einen MIME-Type für "gzip-komprimiertes
>> tar-Archiv" (denn es aber AFAIK nicht gibt).
>
> Den bräuchte man. Müsste dann am ehesten sowas wie application/tar+gzip
> sein. Wobei es einen gzip-Suffix wohl auch bisher nicht gibt.

Eben. Und damit landen wir dann wieder beim klassischen Fallback 
"application/octet-stream". Muss man halt einfach so hinnehmen, dessen 
Semantik nach Jahrzehnten ändern zu wollen, wäre unrealistisch und 
kontraproduktiv.

Autor: Uhu U. (uhu)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
guest schrieb:
> Und wenn Du Deine Konfiguration so dermaßen versaust,

Die habe ich nie angefaßt. Das Profil, das ich benutze ist allerdings 
schon ziemlich alt - von einer Linux-Version zur nächsten migriert...

Im Übrigen bringt ja der zweite Server, der dieselbe Datei verbreitet 
als Mimetype application/x-gzip.

Rolf M. schrieb:
> Da könnte man den Content-Type auch einfach komplett weglassen. Das wäre
> genauso informativ.

So ist es.


Ich habe mir jetzt mal die Tabelle "Applications
Choose how Firefox handles the files you download from the web or the 
applications you use while browsing."
näher angesehen - dort steht nichts über application/octet-stream. Beim 
Download öffnet sich ein Fenster, das abfragt, ob die Datei nur 
gespeichert werden soll, oder mit der jeweils vorgeschlagenen 
Applikation geöffnet werden soll - da liegt der Fehler. Offenbar holt FF 
sich die Information vom System (Mint 17) - auch dort habe ich nie Hand 
angelegt.

: Bearbeitet durch User
Autor: guest (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Rolf M. schrieb:
> Wobei es einen gzip-Suffix wohl auch bisher nicht gibt.

Wohl doch: https://www.iana.org/assignments/media-types/appli...

Uhu U. schrieb:
> Im Übrigen bringt ja der zweite Server, der dieselbe Datei verbreitet
> als Mimetype application/x-gzip.

Und genau das ist eigenlich verkehrt da 'x-gzip' ein nicht registrierter 
experimenteller Subtype ist und darüber hinaus so - mit dem '-' - schon 
seit Ewigkeiten eigenlich nicht mehr verwendet werden soll. Wenn schon, 
dann sollte der Server 'x.gzip' (mit '.') verwenden oder noch besser das 
dafür offiziell registrierten 'gzip'. Du hast einfach Glück, daß die 
Browser-Entwickler so gnädig sind und das 'x-' einfach ignorieren 
(sofern der Rest dann noch irgendwas sinnvolles darstellt).

Und ja, sinnvollerweise sollte auch der andere Server 'application/gzip' 
verwenden. Ändert aber nichts daran, daß 'application/octet-stream' 
trotzdem ebenfalls korrekt ist.

Uhu U. schrieb:
> Offenbar holt FF
> sich die Information vom System (Mint 17) - auch dort habe ich nie Hand
> angelegt.

siehe z.B.: 
https://www.faqforge.com/linux/change-default-appl...

Autor: Rolf M. (rmagnus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
guest schrieb:
> Rolf M. schrieb:
>> Wobei es einen gzip-Suffix wohl auch bisher nicht gibt.
>
> Wohl doch: https://www.iana.org/assignments/media-types/appli...

Das ist ein Subtyp, kein Suffix.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.