There seems to be a bug with YouTube where they serve a http URL in <link> tags for their OEmbed endpoint, but they do not actually allow requests to the http URL, which is why YouTube previews currently do not work.
@Gargron a feature rather than bug no doubt! Playing cat and mouse with the API to keep 3rd party apps from using their content without dev keys (or rather they just changed their API and we only find out when things break!)
@Gargron Seems to me like special-casing it for Youtube would be the cleaner option. It's only them misbehaving, and hopefully it will eventually be fixed and the special case can be removed again.
@WAHa_06x36 @Gargron YouTube have a long history of forcing others to special-case when it suits Google. I recall reading that FF had optimised their layout engine to match/exceed Chrome on pageloads including YouTube, and then a few new empty divs appeared on YouTube's templates one night, breaking the optimised algorithm for FF but not Chromium. The YT/Chromium devs were not forthcoming with answers, because it'd mean an antitrust case if they admitted it.
@WAHa_06x36 @Gargron Which is to say that, perhaps ye do need special-casing, but expect YT to continue to break other people's implementations because they want them to click-that-link and actually go to YouTube, and they know the visitors will blame the soirce site for being "Broken", not the super smart google engineers at YT.
A thought though: Epicyon supports admins giving a preferred YT proxy service, perhaps as an option in Masto too?
@Gargron If you try the http->https method, please make it a fallback only if the *actually stated* url fails. If you do that, I think that’s better than special casing for YouTube.
Server run by the main developers of the project It is not focused on any particular niche interest - everyone is welcome as long as you follow our code of conduct!