API: Add playlist and start time to resolve_url

[iBicha]

Captures the start time and the playlist id (if any) of the resolved url.

Also, make a head request to check for redirects. This is to resolve short urls (https://youtu.be/<videoId>?t=60)

[syeopite]

Code looks good to me. I'm not entirely sure about the additional redirect check though.

The resolve url endpoint in Invidious is mostly used as a limited proxy to InnerTube's resolve url. As the original doesn't support youtu.be should Invidious even tact on that extra functionality?

[iBicha]

Code looks good to me. I'm not entirely sure about the additional redirect check though.

The resolve url endpoint in Invidious is mostly used as a limited proxy to InnerTube's resolve url. As the original doesn't support youtu.be should Invidious even tact on that extra functionality?

I agree with you, the main reason I did add it is because a web client wouldn't be able to do that redirect check because of CORS.

Because it's an endpoint that is not often used, it felt that adding the HEAD call wouldn't be a big deal, and adds the benefit of supporting short URLs and web clients.
If there's a strong opinion against it, I'm okay with removing it

[absidue]

It sounds like your use case is passing every URL to Invidious to pass to YouTube to resolve, personally I feel like that is the wrong approach. Parsing YouTube URLs is not that hard to do, especially youtu.be ones, also means your app will be faster, because you aren't making unnecessary network requests.

Your reasoning for web clients goes out the window too, if you add parsing code.

The only use case, where you have to use the resolve endpoint, is resolving vanity channel URLs (https://youtube.com/@YouTube, https://youtube.com/user/YouTube, https://youtube.com/c/YouTube and https://youtube.com/YouTube) to get the channel ID, as the channel APIs (Invidious' and Innertube/YouTube) need the channel ID.

[SamantazFox]

I second Absidue's comment here: adding support for youtu.be is not useful, as it's a self-explanatory URL (everything you need is already there).

As for the rest, are there cases where the playlist ID or the video's start time are hidden in a shortened URL?

[iBicha]

What's the recommendation? Should I remove the redirect? Or close the PR?

[iBicha]

I second Absidue's comment here: adding support for youtu.be is not useful, as it's a self-explanatory URL (everything you need is already there).

As for the rest, are there cases where the playlist ID or the video's start time are hidden in a shortened URL?

I added this for completeness on both fronts, the resolveUrl api and the short urls. Youtube introduces things all the time (mixes, shorts, etc) and it's nice to have an endpoint you can rely on to tell you what things are.

Also, if the resolveUrl is returning data (like playlistId or startTimeSeconds) then Invidious should return it

[syeopite]

What's the recommendation? Should I remove the redirect? Or close the PR?

I'll say just remove the redirect. The rest of the changes are fine.

As for the rest, are there cases where the playlist ID or the video's start time are hidden in a shortened URL?

While not hidden in a shortened url the resolve endpoint does return those attributes in a standard watch?v= link like

https://www.youtube.com/watch?v=n3Xv_g3g-mA&list=PLFs4vir_WsTySi9F8v5pvCi6zQj7Cwneu&t=60

[iBicha]

Looks like there's a consensus on not doing the HEAD call. It's removed