[MPlayer-dev-eng] http to https redirects (was: offer to include gopher protocol support)
Alexander Strasser
eclipse7 at gmx.net
Thu Jan 23 22:33:52 EET 2020
On 2020-01-19 17:40 +0100, Alexander Strasser wrote:
> Hi Lauri!
>
> On 2020-01-19 09:39 +0200, Lauri Kasanen wrote:
> > On Sat, 18 Jan 2020 22:04:41 +0100
> > Alexander Strasser <eclipse7 at gmx.net> wrote:
> >
> > > After looking at that list I noticed https is in there, since some time.
> > > It makes sense as AFAIK we don't support it with MPlayer's http modules,
> > > though it seems a bit unexpected from a user's end, that consuming a
> > > stream, even the "same stream", via https will switch the underlying
> > > implementation.
> >
> > This has the downside that http-to-https redirects don't work.
> >
> > mplayer http://...
> > Unsupported http 301 redirect to https protocol
> >
> > While direct https:// plays.
>
> That's a good point! I didn't even think about the redirection use case.
>
> I fear redirection with stream_ffmpeg might not work or not work for all
> protocols. That would need to be tested for http/https and if necessary
> implemented.
I tested redirections with stream_ffmpeg and it seems to work fine.
> Then we could IMHO make stream_ffmpeg the preferred handler for
> http/https. We should compare the implementations a bit deeper to
> decide if there are enough benefits to keep our http there in the
> long run.
While testing I found out, that http -> https redirection works fine
without changing the priority of the stream modules. If it's not an
mms and not an http redirect, the http stream module fails, and the
ones after it get a chance to handle the stream.
So on the one hand the attached patch should make http to https work,
OTOH it will mean at least one more request to the server is done. If
there is a chain of redirects
http -> http -> http -> https
or similar, even more requests will be repeated.
Not really sure this matters much, but it could be one reason to put
stream_ffmpeg before other stream modules handling http in the list.
As always comments welcome!
Alexander
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-stream_ffmpeg-Handle-HTTP-protocol-too.patch
Type: text/x-diff
Size: 1201 bytes
Desc: not available
URL: <https://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20200123/6d18455e/attachment.patch>
More information about the MPlayer-dev-eng
mailing list