On Fri, Jul 12, 2013 at 2:08 AM, Ben Reser <ben_at_reser.org> wrote:
> On Thu, Jul 11, 2013 at 7:15 PM, Greg Stein <gstein_at_gmail.com> wrote:
>...
>> I believe the bigger point with tri-state is the change of the
>> *default* from "assumed chunked-request capability" to "perform
>> detection".
>>
>> For 1.9.x, I would be +1 on a default of "perform detection" because I
>> know that with a bit of effort, that detection could be performed with
>> the "next request" after the original OPTIONS negotiation request.
>> That's some work that is absolutely not backportable, if we want to do
>> it right. I can easily see a situation where 1.9.x would auto-detect
>> capability and never need to send an additional OPTIONS probe. The
>> easy path is to send, but we *can* reach a point where we don't have
>> to.
>>
>> So let's just say that 1.9.x will *always* auto-detect because the
>> typical cost is "near zero". We don't even need an option. So whatever
>> is in trunk today would just disappear (or we could keep it for expert
>> users to improve perf a smidgen).
>
> I really don't understand how you can say this AND object to the no
> value in the tristate.
I'm talking about the "no" value in 1.8.1. Rather than saying "that
server causes problems, disable chunking", it should be "that server
has caused me problems, detect if it still does". If they get hit with
C-L, then use an extra OPTIONS to determine if it is still needed
(they may have upgraded the proxy, the user may be on a different
network, etc).
> You say they'll be stuck in a permanent
> degraded state, but at the same time you suggest you believe we'll get
> to the point that there is no overhead at all in detecting.
"near zero [overhead]"
> If that's
> the case then we simply remove the option entirely in 1.9.x and users
> who have set themselves to no will have the best of all worlds when
> they upgrade to 1.9.x.
But during 1.8.x, they could still be using C-L when they don't have
to. That's my problem. Just do the auto-detect for them.
> So why exactly would we deny the users who
> might want to use no for now for some specific purpose the ability to
> do so? If we really go down the path you're laying out here user's
> will never end up with permanently degraded performance.
There is no need for the complexity of a tri-state, or its "no"
pitfall, in the 1.8.x series. Especially given that we will likely be
able to reduce the detection overhead so much in 1.9.x (we can leave
the boolean to disable detection, if people want the extra bit of
perf).
> Based on your suggested method and the one that Branko made on IRC
> earlier today (pipelining two requests one with and one without
> chunking on the first request you'd use chunking with),
Some requests are expensive to produce, so you really wouldn't want to
generate two copies. For these expensive ones, we'd fire off an
OPTIONS detection before running the request (this is why we can get
"near zero", but sometimes there will always be some overhead).
Also, sending duplicate requests might be a bit hard to handle the
response (having to tie the two together, and ignore one, etc).
Doable, sure. IMO, we just go with the 99% expectation that chunked is
support, and fallback if it is not.
> I can see a
> point where we see no reason to have a knob at all. Ultimately this
> is where I want to see us get. But like you I don't think we'll get
> there in 1.8.x.
The extra OPTIONS will always be synchronous in 1.8.x. It is too
intrusive to the 1.8.x branch to try for more.
>...
Cheers,
-g
Received on 2013-07-12 18:45:21 CEST