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
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
