[FFmpeg-devel] [FFmpeg-cvslog] lavf/url: rewrite ff_make_absolute_url() using ff_url_decompose().

[Alexander Strasser]

On 2020-08-13 00:13 +0200, Nicolas George wrote:
> Alexander Strasser (12020-08-12):
> > Stupid question: Why do we transform relative URLs at all?
> >
> > Isn't it normally supposed to work for HTTP on the server-side too?
> >
> > Many clients seem to do it. Just curious why...
>
> At the very least, we need to be able to combine:
>
> http://site.com/contents/text/index.html + ../media/file.mp4
>
> into
>
> http://site.com/contents/text/../media/file.mp4
>
> and
>
> http://site.com/contents/text/index.html + //media.site.com/file.mp4
>
> into
>
> http://media.site.com/file.mp4
>
> because that is what we need to contact the relevant server and generate
> the request. Eliminating double-dots components is just an easy bonus.

Thanks for the quick answers Nicolas and Marton!

First I must apologize, my wording was wrong. I didn't mean
relative URL but relatives paths in URLs.

I was just curious in general and because it seemed on a
glance that the referenced tickets only had problems with
removing-dot-segments-gone-wrong .

That seems to be kind of confirmed by Nicolas answer, but I
guess the initial prompt for Nicolas to rewrite that stuff
didn't come from the referenced tickets. It was another thing
he noticed while looking at ff_make_absolute_url. IIRC that
was something concerning the handling of relative URLs
(not their dot-segments).

If I'm not mistaken that reason for the rewrite didn't make
it into the commit message:

    lavf/url: rewrite ff_make_absolute_url() using ff_url_decompose().

    Also add and update some tests.

    Change the semantic a little, because for filesytem paths
    symlinks complicate things.
    See the comments in the code for detail.

    Fix trac tickets #8813 and 8814.



  Alexander