> -Ursprüngliche Nachricht-
> Von: Issac Goldstand
> Gesendet: Dienstag, 12. September 2006 12:04
> An: dev@httpd.apache.org
> Betreff: why does ap_invoke_handler init input filters?
>
>
> Hi all,
> I've been trying to solve my confusion on the exact
ks and
> filters being invoked inside an HTTP request, and was wondering why
> ap_invoke_filter_init(r->input_filters) is called inside of
> ap_invoke_handler (server/config.c:338) ?
>
> I can understand initializing output filters at this point, but input
> filters that want t
Hi all,
I've been trying to solve my confusion on the exact order of hooks and
filters being invoked inside an HTTP request, and was wondering why
ap_invoke_filter_init(r->input_filters) is called inside of
ap_invoke_handler (server/config.c:338) ?
I can understand initializing output
> 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 m
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
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
> 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 a
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 ma
* "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
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 fil
> 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
> >>c
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 of
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?
m
>-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
E_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
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?
Thanks.
Aryeh
---
Aryeh Katz
Secured-Services Inc.
16 matches
Mail list logo