httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Orton <jor...@redhat.com>
Subject Re: Fwd: Client Initiated Renegotiation after 0.9.8l
Date Thu, 14 Apr 2011 14:10:25 GMT
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

Mime
View raw message