Tri-state for http-detect-chunking config option

Hey all,

Right now, trunk and the 1.8.1 backport request implements the following option:

http-detect-chunking = off / default: perform no detection. A 411
response will throw an error message suggest to turn this option on.

  = on: send an extra OPTIONS at session setup to detect chunk
requests capability.

The tri-state switches this to:

  = auto / default: send an extra OPTIONS. like "on" above.

  = yes: no delivery of OPTIONS. presume chunked is allowed.

  = no: no delivery of OPTIONS. only use C-L, as chunked is presumed
to not be allowed.

Note that the tri-state changes the default from "off" to "on",
relative to the current/boolean implementation.

My current concern with the tri-state is people who set "=no". They
will permanently degrade to C-L requests. That is problematic today,
and especially as ra_serf advances. If the server admin upgrades to a
chunked-enabled proxy, the client would still be in suckage-land.

Further: consider if a client is thrown down in the C-L pit, then
hey.. why NOT throw in some dynamic detection? Can't hurt them much
more, so go ahead and detect.

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).

That leaves the 1.8.1 release. There are several possibilities here:

1) stick to the current trunk/backport implementation: users should
tweak a config knob or get the repos to upgrade their proxy

2) switch the (current) knob to default=on. users eat a bit of request
cost, experts can kill that off.

3) switch to tri-state for full control. no cost to users (w.r.t
on/off chunked capability), or a bit in the "auto/default" state to
perform detection.

This seems to be the current set of possibilities. Any others??

Personally, my thoughts related to the above actions:

1) +1. default is "off" for 1.8.x. becomes "on" for 1.9.x since we can
make detection very cheap. (while I like this, not sure if a default
change is advisable?)
2) +0. the extra request is a perf regression. (and while I like
breser's test, I think the test suite is not a good vehicle for this
kind of test)
3) -something. I don't like the "no" option. Moving towards the
future, I think the *typical* detection overhead will be so small,
that we barely need the config knob, let alone a setting that can be
Bad if set inappropriately.

Note: my request to apply the -9117 group is still there. It needs to
be applied for any of three options. Please update STATUS.

Cheers,
-g
Received on 2013-07-12 04:16:07 CEST