Stefan Sperling wrote on Thu, Jul 11, 2013 at 11:54:39 +0200:
> On Thu, Jul 11, 2013 at 01:52:07AM -0400, Greg Stein wrote:
> > Hey all,
> >
> > I'd like to see us get this approved and applied to 1.8.x. My recent
> > changes "should" remove danielsh's issue with the patch group.
> >
> > Regarding Ben's, I'd suggest: any additional change would build upon
> > this group. Thus, since the darned group is getting pretty large, I
> > think it would make sense to get it folded in.
> >
> > It provides *a* solution to the proxy/chunked issue. Is more work
> > needed? Maybe. There isn't clear consensus yet. But again: this group
> > is a necessary precondition to any further work anyways.
>
> I'd like a tri-state setting for the http-detect-chunking option (yes,
> no, auto) that defaults to "auto". That was the best suggested approach,
> in my opinion. I don't think we should compromise interoperability for
> performance concerns over a single HTTP request. Especially in a patch
> release.
>
> If you're saying that we're going to ship 1.8.1 with a two-state option,
> and ship a tri-state option in a later 1.8 release, I might be happy with
> that. But I don't really understand why we're not going for tri-state
> right now.
The difference between the approved group and the tristate branch is
that the former lacks the "no" option. The "no" option shaves a part
of a second off the interactive response time of people who are behind
a 411ing proxy, but that cost applies unconditionally even if the proxy
gets upgraded. I'm not sure which way I lean, I guess ±0 but that may
change.
Also, if we backport http-detect-chunking as binary and later want to
make it a tristate, we should ask people to either set it to "yes" or to
leave it commended out --- since the "no" answer to the binary option
corresponds to the "auto" answer to the tristate option.
Received on 2013-07-11 15:39:20 CEST