Hi Willy,
Thanks for sharing that. First, I'm amazed that such a hacky method
works well-enough to get QUIC (nearly-fully) working.
Now for your concerns... Honestly, I agree with you and really don't
want to see a brand new protocol compromised on.
Whether one calls it "ossification" or "degraded", it would be a
compromise on a spec that hasn't even reached mass adoption yet, because
of one single stubborn library's committee.
So many hours of our lives (in IT) are wasted on dealing with poor
decisions from the past, leading to inconsistent specs, surprising
behaviours, and security holes left and right.
And these *always* have some obscure justification like "but at the
time, popular software $XYZ wasn't compliant/nice/$whatever, so everyone
was forced to give in, and this is why the spec is now crap".
I've spent far too long complaining and cursing about these things to
not feel strongly against it as it unfolds in my own time for once,
instead of feeling helpless because it happened 25 years ago.
Now that said, I'd understand if HAProxy went forward with it, even if
that feels bad.
I think it'd be a smart thing for the project to do.
Not for technical reasons, but from a "marketing" standpoint (and I
don't mean the word in a negative way). If other similar projects adopt
it, then HAProxy would be the only one missing it, and be perceived as
lacking a feature from a prospective user's point of view. After all,
people *will* keep comparing HAProxy with nginx & friends. And they
won't really care about the hacks that were necessary to get there.
So while it'd be sad, and I'd much much prefer seeing wolfSSL become the
new standard instead, it would not be that unreasonable for HAProxy to
adopt the patch either...
Between a rock and a hard place,
Tristan
