--On Monday, March 1, 2004 8:18 PM -0800 Stas Bekman <[EMAIL PROTECTED]> 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 headers.
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.
Indeed.
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 members.
__________________________________________________________________ Stas Bekman JAm_pH ------> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
