Hi all! On 2020-08-12 14:53 +0000, Nicolas George wrote: > ffmpeg | branch: master | Nicolas George <geo...@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 _______________________________________________ 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".
