Re: HTTP_HEADER filter not getting added until 'insert filters'phase

[Graham Leggett <mi...@sharp.fm>]

sterling wrote:

> What do you mean by HEADERS phase?  I guess I don't know enough about the
> ordering requirements of the filters.

The AP_FTYPE_HTTP_HEADERS phase (sorry - I shortened it).

> What i did to temporarily fix the problem in my tree was add the
> add_output_filter("HTTP_HEADER"...) et. al. to the end of ap_die - this
> way, even if the request dies before the insert_filters phase we can be
> certain the headers filter is added.
> 
> that seems kinda kludgy though....

Hmmm - maybe not... If ap_die() is called, it is quite logical that the
filters stack might be incompletely formed for whatever reason. It would
be reasonable to suggest that ap_die() might fashion things to work just
enough to get things done (by adding the filters there), ie to send the
headers.

We only need to make sure that the filters are not already there should
ap_die() be called, otherwise they will be added twice. Inside the http
module there is a routine called reset_filters() in http_protocol.c that
removes all filters except CORE, CONTENT_LENGTH and HTTP_HEADER. An idea
could be to add the filters, then run reset_filters() to make sure they
only appeared once. (I have a feeling BYTE_RANGE has been fogotten).

Regards,
Graham
-- 
-----------------------------------------
minfrin@sharp.fm		"There's a moon
					over Bourbon Street
						tonight..."

Re: HTTP_HEADER filter not getting added until 'insert filters'phase

[Graham Leggett <mi...@sharp.fm>]

sterling wrote:

> That would work IFF reset_filters guarentees that there is only one
> instance of each of those filters, it looks to me like reset_filters does
> not provide that functionality (it just removes all filters not named
> {CORE,CONTENT_LENGTH,HTTP_HEADER}).

You're right (switches brain on manually, it's late and the weekend was
long).

> Even if it did, is that the desired functionality? (i.e. on error remove
> all filters except those required by the core).  I would expect we just
> want a function to ensure the request has those core filters - and
> leave all other inserted filters.  Then ap_die could call that
> function.

Maybe it should just check whether the core filters are there, and add
them if not.

Regards,
Graham
-- 
-----------------------------------------
minfrin@sharp.fm		"There's a moon
					over Bourbon Street
						tonight..."

Re: HTTP_HEADER filter not getting added until 'insert filters'phase

[sterling <st...@covalent.net>]

On Tue, 29 May 2001, Graham Leggett wrote:

> sterling wrote:
> 
> > What do you mean by HEADERS phase?  I guess I don't know enough about the
> > ordering requirements of the filters.
> 
> The AP_FTYPE_HTTP_HEADERS phase (sorry - I shortened it).
> 
> > What i did to temporarily fix the problem in my tree was add the
> > add_output_filter("HTTP_HEADER"...) et. al. to the end of ap_die - this
> > way, even if the request dies before the insert_filters phase we can be
> > certain the headers filter is added.
> > 
> > that seems kinda kludgy though....
> 
> Hmmm - maybe not... If ap_die() is called, it is quite logical that the
> filters stack might be incompletely formed for whatever reason. It would
> be reasonable to suggest that ap_die() might fashion things to work just
> enough to get things done (by adding the filters there), ie to send the
> headers.
> 
> We only need to make sure that the filters are not already there should
> ap_die() be called, otherwise they will be added twice. Inside the http
> module there is a routine called reset_filters() in http_protocol.c that
> removes all filters except CORE, CONTENT_LENGTH and HTTP_HEADER. An idea
> could be to add the filters, then run reset_filters() to make sure they
> only appeared once. (I have a feeling BYTE_RANGE has been fogotten).

That would work IFF reset_filters guarentees that there is only one
instance of each of those filters, it looks to me like reset_filters does
not provide that functionality (it just removes all filters not named
{CORE,CONTENT_LENGTH,HTTP_HEADER}).  

Even if it did, is that the desired functionality? (i.e. on error remove
all filters except those required by the core).  I would expect we just
want a function to ensure the request has those core filters - and
leave all other inserted filters.  Then ap_die could call that
function.

thoughts?

sterling