Re: Implementer intent -- option 3 for #578

Hi Mark,

On Thu, Oct 23, 2014 at 12:01:46PM +1100, Mark Nottingham wrote:
> It looks like there's a good amount of interest in Option 3 (Willy's proposal) for issue #578. However, there's also concern that it is untested, and pushback on that basis.
> 
> I am *extremely* wary of making a substantial change in the protocol at the last minute without implementation and testing; there is a large risk of introducing bugs, security issues and interop problems.
> 
> So, if we want to pursue option #3, I think we need to do another Implementation Draft based upon it, with a subsequent interop. This will blow out our schedule by one cycle; historically, that means about two to three months (although the holiday season is approaching, so it may be longer).
> 
> Such an interop might be another Interim (likely in January), or it might be virtual; we'd figure that out later. 
> 
> With that in mind, I'd like to hear from our implementers -- who is interested in this enough to implement a new draft and be able to bring it an interop on such a timeframe?
> 
> Please, one person per implementation, and identify your implementation as you do so (we have enough now that it's necessary).
> 
> Note that I'm not saying we're converging on option 3 yet -- I'm trying to find out more about what it would mean if we go in that direction.

Speaking for haproxy, I'm far from having anything close to an implementation
and don't expect to have one by the time we have a standard. However I'll
implement whatever encoding we come up with by then since I'm not worried
with swapping a few bits around. What matters for me is that we don't emit
a new frozen standard that adapts poorly to new use cases. We've known the
set-cookie mess, NTLM, pipelining issues and such things causing all of us
some trouble with H1, I find it important to care a lot about possible
future implementations.

I would like it if someone with an easy-to-modify implementation could run
some tests quickly, as I mostly focused minimizing changes first without
having a working implementation to verify them, and am convinced the
encoding I proposed is not optimal (as shown later in the same thread),
and we'd rather ensure we don't degrade current performance in a new
draft (which was the cause for this proposal). But since we don't have
numbers yet, we could have good surprizes as well.

Also since Jeff is the one who experienced the regression in the first
place, he definitely has an example of problematic workload. It would
be nice if he could either give this a try, or provide some traces to
someone with a flexible implementation.

Best regards,
Willy

Received on Thursday, 23 October 2014 05:15:57 UTC