At 03:58 PM 6/16/2003, Justin Erenkrantz wrote: >--On Monday, June 16, 2003 3:37 PM -0500 "William A. Rowe, Jr." <[EMAIL PROTECTED]> >wrote: > >>You must implement a peek-ahead filter that sets aside the post body. >>Once someone calls the filter stack later, you simply return your set aside >>buckets. Several modules do something similar today, either for incomplete >>data (like charset_lite, which might not have a complete trailing character >>code sequence) or ssl (which might decrypt more data than the caller >>wished to have returned.) > >This would only work if you can wait until or after the handler has been invoked. >From Michael's original email, he wanted the data in the fixups hook which is before >the handler is invoked. Therefore, a peek-ahead filter would only be invoked >during/after the handler. > >This might be enough of a widespread concern that we need to figure out how to >cleanly address this. But, I don't think we have anything in place for that >currently. -- justin
Why do you say that? SSL is a connection level filter that can persist beyond a single request. There is nothing to say that one can't author a pre-handler filter that looks at the post data before someone comes along with some get_client_block style call. Of course you have to pay attention to when your filter should try to peek ahead, e.g. not attempt to read a body from a HEAD style request.
