[FFmpeg-devel] [PATCH 09/10] lavf/file: handle standard file:// URLs.

[Marton Balint]

On Wed, 28 Jul 2021, Nicolas George wrote:

> Marton Balint (12021-07-27):
>> You should mention the relevant rfc - RFC8089.
>
> Locally added.
>
>> Also there are a couple of common deviations/extensions from the normative
>> standard, referenced in the RFC:
>>
>> https://datatracker.ietf.org/doc/html/rfc8089#appendix-F
>>
>> Do you plan to support those?
>
> No. But at a quick glance, nothing is required to support them.
>
>> Well, I guess this is needed for compatiblity, but as far as I see, the RFC
>> supports the minimal repepresentation of local file path, so RFC-wise this
>> is also valid. So what is the plan here? We will do unescaping and remove
>> the deperecation message somewhere in the future?
>
> I know the RFC accepts it, but honestly, semi-relative URLs, where the
> scheme is specified, but then a relative path is used, do not make any
> sense, especially for the file scheme but really for all schemes.

I meant the absolute path case from Appendix B:

    o  The minimal representation of a local file with no authority field
       and an absolute path that begins with a slash "/".  For example:

       *  "file:/path/to/file"

>
> While standard absolute file:// URLs do happen quite easily (file
> choosers can produce one; I had to implement a work-around in my
> application), the odds that we meet a semi-relative one is zero.
>
> On the other hand, we need backward compatibility. So I think reserving
> this case for compatibility is completely ok.

I can agree with this, but all the deviations from the normative RFC 
should be explicitly documented.

>
>> What about the file://host/file syntax which - at least on Windows - should
>> be transformed to //host/file?
>
> I do not intend to implement this, but if somebody wants to, the double
> slash is still enough to distinguish from the compatibility case, so we
> will be good.

Well, it will break compatiblity for cases like
file://server/share/100%.txt because now percent encoding will be 
assumed...

Maybe as the first step percent encoding should only be used for the 
3-slash form, and the deprecation warning should be printed for the 
less-than-3-slash form. (People wanting percent encoding may use the 
4-slash form which is also a thing...)

And after 2 years of deprecation period the warning should be removed and 
percent encoded form can be used for all the cases.

This way eventually the file: handling can be fully RFC compliant.

>
>> Also the question of relative resolution comes to mind, there is some code
>> in libavformat/url.c which also handles file path specially, that should
>> also be updated, right?
>
> Good catch. I added this patch in the series. It passes FATE.
>
> I will re-send the full series after giving more time for comments.
>
> Regards,
>

Thanks,
Marton