[vlc-devel] ALPN support on Apple platforms

Rémi Denis-Courmont remi at remlab.net
Mon Nov 7 20:15:10 CET 2016

Le maanantaina 7. marraskuuta 2016, 8.30.40 EET David Fuhrmann a écrit :
> Why would we explicitly need another HTTP stack? Why would it not work to
> just modify the existing http stack and fallback to HTTP 1.1 in case ALPN
> is not supported?

That would require reloading the x509 again, and reconnecting again. No thanks 
(and I´d expect complaints from sysadmins eventually).

> Just having a brief look in the http module code, in vlc_https_connect you
> already fall back to HTTP 1.1 if the output parameter alp is set to NULL.
> I’m not sure if this is enough already, but it does not seem that hard to
> add potential missing pieces.

The ALP will be nul if the server side does not support ALPN.

If the client side does not support ALP, failure is earlier and connection 
fails. And it can´t be faked, lest it theoretically breach the security model, 
and practically cause misfunction in the proxy support code.

> > This is a red herring because:
> > 1/ Several test cases are actually reportedly failing on Darwin debug
> > builds, so this failure won´t make a meaningful difference.
> I think we need to start somewhere. And I already saw successful debug
> builds with all tests passing (once the TLS test was disabled). So its even
> more important to see if / once the other tests start failing again.

You can run all tests already, e.g.:
# make -k check

I think that it was already brought up on IRC a few days ago even.

But disabling a failing test to see the results of the following tests seems 
totally backward to me.

Rémi Denis-Courmont

More information about the vlc-devel mailing list