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