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 <linkid="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/2404# more data
You 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.ico is the only “default” URL. /favicon.ico is 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 for Link headers or <linkrel=icon> elements. While URLs like /favicon.png may be popular they aren’t part of any actual protocol.
It doesn’t have to be an
*.icofile. 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.
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 dataIndeed. 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.
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.