[FFmpeg-devel] [PATCH]lavf/utils: Do not read "@" without ":" as user name separator

[Carl Eugen Hoyos]

Am So., 5. Mai 2019 um 21:56 Uhr schrieb Hendrik Leppkes <h.leppkes at gmail.com>:
>
> On Sun, May 5, 2019 at 9:47 PM Carl Eugen Hoyos <ceffmpeg at gmail.com> wrote:
> >
> > Am So., 5. Mai 2019 um 21:18 Uhr schrieb Hendrik Leppkes <h.leppkes at gmail.com>:
> > >
> > > On Sun, May 5, 2019 at 9:08 PM Carl Eugen Hoyos <ceffmpeg at gmail.com> wrote:
> > > >
> > > > Hi!
> > > >
> > > > Attached patch fixes ticket #7871 without re-introducing #7816.
> > > >
> > >
> > > There is no patch here. However, please note that its perfectly valid
> > > to have a username without a password (ie. an @ without a ":") - while
> > > it is not valid to have a slash in there.
> >
> > > For the record, the original ticket 7816 was not even about a slash,
> > > it was about URI encoding not being supported. As such, it was never
> > > resolved in the first place (and closed unjustly), and cannot regress.
> >
> > There is no url encoding in ftp according to the rfc.
> >
>
> FTP is not being passed the URI at all, its entirely for the
> convenience of the application. As such, that argument makes no sense.
>
> Either way, this does not fix the underlying problem.
>
> Take this perfectly valid URI: (it does not point to an actual file,
> but that is irrelevant): http://ffmpeg.org:80/foo@bar
> If you support slashes in the username or password, this points at a
> host named "bar" and has login details - both a username and a
> password. If you don't, then this points at ffmpeg.org, port 80, and
> some valid path.
>
> Only one of those interpretations is correct, and everyone else,
> including the RFC, says it should be the second.

I apparently missed the part of the rfc where a slash is
forbidden for the password.

Carl Eugen