Re: ap_invoke_handler
> I assume that most filters that buffer data or have other saved state > across invocations stash it off of f->ctx. If that exists, you know > there is a possibility of corrupting the data stream if you remove the > filter. Wouldn't this be better done in remove_any_filter rather than by the module? It's just asking for trouble to make sure that all module developers check f- >ctx before calling remove filter. Of course, your comment about state maintainance still applies. >If f->ctx doesn't exist, it's less likely but possible of > course. Perhaps we should make a rule that if a filter stashes data, > it better set f->ctx to non-null. > --- Aryeh Katz Secured-Services Inc.
Re: ap_invoke_handler
William A. Rowe, Jr. wrote: Once *one* byte of data has passed through a given filter within the filter chain, you cannot know if one filter is sitting on bytes of request or response body that it is waiting for completion. Maybe it has a partial token stored, maybe it's an incomplete multibyte sequence for a given code page translation. In both cases, once a byte is inside the filter chain, during a request (this is what I'm assuming your module does) you cannot add and drop filters. +1 on this sentiment. I assume that most filters that buffer data or have other saved state across invocations stash it off of f->ctx. If that exists, you know there is a possibility of corrupting the data stream if you remove the filter. If f->ctx doesn't exist, it's less likely but possible of course. Perhaps we should make a rule that if a filter stashes data, it better set f->ctx to non-null. Greg
Re: ap_invoke_handler
At 03:43 PM 10/21/2003, Nick Kew wrote: >> Ahhh. Now look at the code below. WHO removes the byterange filter? >> >> Answer, the byterange filter removes itself. > >That's perfectly clear, and it's common practice. I (and evidently >others) read your previous post as disallowing that, causing a >raised eyebrow. > > >> It *knows* there are no partially >> processed buckets that it is holding on to. Nobody else is allowed to add >> or remove a filter - but the filter may remove itself when it knows this is >> a safe operation. > >May I humbly submit there are other perfectly safe situations: > (1) Any filter in its filter_init phase can remove another > filter (some of my output filters remove the Content-Length > filter - as it was causing bogus results on HEAD requests). > (2) In the main loop, a filter can remove another from later > in the chain before any data have been passed through. > (3) Where another filter's behavious is known to be safe > (mod_diagnostics filters can be removed at any time). Great summary :) However, number (3) use some caution. Although you think that the DIAGNOSTIC filter behaves a certain way, the next upgrade by the author might introduce new considerations. Bill
Re: ap_invoke_handler
> Ahhh. Now look at the code below. WHO removes the byterange filter? > > Answer, the byterange filter removes itself. That's perfectly clear, and it's common practice. I (and evidently others) read your previous post as disallowing that, causing a raised eyebrow. > It *knows* there are no partially > processed buckets that it is holding on to. Nobody else is allowed to add > or remove a filter - but the filter may remove itself when it knows this is > a safe operation. May I humbly submit there are other perfectly safe situations: (1) Any filter in its filter_init phase can remove another filter (some of my output filters remove the Content-Length filter - as it was causing bogus results on HEAD requests). (2) In the main loop, a filter can remove another from later in the chain before any data have been passed through. (3) Where another filter's behavious is known to be safe (mod_diagnostics filters can be removed at any time). -- Nick Kew
Re: ap_invoke_handler
At 12:45 PM 10/21/2003, André Malo wrote: >* "William A. Rowe, Jr." <[EMAIL PROTECTED]> wrote: > >> Answer, the byterange filter removes itself. It *knows* there are no partially >> processed buckets that it is holding on to. Nobody else is allowed to add >> or remove a filter - but the filter may remove itself when it knows this is >> a safe operation. > >Sorry Bill, that doesn't match the reality. Think of AddOutputFilterByType and a >content-type changing filter module (PHP output filter, for example). > >The core triggers a filter insertation for *every* content-type change. >And - actually, this can be quite useful (again, think of PHP. The script may return >different content types). All of the by-type filter changes occur BEFORE bytes start passing. I read this request as the possibility that the user was trying to modify the list of filters after some filtering had started. The part that had me most concerned was removing the filter, which is dangerous after filtering begins, for the reasons I mentioned before. Of course you can add and remove filters however you like before we actually process the request :) Sorry for any confusion. Bill
Re: ap_invoke_handler
* "William A. Rowe, Jr." <[EMAIL PROTECTED]> wrote: > Answer, the byterange filter removes itself. It *knows* there are no partially > processed buckets that it is holding on to. Nobody else is allowed to add > or remove a filter - but the filter may remove itself when it knows this is > a safe operation. Sorry Bill, that doesn't match the reality. Think of AddOutputFilterByType and a content-type changing filter module (PHP output filter, for example). The core triggers a filter insertation for *every* content-type change. And - actually, this can be quite useful (again, think of PHP. The script may return different content types). nd
Re: ap_invoke_handler
At 09:51 AM 10/21/2003, [EMAIL PROTECTED] wrote:
>William A. Rowe, Jr. wrote:
>>At 03:17 PM 10/20/2003, Aryeh Katz wrote:
>>
>>>I have an input filter that might need to reinvoke the handler that inserted this
>>>input filter (this time with the filter removed).
>
>> Do not attempt to remove a filter once it's inserted, simple force it to be inert.
>
>hmmm?
Ahhh. Now look at the code below. WHO removes the byterange filter?
Answer, the byterange filter removes itself. It *knows* there are no partially
processed buckets that it is holding on to. Nobody else is allowed to add
or remove a filter - but the filter may remove itself when it knows this is
a safe operation.
Be careful here, by the way. We have to be certain that f itself isn't
modified, such that the next reference of f->next isn't corrupted. That
won't occur in 2.0.x. Hopefully 2.1-dev retains that behavior, but for
safetys sake, this code would be better if you dereferenced f->next
and saved it, then called remove, the passed the saved reference.
Somewhat pedantic but it seems cleaner to me.
Bill
>modules/http/http_protocol.c:: ap_byterange_filter()
>
>/* We have nothing to do, get out of the way. */
>if (num_ranges == 0) {
>ap_remove_output_filter(f);
>return ap_pass_brigade(f->next, bb);
>}
>
>Greg
>
RE: ap_invoke_handler
> At 06:06 AM 10/21/2003, Tikka, Sami wrote: > >>-Original Message- > >>From: William A. Rowe, Jr. [mailto:[EMAIL PROTECTED] > >[...] > >>Do not attempt to > >>remove a filter once it's inserted, simple force it to be > >>inert. Serveral Apache filters already do this, although I > >>can't name one offhand (SSL might be, I think.) > > > > Perhaps I am just missing something, but is there something > >wrong in removing a filter, perhaps by itself, using > >ap_remove_input/output_filter() > > Once *one* byte of data has passed through a given filter within the > filter chain, you cannot know if one filter is sitting on bytes of > request or response body that it is waiting for completion. Maybe it > has a partial token stored, maybe it's an incomplete multibyte > sequence for a given code page translation. In both cases, once a byte > is inside the filter chain, during a request (this is what I'm > assuming your module does) you cannot add and drop filters. > In my input filter, I don't pass ANY data on until I am sure all the filter processing is done (the filter is only inserted selectively). What would be wrong with calling remove_filter then? It was inserted when required, and when I'm ready to return (and pass some data on), remove the filter I just inserted. > Those APIs are used for changing the filters before the request is > processed. --- Aryeh Katz Secured-Services Inc.
RE: ap_invoke_handler
At 06:06 AM 10/21/2003, Tikka, Sami wrote: >>-Original Message- >>From: William A. Rowe, Jr. [mailto:[EMAIL PROTECTED] >[...] >>Do not attempt to >>remove a filter once it's inserted, simple force it to be >>inert. Serveral Apache filters already do this, although I >>can't name one offhand (SSL might be, I think.) > > Perhaps I am just missing something, but is there something wrong in >removing a filter, perhaps by itself, using ap_remove_input/output_filter() Once *one* byte of data has passed through a given filter within the filter chain, you cannot know if one filter is sitting on bytes of request or response body that it is waiting for completion. Maybe it has a partial token stored, maybe it's an incomplete multibyte sequence for a given code page translation. In both cases, once a byte is inside the filter chain, during a request (this is what I'm assuming your module does) you cannot add and drop filters. Those APIs are used for changing the filters before the request is processed.
Re: ap_invoke_handler
William A. Rowe, Jr. wrote:
At 03:17 PM 10/20/2003, Aryeh Katz wrote:
I have an input filter that might need to reinvoke the handler that inserted this
input filter (this time with the filter removed).
Do not attempt to remove a filter once it's inserted, simple force it to be inert.
hmmm?
modules/http/http_protocol.c:: ap_byterange_filter()
/* We have nothing to do, get out of the way. */
if (num_ranges == 0) {
ap_remove_output_filter(f);
return ap_pass_brigade(f->next, bb);
}
Greg
RE: ap_invoke_handler
>-Original Message- >From: William A. Rowe, Jr. [mailto:[EMAIL PROTECTED] [...] >Do not attempt to >remove a filter once it's inserted, simple force it to be >inert. Serveral Apache filters already do this, although I >can't name one offhand (SSL might be, I think.) Perhaps I am just missing something, but is there something wrong in removing a filter, perhaps by itself, using ap_remove_input/output_filter() -- Sami Tikka, senior software engineer, F-Secure Corporation tel: +358 9 2520 5115, fax: +358 9 2520 5015 http://www.F-Secure.com F-Secure: Securing the Mobile Enterprise
Re: ap_invoke_handler
At 03:17 PM 10/20/2003, Aryeh Katz wrote: >I have an input filter that might need to reinvoke the handler that inserted this >input filter (this time with the filter removed). The right way to do that is to store a per-request apr_pool_data holder for the request. Do not attempt to remove a filter once it's inserted, simple force it to be inert. Serveral Apache filters already do this, although I can't name one offhand (SSL might be, I think.) >It worked exactly as I expected on a UNIX box. >Then, when I did the WIN32 port, I saw the function signature >(CORE_DECLARE) and realized I was in trouble. >I had previously tried _redirect_internal but this did not work. >Is there any other way to get the handler reinvoked? >If not, is there a good reason why ap_invoke_handler is marked private? Yes, because you shouldn't reinvoke the handler, in general. If you must, be sure you include the correct header files (httpd.h etc) in the right order, and be sure /D "WIN32" /D "CORE_PRIVATE" are given to toggle the correct includes. Bill
