Re: Straw Poll: Restore Header Table and Static Table Indices

On Tue, Oct 07, 2014 at 04:41:06PM +1100, Mark Nottingham wrote:
> Willy,
> 
> On 7 Oct 2014, at 4:28 pm, Willy Tarreau <w@1wt.eu> wrote:
> 
> > On Tue, Oct 07, 2014 at 03:24:45PM +1100, Mark Nottingham wrote:
> >> That's not where we're at, Greg.
> >> 
> >> The current stance on changing the static table was that we'd do so *if*
> >> we've agreed to make other breaking changes. 
> > 
> > But Mark, people's experience differ depending on the environment where
> > they deploy the protocol, so that means that the current status is too
> > white or too black and that possibly making it a little bit grayer would
> > make it more suitable for most environments. I don't see what's wrong
> > with considering feedbacks from real deployments, *even at this stage*.
> > Otherwise that means testers are useless and we should just work on
> > paper with a wet finger in the wind.
> 
> We are certainly considering feedback from deployment, and we're also
> considering many other things. 
> 
> So far, the WG is strongly leaning towards not making a change here,

No, the WG is strongly against *reverting* as it's the only option that
was offered. One user in a very specific case encounters issues, and one
of the HPACK authors thinks this radical change was a mistake. I think it
at least deserves being studied. I don't think either that reverting would
be a good idea, but I too think that one of the benefit of HPACK lies in
its ability to act as a cache of recently used header fields at a very low
cost, and the last change has increased this cost. Maybe just offering
provisions for 16 indexed headers instead of zero would significantly
improve the situation without affecting other users at all, but that
option was not offered yet.

> and I
> don't see any overriding security or interoperability concern that would make
> a change at this late stage necessary.
> 
> We've discussed this many times, and had it confirmed by our Area Director;
> it's entirely appropriate to reject changes that don't meet this bar (either
> an overriding security or interop issue, or strong group consensus to make
> the change) at this point in the lifetime of the protocol.

I understand this, but I just think that we should at least wonder whether
Jeff's case is unique (in which case we can decide to ignore it) or just a
preview of many new ones that the protocol will meet after the release. At
least thinking a bit could avoid this bitter late feeling of "too bad we
didn't do X or Y when the same issue was reported 6 months ago".

That's my point.

Willy

Received on Tuesday, 7 October 2014 05:49:49 UTC