On Wed, Jun 26, 2013 at 2:12 AM, Daniel Shahaf <danielsh_at_elego.de> wrote:
> Johan Corveleyn wrote on Tue, Jun 25, 2013 at 23:22:12 +0200:
>> On Tue, Jun 25, 2013 at 11:03 PM, Ivan Zhakov <ivan_at_visualsvn.com> wrote:
>> > On Tue, Jun 25, 2013 at 10:45 PM, Greg Stein <gstein_at_gmail.com> wrote:
>> >> On Tue, Jun 25, 2013 at 11:55 AM, Philip Martin
>> >> <philip.martin_at_wandisco.com> wrote:
>> >>> Branko Čibej <brane_at_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).
Please note that this extra request is per session and currently we
create many sessions even during one operation. And I'm also not happy
to make performance worse for users who doesn't use reverse proxies
and etc.
--
Ivan Zhakov
Received on 2013-06-26 00:21:58 CEST