Falscher Accept Header

Hallo,

Zitat von supervisior

obwohl er eigentlich:

text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/png,image/svg+xml,*/*;q=0.8

sein sollte.

Die Spezifikation sagt ganz klar, dass der korrekte Accept-Header für Dokumente text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 ist. Das Abweichen von der Spezifikation und von Safari, die das bereits korrekt implementiert hatten, hat in der Vergangenheit Webkompatibilitätsprobleme verursacht. Aus diesem Grund wurde das in Firefox 132 geändert und wird irgendwann in den nächsten Monaten auch für Firefox ESR 128 zurück portiert werden.

Kurzfristig kannst du network.http.accept_include_images via about:config auf true setzen, um das alte Verhalten wiederherzustellen. Aber rechne damit, dass die Option entfernt wird, sobald sich Mozilla sicher ist, dass damit keine größeren Probleme bestehen.

Zitat von supervisior

In den about:config Einstellungen war der Wert für network.http.accept leer und habe probehalber den eigentlich notwendigen Wert eingefügt. Das hat das Problem zwar gelöst, aber das beantwortet die Frage nicht, warum der Wert nicht gesetzt war.

Dieser Schalter ist standardmäßig leer, was bedeutet, dass der Standard-Accept-Header verwendet werden soll. Das ist also ebenfalls korrekt so.

Zitat von supervisior

ist diese besagte Änderung des Accept Headers nicht wirklich nachvollziehbar, geschweige denn für irgendwas nützlich

Diese Aussage entspricht so definitiv nicht der Wahrheit. Abgesehen davon, dass es immer nachvollziehbar ist, Webstandards gemäß Spezifikation zu implementieren (was de facto immer das Ziel sein muss), habe ich dir bereits geschrieben, dass damit Webkompatibilitätsprobleme behoben worden sind.

Zitat von supervisior

Vielmehr wird dadurch der Accept Header gegenstandslos

Auch das stimmt nicht. Wir sprechen hier vom Accept Header für Dokumente. Der Accept Header für Bilder nennt nach wie vor unterstützte Bildformate.

Zitat von supervisior

Wenn es darum geht den Support für bestimmte Image Types zu ermitteln, um fallweise z.B. webp oder avif Bilder anstelle ansonsten typischer Bildformate auszuliefern, galt bislang die im Accept Header angegeben Bild Formate als vergleichsweise sicher. Zumal PHP und das HTTP Protokoll sich genau daran orientieren und es ansonsten wenige bis gar keine Möglichkeit gibt den Support für bestimmte Bild Formate auf einfachste Weise zu ermitteln.

Das galt noch nie als sicher, zumal Safari bereits seit Jahren keine Bildformate im Accept Header für Dokumente nennt, du dich also bereits vorher nicht darauf verlassen konntest. Mobil eingerechnet (und da gelten ausnahmslos alle Browser als Safari) sprechen wir hier von mindestens einem Drittel aller Internetnutzer.

Abgesehen davon sehe ich auch deinen Anwendungsfall nicht. Um Bildformate entsprechend der Kompatibilität auszuliefern, gibt es das picture-Element und srcset-Attribut in HTML. Das ist der übliche Weg, Bilder in unterschiedlichen Formaten bereitzustellen. Das stattdessen über den Accept Header zu lösen, ist eine sehr ungewöhnliche Strategie.

Zitat von supervisior

Für den Fall, dass du es nicht wissen solltest.

Keine Sorge, ich kenne mich damit aus. Ich arbeite auch schon einige Jahre in der professionellen Webentwicklung.

Zitat von supervisior

Die Konsequenzen dieser Änderung sind deswegen weitreichend, sodass Hunderte wenn nicht sogar tausende Programmierungen deswegen nicht mehr funktionieren.

Das ist eine maßlose Übertreibung, die nicht auf Fakten beruht. Wie gesagt gibt es eine sehr viel bessere Alternative, was die Bereitstellung von Bildern in unterschiedlichen Formaten betrifft, und Safari verhält sich bereits seit Jahren so. Außerdem ist es umgekehrt so, dass es vorher Webkompatibilitätsprobleme in Firefox gab, die dadurch behoben wurden. Ich bin bislang auf eine Software gestoßen, die ebenfalls vom Accept Header abhing. Dort habe ich das gemeldet und 3 1/2 Stunden später war das Problem behoben. Ansonsten wurde auch bei Mozilla bislang nicht eine einzige Regression aus dieser Änderung gemeldet, was ungewöhnlich ist, wenn die Konsequenz dieser Änderung so weitreichend sein soll. Aber selbst wenn: Was ist das Schlimmste, was passiert? Dann werden Bilder in einem älteren Format und dadurch mit größerer Dateigröße ausgeliefert. Der Nutzer bekommt davon vermutlich nicht einmal etwas mit. Wenn das nicht das schlimmste Problem ist und Dinge tatsächlich nicht mehr funktionieren, dann hat man als Entwickler die Implementierung ziemlich verbockt, würde ich behaupten. Denn das darf so unter gar keinen Umständen passieren, selbst wenn man sich vom Accept Header abhängig macht. Aber davon gehe ich auch in deinem Fall nicht aus. Denn ansonsten hättest du wohl schon viele Rückmeldungen von Safari- / iOS-Nutzern erhalten, sofern für Safari kein unterschiedlicher Codepfad ausgeführt wird.

Zitat von supervisior

Ich bin eigentlich seit dem ersten Tag ein treuer Anhänger von Firefox, aber diese Änderung ist

Diese Änderung hat mit Firefox nicht das Geringste zu tun. Der Standard der WHATWG gibt das so vor und damit muss das so umgesetzt werden. Die bisherige Implementierung war schlicht und ergreifend ein Fehler. Als Entwickler Fehler vorauszusetzen, ist keine gute Strategie. Und nochmal: Firefox ist nicht der einzige Browser, der sich an den Standard hält. Nachdem Chromium jetzt die einzige Plattform ist, welche den Standard missachtet, kannst du sogar davon ausgehen, dass Google und damit ausnahmslos alle Chromium-basierten Browser früher oder später folgen werden.

Zitat von supervisior

sorry für die Ausdrucksweise, Bullsh**.

Alleine die Tatsache, dass du eine Änderung nicht verstehst, rechtfertigt mit Sicherheit nicht den Einsatz von Fäkalsprache. Zumal es ja nun wirklich keine zwei Meinungen darüber geben sollte, dass Browser die Einhaltung von Webstandards anstreben sollten. Schon gar nicht, wenn man Entwickler ist, wovon ich bei dir ausgehe, wenn du so ein Thema eröffnest. Als Entwickler wäre das nämlich eine sehr unprofessionelle Einstellung.