Neues nicht-transparentes favicon.ico wirkt nicht

[Linuchs]

Hallo,

mein favicon.ico war rotes Symbol auf transparentem Grund.

Nun hat vor einiger Zeit der Firefox die Hintergrundfarbe der passiven Tab Reiter gewechselt und das Symbol ist schlecht zu erkennen

Also habe ich dem einen weißen Hintergrund verpasst und natürlich korrekt hochgeladen: https://remso.eu/favicon.ico

Doch das alte Logo wird in den Tab Reitern gezeigt, obwohl ich den FF morgens neu starte.

Auch beim Pale Moon (den ich extrem selten nutze) das alte Logo. Allerdings gut erkennbar auf hellgrauem Grund.

Woran kann das liegen?

Offenbar kann ich bei der Vielzahl der Browser nicht erwarten, das sich irgend eine beliebige Farbe vom Hintergrund abhebt, also muss ich den Hintergrund mitliefern?

Gruß, Linuchs

[Fred]

Hi, ich habe die Seite gerade (erstmals) aufgerufen, da ist definitiv ein favicon mit transparentem Hintergrund.
Zum Testen bietet sich der "private Modus" der Browser an...

Gruß
Fred

[Raketenwilli]

Jepp! Dto in Gimp, abgeholt mit wget: also garantiert NICHT aus einem Cache. Das Favicon hat Transparenz...

[Linuchs]

Jepp! Dto in Gimp, abgeholt mit wget: also garantiert NICHT aus einem Cache. Das Favicon hat Transparenz...

Dann liefert der Server was Altes aus? Mir ist nicht bekannt, dass der einen Cache für Web-Sendungen hat.

Das nicht-transparente, neue favicon.ico ist lt. Filezilla vom 05.02.2022, das alte (jetzt umbenannt in favicon.ico_transparent) vom 25.10.2013

Also gut, Zusatz ?t=1auf der problematischen Seite:

  <link rel="shortcut icon" href="favicon.ico?t=1">

Fehler bleibt.

Wird .ico_transparent als .ico missdeutet? Also umbenannt in favicon-ico-transparent Fehler bleibt. Ich versteh's nicht.

[Raketenwilli]

Das sieht so aus, als wäre die Datei „favicon.ico“, welche der Server ausliefert, nicht diejenige, von welcher Du denkst, dass er diese ausliefern sollte.

Überprüfe doch mal, ob Du diese richtig hochgeladen hast. Vielleicht ein Irrtum bezüglich des Zielverzeichnisses?

Was sagt Dein Hoster bezüglich Uploads? Kommen diese vielleicht erst einmal „irgendwohin“ und werden nach diversen Prüfungen IRGENDWANN ins Document-Root verschoben oder kopiert? (Bei T-Online gab es derlei meiner Erinnerung nach im vorigen Jahrtausend, damals waren aber laut Kundendienst Linux-Server mit Apache und so weiter, „ein zukünftiges Projekt“).

[Raketenwilli]

Überprüfe mal: Hochladen, (im Browser abrufen)

<?php
# file: /RealDocumentRoot.php
header "Content-Type: text/plain");
echo realpath( $_SERVER['DOCUMENT_ROOT'] );

Aufruf mit http[s]://SERVER/RealDocumentRoot-php

und per SSH in das (vermeintliche) Document-Root wechseln und dann:

~> pwd -P

ausführen.

→ Wenn die Zeile im Browser nicht mit der Ausgabe in der Shell übereinstimmt, dann ist Dein vermeintliches Document-Root nicht das tatsächliche Document-Root.

Auch mit einem Shell-FTP-Client kann man (je nach Client und Server: hoffentlich) etwas wie

site exec pwd -P

versuchen. Ansonsten hilft Dir nur die Dokumentation oder der Support des Hosters.

Frag den gleich mal, ob da eventuell mod_speling mitläuft. Das sorgt auch für Irrtümer… Ebenso solltest Du fragen, ob der Hoster vielleicht einen (aggressiven) Reverse-Proxy laufen hat, der halt altes Zeug ausliefert.

In dem Fall kannst Du noch folgendes versuchen:

<?php
# File: /favicon.php
header( 'Content-Type: image/vnd.microsoft.icon');
header( 'X-Test-DateTime: ' .  date('Y-m-d H:i:s') );
echo file_get_contents( 'favicon.ico' );

und im Document dann:

<link rel="shortcut icon" href="favicon.php">

Achte darauf, dass dann auch das Dokument nicht aus dem Cache kommt... und sieh Dir den Netzwerkverkehr und die Header in den Entwicklertools an. Das Zeug gibt es kostenlos aber eben nicht umsonst.

Wichtig: Das solltest Du allenfalls nur temporär machen und das eigentliche Problem lösen.

[Linuchs]

Das sieht so aus, als wäre die Datei „favicon.ico“, welche der Server ausliefert, nicht diejenige, von welcher Du denkst, dass er diese ausliefern sollte.

