On Tue, Mar 02, 2004 at 10:11:06AM -0800, Stas Bekman wrote:
Justin Erenkrantz wrote: ...
Correct. Because the EOS is generated by the request-level protocol handler (HTTP_IN). That's exactly how it is designed. If a connection input filter saw EOS, it'd signal end-of-connection not end-of-request. But, we don't even have EOC yet - Madhu's adding it for mod_ssl's purposes for the output chain.
That sounds very incosistent. Why connection output filters do get the EOS bucket at the end of every HTTP request (which makes them HTTP aware, no?),
but their brother input filters don't? Why it is not a problem with connection output filters?
The output filters see EOS as "end of response", and that information is useful at all levels.
The input filters see EOS in different ways because of where they are in the semantic level of parsing. At the connection level, there is no such thing as a request, so EOS can only mean "end of connection". At the request level, an EOS has the meaning of "end of request".
Any chance someone can document all that? The current state of the filters internals documentation at http://httpd.apache.org/docs-2.0/ is 'nada'. Please correct me if I'm wrong.
__________________________________________________________________ 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
