On 11/18/14, 9:11 AM, "James Peach" <jpe...@apache.org> wrote:
>
>> On Nov 18, 2014, at 8:57 AM, Sudheer Vinukonda
>><sudhe...@yahoo-inc.com.INVALID> wrote:
>>
>>
>>
>> On 11/18/14, 8:48 AM, "James Peach" <jpe...@apache.org> wrote:
>>
>>>
>>>> On Nov 18, 2014, at 8:38 AM, Sudheer Vinukonda
>>>> <sudhe...@yahoo-inc.com.INVALID> wrote:
>>>>
>>>> Hi James,
>>>>
>>>> How can my_awesome_callback() know the specific custom NPN
>>>>advertisement
>>>> list for a given netVC?
>>>
>>> It would know this in the same way the plugin knows what to pass into
>>> your proposed API.
>>
>> Umm, the plugin gets this info from the user configuration. It seems
>>that
>> you are suggesting to handle this config in the core directly? If so,
>>the
>> most logical place to put that config would then be
>>ssl_multicert.config,
>> but, that approach was not accepted originally. This API provides a way
>>to
>> achieve the same result via a plugin.
>
>No I'm not suggesting putting this in core. I'm saying that you don't
>need any new API for your plugin. You can do what you need today by
>calling SSL_CTX_set_next_protos_advertised_cb() from the plugin.
>
I¹ve thought about this earlier, but, the problem with this approach is
that, the plugin doesn¹t have access to make the necessary validations to
ensure the configured NPN list is consistent with the allowed/accepted
protocols per proxy port. So, essentially, there¹s the below approaches:
* Forget the plugin and do the modification of NPN list in the core
(most likely place being ssl_multicert.config, IMHO)
* Do it via a plugin but a new API to allow access to proxy port data
(e.g npnSet) is needed
* Do it via a plugin with the new API like TSSslAdvertiseProtocolSet(),
which hides the validation in the core and lets the plugin modify the list.
>
