TLS ALPN Proposal

[Bradford Wetmore]

On 5/22/2015 8:28 PM, Weijun Wang wrote:
>
>
> On 5/23/2015 9:13 AM, Bradford Wetmore wrote:
>> Weijun wrote:
>>
>>  > But in the RFC the name is in uppercase and chars in string are all
>>  > lowercases.
>>  > ...deleted...
>>  > - Compare with equalsIgnoreCase()
>>
>> Not following here, the spec is specific about the over-the-wire byte
>> values, and http/1.1 != Http/1.1.
>
> Because the spec says
>
>     o  Identification Sequence: The precise set of octet values that
>        identifies the protocol.  This could be the UTF-8 encoding
>        [RFC3629] of the protocol name.
>
> and the name is uppercase. What if someone really sends
> "HTTP/1.1".getBytes("UTF-8")?

I'm sorry, but I'm still not understanding your point.  Looking at an 
existing ALPN directory entry:

    Protocol:  HTTP/1.1
    Identification Sequence:
       0x68 0x74 0x74 0x70 0x2f 0x31 0x2e 0x31 ("http/1.1")
    Reference:  [RFC7230]

The name of the "Protocol" is HTTP/1.1, but the "Identification 
Sequence" is "0x68 0x74 0x74 0x70 0x2f 0x31 0x2e 0x31 ("http/1.1")".  I 
am proposing that the List<String> be the values of the Identification 
Sequence, not the IANA Protocol Names.

Is your opinion that the ALPN API String "Protocol" be the "Protocol:" 
and that we should internally map from HTTP/1.1 to http/1.1 before 
sending?  Or that Identification Sequence "HTTP/1.1" SHOULD BE treated 
the same as "http/1.1"?  I think that's what you're saying, since I 
think you want to compare it using equalsIgnoreCase().  That will make 
future ALPN protocol name addition challenging.

 > What if someone really sends "HTTP/1.1".getBytes("UTF-8")?

In my proposal, then they should send "HTTP/1.1" instead of "http/1.1".

I'm really sorry if I'm still missing something.

Brad