On Tue, Jun 25, 2013 at 8: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.
>
>> I suppose there might be a proxy that accepts some chunked requests but
>> not others and so we might get a 411 in the middle of a pipeline. For
>
> I doubt you would ever get a 411 in the *middle* of a series of
> pipelined request. The proxy is going to allow all, or allow none of
> the requests to use chunking.
>
> (or more precisely: I believe the code should make that assumption
> until we find/learn otherwise)
>
>> that case we probably need the config knob even if we add some automatic
>> detection. But that's a theoretical problem, the bug reports so far
>> involve a proxy with no support for chunked requests for which automatic
>> detection should be possible.
>
> Right. I believe the config knob should be "busted-proxy" and it
> should kick off a second OPTIONS request to detect whether chunked
> requests are allowed.
>
> To that end, I find r1496470 to be insufficient. We need the dynamic
> stuff, and we need to fix the configuration option name. I'm happy to
> work on these two pieces, if we have a bit of consensus.
I read Ivan's response earlier as saying we need a quick fix for 1.8.1
(the config knob) which gives us some time to implement a better
solution.
That better solution would be the extra request, is that something you
can reasonably implement in the coming days and all of us can test
sufficiently?
> Cheers,
> -g
Lieven
Received on 2013-06-25 22:52:16 CEST