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
