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