[FFmpeg-devel] [PATCH] http: handle URLs with spaces

[wm4]

On Sun, 2 Feb 2014 09:12:08 +0000
Eli Kara <eli at algotec.co.il> wrote:

> >>
> >> Basically it's true, but it may be convenient. Some extra option to 
> >> enable escaping could be an compromise.
> >> But it should escape all characters that are not allowed, not just spaces.
> 
> > We cannot perform full escaping (urlencode conversion) seamlessly, because we would get spare conversion of "%" sign to "%25" if user has supplied already urlencoded url.
> > _Option_ to perform urlencode internally is possible, although i think there are a lot of possibilities to do this conversion outside of ffmpeg.
> 
> While there are certain characters such as space that are invalid in URIs in general, the RFC states that they can be percent-encoded. Specifically spaces are very good
> candidates to be included in the query string (the part after the ?). Side note - when in the query string they are traditionally "encoded" to plus signs.
> 
> FFmpeg *can* urlencode. It can also do so if a certain option is set (just like "cookies" or any other protocol option). However, the question is - do you really want to?

Why wouldn't you want to escape things that are clearly not allowed
unescaped? I'd expect libavformat's http support to work well, not that
I have to preprocess URLs in various protocol specific ways before
passing it to libavformat. Sure, I could do that, but what's the point
of forcing every single API user to add a bunch of crappy custom code
just to make it behave as one would expect?

As for escaping in general - you have to be careful not to escape
already escaped characters. I'm not sure how that is supposed to be
handled - I guess there is no standard way, since you don't know
whether the URL you get is escaped or not. Note that this is not the
API user's fault - the user could provide escaped or unescaped or
semi-broken mixed escaping, and expect it to work. There are websites
that encode HTML links that use unescaped URLs.

> I'm a relatively new observer to this list but IMHO the pros and cons for encoding are these:
> 
> Con - URL encoding can be done outside of FFmpeg in many ways and with already existing, proven code.

How/where?

> Pro - In much the same way that http.c implements the HTTP protocol, headers processing, cookies processing and other features, for completeness purposes it should also
> have URL encoding capabilities, at least as an option for HTTP.

Why an option to send invalid HTTP requests? Are you planning to use
libavformat to test webserver bugs?

> Eli