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
