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". >... > > 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 Agreed. [and with Justin's other responses on this thread] > 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). If code needs to *query* to figure out what is going on, then I would posit that it has not been correctly hooked into the Apache processing. If you have a concrete example of something that needs to query the state, then we can examine whether it should hook into the processing differently. I bet there is a different hook or approach that can avoid a query of the state. Cheers, -g -- Greg Stein, http://www.lyra.org/
