[vlc-devel] ALPN support on Apple platforms

[David Fuhrmann]

Hello,

> Am 07.11.2016 um 20:15 schrieb Rémi Denis-Courmont <remi at remlab.net>:
> 
> 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).

To be more precise, I’m talking about a scenario where you revert 677948a635307904117a6f104df0ebf97b56e724
and first let the TLS handshake succeed, both in case ALPN is supported or not.

Afterwards, over the alp parameter it could be signaled to the HTTP stack that it should
use HTTP 1.1 or HTTP/2.

> 
>> 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.

And how should this be any different to the case that the client does not support ALPN?
In both cases the HTTP module should fallback to HTTP 1.1, so I do not see why we should
make any difference between those both cases.

> 
> If the client side does not support ALP, failure is earlier and connection 
> fails.

Why should the failure be earlier?

In general, I still do not really get why the idea outlined above should not work.
And I even understand less why you are arguing with those points that the complete HTTP stack needs to be
rewritten, instead of modifying the existing code to support the scenario we have here.

> 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

Thanks a lot for that tip, its great that this exists.

But my main point is not about hiding tests which come later, but about something different:

I assume no developer really checks the log of all jenkins buildbots after each commit.
So to bring a breakage to the attention of the developer, I think this only works if you see
a green jenkins instance immediately switching to red after the commit (with the appropriate
IRC bot messages).

Having a continuous jenkins instance which is always and knowingly red, and nobody can
actually fix that problem in the short term, helps absolutely no developer.

And in general, if we would really decide as a project to do this kind of test driven development
in this extend as you outlined (which the project as a whole did not decide for yet, I think), then
even more platforms might have red builds most of the time, because not everything is supported yet.
And in this scenario I believe lots of the benefits of a continuous build are mostly gone then.

Best regards,
David