On 3/16/07, Karl Chen <[EMAIL PROTECTED]> wrote:
>>>>> On 2007-03-05 13:24 PST, Joe Orton writes:Joe> On Mon, Mar 05, 2007 at 09:33:56PM +0100, Ruediger Pluem wrote: >> On 03/03/2007 05:47 AM, Karl Chen wrote: present. Also >> other issues like noise in the log file. I've also seen >> people complaining that "GET /" might incur the cost of >> dynamic content generation for /. >> >> Hm. Just thinking loud. Can we avoid this if we replace GET >> / with OPTIONS /? Joe> Doing "OPTIONS *" as Bill notes is probably the best Joe> option available for the dummy connection, though it will Joe> still be confusing for users (possible more confusing, Joe> since that request rarely if ever seen "in the wild"). Thanks for the input everyone and pointers to the bugzilla issues. "OPTIONS *" is a definite improvement over "GET /" for performance. What about the NOOP idea? If the connection could be reliably detected to be coming from [EMAIL PROTECTED], would there still be a risk of an attack going unnoticed?
What about having the MPM normally poll on a pipe in addition to listening sockets, and wake up the MPM with the pipe? How many of the folks with a single listening socket (i.e., avoiding the poll currently) would be harmed the extra syscall? Those who need/want to avoid the syscall can compile with a special flag and deal with the slight oddities caused by the dummy connection. Or, if we know there is no kernel accept filtering (this can only happen based on our configuration enabling it, right?), avoid sending the request at all. We only send a real request to get past a kernel filter.
