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 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.
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?
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.
