RE: [Patch] ALPN Implementation for OpenSSL

2013-07-11 Thread Jeff Mendoza (MS OPEN TECH)
Understood, I'll start working on this behavior: The client can send ALPN, NPN, or both. If the client only sends one: negotiation will take place normally. If the client sends both: the server will prefer ALPN. If nothing matches with ALPN, it will fall back to NPN and send its list.

Re: [Patch] ALPN Implementation for OpenSSL

2013-06-25 Thread Ben Laurie
On 24 June 2013 22:00, Jeff Mendoza (MS OPEN TECH) jemen...@microsoft.com wrote: We simply cannot drop support for NPN (i.e. SPDY) just to add support for ALPN. The idea is to have the choice as a ./config option. The default will stay as NPN, as to not disrupt anyone. I don't have this

RE: [Patch] ALPN Implementation for OpenSSL

2013-06-24 Thread Jeff Mendoza (MS OPEN TECH)
Hi All, Yes, supporting both at runtime would be best. But having a compile-time option now, and defaulting to NPN should keep this from being a blocking issue with the patch, correct? It would also make it kind of useless, at least from my non-authoritative point of view. Understood,

RE: [Patch] ALPN Implementation for OpenSSL

2013-06-24 Thread Jeff Mendoza (MS OPEN TECH)
We simply cannot drop support for NPN (i.e. SPDY) just to add support for ALPN. The idea is to have the choice as a ./config option. The default will stay as NPN, as to not disrupt anyone. I don't have this in the patch yet. That doesn't make any sense. How would a server serve both

Re: [Patch] ALPN Implementation for OpenSSL

2013-06-22 Thread Ben Laurie
On 21 June 2013 02:29, Thor Lancelot Simon t...@panix.com wrote: On Thu, Jun 20, 2013 at 09:30:32PM +, Jeff Mendoza (MS OPEN TECH) wrote: Yeah, my point was that in the perfect world, you'd support both at runtime (at least on the server-side) and either ALPN or NPN could be used. I

Re: [Patch] ALPN Implementation for OpenSSL

2013-06-21 Thread Rajesh Malepati
: Thursday, June 20, 2013 10:41 AM To: openssl-dev@openssl.org Subject: Re: [Patch] ALPN Implementation for OpenSSL We simply cannot drop support for NPN (i.e. SPDY) just to add support for ALPN. The idea is to have the choice as a ./config option. The default will stay as NPN

RE: [Patch] ALPN Implementation for OpenSSL

2013-06-20 Thread Parashuram Narasimhan (MS OPEN TECH)
Hi, I realize it has only been a few days since we originally posted this patch for Application Layer Protocol Negotiation (ALPN) support. I just wanted to expand on why we think this is an important patch for OpenSSL. The latest HTTP/2.0 draft specifies support for a TLS extension called ALPN

Re: [Patch] ALPN Implementation for OpenSSL

2013-06-20 Thread Piotr Sikora
Hi, We really want to work with you to get this patch into OpenSSL to help developers of HTTP/2.0 draft implementations. We welcome your assistance to review this patch. What really makes this patch unusable (at least for us) is this snippet: +#if !defined(OPENSSL_NO_NEXTPROTONEG)

RE: [Patch] ALPN Implementation for OpenSSL

2013-06-20 Thread Jeff Mendoza (MS OPEN TECH)
-Original Message- From: owner-openssl-...@openssl.org [mailto:owner-openssl-...@openssl.org] On Behalf Of Piotr Sikora Sent: Thursday, June 20, 2013 10:41 AM To: openssl-dev@openssl.org Subject: Re: [Patch] ALPN Implementation for OpenSSL We simply cannot drop support for NPN

Re: [Patch] ALPN Implementation for OpenSSL

2013-06-20 Thread Piotr Sikora
Hey Jeff, The idea is to have the choice as a ./config option. The default will stay as NPN, as to not disrupt anyone. I don't have this in the patch yet. Yeah, my point was that in the perfect world, you'd support both at runtime (at least on the server-side) and either ALPN or NPN could be

RE: [Patch] ALPN Implementation for OpenSSL

2013-06-20 Thread Jeff Mendoza (MS OPEN TECH)
Yeah, my point was that in the perfect world, you'd support both at runtime (at least on the server-side) and either ALPN or NPN could be used. I want to have a library that supports both, not either-or. Yes, supporting both at runtime would be best. But having a compile-time option now, and

Re: [Patch] ALPN Implementation for OpenSSL

2013-06-20 Thread Piotr Sikora
Hey, Yes, supporting both at runtime would be best. But having a compile-time option now, and defaulting to NPN should keep this from being a blocking issue with the patch, correct? It would also make it kind of useless, at least from my non-authoritative point of view. Best regards, Piotr

Re: [Patch] ALPN Implementation for OpenSSL

2013-06-20 Thread Thor Lancelot Simon
On Thu, Jun 20, 2013 at 09:30:32PM +, Jeff Mendoza (MS OPEN TECH) wrote: Yeah, my point was that in the perfect world, you'd support both at runtime (at least on the server-side) and either ALPN or NPN could be used. I want to have a library that supports both, not either-or. Yes,

Re: [Patch] ALPN Implementation for OpenSSL

2013-06-20 Thread Ben Laurie
: [Patch] ALPN Implementation for OpenSSL We simply cannot drop support for NPN (i.e. SPDY) just to add support for ALPN. The idea is to have the choice as a ./config option. The default will stay as NPN, as to not disrupt anyone. I don't have this in the patch yet. That doesn't make any sense

RE: [Patch] ALPN Implementation for OpenSSL

2013-06-14 Thread Parashuram Narasimhan (MS OPEN TECH)
Hi, Attached the Patch for the OpenSSL with ALPN implementation. -Original Message- From: Parashuram Narasimhan (MS OPEN TECH) Sent: Thursday, June 13, 2013 5:57 AM To: 'openssl-dev@openssl.org' Subject: [Patch] ALPN Implementation for OpenSSL Hi, I work for Microsoft Open