[FFmpeg-devel] [PATCH] avformat/hls: look for trailing GET headers with m3u8 extension check

Rémi Denis-Courmont remi at remlab.net
Tue May 16 15:41:03 EEST 2023



Le 15 mai 2023 05:38:22 GMT+08:00, Michael Niedermayer <michael at niedermayer.cc> a écrit :
>> > 
>> > But lets consider:
>> > file:///home/myname/myfile.m3u8?file.avi
>> > /home/myname/myfile.m3u8?file.avi
>> > http:/server/myfile.m3u8?file.avi
>> > 
>> > The first is odd, iam not sure what "?file.avi" is and i wonder if we
>> > could simply reject this at file protocol level.
>> 
>> > If its accepted, I think it would map to /home/myname/myfile.m3u8 on disk
>> > not "/home/myname/myfile.m3u8?file.avi"

Yes. You would escape the question mark if you wanted it in the local file path.

>> This is incorrect.

No.

>> try it by naming a file "foo.m3u8?bar.txt" and run
>> xdg-open 'file:///home/leo/foo.m3u8?bar.txt' and you will find that it opens
>> it.

It should stop at the question mark and drop everything from there. FWIW, URL syntax is specified by IETF, not XDG.

>What is incorrect ?
>we have some tools that will interpret "file:///home/leo/foo.m3u8?bar.txt" as
>/home/leo/foo.m3u8?bar.txt and some /home/leo/foo.m3u8 on disk
>
>I think that makes that sort of file URLs ambigous, dont you agree ?

Absolute URLs aren't ambiguous, and if the file scheme is specified, then the URL is absolute by definition. Situations whence relative locations are accepted, are ambiguous because some use URL syntax, some use local file path syntax (which is subtly incompatibly different) and some use a messed up mix of both relying on the tolerance of web browsers.


More information about the ffmpeg-devel mailing list