Guter Hinweis. Ich lade die Dateien des Projekts nach remso.de, da Deutschland ursprünglich (2008) die Heimat ist. Dann kamen Österreicher und Niederländer als Mitglieder dazu.

Die Unterverzeichnisse von remso.eu verweisen auf die Unterverzeichnisse von remso.de, seit Jahren funktioniert das problemlos. ln und ls habe ich am Terminal gemacht:

Das Verzeichnis mp3 unter remso.de soll auch remso.org zur Verfügung stehen:
ln -s /home/osmer/domains/remso.de/public_html/mp3 /home/osmer/domains/remso.org/public_html/mp3

Kontrolle:
ls -l /home/osmer/domains/remso.org/public_html

Ich hatte übersehen, dass das neue favicon.ico nur im Web-Hauptverzeichnis von remso.de liegt, remso.eu hat(te) die alte Version. Habe das neue favicon.ico nun auch nach remso.eu kopiert, jetzt funktioniert's.

Komisch, dass sich der Browser mal remso.eu/favicon.ico holt, wenn es im <head> gefordert wird, aber wenn er nur das Bild liefern soll, kommt es von remso.de/favicon.ico

Vielleicht liegt's an der .htaccess, die ich für die Umstellung von http nach https angelegt habe?

# 2020-08-08 https://www.redim.de/blog/weiterleitung-von-http-zu-https
RewriteEngine On
RewriteCond %{SERVER_PORT} !=443
RewriteRule ^(.*)$ https://remso.eu/$1 [R=301,L]

Um ehrlich zu sein: Das habe ich schon damals nicht verstanden.

[Raketenwilli]

Komisch, dass sich der Browser mal remso.eu/favicon.ico holt, wenn es im <head> gefordert wird, aber wenn er nur das Bild liefern soll, kommt es von remso.de/favicon.ico

Fehler auf Level 8: Du bringst Dich selbst durcheinander. Das Favicon wird immer im Wurzelverzeichnis des Webhosts (also DOCUMENT-ROOT) erwartet. Es stets dort zu lassen ist die einfachste und klarste Variante, die solche Irrtümer zuverlässig vermeidet.

Ich habe ansonsten mit Links und sshfs z.B. auch schon eigene negative Erfahrungen gemacht:

Ich hatte einen Link (also nicht die Quelle bzw. das Linkziel) auf einem sshfs-Mount auf meinem Desktop im Editor geöffnet und nach dem Speichern war mein Link kein Link mehr, sondern eine neue eigenständige Datei - und das eigentliche Original blieb unverändert…

Was hab ich gesucht und geflucht - hätte ich mit ssh direkt auf dem Server gearbeitet, dann hätte ich - wie gewohnt - die verlinkte Datei bearbeitet statt eine neue zu erzeugen…

[Linuchs]

habe die Seite gerade (erstmals) aufgerufen, da ist definitiv ein favicon mit transparentem Hintergrund.

Also kann es nicht am Cache vom Browser liegen?

[Raketenwilli]

habe die Seite gerade (erstmals) aufgerufen, da ist definitiv ein favicon mit transparentem Hintergrund.

Also kann es nicht am Cache vom Browser liegen?

IN DIESEM FALL liegt es erst einmal DEFINITIV NICHT nicht am Browser-Cache.

[Auge]

Hallo

mein favicon.ico war rotes Symbol auf transparentem Grund.

Nun hat vor einiger Zeit der Firefox die Hintergrundfarbe der passiven Tab Reiter gewechselt und das Symbol ist schlecht zu erkennen

So schlecht erkennbar finde ich das nicht. Aber das ist natürlich mein persönlicher Eindruck.

Also habe ich dem einen weißen Hintergrund verpasst und natürlich korrekt hochgeladen: https://remso.eu/favicon.ico

Doch das alte Logo wird in den Tab Reitern gezeigt, obwohl ich den FF morgens neu starte.

Also …, wie auch @Fred sehe ich das alte Favicon mit dem transparenten Hintergrund. Das ist im Firefox so, egal ob privater Modus oder nicht, aber auch im Vivaldi.

Rufe ich das Favicon über deinen obigen Link oder aus der Quelltextansicht des Firefox heraus auf, wird mir jedoch das neue Favicon mit dem weißen Hintergrund angezeigt.

Offenbar kann ich bei der Vielzahl der Browser nicht erwarten, das sich irgend eine beliebige Farbe vom Hintergrund abhebt …

