Forum: PC Hard- und Software Bilder unter Ubuntu im Originalformat speichern und nicht als .webp


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von SvenS (Gast)


Lesenswert?

Hallo,
wenn ich hier auf der Seite png-Bilder unter Ubuntu und Modzilla FF 
speichern möchte, geht das mit den aktuellen Einstellungen anscheinend 
nur im webp-Format (auf anderen Seiten noch nicht probiert).
z.B. das hier kann nach Rechtsklick ins Bild -> "Grafik speichern als 
..."
https://www.mikrocontroller.net/attachment/527778/geschirmteLoop.png
nur als webp-Datei gespeichert werden.

Weiß jemand, was man machen muss, um Bilddateien im orginalen png-Format 
zu speichern?

von Norbert (Gast)


Lesenswert?

Hmm, problemlos hier (78.13.0esr)

von Jack V. (jackv)


Lesenswert?

Das Problem mit dem genannten Bild: es ist, trotz seines Suffixes, ein 
Web/P-Bild:
1
\`> file geschirmteLoop.png 
2
geschirmteLoop.png: RIFF (little-endian) data, Web/P image
Wenn du ein natives PNG auf die Art speicherst, wird dir korrekt das 
Speichern als *.png angeboten.

: Bearbeitet durch User
von Dussel (Gast)


Lesenswert?

Die Bilder unter Beitrag "Unscharfer Werbetext" sind 
laut Endung png, werden aber als webp gespeichert. Haben es drei Leute 
mit falscher Endung hochgeladen oder passiert doch irgendwo eine 
automatische Konvertierung?

von Jack V. (jackv)


Lesenswert?

Wenn man es über den Link speichert, ist es ebenfalls ein PNG. Nur, wenn 
man das Bild über den Link aufruft, und es dann direkt speichern will, 
ist’s kein PNG. Liegt nicht am FF, die Forensoftware konvertiert’s 
offensichtlich vor dem Ausliefern.

: Bearbeitet durch User
von Der Opa aus der Muppet Show (Gast)


Lesenswert?

> Liegt nicht am FF

Ein Haarspalter könnte antworten, diese Aussage ist nicht korrekt.

Der FF sendet den Header "Accept: ...,image/webp,...".

Du kannst im F12 den Header editieren und erneut senden. Dann bekommst 
du ein PNG.

von SvenS (Gast)


Lesenswert?

Jack V. schrieb:
> Wenn man es über den Link speichert, ist es ebenfalls ein PNG.

Ah, Danke für den Tipp! :)


Der Opa aus der Muppet Show schrieb:
> Du kannst im F12 den Header editieren und erneut senden. Dann bekommst
> du ein PNG.

Auch interessant, Danke!

von bluppdidupp (Gast)


Lesenswert?

Man kann webp-Support auch generell im FF deaktivieren (via 
"about:config" nach "image.webp.enabled" suchen)
Es gibt auch Browserweiterungen um webp im Accept-Header wegzulassen.
Dauerhaft würde ich es allerdings nicht deaktivieren - Das Format spart 
schon teils gut ein gegenüber den "klassischen" Formaten...

von LiberNicht (Gast)


Lesenswert?

bluppdidupp schrieb:
> Man kann webp-Support auch generell im FF deaktivieren (via
> "about:config" nach "image.webp.enabled" suchen)
> Es gibt auch Browserweiterungen um webp im Accept-Header wegzulassen.
> Dauerhaft würde ich es allerdings nicht deaktivieren - Das Format spart
> schon teils gut ein gegenüber den "klassischen" Formaten...

Wobei, damit es wirklich spart, das Bild halt noch einmal durch einen 
verlustbehafteten Schredder gedreht wird.
Merke: HTTP ist offensichtlich ungeeignet, um Daten unverfälscht zu 
transportieren oder aber hat jedenfalls jede Menge Fallstricke. Man 
denke an nicht mehr stimmende Datei-Signaturen usw. "GET asd.png" -> 
"Joah, kriegste n webp, näh"

von michael_ (Gast)


Lesenswert?

Erstmal hat das nichts mit Ubuntu zu tun.
Kann es sein, dass es ein MC.NET Problem ist?
Ich glaube, es ist erst seit einiger Zeit so.
Kann auch am FF liegen.

Ich nehme so ein Bild in die Zwischenablage (WIN) und füge es dann in 
meinen Bildbtrachter (IrvanView) ein.
Dort dann ordentlich abspeichern.

von Der Opa aus der Muppet Show (Gast)


Lesenswert?

> HTTP ist offensichtlich ungeeignet, um Daten unverfälscht zu transportieren

Stimmt. Das Cern wollte mit dem HTTP keine Daten übertragen. Dafür 
hatten die ja FTP.

Die wollten Inhalte, Dokumente mit Hyperlinks übertragen. Auf NeXT 
Workstations und DOS PCs wurden diese Inhalte sowieso unterschiedlich 
dargestellt.

von FS (Gast)


Lesenswert?

LiberNicht schrieb:
> Man
> denke an nicht mehr stimmende Datei-Signaturen usw. "GET asd.png" ->
> "Joah, kriegste n webp, näh"

Auf Dateiendungen sollte man sich nie verlassen, die sind nur reine 
Konvention und dienen als Indikator. Man könnte auch jede andere 
Verwenden oder gar keine. Das Format wird allein durch den Dateiinhalt 
bestimmt.

von Jack V. (jackv)


Lesenswert?

LiberNicht schrieb:
> Wobei, damit es wirklich spart, das Bild halt noch einmal durch einen
> verlustbehafteten Schredder gedreht wird.

WebP muss nicht verlustbehaftet sein. Insofern stellt sich mir hier die 
Frage: wurde das PNG denn wirklich nochmal verlustbehaftet komprimiert, 
so dass Informationen des Bildes verlorengegangen werden, oder stört man 
sich nur an der ungewohnten Endung (und dem Problem, dass veraltete 
Systeme mit dem Format nichts anfangen können)?

Interessanterweise wird mir oben nun in jedem Fall ein PNG zum Download 
angeboten, so dass ich das auch auf die Schnelle nicht selbst nachgucken 
kann.

LiberNicht schrieb:
> Merke: HTTP ist offensichtlich ungeeignet, um Daten unverfälscht zu
> transportieren oder aber hat jedenfalls jede Menge Fallstricke. Man
> denke an nicht mehr stimmende Datei-Signaturen usw. "GET asd.png" ->
> "Joah, kriegste n webp, näh"

Vielleicht möchtest du nochmal nachgucken, wie HTTP funktioniert und ob 
es überhaupt was damit zu tun haben könnte, und ob es einen Unterschied 
zwischen Signatur (hier war wohl eher MIME-Typ gemeint) und Dateinamen 
geben könnte? Dann müsstest du nämlich nicht so einen Blödsinn zum 
Besten geben.

: Bearbeitet durch User
von LiberNicht (Gast)


Lesenswert?

Jack V. schrieb:
> Dann müsstest du nämlich nicht so einen Blödsinn zum
> Besten geben.

Ach so... Das ist eine Sache, die man auf dem Server konfigurieren kann. 
HTTP räumt die Möglichkeit ein, eine "passende" Repräsentation eines 
Dokumentes auszuliefern statt dem originalem Dokument. Das ist das, was 
da oben mit der Grafik passiert. Und es gibt keinerlei Möglichkeit 
Seitens des Clients, zu sagen "Ich will genau das Original". Soviel 
dazu.

von Jack V. (jackv)


Lesenswert?

LiberNicht schrieb:
> HTTP räumt die Möglichkeit ein […]

HTTP ist ein Transportprotokoll. Der Webserver liefert die Datei darüber 
aus, aber welche Datei es ist, darauf hat das verwendete Protokoll 
keinen Einfluss. Und das ist bei jedem Protokoll so, nicht nur beim 
HTTP.

: Bearbeitet durch User
von LiberNicht (Gast)


Lesenswert?

Jack V. schrieb:
> LiberNicht schrieb:
>> HTTP räumt die Möglichkeit ein […]
>
> HTTP ist ein Transportprotokoll. Der Webserver liefert die Datei darüber
> aus, aber welche Datei es ist, darauf hat das verwendete Protokoll
> keinen Einfluss. Und das ist bei jedem Protokoll so, nicht nur beim
> HTTP.

Nein, HTTP definiert einen Satz an Standard-Headern usw.und wie diese zu 
interpretieren sind. Magste hier gucken: 
https://developer.mozilla.org/de/docs/Web/HTTP

von Jack V. (jackv)


Lesenswert?

In diesem Fall war der Aufruf etwa GET /Pfad/zur/Datei.png, und der 
Server hat aus Clientsicht genau /Pfad/zur/Datei.png zurückgegeben. Dass 
da nun WebP drin war, lag nicht am Protokoll.

Deine Behauptung war, dass HTTP nicht geeignet wäre, Daten unverfälscht 
zu übertragen – und das ist nunmal Stuss.

: Bearbeitet durch User
von LiberNicht (Gast)


Lesenswert?

Jack V. schrieb:
> In diesem Fall war der Aufruf etwa GET /Pfad/zur/Datei.png, und der
> Server hat aus Clientsicht genau /Pfad/zur/Datei.png zurückgegeben. Dass
> da nun WebP drin war, lag nicht am Protokoll.

Oh, doch - tut es. Auf dem Server liegt ein png. Das ist halt die 
Freiheit eines HTTP-konformen Servers, das lieber als webp auszuliefern.

> Deine Behauptung war, dass HTTP nicht geeignet wäre, Daten unverfälscht
> zu übertragen – und das ist nunmal Stuss.

Ja, lies es nach. Es gibt keine client-seitige Möglichkeit den Server zu 
zwingen, genau die Datei auszuliefern, die er selbst ausliest. Und das 
ist ein HTTP-Feature: Es kann irgendetwas ausgeliefert werden, was dem 
angefragten Inhalt entspricht.

von Der Opa aus der Muppet Show (Gast)


Lesenswert?

Können wir uns auf die Behauptung einigen, HTTP ist nicht dafür 
konzipiert, Daten unverfälscht zu übertragen.

Vom ersten Tag an hatten die Server unterschiedliche Daten für Lynx und 
Mosaik ausgeliefert. Dann kamen die Javascript Hacks für Navigator oder 
IE. Danach die kompaktere Darstellung für die alten Smartphones. Das 
große Feature das Opera: Deren Proxies komprimierten die Bilder soweit, 
dass es auch mit den damaligen Datenübertragungsraten halbwegs flüssig 
lief...

Problem ist eher, die alten Protokolle, die Daten unverfälscht 
übertrugen, sind verschwunden.

von Jack V. (jackv)


Lesenswert?

Der Opa aus der Muppet Show schrieb:
> Können wir uns auf die Behauptung einigen, HTTP ist nicht dafür
> konzipiert, Daten unverfälscht zu übertragen.

Nope. In dem Fall wäre die Integrität von allem anzuzweifeln, und das 
Netz wäre nicht nutzbar. Kein Download würde vertrauenswürdig sein, 
sämtliche „Cloud“-Daten wären wertlos.

Wir können uns aber darauf einigen, dass der Server etwas anderes 
liefern kann – das ist allerdings kein Problem des Protokolls, sondern 
der Serverkonfiguration. Das Protokoll verfälscht keine Daten auf dem 
Transportweg.

: Bearbeitet durch User
von LiberNicht (Gast)


Lesenswert?

Jack V. schrieb:
> In dem Fall wäre die Integrität von allem anzuzweifeln, und das
> Netz wäre nicht nutzbar.

Wieso das? Das ist genau für Webbrowser ausgelegt und konzipiert. Dafür 
ist der Mechanismus ja auch gut. Man hat eine Resource (die naütrlich 
irgendeinen intrinsischen Typ de-facto hat) und man hat einen Client, 
der bestimmte Inhaltstypen beherrscht. Der Server liefert dann einen für 
den Client geeigneten Inhalt, welcher die Resource repräsentiert, oder 
einen Fehler "Die kannst du leider nicht verarbeiten."
Um Dateien zu übertragen gibt es andere (Anwendungs-)Protokolle.

Jack V. schrieb:
> Das Protokoll verfälscht keine Daten auf dem
> Transportweg.


Für den low-level Transport ist ja auch TCP zuständig. Soweit es HTTP 
betrifft: Auch hier kann die Kodierung für den Transport nach belieben 
angepasst werden.

von Der Opa aus der Muppet Show (Gast)


Lesenswert?

Kommt halt drauf an, ob du den "Accept:" Header als Teil des Protokoll 
betrachtest.

Aber das eigentliche Problem: HTTP war gar nicht für Downloads oder 
Cloud-Storrage gedacht. Dafür gab es ja FTP. Was damals fehlte, war ein 
Protokoll, das Inhalte von Hypertext Dokumenten so auslieferte, dass es 
auf Workstations und Ascii Terminals dargestellt werden konnte.

Download über HTTP ist ein Missbrauch des Protokolls. Die Probleme 
entstehen, weil wir dieses Protokoll für Sachen benutzen, für das es gar 
nicht gedacht war.

von Der Opa aus der Muppet Show (Gast)


Lesenswert?

Anfangs gab es ja URLs für unterschiedliche Protokolle. Aber die anderen 
werden nicht mehr benutzt.
1
http://server/datei
2
ftp://server/datei

https://www.w3.org/Addressing/URL/4.1_Schemes.html

Theoretisch könnten wir auch ein cloudspace://server/datei in den 
Standard aufnehmen.

Beitrag #6794417 wurde vom Autor gelöscht.
von Yalu X. (yalu) (Moderator)


Lesenswert?

Jack V. schrieb:
> Interessanterweise wird mir oben nun in jedem Fall ein PNG zum Download
> angeboten, so dass ich das auch auf die Schnelle nicht selbst nachgucken
> kann.

Bei mit (mit Firefox 91.0) ist es ein verlustloses WebP. JPEGs werden
mitunter ebenfalls als WebP gespeichert, dann aber im verlustbehafteten
Modus.

Sowohl die verlustfreie also auch die verlustbehaftete WebP-Variante ist
meiner Erfahrung nach oft nur etwa halb so groß wie das entsprechende
PNG bzw. JPEG, zudem ist im zweiten Fall trotz der geringeren Dateigröße
i. Allg. die Qualität besser. Insofern ist dieses WebP-Format eine gute
Sache. Auch dass es im Web als Alternativformat zu JPEG und PNG genutzt
wird, um den Traffic zu reduzieren, finde ich prinzipiell in Ordnung.
Etwas blöd ist halt nur, dass noch nicht alle Programme dieses Format
importieren können.

von LiberNicht (Gast)


Lesenswert?

Yalu X. schrieb:
> Insofern ist dieses WebP-Format eine gute
> Sache. Auch dass es im Web als Alternativformat zu JPEG und PNG genutzt
> wird, um den Traffic zu reduzieren, finde ich prinzipiell in Ordnung.
> Etwas blöd ist halt nur, dass noch nicht alle Programme dieses Format
> importieren können.

Ja, für den typischen Browser-Usecase ist das schon sinnvoll. 
Problematisch ist nur, dass zumindest die Referenz-Implementierung von 
WebP zum Dekodieren wirklich das gesamte Bild im Speicher halten muss. 
JPEG braucht für die Dekodierung nur Bildbreite*"kleines X" Bytes an 
Arbeitsspeicher und kann also direkt auf Storage gestreamed werden. Ob 
das jetzt ein implementierungsspezifisches Merkmal ist oder direkt am 
Algorithmus liegt, kann ich nicht sagen.
Problem ist, dass der Client den MIME-Type der Resource nicht kennen 
kann, also ggf. eben webp mit angeben muss, um nicht zu riskieren, dass 
der Server einfach nur einen Fehler zurück liefert. Und wenn der dann 
eben im Zweifel alles in WebP konvertiert, hat man unnötigen 
Resourcen-Verbrauch in speziellen Use-Cases.

von Jack V. (jackv)


Lesenswert?

LiberNicht schrieb:
> Wieso das? Das ist genau für Webbrowser ausgelegt und konzipiert. Dafür
> ist der Mechanismus ja auch gut.

Vielleicht sollte man an dieser Stelle differenzieren: ich argumentiere 
nicht gegen die Tatsache, dass man einen Webserver so konfigurieren und 
einen Aufruf so gestalten kann, dass der Browser nicht von vorneherein 
weiß, was genau er bekommt – aber das kann ich halt jedem anderen 
Protokoll auf diesem Layer im Stack genauso machen.

Ich argumentiere gegen die Behauptung, dass HTTP für eine bitgenaue 
Datenübertragung per se ungeeignet, bzw. eine solche über dieses 
Protokoll nicht möglich wäre. Konkret beziehe ich mich dabei auf:

LiberNicht schrieb:
> Merke: HTTP ist offensichtlich ungeeignet, um Daten unverfälscht zu
> transportieren

… und das ist halt in dieser Absolutheit Unsinn.

von LiberNicht (Gast)


Lesenswert?

Jack V. schrieb:
> Vielleicht sollte man an dieser Stelle differenzieren: ich argumentiere
> nicht gegen die Tatsache, dass man einen Webserver so konfigurieren und
> einen Aufruf so gestalten kann, dass der Browser nicht von vorneherein
> weiß, was genau er bekommt – aber das kann ich halt jedem anderen
> Protokoll auf diesem Layer im Stack genauso machen.

Das Problem ist aber schon vielschichtiger. Es könnte auch eine 
dazwischengeschaltete nginx ihre Senf dazu geben, was beim Client 
ankommt. Oder vllt. ein HTTP-Proxy? Das sind alles Möglichkeiten, die 
sich genau aus der Nutzung von HTTP ergeben. HTTP spricht von Resourcen, 
deren Repräsentation beim Client ankommen muss. Da wirst du nirgendwo 
lesen, dass die Resource unverfälscht wiedergegeben werden muss. TCP 
andererseits stellt als Transportprotokoll sicher, dass das, was 
gesendet wird auch genau das ist, was Empfangen wird. Egal über wie 
viele Hops das Paket gelaufen ist.

Jack V. schrieb:
> LiberNicht schrieb:
>> Merke: HTTP ist offensichtlich ungeeignet, um Daten unverfälscht zu
>> transportieren
>
> … und das ist halt in dieser Absolutheit Unsinn.

Um so dumm zu kommen, weiß jeder, der Lesen kann, sofort, dass HTTP für 
Datentransfer völlig ungeeignet ist, weil es eben kein 
Transportprotokoll ist. Punkt.

von Norbert (Gast)


Lesenswert?

LiberNicht schrieb:
> Um so dumm zu kommen, weiß jeder, der Lesen kann, sofort, dass HTTP für
> Datentransfer völlig ungeeignet ist,

> weil es eben kein Transportprotokoll ist. Punkt.

Na hoffentlich wissen das die beiden letzten Buchstaben des ›HTTP‹ auch.

Fassungslos…

von Der Opa aus der Muppet Show (Gast)


Lesenswert?

Wenn schon Haarspalterei, dann aber richtig zitiert. Der vorletzte 
Buchstabe in "Hypertext Transfer Protocol" steht nicht für Transport.

von Der Opa aus der Muppet Show (Gast)


Lesenswert?

Western Union bietet einen Geldtransfer an. Du legst Euroscheine auf den 
Tresen und in Somalia zahlen sie Schilling aus.

Bei einem Geldtransport müssten sie deine Scheine im Koffer nach Somalia 
transportieren und dort genau deine Scheine dem Empfänger aushändigen.

von Norbert (Gast)


Lesenswert?

Der Opa aus der Muppet Show schrieb:
> Western Union bietet einen Geldtransfer an. Du legst Euroscheine
> auf den
> Tresen und in Somalia zahlen sie Schilling aus.
>
> Bei einem Geldtransport müssten sie deine Scheine im Koffer nach Somalia
> transportieren und dort genau deine Scheine dem Empfänger aushändigen.

Schön, spalten wir ein wenig ;-)

Bei einem Transfer ›Du legst Euroscheine auf den Tresen und in Somalia 
zahlen sie Schilling aus‹ kommt also gar nicht das an was man auf die 
Reise geschickt hat.

Bei einem Transport ›deine Scheine im Koffer nach Somalia … und dort 
genau deine Scheine dem Empfänger‹ hingegen doch.

Also, mir ist ein Transport von Daten lieber als ein Transfer mit 
unvorhersehbaren Wandlungen und Modifikationen. ;-)

Wenn der Transfer jedoch in der Realität einem Transport gleichkommt 
(wie in den RFCs vorgesehen), das ist dann OK.

von LiberNicht (Gast)


Lesenswert?

Norbert schrieb:
> Also, mir ist ein Transport von Daten lieber als ein Transfer mit
> unvorhersehbaren Wandlungen und Modifikationen. ;-)

Im Falle des Webhostings sollte man, wenn man eine Seite gestaltet, 
vermutlich die Resourcen in der Tat selbst in webp konvertieren, wenn 
man das Datenvolumen reduzieren will. Das spart Rechenzeit - nicht, dass 
die Konvertierungsarbeit bei jedem Request im gesamten Internet 
hochgerechnet noch dem Bitcoin-Mining den Rang an Energieverschwendung 
abläuft...

von Jack V. (jackv)


Lesenswert?

LiberNicht schrieb:
> Es könnte auch eine
> dazwischengeschaltete nginx ihre Senf dazu geben, was beim Client
> ankommt. Oder vllt. ein HTTP-Proxy?

Nginx ist ein Webserver, der auch als Proxy konfiguriert werden kann. 
Möchtest du wirklich nicht nochmal selbst gucken, wie das alles 
zusammenhängt, und nicht nur ’n paar Stichworte irgendwo raussuchen, die 
dich zu bestätigen scheinen, solange man den Kontext nicht beachtet?

von Al Fine (Gast)


Lesenswert?

Jack V. schrieb:
> Nginx ist ein Webserver, der auch als Proxy konfiguriert werden kann.
> Möchtest du wirklich nicht nochmal selbst gucken, wie das alles
> zusammenhängt, und nicht nur ’n paar Stichworte irgendwo raussuchen, die
> dich zu bestätigen scheinen, solange man den Kontext nicht beachtet?

Wie was zusammenhangt? HTTP und umgewandelte Resourcen?

von Jack V. (jackv)


Lesenswert?

Al Fine schrieb:
> Wie was zusammenhangt?

Was ein Webserver ist, was ein Proxy ist, was ein Protokoll ist, … 
solche Sachen halt. Du erinnerst dich: er sprach dem HTTP die 
Eigenschaft ab, Daten darüber unverfälscht zu übertragen zu können („… 
ist ungeeignet“) – was ganz offensichtlich Unsinn ist, denn wenn das 
nicht ginge, würde kein Hash einer heruntergeladenen Datei stimmen, kein 
heruntergeladenes Image eines Datenträgers booten, kein 
heruntergeladenes Programm laufen, etc.

Darum ging’s in diesem Nebenfaden der Diskussion.

von LiberNicht (Gast)


Lesenswert?

Jack V. schrieb:
> Du erinnerst dich: er sprach dem HTTP die
> Eigenschaft ab, Daten darüber unverfälscht zu übertragen zu können („…
> ist ungeeignet“)

Wenn Ihre Hoheit sich daran zu erinnern beliebt, dass der Satz dort 
keineswegs sein Ende fand? Wie Ihre Hoheit einerseits als Web-Enwickler 
sicherstellen wollen, dass nicht ein Proxy-Server des Kunden den Inhalt 
vermurkst oder als Kunde, ein Reverse-Proxy des Anbieters, der ggf. noch 
hinter Cloudflare sitzt, unter Benutzung des HTTP-Protokolls vermag sich 
nicht zu erschließen. Funktioniert es doch so, wie intendiert, auch wenn 
das geschieht?

von Der Opa aus der Muppet Show (Gast)


Lesenswert?

> Also, mir ist ein Transport von Daten lieber als ein Transfer mit
> unvorhersehbaren Wandlungen und Modifikationen.

Der Rest der Welt ist zu einer anderen Einschätzung gekommen. Und 
benutzt mehr oder weniger das 7-Schichten Modell der OSI.

Layer 4, der Transport Layer überträgt Daten unverändert. Darüber liegt 
ein Presentation Layer, der die Daten in irgend etwas umwandelt, was für 
Computer und Benutzer lesbar ist.

Früher hatte der Presentation Layer zwischen EBCDIC und Ascii 
konvertiert, heute zwischen Jpeg und Webm. Oder zwischen Quicktime und 
H264.

Alle außer dir sind der Ansicht, Youtube sollte die Videos in dem Format 
ausliefert, das der Rechner abspielen kann. Nicht das Format was der 
Ersteller hochgeladen hat.

Problem ist, wir benutzen einen für Webbrowser optimierten Presentation 
Layer für alles mögliche. Und packen dann noch einen Layer 8 oben drauf, 
der einen Presentation Layer als Transport Layer missbraucht.

von Norbert (Gast)


Lesenswert?

Aha, alle außer mir erwarten WEBM wenn sie Portable Network Graphic 
laden.
Alle außer mir erwarten - ja was eigentlich? - wenn sie ein ISO Image 
herunter laden.
Alle außer mir erwarten konvertierten Gibberish wenn sie sich zB. eine 
Firmware herunter laden.
Cool, wusste ich noch nicht. Aber was lernt man nicht alles im Netz.

von Jack V. (jackv)


Lesenswert?

LiberNicht schrieb:
> Wie Ihre Hoheit einerseits als Web-Enwickler
> sicherstellen wollen, dass nicht ein Proxy-Server des Kunden den Inhalt
> vermurkst oder als Kunde, ein Reverse-Proxy des Anbieters, der ggf. noch
> hinter Cloudflare sitzt, unter Benutzung des HTTP-Protokolls vermag sich
> nicht zu erschließen.

Es ging darum, dass der Narr davon geschwafelt hat, dass das Protokoll 
grundsätzlich ungeeignet zum unverfälschten Übertragen von Daten wäre. 
Will er nun etwas anderes behaupten? Dass die Daten auf dem Transportweg 
von jeder Maschine auf dem Weg manipuliert werden können, ist weder ein 
Geheimnis, noch exklusiv beim HT-Transfer-Protocol so – das Problem 
betrifft alle unverschlüsselten Protokolle. Das ist allerdings nicht der 
Punkt gewesen, wie der Narr sich erinnern möge: der Punkt war, dass man 
über das HTTP sehr wohl Daten unverfälscht übertragen kann.

: Bearbeitet durch User
von LiberNicht (Gast)


Lesenswert?

Jack V. schrieb:
> der Punkt war, dass man
> über das HTTP sehr wohl Daten unverfälscht übertragen kann.

Nein, der Punkt war, dass das Protokoll dafür nicht geeignet ist und 
allerlei Mechanismen hat, die eben dieser Nutzung zuwiederlaufen. Man 
sehe und lerne. Im Gegensatz zu vielen anderen Protokollen widerspricht 
es bei HTTP nicht der inhärenten Zielsetzung, wenn ein Proxy nochmal ein 
wenig was an den Daten herumdreht. Schließlich sagt der Client nur: "Gib 
mir mal irgendeine Darstellung der Resource X, von der du meinst, dass 
sie passen könnte."

von Rolf M. (rmagnus)


Lesenswert?

Der Opa aus der Muppet Show schrieb:
> Was damals fehlte, war ein
> Protokoll, das Inhalte von Hypertext Dokumenten so auslieferte, dass es
> auf Workstations und Ascii Terminals dargestellt werden konnte.
>
> Download über HTTP ist ein Missbrauch des Protokolls.

In den Zeiten, von denen du da oben schreibst, wurde der Hypertext aber 
noch größtenteils nicht dynamisch erstellt. Die Webseiten waren einfach 
Dateien, die der Browser sich runtergeladen hat. Heute wird das ja alles 
dynamisch erzeugt, so dass ein Großteil der übertragenen Daten auf dem 
Server gar nicht als Datei rumliegen. Man hat es also streng genommen 
mehr zum Download von Dateien benutzt als heute.

> Die Probleme entstehen, weil wir dieses Protokoll für Sachen benutzen, für
> das es gar nicht gedacht war.

Ja. Wobei das ja nur der Anfang ist. Man schaue sich Websockets und 
sowas an. Da werden quasi ganze Netzwerkverbindungen durch einen 
http-Stream getunnelt, weil das das einzige Protokoll ist, das fast 
überall durchkommt (z.B. Proxies). Also setzt man eben alles auf http 
drauf, statt es einfach direkt zu übertragen.

von Jack V. (jackv)


Lesenswert?

LiberNicht schrieb:
> Nein, der Punkt war, dass das Protokoll dafür nicht geeignet ist und
> allerlei Mechanismen hat, die eben dieser Nutzung zuwiederlaufen.

Es hat auch Mechanismen, welche die integere Übertragung binärer Daten 
sicherstellen kann – was es sehr wohl auch dafür geeignet macht.

Zum ursprünglichen Zweck:
1
HTTP has been in use by the World-Wide Web global
2
   information initiative since 1990. The first version of HTTP,
3
   referred to as HTTP/0.9, was a simple protocol for raw data transfer
4
   across the Internet.
So sehe und lerne.

von LiberNicht (Gast)


Lesenswert?

Jack V. schrieb:
> Zum ursprünglichen Zweck:HTTP has been in use by the World-Wide Web
> global
>    information initiative since 1990. The first version of HTTP,
>    referred to as HTTP/0.9, was a simple protocol for raw data transfer
>    across the Internet.

Also gut - vor 30 Jahren hättest du vielleicht Recht gehabt.

von Jack V. (jackv)


Lesenswert?

Ich sag’s mal so: man kann dafür sorgen, dass der Client die Daten 1:1 
so bekommt, wie er sie angefragt hat. Damit ist das Protokoll aus meiner 
Sicht grundsätzlich geeignet, Daten unverfälscht zu übertragen, und das 
wird auch milliardenfach gemacht – jeden Tag. Deine gegenteilige 
Behauptung ist also falsch.

Soweit ich das verstanden habe, war einer deiner Punkte, dass der Client 
keinen Einfluss darauf hätte, was der Server tatsächlich liefert. Ja, 
das ist so – bei jedem Protokoll.

Ein Weiterer war, dass auf dem Transportweg Manipulationen stattfinden 
könnten. Ja, das ist so – bei jedem unverschlüsselten Protokoll ohne 
Integritätsprüfung auf anderem Weg.

Was macht also das HTTP ungeeigneter zum Übertragen von Dateien, als 
jedes andere Protokoll mit diesen Einschränkungen (etwa FTP)? Der zweite 
Punkt könnte dabei auch wegfallen, da es im Grunde um HTTPS ging (zur 
Erinnerung: Ausgangspunkt war das Bild, welches falsch ausgeliefert 
wurde – und das erfolgte via HTTPS).

von (prx) A. K. (prx)


Lesenswert?

Die Annahme, FTP übertrage stets unverfälscht, ist übrigens falsch. Von 
Haus aus nimmt eine im ursprünglichen Stil gestartete FTP Session gerne 
an, dass es sich um Textdateien handelt und konvertiert zwischen 
verschiedenen Konventionen der beteiligten Systeme. Will man das nicht 
riskieren, sollte im Kommandoprotokoll auf rein binäre Übertragung 
hingewiesen werden.

: Bearbeitet durch User
von ●DesIntegrator ●. (Firma: FULL PALATINSK) (desinfector) Benutzerseite


Lesenswert?

SvenS schrieb:
> z.B. das hier kann nach Rechtsklick ins Bild -> "Grafik speichern als
> ..."
> https://www.mikrocontroller.net/attachment/527778/geschirmteLoop.png
> nur als webp-Datei gespeichert werden.

wenn man den Link hat, kann man noch

"Ziel speichern unter"

auswählen, dann kommt das auch als png

von foobar (Gast)


Lesenswert?

Image resizing and conversion ist ein Feature von CloudFlare und bei 
Microcontroller.net aktiviert.  Ob und wie konvertiert wird entscheidet 
CloudFlare dynamisch, unter anderem Anhand des Accept- und 
User-Agent-Headers.

HTTP erlaubt das und wird z.B. bei User-Agent-spezifischen Seiten oft 
benutzt (unterschiedliches HTML für Desktop, Handy oder TV).  Es gibt 
auch Header (z.B. Accept oder Accept-Language), mit denen man gezielt 
Varianten anfordern kann.  Ob und wie das genutzt wird entscheidet der 
Seitenbetreiber.  Bei Benutzung von Proxys noch der Proxybetreiber. 
Allerdings braucht es seit der starken Verbreitung von HTTPS schon 
MITM-Proxys wie CloudFlare, um da noch zwischenfunken zu können.

von ●DesIntegrator ●. (Firma: FULL PALATINSK) (desinfector) Benutzerseite


Lesenswert?

Screenshot...

von (prx) A. K. (prx)


Lesenswert?

● Des I. schrieb:
> auswählen, dann kommt das auch als png

Zumindest heisst es so. ;-)

Auf diese Art kriegt man aber u.U. PNGs auf die Disk, die keine sind. 
Ich hatte schon gelegentlich Files, die sich beim Öffnen als anderer Typ 
herausstellten. Mancher Bildbetrachter ist dann so freundlich, es 
umzubenennen.

Das ist ja das hier skizzierte Szenario. Aus dem HTML ergibt sich der 
Name samt Endung. Was der Browser aber tatsächlich kriegt, ist eine 
andere Baustelle. Siehe vorhin zu Cloudflare.

: Bearbeitet durch User
von Rolf M. (rmagnus)


Lesenswert?

(prx) A. K. schrieb:
> Die Annahme, FTP übertrage stets unverfälscht, ist übrigens falsch. Von
> Haus aus nimmt eine im ursprünglichen Stil gestartete FTP Session gerne
> an, dass es sich um Textdateien handelt und konvertiert zwischen
> verschiedenen Konventionen der beteiligten Systeme.

Sie nimmt es nicht nur gerne an, sondern es ist spezifiziert, dass ASCII 
mit CR/LF der Default ist (es gibt in FTP mehr als nur "Text" und 
"Daten"). Wer keine Umwandlung will, muss die erst explizit abschalten.
Kann man alles in RFC959 nachlesen:
https://datatracker.ietf.org/doc/html/rfc959

Man muss bedenken, dass FTP aus einer Zeit stammt, als noch so Dinge wie 
36-Bit-Datenwörter oder EBCDIC nicht unüblich waren. Da konnte man ohne 
eine Konvertierung mit den Daten oft nix anfangen oder sie gar nicht 
erst übertragen.

(prx) A. K. schrieb:
> Das ist ja das hier skizzierte Szenario. Aus dem HTML ergibt sich der
> Name samt Endung. Was der Browser aber tatsächlich kriegt, ist eine
> andere Baustelle. Siehe vorhin zu Cloudflare.

Wobei das dem Browser prinzipiell egal ist. Der geht halt nach dem 
Mimetype. Das Problem ergibt sich erst beim abspeichern, sofern man ein 
System hat, das dabei den mimetype verwirft und später nur noch anhand 
des Namens entscheidet, was das für eine Datei ist.

von Jens G. (jensig)


Lesenswert?

LiberNicht schrieb:
> Jack V. schrieb:
>> Das Protokoll verfälscht keine Daten auf dem
>> Transportweg.
>
> Für den low-level Transport ist ja auch TCP zuständig. Soweit es HTTP
> betrifft: Auch hier kann die Kodierung für den Transport nach belieben
> angepasst werden.

HTTP ist eigentlich für alles nutzbar. Das hat zwar das nette Feature 
der Presentation, aber das kann man ja steuern, bzw. muß es eigentlich 
gar nicht nutzen. Wenn ich etwas binär 1:1 rübergereicht haben will, 
dann gebe ich den Mediatype application/octet-stream an, und gut is. Da 
ist dem System dann klar, daß da nix anderweitig präsentiert werden 
soll.
application/octet-stream wird wohl der Typ sein, der allgemein zum 
Download von binären Daten genutzt wird, die nicht näher spezifiziert 
werden können.

von LiberNicht (Gast)


Lesenswert?

Jens G. schrieb:
> application/octet-stream wird wohl der Typ sein, der allgemein zum
> Download von binären Daten genutzt wird, die nicht näher spezifiziert
> werden können.

Ja, das ist naheliegend. Jedoch keine Garantie, dass das es dir 
Originaldatei ist.
1
The recommended action for an implementation that receives an
2
"application/octet-stream" entity is to simply offer to put the data
3
in a file, with any Content-Transfer-Encoding undone, or perhaps to
4
use it as input to a user-specified process.
https://www.iana.org/assignments/media-types/application/octet-stream

Ein tar.gz zu tar.xz umzukonvertieren wäre doch eine Idee...

von LiberNicht (Gast)


Lesenswert?

Rolf M. schrieb:
> Wobei das dem Browser prinzipiell egal ist. Der geht halt nach dem
> Mimetype. Das Problem ergibt sich erst beim abspeichern, sofern man ein
> System hat, das dabei den mimetype verwirft und später nur noch anhand
> des Namens entscheidet, was das für eine Datei ist.

Dafür gab/gibt es zB den "interpreter" Zusatz im Content-Type.
Ist aber wohl etwas in Verruf geraten:
1
To reduce the danger of transmitting rogue programs, it is strongly
2
recommended that implementations NOT implement a path-search
3
mechanism whereby an arbitrary program named in the Content-Type
4
parameter (e.g., an "interpreter=" parameter) is found and executed
5
using the message body as input.
https://www.iana.org/assignments/media-types/application/octet-stream

Haha. Hahahaha...

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.