On 9/25/2015 8:48 PM, Simone Bordet wrote:
> Hi,
>
> On Fri, Sep 25, 2015 at 2:26 PM, Xuelei Fan <xuelei....@oracle.com> wrote:
>> Maybe, we are not on the same page, I think.
>
> We are.
>
>> I think a general cipher strength comparator is sufficient for HTTP/2
>> preference too. What do you think?
>
> I don't know if all the blacklisted ciphers are actually lower
> strength of all the remaining ciphers, nor what is the exact
> definition of "strength" that you can use in a comparator.
> But because the HTTP/2 specification bothered to say what's
> blacklisted, I would just use that.
>
HTTP/2 blacklists them because they are no so strong because of various
reasons.
The definition of "strength" can be customized by the customers.
Therefore, I don't worry too much because of this flexibility.
>> Maybe, need no extra comparator for HTTP2. Extra comparator would make
>> behaviors pretty complicated and hard to get expected, as I described in
>> the previous mail.
>
> There is no complication, really. Two comparators would compose, not exclude.
>
For the complication, I posted the comments in previous mail here:
-----------------------------
> In case you have [HTTP/2, AP_NEW, HTTP/1.1], then you can simply
> compose the comparators to sort first with the H2.CIPHER_COMPARATOR,
> then with AP_NEW.CIPHER_COMPARATOR.
>
> cipherSuites = Arrays.sort(cipherSuites,
> ApplicationProtocol.H2.CIPHER_COMPARATOR.
> thenComparing(AP_NEW.CIPHER_COMPARATOR));
>
Let's look at an example. application_protocol_1 prefer cipher_suite_1,
and application_protocol_1 prefer cipher_suite_2.
The comparator for application_protocol_1 would set the preference as
{cipher_suite_1, cipher_suite_2}. and the comparator for
application_protocol_2} would set the preference as {cipher_suite_2,
cipher_suite_1}.
The result to sort 1 and then 2, and the result to sort 2 and then 1 are
different.
The call sequence to the comparators, and the call to each comparator
would result in difference result. That's may be not the expected behavior.
-----------------------------
It's not easy to use application comparator, I think.
> For example, let's say that you want to sort by "bit" strength in a
> way that you want to prefer 128 bits or lower to favor performance,
> but also do HTTP/2.
>
> The H2 comparator will sort the blacklisted at the end.
> Among the good ones, they all compare == 0 for the H2 comparator.
> That is where the second comparator will kick in, grep the cipher name
> for the bits number and sort them accordingly.
>
It's flexible to meet the requirement by customer's customization.
Maybe, extra comparator is not necessary here. I think the comparator
can be a handy tool, but not belong to ALPN.
Xuelei
