TLS ALPN Proposal
bradford.wetmore at oracle.com
Mon May 25 20:37:56 UTC 2015
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
I'm sorry, but I'm still not understanding your point. Looking at an
existing ALPN directory entry:
0x68 0x74 0x74 0x70 0x2f 0x31 0x2e 0x31 ("http/1.1")
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.
More information about the security-dev