httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stas Bekman <>
Subject Re: making filters more efficient
Date Tue, 02 Mar 2004 06:58:02 GMT
Justin Erenkrantz wrote:
> --On Monday, March 1, 2004 8:18 PM -0800 Stas Bekman <> 
> wrote:
>> It'd be very helpful if Apache provided methods to query various in 
>> and out
>> stream processing events to make filters more efficient. The events I can
>> think at the moment are:
> ...
>> - end of HTTP input headers
> I'm not sure that this is helpful because input filters aren't supposed 
> to know about the input headers.  The headers are read before the HTTP 
> input filters are 'installed' at the end of ap_read_request (i.e. no 
> request-level input filters are installed until *after* the headers are 
> read - which, of course, makes sense).

I'm talking about connection filters which process HTTP requests, not HTTP 
body filters. HTTP body filters don't need this knowledge since they never see 

At least do you agree that scanning for /\n\n/ is very inefficient, and an 
unneeded operation when Apache has already done that.

>> - end of HTTP input body
> An EOS *is* generated for this.

It does in the request filter (in and out).

It does in the connection output filter.

It does *not* in the connection input filter.

I've just double checked.

>> - end of HTTP response headers
> As soon as the first write is sent, it should be assumed that the 
> headers are written.  That is, if you want to change the headers and you 
> are an output filter, you *must* change it on the first write you 
> intercept.

Yes, this is how it works. There is no API to tell you that. e.g. what if you 
want to check from the response handler whether Apache has already sent the 
headers or not? In 1.3 the user controlled that, but that's not the case in 
2.0. The moment something sends the output the headers are flushed. that 
something at times could be an empty bucket when an uninitented flush triggers 
data out.

>> - end of HTTP response body
> An EOS is sent for this.


>> Ideally the connection record could have the following entries:
>> done_with_input_headers
>> done_with_input_body
>> done_with_output_headers
>> done_with_output_body
> As nd pointed out, this is completely invalid as that'd mean that the 
> connections now know about the underlying protocol and that violates our 
> abstraction.
> The impression I got from this email is that you want connection-level 
> filters to know about HTTP, and I'm not sure I agree with that.  If a 
> connection-level filter "needs" to know HTTP, I don't think it should be 
> a connection-level filter.  -- justin

Only connection level filters can see HTTP headers, and they need to know 
about HTTP and they do know (core http filters).

I'm not suggesting to make the connection structure HTTP dependant. I'm just 
looking for a more efficient way to write filters. And I'm all ears for the 
proper design. For example a connection record could have an member similar to 
the context, which could store protocol specific information. So for example 
the http protocol could store the above information in that structure and have 
accessors to read/write it.

Besides the connection structure is not clean of HTTP stuff at the moment. All 
this KeepAlive stuff is httpd specific and from what I can see is used (set) 
only inside http_protocol.c. Granted, other protocols may find per-use those 

Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker     mod_perl Guide --->

View raw message