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
