[vlc-devel] ALPN support on Apple platforms

[David Fuhrmann]

Hello Remi,

> Am 06.11.2016 um 22:25 schrieb Rémi Denis-Courmont <remi at remlab.net>:
> 
> Le lauantaina 5. marraskuuta 2016, 17.51.37 EET David Fuhrmann a écrit :
>> 3) Declare ALPN as not supported on Darwin platforms right now
>> - Currently, in practice all web services should be working perfectly fine
>> without HTTP/2 and ALPN.
> 
> Possible but contextually irrelevant unless you imply writing yet another 
> HTTP(S) stack in VLC, one that supports neither HTTPbis and nor tunneled 
> HTTPbis, and thus will operate without ALPN.

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?

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.

> 
>> 4) Ignore the failing test and just do nothing until someone from
>> securetransport or gnutls adds support for the missing pieces. - I think
>> this is not an option as well, mainly because:
>>  - We should not have always failing tests because a feature is not
>> implemented
> 
> I still totally disagree. And that statement is essentially rejecting the very 
> premise of test-driven development. So I dare extrapolate that a lot of other 
> people in the software industry disagree with you on this.
> 
> A test should fail if the implementation is not working as it is supposed to. 
> It is irrelevant if the failure is caused by a regression, a latent bug, a 
> nondeterministic implementation or an incomplete implementation or a missing 
> implementation. In all cases, removing or disabling the test case amounts to 
> shooting the messenger.
> 
>> - It blocks CI and mainly it blocks visibility of compilation
>> and test execution. So no other developer can see if some change fails on
>> Darwin-platforms coincidentally.
> 
> 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.

> 2/ The test case is only a reflection of the behaviour that the stack relies 
> on. Disabling the test case is not fixing the actual problem.
> 
>> Does anyone know another solution? Do you have any comments or ideas on how
>> to proceed with this issue? PS: It would be great if we can stay on-topic
>> only for these discussions.
> 
> Stating the bleedingly obvious here:
> 1/ Fix GnuTLS and revert to it.
> 2/ Switch to yet another TLS stack.
> 

Best regards,
David