So does the website itself, though, right?
Sort of…
You can just hope that
/favicon.icoworks. But 1. it often doesn’t and 2. it is often of low quality.To find a favicon on a modern site you need to load the HTML and check
Linkheaders and<link rel=icon>elements. However you likely can’t do this client-side for most sites because of CORS. So you need some server (at the very least to strip CORS). That lets you get the URL but 1. you probably don’t want to have connections to external domains for user privacy and 2. some domains will have hot-link protection so you need to fetch the image via your server. You will also want to consider different image formats and sizes to serve the right image to the right client. On top of all of this the site may be using some sort of bot protection which you will have to fight. Google is almost always whitelisted. The site may also have temporary outages so having a cache would be nice, especially if that is almost always populated before you even know the domain exists.At the end of the day you do want some sort of API. And while it isn’t complex it isn’t trivial. So it is nice to just let Google handle it. (Other than tracking risks, but you could proxy Google’s API.)
Hmm, all of those are fair points. I guess I was just thinking this seems like an overengineered solution to a niche problem, but I suppose for the people who actually have that problem, the solution is good to have.
I know that KeepassXC has an automatic favicon downloader built-in and it’s open source. Maybe check out it’s code.
No, favicons are usually encrypted and not publically visible. You have to connect your website to the google favicon service for it to be shown to users. /s
Last night, somewhere in Mountain View, Sundar Pichai sat bolt upright in bed, realizing that there was a possible profit center yet untapped…
Why would you ever want to route your request like this through a third party especially an ad company? To get the favicon of a site you just request
www.example.com/favicon.ico.Not necessarily. You need to fetch the HTML of the web page you want the icon for and see if there’s a <link rel=icon> or equivalent HTTP header.
And yes, this means different pages on the same site can have different icons.
@argv_minus_one@mastodon.sdf.org @FrostyPolicy@suppo.fi @Pro@programming.dev
AFAIK there’s also a special file name Safari uses for bigger PNG icons. That Google thing probably just facilitates all this machinery, but I agree — I wouldn’t rely on Google for such things myself.
It doesn’t have to be an
*.icofile. So you might need to try different file extensions.So you might need to try different file extensions.
No, you don’t. The HTTP response header will tell you what type it is. Anything using file name suffixes to determine content type on the web (unless it’s just a fallback guess) is broken.
So you might need to try different file extensions.
No, you don’t. The HTTP response header will tell you what type it is.
I’m not sure what you’re talking about. You need to know the name of the file before you can download it.
For instance, my lemmy client, says in its HTML that its favicon is
<link id="favicon" rel="shortcut icon" type="image/x-icon" href="https://sopuli.xyz/pictrs/image/9c6eeb58-bf66-4a15-9537-0a822f3c4feb.png">. If I were to blindly download/favicon.ico, I’d naturally get a 404 page:$ curl https://sopuli.xyz/favicon.ico -i HTTP/2 404 # more dataYou need to know the name of the file before you can download it.
Indeed. And /favicon.ico might not be a Windows ICO file, but instead be a PNG, GIF, or some other image format. I thought that’s what you were (correctly) pointing out when you wrote “it doesn’t have to be an *.ico file”. In such cases, the HTTP Content-Type field tells what image format it is.
If I were to blindly download /favicon.ico, I’d naturally get a 404 page:
Ah, so it turns out you were thinking of cases where /favicon.ico doesn’t exist at all. That can also happen, but your suggestion to “try different file extensions” is not the answer, as you can see if you try to curl /favicon.png, /favicon.gif, etc. The correct approach is to parse a web page’s HTML in search of a favicon URL, which you did in your above reply, but that’s not the same thing as what you originally suggested.
True. I’ve just seen requests to that file in my demo env for web apps I have and I’ve seen my browser request that file by itself when running those locally.
/favicon.icois the only “default” URL./favicon.icois usually not an actual “icon” type anymore but PNG or JPG (but with the same URL). Other than that you need to load the HTML and check forLinkheaders or<link rel=icon>elements. While URLs like/favicon.pngmay be popular they aren’t part of any actual protocol.
duckduckgo, icon.horse and favicongrabber.com also have their own APIs for this
I bet there is a way this could be abused in order to proxy/tunnel arbitrary requests via google IPs. Even if it’s slow and must be done through e.g. PNG image data and dynamic subdomains or something, it would still be possible.
What makes this URL an API?
Do they disclose it as free use anywhere?
I would be more interested in themed favicon sets like on Android or Linux DE’s, and any way that would avoid Google or lock-in/forced updates to such as with the Play store or Windows I would avoid like the plague.
Gimme back .dll’s full of icons I can create and edit to my liking. For modernization, meta-text(url or application name) for each icon instead of referencing “icon #x in this .dll”, and a format more usefull than .dll’s full of icons that all have to be the same size(and .tiff, .giff, or bitmaps at that, when jpeg and vector formats exist), but that’s about it.
All this re-inventing-the-wheel/web2.0/3.0 shit is geared towards creating dependency and lock-in in the stupidest ways possible.
I mean, on F-Droid and Linux are plenty of icon sets. SVG too.
Indeed.
