Johan Corveleyn wrote on Tue, Jun 25, 2013 at 23:22:12 +0200: > On Tue, Jun 25, 2013 at 11:03 PM, Ivan Zhakov <i...@visualsvn.com> wrote: > > On Tue, Jun 25, 2013 at 10:45 PM, Greg Stein <gst...@gmail.com> wrote: > >> On Tue, Jun 25, 2013 at 11:55 AM, Philip Martin > >> <philip.mar...@wandisco.com> wrote: > >>> Branko Čibej <br...@wandisco.com> writes: > >>> > >>>> I'm really not a fan of this config knob. Anyone who carries their > >>>> laptop around will effectively have to set this as the default, because > >>>> you never know when the next weird proxy will pop up in front of your > >>>> server. And disabling chunked requests by default is a lot worse than > >>>> the extra non-pipelined request for broken proxies, IMO. > >> > >> Right. > >> > >> Though I suspect most of the problems are reverse proxies in front of > >> a particular server, so you can put the config option into a [server] > >> config block instead of global. That will help to limit the problem, > >> but lack of dynamic detection is still a problem. > >> > > What is the benefit of dynamic detection enabled by some knob in config > > file? > > The dynamic detection has a cost (1 extra request per connection), > that you might want to avoid by default (most environments won't need > the dynamic detection (especially corporate environments)). Only > enable the dynamic detection if you know the proxy has a problem with > chunkness, or if you're not sure it will stay that way, or ... > > (not interfering with the rest of the discussion right now :-)
AIUI the cost is only incurred by set-ups that have the so-called "busted" proxies. And a config option has a cost too: it would need to be supported until 2.0 (aka, indefinitely).
