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: Any votes on this??
William A. Rowe, Jr. wrote: On Mon, 20 Oct 2003, Jim Jagielski wrote: * isn't ap_die() broken with recognizing recursive errors Have you had a chance to run it through the perl-framework testsuite? If so I'd give it +.5. Does the perl test suite check error handling at all? (just curious) 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: Can't use handler + reverse proxy
* Matthieu Estrade <[EMAIL PROTECTED]> wrote: > I could do with a filter but i need to place it before authentication > hook... > I have just finished what i wanted to do: > > The quick handler is controlling if the user is already authenticated > (cookie based or session table) Hmm. You could hook into the access or authentication hook, which is the appropriate place for such things. nd
Re: Can't use handler + reverse proxy
I could do with a filter but i need to place it before authentication hook... I have just finished what i wanted to do: The quick handler is controlling if the user is already authenticated (cookie based or session table) if not, the quick handler setup an output filter which will send the authentication form to the client. if the user is authenticated, then i return declined and all is working normally. I did exactly like mod_cache is working. Cliff Woolley wrote: On Tue, 21 Oct 2003, Matthieu Estrade wrote: I have to look what this quick handler do exactly, but i work well and seems to be able to act as normal handler. ap_hook_quick_handler(cache_url_handler, NULL, NULL, APR_HOOK_FIRST); Be careful there... the quick handler bypasses a whole lot of stuff. I don't remember details, but be absolutely sure it's doing exactly what you want if you're going to use it. I don't understand why you're not writing a filter? --Cliff
Re: Can't use handler + reverse proxy
On Tue, 21 Oct 2003, Matthieu Estrade wrote: > I have to look what this quick handler do exactly, but i work well and > seems to be able to act as normal handler. > ap_hook_quick_handler(cache_url_handler, NULL, NULL, APR_HOOK_FIRST); Be careful there... the quick handler bypasses a whole lot of stuff. I don't remember details, but be absolutely sure it's doing exactly what you want if you're going to use it. I don't understand why you're not writing a filter? --Cliff
Re: Can't use handler + reverse proxy
I have to look what this quick handler do exactly, but i work well and seems to be able to act as normal handler. ap_hook_quick_handler(cache_url_handler, NULL, NULL, APR_HOOK_FIRST); Cliff Woolley wrote: On Tue, 21 Oct 2003, Cliff Woolley wrote: What exactly are you trying to do, and with what version of apache? Wait a minute, let me guess. You're trying to serve up a .cgi script or a .php file or something similar as source code from the backend and then execute/interpret it on the proxy by way of a handler. Yeah, you can't do that. :) As has been pointed out, mod_proxy is taking the role of the handler here, and you can only have one. --Cliff
Re: Can't use handler + reverse proxy
I am using Apache 2.0 and what i want to do is a applicative authentication using a form i wanted sent by the reverse proxy. But i think i will do another way, looking into mod_mem_cache how it's disable mod_proxy when it want to serve data directly from his cache... Cliff Woolley wrote: On Tue, 21 Oct 2003, Cliff Woolley wrote: What exactly are you trying to do, and with what version of apache? Wait a minute, let me guess. You're trying to serve up a .cgi script or a .php file or something similar as source code from the backend and then execute/interpret it on the proxy by way of a handler. Yeah, you can't do that. :) As has been pointed out, mod_proxy is taking the role of the handler here, and you can only have one. --Cliff
Re: Can't use handler + reverse proxy
On Tue, 21 Oct 2003, Cliff Woolley wrote: > What exactly are you trying to do, and with what version of apache? Wait a minute, let me guess. You're trying to serve up a .cgi script or a .php file or something similar as source code from the backend and then execute/interpret it on the proxy by way of a handler. Yeah, you can't do that. :) As has been pointed out, mod_proxy is taking the role of the handler here, and you can only have one. --Cliff
Re: Can't use handler + reverse proxy
On Tue, 21 Oct 2003, Matthieu Estrade wrote: > I am actually using apache as a reverse proxy, and i am trying to use a > handler with... and it doesn't work. > When i setup my SetHandler on a local virtualhost, it works well, but > when i setup it on a virtualhost doing reverse proxy, it's never called. A handler is intended to generate content, whereas with a reverse proxy the content comes from the backend server. Thus the two concepts are mutually exclusive. What exactly are you trying to do, and with what version of apache? --Cliff
Re: Can't use handler + reverse proxy
Matthieu Estrade wrote: I am actually using apache as a reverse proxy, and i am trying to use a handler with... and it doesn't work. When i setup my SetHandler on a local virtualhost, it works well, but when i setup it on a virtualhost doing reverse proxy, it's never called. any ideas ? IMHO, in teh reverse proxy case, the handler is mod_proxy. You'll have to solve this some other way I think. What exactly are you trying to accomplish with your handler? -- ir. Kris Verbeeck Software Engineer Ubizen - Ubicenter - Philipssite 5 - 3001 Leuven - Belgium T: +32 16 28 70 64 F: +32 16 28 70 77 Ubizen - We Secure e-business - www.ubizen.com
Can't use handler + reverse proxy
Hi, I am actually using apache as a reverse proxy, and i am trying to use a handler with... and it doesn't work. When i setup my SetHandler on a local virtualhost, it works well, but when i setup it on a virtualhost doing reverse proxy, it's never called. any ideas ? Matthieu
