--On Monday, March 1, 2004 10:58 PM -0800 Stas Bekman <[EMAIL PROTECTED]> wrote:
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.
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?
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.
There's been no data written by the time the response handler is called. So, the handler can always set the headers before it does the first write. Once a write is triggered, you must assume that the headers are sent. And, that's (almost) how it was in 1.3 as well. -- justin
There are more complicated setups than just one simple script or a handler, where it could be hard to know whether the output headers set has been sent already or not. Granted that setup could write their own flag, which the rest of the application could use, but it sounds ideal for Apache to provide a set of state functions, which can tell you what exactly Apache is doing, whether it has completed something (sent headers) or has not completed (e.g. still parsing headers).
__________________________________________________________________ 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
