On Thu, Apr 14, 2011 at 04:41:01AM -0500, William Rowe wrote: > It seems like our directive is a serious misnomer, if it is required to > enable either legacy or new renegotiation. Before 2.2.18, it seems > prudent to make this a tristate (legacy or modern, modern only, or none) > and support it again, even if the default is a safe 'none' value.
I think you're mixing the two separate (and technically orthogonal) questions: a) whether or not to allow insecure renegotiation b) whether or not to allow client-initiated reneg The directive controls (a), and (b) is hard-coded to "not allowed". If there is evidence that the default setting for (b) is wrong let's hear the arguments, and consider whether a default of "allowed" is instead appropriate, rather than jumping to add another config option? Re: your other point, on performance impact of client-initiated reneg, I agree with you; others in that thread argue that there there is a kind of "unanticipated" CPU overhead of reneg which may not be accounted for in traditional load/bandwidth/connection-limiting or balancing techniques. e.g. MaxKeepAliveRequests to some degree bounds resource usage per TCP connection at HTTP level; there's no equivalent to bound CPU usage due to renegs. I'm not sure this is a particularly solid argument though. Regards, Joe
