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.