Nein, die Programmoberfläche baut halt jeder Programmanbieter, wie er will. Wenn man es genau nimmt, ist es speziell beim Firefox und auch beim Vivaldi noch komplizierter. Im Firefox kann man Themes unterschiedlichster Farbgebung einbinden und der Vivaldi passt (auf Wunsch) die Farbgebung der Programmoberfläche an die generelle Farbgebung der Seite im aktiven Tab an. Rufe ich mit dem Vivaldi deine Seite auf, ist die Grundfarbe der Menüzeile des Programms und die der Reiter der im Hintergrund befindlichen Tabs knallrot, wechsle ich den Tab zur Nextcloud-Dokumentation, ist der selbe Bereich schwarz, bei MS Teams lila und bei MS Tasks blau. Nur der Reiter des aktiven Tabs ist immer weiß hervorgehoben.

Tschö, Auge

[Fred]

Hallo Auge,

Rufe ich das Favicon über deinen obigen Link oder aus der Quelltextansicht des Firefox heraus auf, wird mir jedoch das neue Favicon mit dem weißen Hintergrund angezeigt.

hab ich auch erst gedacht, das ist aber der Browserhintergrund (Firefox) bei transparenten Bildern. Schau mal mit den Entwicklertools und setz die 90 einmal auf 0...

img.transparent {
  background: hsl(0,0%,90%) url("chrome://global/skin/media/imagedoc-lightnoise.png");
  color: #222;
}

Fred

[Raketenwilli]

Offenbar kann ich bei der Vielzahl der Browser nicht erwarten, das sich irgend eine beliebige Farbe vom Hintergrund abhebt, also muss ich den Hintergrund mitliefern?

Nicht mal unbedingt wegen der Browser an sich: Für den Firefox gibt es wunderbunte Skins und dann hätten wir noch die Designverwaltungen diverser Betriebssysteme, die einerseits jegliche Geschmacksverirrung andererseits aber auch etwas wie einen Nachtmodus erlauben.

→ Ja. Hintergrund mitliefern.

Doch das alte Logo wird in den Tab Reitern gezeigt, obwohl ich den FF morgens neu starte.

Ein Cache ist ein Cache ist ein Cache…

Überprüfe mal die Antwort-Header für https://remso.eu/favicon.ico:

Accept-Ranges:	bytes
Connection: Keep-Alive
Content-Length:	1150
Content-Type: image/vnd.microsoft.icon
Date: Wed, 09 Feb 2022 11:51:02 GMT
ETag: "47e-596739195aeb6"
Keep-Alive: timeout=5, max=100
Last-Modified: 	Sun, 03 Nov 2019 16:19:51 GMT

Das Favicons „störrisch“ sind ist ein bekannter Effekt. Manchmal hilft es, das Icon explizit abzurufen, das also nicht der eingebauten „favicon.jsm“ zu überlassen. Manchmal hilft das Löschen des Browsercaches.

Versuchs mal mit

~> firefox --ProfileManager

lege dann ein neues Profil z.B. "Test" an. Schau dann, was Du bekommst, das sollte mit dem explizit geladenem übereinstimmen. Du kannst es bei einem weiteren Start mit der Option löschen.

Keinen Einfluss hast Du auf die Browser der Benutzer.

Letzter und hoffentlich zielführender Tip:

Bei statische Ressourcen (Dateien) wird das Last-Modified-Datum vom Webserver anhand von Metadaten des Dateisystems ermittelt. Es ist möglich, dass dieses Datum nicht oder „in der falschen Richtung“ geändert wurde, denn ich erhalte „Last-Modified: Sun, 03 Nov 2019 16:19:51 GMT“. Das kann das Datum von Deinem Dateisystem sein. Ist das „neue“ Icon vielleicht älter (früher gespeichert worden) als vermeintlich „ältere“?

Manche Übertragungsprogramme setzen auch auf dem entfernten Host das vom lokalen Dateisystem gelesene Last-Modified-Datum.

Handlungsempfehlung:

→ Sieh also zu, dass das aktuelle Favicon formal „neuer“ ist als das, welches Du ersetzen willst.

Etwas wie

stat favicon.ico; # Ansehen
mv favicon.ico favicon.ico.alt
cat favicon.ico.alt > favicon.ico
chmod 644 favicon.ico
rm favicon.ico.alt
stat favicon.ico; # Ansehen

sollte auf einen unixioiden System (e.g. Linux) sicher und brutalst möglich erzwingen, dass Dein Favicon auf jeden Fall das aktuelle Datum hat…

Freilich gänge das auch mit touch -t YYYYMMDDHHmm[ss] DATEI:

touch -t 202202090102 favicon.ico
stat favicon.ico
  Datei: favicon.ico
 Größe: 1         	Blöcke: 8          EA Block: 4096   Normale Datei
Gerät: 10303h/66307d	Inode: 21364839    Verknüpfungen: 1
Zugriff: (0664/-rw-rw-r--)  Uid: ( 1000/  fastix)   Gid: ( 1000/  fastix)
Zugriff: 2022-02-09 01:02:00.000000000 +0100
Modifiziert: 2022-02-09 01:02:00.000000000 +0100
Geändert: 2022-02-09 13:31:18.155043542 +0100
Geburt: -