Well there you go then.
Thanks!
On 06/08/2013, at 10:53 AM, Piotr Sikora pi...@cloudflare.com wrote:
Hey Mark,
ALPN support is already in the mainline:
http://git.openssl.org/gitweb/?p=openssl.git;a=commit;h=6f017a8f9db3a79f3a
3406cf8d493ccd346db691
Best regards,
Piotr
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.
Hi,
I work for Microsoft Open Technologies, a wholly owned subsidiary of
Microsoft Corp. My team is currently working on a patch to OpenSSL to
allow for early testing and interoperability.
More background is available at http://tools.ietf.org/html/draft-ietf-
httpbis-http2-03#section-2.3.
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,
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
-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
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
