Grisha wrote ..
>
> On Wed, 4 Jan 2006, Graham Dumpleton wrote:
> 
>
> Yep.
> 
>
> Hmmm... This needs some more research. i.e. I don't quite completely
> understand why the CONTENT_LENGTH filter can only count bytes when there
> is no flush() (shortcoming of CONTENT_LENGTH or an impossibility?)...

The content length header has to be added before CONTENT_LENGTH
tries to write output from the first call into it. Thus if it doesn't detect
end of content in that first call it can't add the content length header.
It will not buffer input itself and has to write out data before it returns
from each call.

> Implicit buffering would be a significant change - if someone used
> req.write() to generate "dynamic" content (e.g. output from one of those
> traceroute sites being sent in real time), they'd be very surprised to
> not
> see the output anymore. CGI I think flushes implicitely at every end of
> line which where this behaviour comes from...
>
> On the other hand implicit flush slows things down tremenduosly when you
> have lots of req.write()s, this was discovered when PSP was added and
> that's when the no-flush argument was introduced, so if backwards
> compatibility was of no concern, I'd make implicit buffering (i.e.
> no-flush) default.

Not suggesting changing req.write() default, purely that one call of it
in mod_python.publisher(). In the case where the only content is that
returned by the publisher function, the full content is held at that point
in a single string and there will be no more later on. Thus no harm in
that one case of telling req.write() not to flush, since the next thing
mod_python.publisher will do is return apache.OK anyway, which will
cause it t be flushed anyway, but with the side effect that any output
filter will be able to detect end of content in the one call.

As to PSP flushing, you are right. I looked at the code, saw stuff like:

STATIC_STR("req.write(\"\"\"")

and misinterpreted it since I didn't see a "0" at that point. Didn't
realise it was the start of a multiline string with later:

STATIC_STR("\"\"\",0);

> And thanks for all your help BTW :-)

I thought at this point you would be getting sick of me finding all this
bugs and suggested improvements. I have managed to delay you getting
version 3.2 final out now a few times.

Anyway, all an interesting exercise digging into all of this. Maybe one
day I'll know enough about it to contemplate writing a book. ;-)

Graham

[ Post a follow-up to this message ]