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

[Alexander Strasser]

Hi all!

On 2020-08-12 14:53 +0000, Nicolas George wrote:
> ffmpeg | branch: master | Nicolas George <george at nsup.org> | Thu Jul 30 00:02:10 2020 +0200| [1201687da268c11459891a80ca1972aeaca8db88] | committer: Nicolas George
>
> 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.
>
> > http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=1201687da268c11459891a80ca1972aeaca8db88
> ---
>
>  libavformat/tests/url.c |  60 ++++++++++-
>  libavformat/url.c       | 261 ++++++++++++++++++++++++------------------------
>  libavformat/url.h       |   4 +-
>  tests/ref/fate/url      |  54 +++++++++-
>  4 files changed, 245 insertions(+), 134 deletions(-)
>
[...]
> +
> +    /* This is tricky.
> +       For HTTP, http://server/site/page + ../media/file
> +       should resolve into http://server/media/file
> +       but for filesystem access, dir/playlist + ../media/file
> +       should resolve into dir/../media/file
> +       because dir could be a symlink, and .. points to
> +       the actual parent of the target directory.
> +
> +       We'll consider that URLs with an actual scheme and authority,
> +       i.e. starting with scheme://, need parent dir simplification,
> +       while bare paths or pseudo-URLs starting with proto: without
> +       the double slash do not.
> +
> +       For real URLs, the processing is similar to the algorithm described
> +       here:
> +       https://tools.ietf.org/html/rfc3986#section-5
> +     */

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...


[...]

  Alexander