On 6/5/2015 11:16 PM, Simone Bordet wrote:
> Hi,
>
> On Fri, Jun 5, 2015 at 4:46 PM, Xuelei Fan wrote:
>> If H2 is not supported, SPDY/3.1 would be attempted, of SPDY/3.1 is not
>> supported HTTP/1.1 would be attempted.
>
> Correct.
>
>> If H2 is supported in both side,
>> but H2 does not work,
Hi,
On Fri, Jun 5, 2015 at 4:46 PM, Xuelei Fan wrote:
> If H2 is not supported, SPDY/3.1 would be attempted, of SPDY/3.1 is not
> supported HTTP/1.1 would be attempted.
Correct.
> If H2 is supported in both side,
> but H2 does not work, it is a H2 problem that need to be addressed in H2
> layer
On 6/5/2015 10:11 PM, Simone Bordet wrote:
> On Fri, Jun 5, 2015 at 2:36 PM, Xuelei Fan wrote:
>> > See more inlines, please.
>> >
>> > Please help on one question I'm not sure of. Per HTTP/2 specification,
>> > Does H2 server allow fallback to HTTP/1.1 if client requests a HTTP/2
>> > connection
Hi,
On Fri, Jun 5, 2015 at 2:36 PM, Xuelei Fan wrote:
> See more inlines, please.
>
> Please help on one question I'm not sure of. Per HTTP/2 specification,
> Does H2 server allow fallback to HTTP/1.1 if client requests a HTTP/2
> connection? I did not find the answer from RFC 7540.
Yes.
The i
See more inlines, please.
Please help on one question I'm not sure of. Per HTTP/2 specification,
Does H2 server allow fallback to HTTP/1.1 if client requests a HTTP/2
connection? I did not find the answer from RFC 7540.
In TLS, if client requests to negotiate TLS v1.2, and server supports
TLS 1
I've just noticed the SSLParameters.setUseCipherSuitesOrder() method.
I guess this can be used to enforce a higher priority for the h2
compatible ciphers
on the server side.
On the new API, I'm not sure about the SSLBase, SSLFunction construct
either.
I don't think it is very clear, and if its
Hi,
On Fri, Jun 5, 2015 at 6:11 AM, Xuelei Fan wrote:
> I think it should be true that if a server can negotiate h2, the server
> MUST support H2 and the enabled cipher suites MUST contains at least one
> H2 required cipher suite. Otherwise, it's bug in server side.
>
> It's instinctive that if
On 6/5/2015 8:37 AM, Bradford Wetmore wrote:
>> I'd like to use:
>>
>> - * Gets the application protocol value(s) received from the peer
>> - * for this connection.
>> + * Gets a {@link List} of requested application protocol value(s)
>> + * for this connection.
>
> I've never seen a link insi
Hi,
See inlines, please.
On 6/5/2015 5:30 AM, Simone Bordet wrote:
> Hi,
>
> On Thu, Jun 4, 2015 at 6:50 PM, Xuelei Fan wrote:
>> Hm, I see your point now. But I may not agree with your ALPN "MUST
>> happen after" protocol/cipher suite negotiation conclusion.
>>
>> I parse this section as, a H
On 6/2/2015 11:23 PM, Xuelei Fan wrote:
src/java.base/share/classes/javax/net/ssl/ExtendedSSLSession.java
=
List getReceivedApplicationProtocols()
--
C1. It might be useful to know the cl
Hi,
On Thu, Jun 4, 2015 at 6:50 PM, Xuelei Fan wrote:
> Hm, I see your point now. But I may not agree with your ALPN "MUST
> happen after" protocol/cipher suite negotiation conclusion.
>
> I parse this section as, a H2 server must be strong enough(comply to
> RFC7540), and a H2 client must also
On 6/5/2015 12:12 AM, Simone Bordet wrote:
> Hi,
>
> On Thu, Jun 4, 2015 at 5:53 PM, Xuelei Fan wrote:
>> On 6/4/2015 8:19 PM, Simone Bordet wrote:
>>> This is not possible for HTTP/2.
>>> Application protocol negotiation MUST happen *after* the TLS protocol
>>> and the TLS cipher are negotiated.
Hi,
On Thu, Jun 4, 2015 at 5:53 PM, Xuelei Fan wrote:
> On 6/4/2015 8:19 PM, Simone Bordet wrote:
>> This is not possible for HTTP/2.
>> Application protocol negotiation MUST happen *after* the TLS protocol
>> and the TLS cipher are negotiated.
>>
> Why? Is it a spec of HTTP/2? It is a point I d
On 04/06/15 15:18, Simone Bordet wrote:
Hi,
On Thu, Jun 4, 2015 at 3:08 PM, Michael McMahon
wrote:
On 04/06/15 13:19, Simone Bordet wrote:
Hi,
On Wed, Jun 3, 2015 at 8:23 AM, Xuelei Fan wrote:
Per section 4, RFC 7301:
"... The
"application_layer_protocol_negotiation" ServerHello e
On 6/4/2015 8:19 PM, Simone Bordet wrote:
> Hi,
>
> On Wed, Jun 3, 2015 at 8:23 AM, Xuelei Fan wrote:
>> Per section 4, RFC 7301:
>> "... The
>>"application_layer_protocol_negotiation" ServerHello extension is
>>intended to be definitive for the connection (until the connection is
>>
Hi,
On Thu, Jun 4, 2015 at 3:08 PM, Michael McMahon
wrote:
> On 04/06/15 13:19, Simone Bordet wrote:
>>
>> Hi,
>>
>> On Wed, Jun 3, 2015 at 8:23 AM, Xuelei Fan wrote:
>>>
>>> Per section 4, RFC 7301:
>>>"... The
>>> "application_layer_protocol_negotiation" ServerHello extension is
>>>
On 04/06/15 13:19, Simone Bordet wrote:
Hi,
On Wed, Jun 3, 2015 at 8:23 AM, Xuelei Fan wrote:
Per section 4, RFC 7301:
"... The
"application_layer_protocol_negotiation" ServerHello extension is
intended to be definitive for the connection (until the connection is
renegotiated) a
Hi,
On Wed, Jun 3, 2015 at 8:23 AM, Xuelei Fan wrote:
> Per section 4, RFC 7301:
> "... The
>"application_layer_protocol_negotiation" ServerHello extension is
>intended to be definitive for the connection (until the connection is
>renegotiated) and is sent in plaintext to permit net
Hi,
On Wed, Jun 3, 2015 at 2:56 AM, Bradford Wetmore
wrote:
> Hi,
>
> I have just posted the second iteration of the ALPN proposal which hopefully
> addresses all of the comments raised here. It is in javadoc format, but
> things can certainly be adjusted:
>
> http://cr.openjdk.java.net/~wet
src/java.base/share/classes/javax/net/ssl/ExtendedSSLSession.java
=
List getReceivedApplicationProtocols()
--
C1. It might be useful to know the client requested application
protocols in som
20 matches
Mail list logo
