Failed to retrieve favicon from rei.com
brunokc opened this issue · 17 comments
I have an entry for rei.com and I noticed it's not able to pull its favicon. However, hitting https://www.rei.com/favicon.ico directly from the browser seems to work.
I just created a dummy entry for REI to test. Doesn't work with either https or http.
The reference to the favicon.ico is directly in the head when viewing the source of the main page at rei.com:
<link rel="icon" href="/favicon.ico" sizes="16x16" type="image/x-icon"/>
But, if you actually view the properties of the 'page' when using the direct link as in the OPs post above, it actually shows as a 48 x 48 pixel image, versus the 16 x 16 that the HTML refers to:
I see. However, even though the icon is 48x48:
- It still shows up in the browser, near the URL.
- I can manually download and add the icon to KeePass and it works fine.
This site seems to use HTTP/2 only.
.NET doesn't seems to support it "out of the box", needs further research.
Nothing related with the bad HTML or the size of the icon.
Ahhh. So, Matthias' Implementation? Or are you going to write your own? 🔢
@JohnLGalt
Sorry but where is Matthias implementation? I don't recall that.
I guess the future will be that service, since the web is moving faster than .NET framework hahah
I think investments on .NET Framework have stopped (it's in maintenance mode). All new investments are being made towards .NET Code (and .NET 5) going forward.
.NET Code?
You surely mean .NET Core. Which is indeed the latest version of Dotnet, and the successor of the (Windows only) .NET Framework platform.
The current version of .NET Core is 3.1, but you're right, the next version will be .NET Core 5.
They are skipping number 4, I assume to avoid any confusion with the old .NET Platform which is at version 4. something.
https://dotnet.microsoft.com/download/dotnet-core
Edit:
You're right about the new name though, with version 5 they will drop the 'Core', and it will just be called .NET 5.0
Yep, I meant .NET Core, not Code. Butchered it. :-\
Point is somewhat moot though as KeyPass is still on .NET Framework 2, with the justification that the level of investment on sorting out all the issues on all the various supported platforms was high and the unwillingness of the author to pursue those issues again, which is understandable. Perhaps if/once someone ports WinUI to other non-Windows platforms, they can look into moving the whole thing into .NET Core/.NET 5.
Yeah, just remember YAFD it's just a plugin sitting on the middle of all this, so I can't do much.
This is the reason why we had this discussion before:
#42
@JohnLGalt
Sorry but where is Matthias implementation? I don't recall that.I guess the future will be that service, since the web is moving faster than .NET framework hahah
Nice, I will take a look too, but it's on my TODO list do something like a fallback to DuckDuckGo service (https://icons.duckduckgo.com/ip3/www.rei.com.ico).
I need to reach them out first and check if its ok to use it, put a warning explaining that is using a 3rd party service and bla bla bla... What do you think?
For now I think it will solve this edge cases, giving a better resolution.
Good idea. Hopefully they don't have an issue with it. Keeping my fingers crossed!
@JohnLGalt not sure if we are going to get an answer.
I sent the emails over a week ago. 😞
Well, the last time there was an update was a few years ago, and also, it's a library - I doubt that they are going to have a problem with your use case, as 1) your own project is FOSS, and 2) you're not distributing their library (as a whole) in any way manner or fashion, but using it in your own project, which they explicitly state is the entire purpose of the existence of the project:
This library implements the HTTP/2 and HPACK protocol for .NET standard. The goal of the library is to cover all protocol handling parts of the HTTP/2 (RFC7540) and HPACK (RFC7541) specifications. The goal of this library is NOT to provide a ready-to-use HTTP/2 server or client framework with concrete Request/Response abstractions. Instead it should enable other .NET libraries and applications to easily integrate HTTP/2 support by encapsulating the protocol handling in easy to use and flexible .NET classes. Examples for building simple applications on top of the library are provided within the repository.
So, IMO, that means it is meant to be used as you would use it for this project.
If you really are leery of using it without explicit permission, you could either 1) fork your project to use the library, with a notice that the fork is subject to being pulled / removed / deleted at any time without any advanced notice from you due to the use of this library, or just assume it is OK, and use it, and make a provision that in the unlikely scenario that one of those devs there gets back to you and denies permission, you can rebuild without it and just remove HTTP/2 functionality again.
I know that you'd rather have your own code - but their code is also open, so a third option might be a fork that is a very selective and very private beta test using their code until you can develop your own methodology / library after figuring out how theirs works....which you can then give credit to them without actually using their code, and should be a perfectly acceptable situation - after all, it's GitHub - if they didn't want people using the library or seeing the code, it would have been in a pvt repository somewhere, right?
Sure, http2dotnet doesn't seems a problem.
To be honest I was talking about Duck Duck Go favicon service.
They didn't give me an answer until now.
Lol whoops! My bad.