On Thu, 20 Aug 2020, Moritz Barsnick wrote:
Add the "http_proxy" option and its handling to the "tls" protocol,
pass the option from the "https" protocol.
The "https" protocol already defines the "http_proxy" command line
option, like the "http" protocol does. The "http" protocol properly
honors that command line option in addition to the environment
variable. The "https" protocol doesn't, because the proxy is
evaluated in the underlying "tls" protocol, which doesn't have this
option, and thus only handles the environment variable, which it
has access to.
Documentation for the "tls" protocol is not changed, as the new
option is basically only useful together with the "https" protocol.
The patch looks fine in general, I think, but I don't agree with the last
statement here.
Even if you do e.g. a plain tls socket (or rtmps, or whatever), you may
want to do the tls connection through a proxy server (be that a socks
proxy or http proxy).
For the case of rtmps, if you pass the http_proxy option, it should be
passed to the rtmps protocol, which doesn't have such an option, from
where it's passed along in the options dictionary down until the tls
protocol consumes it. This just doesn't work for https, as the shared
http/https options dictionary consumes the option from the dictionary, so
you have to readd it like you do in your patch.
// Martin
_______________________________________________
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".
