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. Bill
