I hope that, if we picked up (some of) this patch, you got credit :) Before my
time.
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
I have attached a patch with our updated ALPN implementation. ALPN and NPN
are both supported at runtime, with a preference for ALPN. ALPN can be
disabled at ./config time, like most options.
We would greatly appreciate any feedback on our implementation. Also, I
have a patch against
We believe our latest patch has addressed all feedback we have received so far.
As far as we can tell this is ready for inclusion in the main trunk of the
project. Naturally, if this is not the case and we still need to make changes
we are happy to work with the community. Assuming no further
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.
.
Attached is the patch for ALPN Implementation for OpenSSL.
Had already sent an email to discuss this on the dev mailing list.
Thanks
Parashuram
Microsoft Open Technologies Inc
I have attached a patch with our updated ALPN implementation. ALPN and NPN are
both supported at runtime
/draft-ietf-
httpbis-http2-03#section-2.3.
Attached is the patch for ALPN Implementation for OpenSSL.
Had already sent an email to discuss this on the dev mailing list.
Thanks
Parashuram
Microsoft Open Technologies Inc
I have attached a patch with our updated ALPN implementation. ALPN
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
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
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
: 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
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
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,
: [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
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
.
Attached is the patch for ALPN Implementation for OpenSSL.
Had already sent an email to discuss this on the dev mailing list.
Thanks
Parashuram
Microsoft Open Technologies Inc
openssl-alpn.patch
Description: Binary data
Hi,
I work for Microsoft Open Technologies, a wholly owned subsidiary of Microsoft
Corp. My team is currently working on the standardization process for HTTP/2.0:
as I believe many of you may have heard, the latest working draft @ IETF
requires using ALPN as the mechanism for secure
22 matches
Mail list logo
