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
I am using openssl-1.0.1 in my 32bit app on 64bit Windows, I got a crash in
ssleay32!freelist_extract(See Call Stack in the OTHER INFO section as
follow), it is not easy to recreate it and we cannot find a stable way to
recreate it, but it happened several times. After looking into the dump
file
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)
-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
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
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
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
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,
On 20 June 2013 21:46, Jeff Mendoza (MS OPEN TECH)
jemen...@microsoft.com wrote:
-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: