httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <>
Subject Re: event MPM works with mod_ssl
Date Mon, 27 Jun 2005 18:20:42 GMT
At 11:44 AM 6/27/2005, Greg Ames wrote:
>Paul Querna wrote:
>>Yes... I believe it will 'mostly' work, but the issue becomes tricky
>>once you consider the SSL protocol.  The problem is we might have an
>>entire pipe-lined request buffered inside the SSL Packets, and
>>therefore, never trigger the socket to come out of the poll().  For
>>simple test cases, it might work, but I am pretty sure a malicious
>>attack would be easy to create.
>hmmm...I assume the poll() on the listening socket works ok or worker would be busted
too.  then as long as we call the input filters to read the request without poll()ing first
to see if the new SSL socket is readable, we should be ok.  if we completely drain the input
filters, we should be reading from the SSL input filters at the same time, so then it should
be safe to poll().  or have I missed something?

Anyone trying to read from the input brigade better invoke a request
non-blocking first, so that any filter down the chain gets a chance
to answer.  If it's would-block, then perhaps you can poll(), but
that's still pretty dicey.

I solved this with my bucket_poll suggestion a couple years ago, but
it never did gain much traction.

In fact; I think poll buckets are required before we can move alot
further with the event-style mpm.  Although you ***MIGHT*** be
blocking on the socket (usually you are), there's another possibility
that you are blocking on read from something else in an input filter.
The poll meta-bucket was ment to be stackable, so that multiple poll
events could percolate up.  That way, external_filter sources, etc
could all be added to the poll() event.  Each filter could keep/drop
the previous filters' poll bucket list, depending on if the filter
believes there could be side-effects from more data above it.

E.g. if the Z filter knows it has enough buffered to be called again,
it would drop the poll bucket.  When called again, it might finally
percolate the poll bucket when it knows it can't return any more data
without more input.


View raw message