name-conflicts in cl-http2-protocol-example between cl+ssl:+ssl-op-no-tlsv1-1+ and cl-async-ssl:+ssl-op-no-tlsv1-1+ about cl-http2-protocol

[martinflack]

Hi, the current code is now quite old. To get this to compile would require using the versions of dependencies CL-ASYNC-SSL and CL+SSL mentioned in the README. The above error looks like the type of message from compiling against the latest versions. Those libraries have evolved, so although this symbol conflict is quite easy to resolve, there is more work to match all the changes. Part of the issue is that to get CL-HTTP2-PROTOCOL to work, I hacked some internals of those libraries and posted those changes in this repo, but I didn't push them upstream, because of time constraints. It's not a lot of lines of code in terms of those changes, but the underlying libraries have now completely changed those functions. I read through the logs for the other two libraries today to see if I could make a commit that would get this compiling on the latest versions, but it will take some time.

(Also, just FYI, speaking of age... currently this library only implements draft-14 which is not the final version of HTTP/2. I posted it during the standards process as part of community review of the protocol and we used it to test for bugs in each other's implementations.)

[martinflack]

I should note that an alternative to extensive hacking on this library would be to get CL-ASYNC-SSL and CL+SSL to support: TLS v1.2 (they may already, it's listed as v1 - HTTP/2 requires TLS 1.2), ALPN (to negotiate the protocol start), dhparams (it slips my mind what this is for), and SNI (to select hostnames without relying upon server IP address). (I used NPN in this version instead of ALPN, as was customary in 2014, but folks moved from NPN to ALPN in 2015, so we would update that.) SNI is also desirable, but if I recall that did make it upstream, for clients at least, because it was necessary to reach many websites.

[ctsrc]

I see, thanks for taking the time to respond :)

[Symbolics]

These particular errors are caused by duplicate definitions in cl+ssl and cl-async. I've raised the question on how this should be handled in orthecreedence/cl-async#186. cl-async doesn't use cl+ssl, instead wrapping libssl itself, so we may have to manually import the duplicate definitions from one library or the other.

@martinflack, it seems that the upstream libs do support TLS v1.2 and SNI. I wasn't able to find any sign of ALPN in there in my quick grep, but it's currently in OpenSSL and Windows SSPI. Is this a problem that can be ignored? I.e. are current clients going to fall back to NPN if ALPN isn't available?

I see in the README where the hacks are. When you responded to @ctsrc above about an alternative to hacking on this library, what exactly did you have in mind? If 2/3 features needed (TLS 1.2 and SNI) have made it upstream, what would a plan to move forward be?