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. 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. > 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. > 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, -- Nicolas George
From e191edd282591301acfcde4d4acafed7e0a34a96 Mon Sep 17 00:00:00 2001
From: Nicolas George <geo...@nsup.org>
Date: Wed, 28 Jul 2021 10:51:15 +0200
Subject: [PATCH 05/11] lavf/url: handle fs: and compatibility file:.
Signed-off-by: Nicolas George <geo...@nsup.org>
---
libavformat/url.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/libavformat/url.c b/libavformat/url.c
index f53fdf59d8..6ab48f8c0c 100644
--- a/libavformat/url.c
+++ b/libavformat/url.c
@@ -196,7 +196,7 @@ int ff_make_absolute_url2(char *buf, int size, const char *base,
URLComponents ub, uc;
char *out, *out_end, *path;
const char *keep, *base_path_end;
- int use_base_path, simplify_path = 0, ret;
+ int use_base_path, fs_scheme, simplify_path = 0, ret;
const char *base_separators = "/";
/* This is tricky.
@@ -224,10 +224,13 @@ int ff_make_absolute_url2(char *buf, int size, const char *base,
if (!base)
base = "";
+ /* XXX temporary fs:/file: compatibility */
+ fs_scheme = av_strstart(base, "fs:", NULL) ||
+ (av_strstart(base, "file:", NULL) && !(base[5] == '/' && base[6] == '/'));
if (handle_dos_paths) {
if ((ret = ff_url_decompose(&ub, base, NULL)) < 0)
goto error;
- if (is_fq_dos_path(base) || av_strstart(base, "file:", NULL) || ub.path == ub.url) {
+ if (is_fq_dos_path(base) || fs_scheme || ub.path == ub.url) {
base_separators = "/\\";
if (is_fq_dos_path(rel))
base = "";
@@ -280,6 +283,8 @@ int ff_make_absolute_url2(char *buf, int size, const char *base,
simplify_path = 0;
if (URL_COMPONENT_HAVE(uc, authority))
simplify_path = 1;
+ if (fs_scheme)
+ simplify_path = 0;
/* No path at all, leave it */
if (!use_base_path && !URL_COMPONENT_HAVE(uc, path))
simplify_path = 0;
--
2.30.2
signature.asc
Description: PGP signature
_______________________________________________ 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".
